Draft                       CEM for EDIINT                  March 2007


   Private                                                   K. Meadors
   Internet-Draft                                   Drummond Group Inc.
   Document: draft-meadors-certificate-exchange-              D. Moberg
   06.txt                                                   Axway, Inc.
   Expires: September 2007                                   March 2007



                 Certificate Exchange Messaging for EDIINT
                 draft-meadors-certificate-exchange-06.doc

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

Status of this Memo

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.html
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

   Any questions, comments, and reports of defects or ambiguities in
   this specification may be sent to the mailing list for the EDIINT
   working group of the IETF, using the address <ietf-ediint@imc.org>.
   Requests to subscribe to the mailing list should be addressed to
   <ietf-ediint-request@imc.org>.


Abstract

   The EDIINT AS1, AS2 and AS3 message formats do not currently contain
   any neutral provisions for transporting and exchanging trading
   partner profiles or digital certificates. EDIINT Certificate Exchange
   Messaging provides the format and means to effectively exchange
   certificates for use within trading partner relationships. The
   messaging consists of two types of messages, Request and Response,
   which allow trading partners to communicate certificates, their


Meadors, Moberg        Expires - September 2007               [Page 1]


Draft                       CEM for EDIINT                  March 2007


   intended usage and their acceptance through XML. Certificates can be
   specified for use in digital signatures, data encryption or SSL/TLS
   over HTTP (HTTPS).


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

Feedback Instructions

   NOTE TO RFC EDITOR:  This section should be removed by the RFC editor
   prior to publication.

   If you want to provide feedback on this draft, follow these
   guidelines:

   -Send feedback via e-mail to kyle@drummondgroup.com, with
   "Certificate Exchange" in the Subject field.

   -Be specific as to what section you are referring to, preferably
   quoting the portion that needs modification, after which you state
   your comments.

   -If you are recommending some text to be replaced with your suggested
   text, again, quote the section to be replaced, and be clear on the
   section in question.


Table of Contents

   1. Introduction...................................................3
      1.1 Overview...................................................3
      1.2 Terminology and Key Word Convention........................4
      1.3 Certificate Lifecycle......................................5
      1.4 Certificate Exchange Process...............................6
   2. Message Processing.............................................7
      2.1 Message Structure..........................................7
      2.2 EDIINT Features Header.....................................9
      2.3 Certificate Exchanging.....................................9
      2.4 Certificate Implementation................................10
      2.5 CEM Response..............................................12
   3. CEM XML Schema Description....................................13
      3.1 EDIINTCertificateExchangeRequest element..................13
      3.2 EDIINTCertificateExchangeResponse element.................17
   4. Use Case Scenario.............................................18
   5. Profile Exchange Messaging....................................20


Meadors, Moberg        Expires - September 2007               [Page 2]


Draft                       CEM for EDIINT                  March 2007


   6. Implementation Considerations.................................21
   7. Future Considerations for CEM I–D.............................21
   8. Security Considerations.......................................21
   9. IANA Considerations...........................................22
   10. References...................................................22
      10.1 Normative References.....................................22
      10.2 Informative References...................................23
   11. Acknowledgments..............................................23
   Author's Addresses...............................................23
   Appendix.........................................................24
      A.1 EDIINT Certificate Exchange XML Schema....................24
      A.2 Example of EDIINT Certificate Exchange Request XML........27
      A.3 Example of EDIINT Certificate Exchange Response XML.......28
   Changes from Previous Versions...................................28
      B.1 Updates from Version 00...................................28
      B.2 Updates from Version 01...................................29
      B.3 Updates from Version 02...................................29
      B.4 Updates from Version 03...................................29
      B.5 Updates from Version 04...................................29
      B.6 Updates from Version 05...................................29


1.
   Introduction

1.1
    Overview

   The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in
   numerous supply-chains was due in part to the security feature which
   was provided. The security is not possible without the digital
   certificates which enable it. To maintain the level of security
   necessary to transmit business documentation, existing certificates
   must occasionally be replaced and exchanged with newer ones. The
   exchanging of digital certificates is unavoidable given how
   certificates can expire or become compromised. Complicating this is
   supply-chains which cannot afford to shutdown their business
   transactions while trading partners laboriously upload new
   certificates. Certificate exchange must be accomplished in a reliable
   and seamless format so as not to affect ongoing business
   transactions.

   This document describes how EDIINT products may exchange public-key
   certificates. Since EDIINT is built upon the security provided by
   public-private key pairs, it is vital that implementers are able to
   update their trading partners with new certificates as their old
   certificates expire, become outdated or insecure. Certificate
   Exchange Messaging (CEM) described here utilizes XML data to exchange
   the certificate and provide information on its intended usage and
   acceptance within the trading partner relationship. There are two
   types of CEM messages. The CEM Request which presents the new


Meadors, Moberg        Expires - September 2007               [Page 3]


Draft                       CEM for EDIINT                  March 2007


   certificate to be introduced into the trading partner relationship
   and the CEM Response which is the recipient’s response to the CEM
   Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or
   AS3 [AS3] message transports. However, it is possible to leverage CE
   messaging through other transport standards besides EDIINT.

1.2
    Terminology and Key Word Convention

   [RFC2828] provides a glossary of Internet security terms, and several
   of their definitions are listed here verbatim. However, some
   definitions required for this document were undefined by [RFC2828] or
   rewritten to better explain their specific use within CEM.

   Certificate - A digital certificate contains the owner’s (End
   Entity’s) name, the issuer’s name, a serial number, expiration date,
   and a copy of the owner’s Public Key. The Public Key is used for
   Encrypting messages and Verifying Signatures (verifying a signature
   is also called Authentication).

   Certificate Revocation List (CRL) - A data structure that enumerates
   digital certificates that have been invalidated by their issuer prior
   to when they were scheduled to expire. [RFC2828]

   Certification Authority (CA) - An entity that issues digital
   certificates (especially X.509 certificates) and vouches for the
   binding between the data items in a certificate. [RFC2828]

   CA Certificate - A certificate issued by a trusted certification
   authority. CA certificates are not used to encrypt data but to sign
   other certificates. CA certificates are signed by themselves, but are
   not considered self-signed certificates for the purpose of this
   document.

   Certification Hierarchy - In this structure, one CA is the top CA,
   the highest level of the hierarchy. The top CA may issue public-key
   certificates to one or more additional CAs that form the second
   highest level. Each of these CAs may issue certificates to more CAs
   at the third highest level, and so on. The CAs at the second-lowest
   of the hierarchy issue certificates only to non-CA entities, called
   "end entities" that form the lowest level. Thus, all certification
   paths begin at the top CA and descend through zero or more levels of
   other CAs. All certificate users base path validations on the top
   CA's public key. [RFC2828]

   CEM Request - The EDIINT Certificate Exchange Messaging (CEM) Request
   is one of two possible CEM messages. It presents a certificate to be
   introduced into the trading partner relationship along with relevant
   information on how it is to be implemented.



