Individual Submission                                     K. Meadors
   Internet-Draft                                   Drummond Group Inc.
   Document: draft-meadors-certificate-exchange-              D. Moberg
   00.txt                                              Cyclone Commerce
   Expires: July 2005                                      January 2005



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

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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


Meadors, Moberg          Expires - July 2005                 [Page 1]


Draft                       CEM for EDIINT               January 2005


   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
   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........................3
      1.3 Certificate Lifecycle......................................5
   2. Message Processing.............................................5
      2.1 Message Structure..........................................5
      2.2 Version Header.............................................7
      2.3 Certificate Exchanging.....................................7
      2.4 Certificate Implementation.................................8
      2.5 CEM Response...............................................9
   3. XML Schema Description.........................................9
      3.1 EDIINTCertificateExchangeRequest element...................9
      3.2 EDIINTCertificateExchangeResponse element.................12


Meadors, Moberg          Expires - July 2005                 [Page 2]


Draft                       CEM for EDIINT               January 2005


   4. Use Case Scenarios............................................14
      4.1 Maintenance Configuration Processing......................14
      4.2 Initial Configuration Processing..........................15
   5. Profile Exchange Messaging....................................17
   6. Security Considerations.......................................18
   7. IANA Considerations...........................................18
   8. References....................................................19
      8.1 Normative References......................................19
      8.2 Informative References....................................20
   9. Acknowledgments...............................................20
   Author's Addresses...............................................20
   Appendix.........................................................20


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. EDIINT 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
   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



Meadors, Moberg          Expires - July 2005                 [Page 3]


Draft                       CEM for EDIINT               January 2005


   [RFC2818] 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 [RFC2818] 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.

   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


Meadors, Moberg          Expires - July 2005                 [Page 4]


Draft                       CEM for EDIINT               January 2005


   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.
   5. Revoked û A certificate which has been explicitly revoked by its
      owner or the certificate authority.

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


Meadors, Moberg          Expires - July 2005                 [Page 5]


Draft                       CEM for EDIINT               January 2005


   acceptance. Both digital certifications and the XML data describing
   their intended use are stored within a multipart-related MIME
   envelope [RFC2387]. The certificates are stored in SMIME, certs-only
   MIME envelope [3851], and processing information is XML data which is
   identified through the MIME content-type of application/ediint-cert-
   exchange+xml. The format for CEM messages 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.

   Both the CEM Request and CEM Response message SHOULD be signed. If it
   is desired to enable automatic exchange based on a previous trust
   relationship, then both the CEM Request and CEM Response message MUST
   be signed. Also, CEM messages SHOULD request a MDN and SHOULD request
   a signed MDN. Extra security such as applying data encryption is
   OPTIONAL. The MDN can be either synchronous or asynchronous. The MDN
   response verifies the transport delivery but is not equivalent to the



Meadors, Moberg          Expires - July 2005                 [Page 6]


Draft                       CEM for EDIINT               January 2005


   CEM Response message. All necessary headers MUST be applied to the
   message per the underlying transport standard.

2.2    Version Header

   Before a CEM Request message is generated, the initiator MUST
   determine if the recipient can accept the CEM Request message. For
   both AS2 and AS3, the version header value of 1.2 or greater (e.g.
   1.3) indicates the implementation can both initiate and receive CEM
   message exchanges. AS2 and AS3 implementers of CEM MUST utilize the
   proper version header in all of their messages, both CEM messages and
   normal document transport messages. Since there is no AS1 version
   header, trading partners using AS1 MUST decide within the trading
   partner agreement whether to utilize CEM.

   For CEM Request messages of initial trading partner configurations,
   the initiator MUST decide within the trading partner agreement if the
   recipient can accept the CEM Request.

2.3    Certificate Exchanging

   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.

   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 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 MUST return the MDN before parsing and interpreting the CEM
   XML data. The returned MDN only provides information on the veracity
   of the transport message and not the acceptance of the certificate(s)
   being exchanged.




