idnits 2.17.1 draft-meadors-certificate-exchange-04.txt: -(162): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(772): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(777): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(926): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(964): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(967): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(980): 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. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1036. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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-04' == There are 31 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 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 581 has weird spacing: '...elative to th...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 2006) is 6366 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) == Missing Reference: '3851' is mentioned on line 349, but not defined == Missing Reference: 'EDIINT-FEATURE' is mentioned on line 408, but not defined == Unused Reference: 'EDIINT FEATURE' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 967, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 970, but no explicit reference was found in the text == Unused Reference: '3821' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'PROFILE' is defined on line 994, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-ediint-as3-02 ** 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: 15 errors (**), 1 flaw (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft CEM for EDIINT November 2006 3 Private K. Meadors 4 Internet-Draft Drummond Group Inc. 5 Document: draft-meadors-certificate-exchange- D. Moberg 6 04.txt Cyclone Commerce 7 Expires: May 2006 November 2006 9 Certificate Exchange Messaging for EDIINT 10 draft-meadors-certificate-exchange-04.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 47 Draft CEM for EDIINT November 2006 49 certificates for use within trading partner relationships. The 50 messaging consists of two types of messages, Request and Response, 51 which allow trading partners to communicate certificates, their 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..............................................11 94 3. CEM XML Schema Description....................................12 95 3.1 EDIINTCertificateExchangeRequest element..................12 97 Draft CEM for EDIINT November 2006 99 3.2 EDIINTCertificateExchangeResponse element.................15 100 4. Use Case Scenario.............................................16 101 5. Profile Exchange Messaging....................................18 102 6. Security Considerations.......................................18 103 7. IANA Considerations...........................................19 104 8. References....................................................19 105 8.1 Normative References......................................19 106 8.2 Informative References....................................20 107 9. Acknowledgments...............................................20 108 Author's Addresses...............................................21 109 Appendix.........................................................21 110 A.1 EDIINT Certificate Exchange XML Schema....................21 111 A.2 Example of EDIINT Certificate Exchange Request XML........23 112 A.3 Example of EDIINT Certificate Exchange Response XML.......24 113 Changes from Previous Versions...................................25 114 B.1 Updates from Version 00...................................25 115 B.2 Updates from Version 01...................................25 116 B.3 Updates from Version 02...................................25 118 1. Introduction 120 1.1 Overview 122 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 123 numerous supply-chains was due in part to the security feature which 124 was provided. The security is not possible without the digital 125 certificates which enable it. To maintain the level of security 126 necessary to transmit business documentation, existing certificates 127 must occasionally be replaced and exchanged with newer ones. The 128 exchanging of digital certificates is unavoidable given how 129 certificates can expire or become compromised. Complicating this is 130 supply-chains which cannot afford to shutdown their business 131 transactions while trading partners laboriously upload new 132 certificates. Certificate exchange must be accomplished in a reliable 133 and seamless format so as not to affect ongoing business 134 transactions. 136 This document describes how EDIINT products may exchange public-key 137 certificates. Since EDIINT is built upon the security provided by 138 public-private key pairs, it is vital that implementers are able to 139 update their trading partners with new certificates as their old 140 certificates expire, become outdated or insecure. Certificate 141 Exchange Messaging (CEM) described here utilizes XML data to exchange 142 the certificate and provide information on its intended usage and 143 acceptance within the trading partner relationship. There are two 144 types of CEM messages, the CEM Request which presents the new 145 certificate to be introduced into the trading partner relationship 146 and the CEM Response which is the recipient�s response to the CEM 148 Draft CEM for EDIINT November 2006 150 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 151 AS3 [AS3] message transports. However, it is possible to leverage CE 152 messaging through other transport standards besides EDIINT. 154 1.2 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 200 Draft CEM for EDIINT November 2006 202 the CEM Request indicating whether or not the end entity certificate 203 present in the CEM Request was accepted. 205 End Entity - A system entity that is the subject of a public-key 206 certificate and that is using, or is permitted and able to use, the 207 matching private key only for a purpose or purposes other than 208 signing a digital certificate; i.e., an entity that is not a CA. 209 [RFC2828] 211 End Entity Certificate - A certificate which is used to encrypt data 212 or authenticate a signature. (The private key associated with the 213 certificate is used to decrypt data or sign data). The certificate 214 may be self-signed or issued by a trusted certificate. 216 Intermediary Certificate - A certificate issued by a CA certificate 217 which itself issues another certificate (either intermediary or end 218 entity). Intermediary certificates are not used to encrypt data but 219 to sign other certificates. 221 Public Key - The publicly-disclosable component of a pair of 222 cryptographic keys used for asymmetric cryptography. [RFC2828] 224 Public Key Certificate - A digital certificate that binds a system 225 entity's identity to a public key value, and possibly to additional 226 data items. [RFC2828] 228 Self-signed Certificate - A certificate which is issued by itself 229 (both issuer and subject are the same) and is an End Entity 230 certificate. 232 1.3 Certificate Lifecycle 234 A certificate has five states. 236 1. Pending - Upon receiving a certificate from a trading partner, the 237 certificate is marked as Pending until a decision can be made to 238 trust it or if its validity period has not yet begun. 239 2. Rejected - If a Pending certificate is not trusted, it is 240 considered Rejected. 241 3. Accepted - Once a Pending certificate has been trusted, it is 242 considered Accepted. An Accepted certificate may be used in 243 secure transactions. 244 4. Expired - A certificate which is no longer valid because its 245 expiration date has passed. Expired certificates SHOULD be kept 246 in a certificate storehouse for decrypting and validating past 247 transactions. 248 5. Revoked - A certificate which has been explicitly revoked by its 249 owner or the certificate authority. 251 Draft CEM for EDIINT November 2006 253 1.4 Certificate Exchange Process 255 This section describes a process whereby a company can distribute 256 certificates to its partners, and the company and its partners can 257 put the certificates into use. Later sections describe the specific 258 CEM protocol, which is an implementation of this process. 260 The exchange process can be used even when CEM is not useable, for 261 example, when the transport protocols or installed software systems 262 do not support CEM. It is RECOMMENDED that this process be followed 263 in distributing certificates. 265 The exchange process covers the update of certificates. It is 266 assumed that certificates have already been distributed and are in 267 use for signing or encrypting messages. The process describes how to 268 replace those certificates with new ones. 270 The company that owns the certificates initiates the process. For a 271 certificate that is to be used (by the partners) to encrypt messages, 272 the initiator first prepares his system to decrypt messages that are 273 encrypted with this certificate. The initiator must also be able to 274 decrypt messages using the old certificate. The initiator company 275 distributes the new certificates by some means. The distribution 276 MUST describe the purposes of the certificates and MAY contain an in- 277 use date, the date when the distributor expects to put the 278 certificates in use. The in-use date SHOULD be present for 279 certificates that are used to sign messages or to authenticate 280 TLS/SSL connections. 282 When a partner receives a certificate, the partner should 283 authenticate the distribution message by some means. (CEM provides 284 for automatic authentication. Partners can use manual methods, 285 either with or without CEM.) 287 When a partner receives a certificate for use in encrypting messages 288 and has authenticated the certificate, the partner should begin using 289 that certificate to encrypt messages. The initiator MUST be prepared 290 to receive messages encrypted with either the old or new certificate. 292 When a partner receives a certificate for use in digitally signing 293 messages or for TLS/SSL authentication and has authenticated the 294 certificate, the partner MUST prepare his system to accept messages 295 that are signed or authenticated with the new certificate. The 296 partner MUST also accept messages signed or authenticated with the 297 old certificate. 299 The partner MAY return a response to the initiator, indicating that 300 the partner has accepted the new certificate and put it in use. The 302 Draft CEM for EDIINT November 2006 304 initiator can use these responses to track which partners are ready 305 to use the new certificate. 307 When the partner has sent a response indicating acceptance of the new 308 certificate, or when the in-use date has passed, the initiator can 309 begin using the new certificate to digitally sign messages or 310 authenticate TLS/SSL messages. The initiator MUST NOT sign or 311 authenticate messages with the new certificate until the partner has 312 accepted it or until the in-use date has passed. The initiator may 313 wait until the in-use date or until all partners have accepted. The 314 partners MUST accept messages signed or authenticated with either the 315 old or new certificate. 317 When the process is fully automated, it is not necessary to have a 318 specific time when both the initiator and partners switch to the new 319 certificate. 321 The initiator MUST be able to decrypt messages with both the old and 322 new certificates as soon as the new certificates are distributed. 323 The partners MUST be able to accept messages signed or TLS/SSL 324 authenticated with either the old or new certificates after they have 325 accepted the new certificate. The initiator SHOULD allow a 326 reasonable time after distributing a new signing or authenticating 327 certificate before putting it in use, so that partners have time to 328 authenticate the new certificate and prepare their systems for it. 330 For a certificate used to digitally sign messages or authenticate 331 TLS/SSL messages, there must be some way for the initiator to know 332 when partners are ready to receive the certificate. For example, 333 this may be a response from the partners, an explicit in-use date in 334 the initial distribution, an implied in-use date based on partner 335 agreements, or the expiration date of the old certificate. For a 336 certificate used to encrypt messages, the in-use date and responses 337 are less important, but responses may be useful to track partners� 338 acceptances. 340 2. Message Processing 342 2.1 Message Structure 344 CEM messages use the underlying EDIINT transport, such as AS2, to 345 communicate information on the certificate, its intended use and its 346 acceptance. Both digital certifications and the XML data describing 347 their intended use are stored within a multipart-related MIME 348 envelope [RFC2387]. The certificates are stored in certificate chains 349 through SMIME, certs-only MIME envelope [3851], and processing 350 information is XML data which is identified through the MIME content- 352 Draft CEM for EDIINT November 2006 354 type of application/ediint-cert-exchange+xml. The format for CEM 355 messages is as follows: 357 Various EDIINT headers 358 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 359 Content-Type: multipart/signed; micalg=sha1; 360 protocol="application/pkcs7-signature"; 361 boundary="--OUTER-BOUNDARY" 363 ----OUTER-BOUNDARY 364 Content-Type: multipart/related; type=" application/ediint-cert- 365 exchange+xml"; boundary="--INNER-BOUNDARY" 367 ----INNER-BOUNDARY 368 Content-Type: application/ediint-cert-exchange+xml 369 Content-ID: <20040101-1.alpha@example.org> 371 [CEM XML data] 372 ----INNER-BOUNDARY 373 Content-Type: application/pkcs7-mime; smime-type=certs-only 374 Content-ID: <20040101-2.alpha@example.org> 376 [digital certificate] 377 ----INNER-BOUNDARY-- 379 ----OUTER-BOUNDARY 380 Content-Type: application/pkcs7-signature 382 [Digital Signature] 383 ----OUTER-BOUNDARY-- 385 One and only one MIME type of application/ediint-cert-exchange+xml 386 MUST be present in the multipart/related structure, and it MUST be 387 the root element. Multiple certs-only media types may be included, 388 but at least one MUST be present. A unique content-id header MUST be 389 present within each of the multipart structures. 391 If possible, both the CEM Request and CEM Response message SHOULD be 392 signed. Applying digital signatures will allow for automatic exchange 393 based on a previous trust relationship. However, it may not be 394 possible in the initial exchange of a new trading partner. If a CEM 395 message is signed, the signing certificate MUST be included in the 396 digital signature. Extra security such as applying data encryption or 397 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and 398 SHOULD request a signed MDN. The MDN can be either synchronous or 399 asynchronous. The MDN response verifies the transport delivery but is 400 not equivalent to the CEM Response message. All necessary headers 401 MUST be applied to the message per the underlying transport standard. 403 Draft CEM for EDIINT November 2006 405 2.2 EDIINT Features Header 407 To indicate support for CEM, an EDIINT application MUST use the 408 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates 409 the instance application can support various features, such as 410 certification exchange. The header is present in all messages from 411 the instance application, not just those which feature certification 412 exchange. 414 For applications implementing certification exchange, the CEM- 415 Feature-Name MUST be used within the EDIINT Features header: 417 CEM-Feature-Name = "CEM" 419 2.3 Certificate Exchanging 421 After obtaining the desired certificate, the initiator of the 422 certificate exchange transmits the end-entity certificate in the CEM 423 Request message. If the end-entity certificate is not self-signed, 424 then the CA certificate and any other certificates needed to create 425 the chain of trust for the end-entity certificate MUST be included in 426 the CEM Request message. Multiple end-entity certificates MAY also be 427 present. 429 The entire certificate trust chain is stored in a BER encoded P7C 430 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- 431 only MIME envelope which is then stored in a single part of the 432 multipart/related structure. Each P7C trust chain MUST include a 433 single end-entity certificate and its trust authorities. No other 434 certificates are to be part of this chain. The number of P7C trust 435 chains in a CEM Request message MUST be equal to the number of end- 436 entity certificates being communicated in the CEM XML document. 437 If different end-entity certificates have common trust authorities 438 certificates, each P7C cert chain still MUST included each 439 certificate necessary to create a trust anchor. Thus, if a recipient 440 can not create a trust relationship from the P7C cert chain, it MAY 441 reject the end-entity certificate in the CEM Request. 443 End-entity certificates are referenced and identified in the XML data 444 by their content-id used in the multipart-related structure. 445 Information on how the certificate is to be used, or certificate 446 usage, by the receiving user agent and other related information is 447 found in the XML data. A certificate can be used for a single 448 function, like digital signatures, or used for multiple functions, 449 such as both digital signatures and data encryption. If a certificate 450 is intended for multiple usages, such as for both digital signatures 451 and data encryption, the certificate MUST be listed only once in the 452 CEM Request message and its multiple usage listed through the 453 CertUsage XML element. 455 Draft CEM for EDIINT November 2006 457 Upon receipt of the CEM Request, the recipient trading partner 458 processes the transport message as normal and returns the MDN. The 459 recipient MUST return the MDN before parsing and interpreting the CEM 460 XML data or certificate chains. The returned MDN only provides 461 information on the veracity of the transport message and not the 462 acceptance of the certificate(s) being exchanged. 464 2.4 Certificate Implementation 466 The new certificate is considered to be in the Pending state for the 467 recipient who MUST decide whether to accept the certificate as 468 trustworthy. This decision is arbitrary and left to each individual 469 trading partner. Upon accepting the certificate, it is to be 470 considered an Accepted certificate within the trading partner 471 relationship. If the certificate is not accepted, it is considered 472 Rejected. 474 When a certificate is intended for use in data encryption, the 475 initiator MUST consider the certificate to be Accepted and be 476 prepared for its trading partner to begin using the certificate upon 477 generating the CEM Request message. After a recipient generates a 478 positive CEM Response message for a certificate, the recipient MUST 479 immediately begin using the certificate in trading with the initiator 480 of the request. The recipient MAY apply encryption to the CEM 481 Response message using the new Accepted certificate or MAY apply 482 encryption to the CEM Response message using the previously Accepted 483 encryption certificate. 485 When a certificate is intended for use in digital signatures or 486 TLS/SSL authentication, the initiator MUST NOT use the certificate 487 until the recipient trading partner generates a CEM Response 488 accepting the certificate or the respond by date, which is listed in 489 the RespondByDate XML element. The initiator MAY use the certificate 490 after the respond by date, regardless of whether the partner has 491 accepted it or not. The certificate used for the digital signature of 492 the CEM Request message MUST be the one which is currently Accepted 493 within the trading partner relationship. 495 Since implementers of EDIINT often use the same certificate with 496 multiple trading partners, implementers of CEM MUST be able to keep 497 both the old and new certificates as Accepted. If the initiator has 498 generated a CEM Request and exchanged a new encryption certificate to 499 multiple trading partners, it MUST be able to accept encrypted data 500 which uses either the older, existing encryption certificate or the 501 newly exchanged encryption certificate. Likewise, a recipient of a 502 CEM Request MUST be able to authenticate digital signatures using 503 either the new or old certificates, since the initiator may not be 505 Draft CEM for EDIINT November 2006 507 able to switch certificates until all trading partners accept the new 508 certificate. Similar provisions MUST be made for certificates 509 intended for TLS/SSL server and client authentication. Revoking a 510 certificate MUST be done outside of CEM. 512 If a CEM Request message contains a certificate which is currently 513 Accepted and has the identical usage for the certificate that has 514 been Accepted, the recipient MUST NOT reject the duplicate 515 certificate but MUST respond with a CEM Response message indicating 516 the certificate has been accepted. For example, if Certificate A is 517 currently Accepted as the encryption certificate for a user agent, 518 any CEM Request message containing Certificate A with the usage as 519 encryption only MUST be accepted by an existing trading partner. This 520 situation may be necessary for an implementation intending to verify 521 its current trading partner certificate. 523 If two trading partners utilize multiple EDIINT protocols for 524 trading, such as AS2 for a primary transport and AS1 as the backup 525 transport, it is dependent upon implementation and trading partner 526 agreement how CEM messages are sent and which transports the 527 exchanged certificates affect. 529 2.5 CEM Response 531 The CEM Response message contains a TrustResponse XML element. 532 TrustResponse provides information needed to match the end-entity 533 certificate sent in an earlier CEM Request and indicate if the 534 certificate was accepted or rejected by the recipient. The 535 CertificateReference in a TrustResponse matches the 536 CertificateIdentifier value for the end-entity certificate in the CEM 537 Request. CertStatus indicates if the certificate was accepted or 538 rejected. If a CEM Request is received, the recipient MUST respond 539 with a CEM Response message indicating if the certificate is Accepted 540 or Rejected. More information about the XML attributes and value for 541 CEM Response can be found in 3.2. 543 If the certificate in the CEM Request message contains multiple 544 usages, such as for both digital signature and data encryption, only 545 a single TrustResponse is needed for that certificate. The CertStatus 546 value in the TrustResponse is the response for both usages of the 547 certificate. A recipient can NOT choose to accept the certificate for 548 one specified use and not the other. 550 If multiple end-entity certificates were included within the CEM 551 Request, the recipient MAY generate individual CEM Response messages 552 for each certificate or the recipient MAY consolidate the 553 TrustResponse for multiple certificates into one CEM Response 554 message. A CEM Response may contain multiple TrustResponse elements 556 Draft CEM for EDIINT November 2006 558 for different certificates but MUST NOT contain two or more 559 TrustResponses for the same certificate. 561 If a second TrustResponses is received in different message matching 562 the same certificate as that of an earlier TrustRespnse but the 563 CertStatus have a different value than the other, the originator MAY 564 accept the CertStatus value in the most recent TrustResponse but MAY 565 choose to ignore it. If the CertStatus in both TrustResponses are the 566 same, the originator should disregard the second TrustResponse. 568 If the originator receives a CEM Response message which violates the 569 rules listed above or is invalid in any way, the originator MAY 570 reject the message entirely but MUST return an MDN if requested. 572 3. CEM XML Schema Description 574 The CEM schema has two top-level elements, 575 EDIINTCertificateExchangeRequest and 576 EDIINTCertificateExchangeResponse. The 577 EDIINTCertificateExchangeRequest element is present only in the CEM 578 Request message, and the EDIINTCertificateExchangeResponse is present 579 only in the CEM Response message. All other elements nest directly or 580 indirectly from these. CEM XML data must be well�formed and valid 581 relative to the CEM XML Schema. Please refer to the appendix for the 582 actual schema document. 584 3.1 EDIINTCertificateExchangeRequest element 586 EDIINTCertificateExchangeRequest contains two elements, 587 TradingPartnerInfo, which can only appear once and TrustRequest, 588 which may be present multiple times. TrustRequest contains 589 information on a certificate and its intended usage. 590 TradingPartnerInfo exists to provide information on the publication 591 of the CEM Request message since processing of the XML data may occur 592 apart from the handling of the accompanying transport message, for 593 example the AS2 request. 595 596 597 598 599 602 603 604 606 Draft CEM for EDIINT November 2006 608 TradingPartnerInfo identifies the entity that created the CEM message 609 through the nested Name element. Both the optional qualifier 610 attribute and the element value of Name are left open to the 611 implementer, but some suggested choices are to list the EDI 612 identification or the transport trading partner relationship, for 613 example the qualifier of �AS2� and the value of the AS2 system 614 identifier (AS2-From value). MessageOriginated is included in 615 TradingPartnerInfo to identify the time and date the message was 616 created. The MessageOriginated date and time values MUST follow XML 617 standard dateTime type syntax and be listed to at least the nearest 618 second and expressed in local time with UTC offset. For example, a 619 message originating from the US Eastern Standard timezone would use 620 2005-03-01T14:05:00-05:00. 622 623 624 625 626 627 628 629 631 632 633 634 635 636 637 638 640 The TrustRequest element contains the EndEntity, CertUsage, 641 RespondByDate and ResponseURL elements. The required EndEntity 642 element is found only once in a TrustRequest element and contains the 643 content-id reference to the end-entity certificate being exchanged. 645 646 647 648 649 650 651 652 654 EndEntity contains the nested elements of CertificateIdentifier and 655 CertificateContentID. CertificateContentID is a string element which 657 Draft CEM for EDIINT November 2006 659 references the content-id of the multipart/related structure where 660 the certificate is stored. CertificateIdentifier comes from the XML 661 Signature schema namespace [XML-DSIG]. 663 664 665 667 668 669 671 CertificateIdentifier contains the string element X509IssuerName and 672 the integer element X509SerialNumber. X509SerialNumber is the 673 assigned serial number of the end entity certificate as it is listed. 674 X509IssuerName contains the issuer name information of the end-entity 675 certificate, such as common name, organization, etc. This information 676 MUST be describe in a string format per the rules of RFC 2253 677 [RFC2253]. This results in the attributes within the Issuer Name to 678 be listed with their attribute type followed by an "=" and the 679 attribute value. Each attribute type and value are separated by a "," 680 and any escape characters in the value are preceded by a "\". Refer 681 to the appendix and the sample CEM Request message for an example of 682 the X509IssuerName. 684 685 686 687 688 689 691 CertUsage is an unbounded element which contains enumerated values on 692 how the exchanged certificate is to be used. There are enumerated 693 values for SMIME digital signatures (digitalSignature), SMIME data 694 encryption (keyEncipherment), the server certificate used in TLS 695 transport encryption (tlsServer) and the client certificate used in 696 TLS transport encryption (tlsClient). While the element is unbounded, 697 CertUsage only has a potential number of four occurrences due to the 698 limit of the enumerated values. 700 701 702 703 704 705 706 707 709 Draft CEM for EDIINT November 2006 711 713 RespondByDate is a required element of the XML standard dateTime type 714 expressed in local time with UTC offset, which provides information 715 on when the certificate should be trusted, inserted into the trading 716 partner relationship and responded to by a CEM Response message. If 717 the certificate can not be trusted or inserted into the trading 718 partner relationship, the CEM Response message should still be 719 returned by the date indicated. 721 723 ResponseURL is an element which indicates where the CEM Response 724 message should be sent. This value takes precedence over the existing 725 inbound URL of the current trading partner relationship. The Response 726 MUST use the same transport protocol (AS1, AS2, or AS3) as the 727 Request. 728 730 3.2 EDIINTCertificateExchangeResponse element 732 EDIINTCertificateExchangeResponse contains the two elements 733 TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is 734 also found in EDIINTCertificateExchangeRequest, describes the trading 735 partner generating this response message. TrustResponse provides 736 information on the acceptance of a previously sent end entity 737 certificate. There can be multiple TrustResponse elements within an 738 EDIINTCertificateExchangeResponse. 740 741 742 743 744 747 748 749 751 752 753 754 755 757 758 760 Draft CEM for EDIINT November 2006 762 A TrustResponse element identifies a certificate which has been 763 previously exchanged within the trading partner relationship through 764 a CEM Request and now has been either accepted or rejected by the 765 partner. The CertificateReference element is of the same type as the 766 CertificateIdentifier element. A CertificateReference element in a 767 CEM Response MUST be identical to its CertificateIdentifier 768 counterpart in the associated CEM Request since they identify the 769 same certificate in question. 771 The required element CertStatus has the enumerated values of 772 �Accepted� or �Rejected�. �Accepted� indicates the certificate was 773 trusted by the trading partner and is now ready for use within the 774 trading partner relationship, and �Rejected� indicates the 775 certificate is not trusted by the trading partner nor can it be 776 currently used with the trading partner relationship. If the value of 777 �Rejected� is chosen, the optional string element ReasonForRejection 778 may be included. If present, ReasonForRejection should contain a 779 brief description of why the certificate was not accepted. Since the 780 value for this element is not enumerated but open, it MUST be 781 interpreted through human means. 783 784 785 786 787 788 789 790 792 4. Use Case Scenario 794 This scenario illustrates how the CEM Request and CEM Response 795 messages described in Section 2 and 3 can be used to exchange 796 certificates. The scenario is only illustrative and any differences 797 between it and the rules above should defer to the rules in Section 2 798 and 3. 800 Two trading partners, Alpha Arrows and Bravo Bows, have an 801 established trading partner relationship using AS2. Alpha Arrows is 802 using a single certificate, CertA, for both digital signatures and 803 data encryption. Alpha Arrows wants to issue a new certificate, 804 CertB, for digital signatures but keep CertA for data encryption. 806 Bravo Bows is using one certificate, Cert1, for digital signatures 807 and another certificate, Cert2, for data encryption. Bravo Bows wants 808 to introduce a new certificate, Cert3, for digital signature and a 809 new certificate, Cert4, for data encryption. 811 Draft CEM for EDIINT November 2006 813 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only 814 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows 815 immediately returns the MDN but must make an internal security 816 decision before accepting CertB. 818 2. While waiting for a CEM Response, Alpha Arrows continues to send 819 AS2 messages to Bravo Bows which have been signed using CertA. The 820 messages originating from Bravo Bows are encrypted using CertA. 822 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus 823 of "Accepted" for CertB. Upon receipt, an MDN is returned which is 824 signed using CertA. Bravo Bows MUST be able to accept the MDN if it 825 has a digital signature from either CertA or CertB as Alpha Arrows 826 may not be able to switch certificates simply upon receipt of the CEM 827 Response message without parsing the XML payload. Also, Alpha Arrows 828 may need to wait for CEM Responses from other trading partners before 829 switching to the new CertB. However, soon as possible, Alpha Arrows 830 should use CertB exclusively for digital signatures. 832 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both 833 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are 834 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows 835 returns an MDN immediately. Bravo Bows is now prepared to receive any 836 inbound messages encrypted by either Cert2 or Cert4, but all its 837 digital signatures are still done through Cert1. 839 5. Eventually, Alpha Arrows returns a single CEM Response message. It 840 contains two TrustResponse elements: one for Cert3 and another for 841 Cert4. The CertStatus for Cert3 is "Rejected" with the 842 ReasonForRejection field present and populated with the string 843 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted." 844 Bravo Bows returns the MDN signed through Cert1. 846 6. Immediately after this, an AS2 message is received from Alpha 847 Arrows which is encrypted using Cert4, and Bravo Bows is able to 848 decrypt the message successfully. Because Alpha Arrows rejected 849 Cert3, Bravo Bows is only using Cert1 for digital signatures and 850 returns the MDN signed with Cert1. 852 7. After creating a new certificate, Cert5, which corrects the 853 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request. 855 8. Shortly after this, Alpha Arrows sends a CEM Response message for 856 Cert5. It contains a CertStatus of "Accepted". This CEM Response 857 message was encrypted using Cert4, but Bravo Bows was prepared for 858 encryption from either Cert2 or Cert4. The message is processed and a 859 good MDN is returned signed with Cert1. While, Bravo Bows can now 860 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows 861 should use Cert5 exclusively as soon as possible. 863 Draft CEM for EDIINT November 2006 865 5. Profile Exchange Messaging 867 CEM provides the means to exchange certificates among trading 868 partners. However, other profile information, such as URLs and 869 preferred security settings, is needed to create a trading partner 870 relationship. A future standard is needed to describe profile 871 descriptions and how they will be exchanged. The format for this 872 profile attachment is not defined in this specification but is 873 planned for a future document. It will build upon the existing CEM 874 protocol with profile information stored with XML data. Both 875 certificate and profile description information will be placed into a 876 multipart/related [RFC2387] body part entity. A possible format for a 877 profile description message is as follows: 879 Various EDIINT headers 880 EDIINT�Features: profile-exchange 881 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 882 Disposition-Notification-Options: signed-receipt-protocol=optional, 883 pkcs7-signature; signed-receipt-micalg=optional, sha1 884 Content-Type: multipart/signed; micalg=sha1; 885 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 887 ----BOUNDARY1 888 Content-Type: multipart/related; 889 start=�"; 890 type=�application/ediint-cert-exchange+xml�; 891 boundary="--BOUNDARY2" 893 ----BOUNDARY2 894 Content-Type: application/ediint-cert-exchange+xml 895 Content-ID: 897 [CEM XML data] 898 ----BOUNDARY2 899 [Profile information attachment] 900 ----BOUNDARY2-- 901 ----BOUNDARY1 903 Content-Type: application/pkcs7-signature 905 [Digital Signature] 906 ----BOUNDARY1-- 908 6. Security Considerations 910 Draft CEM for EDIINT November 2006 912 Certificate exchange is safe for transmitting. However, implementers 913 SHOULD verify the received certificate to determine if it is truly 914 from the stated originator through out-of-band means or whenever the 915 request is not signed. 917 7. IANA Considerations 919 MIME Media type name: Application 921 MIME subtype name: EDIINT-cert-exchange+xml 923 Required parameters: None 925 Optional parameters: This parameter has identical semantics to the 926 charset parameter of the �application/xml� media type as specified 927 in [RFC3023]. 929 Encoding considerations: Identical to those of "application/xml" as 930 described in [RFC3023], section 3.2. 932 Security considerations: See section 6. 934 Interoperability Considerations: See section 2.2 936 Published specification: This document. 938 Applications which use this media type: EDIINT applications, such as 939 AS1, AS2 and AS3 implementations. 941 Additional Information: None 943 Intended Usage: Common 945 Author/Change controller: See Author�s section of this document. 947 8. References 948 8.1 Normative References 950 [AS1] RFC3335 �MIME-based Secure Peer-to-Peer Business Data 951 Interchange over the Internet using SMTP�, T. Harding, R. 952 Drummond, C. Shih, 2002. 954 [AS2] RFC4130 �MIME-based Secure Peer-to-Peer Business Data 955 Interchange over the Internet using HTTP�, D. Moberg, R. 956 Drummond, 2005. 958 Draft CEM for EDIINT November 2006 960 [AS3] draft-ietf-ediint-as3-02.txt �MIME-based Secure Peer-to-Peer 961 Business Data Interchange over the Internet using FTP�, T. 962 Harding, R. Scott, 2003. 964 [EDIINT FEATURE] draft-meadors-ediint-feature-header-00.txt �Feature 965 Header for EDI-INT�, K. Meadors, 2005. 967 [RFC2119] RFC2119 �Key Words for Use in RFC's to Indicate Requirement 968 Levels�, S.Bradner, March 1997. 970 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen, 971 January 1999. 973 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8 974 String Representation of Distinguished Names", M. Wahl, S. Kille 975 and T. Howes, Decemeber 1997. 977 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 978 Levinson, August 1998. 980 [RFC2828] RFC2828 �Internet Security Glossary�, R. Shirley, May 2000. 982 [RFC3023] RFC3023 �XML Media Types�, M. Murata, January 2001. 984 [3821] RFC3821 �S/MIME Version 3.1 Message Specification�, B. 985 Ramsdell, July 2004. 987 [XML-DSIG] RFC3275 �XML-Signature Syntax and Processing�, D. 988 Eastlake, March 2002. 990 [X.520] ITU-T Recommendation X.520: Information Technology - Open 991 Systems Interconnection - The Directory: Selected Attribute 992 Types, 1993. 994 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 995 X.509 Public Key Infrastructure: Certificate and CRL Profile", 996 RFC 3280, April 2002. 998 8.2 Informative References 1000 9. Acknowledgments 1002 The authors wish to extend gratitude to the ecGIF sub-committee 1003 within the GS1 organization from which this effort began. Of special 1004 note is John Duker who chaired the sub-committee and provided 1005 valuable editing, Richard Bigelow who greatly assisted development of 1006 the ideas presented and John Koehring with his insights on 1007 implementation and Debra Petta for her review and comments. 1009 Draft CEM for EDIINT November 2006 1011 Author's Addresses 1013 Kyle Meadors 1014 Drummond Group Inc. 1015 4700 Bryant Irvin Court, Suite 303 1016 Fort Worth, TX 76107 USA 1017 Email: kyle@drummondgroup.com 1019 Dale Moberg 1020 Cyclone Commerce 1021 8388 E. Hartford Drive, Suite 100 1022 Scottsdale, AZ 85255 USA 1023 Email: dmoberg@cyclonecommerce.com 1025 Copyright Notice 1026 Copyright (C) The Internet Society 2006. This document is subject 1027 to the rights, licenses and restrictions contained in BCP 78, and 1028 except as set forth therein, the authors retain all their rights. 1030 This document and the information contained herein are provided on an 1031 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1032 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1033 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1034 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1035 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1036 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1038 Appendix 1040 A.1 EDIINT Certificate Exchange XML Schema 1042 1043 1049 1050 1051 1052 1053 1054 1056 1057 1058 1060 Draft CEM for EDIINT November 2006 1062 1063 1064 1065 1066 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1112 Draft CEM for EDIINT November 2006 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1131 1132 1133 1135 A.2 Example of EDIINT Certificate Exchange Request XML 1137 1138 1142 1143 DGI_Test_CEM 1144 1145 2005-08-30T00:30:00-05:00 1146 1147 1148 keyEncipherment 1149 digitalSignature 1150 2005-09-30T12:00:00-05:00 1151 http://10.1.1.1/as2 1152 1153 1154 CN=Cleo- 1155 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1156 Worth,S=Texas,C=US 1157 9659684611094873474886 1158 1159 1160 SignEncCert-Example_vs02@example.org 1161 1162 1164 Draft CEM for EDIINT November 2006 1166 1167 tlsServer 1168 2005-09-30T12:00:00-05:00 1169 http://10.1.1.1/as2 1170 1171 1172 CN=VeriSign Class 1 CA Individual 1173 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1174 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1175 Inc. 1176 2673611014597817669550861744279966682 1178 1179 1180 SSLCert-Example_vs02@example.org 1181 1182 1183 1185 A.3 Example of EDIINT Certificate Exchange Response XML 1187 1188 1192 1193 DGI_Test_CEM_Trading_Partner 1194 1195 2005-08-31T00:21:00-05:00 1196 1197 1198 Accepted 1199 1200 CN=Cleo- 1201 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1202 Worth,S=Texas,C=US 1203 9659684611094873474886 1204 1205 1206 1207 Accepted 1208 1209 CN=VeriSign Class 1 CA Individual 1210 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1211 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1212 Inc. 1213 2673611014597817669550861744279966682 1216 Draft CEM for EDIINT November 2006 1218 1219 1220 1222 Changes from Previous Versions 1224 B.1 Updates from Version 00 1226 . Updated security requirements in section 2.1, specifically in 1227 regards to digital signatures. 1228 . The XML element responseURL is now required. Modified section 1229 3.1 and example messages in appendix accordingly. 1230 . Certificates are exchanged within a full P7C cert chain. Section 1231 2.3 reflects this. 1232 . The XML element TrustChain is not longer necessary since the 1233 entire cert chain is stored. Removed references in schema and 1234 document. 1235 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be 1236 sent and that if this occurs, the action of the CEM Request 1237 initiator is not defined. 1238 . Updated the examples in Appendix B to reflect the current usage. 1240 B.2 Updates from Version 01 1242 . Added information for handling different scenarios with CEM 1243 Response message. 1244 . Rewrote use case scenarios. 1245 . Added the EDIINT Features header information. 1247 B.3 Updates from Version 02 1249 . Modified use of SSL certificates to match real�world needs. 1250 . Modified schema in changing namespace value and removed schema 1251 location. 1252 . Added statement that CEM XML must be well�formed and valid to 1253 schema. 1254 . Modified Use Case to correct an error and improve clarity. 1255 . Added section 1.4 to describe CEM process.