Meadors, Moberg        Expires - September 2007               [Page 4]


Draft                       CEM for EDIINT                  March 2007


   CEM Response - The EDIINT Certificate Exchange Messaging (CEM)
   Response is one of two possible CEM messages. It is the response to
   the CEM Request indicating whether or not the end entity certificate
   present in the CEM Request was accepted.

   End Entity - A system entity that is the subject of a public-key
   certificate and that is using, or is permitted and able to use, the
   matching private key only for a purpose or purposes other than
   signing a digital certificate; i.e., an entity that is not a CA.
   [RFC2828]

   End Entity Certificate - A certificate which is used to encrypt data
   or authenticate a signature. (The private key associated with the
   certificate is used to decrypt data or sign data). The certificate
   may be self-signed or issued by a trusted certificate.

   Intermediary Certificate - A certificate issued by a CA certificate
   which itself issues another certificate (either intermediary or end
   entity). Intermediary certificates are not used to encrypt data but
   to sign other certificates.

   Public Key - The publicly-disclosable component of a pair of
   cryptographic keys used for asymmetric cryptography. [RFC2828]

   Public Key Certificate - A digital certificate that binds a system
   entity's identity to a public key value, and possibly to additional
   data items. [RFC2828]

   Self-signed Certificate - A certificate which is issued by itself
   (both issuer and subject are the same) and is an End Entity
   certificate.

1.3
   Certificate Lifecycle

   A certificate has five states.

   1. Pending - Upon receiving a certificate from a trading partner, the
      certificate is marked as Pending until a decision can be made to
      trust it or if its validity period has not yet begun.
   2. Rejected - If a Pending certificate is not trusted, it is
      considered Rejected.
   3. Accepted - Once a Pending certificate has been trusted, it is
      considered Accepted. An Accepted certificate may be used in
      secure transactions.
   4. Expired - A certificate which is no longer valid because its
      expiration date has passed. Expired certificates SHOULD be kept
      in a certificate storehouse for decrypting and validating past
      transactions.



Meadors, Moberg        Expires - September 2007               [Page 5]


Draft                       CEM for EDIINT                  March 2007


   5. Revoked - A certificate which has been explicitly revoked by its
      owner or the certificate authority.

1.4
   Certificate Exchange Process

   This section describes a process whereby a company can distribute
   certificates to its partners, and the company and its partners can
   put the certificates into use. Later sections describe the specific
   CEM protocol, which is an implementation of this process.

   The exchange process can be used even when CEM is not useable, for
   example, when the transport protocols or installed software systems
   do not support CEM. It is RECOMMENDED that this process be followed
   in distributing certificates.


   The company that owns the certificates initiates the process. For a
   certificate that is to be used (by the partners) to encrypt messages,
   the initiator first prepares his system to decrypt messages that are
   encrypted with this certificate. The initiator must also be able to
   decrypt messages using the old certificate. The initiator company
   distributes the new certificates by some means. The distribution MUST
   describe the purposes of the certificates and MAY contain a respond
   by date, the date when the distributor expects to put the
   certificates in use. The respond by date SHOULD be present for
   certificates that are used to sign messages or to authenticate
   TLS/SSL connections.

   When a partner receives a certificate, the partner should
   authenticate the distribution message by some means. (CEM provides
   for automatic authentication.  Partners can use manual methods,
   either with or without CEM.)

   When a partner receives a certificate for use in encrypting messages
   and has authenticated the certificate, the partner SHOULD  begin
   using that certificate to encrypt messages. The initiator MUST be
   prepared to receive messages encrypted with either the old or new
   certificate.

   When a partner receives a certificate for use in digitally signing
   messages or for TLS/SSL authentication and has authenticated the
   certificate, the partner MUST prepare his system to accept messages
   that are signed or authenticated with the new certificate.  The
   partner MUST also accept messages signed or authenticated with the
   old certificate.

   The partner MAY return a response to the initiator, indicating that
   the partner has accepted the new certificate and put it in use.  The



Meadors, Moberg        Expires - September 2007               [Page 6]


Draft                       CEM for EDIINT                  March 2007


   initiator can use these responses to track which partners are ready
   to use the new certificate.

   When the partner has sent a response indicating acceptance of the new
   certificate, or when the respond by date has passed, the initiator
   can begin using the new certificate to digitally sign messages or
   authenticate TLS/SSL messages. The initiator MUST NOT sign or
   authenticate messages with the new certificate until the partner has
   accepted it or until the respond by date has passed. The initiator
   MAY wait until the respond by date or until all partners have
   accepted.  The partners MUST accept messages signed or authenticated
   with either the old or new certificate.

   When the process is fully automated, it is not necessary to have a
   specific time when both the initiator and partners switch to the new
   certificate.

   The initiator MUST be able to decrypt messages with both the old and
   new certificates as soon as the new certificates are distributed.
   The partners MUST be able to accept messages signed or TLS/SSL
   authenticated with either the old or new certificates after they have
   accepted the new certificate.  The initiator SHOULD allow a
   reasonable time after distributing a new signing or authenticating
   certificate before putting it in use, so that partners have time to
   authenticate the new certificate and prepare their systems for it.

   For a certificate used to digitally sign messages or authenticate
   TLS/SSL messages, there must be some way for the initiator to know
   when partners are ready to receive the certificate. For example, this
   may be a response from the partners, an explicit respond by date in
   the initial distribution, an implied respond by date based on partner
   agreements, or the expiration date of the old certificate.  For a
   certificate used to encrypt messages, the respond by date and
   responses are less important, but responses may be useful to track
   partners’ acceptances.


2.
  Message Processing

2.1
   Message Structure

   CEM messages use the underlying EDIINT transport, such as AS2, to
   communicate information on the certificate, its intended use and its
   acceptance. Both digital certificates and the XML data describing
   their intended use are stored within a multipart/related MIME
   envelope [RFC2387]. For the CEM Request message, the certificates are
   stored in certificate chains through SMIME, certs-only MIME envelope
   [3851], and processing information is XML data which is identified



Meadors, Moberg        Expires - September 2007               [Page 7]