Meadors, Moberg          Expires - July 2005                 [Page 7]


Draft                       CEM for EDIINT               January 2005


2.4    Certificate Implementation

   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 or TLS/SSL
   server authentication, 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 client authentication, the initiator MUST NOT use the
   certificate until the recipient trading partner generates a CEM
   Response accepting the certificate or the start of 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


Meadors, Moberg          Expires - July 2005                 [Page 8]


Draft                       CEM for EDIINT               January 2005


   the certificate has been accepted. For example, if Certificate A is
   currently Accepted as the encryption certificate for a user agent,
   any CEM Request message containing Certificate A with the usage as
   the 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

   If a CEM Request is received, the recipient MUST respond with a CEM
   Response message indicating if the certificate is Accepted or
   Rejected. 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
   responses for multiple certificates in one or more CEM Response
   messages. The recipient MUST NOT generate more than one CEM Response
   for a given end-entity certificate. CEM Response are NOT sent for any
   certificates other than end-entity certificates. Based on the CEM
   Response message, the initiator determines if the exchanged
   certificate may be used in future trading with the recipient partner.

3.   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. Please refer to the appendix for the actual
   schema document.

3.1    EDIINTCertificateExchangeRequest element

   EDIINTCertificateExchangeRequest contains two elements,
   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.



Meadors, Moberg          Expires - July 2005                 [Page 9]


Draft                       CEM for EDIINT               January 2005


      <xs:element name="EDIINTCertificateExchangeRequest">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustRequest"
                  type="tns:TrustRequestType"
                  maxOccurs="unbounded"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>

   TradingPartnerInfo identifies the entity that created the CEM message
   through the nested Name element. Both the optional qualifier
   attribute and the element value of Name are left open to the
   implementer, but some suggested choices are to list the EDI
   identification or the transport trading partner relationship, for
   example the qualifier of ôAS2ö and the value of the AS2 system
   identifier (AS2-From value). 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.

      <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:sequence>
         </xs:complexType>
      </xs:element>


   The TrustRequest element contains the EndEntity, TrustChain,
   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. TrustChain references any certificates necessary to
   complete the chain of trust for the end entity certificate. For
   example, if the end entity certificate being exchanged is self-signed


Meadors, Moberg          Expires - July 2005                [Page 10]


Draft                       CEM for EDIINT               January 2005


   then there would not be a TrustChain element. However, if the end
   entity certificate is issued by an intermediary certificate which is
   issued by a root CA certificate, both the intermediary certificate
   and the CA certificate would be referenced in the same
   CertificateContentID element within the same TrustChain element.

      <xs:complexType name="TrustRequestType">
         <xs:sequence>
            <xs:element ref="tns:CertUsage" maxOccurs="unbounded"/>
            <xs:element ref="tns:RespondByDate"/>
            <xs:element ref="tns:ResponseURL"/>
            <xs:element name="EndEntity" type="tns:EndEntityType"/>
            <xs:element name="TrustChain" type="tns:TrustChainType"
                        minOccurs=ö0ö/>
         </xs:sequence>
      </xs:complexType>

   EndEntity contains the nested elements of CertificateIdentifier and
   CertificateContentID, and TrustChain only contains
   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"/>
            <xs:element name="CertificateContentID" type="xs:string"/>
         </xs:sequence>

      <xs:complexType name="TrustChainType">
         <xs:sequence>
            <xs:element name="CertificateContentID" type="xs:string"/>
         </xs:sequence>
      </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
   can be described in any format, but it is RECOMMENDED to list each
   issuer attribute abbreviation [X.520] [PROFILE] followed by the equal
   sign (i.e. ô=ö), then separating each attribute listing by a single
   semi-colon (e.g. CN=The Common Name;O=Organization;à). Refer to the
   appendix and the sample CEM Request message for an example of the
   X509IssuerName.



Meadors, Moberg          Expires - July 2005                [Page 11]


