idnits 2.17.1 draft-meadors-certificate-exchange-08.txt: -(171): 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-08' == There are 6 instances of lines with non-ascii characters in the document. == 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 : ---------------------------------------------------------------------------- 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 (February 2008) is 5909 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 359 == Missing Reference: 'EDIINT-FEATURE' is mentioned on line 446, but not defined == Unused Reference: 'EDIINT FEATURE' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 1138, but no explicit reference was found in the text == Unused Reference: 'PROFILE' is defined on line 1159, 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 (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft CEM for EDIINT February 2008 3 Private K. Meadors 4 Internet-Draft Drummond Group Inc. 5 Document: draft-meadors-certificate-exchange- D. Moberg 6 08.txt Axway, Inc. 7 Expires: August 2008 February 2008 9 Certificate Exchange Messaging for EDIINT 10 draft-meadors-certificate-exchange-08.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 50 Draft CEM for EDIINT February 2008 52 intended usage and their acceptance through XML. Certificates can be 53 specified for use in digital signatures, data encryption or SSL/TLS 54 over HTTP (HTTPS). 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119. 62 Feedback Instructions 64 NOTE TO RFC EDITOR: This section should be removed by the RFC editor 65 prior to publication. 67 If you want to provide feedback on this draft, follow these 68 guidelines: 70 -Send feedback via e-mail to kyle@drummondgroup.com, with 71 "Certificate Exchange" in the Subject field. 73 -Be specific as to what section you are referring to, preferably 74 quoting the portion that needs modification, after which you state 75 your comments. 77 -If you are recommending some text to be replaced with your suggested 78 text, again, quote the section to be replaced, and be clear on the 79 section in question. 81 Table of Contents 83 1. Introduction...................................................3 84 1.1 Overview...................................................3 85 1.2 Terminology and Key Word Convention........................4 86 1.3 Certificate Lifecycle......................................5 87 1.4 Certificate Exchange Process...............................6 88 2. Message Processing.............................................7 89 2.1 Message Structure..........................................7 90 2.2 EDIINT Features Header.....................................9 91 2.3 Certificate Exchanging.....................................9 92 2.4 Certificate Implementation................................10 93 2.5 CEM Response..............................................12 94 3. CEM XML Schema Description....................................13 95 3.1 EDIINTCertificateExchangeRequest element..................13 96 3.2 EDIINTCertificateExchangeResponse element.................17 97 4. Use Case Scenario.............................................18 98 5. Profile Exchange Messaging....................................20 100 Draft CEM for EDIINT February 2008 102 6. Implementation Considerations.................................21 103 7. Future Considerations for CEM I-D.............................21 104 8. Security Considerations.......................................21 105 9. IANA Considerations...........................................22 106 10. References...................................................22 107 10.1 Normative References.....................................22 108 10.2 Informative References...................................23 109 11. Acknowledgments..............................................23 110 Author's Addresses...............................................23 111 Appendix.........................................................24 112 A.1 EDIINT Certificate Exchange XML Schema....................24 113 A.2 Example of EDIINT Certificate Exchange Request XML........27 114 A.3 Example of EDIINT Certificate Exchange Response XML.......28 115 Changes from Previous Versions...................................28 116 B.1 Updates from Version 00...................................28 117 B.2 Updates from Version 01...................................29 118 B.3 Updates from Version 02...................................29 119 B.4 Updates from Version 03...................................29 120 B.5 Updates from Version 04...................................29 121 B.6 Updates from Version 05...................................29 122 B.7 Updates from Version 06/07................................29 124 1. 125 Introduction 127 1.1 128 Overview 130 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 131 numerous supply-chains was due in part to the security feature which 132 was provided. The security is not possible without the digital 133 certificates which enable it. To maintain the level of security 134 necessary to transmit business documentation, existing certificates 135 must occasionally be replaced and exchanged with newer ones. The 136 exchanging of digital certificates is unavoidable given how 137 certificates can expire or become compromised. Complicating this is 138 supply-chains which cannot afford to shutdown their business 139 transactions while trading partners laboriously upload new 140 certificates. Certificate exchange must be accomplished in a reliable 141 and seamless format so as not to affect ongoing business 142 transactions. 144 This document describes how EDIINT products may exchange public-key 145 certificates. Since EDIINT is built upon the security provided by 146 public-private key pairs, it is vital that implementers are able to 147 update their trading partners with new certificates as their old 148 certificates expire, become outdated or insecure. Certificate 149 Exchange Messaging (CEM) described here utilizes XML data to exchange 150 the certificate and provide information on its intended usage and 151 acceptance within the trading partner relationship. There are two 153 Draft CEM for EDIINT February 2008 155 types of CEM messages. The CEM Request which presents the new 156 certificate to be introduced into the trading partner relationship 157 and the CEM Response which is the recipient�s response to the CEM 158 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 159 AS3 [AS3] message transports. However, it is possible to leverage CE 160 messaging through other transport standards besides EDIINT. 162 1.2 163 Terminology and Key Word Convention 165 [RFC2828] provides a glossary of Internet security terms, and several 166 of their definitions are listed here verbatim. However, some 167 definitions required for this document were undefined by [RFC2828] or 168 rewritten to better explain their specific use within CEM. 170 Certificate - A digital certificate contains the owner�s (End 171 Entity�s) name, the issuer�s name, a serial number, expiration date, 172 and a copy of the owner�s Public Key. The Public Key is used for 173 Encrypting messages and Verifying Signatures (verifying a signature 174 is also called Authentication). 176 Certificate Revocation List (CRL) - A data structure that enumerates 177 digital certificates that have been invalidated by their issuer prior 178 to when they were scheduled to expire. [RFC2828] 180 Certification Authority (CA) - An entity that issues digital 181 certificates (especially X.509 certificates) and vouches for the 182 binding between the data items in a certificate. [RFC2828] 184 CA Certificate - A certificate issued by a trusted certification 185 authority. CA certificates are not used to encrypt data but to sign 186 other certificates. CA certificates are signed by themselves, but are 187 not considered self-signed certificates for the purpose of this 188 document. 190 Certification Hierarchy - In this structure, one CA is the top CA, 191 the highest level of the hierarchy. The top CA may issue public-key 192 certificates to one or more additional CAs that form the second 193 highest level. Each of these CAs may issue certificates to more CAs 194 at the third highest level, and so on. The CAs at the second-lowest 195 of the hierarchy issue certificates only to non-CA entities, called 196 "end entities" that form the lowest level. Thus, all certification 197 paths begin at the top CA and descend through zero or more levels of 198 other CAs. All certificate users base path validations on the top 199 CA's public key. [RFC2828] 201 CEM Request - The EDIINT Certificate Exchange Messaging (CEM) Request 202 is one of two possible CEM messages. It presents a certificate to be 203 introduced into the trading partner relationship along with relevant 204 information on how it is to be implemented. 206 Draft CEM for EDIINT February 2008 208 CEM Response - The EDIINT Certificate Exchange Messaging (CEM) 209 Response is one of two possible CEM messages. It is the response to 210 the CEM Request indicating whether or not the end entity certificate 211 present in the CEM Request was accepted. 213 End Entity - A system entity that is the subject of a public-key 214 certificate and that is using, or is permitted and able to use, the 215 matching private key only for a purpose or purposes other than 216 signing a digital certificate; i.e., an entity that is not a CA. 217 [RFC2828] 219 End Entity Certificate - A certificate which is used to encrypt data 220 or authenticate a signature. (The private key associated with the 221 certificate is used to decrypt data or sign data). The certificate 222 may be self-signed or issued by a trusted certificate. 224 Intermediary Certificate - A certificate issued by a CA certificate 225 which itself issues another certificate (either intermediary or end 226 entity). Intermediary certificates are not used to encrypt data but 227 to sign other certificates. 229 Public Key - The publicly-disclosable component of a pair of 230 cryptographic keys used for asymmetric cryptography. [RFC2828] 232 Public Key Certificate - A digital certificate that binds a system 233 entity's identity to a public key value, and possibly to additional 234 data items. [RFC2828] 236 Self-signed Certificate - A certificate which is issued by itself 237 (both issuer and subject are the same) and is an End Entity 238 certificate. 240 1.3 241 Certificate Lifecycle 243 A certificate has five states. 245 1. Pending - Upon receiving a certificate from a trading partner, the 246 certificate is marked as Pending until a decision can be made to 247 trust it or if its validity period has not yet begun. 248 2. Rejected - If a Pending certificate is not trusted, it is 249 considered Rejected. 250 3. Accepted - Once a Pending certificate has been trusted, it is 251 considered Accepted. An Accepted certificate may be used in 252 secure transactions. 253 4. Expired - A certificate which is no longer valid because its 254 expiration date has passed. Expired certificates SHOULD be kept 255 in a certificate storehouse for decrypting and validating past 256 transactions. 258 Draft CEM for EDIINT February 2008 260 5. Revoked - A certificate which has been explicitly revoked by its 261 owner or the certificate authority. 263 1.4 264 Certificate Exchange Process 266 This section describes a process whereby a company can distribute 267 certificates to its partners, and the company and its partners can 268 put the certificates into use. Later sections describe the specific 269 CEM protocol, which is an implementation of this process. 271 The exchange process can be used even when CEM is not useable, for 272 example, when the transport protocols or installed software systems 273 do not support CEM. It is RECOMMENDED that this process be followed 274 in distributing certificates. 276 The company that owns the certificates initiates the process. For a 277 certificate that is to be used (by the partners) to encrypt messages, 278 the initiator first prepares his system to decrypt messages that are 279 encrypted with this certificate. The initiator must also be able to 280 decrypt messages using the old certificate. The initiator company 281 distributes the new certificates by some means. The distribution MUST 282 describe the purposes of the certificates and MAY contain a respond 283 by date, the date when the distributor expects to put the 284 certificates in use. The respond by date SHOULD be present for 285 certificates that are used to sign messages or to authenticate 286 TLS/SSL connections. 288 When a partner receives a certificate, the partner should 289 authenticate the distribution message by some means. (CEM provides 290 for automatic authentication. Partners can use manual methods, 291 either with or without CEM.) 293 When a partner receives a certificate for use in encrypting messages 294 and has authenticated the certificate, the partner SHOULD begin 295 using that certificate to encrypt messages. The initiator MUST be 296 prepared to receive messages encrypted with either the old or new 297 certificate. 299 When a partner receives a certificate for use in digitally signing 300 messages or for TLS/SSL authentication and has authenticated the 301 certificate, the partner MUST prepare his system to accept messages 302 that are signed or authenticated with the new certificate. The 303 partner MUST also accept messages signed or authenticated with the 304 old certificate. 306 The partner MAY return a response to the initiator, indicating that 307 the partner has accepted the new certificate and put it in use. The 309 Draft CEM for EDIINT February 2008 311 initiator can use these responses to track which partners are ready 312 to use the new certificate. 314 When the partner has sent a response indicating acceptance of the new 315 certificate, or when the respond by date has passed, the initiator 316 can begin using the new certificate to digitally sign messages or 317 authenticate TLS/SSL messages. The initiator MUST NOT sign or 318 authenticate messages with the new certificate until the partner has 319 accepted it or until the respond by date has passed. The initiator 320 MAY wait until the respond by date or until all partners have 321 accepted. The partners MUST accept messages signed or authenticated 322 with either the old or new certificate. 324 When the process is fully automated, it is not necessary to have a 325 specific time when both the initiator and partners switch to the new 326 certificate. 328 The initiator MUST be able to decrypt messages with both the old and 329 new certificates as soon as the new certificates are distributed. 330 The partners MUST be able to accept messages signed or TLS/SSL 331 authenticated with either the old or new certificates after they have 332 accepted the new certificate. The initiator SHOULD allow a 333 reasonable time after distributing a new signing or authenticating 334 certificate before putting it in use, so that partners have time to 335 authenticate the new certificate and prepare their systems for it. 337 For a certificate used to digitally sign messages or authenticate 338 TLS/SSL messages, there must be some way for the initiator to know 339 when partners are ready to receive the certificate. For example, this 340 may be a response from the partners, an explicit respond by date in 341 the initial distribution, an implied respond by date based on partner 342 agreements, or the expiration date of the old certificate. For a 343 certificate used to encrypt messages, the respond by date and 344 responses are less important, but responses may be useful to track 345 partners� acceptances. 347 2. 348 Message Processing 350 2.1 351 Message Structure 353 CEM messages use the underlying EDIINT transport, such as AS2, to 354 communicate information on the certificate, its intended use and its 355 acceptance. Both digital certificates and the XML data describing 356 their intended use are stored within a multipart/related MIME 357 envelope [RFC2387]. For the CEM Request message, the certificates are 358 stored in certificate chains through SMIME, certs-only MIME envelope 359 [3851], and processing information is XML data which is identified 361 Draft CEM for EDIINT February 2008 363 through the MIME content-type of application/ediint-cert- 364 exchange+xml. The format for a CEM Request message is as follows: 366 Various EDIINT headers 367 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 368 Content-Type: multipart/signed; micalg=sha1; 369 protocol="application/pkcs7-signature"; 370 boundary="--OUTER-BOUNDARY" 372 ----OUTER-BOUNDARY 373 Content-Type: multipart/related; type="application/ediint-cert- 374 exchange+xml"; boundary="--INNER-BOUNDARY" 376 ----INNER-BOUNDARY 377 Content-Type: application/ediint-cert-exchange+xml 378 Content-ID: <20040101-1.alpha@example.org> 380 [CEM XML data] 381 ----INNER-BOUNDARY 382 Content-Type: application/pkcs7-mime; smime-type=certs-only 383 Content-ID: <20040101-2.alpha@example.org> 385 [digital certificate] 386 ----INNER-BOUNDARY-- 388 ----OUTER-BOUNDARY 389 Content-Type: application/pkcs7-signature 391 [Digital Signature] 392 ----OUTER-BOUNDARY-- 394 One and only one MIME type of application/ediint-cert-exchange+xml 395 MUST be present in the multipart/related structure, and it MUST be 396 the root element. Multiple certs-only media types may be included, 397 but at least one MUST be present. A unique content-id header MUST be 398 present within each of the multipart structures. 400 For the CEM Response message, a multipart/related MIME structure is 401 also used. However, no certificates are present in a CEM Response, 402 and the multipart/related structure only contains one MIME type of 403 application/ediint-cert-exchange+xml. The format for a CEM Request 404 message is as follows: 406 Various EDIINT headers 407 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 408 Content-Type: multipart/signed; micalg=sha1; 409 protocol="application/pkcs7-signature"; 410 boundary="--OUTER-BOUNDARY" 412 Draft CEM for EDIINT February 2008 414 ----OUTER-BOUNDARY 415 Content-Type: multipart/related; type="application/ediint-cert- 416 exchange+xml"; boundary="--INNER-BOUNDARY" 418 ----INNER-BOUNDARY 419 Content-Type: application/ediint-cert-exchange+xml 420 Content-ID: <20040201-1.alpha@example.org> 422 [CEM XML data] 423 ----INNER-BOUNDARY-- 425 ----OUTER-BOUNDARY 426 Content-Type: application/pkcs7-signature 428 [Digital Signature] 429 ----OUTER-BOUNDARY-- 431 If possible, both the CEM Request and CEM Response message SHOULD be 432 signed. Applying digital signatures will allow for automatic exchange 433 based on a previous trust relationship. However, it may not be 434 possible in the initial exchange of a new trading partner. If a CEM 435 message is signed, the signing certificate MUST be included in the 436 digital signature. Extra security such as applying data encryption or 437 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and 438 SHOULD request a signed MDN. The MDN can be either synchronous or 439 asynchronous. All necessary headers MUST be applied to the message 440 per the underlying transport standard. 442 2.2 443 EDIINT Features Header 445 To indicate support for CEM, an EDIINT application MUST use the 446 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates 447 the instance application can support various features, such as 448 certification exchange. The header is present in all messages from 449 the instance application, not just those which feature certification 450 exchange. 452 For applications implementing certification exchange, the CEM- 453 Feature-Name MUST be used within the EDIINT Features header: 455 CEM-Feature-Name = "CEM" 457 An example of the EDIINT Features header in a CEM Message: 459 EDIINT-Features: CEM 461 2.3 462 Certificate Exchanging 464 Draft CEM for EDIINT February 2008 466 After obtaining the desired certificate, the initiator of the 467 certificate exchange transmits the end-entity certificate in the CEM 468 Request message. If the end-entity certificate is not self-signed, 469 then the CA certificate and any other certificates needed to create 470 the chain of trust for the end-entity certificate MUST be included in 471 the CEM Request message. Multiple end-entity certificates MAY also be 472 present. 474 The entire certificate trust chain is stored in a BER encoded P7C 475 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- 476 only MIME envelope which is then stored in a single part of the 477 multipart/related structure. Each P7C trust chain MUST include a 478 single end-entity certificate and its trust authorities. No other 479 certificates are to be part of this chain. The number of P7C trust 480 chains in a CEM Request message MUST be equal to the number of end- 481 entity certificates being communicated in the CEM XML document. 482 If different end-entity certificates have common trust authorities� 483 certificates, each P7C cert chain still MUST include each certificate 484 necessary to create a trust anchor. Thus, if a recipient can not 485 create a trust relationship from the P7C cert chain, it MAY reject 486 the end-entity certificate in the CEM Request. 488 End-entity certificates are referenced and identified in the XML data 489 by their content-id used in the multipart/related structure. 490 Information on how the certificate is to be used, or certificate 491 usage, by the receiving user agent and other related information is 492 found in the XML data. A certificate can be used for a single 493 function, like digital signatures, or used for multiple functions, 494 such as both digital signatures and data encryption. If a certificate 495 is intended for multiple usages, such as for both digital signatures 496 and data encryption, the certificate MUST be listed only once in the 497 CEM Request message and its multiple usage listed through the 498 CertUsage XML element. 500 Upon receipt of the CEM Request, the recipient trading partner 501 processes the transport message as normal and returns the MDN. The 502 recipient MAY parse the CEM XML data prior to returning the MDN. If 503 the XML is not well-formed and can not be interpreted, the UA MAY 504 return the MDN with the error disposition modifier of "error: 505 unexpected-processing-error". The returned MDN does not provide 506 information on the acceptance of the certificate(s) being exchanged. 507 An UA who receives an MDN with an error disposition modifier MUST 508 consider the CEM Message was not understood and needs to be corrected 509 and retransmitted. 511 2.4 512 Certificate Implementation 514 Draft CEM for EDIINT February 2008 516 The new certificate is considered to be in the Pending state for the 517 recipient who MUST decide whether to accept the certificate as 518 trustworthy. This decision is arbitrary and left to each individual 519 trading partner. Upon accepting the certificate, it is to be 520 considered an Accepted certificate within the trading partner 521 relationship. If the certificate is not accepted, it is considered 522 Rejected. 524 When a certificate is intended for use in data encryption, the 525 initiator MUST consider the certificate to be Accepted and be 526 prepared for its trading partner to begin using the certificate upon 527 generating the CEM Request message. After a recipient generates a 528 positive CEM Response message for a certificate, the recipient MUST 529 immediately begin using the certificate in trading with the initiator 530 of the request. The recipient MAY apply encryption to the CEM 531 Response message using the new Accepted certificate or MAY apply 532 encryption to the CEM Response message using the previously Accepted 533 encryption certificate. 535 When a certificate is intended for use in digital signatures or 536 TLS/SSL authentication, the initiator MUST NOT use the certificate 537 until the recipient trading partner generates a CEM Response 538 accepting the certificate or the respond by date, which is listed in 539 the RespondByDate XML element. The initiator MAY use the certificate 540 after the respond by date, regardless of whether the partner has 541 accepted it or not. The certificate used for the digital signature of 542 the CEM Request message MUST be the one which is currently Accepted 543 within the trading partner relationship. 545 Since implementers of EDIINT often use the same certificate with 546 multiple trading partners, implementers of CEM MUST be able to keep 547 both the old and new certificates as Accepted. If the initiator has 548 generated a CEM Request and exchanged a new encryption certificate to 549 multiple trading partners, it MUST be able to accept encrypted data 550 which uses either the older, existing encryption certificate or the 551 newly exchanged encryption certificate. Likewise, a recipient of a 552 CEM Request MUST be able to authenticate digital signatures using 553 either the new or old certificates, since the initiator may not be 554 able to switch certificates until all trading partners accept the new 555 certificate. Similar provisions MUST be made for certificates 556 intended for TLS/SSL server and client authentication. Revoking a 557 certificate MUST be done outside of CEM. 559 If a CEM Request message contains a certificate which is currently 560 Accepted and has the identical usage for the certificate that has 561 been Accepted, the recipient MUST NOT reject the duplicate 562 certificate but MUST respond with a CEM Response message indicating 563 the certificate has been accepted. For example, if Certificate A is 564 currently Accepted as the encryption certificate for a user agent, 566 Draft CEM for EDIINT February 2008 568 any CEM Request message containing Certificate A with the usage as 569 encryption only MUST be accepted by an existing trading partner. This 570 situation may be necessary for an implementation intending to verify 571 its current trading partner certificate. 573 If two trading partners utilize multiple EDIINT protocols for 574 trading, such as AS2 for a primary transport and AS1 as the backup 575 transport, it is dependent upon implementation and trading partner 576 agreement how CEM messages are sent and which transports the 577 exchanged certificates affect. 579 2.5 580 CEM Response 582 The CEM Response message is a multipart/related envelope which 583 contains the CEM XML under the MIME type of application/ediint-cert- 584 exchange+xml. If a requestId is used in a CEM Request, then the 585 requestId MUST be present in the CEM Response with the same value. 586 The requestId allows for the CEM Response to be matched to the CEM 587 Request. If the CEM Request contains multiple TrustRequest elements 588 and the corresponding TrustResponse elements are returned in multiple 589 CEM Response messages, each CEM Response message MUST use the same 590 requestId from the originating CEM Request message. This is critical 591 when multiple CEM Requests are sent with the same certificate and the 592 CEM Response can not be matched solely through the TrustResponse 593 elements. 595 A TrustResponse XML element provides information needed to match the 596 end-entity certificate sent in an earlier CEM Request and indicate if 597 the certificate was accepted or rejected by the recipient. The 598 CertificateReference in a TrustResponse matches the 599 CertificateIdentifier value for the end-entity certificate in the CEM 600 Request. CertStatus indicates if the certificate was accepted or 601 rejected. If a CEM Request is received, the recipient MUST respond 602 with a CEM Response message indicating if the certificate is Accepted 603 or Rejected. More information about the XML attributes and value for 604 CEM Response can be found in 3.2. 606 If the certificate in the CEM Request message contains multiple 607 usages, such as for both digital signature and data encryption, only 608 a single TrustResponse is needed for that certificate. The CertStatus 609 value in the TrustResponse is the response for both usages of the 610 certificate. A recipient MUST NOT choose to accept the certificate 611 for one specified use and not the other. 613 If multiple end-entity certificates were included within the CEM 614 Request, the recipient MAY generate individual CEM Response messages 615 for each certificate or the recipient MAY consolidate the 616 TrustResponse for multiple certificates into one CEM Response 617 message. A CEM Response may contain multiple TrustResponse elements 619 Draft CEM for EDIINT February 2008 621 for different certificates but MUST NOT contain two or more 622 TrustResponses for the same certificate. 624 If a second TrustResponse is received in a different message matching 625 the same certificate as that of an earlier TrustRespnse but the 626 CertStatus has a different value than the other, the originator MAY 627 accept the CertStatus value in the most recent TrustResponse but MAY 628 choose to ignore it. If the CertStatus in both TrustResponses are the 629 same, the originator should disregard the second TrustResponse. 631 If the originator receives a CEM Response message which violates the 632 rules listed above or is invalid in any way, the originator MAY 633 reject the message entirely but MUST return an MDN if requested. 635 3. 636 CEM XML Schema Description 638 The CEM schema has two top-level elements, 639 EDIINTCertificateExchangeRequest and 640 EDIINTCertificateExchangeResponse. The 641 EDIINTCertificateExchangeRequest element is present only in the CEM 642 Request message, and the EDIINTCertificateExchangeResponse is present 643 only in the CEM Response message. All other elements nest directly or 644 indirectly from these. CEM XML data must be well-formed and valid 645 relative to the CEM XML Schema. Please refer to the appendix for the 646 actual schema document. 648 3.1 649 EDIINTCertificateExchangeRequest element 651 EDIINTCertificateExchangeRequest contains element TradingPartnerInfo, 652 which can only appear once, and TrustRequest, which may be present 653 multiple times. TrustRequest contains information on a certificate 654 and its intended usage. TradingPartnerInfo exists to provide 655 information on the publication of the CEM Request message since 656 processing of the XML data may occur apart from the handling of the 657 accompanying transport message, for example the AS2 request. 659 660 661 662 663 666 668 669 672 Draft CEM for EDIINT February 2008 674 675 676 678 EDIINTCertificateExchangeRequest also contains the attribute 679 requestId. RequestId uniquely identifies each CEM Request message. 680 Its value MUST be between 1 and 255 characters. The requestId is 681 returned in the CEM Response message to assist the UA in matching the 682 CEM Response with the CEM Request. 684 685 686 687 688 689 691 An optional Extension element is also present along with the 692 anyAttribute attribute. They exist to provide future extendibility 693 for new features which may be developed but not yet defined within 694 CEM. They are present in several locations in the schema for this 695 future extendibility. 697 698 699 700 702 703 704 706 TradingPartnerInfo identifies the entity that created the CEM message 707 through the nested Name element. Both the qualifier attribute and the 708 element value of Name follow mandatory naming conventions. The 709 qualifier attribute is to be the transport standard utilized. For 710 example, "AS1", "AS2" or "AS3". The value of the Name element is the 711 same value in the From header utilized by the transport. For AS2 and 712 AS3, this is the value in the AS2-From and AS3-From headers, 713 respectively. For AS1, this is the value of the From header. If other 714 transports besides AS1, AS2, AS3 are used, the same naming convention 715 SHOULD be followed. 717 MessageOriginated is included in TradingPartnerInfo to identify the 718 time and date the message was created. The MessageOriginated date and 719 time values MUST follow XML standard dateTime type syntax and be 720 listed to at least the nearest second and expressed in local time 721 with UTC offset. For example, a message originating from the US 722 Eastern Standard timezone would use 2005-03-01T14:05:00-05:00. 724 Draft CEM for EDIINT February 2008 726 727 728 729 730 731 732 733 735 736 737 738 739 740 742 743 744 745 747 The TrustRequest element contains the EndEntity, CertUsage, 748 RespondByDate and ResponseURL elements. The required EndEntity 749 element is found only once in a TrustRequest element and contains the 750 content-id reference to the end-entity certificate being exchanged. 752 753 754 755 756 757 758 760 761 762 764 EndEntity contains the nested elements of CertificateIdentifier and 765 CertificateContentID. CertificateContentID is a string element which 766 references the content-id of the multipart/related structure where 767 the certificate is stored. CertificateIdentifier comes from the XML 768 Signature schema namespace [XML-DSIG]. 770 771 772 775 Draft CEM for EDIINT February 2008 777 778 780 781 782 784 CertificateIdentifier contains the string element X509IssuerName and 785 the integer element X509SerialNumber. X509SerialNumber is the 786 assigned serial number of the end entity certificate as it is listed. 787 X509IssuerName contains the issuer name information of the end-entity 788 certificate, such as common name, organization, etc. This information 789 MUST be described in a string format per the rules of RFC 2253 790 [RFC2253]. This results in the attributes within the Issuer Name to 791 be listed with their attribute type followed by an "=" and the 792 attribute value. Each attribute type and value are separated by a "," 793 and any escape characters in the value are preceded by a "\". Refer 794 to the appendix and the sample CEM Request message for an example of 795 the X509IssuerName. 797 798 799 800 801 802 804 CertUsage is an unbounded element which contains enumerated values on 805 how the exchanged certificate is to be used. There are enumerated 806 values for SMIME digital signatures (digitalSignature), SMIME data 807 encryption (keyEncipherment), the server certificate used in TLS 808 transport encryption (tlsServer) and the client certificate used in 809 TLS transport encryption (tlsClient). While the element is unbounded, 810 CertUsage only has a potential number of four occurrences due to the 811 limit of the enumerated values. 813 814 815 816 817 818 819 820 821 823 RespondByDate is a required element of the XML standard dateTime type 824 expressed in local time with UTC offset, which provides information 825 on when the certificate should be trusted, inserted into the trading 827 Draft CEM for EDIINT February 2008 829 partner relationship and responded to by a CEM Response message. If 830 the certificate can not be trusted or inserted into the trading 831 partner relationship, the CEM Response message should still be 832 returned by the date indicated. 834 836 ResponseURL is an element which indicates where the CEM Response 837 message should be sent. This value takes precedence over the existing 838 inbound URL of the current trading partner relationship. The Response 839 MUST use the same transport protocol (AS1, AS2, or AS3) as the 840 Request. 841 843 3.2 844 EDIINTCertificateExchangeResponse element 846 EDIINTCertificateExchangeResponse contains the two elements 847 TradingPartnerInfo and TrustResponse and the attribute requestId. 848 TradingPartnerInfo, which is also found in 849 EDIINTCertificateExchangeRequest, describes the trading partner 850 generating this response message. TrustResponse provides information 851 on the acceptance of a previously sent end entity certificate. There 852 can be multiple TrustResponse elements within an 853 EDIINTCertificateExchangeResponse. The requestId is the same value 854 from a previously sent CEM Request message. The requestId from the 855 CEM Response is matched up with the CEM Request. 857 858 859 860 861 864 866 867 869 870 871 873 874 875 876 877 880 Draft CEM for EDIINT February 2008 882 884 885 886 888 A TrustResponse element identifies a certificate which has been 889 previously exchanged within the trading partner relationship through 890 a CEM Request and now has been either accepted or rejected by the 891 partner. The CertificateReference element is of the same type as the 892 CertificateIdentifier element. A CertificateReference element in a 893 CEM Response MUST be identical to its CertificateIdentifier 894 counterpart in the associated CEM Request since they identify the 895 same certificate in question. 897 The required element CertStatus has the enumerated values of 898 "Accepted" or "Rejected". "Accepted" indicates the certificate was 899 trusted by the trading partner and is now ready for use within the 900 trading partner relationship, and "Rejected" indicates the 901 certificate is not trusted by the trading partner nor can it be 902 currently used with the trading partner relationship. If the value of 903 "Rejected" is chosen, the optional string element ReasonForRejection 904 may be included. If present, ReasonForRejection should contain a 905 brief description of why the certificate was not accepted. Since the 906 value for this element is not enumerated but open, it MUST be 907 interpreted through human means. 909 910 911 912 913 914 915 916 918 4. 919 Use Case Scenario 921 This scenario illustrates how the CEM Request and CEM Response 922 messages described in Section 2 and 3 can be used to exchange 923 certificates. The scenario is only illustrative and any differences 924 between it and the rules above should defer to the rules in Section 2 925 and 3. 927 Two trading partners, Alpha Arrows and Bravo Bows, have an 928 established trading partner relationship using AS2. Alpha Arrows is 929 using a single certificate, CertA, for both digital signatures and 930 data encryption. Alpha Arrows wants to issue a new certificate, 931 CertB, for digital signatures but keep CertA for data encryption. 933 Draft CEM for EDIINT February 2008 935 Bravo Bows is using one certificate, Cert1, for digital signatures 936 and another certificate, Cert2, for data encryption. Bravo Bows wants 937 to introduce a new certificate, Cert3, for digital signature and a 938 new certificate, Cert4, for data encryption. 940 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only 941 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows 942 immediately returns the MDN but must make an internal security 943 decision before accepting CertB. 945 2. While waiting for a CEM Response, Alpha Arrows continues to send 946 AS2 messages to Bravo Bows which have been signed using CertA. The 947 messages originating from Bravo Bows are encrypted using CertA. 949 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus 950 of "Accepted" for CertB. Upon receipt, an MDN is returned which is 951 signed using CertA. Bravo Bows MUST be able to accept the MDN if it 952 has a digital signature from either CertA or CertB as Alpha Arrows 953 may not be able to switch certificates simply upon receipt of the CEM 954 Response message without parsing the XML payload. Also, Alpha Arrows 955 may need to wait for CEM Responses from other trading partners before 956 switching to the new CertB. However, as soon as possible, Alpha 957 Arrows should use CertB exclusively for digital signatures. 959 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both 960 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are 961 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows 962 returns an MDN immediately. Bravo Bows is now prepared to receive any 963 inbound messages encrypted by either Cert2 or Cert4, but all its 964 digital signatures are still done through Cert1. 966 5. Eventually, Alpha Arrows returns a single CEM Response message. It 967 contains two TrustResponse elements: one for Cert3 and another for 968 Cert4. The CertStatus for Cert3 is "Rejected" with the 969 ReasonForRejection field present and populated with the string 970 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted." 971 Bravo Bows returns the MDN signed through Cert1. 973 6. Immediately after this, an AS2 message is received from Alpha 974 Arrows which is encrypted using Cert4, and Bravo Bows is able to 975 decrypt the message successfully. Because Alpha Arrows rejected 976 Cert3, Bravo Bows is only using Cert1 for digital signatures and 977 returns the MDN signed with Cert1. 979 7. After creating a new certificate, Cert5, which corrects the 980 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request. 982 Draft CEM for EDIINT February 2008 984 8. Shortly after this, Alpha Arrows sends a CEM Response message for 985 Cert5. It contains a CertStatus of "Accepted". This CEM Response 986 message was encrypted using Cert4, but Bravo Bows was prepared for 987 encryption from either Cert2 or Cert4. The message is processed and a 988 good MDN is returned signed with Cert1. While, Bravo Bows can now 989 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows 990 should use Cert5 exclusively as soon as possible. 992 5. 993 Profile Exchange Messaging 995 CEM provides the means to exchange certificates among trading 996 partners. However, other profile information, such as URLs and 997 preferred security settings, is needed to create a trading partner 998 relationship. A future standard is needed to describe profile 999 descriptions and how they will be exchanged. The format for this 1000 profile attachment is not defined in this specification but is 1001 planned for a future document. It will build upon the existing CEM 1002 protocol with profile information stored with XML data. Both 1003 certificate and profile description information will be placed into a 1004 multipart/related [RFC2387] body part entity. A possible format for a 1005 profile description message is as follows: 1007 Various EDIINT headers 1008 EDIINT-Features: profile-exchange 1009 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 1010 Disposition-Notification-Options: signed-receipt-protocol=optional, 1011 pkcs7-signature; signed-receipt-micalg=optional, sha1 1012 Content-Type: multipart/signed; micalg=sha1; 1013 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 1015 ----BOUNDARY1 1016 Content-Type: multipart/related; 1017 start=""; 1018 type="application/ediint-cert-exchange+xml"; 1019 boundary="--BOUNDARY2" 1021 ----BOUNDARY2 1022 Content-Type: application/ediint-cert-exchange+xml 1023 Content-ID: 1025 [CEM XML data] 1026 ----BOUNDARY2 1027 [Profile information attachment] 1028 ----BOUNDARY2-- 1029 ----BOUNDARY1 1031 Content-Type: application/pkcs7-signature 1033 Draft CEM for EDIINT February 2008 1035 [Digital Signature] 1036 ----BOUNDARY1-- 1038 6. 1039 Implementation Considerations 1041 This section contains various points to explain practical 1042 implementation considerations. 1044 * If the EDIINT transport message carrying a CEM Request or CEM 1045 Response fails resulting in a negative MDN, the CEM message, its 1046 contents and instructions are to be ignored. The User Agent receiving 1047 the negative MDN is to consider the CEM message to be ignored and 1048 retransmit as needed. 1050 * While a single end-entity certificate can be only be used once in a 1051 single CEM Request message, the same certificate can be sent multiple 1052 times in multiple CEM Request messages. The requestId is used for 1053 matching the CEM Request and CEM Response messages. 1055 * Certificate usage is cumulative. Thus, if a User Agent receives a 1056 valid CEM Request message with Certificate A with certUsage set to 1057 digitalSignature and then a second valid CEM Request message with 1058 Certificate A with certUsage set to keyEncipherment, then the User 1059 Agent MUST configure the certificate to be used both for 1060 digitalSignature and keyEncipherment. As well, if at a later time a 1061 valid CEM Request message is received with Certificate A with 1062 certUsage set only to digitalSignature, Certificate A is still valid 1063 for keyEncipherment. 1065 7. 1066 Future Considerations for CEM I-D 1067 This section contains ideas for consideration in future versions of 1068 CEM and addressed in the future. If deemed necessary, they will be 1069 added into the I-D else they will be removed. This section will be 1070 removed prior to RFC submission. 1072 8. 1073 Security Considerations 1075 Certificate exchange is safe for transmitting. However, implementers 1076 SHOULD verify the received certificate to determine if it is truly 1077 from the stated originator through out-of-band means or whenever the 1078 request is not signed. 1080 Draft CEM for EDIINT February 2008 1082 9. 1083 IANA Considerations 1085 MIME Media type name: Application 1087 MIME subtype name: EDIINT-cert-exchange+xml 1089 Required parameters: None 1091 Optional parameters: This parameter has identical semantics to the 1092 charset parameter of the "application/xml" media type as specified 1093 in [RFC3023]. 1095 Encoding considerations: Identical to those of "application/xml" as 1096 described in [RFC3023], section 3.2. 1098 Security considerations: See section 6. 1100 Interoperability Considerations: See section 2.2 1102 Published specification: This document. 1104 Applications which use this media type: EDIINT applications, such as 1105 AS1, AS2 and AS3 implementations. 1107 Additional Information: None 1109 Intended Usage: Common 1111 Author/Change controller: See Author's section of this document. 1113 10. 1114 References 1115 10.1 1116 Normative References 1118 [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data 1119 Interchange over the Internet using SMTP", T. Harding, R. 1120 Drummond, C. Shih, 2002. 1122 [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data 1123 Interchange over the Internet using HTTP", D. Moberg, R. 1124 Drummond, 2005. 1126 [AS3] draft-ietf-ediint-as3-05.txt "MIME-based Secure Peer-to-Peer 1127 Business Data Interchange over the Internet using FTP", T. 1128 Harding, R. Scott, 2003. 1130 [EDIINT FEATURE] draft-meadors-ediint-feature-header-01.txt "Feature 1131 Header for EDI-INT", K. Meadors, 2006. 1133 Draft CEM for EDIINT February 2008 1135 [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement 1136 Levels", S.Bradner, March 1997. 1138 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen, 1139 January 1999. 1141 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8 1142 String Representation of Distinguished Names", M. Wahl, S. Kille 1143 and T. Howes, Decemeber 1997. 1145 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 1146 Levinson, August 1998. 1148 [RFC2828] RFC2828 "Internet Security Glossary", R. Shirley, May 2000. 1150 [RFC3023] RFC3023 "XML Media Types", M. Murata, January 2001. 1152 [XML-DSIG] RFC3275 "XML-Signature Syntax and Processing", D. 1153 Eastlake, March 2002. 1155 [X.520] ITU-T Recommendation X.520: Information Technology - Open 1156 Systems Interconnection - The Directory: Selected Attribute 1157 Types, 1993. 1159 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1160 X.509 Public Key Infrastructure: Certificate and CRL Profile", 1161 RFC 3280, April 2002. 1163 10.2 1164 Informative References 1166 11. 1167 Acknowledgments 1169 The authors wish to extend gratitude to the ecGIF sub-committee 1170 within the GS1 organization from which this effort began. Many have 1171 contributed to the development of this specification, but some 1172 deserve special recognition. John Duker who chaired the sub-committee 1173 and provided valuable editing. John Koehring with his work on the 1174 reference ID and shared important insights on implementation. Aaron 1175 Gomez in the coordinating of vendors testing CEM. Richard Bigelow who 1176 greatly assisted development of the ideas presented, and Debra Petta 1177 for her review and comments. 1179 Author's Addresses 1181 Kyle Meadors 1182 Drummond Group Inc. 1183 4700 Bryant Irvin Court, Suite 303 1184 Fort Worth, TX 76107 USA 1185 Email: kyle@drummondgroup.com 1187 Draft CEM for EDIINT February 2008 1189 Dale Moberg 1190 Axway, Inc. 1191 8388 E. Hartford Drive, Suite 100 1192 Scottsdale, AZ 85255 USA 1193 Email: dmoberg@us.axway.com 1195 Copyright Notice 1196 Copyright (C) The IETF Trust (2008). 1198 This document is subject to the rights, licenses and restrictions 1199 contained in BCP 78, and except as set forth therein, the authors 1200 retain all their rights. 1202 This document and the information contained herein are provided on an 1203 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1204 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1205 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1206 OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1207 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1208 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1210 Appendix 1212 A.1 EDIINT Certificate Exchange XML Schema 1214 1215 1221 1223 1224 1225 1226 1227 1229 1231 1232 1234 1235 1237 Draft CEM for EDIINT February 2008 1239 1240 1241 1242 1243 1244 1246 1248 1249 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1263 1264 1265 1266 1267 1268 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1289 Draft CEM for EDIINT February 2008 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1306 1307 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1320 1321 1322 1323 1324 1325 1326 1327 1329 1331 1332 1333 1334 1335 1336 1337 1339 1341 Draft CEM for EDIINT February 2008 1343 1344 1345 1347 A.2 Example of EDIINT Certificate Exchange Request XML 1349 1350 1355 1356 DGI_Test_CEM 1357 1358 2005-08-30T00:30:00-05:00 1359 1360 1361 keyEncipherment 1362 digitalSignature 1363 2005-09-30T12:00:00-05:00 1364 http://10.1.1.1/as2 1365 1366 1367 CN=Cleo- 1368 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1369 Worth,S=Texas,C=US 1370 9659684611094873474886 1371 1372 1373 SignEncCert-Example_vs02@example.org 1374 1375 1376 1377 tlsServer 1378 2005-09-30T12:00:00-05:00 1379 http://10.1.1.1/as2 1380 1381 1382 CN=VeriSign Class 1 CA Individual 1383 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1384 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1385 Inc. 1386 2673611014597817669550861744279966682 1388 1389 1390 SSLCert-Example_vs02@example.org 1391 1393 Draft CEM for EDIINT February 2008 1395 1396 1398 A.3 Example of EDIINT Certificate Exchange Response XML 1400 1401 1406 1407 DGI_Test_CEM_Trading_Partner 1408 1409 2005-08-31T00:21:00-05:00 1410 1411 1412 Accepted 1413 1414 CN=Cleo- 1415 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1416 Worth,S=Texas,C=US 1417 9659684611094873474886 1418 1419 1420 1421 Accepted 1422 1423 CN=VeriSign Class 1 CA Individual 1424 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1425 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1426 Inc. 1427 2673611014597817669550861744279966682 1429 1430 1431 1433 Changes from Previous Versions 1435 B.1 Updates from Version 00 1437 . Updated security requirements in section 2.1, specifically in 1438 regards to digital signatures. 1439 . The XML element responseURL is now required. Modified section 1440 3.1 and example messages in appendix accordingly. 1441 . Certificates are exchanged within a full P7C cert chain. Section 1442 2.3 reflects this. 1444 Draft CEM for EDIINT February 2008 1446 . The XML element TrustChain is not longer necessary since the 1447 entire cert chain is stored. Removed references in schema and 1448 document. 1449 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be 1450 sent and that if this occurs, the action of the CEM Request 1451 initiator is not defined. 1452 . Updated the examples in Appendix B to reflect the current usage. 1454 B.2 Updates from Version 01 1456 . Added information for handling different scenarios with CEM 1457 Response message. 1458 . Rewrote use case scenarios. 1459 . Added the EDIINT Features header information. 1461 B.3 Updates from Version 02 1463 . Modified use of SSL certificates to match real-world needs. 1464 . Modified schema in changing namespace value and removed schema 1465 location. 1466 . Added statement that CEM XML must be well-formed and valid to 1467 schema. 1468 . Modified Use Case to correct an error and improve clarity. 1469 . Added section 1.4 to describe CEM process. 1471 B.4 Updates from Version 03 1472 . None. Update done because vs03 expired. 1474 B.5 Updates from Version 04 1475 . Clarified requirement of using multipart/related for CEM 1476 Response. 1477 . Added sections on Implementation Considerations and Future 1478 Implementation. 1479 . Modified schema to allow future extensions. 1480 . Changed requirements on qualifier attribute in the Name 1481 element. 1482 . Changed functionality to allow error MDN to be returned when 1483 CEM XML can not be parsed. 1485 B.6 Updates from Version 05 1486 . Added requestId to CEM. 1487 . Removed normative reference to RFC 3821. 1489 B.7 Updates from Version 06/07 1490 . None. Updated for 6-month I-D expiration.