Certificate Exchange and Agreement Update for AS4

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.