idnits 2.17.1 draft-meadors-certificate-exchange-03.txt: -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(731): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(736): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(878): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(914): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(917): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(930): 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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 984. ** 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 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-03' == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 549 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 (April 2006) is 6587 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 330, but not defined == Missing Reference: 'EDIINT-FEATURE' is mentioned on line 384, but not defined == Unused Reference: 'EDIINT FEATURE' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '3821' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'PROFILE' is defined on line 944, 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: 13 errors (**), 1 flaw (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Private K. Meadors 2 Internet-Draft Drummond Group Inc. 3 Document: draft-meadors-certificate-exchange- D. Moberg 4 03.txt Cyclone Commerce 5 Expires: October 2006 April 2006 7 Certificate Exchange Messaging for EDIINT 8 draft-meadors-certificate-exchange-03.doc 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Status of this Memo 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Any questions, comments, and reports of defects or ambiguities in 33 this specification may be sent to the mailing list for the EDIINT 34 working group of the IETF, using the address . 35 Requests to subscribe to the mailing list should be addressed to 36 . 38 Abstract 40 The EDIINT AS1, AS2 and AS3 message formats do not currently contain 41 any neutral provisions for transporting and exchanging trading 42 partner profiles or digital certificates. EDIINT Certificate Exchange 43 Messaging provides the format and means to effectively exchange 44 certificates for use within trading partner relationships. The 45 messaging consists of two types of messages, Request and Response, 46 which allow trading partners to communicate certificates, their 47 intended usage and their acceptance through XML. Certificates can be 48 specified for use in digital signatures, data encryption or SSL/TLS 49 over HTTP (HTTPS). 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119. 57 Feedback Instructions 59 NOTE TO RFC EDITOR: This section should be removed by the RFC editor 60 prior to publication. 62 If you want to provide feedback on this draft, follow these 63 guidelines: 65 -Send feedback via e-mail to kyle@drummondgroup.com, with 66 "Certificate Exchange" in the Subject field. 68 -Be specific as to what section you are referring to, preferably 69 quoting the portion that needs modification, after which you state 70 your comments. 72 -If you are recommending some text to be replaced with your suggested 73 text, again, quote the section to be replaced, and be clear on the 74 section in question. 76 Table of Contents 78 1. Introduction...................................................3 79 1.1 Overview...................................................3 80 1.2 Terminology and Key Word Convention........................4 81 1.3 Certificate Lifecycle......................................5 82 1.4 Certificate Exchange Process...............................6 83 2. Message Processing.............................................7 84 2.1 Message Structure..........................................7 85 2.2 EDIINT Features Header.....................................9 86 2.3 Certificate Exchanging.....................................9 87 2.4 Certificate Implementation................................10 88 2.5 CEM Response..............................................11 89 3. CEM XML Schema Description....................................12 90 3.1 EDIINTCertificateExchangeRequest element..................12 91 3.2 EDIINTCertificateExchangeResponse element.................15 92 4. Use Case Scenario.............................................16 93 5. Profile Exchange Messaging....................................18 94 6. Security Considerations.......................................18 95 7. IANA Considerations...........................................19 96 8. References....................................................19 97 8.1 Normative References......................................19 98 8.2 Informative References....................................20 99 9. Acknowledgments...............................................20 100 Author's Addresses...............................................21 101 Appendix.........................................................21 102 A.1 EDIINT Certificate Exchange XML Schema....................21 103 A.2 Example of EDIINT Certificate Exchange Request XML........23 104 A.3 Example of EDIINT Certificate Exchange Response XML.......24 105 Changes from Previous Versions...................................25 106 B.1 Updates from Version 00...................................25 107 B.2 Updates from Version 01...................................25 108 B.3 Updates from Version 02...................................25 110 1. Introduction 112 1.1 Overview 114 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 115 numerous supply-chains was due in part to the security feature which 116 was provided. The security is not possible without the digital 117 certificates which enable it. To maintain the level of security 118 necessary to transmit business documentation, existing certificates 119 must occasionally be replaced and exchanged with newer ones. The 120 exchanging of digital certificates is unavoidable given how 121 certificates can expire or become compromised. Complicating this is 122 supply-chains which cannot afford to shutdown their business 123 transactions while trading partners laboriously upload new 124 certificates. Certificate exchange must be accomplished in a reliable 125 and seamless format so as not to affect ongoing business 126 transactions. 128 This document describes how EDIINT products may exchange public-key 129 certificates. Since EDIINT is built upon the security provided by 130 public-private key pairs, it is vital that implementers are able to 131 update their trading partners with new certificates as their old 132 certificates expire, become outdated or insecure. Certificate 133 Exchange Messaging (CEM) described here utilizes XML data to exchange 134 the certificate and provide information on its intended usage and 135 acceptance within the trading partner relationship. There are two 136 types of CEM messages, the CEM Request which presents the new 137 certificate to be introduced into the trading partner relationship 138 and the CEM Response which is the recipient�s response to the CEM 139 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 140 AS3 [AS3] message transports. However, it is possible to leverage CE 141 messaging through other transport standards besides EDIINT. 143 1.2 Terminology and Key Word Convention 145 [RFC2828] provides a glossary of Internet security terms, and several 146 of their definitions are listed here verbatim. However, some 147 definitions required for this document were undefined by [RFC2828] or 148 rewritten to better explain their specific use within CEM. 150 Certificate - A digital certificate contains the owner�s (End 151 Entity�s) name, the issuer�s name, a serial number, expiration date, 152 and a copy of the owner�s Public Key. The Public Key is used for 153 Encrypting messages and Verifying Signatures (verifying a signature 154 is also called Authentication). 156 Certificate Revocation List (CRL) - A data structure that enumerates 157 digital certificates that have been invalidated by their issuer prior 158 to when they were scheduled to expire. [RFC2828] 160 Certification Authority (CA) - An entity that issues digital 161 certificates (especially X.509 certificates) and vouches for the 162 binding between the data items in a certificate. [RFC2828] 164 CA Certificate - A certificate issued by a trusted certification 165 authority. CA certificates are not used to encrypt data but to sign 166 other certificates. CA certificates are signed by themselves, but are 167 not considered self-signed certificates for the purpose of this 168 document. 170 Certification Hierarchy - In this structure, one CA is the top CA, 171 the highest level of the hierarchy. The top CA may issue public-key 172 certificates to one or more additional CAs that form the second 173 highest level. Each of these CAs may issue certificates to more CAs 174 at the third highest level, and so on. The CAs at the second-lowest 175 of the hierarchy issue certificates only to non-CA entities, called 176 "end entities" that form the lowest level. Thus, all certification 177 paths begin at the top CA and descend through zero or more levels of 178 other CAs. All certificate users base path validations on the top 179 CA's public key. [RFC2828] 181 CEM Request -The EDIINT Certificate Exchange Messaging (CEM) Request 182 is one of two possible CEM messages. It presents a certificate to be 183 introduced into the trading partner relationship along with relevant 184 information on how it is to be implemented. 186 CEM Response -The EDIINT Certificate Exchange Messaging (CEM) 187 Response is one of two possible CEM messages. It is the response to 188 the CEM Request indicating whether or not the end entity certificate 189 present in the CEM Request was accepted. 191 End Entity - A system entity that is the subject of a public-key 192 certificate and that is using, or is permitted and able to use, the 193 matching private key only for a purpose or purposes other than 194 signing a digital certificate; i.e., an entity that is not a CA. 195 [RFC2828] 197 End Entity Certificate - A certificate which is used to encrypt data 198 or authenticate a signature. (The private key associated with the 199 certificate is used to decrypt data or sign data). The certificate 200 may be self-signed or issued by a trusted certificate. 202 Intermediary Certificate - A certificate issued by a CA certificate 203 which itself issues another certificate (either intermediary or end 204 entity). Intermediary certificates are not used to encrypt data but 205 to sign other certificates. 207 Public Key - The publicly-disclosable component of a pair of 208 cryptographic keys used for asymmetric cryptography. [RFC2828] 210 Public Key Certificate - A digital certificate that binds a system 211 entity's identity to a public key value, and possibly to additional 212 data items. [RFC2828] 214 Self-signed Certificate - A certificate which is issued by itself 215 (both issuer and subject are the same) and is an End Entity 216 certificate. 218 1.3 Certificate Lifecycle 220 A certificate has five states. 222 1. Pending - Upon receiving a certificate from a trading partner, the 223 certificate is marked as Pending until a decision can be made to 224 trust it or if its validity period has not yet begun. 225 2. Rejected - If a Pending certificate is not trusted, it is 226 considered Rejected. 227 3. Accepted - Once a Pending certificate has been trusted, it is 228 considered Accepted. An Accepted certificate may be used in 229 secure transactions. 230 4. Expired - A certificate which is no longer valid because its 231 expiration date has passed. Expired certificates SHOULD be kept 232 in a certificate storehouse for decrypting and validating past 233 transactions. 234 5. Revoked - A certificate which has been explicitly revoked by its 235 owner or the certificate authority. 237 1.4 Certificate Exchange Process 239 This section describes a process whereby a company can distribute 240 certificates to its partners, and the company and its partners can 241 put the certificates into use. Later sections describe the specific 242 CEM protocol, which is an implementation of this process. 244 The exchange process can be used even when CEM is not useable, for 245 example, when the transport protocols or installed software systems 246 do not support CEM. It is RECOMMENDED that this process be followed 247 in distributing certificates. 249 The exchange process covers the update of certificates. It is 250 assumed that certificates have already been distributed and are in 251 use for signing or encrypting messages. The process describes how to 252 replace those certificates with new ones. 254 The company that owns the certificates initiates the process. For a 255 certificate that is to be used (by the partners) to encrypt messages, 256 the initiator first prepares his system to decrypt messages that are 257 encrypted with this certificate. The initiator must also be able to 258 decrypt messages using the old certificate. The initiator company 259 distributes the new certificates by some means. The distribution 260 MUST describe the purposes of the certificates and MAY contain an in- 261 use date, the date when the distributor expects to put the 262 certificates in use. The in-use date SHOULD be present for 263 certificates that are used to sign messages or to authenticate 264 TLS/SSL connections. 266 When a partner receives a certificate, the partner should 267 authenticate the distribution message by some means. (CEM provides 268 for automatic authentication. Partners can use manual methods, 269 either with or without CEM.) 271 When a partner receives a certificate for use in encrypting messages 272 and has authenticated the certificate, the partner should begin using 273 that certificate to encrypt messages. The initiator MUST be prepared 274 to receive messages encrypted with either the old or new certificate. 276 When a partner receives a certificate for use in digitally signing 277 messages or for TLS/SSL authentication and has authenticated the 278 certificate, the partner MUST prepare his system to accept messages 279 that are signed or authenticated with the new certificate. The 280 partner MUST also accept messages signed or authenticated with the 281 old certificate. 283 The partner MAY return a response to the initiator, indicating that 284 the partner has accepted the new certificate and put it in use. The 285 initiator can use these responses to track which partners are ready 286 to use the new certificate. 288 When the partner has sent a response indicating acceptance of the new 289 certificate, or when the in-use date has passed, the initiator can 290 begin using the new certificate to digitally sign messages or 291 authenticate TLS/SSL messages. The initiator MUST NOT sign or 292 authenticate messages with the new certificate until the partner has 293 accepted it or until the in-use date has passed. The initiator may 294 wait until the in-use date or until all partners have accepted. The 295 partners MUST accept messages signed or authenticated with either the 296 old or new certificate. 298 When the process is fully automated, it is not necessary to have a 299 specific time when both the initiator and partners switch to the new 300 certificate. 302 The initiator MUST be able to decrypt messages with both the old and 303 new certificates as soon as the new certificates are distributed. 304 The partners MUST be able to accept messages signed or TLS/SSL 305 authenticated with either the old or new certificates after they have 306 accepted the new certificate. The initiator SHOULD allow a 307 reasonable time after distributing a new signing or authenticating 308 certificate before putting it in use, so that partners have time to 309 authenticate the new certificate and prepare their systems for it. 311 For a certificate used to digitally sign messages or authenticate 312 TLS/SSL messages, there must be some way for the initiator to know 313 when partners are ready to receive the certificate. For example, 314 this may be a response from the partners, an explicit in-use date in 315 the initial distribution, an implied in-use date based on partner 316 agreements, or the expiration date of the old certificate. For a 317 certificate used to encrypt messages, the in-use date and responses 318 are less important, but responses may be useful to track partners� 319 acceptances. 321 2. Message Processing 323 2.1 Message Structure 325 CEM messages use the underlying EDIINT transport, such as AS2, to 326 communicate information on the certificate, its intended use and its 327 acceptance. Both digital certifications and the XML data describing 328 their intended use are stored within a multipart-related MIME 329 envelope [RFC2387]. The certificates are stored in certificate chains 330 through SMIME, certs-only MIME envelope [3851], and processing 331 information is XML data which is identified through the MIME content- 332 type of application/ediint-cert-exchange+xml. The format for CEM 333 messages is as follows: 335 Various EDIINT headers 336 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 337 Content-Type: multipart/signed; micalg=sha1; 338 protocol="application/pkcs7-signature"; 339 boundary="--OUTER-BOUNDARY" 341 ----OUTER-BOUNDARY 342 Content-Type: multipart/related; type=" application/ediint-cert- 343 exchange+xml"; boundary="--INNER-BOUNDARY" 345 ----INNER-BOUNDARY 346 Content-Type: application/ediint-cert-exchange+xml 347 Content-ID: <20040101-1.alpha@example.org> 349 [CEM XML data] 350 ----INNER-BOUNDARY 351 Content-Type: application/pkcs7-mime; smime-type=certs-only 352 Content-ID: <20040101-2.alpha@example.org> 354 [digital certificate] 355 ----INNER-BOUNDARY-- 357 ----OUTER-BOUNDARY 358 Content-Type: application/pkcs7-signature 360 [Digital Signature] 361 ----OUTER-BOUNDARY-- 363 One and only one MIME type of application/ediint-cert-exchange+xml 364 MUST be present in the multipart/related structure, and it MUST be 365 the root element. Multiple certs-only media types may be included, 366 but at least one MUST be present. A unique content-id header MUST be 367 present within each of the multipart structures. 369 If possible, both the CEM Request and CEM Response message SHOULD be 370 signed. Applying digital signatures will allow for automatic exchange 371 based on a previous trust relationship. However, it may not be 372 possible in the initial exchange of a new trading partner. If a CEM 373 message is signed, the signing certificate MUST be included in the 374 digital signature. Extra security such as applying data encryption or 375 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and 376 SHOULD request a signed MDN. The MDN can be either synchronous or 377 asynchronous. The MDN response verifies the transport delivery but is 378 not equivalent to the CEM Response message. All necessary headers 379 MUST be applied to the message per the underlying transport standard. 381 2.2 EDIINT Features Header 383 To indicate support for CEM, an EDIINT application MUST use the 384 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates 385 the instance application can support various features, such as 386 certification exchange. The header is present in all messages from 387 the instance application, not just those which feature certification 388 exchange. 390 For applications implementing certification exchange, the CEM- 391 Feature-Name MUST be used within the EDIINT Features header: 393 CEM-Feature-Name = "CEM" 395 2.3 Certificate Exchanging 397 After obtaining the desired certificate, the initiator of the 398 certificate exchange transmits the end-entity certificate in the CEM 399 Request message. If the end-entity certificate is not self-signed, 400 then the CA certificate and any other certificates needed to create 401 the chain of trust for the end-entity certificate MUST be included in 402 the CEM Request message. Multiple end-entity certificates MAY also be 403 present. 405 The entire certificate trust chain is stored in a BER encoded P7C 406 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- 407 only MIME envelope which is then stored in a single part of the 408 multipart/related structure. Each P7C trust chain MUST include a 409 single end-entity certificate and its trust authorities. No other 410 certificates are to be part of this chain. The number of P7C trust 411 chains in a CEM Request message MUST be equal to the number of end- 412 entity certificates being communicated in the CEM XML document. 413 If different end-entity certificates have common trust authorities 414 certificates, each P7C cert chain still MUST included each 415 certificate necessary to create a trust anchor. Thus, if a recipient 416 can not create a trust relationship from the P7C cert chain, it MAY 417 reject the end-entity certificate in the CEM Request. 419 End-entity certificates are referenced and identified in the XML data 420 by their content-id used in the multipart-related structure. 421 Information on how the certificate is to be used, or certificate 422 usage, by the receiving user agent and other related information is 423 found in the XML data. A certificate can be used for a single 424 function, like digital signatures, or used for multiple functions, 425 such as both digital signatures and data encryption. If a certificate 426 is intended for multiple usages, such as for both digital signatures 427 and data encryption, the certificate MUST be listed only once in the 428 CEM Request message and its multiple usage listed through the 429 CertUsage XML element. 431 Upon receipt of the CEM Request, the recipient trading partner 432 processes the transport message as normal and returns the MDN. The 433 recipient MUST return the MDN before parsing and interpreting the CEM 434 XML data or certificate chains. The returned MDN only provides 435 information on the veracity of the transport message and not the 436 acceptance of the certificate(s) being exchanged. 438 2.4 Certificate Implementation 440 The new certificate is considered to be in the Pending state for the 441 recipient who MUST decide whether to accept the certificate as 442 trustworthy. This decision is arbitrary and left to each individual 443 trading partner. Upon accepting the certificate, it is to be 444 considered an Accepted certificate within the trading partner 445 relationship. If the certificate is not accepted, it is considered 446 Rejected. 448 When a certificate is intended for use in data encryption, the 449 initiator MUST consider the certificate to be Accepted and be 450 prepared for its trading partner to begin using the certificate upon 451 generating the CEM Request message. After a recipient generates a 452 positive CEM Response message for a certificate, the recipient MUST 453 immediately begin using the certificate in trading with the initiator 454 of the request. The recipient MAY apply encryption to the CEM 455 Response message using the new Accepted certificate or MAY apply 456 encryption to the CEM Response message using the previously Accepted 457 encryption certificate. 459 When a certificate is intended for use in digital signatures or 460 TLS/SSL authentication, the initiator MUST NOT use the certificate 461 until the recipient trading partner generates a CEM Response 462 accepting the certificate or the respond by date, which is listed in 463 the RespondByDate XML element. The initiator MAY use the certificate 464 after the respond by date, regardless of whether the partner has 465 accepted it or not. The certificate used for the digital signature of 466 the CEM Request message MUST be the one which is currently Accepted 467 within the trading partner relationship. 469 Since implementers of EDIINT often use the same certificate with 470 multiple trading partners, implementers of CEM MUST be able to keep 471 both the old and new certificates as Accepted. If the initiator has 472 generated a CEM Request and exchanged a new encryption certificate to 473 multiple trading partners, it MUST be able to accept encrypted data 474 which uses either the older, existing encryption certificate or the 475 newly exchanged encryption certificate. Likewise, a recipient of a 476 CEM Request MUST be able to authenticate digital signatures using 477 either the new or old certificates, since the initiator may not be 478 able to switch certificates until all trading partners accept the new 479 certificate. Similar provisions MUST be made for certificates 480 intended for TLS/SSL server and client authentication. Revoking a 481 certificate MUST be done outside of CEM. 483 If a CEM Request message contains a certificate which is currently 484 Accepted and has the identical usage for the certificate that has 485 been Accepted, the recipient MUST NOT reject the duplicate 486 certificate but MUST respond with a CEM Response message indicating 487 the certificate has been accepted. For example, if Certificate A is 488 currently Accepted as the encryption certificate for a user agent, 489 any CEM Request message containing Certificate A with the usage as 490 encryption only MUST be accepted by an existing trading partner. This 491 situation may be necessary for an implementation intending to verify 492 its current trading partner certificate. 494 If two trading partners utilize multiple EDIINT protocols for 495 trading, such as AS2 for a primary transport and AS1 as the backup 496 transport, it is dependent upon implementation and trading partner 497 agreement how CEM messages are sent and which transports the 498 exchanged certificates affect. 500 2.5 CEM Response 502 The CEM Response message contains a TrustResponse XML element. 503 TrustResponse provides information needed to match the end-entity 504 certificate sent in an earlier CEM Request and indicate if the 505 certificate was accepted or rejected by the recipient. The 506 CertificateReference in a TrustResponse matches the 507 CertificateIdentifier value for the end-entity certificate in the CEM 508 Request. CertStatus indicates if the certificate was accepted or 509 rejected. If a CEM Request is received, the recipient MUST respond 510 with a CEM Response message indicating if the certificate is Accepted 511 or Rejected. More information about the XML attributes and value for 512 CEM Response can be found in 3.2. 514 If the certificate in the CEM Request message contains multiple 515 usages, such as for both digital signature and data encryption, only 516 a single TrustResponse is needed for that certificate. The CertStatus 517 value in the TrustResponse is the response for both usages of the 518 certificate. A recipient can NOT choose to accept the certificate for 519 one specified use and not the other. 521 If multiple end-entity certificates were included within the CEM 522 Request, the recipient MAY generate individual CEM Response messages 523 for each certificate or the recipient MAY consolidate the 524 TrustResponse for multiple certificates into one CEM Response 525 message. A CEM Response may contain multiple TrustResponse elements 526 for different certificates but MUST NOT contain two or more 527 TrustResponses for the same certificate. 529 If a second TrustResponses is received in different message matching 530 the same certificate as that of an earlier TrustRespnse but the 531 CertStatus have a different value than the other, the originator MAY 532 accept the CertStatus value in the most recent TrustResponse but MAY 533 choose to ignore it. If the CertStatus in both TrustResponses are the 534 same, the originator should disregard the second TrustResponse. 536 If the originator receives a CEM Response message which violates the 537 rules listed above or is invalid in any way, the originator MAY 538 reject the message entirely but MUST return an MDN if requested. 540 3. CEM XML Schema Description 542 The CEM schema has two top-level elements, 543 EDIINTCertificateExchangeRequest and 544 EDIINTCertificateExchangeResponse. The 545 EDIINTCertificateExchangeRequest element is present only in the CEM 546 Request message, and the EDIINTCertificateExchangeResponse is present 547 only in the CEM Response message. All other elements nest directly or 548 indirectly from these. CEM XML data must be well�formed and valid 549 relative to the CEM XML Schema. Please refer to the appendix for the 550 actual schema document. 552 3.1 EDIINTCertificateExchangeRequest element 554 EDIINTCertificateExchangeRequest contains two elements, 555 TradingPartnerInfo, which can only appear once and TrustRequest, 556 which may be present multiple times. TrustRequest contains 557 information on a certificate and its intended usage. 558 TradingPartnerInfo exists to provide information on the publication 559 of the CEM Request message since processing of the XML data may occur 560 apart from the handling of the accompanying transport message, for 561 example the AS2 request. 563 564 565 566 567 570 571 572 574 TradingPartnerInfo identifies the entity that created the CEM message 575 through the nested Name element. Both the optional qualifier 576 attribute and the element value of Name are left open to the 577 implementer, but some suggested choices are to list the EDI 578 identification or the transport trading partner relationship, for 579 example the qualifier of �AS2� and the value of the AS2 system 580 identifier (AS2-From value). MessageOriginated is included in 581 TradingPartnerInfo to identify the time and date the message was 582 created. The MessageOriginated date and time values MUST follow XML 583 standard dateTime type syntax and be listed to at least the nearest 584 second and expressed in local time with UTC offset. For example, a 585 message originating from the US Eastern Standard timezone would use 586 2005-03-01T14:05:00-05:00. 588 589 590 591 592 593 594 595 597 598 599 600 601 602 603 604 606 The TrustRequest element contains the EndEntity, CertUsage, 607 RespondByDate and ResponseURL elements. The required EndEntity 608 element is found only once in a TrustRequest element and contains the 609 content-id reference to the end-entity certificate being exchanged. 611 612 613 614 615 616 617 618 620 EndEntity contains the nested elements of CertificateIdentifier and 621 CertificateContentID. CertificateContentID is a string element which 622 references the content-id of the multipart/related structure where 623 the certificate is stored. CertificateIdentifier comes from the XML 624 Signature schema namespace [XML-DSIG]. 626 627 628 630 631 632 634 CertificateIdentifier contains the string element X509IssuerName and 635 the integer element X509SerialNumber. X509SerialNumber is the 636 assigned serial number of the end entity certificate as it is listed. 637 X509IssuerName contains the issuer name information of the end-entity 638 certificate, such as common name, organization, etc. This information 639 MUST be describe in a string format per the rules of RFC 2253 640 [RFC2253]. This results in the attributes within the Issuer Name to 641 be listed with their attribute type followed by an "=" and the 642 attribute value. Each attribute type and value are separated by a "," 643 and any escape characters in the value are preceded by a "\". Refer 644 to the appendix and the sample CEM Request message for an example of 645 the X509IssuerName. 647 648 649 650 651 652 654 CertUsage is an unbounded element which contains enumerated values on 655 how the exchanged certificate is to be used. There are enumerated 656 values for SMIME digital signatures (digitalSignature), SMIME data 657 encryption (keyEncipherment), the server certificate used in TLS 658 transport encryption (tlsServer) and the client certificate used in 659 TLS transport encryption (tlsClient). While the element is unbounded, 660 CertUsage only has a potential number of four occurrences due to the 661 limit of the enumerated values. 663 664 665 666 667 668 669 670 672 674 RespondByDate is a required element of the XML standard dateTime type 675 expressed in local time with UTC offset, which provides information 676 on when the certificate should be trusted, inserted into the trading 677 partner relationship and responded to by a CEM Response message. If 678 the certificate can not be trusted or inserted into the trading 679 partner relationship, the CEM Response message should still be 680 returned by the date indicated. 682 684 ResponseURL is an element which indicates where the CEM Response 685 message should be sent. This value takes precedence over the existing 686 inbound URL of the current trading partner relationship. The Response 687 MUST use the same transport protocol (AS1, AS2, or AS3) as the 688 Request. 689 691 3.2 EDIINTCertificateExchangeResponse element 693 EDIINTCertificateExchangeResponse contains the two elements 694 TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is 695 also found in EDIINTCertificateExchangeRequest, describes the trading 696 partner generating this response message. TrustResponse provides 697 information on the acceptance of a previously sent end entity 698 certificate. There can be multiple TrustResponse elements within an 699 EDIINTCertificateExchangeResponse. 701 702 703 704 705 708 709 710 712 713 714 715 716 718 719 721 A TrustResponse element identifies a certificate which has been 722 previously exchanged within the trading partner relationship through 723 a CEM Request and now has been either accepted or rejected by the 724 partner. The CertificateReference element is of the same type as the 725 CertificateIdentifier element. A CertificateReference element in a 726 CEM Response MUST be identical to its CertificateIdentifier 727 counterpart in the associated CEM Request since they identify the 728 same certificate in question. 730 The required element CertStatus has the enumerated values of 731 �Accepted� or �Rejected�. �Accepted� indicates the certificate was 732 trusted by the trading partner and is now ready for use within the 733 trading partner relationship, and �Rejected� indicates the 734 certificate is not trusted by the trading partner nor can it be 735 currently used with the trading partner relationship. If the value of 736 �Rejected� is chosen, the optional string element ReasonForRejection 737 may be included. If present, ReasonForRejection should contain a 738 brief description of why the certificate was not accepted. Since the 739 value for this element is not enumerated but open, it MUST be 740 interpreted through human means. 742 743 744 745 746 747 748 749 751 4. Use Case Scenario 753 This scenario illustrates how the CEM Request and CEM Response 754 messages described in Section 2 and 3 can be used to exchange 755 certificates. The scenario is only illustrative and any differences 756 between it and the rules above should defer to the rules in Section 2 757 and 3. 759 Two trading partners, Alpha Arrows and Bravo Bows, have an 760 established trading partner relationship using AS2. Alpha Arrows is 761 using a single certificate, CertA, for both digital signatures and 762 data encryption. Alpha Arrows wants to issue a new certificate, 763 CertB, for digital signatures but keep CertA for data encryption. 765 Bravo Bows is using one certificate, Cert1, for digital signatures 766 and another certificate, Cert2, for data encryption. Bravo Bows wants 767 to introduce a new certificate, Cert3, for digital signature and a 768 new certificate, Cert4, for data encryption. 770 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only 771 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows 772 immediately returns the MDN but must make an internal security 773 decision before accepting CertB. 775 2. While waiting for a CEM Response, Alpha Arrows continues to send 776 AS2 messages to Bravo Bows which have been signed using CertA. The 777 messages originating from Bravo Bows are encrypted using CertA. 779 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus 780 of "Accepted" for CertB. Upon receipt, an MDN is returned which is 781 signed using CertA. Bravo Bows MUST be able to accept the MDN if it 782 has a digital signature from either CertA or CertB as Alpha Arrows 783 may not be able to switch certificates simply upon receipt of the CEM 784 Response message without parsing the XML payload. Also, Alpha Arrows 785 may need to wait for CEM Responses from other trading partners before 786 switching to the new CertB. However, soon as possible, Alpha Arrows 787 should use CertB exclusively for digital signatures. 789 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both 790 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are 791 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows 792 returns an MDN immediately. Bravo Bows is now prepared to receive any 793 inbound messages encrypted by either Cert2 or Cert4, but all its 794 digital signatures are still done through Cert1. 796 5. Eventually, Alpha Arrows returns a single CEM Response message. It 797 contains two TrustResponse elements: one for Cert3 and another for 798 Cert4. The CertStatus for Cert3 is "Rejected" with the 799 ReasonForRejection field present and populated with the string 800 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted." 801 Bravo Bows returns the MDN signed through Cert1. 803 6. Immediately after this, an AS2 message is received from Alpha 804 Arrows which is encrypted using Cert4, and Bravo Bows is able to 805 decrypt the message successfully. Because Alpha Arrows rejected 806 Cert3, Bravo Bows is only using Cert1 for digital signatures and 807 returns the MDN signed with Cert1. 809 7. After creating a new certificate, Cert5, which corrects the 810 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request. 812 8. Shortly after this, Alpha Arrows sends a CEM Response message for 813 Cert5. It contains a CertStatus of "Accepted". This CEM Response 814 message was encrypted using Cert4, but Bravo Bows was prepared for 815 encryption from either Cert2 or Cert4. The message is processed and a 816 good MDN is returned signed with Cert1. While, Bravo Bows can now 817 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows 818 should use Cert5 exclusively as soon as possible. 820 5. Profile Exchange Messaging 822 CEM provides the means to exchange certificates among trading 823 partners. However, other profile information, such as URLs and 824 preferred security settings, is needed to create a trading partner 825 relationship. A future standard is needed to describe profile 826 descriptions and how they will be exchanged. The format for this 827 profile attachment is not defined in this specification but is 828 planned for a future document. It will build upon the existing CEM 829 protocol with profile information stored with XML data. Both 830 certificate and profile description information will be placed into a 831 multipart/related [RFC2387] body part entity. A possible format for a 832 profile description message is as follows: 834 Various EDIINT headers 835 EDIINT�Features: profile-exchange 836 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 837 Disposition-Notification-Options: signed-receipt-protocol=optional, 838 pkcs7-signature; signed-receipt-micalg=optional, sha1 839 Content-Type: multipart/signed; micalg=sha1; 840 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 842 ----BOUNDARY1 843 Content-Type: multipart/related; 844 start=�"; 845 type=�application/ediint-cert-exchange+xml�; 846 boundary="--BOUNDARY2" 848 ----BOUNDARY2 849 Content-Type: application/ediint-cert-exchange+xml 850 Content-ID: 852 [CEM XML data] 853 ----BOUNDARY2 854 [Profile information attachment] 855 ----BOUNDARY2-- 856 ----BOUNDARY1 858 Content-Type: application/pkcs7-signature 860 [Digital Signature] 861 ----BOUNDARY1-- 863 6. Security Considerations 864 Certificate exchange is safe for transmitting. However, implementers 865 SHOULD verify the received certificate to determine if it is truly 866 from the stated originator through out-of-band means or whenever the 867 request is not signed. 869 7. IANA Considerations 871 MIME Media type name: Application 873 MIME subtype name: EDIINT-cert-exchange+xml 875 Required parameters: None 877 Optional parameters: This parameter has identical semantics to the 878 charset parameter of the �application/xml� media type as specified 879 in [RFC3023]. 881 Encoding considerations: Identical to those of "application/xml" as 882 described in [RFC3023], section 3.2. 884 Security considerations: See section 6. 886 Interoperability Considerations: See section 2.2 888 Published specification: This document. 890 Applications which use this media type: EDIINT applications, such as 891 AS1, AS2 and AS3 implementations. 893 Additional Information: None 895 Intended Usage: Common 897 Author/Change controller: See Author�s section of this document. 899 8. References 900 8.1 Normative References 902 [AS1] RFC3335 �MIME-based Secure Peer-to-Peer Business Data 903 Interchange over the Internet using SMTP�, T. Harding, R. 904 Drummond, C. Shih, 2002. 906 [AS2] RFC4130 �MIME-based Secure Peer-to-Peer Business Data 907 Interchange over the Internet using HTTP�, D. Moberg, R. 908 Drummond, 2005. 910 [AS3] draft-ietf-ediint-as3-02.txt �MIME-based Secure Peer-to-Peer 911 Business Data Interchange over the Internet using FTP�, T. 912 Harding, R. Scott, 2003. 914 [EDIINT FEATURE] draft-meadors-ediint-feature-header-00.txt �Feature 915 Header for EDI-INT�, K. Meadors, 2005. 917 [RFC2119] RFC2119 �Key Words for Use in RFC's to Indicate Requirement 918 Levels�, S.Bradner, March 1997. 920 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen, 921 January 1999. 923 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8 924 String Representation of Distinguished Names", M. Wahl, S. Kille 925 and T. Howes, Decemeber 1997. 927 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 928 Levinson, August 1998. 930 [RFC2828] RFC2828 �Internet Security Glossary�, R. Shirley, May 2000. 932 [RFC3023] RFC3023 �XML Media Types�, M. Murata, January 2001. 934 [3821] RFC3821 �S/MIME Version 3.1 Message Specification�, B. 935 Ramsdell, July 2004. 937 [XML-DSIG] RFC3275 �XML-Signature Syntax and Processing�, D. 938 Eastlake, March 2002. 940 [X.520] ITU-T Recommendation X.520: Information Technology - Open 941 Systems Interconnection - The Directory: Selected Attribute 942 Types, 1993. 944 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 945 X.509 Public Key Infrastructure: Certificate and CRL Profile", 946 RFC 3280, April 2002. 948 8.2 Informative References 950 9. Acknowledgments 952 The authors wish to extend gratitude to the ecGIF sub-committee 953 within the GS1 organization from which this effort began. Of special 954 note is John Duker who chaired the sub-committee and provided 955 valuable editing, Richard Bigelow who greatly assisted development of 956 the ideas presented and John Koehring with his insights on 957 implementation and Debra Petta for her review and comments. 959 Author's Addresses 961 Kyle Meadors 962 Drummond Group Inc. 963 4700 Bryant Irvin Court, Suite 303 964 Fort Worth, TX 76107 USA 965 Email: kyle@drummondgroup.com 967 Dale Moberg 968 Cyclone Commerce 969 8388 E. Hartford Drive, Suite 100 970 Scottsdale, AZ 85255 USA 971 Email: dmoberg@cyclonecommerce.com 973 Copyright Notice 974 Copyright (C) The Internet Society (2006). This document is subject 975 to the rights, licenses and restrictions contained in BCP 78, and 976 except as set forth therein, the authors retain all their rights. 978 This document and the information contained herein are provided on an 979 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 980 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 981 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 982 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 983 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 984 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 Appendix 988 A.1 EDIINT Certificate Exchange XML Schema 990 991 997 998 999 1000 1001 1002 1004 1005 1006 1007 1008 1009 1010 1011 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1074 1075 1076 1078 A.2 Example of EDIINT Certificate Exchange Request XML 1080 1081 1085 1086 DGI_Test_CEM 1087 1088 2005-08-30T00:30:00-05:00 1089 1090 1091 keyEncipherment 1092 digitalSignature 1093 2005-09-30T12:00:00-05:00 1094 http://10.1.1.1/as2 1095 1096 1097 CN=Cleo- 1098 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1099 Worth,S=Texas,C=US 1100 9659684611094873474886 1101 1102 1103 SignEncCert-Example_vs02@example.org 1104 1105 1106 1107 tlsServer 1108 2005-09-30T12:00:00-05:00 1109 http://10.1.1.1/as2 1110 1111 1112 CN=VeriSign Class 1 CA Individual 1113 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1114 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1115 Inc. 1116 2673611014597817669550861744279966682 1118 1119 1120 SSLCert-Example_vs02@example.org 1121 1122 1123 1125 A.3 Example of EDIINT Certificate Exchange Response XML 1127 1128 1132 1133 DGI_Test_CEM_Trading_Partner 1134 1135 2005-08-31T00:21:00-05:00 1136 1137 1138 Accepted 1139 1140 CN=Cleo- 1141 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft. 1142 Worth,S=Texas,C=US 1143 9659684611094873474886 1144 1145 1146 1147 Accepted 1148 1149 CN=VeriSign Class 1 CA Individual 1150 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA 1151 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\, 1152 Inc. 1153 2673611014597817669550861744279966682 1155 1156 1157 1159 Changes from Previous Versions 1161 B.1 Updates from Version 00 1163 . Updated security requirements in section 2.1, specifically in 1164 regards to digital signatures. 1165 . The XML element responseURL is now required. Modified section 1166 3.1 and example messages in appendix accordingly. 1167 . Certificates are exchanged within a full P7C cert chain. Section 1168 2.3 reflects this. 1169 . The XML element TrustChain is not longer necessary since the 1170 entire cert chain is stored. Removed references in schema and 1171 document. 1172 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be 1173 sent and that if this occurs, the action of the CEM Request 1174 initiator is not defined. 1175 . Updated the examples in Appendix B to reflect the current usage. 1177 B.2 Updates from Version 01 1179 . Added information for handling different scenarios with CEM 1180 Response message. 1181 . Rewrote use case scenarios. 1182 . Added the EDIINT Features header information. 1184 B.3 Updates from Version 02 1186 . Modified use of SSL certificates to match real�world needs. 1187 . Modified schema in changing namespace value and removed schema 1188 location. 1189 . Added statement that CEM XML must be well�formed and valid to 1190 schema. 1191 . Modified Use Case to correct an error and improve clarity. 1192 . Added section 1.4 to describe CEM process.