Draft                       CEM for EDIINT                  March 2007


   through the MIME content-type of application/ediint-cert-
   exchange+xml. The format for a CEM Request message is as follows:

   Various EDIINT headers
   Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company
   Content-Type: multipart/signed; micalg=sha1;
   protocol="application/pkcs7-signature";
     boundary="--OUTER-BOUNDARY"

   ----OUTER-BOUNDARY
   Content-Type: multipart/related; type="application/ediint-cert-
   exchange+xml"; boundary="--INNER-BOUNDARY"

   ----INNER-BOUNDARY
   Content-Type: application/ediint-cert-exchange+xml
   Content-ID: <20040101-1.alpha@example.org>

   [CEM XML data]
   ----INNER-BOUNDARY
   Content-Type: application/pkcs7-mime; smime-type=certs-only
   Content-ID: <20040101-2.alpha@example.org>

   [digital certificate]
   ----INNER-BOUNDARY--

   ----OUTER-BOUNDARY
   Content-Type: application/pkcs7-signature

   [Digital Signature]
   ----OUTER-BOUNDARY--

   One and only one MIME type of application/ediint-cert-exchange+xml
   MUST be present in the multipart/related structure, and it MUST be
   the root element. Multiple certs-only media types may be included,
   but at least one MUST be present. A unique content-id header MUST be
   present within each of the multipart structures.

   For the CEM Response message, a multipart/related MIME structure is
   also used. However, no certificates are present in a CEM Response,
   and the multipart/related structure only contains one MIME type of
   application/ediint-cert-exchange+xml. The format for a CEM Request
   message is as follows:

   Various EDIINT headers
   Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company
   Content-Type: multipart/signed; micalg=sha1;
   protocol="application/pkcs7-signature";
     boundary="--OUTER-BOUNDARY"



Meadors, Moberg        Expires - September 2007               [Page 8]


Draft                       CEM for EDIINT                  March 2007


   ----OUTER-BOUNDARY
   Content-Type: multipart/related; type="application/ediint-cert-
   exchange+xml"; boundary="--INNER-BOUNDARY"

   ----INNER-BOUNDARY
   Content-Type: application/ediint-cert-exchange+xml
   Content-ID: <20040201-1.alpha@example.org>

   [CEM XML data]
   ----INNER-BOUNDARY--

   ----OUTER-BOUNDARY
   Content-Type: application/pkcs7-signature

   [Digital Signature]
   ----OUTER-BOUNDARY--


   If possible, both the CEM Request and CEM Response message SHOULD be
   signed. Applying digital signatures will allow for automatic exchange
   based on a previous trust relationship. However, it may not be
   possible in the initial exchange of a new trading partner. If a CEM
   message is signed, the signing certificate MUST be included in the
   digital signature. Extra security such as applying data encryption or
   compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and
   SHOULD request a signed MDN. The MDN can be either synchronous or
   asynchronous. All necessary headers MUST be applied to the message
   per the underlying transport standard.

2.2
   EDIINT Features Header

   To indicate support for CEM, an EDIINT application MUST use the
   EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates
   the instance application can support various features, such as
   certification exchange. The header is present in all messages from
   the instance application, not just those which feature certification
   exchange.

   For applications implementing certification exchange, the CEM-
   Feature-Name MUST be used within the EDIINT Features header:

      CEM-Feature-Name = "CEM"

   An example of the EDIINT Features header in a CEM Message:

      EDIINT–Features: CEM

2.3
   Certificate Exchanging



Meadors, Moberg        Expires - September 2007               [Page 9]


Draft                       CEM for EDIINT                  March 2007


   After obtaining the desired certificate, the initiator of the
   certificate exchange transmits the end-entity certificate in the CEM
   Request message. If the end-entity certificate is not self-signed,
   then the CA certificate and any other certificates needed to create
   the chain of trust for the end-entity certificate MUST be included in
   the CEM Request message. Multiple end-entity certificates MAY also be
   present.

   The entire certificate trust chain is stored in a BER encoded P7C
   format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs-
   only MIME envelope which is then stored in a single part of the
   multipart/related structure. Each P7C trust chain MUST include a
   single end-entity certificate and its trust authorities. No other
   certificates are to be part of this chain. The number of P7C trust
   chains in a CEM Request message MUST be equal to the number of end-
   entity certificates being communicated in the CEM XML document.
   If different end-entity certificates have common trust authorities’
   certificates, each P7C cert chain still MUST include each certificate
   necessary to create a trust anchor. Thus, if a recipient can not
   create a trust relationship from the P7C cert chain, it MAY reject
   the end-entity certificate in the CEM Request.

   End-entity certificates are referenced and identified in the XML data
   by their content-id used in the multipart/related structure.
   Information on how the certificate is to be used, or certificate
   usage, by the receiving user agent and other related information is
   found in the XML data. A certificate can be used for a single
   function, like digital signatures, or used for multiple functions,
   such as both digital signatures and data encryption. If a certificate
   is intended for multiple usages, such as for both digital signatures
   and data encryption, the certificate MUST be listed only once in the
   CEM Request message and its multiple usage listed through the
   CertUsage XML element.

   Upon receipt of the CEM Request, the recipient trading partner
   processes the transport message as normal and returns the MDN. The
   recipient MAY parse the CEM XML data prior to returning the MDN. If
   the XML is not well–formed and can not be interpreted, the UA MAY
   return the MDN with the error disposition modifier of "error:
   unexpected-processing-error". The returned MDN does not provide
   information on the acceptance of the certificate(s) being exchanged.
   An UA who receives an MDN with an error disposition modifier MUST
   consider the CEM Message was not understood and needs to be corrected
   and retransmitted.


2.4
   Certificate Implementation




Meadors, Moberg        Expires - September 2007              [Page 10]


Draft                       CEM for EDIINT                  March 2007


   The new certificate is considered to be in the Pending state for the
   recipient who MUST decide whether to accept the certificate as
   trustworthy. This decision is arbitrary and left to each individual
   trading partner. Upon accepting the certificate, it is to be
   considered an Accepted certificate within the trading partner
   relationship. If the certificate is not accepted, it is considered
   Rejected.

   When a certificate is intended for use in data encryption, the
   initiator MUST consider the certificate to be Accepted and be
   prepared for its trading partner to begin using the certificate upon
   generating the CEM Request message. After a recipient generates a
   positive CEM Response message for a certificate, the recipient MUST
   immediately begin using the certificate in trading with the initiator
   of the request. The recipient MAY apply encryption to the CEM
   Response message using the new Accepted certificate or MAY apply
   encryption to the CEM Response message using the previously Accepted
   encryption certificate.

   When a certificate is intended for use in digital signatures or
   TLS/SSL authentication, the initiator MUST NOT use the certificate
   until the recipient trading partner generates a CEM Response
   accepting the certificate or the respond by date, which is listed in
   the RespondByDate XML element. The initiator MAY use the certificate
   after the respond by date, regardless of whether the partner has
   accepted it or not. The certificate used for the digital signature of
   the CEM Request message MUST be the one which is currently Accepted
   within the trading partner relationship.

   Since implementers of EDIINT often use the same certificate with
   multiple trading partners, implementers of CEM MUST be able to keep
   both the old and new certificates as Accepted. If the initiator has
   generated a CEM Request and exchanged a new encryption certificate to
   multiple trading partners, it MUST be able to accept encrypted data
   which uses either the older, existing encryption certificate or the
   newly exchanged encryption certificate. Likewise, a recipient of a
   CEM Request MUST be able to authenticate digital signatures using
   either the new or old certificates, since the initiator may not be
   able to switch certificates until all trading partners accept the new
   certificate. Similar provisions MUST be made for certificates
   intended for TLS/SSL server and client authentication. Revoking a
   certificate MUST be done outside of CEM.

   If a CEM Request message contains a certificate which is currently
   Accepted and has the identical usage for the certificate that has
   been Accepted, the recipient MUST NOT reject the duplicate
   certificate but MUST respond with a CEM Response message indicating
   the certificate has been accepted. For example, if Certificate A is
   currently Accepted as the encryption certificate for a user agent,


