idnits 2.17.1 draft-meadors-certificate-exchange-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2009) is 5330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3851' on line 357 == Unused Reference: 'RFC2119' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'PROFILE' is defined on line 1153, but no explicit reference was found in the text -- No information found for draft-meadors-ediint-feature-header - is the name correct? ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT CEM for EDIINT September 2009 3 Target Category: Informational K. Meadors 4 Internet-Draft Drummond Group Inc. 5 Document: draft-meadors-certificate-exchange-11.txt D. Moberg 6 Axway, Inc. 7 Expires: March 2010 September 1, 2009 9 Certificate Exchange Messaging for EDIINT 10 draft-meadors-certificate-exchange-11.txt 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Status of this Memo 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Any questions, comments, and reports of defects or ambiguities in 33 this specification may be sent to the mailing list for the EDIINT 34 working group of the IETF, using the address . 35 Requests to subscribe to the mailing list should be addressed to 36 . 38 Abstract 40 The EDIINT AS1, AS2 and AS3 message formats do not currently contain 41 any neutral provisions for transporting and exchanging trading 42 partner profiles or digital certificates. EDIINT Certificate Exchange 43 Messaging provides the format and means to effectively exchange 44 certificates for use within trading partner relationships. The 45 messaging consists of two types of messages, Request and Response, 46 which allow trading partners to communicate certificates, their 48 Draft CEM for EDIINT September 2009 50 intended usage and their acceptance through XML. Certificates can be 51 specified for use in digital signatures, data encryption or SSL/TLS 52 over HTTP (HTTPS). 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119. 60 Feedback Instructions 62 NOTE TO RFC EDITOR: This section should be removed by the RFC 63 editor prior to publication. 65 If you want to provide feedback on this draft, follow these 66 guidelines: 68 -Send feedback via e-mail to kyle@drummondgroup.com, with 69 "Certificate Exchange" in the Subject field. 71 -Be specific as to what section you are referring to, preferably 72 quoting the portion that needs modification, after which you state 73 your comments. 75 -If you are recommending some text to be replaced with your 76 suggested text, again, quote the section to be replaced, and be 77 clear on the section in question. 79 Table of Contents 81 1. Introduction...................................................3 82 1.1 Overview...................................................3 83 1.2 Terminology and Key Word Convention........................4 84 1.3 Certificate Lifecycle......................................5 85 1.4 Certificate Exchange Process...............................6 86 2. Message Processing.............................................7 87 2.1 Message Structure..........................................7 88 2.2 EDIINT Features Header.....................................9 89 2.3 Certificate Exchanging.....................................9 90 2.4 Certificate Implementation................................10 91 2.5 CEM Response..............................................12 92 3. CEM XML Schema Description....................................13 93 3.1 EDIINTCertificateExchangeRequest element..................13 94 3.2 EDIINTCertificateExchangeResponse element.................17 95 4. Use Case Scenario.............................................18 96 5. Profile Exchange Messaging....................................20 98 Draft CEM for EDIINT September 2009 100 6. Implementation Considerations.................................21 101 7. Future Considerations for CEM I-D.............................21 102 8. Security Considerations.......................................21 103 9. IANA Considerations...........................................22 104 10. References...................................................22 105 10.1 Normative References.....................................22 106 10.2 Informative References...................................23 107 11. Acknowledgments..............................................23 108 Author's Addresses...............................................23 109 Appendix.........................................................24 110 A.1 EDIINT Certificate Exchange XML Schema....................24 111 A.2 Example of EDIINT Certificate Exchange Request XML........27 112 A.3 Example of EDIINT Certificate Exchange Response XML.......28 113 Changes from Previous Versions...................................28 114 B.1 Updates from Version 00...................................28 115 B.2 Updates from Version 01...................................29 116 B.3 Updates from Version 02...................................29 117 B.4 Updates from Version 03...................................29 118 B.5 Updates from Version 04...................................29 119 B.6 Updates from Version 05...................................29 120 B.7 Updates from Version 06/07/08/09..........................29 122 1. 123 Introduction 125 1.1 126 Overview 128 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 129 numerous supply-chains was due in part to the security feature which 130 was provided. The security is not possible without the digital 131 certificates which enable it. To maintain the level of security 132 necessary to transmit business documentation, existing certificates 133 must occasionally be replaced and exchanged with newer ones. The 134 exchanging of digital certificates is unavoidable given how 135 certificates can expire or become compromised. Complicating this is 136 supply-chains which cannot afford to shutdown their business 137 transactions while trading partners laboriously upload new 138 certificates. Certificate exchange must be accomplished in a 139 reliable and seamless format so as not to affect ongoing business 140 transactions. 142 This document describes how EDIINT products may exchange public-key 143 certificates. Since EDIINT is built upon the security provided by 144 public-private key pairs, it is vital that implementers are able to 145 update their trading partners with new certificates as their old 146 certificates expire, become outdated or insecure. Certificate 147 Exchange Messaging (CEM) described here utilizes XML data to 148 exchange the certificate and provide information on its intended 149 usage and acceptance within the trading partner relationship. There 151 Draft CEM for EDIINT September 2009 153 are two types of CEM messages. The CEM Request which presents the 154 new certificate to be introduced into the trading partner relationship 155 and the CEM Response which is the recipient's response to the CEM 156 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 157 AS3 [AS3] message transports. However, it is possible to leverage CE 158 messaging through other transport standards besides EDIINT. 160 1.2 161 Terminology and Key Word Convention 163 [RFC4949] provides a glossary of Internet security terms, and several 164 of their definitions are listed here verbatim. However, some 165 definitions required for this document were undefined by [RFC4949] or 166 rewritten to better explain their specific use within CEM. 168 Certificate - A digital certificate contains the owner's (End 169 Entity's) name, the issuer's name, a serial number, expiration date, 170 and a copy of the owner's Public Key. The Public Key is used for 171 Encrypting messages and Verifying Signatures (verifying a signature 172 is also called Authentication). 174 Certificate Revocation List (CRL) - A data structure that enumerates 175 digital certificates that have been invalidated by their issuer prior 176 to when they were scheduled to expire. [RFC4949] 178 Certification Authority (CA) - An entity that issues digital 179 certificates (especially X.509 certificates) and vouches for the 180 binding between the data items in a certificate. [RFC4949] 182 CA Certificate - A certificate issued by a trusted certification 183 authority. CA certificates are not used to encrypt data but to sign 184 other certificates. CA certificates are signed by themselves, but are 185 not considered self-signed certificates for the purpose of this 186 document. 188 Certification Hierarchy - In this structure, one CA is the top CA, 189 the highest level of the hierarchy. The top CA may issue public-key 190 certificates to one or more additional CAs that form the second 191 highest level. Each of these CAs may issue certificates to more CAs 192 at the third highest level, and so on. The CAs at the second-lowest 193 of the hierarchy issue certificates only to non-CA entities, called 194 "end entities" that form the lowest level. Thus, all certification 195 paths begin at the top CA and descend through zero or more levels of 196 other CAs. All certificate users base path validations on the top 197 CA's public key. [RFC4949] 199 CEM Request - The EDIINT Certificate Exchange Messaging (CEM) Request 200 is one of two possible CEM messages. It presents a certificate to be 201 introduced into the trading partner relationship along with relevant 202 information on how it is to be implemented. 204 Draft CEM for EDIINT September 2009 206 CEM Response - The EDIINT Certificate Exchange Messaging (CEM) 207 Response is one of two possible CEM messages. It is the response to 208 the CEM Request indicating whether or not the end entity certificate 209 present in the CEM Request was accepted. 211 End Entity - A system entity that is the subject of a public-key 212 certificate and that is using, or is permitted and able to use, the 213 matching private key only for a purpose or purposes other than 214 signing a digital certificate; i.e., an entity that is not a CA. 215 [RFC4949] 217 End Entity Certificate - A certificate which is used to encrypt data 218 or authenticate a signature. (The private key associated with the 219 certificate is used to decrypt data or sign data). The certificate 220 may be self-signed or issued by a trusted certificate. 222 Intermediary Certificate - A certificate issued by a CA certificate 223 which itself issues another certificate (either intermediary or end 224 entity). Intermediary certificates are not used to encrypt data but 225 to sign other certificates. 227 Public Key - The publicly-disclosable component of a pair of 228 cryptographic keys used for asymmetric cryptography. [RFC4949] 230 Public Key Certificate - A digital certificate that binds a system 231 entity's identity to a public key value, and possibly to additional 232 data items. [RFC4949] 234 Self-signed Certificate - A certificate which is issued by itself 235 (both issuer and subject are the same) and is an End Entity 236 certificate. 238 1.3 239 Certificate Lifecycle 241 A certificate has five states. 243 1. Pending - Upon receiving a certificate from a trading partner, the 244 certificate is marked as Pending until a decision can be made to 245 trust it or if its validity period has not yet begun. 246 2. Rejected - If a Pending certificate is not trusted, it is 247 considered Rejected. 248 3. Accepted - Once a Pending certificate has been trusted, it is 249 considered Accepted. An Accepted certificate may be used in 250 secure transactions. 251 4. Expired - A certificate which is no longer valid because its 252 expiration date has passed. Expired certificates SHOULD be kept 253 in a certificate storehouse for decrypting and validating past 254 transactions. 256 Draft CEM for EDIINT September 2009 258 5. Revoked - A certificate which has been explicitly revoked by its 259 owner or the certificate authority. 261 1.4 262 Certificate Exchange Process 264 This section describes a process whereby a company can distribute 265 certificates to its partners, and the company and its partners can 266 put the certificates into use. Later sections describe the specific 267 CEM protocol, which is an implementation of this process. 269 The exchange process can be used even when CEM is not useable, for 270 example, when the transport protocols or installed software systems 271 do not support CEM. It is RECOMMENDED that this process be followed 272 in distributing certificates. 274 The company that owns the certificates initiates the process. For a 275 certificate that is to be used (by the partners) to encrypt messages, 276 the initiator first prepares his system to decrypt messages that are 277 encrypted with this certificate. The initiator must also be able to 278 decrypt messages using the old certificate. The initiator company 279 distributes the new certificates by some means. The distribution MUST 280 describe the purposes of the certificates and MAY contain a respond 281 by date, the date when the distributor expects to put the 282 certificates in use. The respond by date SHOULD be present for 283 certificates that are used to sign messages or to authenticate 284 TLS/SSL connections. 286 When a partner receives a certificate, the partner should 287 authenticate the distribution message by some means. (CEM provides 288 for automatic authentication. Partners can use manual methods, 289 either with or without CEM.) 291 When a partner receives a certificate for use in encrypting messages 292 and has authenticated the certificate, the partner SHOULD begin 293 using that certificate to encrypt messages. The initiator MUST be 294 prepared to receive messages encrypted with either the old or new 295 certificate. 297 When a partner receives a certificate for use in digitally signing 298 messages or for TLS/SSL authentication and has authenticated the 299 certificate, the partner MUST prepare his system to accept messages 300 that are signed or authenticated with the new certificate. The 301 partner MUST also accept messages signed or authenticated with the 302 old certificate. 304 The partner MAY return a response to the initiator, indicating that 305 the partner has accepted the new certificate and put it in use. The 307 Draft CEM for EDIINT September 2009 309 initiator can use these responses to track which partners are ready 310 to use the new certificate. 312 When the partner has sent a response indicating acceptance of the new 313 certificate, or when the respond by date has passed, the initiator 314 can begin using the new certificate to digitally sign messages or 315 authenticate TLS/SSL messages. The initiator MUST NOT sign or 316 authenticate messages with the new certificate until the partner has 317 accepted it or until the respond by date has passed. The initiator 318 MAY wait until the respond by date or until all partners have 319 accepted. The partners MUST accept messages signed or authenticated 320 with either the old or new certificate. 322 When the process is fully automated, it is not necessary to have a 323 specific time when both the initiator and partners switch to the new 324 certificate. 326 The initiator MUST be able to decrypt messages with both the old and 327 new certificates as soon as the new certificates are distributed. 328 The partners MUST be able to accept messages signed or TLS/SSL 329 authenticated with either the old or new certificates after they have 330 accepted the new certificate. The initiator SHOULD allow a 331 reasonable time after distributing a new signing or authenticating 332 certificate before putting it in use, so that partners have time to 333 authenticate the new certificate and prepare their systems for it. 335 For a certificate used to digitally sign messages or authenticate 336 TLS/SSL messages, there must be some way for the initiator to know 337 when partners are ready to receive the certificate. For example, this 338 may be a response from the partners, an explicit respond by date in 339 the initial distribution, an implied respond by date based on partner 340 agreements, or the expiration date of the old certificate. For a 341 certificate used to encrypt messages, the respond by date and 342 responses are less important, but responses may be useful to track 343 partners' acceptances. 345 2. 346 Message Processing 348 2.1 349 Message Structure 351 CEM messages use the underlying EDIINT transport, such as AS2, to 352 communicate information on the certificate, its intended use and its 353 acceptance. Both digital certificates and the XML data describing 354 their intended use are stored within a multipart/related MIME 355 envelope [RFC2387]. For the CEM Request message, the certificates are 356 stored in certificate chains through SMIME, certs-only MIME envelope 357 [3851], and processing information is XML data which is identified 359 Draft CEM for EDIINT September 2009 361 through the MIME content-type of application/ediint-cert- 362 exchange+xml. The format for a CEM Request message is as follows: 364 Various EDIINT headers 365 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 366 Content-Type: multipart/signed; micalg=sha1; 367 protocol="application/pkcs7-signature"; 368 boundary="--OUTER-BOUNDARY" 370 ----OUTER-BOUNDARY 371 Content-Type: multipart/related; type="application/ediint-cert- 372 exchange+xml"; boundary="--INNER-BOUNDARY" 374 ----INNER-BOUNDARY 375 Content-Type: application/ediint-cert-exchange+xml 376 Content-ID: <20040101-1.alpha@example.org> 378 [CEM XML data] 379 ----INNER-BOUNDARY 380 Content-Type: application/pkcs7-mime; smime-type=certs-only 381 Content-ID: <20040101-2.alpha@example.org> 383 [digital certificate] 384 ----INNER-BOUNDARY-- 386 ----OUTER-BOUNDARY 387 Content-Type: application/pkcs7-signature 389 [Digital Signature] 390 ----OUTER-BOUNDARY-- 392 One and only one MIME type of application/ediint-cert-exchange+xml 393 MUST be present in the multipart/related structure, and it MUST be 394 the root element. Multiple certs-only media types may be included, 395 but at least one MUST be present. A unique content-id header MUST be 396 present within each of the multipart structures. 398 For the CEM Response message, a multipart/related MIME structure is 399 also used. However, no certificates are present in a CEM Response, 400 and the multipart/related structure only contains one MIME type of 401 application/ediint-cert-exchange+xml. The format for a CEM Request 402 message is as follows: 404 Various EDIINT headers 405 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 406 Content-Type: multipart/signed; micalg=sha1; 407 protocol="application/pkcs7-signature"; 408 boundary="--OUTER-BOUNDARY" 410 Draft CEM for EDIINT September 2009 412 ----OUTER-BOUNDARY 413 Content-Type: multipart/related; type="application/ediint-cert- 414 exchange+xml"; boundary="--INNER-BOUNDARY" 416 ----INNER-BOUNDARY 417 Content-Type: application/ediint-cert-exchange+xml 418 Content-ID: <20040201-1.alpha@example.org> 420 [CEM XML data] 421 ----INNER-BOUNDARY-- 423 ----OUTER-BOUNDARY 424 Content-Type: application/pkcs7-signature 426 [Digital Signature] 427 ----OUTER-BOUNDARY-- 429 If possible, both the CEM Request and CEM Response message SHOULD be 430 signed. Applying digital signatures will allow for automatic exchange 431 based on a previous trust relationship. However, it may not be 432 possible in the initial exchange of a new trading partner. If a CEM 433 message is signed, the signing certificate MUST be included in the 434 digital signature. Extra security such as applying data encryption or 435 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and 436 SHOULD request a signed MDN. The MDN can be either synchronous or 437 asynchronous. All necessary headers MUST be applied to the message 438 per the underlying transport standard. 440 2.2 441 EDIINT Features Header 443 To indicate support for CEM, an EDIINT application MUST use the 444 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates 445 the instance application can support various features, such as 446 certification exchange. The header is present in all messages from 447 the instance application, not just those which feature certification 448 exchange. 450 For applications implementing certification exchange, the CEM- 451 Feature-Name MUST be used within the EDIINT Features header: 453 CEM-Feature-Name = "CEM" 455 An example of the EDIINT Features header in a CEM Message: 457 EDIINT-Features: CEM 459 2.3 460 Certificate Exchanging 462 Draft CEM for EDIINT September 2009 464 After obtaining the desired certificate, the initiator of the 465 certificate exchange transmits the end-entity certificate in the CEM 466 Request message. If the end-entity certificate is not self-signed, 467 then the CA certificate and any other certificates needed to create 468 the chain of trust for the end-entity certificate MUST be included in 469 the CEM Request message. Multiple end-entity certificates MAY also be 470 present. 472 The entire certificate trust chain is stored in a BER encoded P7C 473 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- 474 only MIME envelope which is then stored in a single part of the 475 multipart/related structure. Each P7C trust chain MUST include a 476 single end-entity certificate and its trust authorities. No other 477 certificates are to be part of this chain. The number of P7C trust 478 chains in a CEM Request message MUST be equal to the number of end- 479 entity certificates being communicated in the CEM XML document. 480 If different end-entity certificates have common trust authorities' 481 certificates, each P7C cert chain still MUST include each certificate 482 necessary to create a trust anchor. Thus, if a recipient can not 483 create a trust relationship from the P7C cert chain, it MAY reject 484 the end-entity certificate in the CEM Request. 486 End-entity certificates are referenced and identified in the XML data 487 by their content-id used in the multipart/related structure. 488 Information on how the certificate is to be used, or certificate 489 usage, by the receiving user agent and other related information is 490 found in the XML data. A certificate can be used for a single 491 function, like digital signatures, or used for multiple functions, 492 such as both digital signatures and data encryption. If a certificate 493 is intended for multiple usages, such as for both digital signatures 494 and data encryption, the certificate MUST be listed only once in the 495 CEM Request message and its multiple usage listed through the 496 CertUsage XML element. 498 Upon receipt of the CEM Request, the recipient trading partner 499 processes the transport message as normal and returns the MDN. The 500 recipient MAY parse the CEM XML data prior to returning the MDN. If 501 the XML is not well-formed and can not be interpreted, the UA MAY 502 return the MDN with the error disposition modifier of "error: 503 unexpected-processing-error". The returned MDN does not provide 504 information on the acceptance of the certificate(s) being exchanged. 505 An UA who receives an MDN with an error disposition modifier MUST 506 consider the CEM Message was not understood and needs to be corrected 507 and retransmitted. 509 2.4 510 Certificate Implementation 512 Draft CEM for EDIINT September 2009 514 The new certificate is considered to be in the Pending state for the 515 recipient who MUST decide whether to accept the certificate as 516 trustworthy. This decision is arbitrary and left to each individual 517 trading partner. Upon accepting the certificate, it is to be 518 considered an Accepted certificate within the trading partner 519 relationship. If the certificate is not accepted, it is considered 520 Rejected. 522 When a certificate is intended for use in data encryption, the 523 initiator MUST consider the certificate to be Accepted and be 524 prepared for its trading partner to begin using the certificate upon 525 generating the CEM Request message. After a recipient generates a 526 positive CEM Response message for a certificate, the recipient MUST 527 immediately begin using the certificate in trading with the initiator 528 of the request. The recipient MAY apply encryption to the CEM 529 Response message using the new Accepted certificate or MAY apply 530 encryption to the CEM Response message using the previously Accepted 531 encryption certificate. 533 When a certificate is intended for use in digital signatures or 534 TLS/SSL authentication, the initiator MUST NOT use the certificate 535 until the recipient trading partner generates a CEM Response 536 accepting the certificate or the respond by date, which is listed in 537 the RespondByDate XML element. The initiator MAY use the certificate 538 after the respond by date, regardless of whether the partner has 539 accepted it or not. The certificate used for the digital signature of 540 the CEM Request message MUST be the one which is currently Accepted 541 within the trading partner relationship. 543 Since implementers of EDIINT often use the same certificate with 544 multiple trading partners, implementers of CEM MUST be able to keep 545 both the old and new certificates as Accepted. If the initiator has 546 generated a CEM Request and exchanged a new encryption certificate to 547 multiple trading partners, it MUST be able to accept encrypted data 548 which uses either the older, existing encryption certificate or the 549 newly exchanged encryption certificate. Likewise, a recipient of a 550 CEM Request MUST be able to authenticate digital signatures using 551 either the new or old certificates, since the initiator may not be 552 able to switch certificates until all trading partners accept the new 553 certificate. Similar provisions MUST be made for certificates 554 intended for TLS/SSL server and client authentication. Revoking a 555 certificate MUST be done outside of CEM. 557 If a CEM Request message contains a certificate which is currently 558 Accepted and has the identical usage for the certificate that has 559 been Accepted, the recipient MUST NOT reject the duplicate 560 certificate but MUST respond with a CEM Response message indicating 561 the certificate has been accepted. For example, if Certificate A is 562 currently Accepted as the encryption certificate for a user agent, 564 Draft CEM for EDIINT September 2009 566 any CEM Request message containing Certificate A with the usage as 567 encryption only MUST be accepted by an existing trading partner. This 568 situation may be necessary for an implementation intending to verify 569 its current trading partner certificate. 571 If two trading partners utilize multiple EDIINT protocols for 572 trading, such as AS2 for a primary transport and AS1 as the backup 573 transport, it is dependent upon implementation and trading partner 574 agreement how CEM messages are sent and which transports the 575 exchanged certificates affect. 577 2.5 578 CEM Response 580 The CEM Response message is a multipart/related envelope which 581 contains the CEM XML under the MIME type of application/ediint-cert- 582 exchange+xml. If a requestId is used in a CEM Request, then the 583 requestId MUST be present in the CEM Response with the same value. 584 The requestId allows for the CEM Response to be matched to the CEM 585 Request. If the CEM Request contains multiple TrustRequest elements 586 and the corresponding TrustResponse elements are returned in multiple 587 CEM Response messages, each CEM Response message MUST use the same 588 requestId from the originating CEM Request message. This is critical 589 when multiple CEM Requests are sent with the same certificate and the 590 CEM Response can not be matched solely through the TrustResponse 591 elements. 593 A TrustResponse XML element provides information needed to match the 594 end-entity certificate sent in an earlier CEM Request and indicate if 595 the certificate was accepted or rejected by the recipient. The 596 CertificateReference in a TrustResponse matches the 597 CertificateIdentifier value for the end-entity certificate in the CEM 598 Request. CertStatus indicates if the certificate was accepted or 599 rejected. If a CEM Request is received, the recipient MUST respond 600 with a CEM Response message indicating if the certificate is Accepted 601 or Rejected. More information about the XML attributes and value for 602 CEM Response can be found in 3.2. 604 If the certificate in the CEM Request message contains multiple 605 usages, such as for both digital signature and data encryption, only 606 a single TrustResponse is needed for that certificate. The CertStatus 607 value in the TrustResponse is the response for both usages of the 608 certificate. A recipient MUST NOT choose to accept the certificate 609 for one specified use and not the other. 611 If multiple end-entity certificates were included within the CEM 612 Request, the recipient MAY generate individual CEM Response messages 613 for each certificate or the recipient MAY consolidate the 614 TrustResponse for multiple certificates into one CEM Response 615 message. A CEM Response may contain multiple TrustResponse elements 617 Draft CEM for EDIINT September 2009 619 for different certificates but MUST NOT contain two or more 620 TrustResponses for the same certificate. 622 If a second TrustResponse is received in a different message matching 623 the same certificate as that of an earlier TrustRespnse but the 624 CertStatus has a different value than the other, the originator MAY 625 accept the CertStatus value in the most recent TrustResponse but MAY 626 choose to ignore it. If the CertStatus in both TrustResponses are the 627 same, the originator should disregard the second TrustResponse. 629 If the originator receives a CEM Response message which violates the 630 rules listed above or is invalid in any way, the originator MAY 631 reject the message entirely but MUST return an MDN if requested. 633 3. 634 CEM XML Schema Description 636 The CEM schema has two top-level elements, 637 EDIINTCertificateExchangeRequest and 638 EDIINTCertificateExchangeResponse. The 639 EDIINTCertificateExchangeRequest element is present only in the CEM 640 Request message, and the EDIINTCertificateExchangeResponse is present 641 only in the CEM Response message. All other elements nest directly or 642 indirectly from these. CEM XML data must be well-formed and valid 643 relative to the CEM XML Schema. Please refer to the appendix for the 644 actual schema document. 646 3.1 647 EDIINTCertificateExchangeRequest element 649 EDIINTCertificateExchangeRequest contains element TradingPartnerInfo, 650 which can only appear once, and TrustRequest, which may be present 651 multiple times. TrustRequest contains information on a certificate 652 and its intended usage. TradingPartnerInfo exists to provide 653 information on the publication of the CEM Request message since 654 processing of the XML data may occur apart from the handling of the 655 accompanying transport message, for example the AS2 request. 657 658 659 660 661 664 666 667 670 Draft CEM for EDIINT September 2009 672 673 674 676 EDIINTCertificateExchangeRequest also contains the attribute 677 requestId. RequestId uniquely identifies each CEM Request message. 678 Its value MUST be between 1 and 255 characters. The requestId is 679 returned in the CEM Response message to assist the UA in matching the 680 CEM Response with the CEM Request. 682 683 684 685 686 687 689 An optional Extension element is also present along with the 690 anyAttribute attribute. They exist to provide future extendibility 691 for new features which may be developed but not yet defined within 692 CEM. They are present in several locations in the schema for this 693 future extendibility. 695 696 697 698 700 701 702 704 TradingPartnerInfo identifies the entity that created the CEM message 705 through the nested Name element. Both the qualifier attribute and the 706 element value of Name follow mandatory naming conventions. The 707 qualifier attribute is to be the transport standard utilized. For 708 example, "AS1", "AS2" or "AS3". The value of the Name element is the 709 same value in the From header utilized by the transport. For AS2 and 710 AS3, this is the value in the AS2-From and AS3-From headers, 711 respectively. For AS1, this is the value of the From header. If other 712 transports besides AS1, AS2, AS3 are used, the same naming convention 713 SHOULD be followed. 715 MessageOriginated is included in TradingPartnerInfo to identify the 716 time and date the message was created. The MessageOriginated date and 717 time values MUST follow XML standard dateTime type syntax and be 718 listed to at least the nearest second and expressed in local time 719 with UTC offset. For example, a message originating from the US 720 Eastern Standard timezone would use 2005-03-01T14:05:00-05:00. 722 Draft CEM for EDIINT September 2009 724 725 726 727 728 729 730 731 733 734 735 736 737 738 740 741 742 743 745 The TrustRequest element contains the EndEntity, CertUsage, 746 RespondByDate and ResponseURL elements. The required EndEntity 747 element is found only once in a TrustRequest element and contains the 748 content-id reference to the end-entity certificate being exchanged. 750 751 752 753 754 755 756 758 759 760 762 EndEntity contains the nested elements of CertificateIdentifier and 763 CertificateContentID. CertificateContentID is a string element which 764 references the content-id of the multipart/related structure where 765 the certificate is stored. CertificateIdentifier comes from the XML 766 Signature schema namespace [XML-DSIG]. 768 769 770 773 Draft CEM for EDIINT September 2009 775 776 778 779 780 782 CertificateIdentifier contains the string element X509IssuerName and 783 the integer element X509SerialNumber. X509SerialNumber is the 784 assigned serial number of the end entity certificate as it is listed. 785 X509IssuerName contains the issuer name information of the end-entity 786 certificate, such as common name, organization, etc. This information 787 MUST be described in a string format per the rules of RFC 4514 788 [RFC4514]. This results in the attributes within the Issuer Name to 789 be listed with their attribute type followed by an "=" and the 790 attribute value. Each attribute type and value are separated by a "," 791 and any escape characters in the value are preceded by a "\". Refer 792 to the appendix and the sample CEM Request message for an example of 793 the X509IssuerName. 795 796 797 798 799 800 802 CertUsage is an unbounded element which contains enumerated values on 803 how the exchanged certificate is to be used. There are enumerated 804 values for SMIME digital signatures (digitalSignature), SMIME data 805 encryption (keyEncipherment), the server certificate used in TLS 806 transport encryption (tlsServer) and the client certificate used in 807 TLS transport encryption (tlsClient). While the element is unbounded, 808 CertUsage only has a potential number of four occurrences due to the 809 limit of the enumerated values. 811 812 813 814 815 816 817 818 819 821 RespondByDate is a required element of the XML standard dateTime type 822 expressed in local time with UTC offset, which provides information 823 on when the certificate should be trusted, inserted into the trading 825 Draft CEM for EDIINT September 2009 827 partner relationship and responded to by a CEM Response message. If 828 the certificate can not be trusted or inserted into the trading 829 partner relationship, the CEM Response message should still be 830 returned by the date indicated. 832 834 ResponseURL is an element which indicates where the CEM Response 835 message should be sent. This value takes precedence over the existing 836 inbound URL of the current trading partner relationship. The Response 837 MUST use the same transport protocol (AS1, AS2, or AS3) as the 838 Request. 839 841 3.2 842 EDIINTCertificateExchangeResponse element 844 EDIINTCertificateExchangeResponse contains the two elements 845 TradingPartnerInfo and TrustResponse and the attribute requestId. 846 TradingPartnerInfo, which is also found in 847 EDIINTCertificateExchangeRequest, describes the trading partner 848 generating this response message. TrustResponse provides information 849 on the acceptance of a previously sent end entity certificate. There 850 can be multiple TrustResponse elements within an 851 EDIINTCertificateExchangeResponse. The requestId is the same value 852 from a previously sent CEM Request message. The requestId from the 853 CEM Response is matched up with the CEM Request. 855 856 857 858 859 862 864 865 867 868 869 871 872 873 874 875 878 Draft CEM for EDIINT September 2009 880 882 883 884 886 A TrustResponse element identifies a certificate which has been 887 previously exchanged within the trading partner relationship through 888 a CEM Request and now has been either accepted or rejected by the 889 partner. The CertificateReference element is of the same type as the 890 CertificateIdentifier element. A CertificateReference element in a 891 CEM Response MUST be identical to its CertificateIdentifier 892 counterpart in the associated CEM Request since they identify the 893 same certificate in question. 895 The required element CertStatus has the enumerated values of 896 "Accepted" or "Rejected". "Accepted" indicates the certificate was 897 trusted by the trading partner and is now ready for use within the 898 trading partner relationship, and "Rejected" indicates the 899 certificate is not trusted by the trading partner nor can it be 900 currently used with the trading partner relationship. If the value of 901 "Rejected" is chosen, the optional string element ReasonForRejection 902 may be included. If present, ReasonForRejection should contain a 903 brief description of why the certificate was not accepted. Since the 904 value for this element is not enumerated but open, it MUST be 905 interpreted through human means. 907 908 909 910 911 912 913 914 916 4. 917 Use Case Scenario 919 This scenario illustrates how the CEM Request and CEM Response 920 messages described in Section 2 and 3 can be used to exchange 921 certificates. The scenario is only illustrative and any differences 922 between it and the rules above should defer to the rules in Section 2 923 and 3. 925 Two trading partners, Alpha Arrows and Bravo Bows, have an 926 established trading partner relationship using AS2. Alpha Arrows is 927 using a single certificate, CertA, for both digital signatures and 928 data encryption. Alpha Arrows wants to issue a new certificate, 929 CertB, for digital signatures but keep CertA for data encryption. 931 Draft CEM for EDIINT September 2009 933 Bravo Bows is using one certificate, Cert1, for digital signatures 934 and another certificate, Cert2, for data encryption. Bravo Bows wants 935 to introduce a new certificate, Cert3, for digital signature and a 936 new certificate, Cert4, for data encryption. 938 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only 939 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows 940 immediately returns the MDN but must make an internal security 941 decision before accepting CertB. 943 2. While waiting for a CEM Response, Alpha Arrows continues to send 944 AS2 messages to Bravo Bows which have been signed using CertA. The 945 messages originating from Bravo Bows are encrypted using CertA. 947 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus 948 of "Accepted" for CertB. Upon receipt, an MDN is returned which is 949 signed using CertA. Bravo Bows MUST be able to accept the MDN if it 950 has a digital signature from either CertA or CertB as Alpha Arrows 951 may not be able to switch certificates simply upon receipt of the CEM 952 Response message without parsing the XML payload. Also, Alpha Arrows 953 may need to wait for CEM Responses from other trading partners before 954 switching to the new CertB. However, as soon as possible, Alpha 955 Arrows should use CertB exclusively for digital signatures. 957 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both 958 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are 959 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows 960 returns an MDN immediately. Bravo Bows is now prepared to receive any 961 inbound messages encrypted by either Cert2 or Cert4, but all its 962 digital signatures are still done through Cert1. 964 5. Eventually, Alpha Arrows returns a single CEM Response message. It 965 contains two TrustResponse elements: one for Cert3 and another for 966 Cert4. The CertStatus for Cert3 is "Rejected" with the 967 ReasonForRejection field present and populated with the string 968 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted." 969 Bravo Bows returns the MDN signed through Cert1. 971 6. Immediately after this, an AS2 message is received from Alpha 972 Arrows which is encrypted using Cert4, and Bravo Bows is able to 973 decrypt the message successfully. Because Alpha Arrows rejected 974 Cert3, Bravo Bows is only using Cert1 for digital signatures and 975 returns the MDN signed with Cert1. 977 7. After creating a new certificate, Cert5, which corrects the 978 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request. 980 Draft CEM for EDIINT September 2009 982 8. Shortly after this, Alpha Arrows sends a CEM Response message for 983 Cert5. It contains a CertStatus of "Accepted". This CEM Response 984 message was encrypted using Cert4, but Bravo Bows was prepared for 985 encryption from either Cert2 or Cert4. The message is processed and a 986 good MDN is returned signed with Cert1. While, Bravo Bows can now 987 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows 988 should use Cert5 exclusively as soon as possible. 990 5. 991 Profile Exchange Messaging 993 CEM provides the means to exchange certificates among trading 994 partners. However, other profile information, such as URLs and 995 preferred security settings, is needed to create a trading partner 996 relationship. A future standard is needed to describe profile 997 descriptions and how they will be exchanged. The format for this 998 profile attachment is not defined in this specification but is 999 planned for a future document. It will build upon the existing CEM 1000 protocol with profile information stored with XML data. Both 1001 certificate and profile description information will be placed into a 1002 multipart/related [RFC2387] body part entity. A possible format for a 1003 profile description message is as follows: 1005 Various EDIINT headers 1006 EDIINT-Features: profile-exchange 1007 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 1008 Disposition-Notification-Options: signed-receipt-protocol=optional, 1009 pkcs7-signature; signed-receipt-micalg=optional, sha1 1010 Content-Type: multipart/signed; micalg=sha1; 1011 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 1013 ----BOUNDARY1 1014 Content-Type: multipart/related; 1015 start=""; 1016 type="application/ediint-cert-exchange+xml"; 1017 boundary="--BOUNDARY2" 1019 ----BOUNDARY2 1020 Content-Type: application/ediint-cert-exchange+xml 1021 Content-ID: 1023 [CEM XML data] 1024 ----BOUNDARY2 1025 [Profile information attachment] 1026 ----BOUNDARY2-- 1027 ----BOUNDARY1 1029 Content-Type: application/pkcs7-signature 1031 Draft CEM for EDIINT September 2009 1033 [Digital Signature] 1034 ----BOUNDARY1-- 1036 6. 1037 Implementation Considerations 1039 This section contains various points to explain practical 1040 implementation considerations. 1042 * If the EDIINT transport message carrying a CEM Request or CEM 1043 Response fails resulting in a negative MDN, the CEM message, its 1044 contents and instructions are to be ignored. The User Agent receiving 1045 the negative MDN is to consider the CEM message to be ignored and 1046 retransmit as needed. 1048 * While a single end-entity certificate can be only be used once in a 1049 single CEM Request message, the same certificate can be sent multiple 1050 times in multiple CEM Request messages. The requestId is used for 1051 matching the CEM Request and CEM Response messages. 1053 * Certificate usage is cumulative. Thus, if a User Agent receives a 1054 valid CEM Request message with Certificate A with certUsage set to 1055 digitalSignature and then a second valid CEM Request message with 1056 Certificate A with certUsage set to keyEncipherment, then the User 1057 Agent MUST configure the certificate to be used both for 1058 digitalSignature and keyEncipherment. As well, if at a later time a 1059 valid CEM Request message is received with Certificate A with 1060 certUsage set only to digitalSignature, Certificate A is still valid 1061 for keyEncipherment. 1063 7. 1064 Future Considerations for CEM I-D 1065 This section contains ideas for consideration in future versions of 1066 CEM and addressed in the future. If deemed necessary, they will be 1067 added into the I-D else they will be removed. This section will be 1068 removed prior to RFC submission. 1070 8. 1071 Security Considerations 1073 Certificate exchange is safe for transmitting. However, implementers 1074 SHOULD verify the received certificate to determine if it is truly 1075 from the stated originator through out-of-band means or whenever the 1076 request is not signed. 1078 Draft CEM for EDIINT September 2009 1080 9. 1081 IANA Considerations 1083 MIME Media type name: Application 1085 MIME subtype name: EDIINT-cert-exchange+xml 1087 Required parameters: None 1089 Optional parameters: This parameter has identical semantics to the 1090 charset parameter of the "application/xml" media type as specified 1091 in [RFC3023]. 1093 Encoding considerations: Identical to those of "application/xml" as 1094 described in [RFC3023], section 3.2. 1096 Security considerations: See section 6. 1098 Interoperability Considerations: See section 2.2 1100 Published specification: This document. 1102 Applications which use this media type: EDIINT applications, such as 1103 AS1, AS2 and AS3 implementations. 1105 Additional Information: None 1107 Intended Usage: Common 1109 Author/Change controller: See Author's section of this document. 1111 10. 1112 References 1113 10.1 1114 Normative References 1116 [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data 1117 Interchange over the Internet using SMTP", T. Harding, R. 1118 Drummond, C. Shih, 2002. 1120 [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data 1121 Interchange over the Internet using HTTP", D. Moberg, R. 1122 Drummond, 2005. 1124 [AS3] RFC 4823 "FTP Transport for Secure Peer-to-Peer", T. Harding, 1125 R. Scott, 2007. 1127 [EDIINT-FEATURE] draft-meadors-ediint-feature-header-05.txt "Feature 1128 Header for EDI-INT", K. Meadors, 2009. 1130 Draft CEM for EDIINT September 2009 1132 [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement 1133 Levels", S.Bradner, March 1997. 1135 [RFC4514] RFC4514 "Lightweight Directory Access Protocol (LDAP): 1136 String Representation of Distinguished Names", K. Zeilenga 1137 June 2006. 1139 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 1140 Levinson, August 1998. 1142 [RFC4949] RFC4949 "Internet Security Glossary", R. Shirley, August 2007. 1144 [RFC3023] RFC3023 "XML Media Types", M. Murata, October 2001. 1146 [XML-DSIG] RFC3275 "XML-Signature Syntax and Processing", D. 1147 Eastlake, March 2002. 1149 [X.520] ITU-T Recommendation X.520: Information Technology - Open 1150 Systems Interconnection - The Directory: Selected Attribute 1151 Types, 1993. 1153 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1154 X.509 Public Key Infrastructure: Certificate and CRL Profile", 1155 RFC 3280, April 2002. 1157 10.2 1158 Informative References 1160 11. 1161 Acknowledgments 1163 The authors wish to extend gratitude to the ecGIF sub-committee 1164 within the GS1 organization from which this effort began. Many have 1165 contributed to the development of this specification, but some 1166 deserve special recognition. John Duker who chaired the sub-committee 1167 and provided valuable editing. John Koehring with his work on the 1168 reference ID and shared important insights on implementation. Aaron 1169 Gomez in the coordinating of vendors testing CEM. Richard Bigelow who 1170 greatly assisted development of the ideas presented, and Debra Petta 1171 for her review and comments. 1173 Author's Addresses 1175 Kyle Meadors 1176 Drummond Group Inc. 1177 180 Marseille Dr. 1178 Maumelle, AR 72113 USA 1179 Email: kyle@drummondgroup.com 1181 Draft CEM for EDIINT September 2009 1183 Dale Moberg 1184 Axway, Inc. 1185 8388 E. Hartford Drive, Suite 100 1186 Scottsdale, AZ 85255 USA 1187 Email: dmoberg@us.axway.com 1189 Copyright (c) 2009 IETF Trust and the persons identified as the document 1190 authors. All rights reserved. 1192 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 1193 Relating to IETF Documents in effect on the date of publication of this 1194 document (http://trustee.ietf.org/license-info). Please review these 1195 documents carefully, as they describe your rights and restrictions with 1196 respect to this document. 1198 All IETF Documents and the information contained therein are provided on 1199 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1200 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 1201 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1202 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1203 THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1204 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1206 Appendix 1208 A.1 EDIINT Certificate Exchange XML Schema 1210 1211 1217 1219 1220 1221 1222 1223 1225 1227 1228 1230 1231 1233 Draft CEM for EDIINT September 2009 1235 1236 1237 1238 1239 1240 1242 1244 1245 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1259 1260 1261 1262 1263 1264 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1285 Draft CEM for EDIINT September 2009 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1302 1303 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1316 1317 1318 1319 1320 1321 1322 1323 1325 1327 1328 1329 1330 1331 1332 1333 1335 1337 Draft CEM for EDIINT September 2009 1339 1340 1341 1343 A.2 Example of EDIINT Certificate Exchange Request XML 1345 1346 1351 1352 DGI_Test_CEM 1353 1354 2005-08-30T00:30:00-05:00 1355 1356 1357 keyEncipherment 1358 digitalSignature 1359 2005-09-30T12:00:00-05:00 1360 http://10.1.1.1/as2 1361 1362 1363 CN=Cleo- 1364 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1365 Worth,S=Texas,C=US 1366 9659684611094873474886 1367 1368 1369 SignEncCert-Example_vs02@example.org 1370 1371 1372 1373 tlsServer 1374 2005-09-30T12:00:00-05:00 1375 http://10.1.1.1/as2 1376 1377 1378 CN=VeriSign Class 1 CA Individual 1379 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1380 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1381 Inc. 1382 2673611014597817669550861744279966682 1384 1385 1386 SSLCert-Example_vs02@example.org 1387 1389 Draft CEM for EDIINT September 2009 1391 1392 1394 A.3 Example of EDIINT Certificate Exchange Response XML 1396 1397 1402 1403 DGI_Test_CEM_Trading_Partner 1404 1405 2005-08-31T00:21:00-05:00 1406 1407 1408 Accepted 1409 1410 CN=Cleo- 1411 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1412 Worth,S=Texas,C=US 1413 9659684611094873474886 1414 1415 1416 1417 Accepted 1418 1419 CN=VeriSign Class 1 CA Individual 1420 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1421 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1422 Inc. 1423 2673611014597817669550861744279966682 1425 1426 1427 1429 Changes from Previous Versions 1431 B.1 Updates from Version 00 1433 . Updated security requirements in section 2.1, specifically in 1434 regards to digital signatures. 1435 . The XML element responseURL is now required. Modified section 1436 3.1 and example messages in appendix accordingly. 1437 . Certificates are exchanged within a full P7C cert chain. Section 1438 2.3 reflects this. 1440 Draft CEM for EDIINT September 2009 1442 . The XML element TrustChain is not longer necessary since the 1443 entire cert chain is stored. Removed references in schema and 1444 document. 1445 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be 1446 sent and that if this occurs, the action of the CEM Request 1447 initiator is not defined. 1448 . Updated the examples in Appendix B to reflect the current usage. 1450 B.2 Updates from Version 01 1452 . Added information for handling different scenarios with CEM 1453 Response message. 1454 . Rewrote use case scenarios. 1455 . Added the EDIINT Features header information. 1457 B.3 Updates from Version 02 1459 . Modified use of SSL certificates to match real-world needs. 1460 . Modified schema in changing namespace value and removed schema 1461 location. 1462 . Added statement that CEM XML must be well-formed and valid to 1463 schema. 1464 . Modified Use Case to correct an error and improve clarity. 1465 . Added section 1.4 to describe CEM process. 1467 B.4 Updates from Version 03 1468 . None. Update done because vs03 expired. 1470 B.5 Updates from Version 04 1471 . Clarified requirement of using multipart/related for CEM 1472 Response. 1473 . Added sections on Implementation Considerations and Future 1474 Implementation. 1475 . Modified schema to allow future extensions. 1476 . Changed requirements on qualifier attribute in the Name 1477 element. 1478 . Changed functionality to allow error MDN to be returned when 1479 CEM XML can not be parsed. 1481 B.6 Updates from Version 05 1482 . Added requestId to CEM. 1483 . Removed normative reference to RFC 3821. 1485 B.7 Updates from Version 06/07/08/09/10 1486 . None. Updated for 6-month I-D expiration.