Draft                       CEM for EDIINT               January 2005


         <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
   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 optional 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. If
   the element is absent, the CEM Response message is returned according
   to the URL stipulated in the trading partner relationship. The
   Response MUST use the same transport protocol (AS1, AS2, or AS3) as
   the Request. The Response URL MUST use this protocol.

      <xs:element name="ResponseURL" type="xs:anyURI"/>

3.2    EDIINTCertificateExchangeResponse element




Meadors, Moberg          Expires - July 2005                [Page 12]


Draft                       CEM for EDIINT               January 2005


   EDIINTCertificateExchangeResponse contains the two elements
   TradingPartnerInfo and TrustResponse. 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.

      <xs:element name="EDIINTCertificateExchangeResponse">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="tns:TradingPartnerInfo"/>
               <xs:element name="TrustResponse"
                   type="tns:TrustResponseType"
                   maxOccurs="unbounded"/>
            </xs:sequence>
         </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"/>
         </xs:sequence>
      </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.



Meadors, Moberg          Expires - July 2005                [Page 13]


Draft                       CEM for EDIINT               January 2005


      <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 Scenarios

   These scenarios illustrate how the request and response messages
   described in Section 2 and 3 can be used to exchange certificates.
   The requirements of this standard are in Section 2 and 3; this
   section is only illustrative.

4.1    Maintenance Configuration Processing

   This use case assumes an established relationship with currently
   working certificates. Examples of this use case include, but are not
   limited to a certificate with an expiration date approaching.  If the
   current certificate is used to sign the Certificate Exchange
   messages, this signature can be used to establish a level of trust in
   the transaction. For this example, the AS2 transport protocol is
   used.

   4.1.1.  Step 1

   Initiator creates an EDIINTCertificateExchangeRequest as described in
   Section 2. Message Processing and Section 3. XML Schema Description
   and sends it according to EDIINT-AS2 protocol.  A positive MDN
   received during this step indicates successful transmission of the
   message but does not imply successful action on the certificate.  In
   the case of an encryption certificate, the initiator MUST be
   immediately ready to receive documents encrypted with the new
   certificate.  In the case of a signing certificate, the initiator can
   begin signing documents with the new certificate at the RespondByDate
   or upon receipt of an EDIINTCertificateExchangeResponse from the
   partner indicating acceptance of the certificate. If an acceptance
   response is not received by the RespondByDate, the initiator may or
   may not begin signing with the new certificate, depending on the
   implementationÆs capabilities and the policies of the initiator.

   4.1.2. Step 2

   Receiver validates the EDIINTCertificateExchangeRequest message at
   the AS2 level and returns a correct MDN.  If the message is a proper
   AS2 document, the receiver MUST automatically accept or reject the
   new certificate(s) or require manual intervention. If the certificate


Meadors, Moberg          Expires - July 2005                [Page 14]


Draft                       CEM for EDIINT               January 2005


   is automatically accepted or rejected, an
   EDIINTCertificateExchangeResponse MUST be generated and returned to
   the initiator.  Since the trading relationship could be hindered if
   action is not taken prior to the RespondByDate, manual intervention
   MUST be done before that date. When the manual intervention
   determines to accept or reject the new certificate, an
   EDIINTCertificateExchangeResponse MUST be generated and returned to
   the initiator. Both automatic and manual
   EDIINTCertificateExchangeResponses MUST be formatted according to
   Section 2. Message Processing and Section 3. XML Schema Description
   and sent according to EDIINT-AS2 protocol.  A positive MDN received
   for the response message indicates successful transmission of the
   response message.

   After the receiver accepts the new certificate and returns an
   acceptance response, the receiver encrypts all messages to the
   initiator with the new encryption certificate.  The receiver
   continues to accept messages from the initiator that are signed with
   the old signing certificate, and also accepts messages signed with
   the new signing certificate.  The initiator may start signing with
   the new certificate when it receives the acceptance response, or when
   it receives acceptance responses from all its partners, or after the
   RespondByDate, or when the old signing certificate expires.

   4.1.3.  Step 3

   After the exchange is complete, some cleanup may be desirable,
   including retiring or archiving the old certificates.  This step is
   considered an implementation detail that is left purely to the
   vendors and users.

