ebxml-msg — archive

[Pim van der Eijk]

Dear ebCore, ebXML-MSG TCs, Some user communities have been asking for a standardized protocol to automatically update X.509 certificates used to secure message exchanges using ebMS.  This is intended to address the situation where two communication partners have configured an exchange that is stable as regards business functionality (message types, schemas), but still need to update their configuration periodically because certificates have a fixed lifetime and need to be replaced when they expire. Some large retail companies have thousands of communication partners. Some even have tens of thousands of partners or more.   In practice, these companies need to update and test at least some certificate configurations almost every day, which is a major operational cost and (in case mistakes are made and communication disabled) a business continuity risk.  PKI is not a solution to these situations because many,  in some geographies/industries the majority of, certificates are self-signed, not issued by any CA, and therefore need to be individually managed. The IETF CEM specification defines a mechanism that supports automated exchange of certificates. This specification, though expired ( https://tools.ietf.org/html/draft-meadors-certificate-exchange-14 ), is implemented in some products for AS2 and used by some user communities.   However, it is more suited to protocols like AS2 than to ebMS,  which has richer configuration concepts (ebMS3/AS4 P-Modes, CPP/CPA 2.0 for ebMS 2.0) and a concept of agreements that can be taken advantage of to manage multiple configurations, each with their own certificate sets and lifetimes, in parallel. Uploaded to https://www.oasis-open.org/apps/org/workgroup/ebcore/document.php?document_id=55644 is a new draft schema, documentation and examples for a CEM-like mechanism suited for ebMS, 2.0, 3.0 and AS4.   Below is an introduction to the schema and overall approach. It also relates this work to CEM. As an aside, the schema uses element and type substitution to provide extensibility.  While the schema currently is limited to certificate updates,  it could be enhanced easily for other common configuration updates, such as server address URL or IP address updates.   However,  tweaking existing configurations is what it is about.  it is not intended to support the more ambitious automation of the initial set-up of an exchange. Looking forward to any comments, Pim van der Eijk ---- What is included in the ZIP file: -   a single XML schema AgreementUpdate.xsd ,  which covers three message types (and underlying elements and types): AgreementUpdateRequest, AgreementUpdateResponse, AgreementUpdateException. -   a subdirectory documentation .  Click on index.html,  this provides the most user-friendly access to the schema documentation.  This documentation is actually generated from embedded schema documentation. -   a subdirectory samples :  a request message,  a positive response message and a negative response message. Introduction to the schema (excerpted from the documentation): This schema defines XML structures supporting the updating of configurations of B2B gateways among communication partners. The XML schema is independent of any particular product, and support both automated and manual updates. This schema is based on the concept of agreements, which denote sets of configuration parameters and parameter values used to control a particular exchange type, or sets of exchange types. At any particular point in time one or multiple agreements may be in place. For various reasons, one or multiple parameter values associated with a particular agreement may cease to be valid. The schema allows partners to create new agreements based on existing agreements by proposing and confirming updates to these agreements. Updates may be confirmed (accepted) or rejected. Once a new agreement has been agreed, partners may stop using the agreement it is based on, but it is also possible to use the old and the new agreement in parallel. The following XML elements are to be used as top-level elements in XML documents. AgreementUpdateRequest is the request document. AgreementUpdateResponse is the positive response document. AgreementUpdateException is the negative response document. This schema does not provide a full XML schema for ebMS3/AS4 processing modes. It is assumed that partners agree on an initial configuration using some other mechanism, this schema allows them to then update this configuration for common types of updates. As regards type of updates, the initial aim is to support the exchange and update of X.509 certificates. These certificates have a limited lifetime and need to be replaced before they expire. This schema and the exchange of documents based on it allows partners to set up, deploy and test new configurations before old configurations expire or are disabled, allowing communication to continue without disruption and without the risk that an error in an update results in a complete breakdown of communication. As regards communication protocols, this schema is primarily aimed to support ebMS3/AS4 messaging. This assumes some profiling of AS4. In particular, the AgreementRef element has to be included in AS4 messages. Also, products must support associated of AgreementRef values to configured PModes and to information linked to those PModes that is intended to be updated. Note that other protocols that have a concept of agreement can be supported in a similar way. In particular, the older ebMS2 protocol can easily be supported. In ebMS2, the cpaid element is a mandatory element that serves the same purpose as AgreementRef in ebMS3. This schema is inspired by the IETF Certificate Exchange Message (CEM), the latest version of which is available at https://tools.ietf.org/html/draft-meadors-certificate-exchange-14 . Compared with CEM, this schema differs as follows: CEM is closely linked to, and inspired by, the MIME-based packaging of AS1/AS2/AS3. The CEM specification assumes a combination of an XML schema and binary certificates exchanged in separate MIME parts. This schema is only based on exchange of XML document payloads. For the exchange of X.509 certificate data, it uses structures defined in the W3C XML Signature recommendation. CEM is not based on the concepts of agreements. Instead, it requires gateways to support old and new certificates in parallel. The concept of agreements allows gateways to unambiguously select a specific agreement. The CEM request specifies the CertUsage for a certificate. In this schema, a proposed new certificate is associated with the certificate it is to replace. This means that the new certificate will function for whatever usage the old certificate was used. The schema provides future extensibility options to common configuration updates other than certificate changes. The current suggestion is to propose to standardize this specification via the OASIS ebCore maintenance committee.