idnits 2.17.1 draft-meadors-certificate-exchange-10.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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-meadors-certificate-exchange-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-meadors-certificate-exchange-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-meadors-certificate-exchange-', but the file name used is 'draft-meadors-certificate-exchange-10' == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 7 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 == Line 1137 has weird spacing: '...ication of th...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 2009) is 5488 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3851' on line 339 == Missing Reference: 'EDIINT-FEATURE' is mentioned on line 421, but not defined == Unused Reference: 'EDIINT FEATURE' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'PROFILE' is defined on line 1100, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-ediint-as3 is -04, but you're referring to -05. ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-as3 (ref. 'AS3') -- No information found for draft-meadors-ediint-feature-header - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EDIINT FEATURE' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) Summary: 9 errors (**), 1 flaw (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Private K. Meadors 2 Internet-Draft Drummond Group Inc. 3 Document: draft-meadors-certificate-exchange- D. Moberg 4 10.txt Axway, Inc. 5 Expires: October 2009 April 2009 7 Certificate Exchange Messaging for EDIINT 8 draft-meadors-certificate-exchange-10.txt 10 This Internet-Draft is submitted to IETF in full conformance with 11 the provisions of BCP 78 and BCP 79. 13 Status of this Memo 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Any questions, comments, and reports of defects or ambiguities in 31 this specification may be sent to the mailing list for the EDIINT 32 working group of the IETF, using the address . 33 Requests to subscribe to the mailing list should be addressed to 34 . 36 Abstract 38 The EDIINT AS1, AS2 and AS3 message formats do not currently contain 39 any neutral provisions for transporting and exchanging trading 40 partner profiles or digital certificates. EDIINT Certificate Exchange 41 Messaging provides the format and means to effectively exchange 42 certificates for use within trading partner relationships. The 43 messaging consists of two types of messages, Request and Response, 44 which allow trading partners to communicate certificates, their 45 intended usage and their acceptance through XML. Certificates can be 46 specified for use in digital signatures, data encryption or SSL/TLS 47 over HTTP (HTTPS). 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Feedback Instructions 57 NOTE TO RFC EDITOR: This section should be removed by the RFC editor 58 prior to publication. 60 If you want to provide feedback on this draft, follow these 61 guidelines: 63 -Send feedback via e-mail to kyle@drummondgroup.com, with 64 "Certificate Exchange" in the Subject field. 66 -Be specific as to what section you are referring to, preferably 67 quoting the portion that needs modification, after which you state 68 your comments. 70 -If you are recommending some text to be replaced with your suggested 71 text, again, quote the section to be replaced, and be clear on the 72 section in question. 74 Table of Contents 76 1. Introduction...................................................3 77 1.1 Overview...................................................3 78 1.2 Terminology and Key Word Convention........................4 79 1.3 Certificate Lifecycle......................................5 80 1.4 Certificate Exchange Process...............................6 81 2. Message Processing.............................................7 82 2.1 Message Structure..........................................7 83 2.2 EDIINT Features Header.....................................9 84 2.3 Certificate Exchanging.....................................9 85 2.4 Certificate Implementation................................10 86 2.5 CEM Response..............................................12 87 3. CEM XML Schema Description....................................13 88 3.1 EDIINTCertificateExchangeRequest element..................13 89 3.2 EDIINTCertificateExchangeResponse element.................17 90 4. Use Case Scenario.............................................18 91 5. Profile Exchange Messaging....................................20 92 6. Implementation Considerations.................................21 93 7. Future Considerations for CEM I-D.............................21 94 8. Security Considerations.......................................21 95 9. IANA Considerations...........................................22 96 10. References...................................................22 97 10.1 Normative References.....................................22 98 10.2 Informative References...................................23 99 11. Acknowledgments..............................................23 100 Author's Addresses...............................................23 101 Appendix.........................................................24 102 A.1 EDIINT Certificate Exchange XML Schema....................24 103 A.2 Example of EDIINT Certificate Exchange Request XML........27 104 A.3 Example of EDIINT Certificate Exchange Response XML.......28 105 Changes from Previous Versions...................................28 106 B.1 Updates from Version 00...................................28 107 B.2 Updates from Version 01...................................29 108 B.3 Updates from Version 02...................................29 109 B.4 Updates from Version 03...................................29 110 B.5 Updates from Version 04...................................29 111 B.6 Updates from Version 05...................................29 112 B.7 Updates from Version 06/07/08/09..........................29 114 1. 115 Introduction 117 1.1 118 Overview 120 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 121 numerous supply-chains was due in part to the security feature which 122 was provided. The security is not possible without the digital 123 certificates which enable it. To maintain the level of security 124 necessary to transmit business documentation, existing certificates 125 must occasionally be replaced and exchanged with newer ones. The 126 exchanging of digital certificates is unavoidable given how 127 certificates can expire or become compromised. Complicating this is 128 supply-chains which cannot afford to shutdown their business 129 transactions while trading partners laboriously upload new 130 certificates. Certificate exchange must be accomplished in a reliable 131 and seamless format so as not to affect ongoing business 132 transactions. 134 This document describes how EDIINT products may exchange public-key 135 certificates. Since EDIINT is built upon the security provided by 136 public-private key pairs, it is vital that implementers are able to 137 update their trading partners with new certificates as their old 138 certificates expire, become outdated or insecure. Certificate 139 Exchange Messaging (CEM) described here utilizes XML data to exchange 140 the certificate and provide information on its intended usage and 141 acceptance within the trading partner relationship. There are two 142 types of CEM messages. The CEM Request which presents the new 143 certificate to be introduced into the trading partner relationship 144 and the CEM Response which is the recipient's response to the CEM 145 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 146 AS3 [AS3] message transports. However, it is possible to leverage CE 147 messaging through other transport standards besides EDIINT. 149 1.2 150 Terminology and Key Word Convention 152 [RFC2828] provides a glossary of Internet security terms, and several 153 of their definitions are listed here verbatim. However, some 154 definitions required for this document were undefined by [RFC2828] or 155 rewritten to better explain their specific use within CEM. 157 Certificate - A digital certificate contains the owner's (End 158 Entity's) name, the issuer's name, a serial number, expiration date, 159 and a copy of the owner's Public Key. The Public Key is used for 160 Encrypting messages and Verifying Signatures (verifying a signature 161 is also called Authentication). 163 Certificate Revocation List (CRL) - A data structure that enumerates 164 digital certificates that have been invalidated by their issuer prior 165 to when they were scheduled to expire. [RFC2828] 167 Certification Authority (CA) - An entity that issues digital 168 certificates (especially X.509 certificates) and vouches for the 169 binding between the data items in a certificate. [RFC2828] 171 CA Certificate - A certificate issued by a trusted certification 172 authority. CA certificates are not used to encrypt data but to sign 173 other certificates. CA certificates are signed by themselves, but are 174 not considered self-signed certificates for the purpose of this 175 document. 177 Certification Hierarchy - In this structure, one CA is the top CA, 178 the highest level of the hierarchy. The top CA may issue public-key 179 certificates to one or more additional CAs that form the second 180 highest level. Each of these CAs may issue certificates to more CAs 181 at the third highest level, and so on. The CAs at the second-lowest 182 of the hierarchy issue certificates only to non-CA entities, called 183 "end entities" that form the lowest level. Thus, all certification 184 paths begin at the top CA and descend through zero or more levels of 185 other CAs. All certificate users base path validations on the top 186 CA's public key. [RFC2828] 188 CEM Request - The EDIINT Certificate Exchange Messaging (CEM) Request 189 is one of two possible CEM messages. It presents a certificate to be 190 introduced into the trading partner relationship along with relevant 191 information on how it is to be implemented. 193 CEM Response - The EDIINT Certificate Exchange Messaging (CEM) 194 Response is one of two possible CEM messages. It is the response to 195 the CEM Request indicating whether or not the end entity certificate 196 present in the CEM Request was accepted. 198 End Entity - A system entity that is the subject of a public-key 199 certificate and that is using, or is permitted and able to use, the 200 matching private key only for a purpose or purposes other than 201 signing a digital certificate; i.e., an entity that is not a CA. 202 [RFC2828] 204 End Entity Certificate - A certificate which is used to encrypt data 205 or authenticate a signature. (The private key associated with the 206 certificate is used to decrypt data or sign data). The certificate 207 may be self-signed or issued by a trusted certificate. 209 Intermediary Certificate - A certificate issued by a CA certificate 210 which itself issues another certificate (either intermediary or end 211 entity). Intermediary certificates are not used to encrypt data but 212 to sign other certificates. 214 Public Key - The publicly-disclosable component of a pair of 215 cryptographic keys used for asymmetric cryptography. [RFC2828] 217 Public Key Certificate - A digital certificate that binds a system 218 entity's identity to a public key value, and possibly to additional 219 data items. [RFC2828] 221 Self-signed Certificate - A certificate which is issued by itself 222 (both issuer and subject are the same) and is an End Entity 223 certificate. 225 1.3 226 Certificate Lifecycle 228 A certificate has five states. 230 1. Pending - Upon receiving a certificate from a trading partner, the 231 certificate is marked as Pending until a decision can be made to 232 trust it or if its validity period has not yet begun. 233 2. Rejected - If a Pending certificate is not trusted, it is 234 considered Rejected. 235 3. Accepted - Once a Pending certificate has been trusted, it is 236 considered Accepted. An Accepted certificate may be used in 237 secure transactions. 238 4. Expired - A certificate which is no longer valid because its 239 expiration date has passed. Expired certificates SHOULD be kept 240 in a certificate storehouse for decrypting and validating past 241 transactions. 243 5. Revoked - A certificate which has been explicitly revoked by its 244 owner or the certificate authority. 246 1.4 247 Certificate Exchange Process 249 This section describes a process whereby a company can distribute 250 certificates to its partners, and the company and its partners can 251 put the certificates into use. Later sections describe the specific 252 CEM protocol, which is an implementation of this process. 254 The exchange process can be used even when CEM is not useable, for 255 example, when the transport protocols or installed software systems 256 do not support CEM. It is RECOMMENDED that this process be followed 257 in distributing certificates. 259 The company that owns the certificates initiates the process. For a 260 certificate that is to be used (by the partners) to encrypt messages, 261 the initiator first prepares his system to decrypt messages that are 262 encrypted with this certificate. The initiator must also be able to 263 decrypt messages using the old certificate. The initiator company 264 distributes the new certificates by some means. The distribution MUST 265 describe the purposes of the certificates and MAY contain a respond 266 by date, the date when the distributor expects to put the 267 certificates in use. The respond by date SHOULD be present for 268 certificates that are used to sign messages or to authenticate 269 TLS/SSL connections. 271 When a partner receives a certificate, the partner should 272 authenticate the distribution message by some means. (CEM provides 273 for automatic authentication. Partners can use manual methods, 274 either with or without CEM.) 276 When a partner receives a certificate for use in encrypting messages 277 and has authenticated the certificate, the partner SHOULD begin 278 using that certificate to encrypt messages. The initiator MUST be 279 prepared to receive messages encrypted with either the old or new 280 certificate. 282 When a partner receives a certificate for use in digitally signing 283 messages or for TLS/SSL authentication and has authenticated the 284 certificate, the partner MUST prepare his system to accept messages 285 that are signed or authenticated with the new certificate. The 286 partner MUST also accept messages signed or authenticated with the 287 old certificate. 289 The partner MAY return a response to the initiator, indicating that 290 the partner has accepted the new certificate and put it in use. The 291 initiator can use these responses to track which partners are ready 292 to use the new certificate. 294 When the partner has sent a response indicating acceptance of the new 295 certificate, or when the respond by date has passed, the initiator 296 can begin using the new certificate to digitally sign messages or 297 authenticate TLS/SSL messages. The initiator MUST NOT sign or 298 authenticate messages with the new certificate until the partner has 299 accepted it or until the respond by date has passed. The initiator 300 MAY wait until the respond by date or until all partners have 301 accepted. The partners MUST accept messages signed or authenticated 302 with either the old or new certificate. 304 When the process is fully automated, it is not necessary to have a 305 specific time when both the initiator and partners switch to the new 306 certificate. 308 The initiator MUST be able to decrypt messages with both the old and 309 new certificates as soon as the new certificates are distributed. 310 The partners MUST be able to accept messages signed or TLS/SSL 311 authenticated with either the old or new certificates after they have 312 accepted the new certificate. The initiator SHOULD allow a 313 reasonable time after distributing a new signing or authenticating 314 certificate before putting it in use, so that partners have time to 315 authenticate the new certificate and prepare their systems for it. 317 For a certificate used to digitally sign messages or authenticate 318 TLS/SSL messages, there must be some way for the initiator to know 319 when partners are ready to receive the certificate. For example, this 320 may be a response from the partners, an explicit respond by date in 321 the initial distribution, an implied respond by date based on partner 322 agreements, or the expiration date of the old certificate. For a 323 certificate used to encrypt messages, the respond by date and 324 responses are less important, but responses may be useful to track 325 partners' acceptances. 327 2. 328 Message Processing 330 2.1 331 Message Structure 333 CEM messages use the underlying EDIINT transport, such as AS2, to 334 communicate information on the certificate, its intended use and its 335 acceptance. Both digital certificates and the XML data describing 336 their intended use are stored within a multipart/related MIME 337 envelope [RFC2387]. For the CEM Request message, the certificates are 338 stored in certificate chains through SMIME, certs-only MIME envelope 339 [3851], and processing information is XML data which is identified 340 through the MIME content-type of application/ediint-cert- 341 exchange+xml. The format for a CEM Request message is as follows: 343 Various EDIINT headers 344 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 345 Content-Type: multipart/signed; micalg=sha1; 346 protocol="application/pkcs7-signature"; 347 boundary="--OUTER-BOUNDARY" 349 ----OUTER-BOUNDARY 350 Content-Type: multipart/related; type="application/ediint-cert- 351 exchange+xml"; boundary="--INNER-BOUNDARY" 353 ----INNER-BOUNDARY 354 Content-Type: application/ediint-cert-exchange+xml 355 Content-ID: <20040101-1.alpha@example.org> 357 [CEM XML data] 358 ----INNER-BOUNDARY 359 Content-Type: application/pkcs7-mime; smime-type=certs-only 360 Content-ID: <20040101-2.alpha@example.org> 362 [digital certificate] 363 ----INNER-BOUNDARY-- 365 ----OUTER-BOUNDARY 366 Content-Type: application/pkcs7-signature 368 [Digital Signature] 369 ----OUTER-BOUNDARY-- 371 One and only one MIME type of application/ediint-cert-exchange+xml 372 MUST be present in the multipart/related structure, and it MUST be 373 the root element. Multiple certs-only media types may be included, 374 but at least one MUST be present. A unique content-id header MUST be 375 present within each of the multipart structures. 377 For the CEM Response message, a multipart/related MIME structure is 378 also used. However, no certificates are present in a CEM Response, 379 and the multipart/related structure only contains one MIME type of 380 application/ediint-cert-exchange+xml. The format for a CEM Request 381 message is as follows: 383 Various EDIINT headers 384 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 385 Content-Type: multipart/signed; micalg=sha1; 386 protocol="application/pkcs7-signature"; 387 boundary="--OUTER-BOUNDARY" 389 ----OUTER-BOUNDARY 390 Content-Type: multipart/related; type="application/ediint-cert- 391 exchange+xml"; boundary="--INNER-BOUNDARY" 393 ----INNER-BOUNDARY 394 Content-Type: application/ediint-cert-exchange+xml 395 Content-ID: <20040201-1.alpha@example.org> 397 [CEM XML data] 398 ----INNER-BOUNDARY-- 400 ----OUTER-BOUNDARY 401 Content-Type: application/pkcs7-signature 403 [Digital Signature] 404 ----OUTER-BOUNDARY-- 406 If possible, both the CEM Request and CEM Response message SHOULD be 407 signed. Applying digital signatures will allow for automatic exchange 408 based on a previous trust relationship. However, it may not be 409 possible in the initial exchange of a new trading partner. If a CEM 410 message is signed, the signing certificate MUST be included in the 411 digital signature. Extra security such as applying data encryption or 412 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and 413 SHOULD request a signed MDN. The MDN can be either synchronous or 414 asynchronous. All necessary headers MUST be applied to the message 415 per the underlying transport standard. 417 2.2 418 EDIINT Features Header 420 To indicate support for CEM, an EDIINT application MUST use the 421 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates 422 the instance application can support various features, such as 423 certification exchange. The header is present in all messages from 424 the instance application, not just those which feature certification 425 exchange. 427 For applications implementing certification exchange, the CEM- 428 Feature-Name MUST be used within the EDIINT Features header: 430 CEM-Feature-Name = "CEM" 432 An example of the EDIINT Features header in a CEM Message: 434 EDIINT-Features: CEM 436 2.3 437 Certificate Exchanging 438 After obtaining the desired certificate, the initiator of the 439 certificate exchange transmits the end-entity certificate in the CEM 440 Request message. If the end-entity certificate is not self-signed, 441 then the CA certificate and any other certificates needed to create 442 the chain of trust for the end-entity certificate MUST be included in 443 the CEM Request message. Multiple end-entity certificates MAY also be 444 present. 446 The entire certificate trust chain is stored in a BER encoded P7C 447 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- 448 only MIME envelope which is then stored in a single part of the 449 multipart/related structure. Each P7C trust chain MUST include a 450 single end-entity certificate and its trust authorities. No other 451 certificates are to be part of this chain. The number of P7C trust 452 chains in a CEM Request message MUST be equal to the number of end- 453 entity certificates being communicated in the CEM XML document. 454 If different end-entity certificates have common trust authorities' 455 certificates, each P7C cert chain still MUST include each certificate 456 necessary to create a trust anchor. Thus, if a recipient can not 457 create a trust relationship from the P7C cert chain, it MAY reject 458 the end-entity certificate in the CEM Request. 460 End-entity certificates are referenced and identified in the XML data 461 by their content-id used in the multipart/related structure. 462 Information on how the certificate is to be used, or certificate 463 usage, by the receiving user agent and other related information is 464 found in the XML data. A certificate can be used for a single 465 function, like digital signatures, or used for multiple functions, 466 such as both digital signatures and data encryption. If a certificate 467 is intended for multiple usages, such as for both digital signatures 468 and data encryption, the certificate MUST be listed only once in the 469 CEM Request message and its multiple usage listed through the 470 CertUsage XML element. 472 Upon receipt of the CEM Request, the recipient trading partner 473 processes the transport message as normal and returns the MDN. The 474 recipient MAY parse the CEM XML data prior to returning the MDN. If 475 the XML is not well-formed and can not be interpreted, the UA MAY 476 return the MDN with the error disposition modifier of "error: 477 unexpected-processing-error". The returned MDN does not provide 478 information on the acceptance of the certificate(s) being exchanged. 479 An UA who receives an MDN with an error disposition modifier MUST 480 consider the CEM Message was not understood and needs to be corrected 481 and retransmitted. 483 2.4 484 Certificate Implementation 485 The new certificate is considered to be in the Pending state for the 486 recipient who MUST decide whether to accept the certificate as 487 trustworthy. This decision is arbitrary and left to each individual 488 trading partner. Upon accepting the certificate, it is to be 489 considered an Accepted certificate within the trading partner 490 relationship. If the certificate is not accepted, it is considered 491 Rejected. 493 When a certificate is intended for use in data encryption, the 494 initiator MUST consider the certificate to be Accepted and be 495 prepared for its trading partner to begin using the certificate upon 496 generating the CEM Request message. After a recipient generates a 497 positive CEM Response message for a certificate, the recipient MUST 498 immediately begin using the certificate in trading with the initiator 499 of the request. The recipient MAY apply encryption to the CEM 500 Response message using the new Accepted certificate or MAY apply 501 encryption to the CEM Response message using the previously Accepted 502 encryption certificate. 504 When a certificate is intended for use in digital signatures or 505 TLS/SSL authentication, the initiator MUST NOT use the certificate 506 until the recipient trading partner generates a CEM Response 507 accepting the certificate or the respond by date, which is listed in 508 the RespondByDate XML element. The initiator MAY use the certificate 509 after the respond by date, regardless of whether the partner has 510 accepted it or not. The certificate used for the digital signature of 511 the CEM Request message MUST be the one which is currently Accepted 512 within the trading partner relationship. 514 Since implementers of EDIINT often use the same certificate with 515 multiple trading partners, implementers of CEM MUST be able to keep 516 both the old and new certificates as Accepted. If the initiator has 517 generated a CEM Request and exchanged a new encryption certificate to 518 multiple trading partners, it MUST be able to accept encrypted data 519 which uses either the older, existing encryption certificate or the 520 newly exchanged encryption certificate. Likewise, a recipient of a 521 CEM Request MUST be able to authenticate digital signatures using 522 either the new or old certificates, since the initiator may not be 523 able to switch certificates until all trading partners accept the new 524 certificate. Similar provisions MUST be made for certificates 525 intended for TLS/SSL server and client authentication. Revoking a 526 certificate MUST be done outside of CEM. 528 If a CEM Request message contains a certificate which is currently 529 Accepted and has the identical usage for the certificate that has 530 been Accepted, the recipient MUST NOT reject the duplicate 531 certificate but MUST respond with a CEM Response message indicating 532 the certificate has been accepted. For example, if Certificate A is 533 currently Accepted as the encryption certificate for a user agent, 534 any CEM Request message containing Certificate A with the usage as 535 encryption only MUST be accepted by an existing trading partner. This 536 situation may be necessary for an implementation intending to verify 537 its current trading partner certificate. 539 If two trading partners utilize multiple EDIINT protocols for 540 trading, such as AS2 for a primary transport and AS1 as the backup 541 transport, it is dependent upon implementation and trading partner 542 agreement how CEM messages are sent and which transports the 543 exchanged certificates affect. 545 2.5 546 CEM Response 548 The CEM Response message is a multipart/related envelope which 549 contains the CEM XML under the MIME type of application/ediint-cert- 550 exchange+xml. If a requestId is used in a CEM Request, then the 551 requestId MUST be present in the CEM Response with the same value. 552 The requestId allows for the CEM Response to be matched to the CEM 553 Request. If the CEM Request contains multiple TrustRequest elements 554 and the corresponding TrustResponse elements are returned in multiple 555 CEM Response messages, each CEM Response message MUST use the same 556 requestId from the originating CEM Request message. This is critical 557 when multiple CEM Requests are sent with the same certificate and the 558 CEM Response can not be matched solely through the TrustResponse 559 elements. 561 A TrustResponse XML element provides information needed to match the 562 end-entity certificate sent in an earlier CEM Request and indicate if 563 the certificate was accepted or rejected by the recipient. The 564 CertificateReference in a TrustResponse matches the 565 CertificateIdentifier value for the end-entity certificate in the CEM 566 Request. CertStatus indicates if the certificate was accepted or 567 rejected. If a CEM Request is received, the recipient MUST respond 568 with a CEM Response message indicating if the certificate is Accepted 569 or Rejected. More information about the XML attributes and value for 570 CEM Response can be found in 3.2. 572 If the certificate in the CEM Request message contains multiple 573 usages, such as for both digital signature and data encryption, only 574 a single TrustResponse is needed for that certificate. The CertStatus 575 value in the TrustResponse is the response for both usages of the 576 certificate. A recipient MUST NOT choose to accept the certificate 577 for one specified use and not the other. 579 If multiple end-entity certificates were included within the CEM 580 Request, the recipient MAY generate individual CEM Response messages 581 for each certificate or the recipient MAY consolidate the 582 TrustResponse for multiple certificates into one CEM Response 583 message. A CEM Response may contain multiple TrustResponse elements 584 for different certificates but MUST NOT contain two or more 585 TrustResponses for the same certificate. 587 If a second TrustResponse is received in a different message matching 588 the same certificate as that of an earlier TrustRespnse but the 589 CertStatus has a different value than the other, the originator MAY 590 accept the CertStatus value in the most recent TrustResponse but MAY 591 choose to ignore it. If the CertStatus in both TrustResponses are the 592 same, the originator should disregard the second TrustResponse. 594 If the originator receives a CEM Response message which violates the 595 rules listed above or is invalid in any way, the originator MAY 596 reject the message entirely but MUST return an MDN if requested. 598 3. 599 CEM XML Schema Description 601 The CEM schema has two top-level elements, 602 EDIINTCertificateExchangeRequest and 603 EDIINTCertificateExchangeResponse. The 604 EDIINTCertificateExchangeRequest element is present only in the CEM 605 Request message, and the EDIINTCertificateExchangeResponse is present 606 only in the CEM Response message. All other elements nest directly or 607 indirectly from these. CEM XML data must be well-formed and valid 608 relative to the CEM XML Schema. Please refer to the appendix for the 609 actual schema document. 611 3.1 612 EDIINTCertificateExchangeRequest element 614 EDIINTCertificateExchangeRequest contains element TradingPartnerInfo, 615 which can only appear once, and TrustRequest, which may be present 616 multiple times. TrustRequest contains information on a certificate 617 and its intended usage. TradingPartnerInfo exists to provide 618 information on the publication of the CEM Request message since 619 processing of the XML data may occur apart from the handling of the 620 accompanying transport message, for example the AS2 request. 622 623 624 625 626 629 631 632 634 635 636 638 EDIINTCertificateExchangeRequest also contains the attribute 639 requestId. RequestId uniquely identifies each CEM Request message. 640 Its value MUST be between 1 and 255 characters. The requestId is 641 returned in the CEM Response message to assist the UA in matching the 642 CEM Response with the CEM Request. 644 645 646 647 648 649 651 An optional Extension element is also present along with the 652 anyAttribute attribute. They exist to provide future extendibility 653 for new features which may be developed but not yet defined within 654 CEM. They are present in several locations in the schema for this 655 future extendibility. 657 658 659 660 662 663 664 666 TradingPartnerInfo identifies the entity that created the CEM message 667 through the nested Name element. Both the qualifier attribute and the 668 element value of Name follow mandatory naming conventions. The 669 qualifier attribute is to be the transport standard utilized. For 670 example, "AS1", "AS2" or "AS3". The value of the Name element is the 671 same value in the From header utilized by the transport. For AS2 and 672 AS3, this is the value in the AS2-From and AS3-From headers, 673 respectively. For AS1, this is the value of the From header. If other 674 transports besides AS1, AS2, AS3 are used, the same naming convention 675 SHOULD be followed. 677 MessageOriginated is included in TradingPartnerInfo to identify the 678 time and date the message was created. The MessageOriginated date and 679 time values MUST follow XML standard dateTime type syntax and be 680 listed to at least the nearest second and expressed in local time 681 with UTC offset. For example, a message originating from the US 682 Eastern Standard timezone would use 2005-03-01T14:05:00-05:00. 684 685 686 687 688 689 690 691 693 694 695 696 697 698 700 701 702 703 705 The TrustRequest element contains the EndEntity, CertUsage, 706 RespondByDate and ResponseURL elements. The required EndEntity 707 element is found only once in a TrustRequest element and contains the 708 content-id reference to the end-entity certificate being exchanged. 710 711 712 713 714 715 716 718 719 720 722 EndEntity contains the nested elements of CertificateIdentifier and 723 CertificateContentID. CertificateContentID is a string element which 724 references the content-id of the multipart/related structure where 725 the certificate is stored. CertificateIdentifier comes from the XML 726 Signature schema namespace [XML-DSIG]. 728 729 730 733 734 736 737 738 740 CertificateIdentifier contains the string element X509IssuerName and 741 the integer element X509SerialNumber. X509SerialNumber is the 742 assigned serial number of the end entity certificate as it is listed. 743 X509IssuerName contains the issuer name information of the end-entity 744 certificate, such as common name, organization, etc. This information 745 MUST be described in a string format per the rules of RFC 2253 746 [RFC2253]. This results in the attributes within the Issuer Name to 747 be listed with their attribute type followed by an "=" and the 748 attribute value. Each attribute type and value are separated by a "," 749 and any escape characters in the value are preceded by a "\". Refer 750 to the appendix and the sample CEM Request message for an example of 751 the X509IssuerName. 753 754 755 756 757 758 760 CertUsage is an unbounded element which contains enumerated values on 761 how the exchanged certificate is to be used. There are enumerated 762 values for SMIME digital signatures (digitalSignature), SMIME data 763 encryption (keyEncipherment), the server certificate used in TLS 764 transport encryption (tlsServer) and the client certificate used in 765 TLS transport encryption (tlsClient). While the element is unbounded, 766 CertUsage only has a potential number of four occurrences due to the 767 limit of the enumerated values. 769 770 771 772 773 774 775 776 777 779 RespondByDate is a required element of the XML standard dateTime type 780 expressed in local time with UTC offset, which provides information 781 on when the certificate should be trusted, inserted into the trading 782 partner relationship and responded to by a CEM Response message. If 783 the certificate can not be trusted or inserted into the trading 784 partner relationship, the CEM Response message should still be 785 returned by the date indicated. 787 789 ResponseURL is an element which indicates where the CEM Response 790 message should be sent. This value takes precedence over the existing 791 inbound URL of the current trading partner relationship. The Response 792 MUST use the same transport protocol (AS1, AS2, or AS3) as the 793 Request. 794 796 3.2 797 EDIINTCertificateExchangeResponse element 799 EDIINTCertificateExchangeResponse contains the two elements 800 TradingPartnerInfo and TrustResponse and the attribute requestId. 801 TradingPartnerInfo, which is also found in 802 EDIINTCertificateExchangeRequest, describes the trading partner 803 generating this response message. TrustResponse provides information 804 on the acceptance of a previously sent end entity certificate. There 805 can be multiple TrustResponse elements within an 806 EDIINTCertificateExchangeResponse. The requestId is the same value 807 from a previously sent CEM Request message. The requestId from the 808 CEM Response is matched up with the CEM Request. 810 811 812 813 814 817 819 820 822 823 824 826 827 828 829 830 833 835 836 837 839 A TrustResponse element identifies a certificate which has been 840 previously exchanged within the trading partner relationship through 841 a CEM Request and now has been either accepted or rejected by the 842 partner. The CertificateReference element is of the same type as the 843 CertificateIdentifier element. A CertificateReference element in a 844 CEM Response MUST be identical to its CertificateIdentifier 845 counterpart in the associated CEM Request since they identify the 846 same certificate in question. 848 The required element CertStatus has the enumerated values of 849 "Accepted" or "Rejected". "Accepted" indicates the certificate was 850 trusted by the trading partner and is now ready for use within the 851 trading partner relationship, and "Rejected" indicates the 852 certificate is not trusted by the trading partner nor can it be 853 currently used with the trading partner relationship. If the value of 854 "Rejected" is chosen, the optional string element ReasonForRejection 855 may be included. If present, ReasonForRejection should contain a 856 brief description of why the certificate was not accepted. Since the 857 value for this element is not enumerated but open, it MUST be 858 interpreted through human means. 860 861 862 863 864 865 866 867 869 4. 870 Use Case Scenario 872 This scenario illustrates how the CEM Request and CEM Response 873 messages described in Section 2 and 3 can be used to exchange 874 certificates. The scenario is only illustrative and any differences 875 between it and the rules above should defer to the rules in Section 2 876 and 3. 878 Two trading partners, Alpha Arrows and Bravo Bows, have an 879 established trading partner relationship using AS2. Alpha Arrows is 880 using a single certificate, CertA, for both digital signatures and 881 data encryption. Alpha Arrows wants to issue a new certificate, 882 CertB, for digital signatures but keep CertA for data encryption. 884 Bravo Bows is using one certificate, Cert1, for digital signatures 885 and another certificate, Cert2, for data encryption. Bravo Bows wants 886 to introduce a new certificate, Cert3, for digital signature and a 887 new certificate, Cert4, for data encryption. 889 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only 890 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows 891 immediately returns the MDN but must make an internal security 892 decision before accepting CertB. 894 2. While waiting for a CEM Response, Alpha Arrows continues to send 895 AS2 messages to Bravo Bows which have been signed using CertA. The 896 messages originating from Bravo Bows are encrypted using CertA. 898 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus 899 of "Accepted" for CertB. Upon receipt, an MDN is returned which is 900 signed using CertA. Bravo Bows MUST be able to accept the MDN if it 901 has a digital signature from either CertA or CertB as Alpha Arrows 902 may not be able to switch certificates simply upon receipt of the CEM 903 Response message without parsing the XML payload. Also, Alpha Arrows 904 may need to wait for CEM Responses from other trading partners before 905 switching to the new CertB. However, as soon as possible, Alpha 906 Arrows should use CertB exclusively for digital signatures. 908 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both 909 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are 910 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows 911 returns an MDN immediately. Bravo Bows is now prepared to receive any 912 inbound messages encrypted by either Cert2 or Cert4, but all its 913 digital signatures are still done through Cert1. 915 5. Eventually, Alpha Arrows returns a single CEM Response message. It 916 contains two TrustResponse elements: one for Cert3 and another for 917 Cert4. The CertStatus for Cert3 is "Rejected" with the 918 ReasonForRejection field present and populated with the string 919 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted." 920 Bravo Bows returns the MDN signed through Cert1. 922 6. Immediately after this, an AS2 message is received from Alpha 923 Arrows which is encrypted using Cert4, and Bravo Bows is able to 924 decrypt the message successfully. Because Alpha Arrows rejected 925 Cert3, Bravo Bows is only using Cert1 for digital signatures and 926 returns the MDN signed with Cert1. 928 7. After creating a new certificate, Cert5, which corrects the 929 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request. 931 8. Shortly after this, Alpha Arrows sends a CEM Response message for 932 Cert5. It contains a CertStatus of "Accepted". This CEM Response 933 message was encrypted using Cert4, but Bravo Bows was prepared for 934 encryption from either Cert2 or Cert4. The message is processed and a 935 good MDN is returned signed with Cert1. While, Bravo Bows can now 936 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows 937 should use Cert5 exclusively as soon as possible. 939 5. 940 Profile Exchange Messaging 942 CEM provides the means to exchange certificates among trading 943 partners. However, other profile information, such as URLs and 944 preferred security settings, is needed to create a trading partner 945 relationship. A future standard is needed to describe profile 946 descriptions and how they will be exchanged. The format for this 947 profile attachment is not defined in this specification but is 948 planned for a future document. It will build upon the existing CEM 949 protocol with profile information stored with XML data. Both 950 certificate and profile description information will be placed into a 951 multipart/related [RFC2387] body part entity. A possible format for a 952 profile description message is as follows: 954 Various EDIINT headers 955 EDIINT-Features: profile-exchange 956 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 957 Disposition-Notification-Options: signed-receipt-protocol=optional, 958 pkcs7-signature; signed-receipt-micalg=optional, sha1 959 Content-Type: multipart/signed; micalg=sha1; 960 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 962 ----BOUNDARY1 963 Content-Type: multipart/related; 964 start=""; 965 type="application/ediint-cert-exchange+xml"; 966 boundary="--BOUNDARY2" 968 ----BOUNDARY2 969 Content-Type: application/ediint-cert-exchange+xml 970 Content-ID: 972 [CEM XML data] 973 ----BOUNDARY2 974 [Profile information attachment] 975 ----BOUNDARY2-- 976 ----BOUNDARY1 978 Content-Type: application/pkcs7-signature 980 [Digital Signature] 981 ----BOUNDARY1-- 983 6. 984 Implementation Considerations 986 This section contains various points to explain practical 987 implementation considerations. 989 * If the EDIINT transport message carrying a CEM Request or CEM 990 Response fails resulting in a negative MDN, the CEM message, its 991 contents and instructions are to be ignored. The User Agent receiving 992 the negative MDN is to consider the CEM message to be ignored and 993 retransmit as needed. 995 * While a single end-entity certificate can be only be used once in a 996 single CEM Request message, the same certificate can be sent multiple 997 times in multiple CEM Request messages. The requestId is used for 998 matching the CEM Request and CEM Response messages. 1000 * Certificate usage is cumulative. Thus, if a User Agent receives a 1001 valid CEM Request message with Certificate A with certUsage set to 1002 digitalSignature and then a second valid CEM Request message with 1003 Certificate A with certUsage set to keyEncipherment, then the User 1004 Agent MUST configure the certificate to be used both for 1005 digitalSignature and keyEncipherment. As well, if at a later time a 1006 valid CEM Request message is received with Certificate A with 1007 certUsage set only to digitalSignature, Certificate A is still valid 1008 for keyEncipherment. 1010 7. 1011 Future Considerations for CEM I-D 1012 This section contains ideas for consideration in future versions of 1013 CEM and addressed in the future. If deemed necessary, they will be 1014 added into the I-D else they will be removed. This section will be 1015 removed prior to RFC submission. 1017 8. 1018 Security Considerations 1020 Certificate exchange is safe for transmitting. However, implementers 1021 SHOULD verify the received certificate to determine if it is truly 1022 from the stated originator through out-of-band means or whenever the 1023 request is not signed. 1025 9. 1026 IANA Considerations 1028 MIME Media type name: Application 1030 MIME subtype name: EDIINT-cert-exchange+xml 1032 Required parameters: None 1034 Optional parameters: This parameter has identical semantics to the 1035 charset parameter of the "application/xml" media type as specified 1036 in [RFC3023]. 1038 Encoding considerations: Identical to those of "application/xml" as 1039 described in [RFC3023], section 3.2. 1041 Security considerations: See section 6. 1043 Interoperability Considerations: See section 2.2 1045 Published specification: This document. 1047 Applications which use this media type: EDIINT applications, such as 1048 AS1, AS2 and AS3 implementations. 1050 Additional Information: None 1052 Intended Usage: Common 1054 Author/Change controller: See Author's section of this document. 1056 10. 1057 References 1058 10.1 1059 Normative References 1061 [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data 1062 Interchange over the Internet using SMTP", T. Harding, R. 1063 Drummond, C. Shih, 2002. 1065 [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data 1066 Interchange over the Internet using HTTP", D. Moberg, R. 1067 Drummond, 2005. 1069 [AS3] draft-ietf-ediint-as3-05.txt "MIME-based Secure Peer-to-Peer 1070 Business Data Interchange over the Internet using FTP", T. 1071 Harding, R. Scott, 2003. 1073 [EDIINT FEATURE] draft-meadors-ediint-feature-header-01.txt "Feature 1074 Header for EDI-INT", K. Meadors, 2006. 1076 [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement 1077 Levels", S.Bradner, March 1997. 1079 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen, 1080 October 1999. 1082 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8 1083 String Representation of Distinguished Names", M. Wahl, S. Kille 1084 and T. Howes, Decemeber 1997. 1086 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 1087 Levinson, August 1998. 1089 [RFC2828] RFC2828 "Internet Security Glossary", R. Shirley, May 2000. 1091 [RFC3023] RFC3023 "XML Media Types", M. Murata, October 2001. 1093 [XML-DSIG] RFC3275 "XML-Signature Syntax and Processing", D. 1094 Eastlake, March 2002. 1096 [X.520] ITU-T Recommendation X.520: Information Technology - Open 1097 Systems Interconnection - The Directory: Selected Attribute 1098 Types, 1993. 1100 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1101 X.509 Public Key Infrastructure: Certificate and CRL Profile", 1102 RFC 3280, April 2002. 1104 10.2 1105 Informative References 1107 11. 1108 Acknowledgments 1110 The authors wish to extend gratitude to the ecGIF sub-committee 1111 within the GS1 organization from which this effort began. Many have 1112 contributed to the development of this specification, but some 1113 deserve special recognition. John Duker who chaired the sub-committee 1114 and provided valuable editing. John Koehring with his work on the 1115 reference ID and shared important insights on implementation. Aaron 1116 Gomez in the coordinating of vendors testing CEM. Richard Bigelow who 1117 greatly assisted development of the ideas presented, and Debra Petta 1118 for her review and comments. 1120 Author's Addresses 1122 Kyle Meadors 1123 Drummond Group Inc. 1124 4700 Bryant Irvin Court, Suite 303 1125 Fort Worth, TX 76107 USA 1126 Email: kyle@drummondgroup.com 1127 Dale Moberg 1128 Axway, Inc. 1129 8388 E. Hartford Drive, Suite 100 1130 Scottsdale, AZ 85255 USA 1131 Email: dmoberg@us.axway.com 1133 Copyright (c) 2009 IETF Trust and the persons identified as the document 1134 authors. All rights reserved. 1136 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 1137 Relating to IETF Documents in effect on the date of publication of this 1138 document (http://trustee.ietf.org/license-info). Please review these 1139 documents carefully, as they describe your rights and restrictions with 1140 respect to this document. 1142 All IETF Documents and the information contained therein are provided on 1143 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1144 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 1145 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1146 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1147 THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1150 Appendix 1152 A.1 EDIINT Certificate Exchange XML Schema 1154 1155 1161 1163 1164 1165 1166 1167 1169 1171 1172 1174 1175 1177 1178 1179 1180 1181 1182 1184 1186 1187 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1201 1202 1203 1204 1205 1206 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1242 1243 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1256 1257 1258 1259 1260 1261 1262 1263 1265 1267 1268 1269 1270 1271 1272 1273 1275 1277 1278 1279 1281 A.2 Example of EDIINT Certificate Exchange Request XML 1283 1284 1289 1290 DGI_Test_CEM 1291 1292 2005-08-30T00:30:00-05:00 1293 1294 1295 keyEncipherment 1296 digitalSignature 1297 2005-09-30T12:00:00-05:00 1298 http://10.1.1.1/as2 1299 1300 1301 CN=Cleo- 1302 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1303 Worth,S=Texas,C=US 1304 9659684611094873474886 1305 1306 1307 SignEncCert-Example_vs02@example.org 1308 1309 1310 1311 tlsServer 1312 2005-09-30T12:00:00-05:00 1313 http://10.1.1.1/as2 1314 1315 1316 CN=VeriSign Class 1 CA Individual 1317 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1318 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1319 Inc. 1320 2673611014597817669550861744279966682 1322 1323 1324 SSLCert-Example_vs02@example.org 1325 1327 1328 1330 A.3 Example of EDIINT Certificate Exchange Response XML 1332 1333 1338 1339 DGI_Test_CEM_Trading_Partner 1340 1341 2005-08-31T00:21:00-05:00 1342 1343 1344 Accepted 1345 1346 CN=Cleo- 1347 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1348 Worth,S=Texas,C=US 1349 9659684611094873474886 1350 1351 1352 1353 Accepted 1354 1355 CN=VeriSign Class 1 CA Individual 1356 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1357 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1358 Inc. 1359 2673611014597817669550861744279966682 1361 1362 1363 1365 Changes from Previous Versions 1367 B.1 Updates from Version 00 1369 . Updated security requirements in section 2.1, specifically in 1370 regards to digital signatures. 1371 . The XML element responseURL is now required. Modified section 1372 3.1 and example messages in appendix accordingly. 1373 . Certificates are exchanged within a full P7C cert chain. Section 1374 2.3 reflects this. 1376 . The XML element TrustChain is not longer necessary since the 1377 entire cert chain is stored. Removed references in schema and 1378 document. 1379 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be 1380 sent and that if this occurs, the action of the CEM Request 1381 initiator is not defined. 1382 . Updated the examples in Appendix B to reflect the current usage. 1384 B.2 Updates from Version 01 1386 . Added information for handling different scenarios with CEM 1387 Response message. 1388 . Rewrote use case scenarios. 1389 . Added the EDIINT Features header information. 1391 B.3 Updates from Version 02 1393 . Modified use of SSL certificates to match real-world needs. 1394 . Modified schema in changing namespace value and removed schema 1395 location. 1396 . Added statement that CEM XML must be well-formed and valid to 1397 schema. 1398 . Modified Use Case to correct an error and improve clarity. 1399 . Added section 1.4 to describe CEM process. 1401 B.4 Updates from Version 03 1402 . None. Update done because vs03 expired. 1404 B.5 Updates from Version 04 1405 . Clarified requirement of using multipart/related for CEM 1406 Response. 1407 . Added sections on Implementation Considerations and Future 1408 Implementation. 1409 . Modified schema to allow future extensions. 1410 . Changed requirements on qualifier attribute in the Name 1411 element. 1412 . Changed functionality to allow error MDN to be returned when 1413 CEM XML can not be parsed. 1415 B.6 Updates from Version 05 1416 . Added requestId to CEM. 1417 . Removed normative reference to RFC 3821. 1419 B.7 Updates from Version 06/07/08/09 1420 . None. Updated for 6-month I-D expiration.