4.2    Initial Configuration Processing

   This use case assumes all necessary elements of an EDIINT
   relationship exist outside of the certificates, including an
   understanding of the partnerÆs ability to support a CEM.
   Establishing these elements may be accomplished via an automated
   exchange, a manual process, or any other method desirable.  No
   methods of exchanging the additional information are described in
   this specification.  Examples of this use case include, but are not
   limited to the first exchange of a certificate, or recovery from an
   expired or compromised certificate.  This case assumes no signing
   certificate has been established, precluding a signature being used
   to establish a level of trust.  Therefore, extra precautions may be
   appropriate in this use case.  There are additional use cases
   possible where some certificates are already established.  It is not
   practical to cover every case here, but this case and the maintenance
   case should give sufficient guidance.



Meadors, Moberg          Expires - July 2005                [Page 15]


Draft                       CEM for EDIINT               January 2005


   4.2.1.  Step 1

   Initiator creates an EDIINTCertificateExchangeRequest as described in
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator
   sends it according to EDIINT-AS2 protocol.  Using a digital signature
   on the AS2 message is optional, as the receiver will not be able to
   verify until after accepting the signature certificate.  If the
   receiver supports this use case, they MUST accept this message
   regardless of the presence of a signature.  Unless the initiator
   possesses the receiverÆs encryption certificate, encryption MUST NOT
   be used.  Unless the initiator possesses the receiverÆs signature
   certificate, they SHOULD NOT request a signed MDN.  If the MDN is not
   signed, there is no legal proof the receiver received the message.
   In addition, a positive MDN received during this step gives some
   indication of successful transmission of the message, but does not
   imply successful action on the certificate.  In the case of an
   encryption certificate, the initiator MUST be immediately ready to
   receive documents encrypted with the new certificate.  In the case of
   a signing certificate, the initiator can begin signing documents with
   the new certificate at the RespondByDate or upon receipt of an
   EDIINTCertificateExchangeResponse from the partner indicating they
   are ready. If an acceptance response is not received by the
   RespondByDate, the initiator may or may not begin signing with the
   new certificate, depending on the implementationÆs capabilities and
   the policies of the initiator.

   4.2.2.   Step 2

   Receiver validates the EDIINTCertificateExchangeRequest message at
   the AS2 level and returns an MDN according to the EDIINT-AS2
   protocol.  If the message is a proper AS2 document, the receiver MUST
   automatically accept or reject the new certificate(s), or require
   manual intervention.  Caution should be used in automatically
   accepting the certificate, as it may be impossible to verify the
   sender is authentic.  If the certificate is automatically accepted or
   rejected, an EDIINTCertificateExchangeResponse MUST be generated and
   returned to the initiator.  Since the trading relationship could be
   hindered if action is not taken prior to the RespondByDate, manual
   intervention MUST be done before that date. When the manual
   intervention determines to accept or reject the certificate, an
   EDIINTCertificateExchangeResponse MUST be generated and returned to
   the initiator.

   In both the automatic and manual case, the
   EDIINTCertificateExchangeResponses MUST be formatted according to
   Section 2. Message Processing and Section 3. XML Schema Description
   and sent according to EDIINT-AS2 protocol.  If the original CEM
   included the encryption certificate, or if the receiver has the
   initiator encryption certificate on file, it may be used to encrypt


Meadors, Moberg          Expires - July 2005                [Page 16]


