Draft CEM for EDIINT August 2005 Private K. Meadors Internet-Draft Drummond Group Inc. Document: draft-meadors-certificate-exchange- D. Moberg 02.txt Cyclone Commerce Expires: February 2005 August 2005 Certificate Exchange Messaging for EDIINT draft-meadors-certificate-exchange-02.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 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 . Requests to subscribe to the mailing list should be addressed to . 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 - February 2006 [Page 1] Draft CEM for EDIINT August 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........................4 1.3 Certificate Lifecycle......................................5 2. Message Processing.............................................6 2.1 Message Structure..........................................6 2.2 Version Header.............................................7 2.3 Certificate Exchanging.....................................7 2.4 Certificate Implementation.................................8 2.5 CEM Response...............................................9 3. XML Schema Description........................................10 3.1 EDIINTCertificateExchangeRequest element..................10 3.2 EDIINTCertificateExchangeResponse element.................13 Meadors, Moberg Expires - February 2006 [Page 2] Draft CEM for EDIINT August 2005 4. Use Case Scenario.............................................14 5. Profile Exchange Messaging....................................16 6. Security Considerations.......................................16 7. IANA Considerations...........................................17 8. References....................................................17 8.1 Normative References......................................17 8.2 Informative References....................................18 9. Acknowledgments...............................................18 Author's Addresses...............................................18 Appendix.........................................................19 A.1 EDIINT Certificate Exchange XML Schema....................19 A.2 Example of EDIINT Certificate Exchange Request XML........21 A.3 Example of EDIINT Certificate Exchange Response XML.......22 Changes from Previous Versions...................................23 B.1 Updates from Version 00...................................23 B.2 Updates from Version 01...................................23 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 Meadors, Moberg Expires - February 2006 [Page 3] Draft CEM for EDIINT August 2005 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 [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 Meadors, Moberg Expires - February 2006 [Page 4] Draft CEM for EDIINT August 2005 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. 5. Revoked - A certificate which has been explicitly revoked by its owner or the certificate authority. Meadors, Moberg Expires - February 2006 [Page 5] Draft CEM for EDIINT August 2005 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 certifications and the XML data describing their intended use are stored within a multipart-related MIME envelope [RFC2387]. The certificates are stored in certificate chains through 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. Meadors, Moberg Expires - February 2006 [Page 6] Draft CEM for EDIINT August 2005 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. The MDN response verifies the transport delivery but is not equivalent to the CEM Response message. 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" 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. 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 included 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. Meadors, Moberg Expires - February 2006 [Page 7] Draft CEM for EDIINT August 2005 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 MUST return the MDN before parsing and interpreting the CEM XML data or certificate chains. The returned MDN only provides information on the veracity of the transport message and not the acceptance of the certificate(s) being exchanged. 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 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 Meadors, Moberg Expires - February 2006 [Page 8] Draft CEM for EDIINT August 2005 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, 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 contains a TrustResponse XML element. TrustResponse provides information needed to match the end-entity certificate sent in an earlier CEMRequest 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. Meadors, Moberg Expires - February 2006 [Page 9] Draft CEM for EDIINT August 2005 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 can 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 for different certificates but MUST NOT contain two or more TrustResponses for the same certificate. If a second TrustResponses is received in different message matching the same certificate as that of an earlier TrustRespnse but the CertStatus have 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. 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 - February 2006 [Page 10] Draft CEM for EDIINT August 2005 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. For example, a message originating from the US Eastern Standard timezone would use 2005-03-01T14:05:00-05:00. 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. Meadors, Moberg Expires - February 2006 [Page 11] Draft CEM for EDIINT August 2005 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]. 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 describe 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. 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, Meadors, Moberg Expires - February 2006 [Page 12] Draft CEM for EDIINT August 2005 CertUsage only has a potential number of four occurrences due to the limit of the enumerated values. 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. 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. 3.2 EDIINTCertificateExchangeResponse element 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. Meadors, Moberg Expires - February 2006 [Page 13] Draft CEM for EDIINT August 2005 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. 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. Meadors, Moberg Expires - February 2006 [Page 14] Draft CEM for EDIINT August 2005 Two trading partners, TPA and TPB, have an established trading partner relationship using AS2. TPA is using a single certificate, CertA, for both digital signatures and data encryption. TPA wants to issue a new certificate, CertB, for digital signatures but keep CertA for data encryption. TPB is using one certificate, Cert1, for digital signatures and another certificate, Cert2, for data encryption. TPB wants to introduce a new certificate, Cert3, for digital signature and a new certificate, Cert4, for data encryption. TPA sends a CEM Request to TPB containing only CertB. The CertUsage has a value of "digitalSignature". TPB immediately returns the MDN but must make an internal security decision before accepting CertB. In the mean time, TPA continues to send AS2 messages to TPB which have been signed using CertA. The messages originating from TPB are encrypted using CertA. After some point, TPB returns a CEMResponse with the CertStatus of "Accepted" for CertB. Upon receipt, an MDN is returned which is signed using CertA. TPB must be able to accept the MDN if it has a digital signature from either CertA or CertB as TPA may not be able to switch certificates simply upon receipt of the CEM Response message without parsing the XML payload. Also, TPA may need to wait for other trading partners to accept the new CertB. TPB should be prepared to accept digital signatures either from CertA or CertB. However, soon as possible, TPA should being using CertB exclusively for digital signatures. TPB sends a CEM Request to TPA containing both Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are "digitalSignature" and "keyEncipherment", respectively. TPA returns an MDN immediately. TPB is prepared to receive any encrypted inbound messages by either Cert2 or Cert4. All its digital signatures are done through Cert1. After some time, TPA returns a single CEM Response message. It contains a TrustResponse element for Cert3 and a TrustResponse element 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." TPB returns the MDN signed through Cert1. Immediately after this, an AS2 message is received from TPA which is encrypted using Cert2. TPB returns the MDN signed with Cert3 and is only using Cert3 for digital signatures. After creating a new certificate, Cert5, which corrects the previous keyUsage problem, TPB sends Cert5 in a CEM Request. Shortly after this, TPA sends a CEM Response message for Cert5. It contains a CertStatus of "Accepted". This CEM Response message was encrypted using Cert4, but TPB was prepared for encryption from either Cert2 or Cert4. The message is processed and a good MDN is returned. Meadors, Moberg Expires - February 2006 [Page 15] Draft CEM for EDIINT August 2005 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=ö"; type=öapplication/ediint-cert-exchange+xmlö; boundary="--BOUNDARY2" ----BOUNDARY2 Content-Type: application/ediint-cert-exchange+xml Content-ID: [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 Meadors, Moberg Expires - February 2006 [Page 16] Draft CEM for EDIINT August 2005 from the stated originator through out-of-band means 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. 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] 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-02.txt ôMIME-based Secure Peer-to-Peer Business Data Interchange over the Internet using FTPö, T. Harding, R. Scott, 2003. Meadors, Moberg Expires - February 2006 [Page 17] Draft CEM for EDIINT August 2005 [EDIINT FEATURE] draft-meadors-ediint-features-header-00.txt ôEDI-INT Features Headerö, K. Meadors, 2005. [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. [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. [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 GS1 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 and John Koehring with his insights on implementation and Debra Petta for her review and comments. Author's Addresses Meadors, Moberg Expires - February 2006 [Page 18] Draft CEM for EDIINT August 2005 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 (2005). 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 Meadors, Moberg Expires - February 2006 [Page 19] Draft CEM for EDIINT August 2005 Meadors, Moberg Expires - February 2006 [Page 20] Draft CEM for EDIINT August 2005 A.2 Example of EDIINT Certificate Exchange Request XML DGI_Test_CEM 2005-08-30T00:30:00-05:00 keyEncipherment digitalSignature 2005-09-30T12:00:00-05:00 http://10.1.1.1/as2 CN=Cleo- SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. Worth,S=Texas,C=US 9659684611094873474886 SignEncCert-Example_vs02@example.org Meadors, Moberg Expires - February 2006 [Page 21] Draft CEM for EDIINT August 2005 tlsServer 2005-09-30T12:00:00-05:00 http://10.1.1.1/as2 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. 2673611014597817669550861744279966682 SSLCert-Example_vs02@example.org A.3 Example of EDIINT Certificate Exchange Response XML DGI_Test_CEM_Trading_Partner 2005-08-31T00:21:00-05:00 Accepted CN=Cleo- SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. Worth,S=Texas,C=US 9659684611094873474886 Accepted 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. Meadors, Moberg Expires - February 2006 [Page 22] Draft CEM for EDIINT August 2005 2673611014597817669550861744279966682 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. . 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. Meadors, Moberg Expires - February 2006 [Page 23]