RE: Clean copy of CEM
"Kyle Meadors" <[email protected]> Tue, 12 Jul 2005 08:03:56 -0500
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------=_NextPart_000_0314_01C586B8.40E178F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0315_01C586B8.40E178F0" ------=_NextPart_001_0315_01C586B8.40E178F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Shan, Try this. I checked the IETF site and I see the odd characters there as well. Will fix this on the next revision. Kyle Meadors DGI _____ From: [email protected] [mailto:[email protected]] On Behalf Of Shan Harter Sent: Monday, July 11, 2005 6:53 PM To: [email protected] Subject: Clean copy of CEM The CEM protocol document contains some unknown characters. This was also downloaded from IETF and, it too contains these characters, such as an Most of them are apostrophes and other punctuation, but instead of me guessing, does anyone have a "clean" copy of the CEM draft? Thank you in advance... Regards, Shan Shan Harter VP of Project Services PEBS, Inc. Tempe Arizona, 85284 ph: 480-756-6777 Ext 205, fax: 480-756-9755, cell: 602-821-2951 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 7/11/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 7/11/2005 ------=_NextPart_001_0315_01C586B8.40E178F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dwindows-1250"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Message</title> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PostalCode"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"State"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City" = downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Shan,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Try = this.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>I checked the IETF site and I see = the odd characters there as well. Will fix this on the next = revision.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Kyle Meadors</span></font><font color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>DGI</span></font><o:p></o:p></p> </div> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> [email protected] [mailto:[email protected]] = <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Shan Harter<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 11, = 2005 6:53 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> = [email protected]<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Clean copy of = CEM</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>The CEM protocol document contains = some unknown characters. This was also downloaded from IETF and, it too = contains these characters, such as an </span></font><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Most of them are apostrophes and = other punctuation, but instead of me guessing, does anyone have a = "clean" copy of the CEM draft?</span></font><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size: 10.0pt'>Thank you in advance...</span></font><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Regards,</span></font><o:p></o:p></p> </div> <div> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Shan</span></font><o:p></o:p></p> <div> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><br> Shan Harter<br> VP of Project Services<br> PEBS, Inc.<br> <st1:place w:st=3D"on"><st1:City w:st=3D"on">Tempe</st1:City> <st1:State = w:st=3D"on">Arizona</st1:State>, <st1:PostalCode w:st=3D"on">85284</st1:PostalCode></st1:place><br> ph: 480-756-6777 Ext 205, <o:p></o:p></span></font></p> </div> <div> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>fax: 480-756-9755, cell: = 602-821-2951</span></font><o:p></o:p></p> </div> </div> </div> </body> <!--[object_id=3D#systrends.com#]--><P align=3Dcenter><FONT = face=3DTahoma size=3D2><FONT color=3D#0000ff></FONT></FONT> </P> </html> <BR> <P><FONT SIZE=3D2>--<BR> No virus found in this incoming message.<BR> Checked by AVG Anti-Virus.<BR> Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: = 7/11/2005<BR> </FONT> </P><BR> <P><FONT SIZE=3D2>--<BR> No virus found in this outgoing message.<BR> Checked by AVG Anti-Virus.<BR> Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: = 7/11/2005<BR> </FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial"> </FONT> </P> ------=_NextPart_001_0315_01C586B8.40E178F0-- ------=_NextPart_000_0314_01C586B8.40E178F0 Content-Type: text/plain; name="draft-meadors-certificate-exchange-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-meadors-certificate-exchange-01.txt" Draft CEM for EDIINT February 2005=20 =20 =20 Private Working Group K. Meadors=20 Internet-Draft Drummond Group Inc.=20 Document: draft-meadors-certificate-exchange- D. Moberg=20 01.txt Cyclone Commerce=20 Expires: August 2005 February 2005=20 =20 =20 =20 Certificate Exchange Messaging for EDIINT=20 draft-meadors-certificate-exchange-01.doc=20 =20 By submitting this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have been disclosed,=20 or will be disclosed, and any of which I become aware will be=20 disclosed, in accordance with RFC 3668.=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.html=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Any questions, comments, and reports of defects or ambiguities in=20 this specification may be sent to the mailing list for the EDIINT=20 working group of the IETF, using the address <[email protected]>.=20 Requests to subscribe to the mailing list should be addressed to=20 <[email protected]>.=20 =20 =20 Abstract=20 =20 The EDIINT AS1, AS2 and AS3 message formats do not currently contain=20 any neutral provisions for transporting and exchanging trading=20 partner profiles or digital certificates. EDIINT Certificate Exchange = Messaging provides the format and means to effectively exchange=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 1]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 certificates for use within trading partner relationships. The=20 messaging consists of two types of messages, Request and Response,=20 which allow trading partners to communicate certificates, their=20 intended usage and their acceptance through XML. Certificates can be=20 specified for use in digital signatures, data encryption or SSL/TLS=20 over HTTP (HTTPS). =20 =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119.=20 =20 Feedback Instructions=20 =20 NOTE TO RFC EDITOR: This section should be removed by the RFC editor = prior to publication.=20 =20 If you want to provide feedback on this draft, follow these=20 guidelines:=20 =20 -Send feedback via e-mail to [email protected], with=20 "Certificate Exchange" in the Subject field.=20 =20 -Be specific as to what section you are referring to, preferably=20 quoting the portion that needs modification, after which you state=20 your comments.=20 =20 -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=20 section in question.=20 =20 =20 Table of Contents=20 =20 1. Introduction...................................................3=20 1.1 Overview...................................................3=20 1.2 Terminology and Key Word Convention........................4=20 1.3 Certificate Lifecycle......................................5=20 2. Message Processing.............................................6=20 2.1 Message Structure..........................................6=20 2.2 Version Header.............................................7=20 2.3 Certificate Exchanging.....................................7=20 2.4 Certificate Implementation.................................8=20 2.5 CEM Response...............................................9=20 3. XML Schema Description........................................10=20 3.1 EDIINTCertificateExchangeRequest element..................10=20 3.2 EDIINTCertificateExchangeResponse element.................13=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 2]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 4. Use Case Scenarios............................................14=20 4.1 Maintenance Configuration Processing......................14=20 4.2 Initial Configuration Processing..........................15=20 5. Profile Exchange Messaging....................................17=20 6. Security Considerations.......................................18=20 7. IANA Considerations...........................................18=20 8. References....................................................19=20 8.1 Normative References......................................19=20 8.2 Informative References....................................20=20 9. Acknowledgments...............................................20=20 Author's Addresses...............................................20=20 Appendix.........................................................21=20 A.1 EDIINT Certificate Exchange XML Schema....................21=20 A.2 Example of EDIINT Certificate Exchange Request XML........23=20 A.3 Example of EDIINT Certificate Exchange Response XML.......24=20 Changes from Previous Versions...................................24=20 B.1 Updates from Version 00...................................25=20 =20 =20 1. =0D Introduction=20 =20 1.1 =0D Overview=20 =20 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in=20 numerous supply-chains was due in part to the security feature which=20 was provided. The security is not possible without the digital=20 certificates which enable it. To maintain the level of security=20 necessary to transmit business documentation, existing certificates=20 must occasionally be replaced and exchanged with newer ones. The=20 exchanging of digital certificates is unavoidable given how=20 certificates can expire or become compromised. Complicating this is=20 supply-chains which cannot afford to shutdown their business=20 transactions while trading partners laboriously upload new=20 certificates. Certificate exchange must be accomplished in a reliable = and seamless format so as not to affect ongoing business=20 transactions. =20 =20 This document describes how EDIINT products may exchange public-key=20 certificates. Since EDIINT is built upon the security provided by=20 public-private key pairs, it is vital that implementers are able to=20 update their trading partners with new certificates as their old=20 certificates expire, become outdated or insecure. EDIINT Certificate=20 Exchange Messaging (CEM) described here utilizes XML data to exchange = the certificate and provide information on its intended usage and=20 acceptance within the trading partner relationship. There are two=20 types of CEM messages, the CEM Request which presents the new=20 certificate to be introduced into the trading partner relationship=20 and the CEM Response which is the recipient=92s response to the CEM=20 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or = =20 =20 Meadors, Moberg Expires - August 2005 [Page 3]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 AS3 [AS3] message transports. However, it is possible to leverage CE=20 messaging through other transport standards besides EDIINT.=20 =20 1.2 =0D Terminology and Key Word Convention=20 =20 [RFC2818] provides a glossary of Internet security terms, and several = of their definitions are listed here verbatim. However, some=20 definitions required for this document were undefined by [RFC2818] or = rewritten to better explain their specific use within CEM. =20 =20 Certificate =96 A digital certificate contains the owner=92s (End=20 Entity=92s) name, the issuer=92s name, a serial number, expiration = date,=20 and a copy of the owner=92s Public Key. The Public Key is used for=20 Encrypting messages and Verifying Signatures (verifying a signature=20 is also called Authentication). =20 =20 Certificate Revocation List (CRL) =96 A data structure that = enumerates=20 digital certificates that have been invalidated by their issuer prior = to when they were scheduled to expire. [RFC2828]=20 =20 Certification Authority (CA) =96 An entity that issues digital=20 certificates (especially X.509 certificates) and vouches for the=20 binding between the data items in a certificate. [RFC2828]=20 =20 CA Certificate - A certificate issued by a trusted certification=20 authority. CA certificates are not used to encrypt data but to sign=20 other certificates. CA certificates are signed by themselves, but are = not considered self-signed certificates for the purpose of this=20 document.=20 =20 Certification Hierarchy - In this structure, one CA is the top CA,=20 the highest level of the hierarchy. The top CA may issue public-key=20 certificates to one or more additional CAs that form the second=20 highest level. Each of these CAs may issue certificates to more CAs=20 at the third highest level, and so on. The CAs at the second-lowest=20 of the hierarchy issue certificates only to non-CA entities, called=20 "end entities" that form the lowest level. Thus, all certification=20 paths begin at the top CA and descend through zero or more levels of=20 other CAs. All certificate users base path validations on the top=20 CA's public key. [RFC2828]=20 =20 CEM Request =96The EDIINT Certificate Exchange Messaging (CEM) = Request=20 is one of two possible CEM messages. It presents a certificate to be=20 introduced into the trading partner relationship along with relevant=20 information on how it is to be implemented.=20 =20 CEM Response =96The EDIINT Certificate Exchange Messaging (CEM)=20 Response is one of two possible CEM messages. It is the response to=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 4]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 the CEM Request indicating whether or not the end entity certificate=20 present in the CEM Request was accepted. =20 =20 End Entity =96 A system entity that is the subject of a public-key=20 certificate and that is using, or is permitted and able to use, the=20 matching private key only for a purpose or purposes other than=20 signing a digital certificate; i.e., an entity that is not a CA.=20 [RFC2828]=20 =20 End Entity Certificate - A certificate which is used to encrypt data=20 or authenticate a signature. (The private key associated with the=20 certificate is used to decrypt data or sign data). The certificate=20 may be self-signed or issued by a trusted certificate.=20 =20 Intermediary Certificate - A certificate issued by a CA certificate=20 which itself issues another certificate (either intermediary or end=20 entity). Intermediary certificates are not used to encrypt data but=20 to sign other certificates.=20 =20 Public Key - The publicly-disclosable component of a pair of=20 cryptographic keys used for asymmetric cryptography. [RFC2828]=20 =20 Public Key Certificate - A digital certificate that binds a system=20 entity's identity to a public key value, and possibly to additional=20 data items. [RFC2828]=20 =20 Self-signed Certificate - A certificate which is issued by itself=20 (both issuer and subject are the same) and is an End Entity=20 certificate.=20 =20 1.3 =0D Certificate Lifecycle=20 =20 A certificate has five states.=20 =20 1. Pending - Upon receiving a certificate from a trading partner, the = certificate is marked as Pending until a decision can be made to=20 trust it or if its validity period has not yet begun.=20 2. Rejected =96 If a Pending certificate is not trusted, it is=20 considered Rejected.=20 3. Accepted - Once a Pending certificate has been trusted, it is=20 considered Accepted. An Accepted certificate may be used in=20 secure transactions. =20 4. Expired =96 A certificate which is no longer valid because its=20 expiration date has passed. Expired certificates SHOULD be kept=20 in a certificate storehouse for decrypting and validating past=20 transactions.=20 5. Revoked =96 A certificate which has been explicitly revoked by its = owner or the certificate authority.=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 5]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 2. =0D Message Processing=20 =20 2.1 =0D Message Structure=20 =20 CEM messages use the underlying EDIINT transport, such as AS2, to=20 communicate information on the certificate, its intended use and its=20 acceptance. Both digital certifications and the XML data describing=20 their intended use are stored within a multipart-related MIME=20 envelope [RFC2387]. The certificates are stored in certificate chains = through SMIME, certs-only MIME envelope [3851], and processing=20 information is XML data which is identified through the MIME content- type of application/ediint-cert-exchange+xml. The format for CEM=20 messages is as follows:=20 =20 Various EDIINT headers=20 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company=20 Content-Type: multipart/signed; micalg=3Dsha1;=20 protocol=3D"application/pkcs7-signature"; =20 boundary=3D"--OUTER-BOUNDARY"=20 =20 ----OUTER-BOUNDARY=20 Content-Type: multipart/related; type=3D" application/ediint-cert- exchange+xml"; boundary=3D"--INNER-BOUNDARY"=20 =20 ----INNER-BOUNDARY=20 Content-Type: application/ediint-cert-exchange+xml=20 Content-ID: <[email protected]>=20 =20 [CEM XML data]=20 ----INNER-BOUNDARY=20 Content-Type: application/pkcs7-mime; smime-type=3Dcerts-only=20 Content-ID: <[email protected]>=20 =20 [digital certificate]=20 ----INNER-BOUNDARY--=20 =20 ----OUTER-BOUNDARY=20 Content-Type: application/pkcs7-signature=20 =20 [Digital Signature]=20 ----OUTER-BOUNDARY--=20 =20 One and only one MIME type of application/ediint-cert-exchange+xml=20 MUST be present in the multipart/related structure, and it MUST be=20 the root element. Multiple certs-only media types may be included,=20 but at least one MUST be present. A unique content-id header MUST be=20 present within each of the multipart structures.=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 6]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 If possible, both the CEM Request and CEM Response message SHOULD be=20 signed. Applying digital signatures will allow for automatic exchange = based on a previous trust relationship. However, it may not be=20 possible in the initial exchange of a new trading partner. If a CEM=20 message is signed, the signing certificate MUST be included in the=20 digital signature. Extra security such as applying data encryption or = compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and=20 SHOULD request a signed MDN. The MDN can be either synchronous or=20 asynchronous. The MDN response verifies the transport delivery but is = not equivalent to the CEM Response message. All necessary headers=20 MUST be applied to the message per the underlying transport standard. = =20 =20 2.2 =0D Version Header=20 =20 Before a CEM Request message is generated, the initiator MUST=20 determine if the recipient can accept the CEM Request message. For=20 both AS2 and AS3, the version header value of 1.2 or greater (e.g.=20 1.3) indicates the implementation can both initiate and receive CEM=20 message exchanges. AS2 and AS3 implementers of CEM MUST utilize the=20 proper version header in all of their messages, both CEM messages and = normal document transport messages. Since there is no AS1 version=20 header, trading partners using AS1 MUST decide within the trading=20 partner agreement whether to utilize CEM.=20 =20 For CEM Request messages of initial trading partner configurations,=20 the initiator MUST decide within the trading partner agreement if the = recipient can accept the CEM Request.=20 =20 2.3 =0D Certificate Exchanging=20 =20 After obtaining the desired certificate, the initiator of the=20 certificate exchange transmits the end-entity certificate in the CEM=20 Request message. If the end-entity certificate is not self-signed,=20 then the CA certificate and any other certificates needed to create=20 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.=20 =20 The entire certificate trust chain is stored in a BER encoded P7C=20 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- only MIME envelope which is then stored in a single part of the=20 multipart/related structure. Each P7C trust chain MUST include a=20 single end-entity certificate and its trust authorities. No other=20 certificates are to be part of this chain. The number of P7C trust=20 chains in a CEM Request message MUST be equal to the number of end- entity certificates being communicated in the CEM XML document.=20 If different end-entity certificates have common trust authorities=20 certificates, each P7C cert chain still MUST included each=20 certificate necessary to create a trust anchor. Thus, if a recipient=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 7]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 can not create a trust relationship from the P7C cert chain, it MAY=20 reject the end-entity certificate in the CEM Request.=20 =20 End-entity certificates are referenced and identified in the XML data = by their content-id used in the multipart-related structure.=20 Information on how the certificate is to be used, or certificate=20 usage, by the receiving user agent and other related information is=20 found in the XML data. A certificate can be used for a single=20 function, like digital signatures, or used for multiple functions,=20 such as both digital signatures and data encryption. If a certificate = is intended for multiple usages, such as for both digital signatures=20 and data encryption, the certificate MUST be listed only once in the=20 CEM Request message and its multiple usage listed through the=20 CertUsage XML element.=20 =20 Upon receipt of the CEM Request, the recipient trading partner=20 processes the transport message as normal and returns the MDN. The=20 recipient MUST return the MDN before parsing and interpreting the CEM = XML data or certificate chains. The returned MDN only provides=20 information on the veracity of the transport message and not the=20 acceptance of the certificate(s) being exchanged.=20 =20 =20 2.4 =0D Certificate Implementation=20 =20 The new certificate is considered to be in the Pending state for the=20 recipient who MUST decide whether to accept the certificate as=20 trustworthy. This decision is arbitrary and left to each individual=20 trading partner. Upon accepting the certificate, it is to be=20 considered an Accepted certificate within the trading partner=20 relationship. If the certificate is not accepted, it is considered=20 Rejected.=20 =20 When a certificate is intended for use in data encryption or TLS/SSL=20 server authentication, the initiator MUST consider the certificate to = be Accepted and be prepared for its trading partner to begin using=20 the certificate upon generating the CEM Request message. After a=20 recipient generates a positive CEM Response message for a=20 certificate, the recipient MUST immediately begin using the=20 certificate in trading with the initiator of the request. The=20 recipient MAY apply encryption to the CEM Response message using the=20 new Accepted certificate or MAY apply encryption to the CEM Response=20 message using the previously Accepted encryption certificate.=20 =20 When a certificate is intended for use in digital signatures or=20 TLS/SSL client authentication, the initiator MUST NOT use the=20 certificate until the recipient trading partner generates a CEM=20 Response accepting the certificate or the respond by date, which is=20 listed in the RespondByDate XML element. The initiator MAY use the=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 8]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 certificate after the respond by date, regardless of whether the=20 partner has accepted it or not. The certificate used for the digital=20 signature of the CEM Request message MUST be the one which is=20 currently Accepted within the trading partner relationship.=20 =20 Since implementers of EDIINT often use the same certificate with=20 multiple trading partners, implementers of CEM MUST be able to keep=20 both the old and new certificates as Accepted. If the initiator has=20 generated a CEM Request and exchanged a new encryption certificate to = multiple trading partners, it MUST be able to accept encrypted data=20 which uses either the older, existing encryption certificate or the=20 newly exchanged encryption certificate. Likewise, a recipient of a=20 CEM Request MUST be able to authenticate digital signatures using=20 either the new or old certificates, since the initiator may not be=20 able to switch certificates until all trading partners accept the new = certificate. Similar provisions MUST be made for certificates=20 intended for TLS/SSL server and client authentication. Revoking a=20 certificate MUST be done outside of CEM.=20 =20 If a CEM Request message contains a certificate which is currently=20 Accepted and has the identical usage for the certificate that has=20 been Accepted, the recipient MUST NOT reject the duplicate=20 certificate but MUST respond with a CEM Response message indicating=20 the certificate has been accepted. For example, if Certificate A is=20 currently Accepted as the encryption certificate for a user agent,=20 any CEM Request message containing Certificate A with the usage as=20 the encryption only MUST be accepted by an existing trading partner.=20 This situation may be necessary for an implementation intending to=20 verify its current trading partner certificate.=20 =20 If two trading partners utilize multiple EDIINT protocols for=20 trading, such as AS2 for a primary transport and AS1 as the backup=20 transport, it is dependent upon implementation and trading partner=20 agreement how CEM messages are sent and which transports the=20 exchanged certificates affect.=20 =20 2.5 =0D CEM Response=20 =20 If a CEM Request is received, the recipient MUST respond with a CEM=20 Response message indicating if the certificate is Accepted or=20 Rejected. If multiple end-entity certificates were included within=20 the CEM Request, the recipient MAY generate individual CEM Response=20 messages for each certificate or the recipient MAY consolidate=20 responses for multiple certificates in one or more CEM Response=20 messages. CEM Response are NOT sent for any certificates other than=20 end-entity certificates. Based on the CEM Response message, the=20 initiator determines if the exchanged certificate may be used in=20 future trading with the recipient partner.=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 9]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 The recipient SHOULD NOT generate more than one CEM Response for a=20 given end-entity certificate. If the recipient sends more than one=20 response, the action of the originator of the CEM Request is not=20 defined.=20 =20 =20 =20 3. =0D XML Schema Description=20 =20 The CEM schema has two top-level elements,=20 EDIINTCertificateExchangeRequest and=20 EDIINTCertificateExchangeResponse. The=20 EDIINTCertificateExchangeRequest element is present only in the CEM=20 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=20 schema document.=20 =20 3.1 =0D EDIINTCertificateExchangeRequest element=20 =20 EDIINTCertificateExchangeRequest contains two elements,=20 TradingPartnerInfo, which can only appear once and TrustRequest,=20 which may be present multiple times. TrustRequest contains=20 information on a certificate and its intended usage.=20 TradingPartnerInfo exists to provide information on the publication=20 of the CEM Request message since processing of the XML data may occur = apart from the handling of the accompanying transport message, for=20 example the AS2 request. =20 =20 <xs:element name=3D"EDIINTCertificateExchangeRequest">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element ref=3D"tns:TradingPartnerInfo"/>=20 <xs:element name=3D"TrustRequest" =20 type=3D"tns:TrustRequestType"=20 maxOccurs=3D"unbounded"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 =20 TradingPartnerInfo identifies the entity that created the CEM message = through the nested Name element. Both the optional qualifier=20 attribute and the element value of Name are left open to the=20 implementer, but some suggested choices are to list the EDI=20 identification or the transport trading partner relationship, for=20 example the qualifier of =93AS2=94 and the value of the AS2 system=20 identifier (AS2-From value). MessageOriginated is included in=20 TradingPartnerInfo to identify the time and date the message was=20 created. The MessageOriginated date and time values MUST follow XML=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 10]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 standard dateTime type syntax and be listed to at least the nearest=20 second and expressed in local time with UTC offset.=20 =20 <xs:element name=3D"TradingPartnerInfo">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element name=3D"Name">=20 <xs:complexType>=20 <xs:simpleContent>=20 <xs:extension base=3D"xs:string">=20 <xs:attribute name=3D"qualifier" =20 type=3D"xs:string" use=3D"optional"/>=20 </xs:extension>=20 </xs:simpleContent>=20 </xs:complexType>=20 </xs:element>=20 <xs:element name=3D"MessageOriginated" = type=3D"xs:dateTime"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 =20 =20 The TrustRequest element contains the EndEntity, CertUsage,=20 RespondByDate and ResponseURL elements. The required EndEntity=20 element is found only once in a TrustRequest element and contains the = content-id reference to the end-entity certificate being exchanged. =20 =20 <xs:complexType name=3D"TrustRequestType">=20 <xs:sequence>=20 <xs:element ref=3D"tns:CertUsage" maxOccurs=3D"unbounded"/>=20 <xs:element ref=3D"tns:RespondByDate"/>=20 <xs:element ref=3D"tns:ResponseURL"/>=20 <xs:element name=3D"EndEntity" type=3D"tns:EndEntityType"/>=20 </xs:sequence>=20 </xs:complexType>=20 =20 EndEntity contains the nested elements of CertificateIdentifier and=20 CertificateContentID. CertificateContentID is a string element which=20 references the content-id of the multipart/related structure where=20 the certificate is stored. CertificateIdentifier comes from the XML=20 Signature schema namespace [XML-DSIG]. =20 =20 <xs:complexType name=3D"EndEntityType">=20 <xs:sequence>=20 <xs:element name=3D"CertificateIdentifier" =20 type=3D"ds:X509IssuerSerialType"/>=20 <xs:element name=3D"CertificateContentID" = type=3D"xs:string"/>=20 </xs:sequence>=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 11]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 CertificateIdentifier contains the string element X509IssuerName and=20 the integer element X509SerialNumber. X509SerialNumber is the=20 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=20 issuer attribute abbreviation [X.520] [PROFILE] followed by the equal = sign (i.e. =93=3D=94), then separating each attribute listing by a = single=20 semi-colon (e.g. CN=3DThe Common Name;O=3DOrganization;=85). Refer to = the=20 appendix and the sample CEM Request message for an example of the=20 X509IssuerName.=20 =20 <complexType name=3D"X509IssuerSerialType"> =20 <sequence> =20 <element name=3D"X509IssuerName" type=3D"string"/> =20 <element name=3D"X509SerialNumber" = type=3D"integer"/> =20 </sequence>=20 </complexType>=20 =20 CertUsage is an unbounded element which contains enumerated values on = how the exchanged certificate is to be used. There are enumerated=20 values for SMIME digital signatures (digitalSignature), SMIME data=20 encryption (keyEncipherment), the server certificate used in TLS=20 transport encryption (tlsServer) and the client certificate used in=20 TLS transport encryption (tlsClient). While the element is unbounded, = CertUsage only has a potential number of four occurrences due to the=20 limit of the enumerated values. =20 =20 <xs:element name=3D"CertUsage" type=3D"tns:CertUsageType"/>=20 <xs:simpleType name=3D"CertUsageType">=20 <xs:restriction base=3D"xs:string">=20 <xs:enumeration value=3D"tlsClient"/>=20 <xs:enumeration value=3D"tlsServer"/>=20 <xs:enumeration value=3D"keyEncipherment"/>=20 <xs:enumeration value=3D"digitalSignature"/>=20 </xs:restriction>=20 </xs:simpleType>=20 =20 RespondByDate is a required element of the XML standard dateTime type = expressed in local time with UTC offset, which provides information=20 on when the certificate should be trusted, inserted into the trading=20 partner relationship and responded to by a CEM Response message. If=20 the certificate can not be trusted or inserted into the trading=20 partner relationship, the CEM Response message should still be=20 returned by the date indicated.=20 =20 <xs:element name=3D"RespondByDate" type=3D"xs:dateTime"/>=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 12]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 ResponseURL is an element which indicates where the CEM Response=20 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=20 Request. =20 <xs:element name=3D"ResponseURL" type=3D"xs:anyURI"/>=20 =20 3.2 =0D EDIINTCertificateExchangeResponse element=20 =20 EDIINTCertificateExchangeResponse contains the two elements=20 TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is=20 also found in EDIINTCertificateExchangeRequest, describes the trading = partner generating this response message. TrustResponse provides=20 information on the acceptance of a previously sent end entity=20 certificate. There can be multiple TrustResponse elements within an=20 EDIINTCertificateExchangeResponse.=20 =20 <xs:element name=3D"EDIINTCertificateExchangeResponse">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element ref=3D"tns:TradingPartnerInfo"/>=20 <xs:element name=3D"TrustResponse" =20 type=3D"tns:TrustResponseType"=20 maxOccurs=3D"unbounded"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 =20 <xs:complexType name=3D"TrustResponseType">=20 <xs:sequence>=20 <xs:element ref=3D"tns:CertStatus"/>=20 <xs:element ref=3D"tns:ReasonForRejection" minOccurs=3D"0"/> = <xs:element name=3D"CertificateReference" =20 type=3D"ds:X509IssuerSerialType"/>=20 </xs:sequence>=20 </xs:complexType>=20 =20 A TrustResponse element identifies a certificate which has been=20 previously exchanged within the trading partner relationship through=20 a CEM Request and now has been either accepted or rejected by the=20 partner. The CertificateReference element is of the same type as the=20 CertificateIdentifier element. A CertificateReference element in a=20 CEM Response MUST be identical to its CertificateIdentifier=20 counterpart in the associated CEM Request since they identify the=20 same certificate in question.=20 =20 The required element CertStatus has the enumerated values of=20 =93Accepted=94 or =93Rejected=94. =93Accepted=94 indicates the = certificate was=20 trusted by the trading partner and is now ready for use within the=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 13]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 trading partner relationship, and =93Rejected=94 indicates the=20 certificate is not trusted by the trading partner nor can it be=20 currently used with the trading partner relationship. If the value of = =93Rejected=94 is chosen, the optional string element = ReasonForRejection=20 may be included. If present, ReasonForRejection should contain a=20 brief description of why the certificate was not accepted. Since the=20 value for this element is not enumerated but open, it MUST be=20 interpreted through human means.=20 =20 <xs:element name=3D"CertStatus" type=3D"tns:CertStatusType"/>=20 <xs:simpleType name=3D"CertStatusType">=20 <xs:restriction base=3D"xs:string">=20 <xs:enumeration value=3D"Rejected"/>=20 <xs:enumeration value=3D"Accepted"/>=20 </xs:restriction>=20 </xs:simpleType>=20 <xs:element name=3D"ReasonForRejection" type=3D"xs:string"/>=20 =20 4. =0D Use Case Scenarios=20 =20 These scenarios illustrate how the request and response messages=20 described in Section 2 and 3 can be used to exchange certificates. =20 The requirements of this standard are in Section 2 and 3; this=20 section is only illustrative.=20 =20 4.1 =0D Maintenance Configuration Processing=20 =20 This use case assumes an established relationship with currently=20 working certificates. Examples of this use case include, but are not=20 limited to a certificate with an expiration date approaching. If the = current certificate is used to sign the Certificate Exchange=20 messages, this signature can be used to establish a level of trust in = the transaction. For this example, the AS2 transport protocol is=20 used.=20 =20 4.1.1. Step 1=20 =20 Initiator creates an EDIINTCertificateExchangeRequest as described in = Section 2. Message Processing and Section 3. XML Schema Description=20 and sends it according to EDIINT-AS2 protocol. A positive MDN=20 received during this step indicates successful transmission of the=20 message but does not imply successful action on the certificate. In=20 the case of an encryption certificate, the initiator MUST be=20 immediately ready to receive documents encrypted with the new=20 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=20 partner indicating acceptance of the certificate. If an acceptance=20 response is not received by the RespondByDate, the initiator may or=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 14]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 may not begin signing with the new certificate, depending on the=20 implementation=92s capabilities and the policies of the initiator.=20 =20 4.1.2. Step 2=20 =20 Receiver validates the EDIINTCertificateExchangeRequest message at=20 the AS2 level and returns a correct MDN. If the message is a proper=20 AS2 document, the receiver MUST automatically accept or reject the=20 new certificate(s) or require manual intervention. If the certificate = is automatically accepted or rejected, an=20 EDIINTCertificateExchangeResponse MUST be generated and returned to=20 the initiator. Since the trading relationship could be hindered if=20 action is not taken prior to the RespondByDate, manual intervention=20 MUST be done before that date. When the manual intervention=20 determines to accept or reject the new certificate, an=20 EDIINTCertificateExchangeResponse MUST be generated and returned to=20 the initiator. Both automatic and manual=20 EDIINTCertificateExchangeResponses MUST be formatted according to=20 Section 2. Message Processing and Section 3. XML Schema Description=20 and sent according to EDIINT-AS2 protocol. A positive MDN received=20 for the response message indicates successful transmission of the=20 response message.=20 =20 After the receiver accepts the new certificate and returns an=20 acceptance response, the receiver encrypts all messages to the=20 initiator with the new encryption certificate. The receiver=20 continues to accept messages from the initiator that are signed with=20 the old signing certificate, and also accepts messages signed with=20 the new signing certificate. The initiator may start signing with=20 the new certificate when it receives the acceptance response, or when = it receives acceptance responses from all its partners, or after the=20 RespondByDate, or when the old signing certificate expires.=20 =20 4.1.3. Step 3=20 =20 After the exchange is complete, some cleanup may be desirable,=20 including retiring or archiving the old certificates. This step is=20 considered an implementation detail that is left purely to the=20 vendors and users.=20 =20 4.2 =0D Initial Configuration Processing=20 =20 This use case assumes all necessary elements of an EDIINT=20 relationship exist outside of the certificates, including an=20 understanding of the partner=92s ability to support a CEM. =20 Establishing these elements may be accomplished via an automated=20 exchange, a manual process, or any other method desirable. No=20 methods of exchanging the additional information are described in=20 this specification. Examples of this use case include, but are not=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 15]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 limited to the first exchange of a certificate, or recovery from an=20 expired or compromised certificate. This case assumes no signing=20 certificate has been established, precluding a signature being used=20 to establish a level of trust. Therefore, extra precautions may be=20 appropriate in this use case. There are additional use cases=20 possible where some certificates are already established. It is not=20 practical to cover every case here, but this case and the maintenance = case should give sufficient guidance.=20 =20 4.2.1. Step 1=20 =20 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=20 verify until after accepting the signature certificate. If the=20 receiver supports this use case, they MUST accept this message=20 regardless of the presence of a signature. Unless the initiator=20 possesses the receiver=92s encryption certificate, encryption MUST = NOT=20 be used. Unless the initiator possesses the receiver=92s signature=20 certificate, they SHOULD NOT request a signed MDN. If the MDN is not = signed, there is no legal proof the receiver received the message. =20 In addition, a positive MDN received during this step gives some=20 indication of successful transmission of the message, but does not=20 imply successful action on the certificate. In the case of an=20 encryption certificate, the initiator MUST be immediately ready to=20 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=20 EDIINTCertificateExchangeResponse from the partner indicating they=20 are ready. If an acceptance response is not received by the=20 RespondByDate, the initiator may or may not begin signing with the=20 new certificate, depending on the implementation=92s capabilities and = the policies of the initiator.=20 =20 4.2.2. Step 2=20 =20 Receiver validates the EDIINTCertificateExchangeRequest message at=20 the AS2 level and returns an MDN according to the EDIINT-AS2=20 protocol. If the message is a proper AS2 document, the receiver MUST = automatically accept or reject the new certificate(s), or require=20 manual intervention. Caution should be used in automatically=20 accepting the certificate, as it may be impossible to verify the=20 sender is authentic. If the certificate is automatically accepted or = rejected, an EDIINTCertificateExchangeResponse MUST be generated and=20 returned to the initiator. Since the trading relationship could be=20 hindered if action is not taken prior to the RespondByDate, manual=20 intervention MUST be done before that date. When the manual=20 intervention determines to accept or reject the certificate, an=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 16]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 EDIINTCertificateExchangeResponse MUST be generated and returned to=20 the initiator. =20 =20 In both the automatic and manual case, the=20 EDIINTCertificateExchangeResponses MUST be formatted according to=20 Section 2. Message Processing and Section 3. XML Schema Description=20 and sent according to EDIINT-AS2 protocol. If the original CEM=20 included the encryption certificate, or if the receiver has the=20 initiator encryption certificate on file, it may be used to encrypt=20 the AS2 message including the EDIINTCertificateExchangeResponse. =20 Otherwise, it may be necessary to send this=20 EDIINTCertificateExchangeResponse unencrypted. The message may be=20 signed, but it is possible the initiator will have no way to verify=20 the signature. The initiator MUST accept this response, regardless=20 of if it is signed. A positive MDN received for the response message = indicates successful transmission of the response message.=20 =20 After the receiver accepts the certificate and returns an acceptance=20 response, the receiver may encrypt messages to the initiator with the = encryption certificate. The receiver begins to accept messages from=20 the initiator that are signed with the signing certificate. The=20 initiator may start signing with the certificate when it receives the = acceptance response, or when it receives acceptance responses from=20 all its partners, or after the RespondByDate.=20 =20 4.2.3. Step 3=20 =20 After the exchange is complete, additional certificates may need to=20 be exchanged before a complete trading relationship can be=20 successful. This step is considered an implementation detail that=20 is left purely to the vendors and users.=20 =20 =20 5. =0D Profile Exchange Messaging=20 =20 CEM provides the means to exchange certificates among trading=20 partners. However, other profile information, such as URLs and=20 preferred security settings, is needed to create a trading partner=20 relationship. A future standard is needed to describe profile=20 descriptions and how they will be exchanged. The format for this=20 profile attachment is not defined in this specification but is=20 planned for a future document. It will build upon the existing CEM=20 protocol with profile information stored with XML data. Both=20 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:=20 =20 Various EDIINT headers=20 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 17]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 Disposition-Notification-Options: signed-receipt-protocol=3Doptional, = pkcs7-signature; signed-receipt-micalg=3Doptional, sha1=20 Content-Type: multipart/signed; micalg=3Dsha1;=20 protocol=3D"application/pkcs7-signature"; boundary=3D"--BOUNDARY1"=20 =20 ----BOUNDARY1=20 Content-Type: multipart/related;=20 start=3D=94<[email protected]>"; =20 type=3D=94application/ediint-cert-exchange+xml=94; =20 boundary=3D"--BOUNDARY2"=20 =20 ----BOUNDARY2=20 Content-Type: application/ediint-cert-exchange+xml=20 Content-ID: <[email protected]>=20 =20 [CEM XML data]=20 ----BOUNDARY2=20 [Profile information attachment]=20 ----BOUNDARY2--=20 ----BOUNDARY1=20 =20 Content-Type: application/pkcs7-signature=20 =20 [Digital Signature]=20 ----BOUNDARY1--=20 =20 =20 6. =0D Security Considerations=20 =20 Certificate exchange is safe for transmitting. However, implementers=20 SHOULD verify the received certificate to determine if it is truly=20 from the stated originator through out-of-band means for the initial=20 use case of 4.2 or whenever the request is not signed.=20 =20 =20 7. =0D IANA Considerations=20 =20 MIME Media type name: Application=20 =20 MIME subtype name: EDIINT-cert-exchange+xml=20 =20 Required parameters: None=20 =20 Optional parameters: This parameter has identical semantics to the=20 charset parameter of the =93application/xml=94 media type as = specified=20 in [RFC3023].=20 =20 Encoding considerations: Identical to those of "application/xml" as=20 described in [RFC3023], section 3.2.=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 18]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 =20 Security considerations: See section 6. =20 =20 Interoperability Considerations: See section 2.2=20 =20 Published specification: This document.=20 =20 Applications which use this media type: EDIINT applications, such as=20 AS1, AS2 and AS3 implementations.=20 =20 Additional Information: None=20 =20 Intended Usage: Common=20 =20 Author/Change controller: See Author=92s section of this document.=20 =20 8. =0D References=20 8.1 =0D Normative References=20 =20 [AS1] RFC3335 =93MIME-based Secure Peer-to-Peer Business Data=20 Interchange over the Internet using SMTP=94, T. Harding, R.=20 Drummond, C. Shih, 2002.=20 =20 [AS2] draft-ietf-ediint-as2-15.txt =93MIME-based Secure Peer-to-Peer=20 Business Data Interchange over the Internet using HTTP=94, D.=20 Moberg, R. Drummond, 2004.=20 =20 [AS3] draft-ietf-ediint-as3-02.txt =93MIME-based Secure Peer-to-Peer=20 Business Data Interchange over the Internet using FTP=94, T.=20 Harding, R. Scott, 2003.=20 =20 [RFC2119] RFC2119 =93Key Words for Use in RFC's to Indicate = Requirement=20 Levels=94, S.Bradner, March 1997.=20 =20 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,=20 January 1999.=20 =20 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.=20 Levinson, August 1998.=20 =20 [RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000.=20 =20 [RFC2828] RFC2828 =93Internet Security Glossary=94, R. Shirley, May = 2000.=20 =20 [RFC3023] RFC3023 =93XML Media Types=94, M. Murata, January 2001.=20 =20 [3821] RFC3821 =93S/MIME Version 3.1 Message Specification=94, B.=20 Ramsdell, July 2004.=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 19]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 [XML-DSIG] RFC3275 =93XML-Signature Syntax and Processing=94, D.=20 Eastlake, March 2002. =20 =20 [X.520] ITU-T Recommendation X.520: Information Technology =96 Open=20 Systems Interconnection - The Directory: Selected Attribute=20 Types, 1993.=20 =20 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet=20 X.509 Public Key Infrastructure: Certificate and CRL Profile",=20 RFC 3280, April 2002.=20 =20 8.2 =0D Informative References=20 =20 9. =0D Acknowledgments=20 =20 The authors wish to extend gratitude to the ecGIF sub-committee=20 within the EAN.UCC organization from which this effort began. Of=20 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=20 implementation and James Zwyer for his contribution to the use case=20 scenarios.=20 =20 Author's Addresses=20 =20 Kyle Meadors=20 Drummond Group Inc.=20 4700 Bryant Irvin Court, Suite 303=20 Fort Worth, TX 76107 USA=20 Email: [email protected]=20 =20 Dale Moberg=20 Cyclone Commerce=20 8388 E. Hartford Drive, Suite 100=20 Scottsdale, AZ 85255 USA=20 Email: [email protected]=20 =20 =20 Copyright Notice=20 Copyright (C) The Internet Society 2004. This document is subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights.=20 =20 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=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 20]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Appendix=20 =20 A.1 EDIINT Certificate Exchange XML Schema=20 =20 <?xml version=3D"1.0" encoding=3D"UTF-8"?>=20 <!--W3C Schema generated by XMLSPY v2004 rel. 3 U=20 (http://www.xmlspy.com)-->=20 <xs:schema=20 = targetNamespace=3D"http://www.ietf.org/schemas/EDIINTCertificateExchang e.xsd"=20 = xmlns:tns=3D"http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd"=20 xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=20 xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"=20 elementFormDefault=3D"qualified">=20 <xs:import namespace=3D"http://www.w3.org/2000/09/xmldsig#"=20 schemaLocation=3D"xmldsig-core-schema.xsd"/>=20 <xs:element name=3D"EDIINTCertificateExchangeRequest">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element ref=3D"tns:TradingPartnerInfo"/>=20 <xs:element name=3D"TrustRequest" =20 type=3D"tns:TrustRequestType" = maxOccurs=3D"unbounded"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 <xs:element name=3D"EDIINTCertificateExchangeResponse">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element ref=3D"tns:TradingPartnerInfo"/>=20 <xs:element name=3D"TrustResponse" =20 type=3D"tns:TrustResponseType" = maxOccurs=3D"unbounded"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 <xs:element name=3D"TradingPartnerInfo">=20 <xs:complexType>=20 <xs:sequence>=20 <xs:element name=3D"Name">=20 <xs:complexType>=20 <xs:simpleContent>=20 <xs:extension base=3D"xs:string">=20 <xs:attribute name=3D"qualifier" =20 type=3D"xs:string" use=3D"optional"/>=20 </xs:extension>=20 </xs:simpleContent>=20 </xs:complexType>=20 </xs:element>=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 21]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 <xs:element name=3D"MessageOriginated" = type=3D"xs:dateTime"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:element>=20 <xs:element name=3D"CertUsage" type=3D"tns:CertUsageType"/>=20 <xs:simpleType name=3D"CertUsageType">=20 <xs:restriction base=3D"xs:string">=20 <xs:enumeration value=3D"tlsClient"/>=20 <xs:enumeration value=3D"tlsServer"/>=20 <xs:enumeration value=3D"keyEncipherment"/>=20 <xs:enumeration value=3D"digitalSignature"/>=20 </xs:restriction>=20 </xs:simpleType>=20 <xs:element name=3D"CertStatus" type=3D"tns:CertStatusType"/>=20 <xs:simpleType name=3D"CertStatusType">=20 <xs:restriction base=3D"xs:string">=20 <xs:enumeration value=3D"Rejected"/>=20 <xs:enumeration value=3D"Accepted"/>=20 </xs:restriction>=20 </xs:simpleType>=20 <xs:element name=3D"ReasonForRejection" type=3D"xs:string"/>=20 <xs:element name=3D"RespondByDate" type=3D"xs:dateTime"/>=20 <xs:element name=3D"ResponseURL" type=3D"xs:anyURI"/>=20 <xs:complexType name=3D"EndEntityType">=20 <xs:sequence>=20 <xs:element name=3D"CertificateIdentifier" =20 type=3D"ds:X509IssuerSerialType"/>=20 <xs:element name=3D"CertificateContentID" = type=3D"xs:string"/>=20 </xs:sequence>=20 </xs:complexType>=20 <xs:complexType name=3D"TrustRequestType">=20 <xs:sequence>=20 <xs:element ref=3D"tns:CertUsage" maxOccurs=3D"unbounded"/>=20 <xs:element ref=3D"tns:RespondByDate"/>=20 <xs:element ref=3D"tns:ResponseURL"/>=20 <xs:element name=3D"EndEntity" type=3D"tns:EndEntityType"/>=20 </xs:sequence>=20 </xs:complexType>=20 <xs:complexType name=3D"TrustResponseType">=20 <xs:sequence>=20 <xs:element ref=3D"tns:CertStatus"/>=20 <xs:element ref=3D"tns:ReasonForRejection" minOccurs=3D"0"/> = <xs:element name=3D"CertificateReference" =20 type=3D"ds:X509IssuerSerialType"/>=20 </xs:sequence>=20 </xs:complexType>=20 </xs:schema>=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 22]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 A.2 Example of EDIINT Certificate Exchange Request XML=20 =20 <?xml version=3D"1.0" standalone=3D"yes"?> =20 <EDIINTCertificateExchangeRequest=20 xmlns=3D"EDIINTCertificateExchange.xsd" =20 xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =20 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =20 = xsi:schemaLocation=3D"http://www.ietf.org/schemas/EDIINTCertificateE xchange.xsd=20 EDIINTCertificateExchange.xsd"> =20 <TradingPartnerInfo> =20 <Name qualifier=3D"AS2">DGI_Test_CEM</Name> =20 <MessageOriginated>2005-01-27T17:21:00- 05:00</MessageOriginated> =20 </TradingPartnerInfo>=20 <TrustRequest> =20 <CertUsage>keyEncipherment</CertUsage>=20 <CertUsage>digitalSignature</CertUsage>=20 <RespondByDate>2005-02-01T12:00:00-05:00</RespondByDate>=20 <ResponseURL>http://10.1.1.1/as2</ResponseURL>=20 <EndEntity>=20 <CertificateIdentifier>=20 <ds:X509IssuerName>CN=3DCleo-SP;=20 [email protected];=20 O=3DDGI; OU=3DDGI; L=3DFt. Worth; S=3DTexas;=20 C=3DUS</ds:X509IssuerName> =20 =20 <ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>=20 </CertificateIdentifier>=20 <CertificateContentID>sign_enc-cert- [email protected]</CertificateContentID>=20 </EndEntity> =20 </TrustRequest>=20 <TrustRequest>=20 <CertUsage>tlsServer</CertUsage>=20 <RespondByDate>2005-02-01T12:00:00-05:00</RespondByDate>=20 <ResponseURL>http://10.1.1.1/as2</ResponseURL>=20 <EndEntity>=20 <CertificateIdentifier>=20 <ds:X509IssuerName>CN=3DVeriSign Class 1 CA Individual=20 Subscriber-Persona Not Validated;=20 OU=3Dwww.verisign.com/repository/RPA Incorp. By=20 Ref.,LIAB.LTD(c)98 OU=3DVeriSign Trust Network=20 O=3DVeriSign, Inc.</ds:X509IssuerName> =20 =20 <ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X509Se rialNumber>=20 </CertificateIdentifier>=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 23]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 <CertificateContentID>ssl-cert- [email protected]</CertificateContentID>=20 </EndEntity> =20 </TrustRequest>=20 </EDIINTCertificateExchangeRequest>=20 =20 A.3 Example of EDIINT Certificate Exchange Response XML=20 =20 <?xml version=3D"1.0"?>=20 <EDIINTCertificateExchangeResponse=20 xmlns=3D"EDIINTCertificateExchange.xsd" =20 xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =20 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=20 = xsi:schemaLocation=3D"http://www.ietf.org/schemas/EDIINTCertificateExch ange.xsd EDIINTCertificateExchange.xsd">=20 <TradingPartnerInfo> =20 <Name qualifier=3D"AS2">DGI_Test_CEM_Trading_Partner</Name> =20 <MessageOriginated>2005-01-22T17:21:00- 05:00</MessageOriginated> =20 </TradingPartnerInfo> =20 <TrustResponse>=20 <CertStatus>Accepted</CertStatus>=20 <CertificateReference>=20 <ds:X509IssuerName>CN=3DCleo-SP;=20 [email protected];=20 O=3DDGI; OU=3DDGI; L=3DFt. Worth; S=3DTexas;=20 C=3DUS</ds:X509IssuerName>=20 =20 <ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>=20 </CertificateReference>=20 </TrustResponse>=20 <TrustResponse>=20 <CertStatus>Accepted</CertStatus>=20 <CertificateReference>=20 <ds:X509IssuerName>CN=3DVeriSign Class 1 CA Individual=20 Subscriber-Persona Not Validated;=20 OU=3Dwww.verisign.com/repository/RPA Incorp. By=20 Ref.,LIAB.LTD(c)98 OU=3DVeriSign Trust Network=20 O=3DVeriSign, Inc.</ds:X509IssuerName> =20 =20 <ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X50 9SerialNumber>=20 </CertificateReference>=20 </TrustResponse>=20 </EDIINTCertificateExchangeResponse>=20 =20 Changes from Previous Versions=20 =20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 24]=20 =0CDraft CEM for EDIINT February = 2005=20 =20 =20 B.1 Updates from Version 00=20 =20 . Updated security requirements in section 2.1, specifically in=20 regards to digital signatures.=20 . The XML element responseURL is now required. Modified section=20 3.1 and example messages in appendix accordingly.=20 . Certificates are exchanged within a full P7C cert chain. Section=20 2.3 reflects this.=20 . The XML element TrustChain is not longer necessary since the=20 entire cert chain is stored. Removed references in schema and=20 document.=20 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be=20 sent and that if this occurs, the action of the CEM Request=20 initiator is not defined. =20 . Updated the examples in Appendix B to reflect the current usage.=20 =20 =20 Meadors, Moberg Expires - August 2005 [Page 25]=20 =0C ------=_NextPart_000_0314_01C586B8.40E178F0--