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