Draft                       CEM for EDIINT               January 2005


   the AS2 message including the EDIINTCertificateExchangeResponse.
   Otherwise, it may be necessary to send this
   EDIINTCertificateExchangeResponse unencrypted.  The message may be
   signed, but it is possible the initiator will have no way to verify
   the signature.  The initiator MUST accept this response, regardless
   of if it is signed.  A positive MDN received for the response message
   indicates successful transmission of the response message.

   After the receiver accepts the certificate and returns an acceptance
   response, the receiver may encrypt messages to the initiator with the
   encryption certificate.  The receiver begins to accept messages from
   the initiator that are signed with the signing certificate.  The
   initiator may start signing with the certificate when it receives the
   acceptance response, or when it receives acceptance responses from
   all its partners, or after the RespondByDate.

   4.2.3.   Step 3

   After the exchange is complete, additional certificates may need to
   be exchanged before a complete trading relationship can be
   successful.   This step is considered an implementation detail that
   is left purely to the vendors and users.


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
   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ö;


Meadors, Moberg          Expires - July 2005                [Page 17]


Draft                       CEM for EDIINT               January 2005


     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

   [Digital Signature]
   ----BOUNDARY1--


6.   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 for the initial
   use case of 4.2 or whenever the request is not signed.


7.   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.


Meadors, Moberg          Expires - July 2005                [Page 18]


Draft                       CEM for EDIINT               January 2005



   Additional Information: None

   Intended Usage: Common

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