Meadors, Moberg        Expires - September 2007              [Page 11]


Draft                       CEM for EDIINT                  March 2007


   any CEM Request message containing Certificate A with the usage as
   encryption only MUST be accepted by an existing trading partner. This
   situation may be necessary for an implementation intending to verify
   its current trading partner certificate.

   If two trading partners utilize multiple EDIINT protocols for
   trading, such as AS2 for a primary transport and AS1 as the backup
   transport, it is dependent upon implementation and trading partner
   agreement how CEM messages are sent and which transports the
   exchanged certificates affect.

2.5
   CEM Response

   The CEM Response message is a multipart/related envelope which
   contains the CEM XML under the MIME type of application/ediint-cert-
   exchange+xml. If a requestId is used in a CEM Request, then the
   requestId MUST be present in the CEM Response with the same value.
   The requestId allows for the CEM Response to be matched to the CEM
   Request. If the CEM Request contains multiple TrustRequest elements
   and the corresponding TrustResponse elements are returned in multiple
   CEM Response messages, each CEM Response message MUST use the same
   requestId from the originating CEM Request message. This is critical
   when multiple CEM Requests are sent with the same certificate and the
   CEM Response can not be matched solely through the TrustResponse
   elements.

   A TrustResponse XML element provides information needed to match the
   end-entity certificate sent in an earlier CEM Request and indicate if
   the certificate was accepted or rejected by the recipient. The
   CertificateReference in a TrustResponse matches the
   CertificateIdentifier value for the end-entity certificate in the CEM
   Request. CertStatus indicates if the certificate was accepted or
   rejected. If a CEM Request is received, the recipient MUST respond
   with a CEM Response message indicating if the certificate is Accepted
   or Rejected. More information about the XML attributes and value for
   CEM Response can be found in 3.2.

   If the certificate in the CEM Request message contains multiple
   usages, such as for both digital signature and data encryption, only
   a single TrustResponse is needed for that certificate. The CertStatus
   value in the TrustResponse is the response for both usages of the
   certificate. A recipient MUST NOT choose to accept the certificate
   for one specified use and not the other.

   If multiple end-entity certificates were included within the CEM
   Request, the recipient MAY generate individual CEM Response messages
   for each certificate or the recipient MAY consolidate the
   TrustResponse for multiple certificates into one CEM Response
   message. A CEM Response may contain multiple TrustResponse elements


Meadors, Moberg        Expires - September 2007              [Page 12]


Draft                       CEM for EDIINT                  March 2007


   for different certificates but MUST NOT contain two or more
   TrustResponses for the same certificate.

   If a second TrustResponse is received in a different message matching
   the same certificate as that of an earlier TrustRespnse but the
   CertStatus has a different value than the other, the originator MAY
   accept the CertStatus value in the most recent TrustResponse but MAY
   choose to ignore it. If the CertStatus in both TrustResponses are the
   same, the originator should disregard the second TrustResponse.

   If the originator receives a CEM Response message which violates the
   rules listed above or is invalid in any way, the originator MAY
   reject the message entirely but MUST return an MDN if requested.


3.
  CEM XML Schema Description

   The CEM schema has two top-level elements,
   EDIINTCertificateExchangeRequest and
   EDIINTCertificateExchangeResponse. The
   EDIINTCertificateExchangeRequest element is present only in the CEM
   Request message, and the EDIINTCertificateExchangeResponse is present
   only in the CEM Response message. All other elements nest directly or
   indirectly from these. CEM XML data must be well–formed and valid
   relative to the CEM XML Schema. Please refer to the appendix for the
   actual schema document.

3.1
   EDIINTCertificateExchangeRequest element

   EDIINTCertificateExchangeRequest contains element TradingPartnerInfo,
   which can only appear once, and TrustRequest, which may be present
   multiple times. TrustRequest contains information on a certificate
   and its intended usage. TradingPartnerInfo exists to provide
   information on the publication of the CEM Request message since
   processing of the XML data may occur apart from the handling of the
   accompanying transport message, for example the AS2 request.

      <xs:element name="EDIINTCertificateExchangeRequest">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustRequest"
                  type="tns:TrustRequestType"
                  maxOccurs="unbounded"/>
               <xs:element ref=”tns:Extensions” minOccurs=”0”
               maxOccurs=”1”/>
            </xs:sequence>
            <xs:attribute name=”requestId” type=”tns:RequestIdType”
            use=”optional”/>


Meadors, Moberg        Expires - September 2007              [Page 13]


Draft                       CEM for EDIINT                  March 2007


            <xs:anyAttribute namespace=”##any” processContents=”lax”/>
         </xs:complexType>
      </xs:element>

   EDIINTCertificateExchangeRequest also contains the attribute
   requestId. RequestId uniquely identifies each CEM Request message.
   Its value MUST be between 1 and 255 characters. The requestId is
   returned in the CEM Response message to assist the UA in matching the
   CEM Response with the CEM Request.

      <xs:simpleType name="RequestIdType">
         <xs:restriction base="xs:string">
            <xs:minLength value="1"/>
            <xs:maxLength value="255"/>
         </xs:restriction>
      </xs:simpleType>

   An optional Extension element is also present along with the
   anyAttribute attribute. They exist to provide future extendibility
   for new features which may be developed but not yet defined within
   CEM. They are present in several locations in the schema for this
   future extendibility.

      <xs:element name="Extensions">
         <xs:complexType>
            <xs:sequence>
               <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>

   TradingPartnerInfo identifies the entity that created the CEM message
   through the nested Name element. Both the qualifier attribute and the
   element value of Name follow mandatory naming conventions. The
   qualifier attribute is to be the transport standard utilized. For
   example, "AS1", "AS2" or "AS3". The value of the Name element is the
   same value in the From header utilized by the transport. For AS2 and
   AS3, this is the value in the AS2–From and AS3–From headers,
   respectively. For AS1, this is the value of the From header. If other
   transports besides AS1, AS2, AS3 are used, the same naming convention
   SHOULD be followed.

   MessageOriginated is included in TradingPartnerInfo to identify the
   time and date the message was created. The MessageOriginated date and
   time values MUST follow XML standard dateTime type syntax and be
   listed to at least the nearest second and expressed in local time
   with UTC offset. For example, a message originating from the US
   Eastern Standard timezone would use 2005-03-01T14:05:00-05:00.