8.   References
8.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] draft-ietf-ediint-as2-15.txt ôMIME-based Secure Peer-to-Peer
      Business Data Interchange over the Internet using HTTPö, D.
      Moberg, R. Drummond, 2004.

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

   [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.

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

   [RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000.

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

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

   [3821] RFC3821 ôS/MIME Version 3.1 Message Specificationö, B.
      Ramsdell, July 2004.

   [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.





Meadors, Moberg          Expires - July 2005                [Page 19]


Draft                       CEM for EDIINT               January 2005


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

8.2    Informative References

9.   Acknowledgments

   The authors wish to extend gratitude to the ecGIF sub-committee
   within the EAN.UCC organization from which this effort began. Of
   special note is John Duker who chaired the sub-committee and provided
   valuable editing, Richard Bigelow who greatly assisted development of
   the ideas presented, John Koehring with his insights on
   implementation and James Zwyer for his contribution to the use case
   scenarios.

Author's Addresses

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

   Dale Moberg
   Cyclone Commerce
   8388 E. Hartford Drive, Suite 100
   Scottsdale, AZ  85255 USA
   Email: dmoberg@cyclonecommerce.com


Copyright Notice
   Copyright (C) The Internet Society 2004.  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 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" encoding="UTF-8"?>


Meadors, Moberg          Expires - July 2005                [Page 20]


Draft                       CEM for EDIINT               January 2005


   <!--W3C Schema generated by XMLSPY v2004 rel. 3 U
   (http://www.xmlspy.com)-->
   <xs:schema
   targetNamespace="http://www.ietf.org/schemas/EDIINTCertificateExchang
   e.xsd"
   xmlns:tns="http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   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:sequence>
         </xs:complexType>
      </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:sequence>
         </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:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="CertUsage" type="tns:CertUsageType"/>
      <xs:simpleType name="CertUsageType">
         <xs:restriction base="xs:string">


Meadors, Moberg          Expires - July 2005                [Page 21]


Draft                       CEM for EDIINT               January 2005


            <xs:enumeration value="tlsClient"/>
            <xs:enumeration value="tlsServer"/>
            <xs:enumeration value="keyEncipherment"/>
            <xs:enumeration value="digitalSignature"/>
         </xs:restriction>
      </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:sequence>
      </xs:complexType>
      <xs:complexType name="TrustChainType">
         <xs:sequence>
            <xs:element name="CertificateContentID" type="xs:string"/>
         </xs:sequence>
      </xs:complexType>
      <xs:complexType name="TrustRequestType">
         <xs:sequence>
            <xs:element ref="tns:CertUsage" maxOccurs="unbounded"/>
            <xs:element ref="tns:RespondByDate"/>
            <xs:element ref="tns:ResponseURL"/>
            <xs:element name="EndEntity" type="tns:EndEntityType"/>
            <xs:element name="TrustChain" type="tns:TrustChainType"
                 minOccurs=ö0ö/>
         </xs:sequence>
      </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:sequence>
      </xs:complexType>
   </xs:schema>

   A.2 Example of EDIINT Certificate Exchange Request XML


Meadors, Moberg          Expires - July 2005                [Page 22]


Draft                       CEM for EDIINT               January 2005



   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <EDIINTCertificateExchangeRequest
   xmlns="http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.ietf.org/schemas/EDIINTCertificateExch
   ange.xsd EDIINTCertificateExchange.xsd">
      <TradingPartnerInfo>
         <Name qualifier="ZZ">Somewhere.com</Name>
         <MessageOriginated>2005-05-17T07:21:00-03:00
         </MessageOriginated>
         </TradingPartnerInfo>
      <TrustRequest>
         <CertUsage>digitalSignature</CertUsage>
         <RespondByDate>2005-05-20T07:21:00-03:00</RespondByDate>
         <ResponseURL>http://somewhere.com/someplace</ResponseURL>
         <EndEntity>
            <CertificateIdentifier>
               <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT;
                   L=New York; S=New York; C=US</ds:X509IssuerName>
               <ds:X509SerialNumber>123454321</ds:X509SerialNumber>
            </CertificateIdentifier>
            <CertificateContentID>0001@example.org
            </CertificateContentID>
         </EndEntity>
         <TrustChain>
               <!-- Intermediate cert -->
            <CertificateContentID>0002@example.org
            </CertificateContentID>
               <!-- Root cert  -->
            <CertificateContentID>0003@example.org
            </CertificateContentID>
         </TrustChain>
      </TrustRequest>
      <TrustRequest>
         <CertUsage>keyEncipherment</CertUsage>
         <RespondByDate>2005-05-20T07:21:00-03:00</RespondByDate>
         <ResponseURL>http://foo.com/path</ResponseURL>
         <EndEntity>
            <CertificateIdentifier>
                  <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT;
                     L=New York; S=New York; C=US</ds:X509IssuerName>
                  <ds:X509SerialNumber>987654321</ds:X509SerialNumber>
            </CertificateIdentifier>
              <!--Key exchange encryption cert -->
            <CertificateContentID>0004@example.org
            </CertificateContentID>
         </EndEntity>


Meadors, Moberg          Expires - July 2005                [Page 23]


Draft                       CEM for EDIINT               January 2005


         <TrustChain>
               <!-- Intermediate cert -->
            <CertificateContentID>0005@example.org
            </CertificateContentID>
               <!-- Root cert  -->
            <CertificateContentID>0006@example.org
            </CertificateContentID>
         </TrustChain>
      </TrustRequest>
   </EDIINTCertificateExchangeRequest>

   A.3 Example of EDIINT Certificate Exchange Response XML

   <?xml version="1.0" encoding="UTF-8"?>
   <EDIINTCertificateExchangeResponse
   xmlns="http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.ietf.org/schemas/EDIINTCertificateExch
   ange.xsd EDIINTCertificateExchange.xsd">
      <TrustResponse>
         <CertStatus>Rejected</CertStatus>
         <ReasonForRejection>Invalid KeyUsage
            extension</ReasonForRejection>
         <CertificateReference>
            <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT;
                 L=New York; S=New York; C=US</ds:X509IssuerName>
            <ds:X509SerialNumber>123454321</ds:X509SerialNumber>
         </CertificateReference>
      </TrustResponse>
      <TrustResponse>
         <CertStatus>Accepted</CertStatus>
         <CertificateReference>
            <ds:X509IssuerName>CN=US;O=Somewhere.com</ds:X509IssuerName>
            <ds:X509SerialNumber>987654321</ds:X509SerialNumber>
         </CertificateReference>
      </TrustResponse>
      </EDIINTCertificateExchangeResponse>













Meadors, Moberg          Expires - July 2005                [Page 24]