Meadors, Moberg        Expires - September 2007              [Page 14]


Draft                       CEM for EDIINT                  March 2007



      <xs:element name="TradingPartnerInfo">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="Name">
                  <xs:complexType>
                     <xs:simpleContent>
                        <xs:extension base="xs:string">
                           <xs:attribute name="qualifier"
                            type="xs:string" />
                        </xs:extension>
                     </xs:simpleContent>
                  </xs:complexType>
               </xs:element>
               <xs:element name="MessageOriginated" type="xs:dateTime"/>
               <xs:any namespace="##any" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>
      </xs:element>

   The TrustRequest element contains the EndEntity, CertUsage,
   RespondByDate and ResponseURL elements. The required EndEntity
   element is found only once in a TrustRequest element and contains the
   content-id reference to the end-entity certificate being exchanged.

      <xs:complexType name="TrustRequestType">
         <xs:sequence>
            <xs:element ref="tns:CertUsage" maxOccurs="unbounded"/>
            <xs:element ref="tns:RespondByDate" minOccurs=”0”/>
            <xs:element ref="tns:ResponseURL"/>
            <xs:element name="EndEntity" type="tns:EndEntityType"/>
            <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>

   EndEntity contains the nested elements of CertificateIdentifier and
   CertificateContentID. CertificateContentID is a string element which
   references the content-id of the multipart/related structure where
   the certificate is stored. CertificateIdentifier comes from the XML
   Signature schema namespace [XML-DSIG].

      <xs:complexType name="EndEntityType">
         <xs:sequence>
            <xs:element name="CertificateIdentifier"
                type="ds:X509IssuerSerialType"/>


Meadors, Moberg        Expires - September 2007              [Page 15]


Draft                       CEM for EDIINT                  March 2007


            <xs:element name="CertificateContentID" type="xs:string"/>
            <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>

   CertificateIdentifier contains the string element X509IssuerName and
   the integer element X509SerialNumber. X509SerialNumber is the
   assigned serial number of the end entity certificate as it is listed.
   X509IssuerName contains the issuer name information of the end-entity
   certificate, such as common name, organization, etc. This information
   MUST be described in a string format per the rules of RFC 2253
   [RFC2253]. This results in the attributes within the Issuer Name to
   be listed with their attribute type followed by an "=" and the
   attribute value. Each attribute type and value are separated by a ","
   and any escape characters in the value are preceded by a "\". Refer
   to the appendix and the sample CEM Request message for an example of
   the X509IssuerName.

         <complexType name="X509IssuerSerialType">
               <sequence>
                    <element name="X509IssuerName" type="string"/>
                    <element name="X509SerialNumber" type="integer"/>
              </sequence>
        </complexType>

   CertUsage is an unbounded element which contains enumerated values on
   how the exchanged certificate is to be used. There are enumerated
   values for SMIME digital signatures (digitalSignature), SMIME data
   encryption (keyEncipherment), the server certificate used in TLS
   transport encryption (tlsServer) and the client certificate used in
   TLS transport encryption (tlsClient). While the element is unbounded,
   CertUsage only has a potential number of four occurrences due to the
   limit of the enumerated values.

      <xs:element name="CertUsage" type="tns:CertUsageType"/>
      <xs:simpleType name="CertUsageType">
         <xs:restriction base="xs:string">
            <xs:enumeration value="tlsClient"/>
            <xs:enumeration value="tlsServer"/>
            <xs:enumeration value="keyEncipherment"/>
            <xs:enumeration value="digitalSignature"/>
         </xs:restriction>
      </xs:simpleType>

   RespondByDate is a required element of the XML standard dateTime type
   expressed in local time with UTC offset, which provides information
   on when the certificate should be trusted, inserted into the trading


Meadors, Moberg        Expires - September 2007              [Page 16]


Draft                       CEM for EDIINT                  March 2007


   partner relationship and responded to by a CEM Response message. If
   the certificate can not be trusted or inserted into the trading
   partner relationship, the CEM Response message should still be
   returned by the date indicated.

      <xs:element name="RespondByDate" type="xs:dateTime"/>

   ResponseURL is an element which indicates where the CEM Response
   message should be sent. This value takes precedence over the existing
   inbound URL of the current trading partner relationship. The Response
   MUST use the same transport protocol (AS1, AS2, or AS3) as the
   Request.
      <xs:element name="ResponseURL" type="xs:anyURI"/>

3.2
   EDIINTCertificateExchangeResponse element

   EDIINTCertificateExchangeResponse contains the two elements
   TradingPartnerInfo and TrustResponse and the attribute requestId.
   TradingPartnerInfo, which is also found in
   EDIINTCertificateExchangeRequest, describes the trading partner
   generating this response message. TrustResponse provides information
   on the acceptance of a previously sent end entity certificate. There
   can be multiple TrustResponse elements within an
   EDIINTCertificateExchangeResponse. The requestId is the same value
   from a previously sent CEM Request message. The requestId from the
   CEM Response is matched up with the CEM Request.

      <xs:element name="EDIINTCertificateExchangeResponse">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustResponse"
                   type="tns:TrustResponseType"
                   maxOccurs="unbounded"/>
               <xs:element ref="tns:Extensions" minOccurs="0"
                  maxOccurs="1"/>
            </xs:sequence>
            <xs:attribute name="requestId" type="tns:RequestIdType"
             use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>
      </xs:element>

      <xs:complexType name="TrustResponseType">
         <xs:sequence>
            <xs:element ref="tns:CertStatus"/>
            <xs:element ref="tns:ReasonForRejection" minOccurs="0"/>
            <xs:element name="CertificateReference"
                        type="ds:X509IssuerSerialType"/>


Meadors, Moberg        Expires - September 2007              [Page 17]


Draft                       CEM for EDIINT                  March 2007


            <xs:any namespace="##any" processContents="lax"
             minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>

   A TrustResponse element identifies a certificate which has been
   previously exchanged within the trading partner relationship through
   a CEM Request and now has been either accepted or rejected by the
   partner. The CertificateReference element is of the same type as the
   CertificateIdentifier element. A CertificateReference element in a
   CEM Response MUST be identical to its CertificateIdentifier
   counterpart in the associated CEM Request since they identify the
   same certificate in question.

   The required element CertStatus has the enumerated values of
   "Accepted" or "Rejected". "Accepted" indicates the certificate was
   trusted by the trading partner and is now ready for use within the
   trading partner relationship, and "Rejected" indicates the
   certificate is not trusted by the trading partner nor can it be
   currently used with the trading partner relationship. If the value of
   "Rejected" is chosen, the optional string element ReasonForRejection
   may be included. If present, ReasonForRejection should contain a
   brief description of why the certificate was not accepted. Since the
   value for this element is not enumerated but open, it MUST be
   interpreted through human means.

      <xs:element name="CertStatus" type="tns:CertStatusType"/>
      <xs:simpleType name="CertStatusType">
         <xs:restriction base="xs:string">
            <xs:enumeration value="Rejected"/>
            <xs:enumeration value="Accepted"/>
         </xs:restriction>
      </xs:simpleType>
      <xs:element name="ReasonForRejection" type="xs:string"/>

4.
  Use Case Scenario

   This scenario illustrates how the CEM Request and CEM Response
   messages described in Section 2 and 3 can be used to exchange
   certificates. The scenario is only illustrative and any differences
   between it and the rules above should defer to the rules in Section 2
   and 3.

   Two trading partners, Alpha Arrows and Bravo Bows, have an
   established trading partner relationship using AS2. Alpha Arrows is
   using a single certificate, CertA, for both digital signatures and
   data encryption. Alpha Arrows wants to issue a new certificate,
   CertB, for digital signatures but keep CertA for data encryption.


Meadors, Moberg        Expires - September 2007              [Page 18]


Draft                       CEM for EDIINT                  March 2007



   Bravo Bows is using one certificate, Cert1, for digital signatures
   and another certificate, Cert2, for data encryption. Bravo Bows wants
   to introduce a new certificate, Cert3, for digital signature and a
   new certificate, Cert4, for data encryption.

   1. Alpha Arrows sends a CEM Request to Bravo Bows containing only
   CertB. The CertUsage has a value of "digitalSignature". Bravo Bows
   immediately returns the MDN but must make an internal security
   decision before accepting CertB.

   2. While waiting for a CEM Response, Alpha Arrows continues to send
   AS2 messages to Bravo Bows which have been signed using CertA. The
   messages originating from Bravo Bows are encrypted using CertA.

   3. Eventually, Bravo Bows returns a CEM Response with the CertStatus
   of "Accepted" for CertB. Upon receipt, an MDN is returned which is
   signed using CertA. Bravo Bows MUST be able to accept the MDN if it
   has a digital signature from either CertA or CertB as Alpha Arrows
   may not be able to switch certificates simply upon receipt of the CEM
   Response message without parsing the XML payload. Also, Alpha Arrows
   may need to wait for CEM Responses from other trading partners before
   switching to the new CertB. However, as soon as possible, Alpha
   Arrows should use CertB exclusively for digital signatures.

   4. Bravo Bows sends a CEM Request to Alpha Arrows containing both
   Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are
   "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows
   returns an MDN immediately. Bravo Bows is now prepared to receive any
   inbound messages encrypted by either Cert2 or Cert4, but all its
   digital signatures are still done through Cert1.

   5. Eventually, Alpha Arrows returns a single CEM Response message. It
   contains two TrustResponse elements: one for Cert3 and another for
   Cert4. The CertStatus for Cert3 is "Rejected" with the
   ReasonForRejection field present and populated with the string
   "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted."
   Bravo Bows returns the MDN signed through Cert1.

   6. Immediately after this, an AS2 message is received from Alpha
   Arrows which is encrypted using Cert4, and Bravo Bows is able to
   decrypt the message successfully. Because Alpha Arrows rejected
   Cert3, Bravo Bows is only using Cert1 for digital signatures and
   returns the MDN signed with Cert1.

   7. After creating a new certificate, Cert5, which corrects the
   previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request.




Meadors, Moberg        Expires - September 2007              [Page 19]


Draft                       CEM for EDIINT                  March 2007


   8. Shortly after this, Alpha Arrows sends a CEM Response message for
   Cert5. It contains a CertStatus of "Accepted". This CEM Response
   message was encrypted using Cert4, but Bravo Bows was prepared for
   encryption from either Cert2 or Cert4. The message is processed and a
   good MDN is returned signed with Cert1. While, Bravo Bows can now
   sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows
   should use Cert5 exclusively as soon as possible.


5.
  Profile Exchange Messaging

   CEM provides the means to exchange certificates among trading
   partners. However, other profile information, such as URLs and
   preferred security settings, is needed to create a trading partner
   relationship. A future standard is needed to describe profile
   descriptions and how they will be exchanged. The format for this
   profile attachment is not defined in this specification but is
   planned for a future document. It will build upon the existing CEM
   protocol with profile information stored with XML data. Both
   certificate and profile description information will be placed into a
   multipart/related [RFC2387] body part entity. A possible format for a
   profile description message is as follows:

   Various EDIINT headers
   EDIINT–Features: profile-exchange
   Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company
   Disposition-Notification-Options: signed-receipt-protocol=optional,
     pkcs7-signature; signed-receipt-micalg=optional, sha1
   Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature"; boundary="--BOUNDARY1"

   ----BOUNDARY1
   Content-Type: multipart/related;
     start="<aayxdfl01012000@foo.com>";
     type="application/ediint-cert-exchange+xml";
     boundary="--BOUNDARY2"

   ----BOUNDARY2
   Content-Type: application/ediint-cert-exchange+xml
   Content-ID: <aayxdfl01012000@foo.com>

   [CEM XML data]
   ----BOUNDARY2
   [Profile information attachment]
   ----BOUNDARY2--
   ----BOUNDARY1

   Content-Type: application/pkcs7-signature



Meadors, Moberg        Expires - September 2007              [Page 20]


Draft                       CEM for EDIINT                  March 2007


   [Digital Signature]
   ----BOUNDARY1--


6.
  Implementation Considerations

   This section contains various points to explain practical
   implementation considerations.

   • If the EDIINT transport message carrying a CEM Request or CEM
   Response fails resulting in a negative MDN, the CEM message, its
   contents and instructions are to be ignored. The User Agent receiving
   the negative MDN is to consider the CEM message to be ignored and
   retransmit as needed.

   • While a single end–entity certificate can be only be used once in a
   single CEM Request message, the same certificate can be sent multiple
   times in multiple CEM Request messages. The requestId is used for
   matching the CEM Request and CEM Response messages.

   • Certificate usage is cumulative. Thus, if a User Agent receives a
   valid CEM Request message with Certificate A with certUsage set to
   digitalSignature and then a second valid CEM Request message with
   Certificate A with certUsage set to keyEncipherment, then the User
   Agent MUST configure the certificate to be used both for
   digitalSignature and keyEncipherment. As well, if at a later time a
   valid CEM Request message is received with Certificate A with
   certUsage set only to digitalSignature, Certificate A is still valid
   for keyEncipherment.


7.
  Future Considerations for CEM I–D
   This section contains ideas for consideration in future versions of
   CEM and addressed in the future. If deemed necessary, they will be
   added into the I–D else they will be removed. This section will be
   removed prior to RFC submission.

   •

8.
  Security Considerations

   Certificate exchange is safe for transmitting. However, implementers
   SHOULD verify the received certificate to determine if it is truly
   from the stated originator through out-of-band means or whenever the
   request is not signed.






Meadors, Moberg        Expires - September 2007              [Page 21]


Draft                       CEM for EDIINT                  March 2007


9.
  IANA Considerations

   MIME Media type name: Application

   MIME subtype name: EDIINT-cert-exchange+xml

   Required parameters: None

   Optional parameters: This parameter has identical semantics to the
     charset parameter of the "application/xml" media type as specified
     in [RFC3023].

   Encoding considerations: Identical to those of "application/xml" as
     described in [RFC3023], section 3.2.

   Security considerations: See section 6.

   Interoperability Considerations: See section 2.2

   Published specification: This document.

   Applications which use this media type: EDIINT applications, such as
     AS1, AS2 and AS3 implementations.

   Additional Information: None

   Intended Usage: Common

   Author/Change controller: See Author's section of this document.

10.
   References
10.1
     Normative References

   [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data
      Interchange over the Internet using SMTP", T. Harding, R.
      Drummond, C. Shih, 2002.

   [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data
      Interchange over the Internet using HTTP", D. Moberg, R.
      Drummond, 2005.

   [AS3] draft-ietf-ediint-as3-05.txt "MIME-based Secure Peer-to-Peer
      Business Data Interchange over the Internet using FTP", T.
      Harding, R. Scott, 2003.

   [EDIINT FEATURE] draft-meadors-ediint-feature-header-01.txt "Feature
      Header for EDI-INT", K. Meadors, 2006.




Meadors, Moberg        Expires - September 2007              [Page 22]


Draft                       CEM for EDIINT                  March 2007


   [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement
      Levels", S.Bradner, March 1997.

   [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,
      January 1999.

   [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8
      String Representation of Distinguished Names", M. Wahl, S. Kille
      and T. Howes, Decemeber 1997.

   [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.
      Levinson, August 1998.

   [RFC2828] RFC2828 "Internet Security Glossary", R. Shirley, May 2000.

   [RFC3023] RFC3023 "XML Media Types", M. Murata, January 2001.

   [XML-DSIG] RFC3275 "XML-Signature Syntax and Processing", D.
      Eastlake, March 2002.

   [X.520] ITU-T Recommendation X.520: Information Technology - Open
      Systems Interconnection - The Directory: Selected Attribute
      Types, 1993.

   [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
      X.509 Public Key Infrastructure: Certificate and CRL Profile",
      RFC 3280, April 2002.

10.2
    Informative References

11.
   Acknowledgments

   The authors wish to extend gratitude to the ecGIF sub-committee
   within the GS1 organization from which this effort began. Many have
   contributed to the development of this specification, but some
   deserve special recognition. John Duker who chaired the sub-committee
   and provided valuable editing. John Koehring with his work on the
   reference ID and shared important insights on implementation. Aaron
   Gomez in the coordinating of vendors testing CEM. Richard Bigelow who
   greatly assisted development of the ideas presented, and Debra Petta
   for her review and comments.

Author's Addresses

   Kyle Meadors
   Drummond Group Inc.
   4700 Bryant Irvin Court, Suite 303
   Fort Worth, TX  76107 USA
   Email: kyle@drummondgroup.com


Meadors, Moberg        Expires - September 2007              [Page 23]


Draft                       CEM for EDIINT                  March 2007



   Dale Moberg
   Axway, Inc.
   8388 E. Hartford Drive, Suite 100
   Scottsdale, AZ  85255 USA
   Email: dmoberg@us.axway.com


Copyright Notice
   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Appendix

   A.1 EDIINT Certificate Exchange XML Schema

   <?xml version="1.0"?>
   <xs:schema
   xmlns:tns="urn:ietf:params:xml:ns:ediintcertificateexchange"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   targetNamespace="urn:ietf:params:xml:ns:ediintcertificateexchange"
   elementFormDefault="qualified">
      <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
   schemaLocation="xmldsig-core-schema.xsd"/>
      <xs:element name="EDIINTCertificateExchangeRequest">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustRequest"
   type="tns:TrustRequestType" maxOccurs="unbounded"/>
               <xs:element ref="tns:Extensions" minOccurs="0"
   maxOccurs="1"/>
            </xs:sequence>
            <xs:attribute name="requestId" type="tns:RequestIdType"
             use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>


Meadors, Moberg        Expires - September 2007              [Page 24]


Draft                       CEM for EDIINT                  March 2007


      </xs:element>
      <xs:element name="EDIINTCertificateExchangeResponse">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustResponse"
   type="tns:TrustResponseType" maxOccurs="unbounded"/>
               <xs:element ref="tns:Extensions" minOccurs="0"
   maxOccurs="1"/>
            </xs:sequence>
            <xs:attribute name="requestId" type="tns:RequestIdType"
             use="optional"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>
      </xs:element>
      <xs:element name="TradingPartnerInfo">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="Name">
                  <xs:complexType>
                     <xs:simpleContent>
                        <xs:extension base="xs:string">
                           <xs:attribute name="qualifier"
   type="xs:string" use="optional"/>
                        </xs:extension>
                     </xs:simpleContent>
                  </xs:complexType>
               </xs:element>
               <xs:element name="MessageOriginated" type="xs:dateTime"/>
               <xs:any namespace="##any" processContents="lax"
   minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:complexType>
      </xs:element>
      <xs:simpleType name=”RequestIdType”>
         <xs:restriction base=”xs:string”>
            <xs:minLength value=”1”/>
            <xs:maxLength value=”255”/>
         </xs:restriction>
      </xs:simpleType>
      <xs:element name="CertUsage" type="tns:CertUsageType"/>
      <xs:simpleType name="CertUsageType">
         <xs:restriction base="xs:string">
            <xs:enumeration value="tlsClient"/>
            <xs:enumeration value="tlsServer"/>
            <xs:enumeration value="keyEncipherment"/>
            <xs:enumeration value="digitalSignature"/>
         </xs:restriction>


Meadors, Moberg        Expires - September 2007              [Page 25]


Draft                       CEM for EDIINT                  March 2007


      </xs:simpleType>
      <xs:element name="CertStatus" type="tns:CertStatusType"/>
      <xs:simpleType name="CertStatusType">
         <xs:restriction base="xs:string">
            <xs:enumeration value="Rejected"/>
            <xs:enumeration value="Accepted"/>
         </xs:restriction>
      </xs:simpleType>
      <xs:element name="ReasonForRejection" type="xs:string"/>
      <xs:element name="RespondByDate" type="xs:dateTime"/>
      <xs:element name="ResponseURL" type="xs:anyURI"/>
      <xs:complexType name="EndEntityType">
         <xs:sequence>
            <xs:element name="CertificateIdentifier"
   type="ds:X509IssuerSerialType"/>
            <xs:element name="CertificateContentID" type="xs:string"/>
            <xs:any namespace="##any" processContents="lax"
   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>
      <xs:complexType name="TrustRequestType">
         <xs:sequence>
            <xs:element ref="tns:CertUsage" maxOccurs="unbounded"/>
            <xs:element ref="tns:RespondByDate" minOccurs=”0”/>
            <xs:element ref="tns:ResponseURL"/>
            <xs:element name="EndEntity" type="tns:EndEntityType"/>
            <xs:any namespace="##any" processContents="lax"
   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>
      <xs:complexType name="TrustResponseType">
         <xs:sequence>
            <xs:element ref="tns:CertStatus"/>
            <xs:element ref="tns:ReasonForRejection" minOccurs="0"/>
            <xs:element name="CertificateReference"
   type="ds:X509IssuerSerialType"/>
            <xs:any namespace="##any" processContents="lax"
   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:complexType>
      <xs:element name="Extensions">
         <xs:complexType>
            <xs:sequence>
               <xs:any namespace="##any" processContents="lax"
   minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>


Meadors, Moberg        Expires - September 2007              [Page 26]


Draft                       CEM for EDIINT                  March 2007


         </xs:complexType>
      </xs:element>
   </xs:schema>

   A.2 Example of EDIINT Certificate Exchange Request XML

   <?xml version="1.0" standalone="yes"?>
   <EDIINTCertificateExchangeRequest
   xmlns="urn:ietf:params:xml:ns:ediintcertificateexchange"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   requestId=”01170702153479-msgAlphaBravo”>
      <TradingPartnerInfo>
         <Name qualifier="AS2">DGI_Test_CEM</Name>
         <MessageOriginated>
            2005-08-30T00:30:00-05:00</MessageOriginated>
      </TradingPartnerInfo>
      <TrustRequest>
         <CertUsage>keyEncipherment</CertUsage>
         <CertUsage>digitalSignature</CertUsage>
         <RespondByDate>2005-09-30T12:00:00-05:00</RespondByDate>
         <ResponseURL>http://10.1.1.1/as2</ResponseURL>
         <EndEntity>
            <CertificateIdentifier>
               <ds:X509IssuerName>CN=Cleo-
   SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft.
   Worth,S=Texas,C=US</ds:X509IssuerName>
      <ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>
            </CertificateIdentifier>
            <CertificateContentID>
            SignEncCert-Example_vs02@example.org</CertificateContentID>
         </EndEntity>
      </TrustRequest>
      <TrustRequest>
         <CertUsage>tlsServer</CertUsage>
         <RespondByDate>2005-09-30T12:00:00-05:00</RespondByDate>
         <ResponseURL>http://10.1.1.1/as2</ResponseURL>
         <EndEntity>
            <CertificateIdentifier>
               <ds:X509IssuerName>CN=VeriSign Class 1 CA Individual
   Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA
   Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\,
   Inc.</ds:X509IssuerName>
      <ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X50
   9SerialNumber>
            </CertificateIdentifier>
            <CertificateContentID>
               SSLCert-Example_vs02@example.org</CertificateContentID>
         </EndEntity>


Meadors, Moberg        Expires - September 2007              [Page 27]


Draft                       CEM for EDIINT                  March 2007


      </TrustRequest>
   </EDIINTCertificateExchangeRequest>

   A.3 Example of EDIINT Certificate Exchange Response XML

   <?xml version="1.0"?>
   <EDIINTCertificateExchangeResponse
   xmlns="urn:ietf:params:xml:ns:ediintcertificateexchange"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   requestId=”01170702153479-msgAlphaBravo”>
      <TradingPartnerInfo>
         <Name qualifier="AS2">DGI_Test_CEM_Trading_Partner</Name>
         <MessageOriginated>
         2005-08-31T00:21:00-05:00</MessageOriginated>
      </TradingPartnerInfo>
      <TrustResponse>
         <CertStatus>Accepted</CertStatus>
         <CertificateReference>
            <ds:X509IssuerName>CN=Cleo-
   SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft.
   Worth,S=Texas,C=US</ds:X509IssuerName>
      <ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>
         </CertificateReference>
      </TrustResponse>
      <TrustResponse>
         <CertStatus>Accepted</CertStatus>
         <CertificateReference>
            <ds:X509IssuerName>CN=VeriSign Class 1 CA Individual
   Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA
   Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\,
   Inc.</ds:X509IssuerName>
      <ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X50
   9SerialNumber>
         </CertificateReference>
      </TrustResponse>
   </EDIINTCertificateExchangeResponse>

Changes from Previous Versions

   B.1 Updates from Version 00

     . Updated security requirements in section 2.1, specifically in
        regards to digital signatures.
     . The XML element responseURL is now required. Modified section
        3.1 and example messages in appendix accordingly.
     . Certificates are exchanged within a full P7C cert chain. Section
        2.3 reflects this.



Meadors, Moberg        Expires - September 2007              [Page 28]


Draft                       CEM for EDIINT                  March 2007


     . The XML element TrustChain is not longer necessary since the
        entire cert chain is stored. Removed references in schema and
        document.
     . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be
        sent and that if this occurs, the action of the CEM Request
        initiator is not defined.
     . Updated the examples in Appendix B to reflect the current usage.

   B.2 Updates from Version 01

     . Added information for handling different scenarios with CEM
        Response message.
     . Rewrote use case scenarios.
     . Added the EDIINT Features header information.

   B.3 Updates from Version 02

      . Modified use of SSL certificates to match real–world needs.
      . Modified schema in changing namespace value and removed schema
        location.
      . Added statement that CEM XML must be well–formed and valid to
        schema.
      . Modified Use Case to correct an error and improve clarity.
      . Added section 1.4 to describe CEM process.


   B.4 Updates from Version 03
      . None. Update done because vs03 expired.

   B.5 Updates from Version 04
      . Clarified requirement of using multipart/related for CEM
        Response.
      . Added sections on Implementation Considerations and Future
        Implementation.
      . Modified schema to allow future extensions.
      . Changed requirements on qualifier attribute in the Name
        element.
      . Changed functionality to allow error MDN to be returned when
        CEM XML can not be parsed.

   B.6 Updates from Version 05
      . Added requestId to CEM.
      . Removed normative reference to RFC 3821.








Meadors, Moberg        Expires - September 2007              [Page 29]