idnits 2.17.1 draft-meadors-certificate-exchange-00.txt: -(150): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(155): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(528): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(618): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(623): 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 -(857): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(893): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(904): 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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 959. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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-00' == There are 42 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 2005) is 7040 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 245, but not defined == Unused Reference: 'RFC2119' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 896, but no explicit reference was found in the text == Unused Reference: '3821' is defined on line 908, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-ediint-as2-15 == 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') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** 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: 16 errors (**), 1 flaw (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission K. Meadors 3 Internet-Draft Drummond Group Inc. 4 Document: draft-meadors-certificate-exchange- D. Moberg 5 00.txt Cyclone Commerce 6 Expires: July 2005 January 2005 8 Certificate Exchange Messaging for EDIINT 9 draft-meadors-certificate-exchange-00.doc 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Any questions, comments, and reports of defects or ambiguities in 37 this specification may be sent to the mailing list for the EDIINT 38 working group of the IETF, using the address . 39 Requests to subscribe to the mailing list should be addressed to 40 . 42 Abstract 44 The EDIINT AS1, AS2 and AS3 message formats do not currently contain 45 any neutral provisions for transporting and exchanging trading 46 partner profiles or digital certificates. EDIINT Certificate Exchange 47 Messaging provides the format and means to effectively exchange 48 certificates for use within trading partner relationships. The 49 messaging consists of two types of messages, Request and Response, 50 which allow trading partners to communicate certificates, their 51 intended usage and their acceptance through XML. Certificates can be 52 specified for use in digital signatures, data encryption or SSL/TLS 53 over HTTP (HTTPS). 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119. 61 Feedback Instructions 63 NOTE TO RFC EDITOR: This section should be removed by the RFC editor 64 prior to publication. 66 If you want to provide feedback on this draft, follow these 67 guidelines: 69 -Send feedback via e-mail to kyle@drummondgroup.com, with 70 "Certificate Exchange" in the Subject field. 72 -Be specific as to what section you are referring to, preferably 73 quoting the portion that needs modification, after which you state 74 your comments. 76 -If you are recommending some text to be replaced with your suggested 77 text, again, quote the section to be replaced, and be clear on the 78 section in question. 80 Table of Contents 82 1. Introduction...................................................3 83 1.1 Overview...................................................3 84 1.2 Terminology and Key Word Convention........................3 85 1.3 Certificate Lifecycle......................................5 86 2. Message Processing.............................................5 87 2.1 Message Structure..........................................5 88 2.2 Version Header.............................................7 89 2.3 Certificate Exchanging.....................................7 90 2.4 Certificate Implementation.................................8 91 2.5 CEM Response...............................................9 92 3. XML Schema Description.........................................9 93 3.1 EDIINTCertificateExchangeRequest element...................9 94 3.2 EDIINTCertificateExchangeResponse element.................12 96 4. Use Case Scenarios............................................14 97 4.1 Maintenance Configuration Processing......................14 98 4.2 Initial Configuration Processing..........................15 99 5. Profile Exchange Messaging....................................17 100 6. Security Considerations.......................................18 101 7. IANA Considerations...........................................18 102 8. References....................................................19 103 8.1 Normative References......................................19 104 8.2 Informative References....................................20 105 9. Acknowledgments...............................................20 106 Author's Addresses...............................................20 107 Appendix.........................................................20 109 1. Introduction 111 1.1 Overview 113 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in 114 numerous supply-chains was due in part to the security feature which 115 was provided. The security is not possible without the digital 116 certificates which enable it. To maintain the level of security 117 necessary to transmit business documentation, existing certificates 118 must occasionally be replaced and exchanged with newer ones. The 119 exchanging of digital certificates is unavoidable given how 120 certificates can expire or become compromised. Complicating this is 121 supply-chains which cannot afford to shutdown their business 122 transactions while trading partners laboriously upload new 123 certificates. Certificate exchange must be accomplished in a reliable 124 and seamless format so as not to affect ongoing business 125 transactions. 127 This document describes how EDIINT products may exchange public-key 128 certificates. Since EDIINT is built upon the security provided by 129 public-private key pairs, it is vital that implementers are able to 130 update their trading partners with new certificates as their old 131 certificates expire, become outdated or insecure. EDIINT Certificate 132 Exchange Messaging (CEM) described here utilizes XML data to exchange 133 the certificate and provide information on its intended usage and 134 acceptance within the trading partner relationship. There are two 135 types of CEM messages, the CEM Request which presents the new 136 certificate to be introduced into the trading partner relationship 137 and the CEM Response which is the recipient�s response to the CEM 138 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or 139 AS3 [AS3] message transports. However, it is possible to leverage CE 140 messaging through other transport standards besides EDIINT. 142 1.2 Terminology and Key Word Convention 144 [RFC2818] provides a glossary of Internet security terms, and several 145 of their definitions are listed here verbatim. However, some 146 definitions required for this document were undefined by [RFC2818] or 147 rewritten to better explain their specific use within CEM. 149 Certificate � A digital certificate contains the owner�s (End 150 Entity�s) name, the issuer�s name, a serial number, expiration date, 151 and a copy of the owner�s Public Key. The Public Key is used for 152 Encrypting messages and Verifying Signatures (verifying a signature 153 is also called Authentication). 155 Certificate Revocation List (CRL) � A data structure that enumerates 156 digital certificates that have been invalidated by their issuer prior 157 to when they were scheduled to expire. [RFC2828] 159 Certification Authority (CA) � An entity that issues digital 160 certificates (especially X.509 certificates) and vouches for the 161 binding between the data items in a certificate. [RFC2828] 163 CA Certificate - A certificate issued by a trusted certification 164 authority. CA certificates are not used to encrypt data but to sign 165 other certificates. CA certificates are signed by themselves, but are 166 not considered self-signed certificates for the purpose of this 167 document. 169 Certification Hierarchy - In this structure, one CA is the top CA, 170 the highest level of the hierarchy. The top CA may issue public-key 171 certificates to one or more additional CAs that form the second 172 highest level. Each of these CAs may issue certificates to more CAs 173 at the third highest level, and so on. The CAs at the second-lowest 174 of the hierarchy issue certificates only to non-CA entities, called 175 "end entities" that form the lowest level. Thus, all certification 176 paths begin at the top CA and descend through zero or more levels of 177 other CAs. All certificate users base path validations on the top 178 CA's public key. [RFC2828] 180 CEM Request �The EDIINT Certificate Exchange Messaging (CEM) Request 181 is one of two possible CEM messages. It presents a certificate to be 182 introduced into the trading partner relationship along with relevant 183 information on how it is to be implemented. 185 CEM Response �The EDIINT Certificate Exchange Messaging (CEM) 186 Response is one of two possible CEM messages. It is the response to 187 the CEM Request indicating whether or not the end entity certificate 188 present in the CEM Request was accepted. 190 End Entity � A system entity that is the subject of a public-key 191 certificate and that is using, or is permitted and able to use, the 192 matching private key only for a purpose or purposes other than 193 signing a digital certificate; i.e., an entity that is not a CA. 194 [RFC2828] 196 End Entity Certificate - A certificate which is used to encrypt data 197 or authenticate a signature. (The private key associated with the 198 certificate is used to decrypt data or sign data). The certificate 199 may be self-signed or issued by a trusted certificate. 201 Intermediary Certificate - A certificate issued by a CA certificate 202 which itself issues another certificate (either intermediary or end 203 entity). Intermediary certificates are not used to encrypt data but 204 to sign other certificates. 206 Public Key - The publicly-disclosable component of a pair of 207 cryptographic keys used for asymmetric cryptography. [RFC2828] 209 Public Key Certificate - A digital certificate that binds a system 210 entity's identity to a public key value, and possibly to additional 211 data items. [RFC2828] 213 Self-signed Certificate - A certificate which is issued by itself 214 (both issuer and subject are the same) and is an End Entity 215 certificate. 217 1.3 Certificate Lifecycle 219 A certificate has five states. 221 1. Pending - Upon receiving a certificate from a trading partner, the 222 certificate is marked as Pending until a decision can be made to 223 trust it or if its validity period has not yet begun. 224 2. Rejected � If a Pending certificate is not trusted, it is 225 considered Rejected. 226 3. Accepted - Once a Pending certificate has been trusted, it is 227 considered Accepted. An Accepted certificate may be used in 228 secure transactions. 229 4. Expired � A certificate which is no longer valid because its 230 expiration date has passed. Expired certificates SHOULD be kept 231 in a certificate storehouse for decrypting and validating past 232 transactions. 233 5. Revoked � A certificate which has been explicitly revoked by its 234 owner or the certificate authority. 236 2. Message Processing 238 2.1 Message Structure 240 CEM messages use the underlying EDIINT transport, such as AS2, to 241 communicate information on the certificate, its intended use and its 242 acceptance. Both digital certifications and the XML data describing 243 their intended use are stored within a multipart-related MIME 244 envelope [RFC2387]. The certificates are stored in SMIME, certs-only 245 MIME envelope [3851], and processing information is XML data which is 246 identified through the MIME content-type of application/ediint-cert- 247 exchange+xml. The format for CEM messages is as follows: 249 Various EDIINT headers 250 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company 251 Content-Type: multipart/signed; micalg=sha1; 252 protocol="application/pkcs7-signature"; 253 boundary="--OUTER-BOUNDARY" 255 ----OUTER-BOUNDARY 256 Content-Type: multipart/related; type="application/ediint-cert- 257 exchange+xml"; boundary="--INNER-BOUNDARY" 259 ----INNER-BOUNDARY 260 Content-Type: application/ediint-cert-exchange+xml 261 Content-ID: <20040101-1.alpha@example.org> 263 [CEM XML data] 264 ----INNER-BOUNDARY 265 Content-Type: application/pkcs7-mime; smime-type=certs-only 266 Content-ID: <20040101-2.alpha@example.org> 268 [digital certificate] 269 ----INNER-BOUNDARY-- 271 ----OUTER-BOUNDARY 272 Content-Type: application/pkcs7-signature 274 [Digital Signature] 275 ----OUTER-BOUNDARY-- 277 One and only one MIME type of application/ediint-cert-exchange+xml 278 MUST be present in the multipart/related structure, and it MUST be 279 the root element. Multiple certs-only media types may be included, 280 but at least one MUST be present. A unique content-id header MUST be 281 present within each of the multipart structures. 283 Both the CEM Request and CEM Response message SHOULD be signed. If it 284 is desired to enable automatic exchange based on a previous trust 285 relationship, then both the CEM Request and CEM Response message MUST 286 be signed. Also, CEM messages SHOULD request a MDN and SHOULD request 287 a signed MDN. Extra security such as applying data encryption is 288 OPTIONAL. The MDN can be either synchronous or asynchronous. The MDN 289 response verifies the transport delivery but is not equivalent to the 290 CEM Response message. All necessary headers MUST be applied to the 291 message per the underlying transport standard. 293 2.2 Version Header 295 Before a CEM Request message is generated, the initiator MUST 296 determine if the recipient can accept the CEM Request message. For 297 both AS2 and AS3, the version header value of 1.2 or greater (e.g. 298 1.3) indicates the implementation can both initiate and receive CEM 299 message exchanges. AS2 and AS3 implementers of CEM MUST utilize the 300 proper version header in all of their messages, both CEM messages and 301 normal document transport messages. Since there is no AS1 version 302 header, trading partners using AS1 MUST decide within the trading 303 partner agreement whether to utilize CEM. 305 For CEM Request messages of initial trading partner configurations, 306 the initiator MUST decide within the trading partner agreement if the 307 recipient can accept the CEM Request. 309 2.3 Certificate Exchanging 311 After obtaining the desired certificate, the initiator of the 312 certificate exchange transmits the end-entity certificate in the CEM 313 Request message. If the end-entity certificate is not self-signed, 314 then the CA certificate and any other certificates needed to create 315 the chain of trust for the end-entity certificate MUST be included in 316 the CEM Request message. Multiple end-entity certificates MAY also be 317 present. 319 Certificates are referenced and identified in the XML data by their 320 content-id used in the multipart-related structure. Information on 321 how the certificate is to be used, or certificate usage, by the user 322 agent and other related information is found in the XML data. A 323 certificate can be used for a single function, like digital 324 signatures, or used for multiple functions, such as both digital 325 signatures and data encryption. If a certificate is intended for 326 multiple usages, such as for both digital signatures and data 327 encryption, the certificate MUST be listed only once in the CEM 328 Request message and its multiple usage listed through the CertUsage 329 XML element. 331 Upon receipt of the CEM Request, the recipient trading partner 332 processes the transport message as normal and returns the MDN. The 333 recipient MUST return the MDN before parsing and interpreting the CEM 334 XML data. The returned MDN only provides information on the veracity 335 of the transport message and not the acceptance of the certificate(s) 336 being exchanged. 338 2.4 Certificate Implementation 340 The new certificate is considered to be in the Pending state for the 341 recipient who MUST decide whether to accept the certificate as 342 trustworthy. This decision is arbitrary and left to each individual 343 trading partner. Upon accepting the certificate, it is to be 344 considered an Accepted certificate within the trading partner 345 relationship. If the certificate is not accepted, it is considered 346 Rejected. 348 When a certificate is intended for use in data encryption or TLS/SSL 349 server authentication, the initiator MUST consider the certificate to 350 be Accepted and be prepared for its trading partner to begin using 351 the certificate upon generating the CEM Request message. After a 352 recipient generates a positive CEM Response message for a 353 certificate, the recipient MUST immediately begin using the 354 certificate in trading with the initiator of the request. The 355 recipient MAY apply encryption to the CEM Response message using the 356 new Accepted certificate or MAY apply encryption to the CEM Response 357 message using the previously Accepted encryption certificate. 359 When a certificate is intended for use in digital signatures or 360 TLS/SSL client authentication, the initiator MUST NOT use the 361 certificate until the recipient trading partner generates a CEM 362 Response accepting the certificate or the start of the respond by 363 date, which is listed in the RespondByDate XML element. The initiator 364 MAY use the certificate after the respond by date, regardless of 365 whether the partner has accepted it or not. The certificate used for 366 the digital signature of the CEM Request message MUST be the one 367 which is currently Accepted within the trading partner relationship. 369 Since implementers of EDIINT often use the same certificate with 370 multiple trading partners, implementers of CEM MUST be able to keep 371 both the old and new certificates as Accepted. If the initiator has 372 generated a CEM Request and exchanged a new encryption certificate to 373 multiple trading partners, it MUST be able to accept encrypted data 374 which uses either the older, existing encryption certificate or the 375 newly exchanged encryption certificate. Likewise, a recipient of a 376 CEM Request MUST be able to authenticate digital signatures using 377 either the new or old certificates, since the initiator may not be 378 able to switch certificates until all trading partners accept the new 379 certificate. Similar provisions MUST be made for certificates 380 intended for TLS/SSL server and client authentication. Revoking a 381 certificate MUST be done outside of CEM. 383 If a CEM Request message contains a certificate which is currently 384 Accepted and has the identical usage for the certificate that has 385 been Accepted, the recipient MUST NOT reject the duplicate 386 certificate but MUST respond with a CEM Response message indicating 387 the certificate has been accepted. For example, if Certificate A is 388 currently Accepted as the encryption certificate for a user agent, 389 any CEM Request message containing Certificate A with the usage as 390 the encryption only MUST be accepted by an existing trading partner. 391 This situation may be necessary for an implementation intending to 392 verify its current trading partner certificate. 394 If two trading partners utilize multiple EDIINT protocols for 395 trading, such as AS2 for a primary transport and AS1 as the backup 396 transport, it is dependent upon implementation and trading partner 397 agreement how CEM messages are sent and which transports the 398 exchanged certificates affect. 400 2.5 CEM Response 402 If a CEM Request is received, the recipient MUST respond with a CEM 403 Response message indicating if the certificate is Accepted or 404 Rejected. If multiple end-entity certificates were included within 405 the CEM Request, the recipient MAY generate individual CEM Response 406 messages for each certificate or the recipient MAY consolidate 407 responses for multiple certificates in one or more CEM Response 408 messages. The recipient MUST NOT generate more than one CEM Response 409 for a given end-entity certificate. CEM Response are NOT sent for any 410 certificates other than end-entity certificates. Based on the CEM 411 Response message, the initiator determines if the exchanged 412 certificate may be used in future trading with the recipient partner. 414 3. XML Schema Description 416 The CEM schema has two top-level elements, 417 EDIINTCertificateExchangeRequest and 418 EDIINTCertificateExchangeResponse. The 419 EDIINTCertificateExchangeRequest element is present only in the CEM 420 Request message, and the EDIINTCertificateExchangeResponse is present 421 only in the CEM Response message. All other elements nest directly or 422 indirectly from these. Please refer to the appendix for the actual 423 schema document. 425 3.1 EDIINTCertificateExchangeRequest element 427 EDIINTCertificateExchangeRequest contains two elements, 428 TradingPartnerInfo, which can only appear once and TrustRequest, 429 which may be present multiple times. TrustRequest contains 430 information on a certificate and its intended usage. 431 TradingPartnerInfo exists to provide information on the publication 432 of the CEM Request message since processing of the XML data may occur 433 apart from the handling of the accompanying transport message, for 434 example the AS2 request. 436 437 438 439 440 443 444 445 447 TradingPartnerInfo identifies the entity that created the CEM message 448 through the nested Name element. Both the optional qualifier 449 attribute and the element value of Name are left open to the 450 implementer, but some suggested choices are to list the EDI 451 identification or the transport trading partner relationship, for 452 example the qualifier of �AS2� and the value of the AS2 system 453 identifier (AS2-From value). MessageOriginated is included in 454 TradingPartnerInfo to identify the time and date the message was 455 created. The MessageOriginated date and time values MUST follow XML 456 standard dateTime type syntax and be listed to at least the nearest 457 second and expressed in local time with UTC offset. 459 460 461 462 463 464 465 466 468 469 470 471 472 473 474 475 477 The TrustRequest element contains the EndEntity, TrustChain, 478 CertUsage, RespondByDate and ResponseURL elements. The required 479 EndEntity element is found only once in a TrustRequest element and 480 contains the content-id reference to the end-entity certificate being 481 exchanged. TrustChain references any certificates necessary to 482 complete the chain of trust for the end entity certificate. For 483 example, if the end entity certificate being exchanged is self-signed 484 then there would not be a TrustChain element. However, if the end 485 entity certificate is issued by an intermediary certificate which is 486 issued by a root CA certificate, both the intermediary certificate 487 and the CA certificate would be referenced in the same 488 CertificateContentID element within the same TrustChain element. 490 491 492 493 494 495 496 498 499 501 EndEntity contains the nested elements of CertificateIdentifier and 502 CertificateContentID, and TrustChain only contains 503 CertificateContentID. CertificateContentID is a string element which 504 references the content-id of the multipart/related structure where 505 the certificate is stored. CertificateIdentifier comes from the XML 506 Signature schema namespace [XML-DSIG]. 508 509 510 512 513 515 516 517 518 519 521 CertificateIdentifier contains the string element X509IssuerName and 522 the integer element X509SerialNumber. X509SerialNumber is the 523 assigned serial number of the end entity certificate as it is listed. 524 X509IssuerName contains the issuer name information of the end-entity 525 certificate, such as common name, organization, etc. This information 526 can be described in any format, but it is RECOMMENDED to list each 527 issuer attribute abbreviation [X.520] [PROFILE] followed by the equal 528 sign (i.e. �=�), then separating each attribute listing by a single 529 semi-colon (e.g. CN=The Common Name;O=Organization;�). Refer to the 530 appendix and the sample CEM Request message for an example of the 531 X509IssuerName. 533 534 535 536 537 538 540 CertUsage is an unbounded element which contains enumerated values on 541 how the exchanged certificate is to be used. There are enumerated 542 values for SMIME digital signatures (digitalSignature), SMIME data 543 encryption (keyEncipherment), the server certificate used in TLS 544 transport encryption (tlsServer) and the client certificate used in 545 TLS transport encryption (tlsClient). While the element is unbounded, 546 CertUsage only has a potential number of four occurrences due to the 547 limit of the enumerated values. 549 550 551 552 553 554 555 556 557 559 RespondByDate is a required element of the XML standard dateTime type 560 expressed in local time with UTC offset, which provides information 561 on when the certificate should be trusted, inserted into the trading 562 partner relationship and responded to by a CEM Response message. If 563 the certificate can not be trusted or inserted into the trading 564 partner relationship, the CEM Response message should still be 565 returned by the date indicated. 567 569 ResponseURL is an optional element which indicates where the CEM 570 Response message should be sent. This value takes precedence over the 571 existing inbound URL of the current trading partner relationship. If 572 the element is absent, the CEM Response message is returned according 573 to the URL stipulated in the trading partner relationship. The 574 Response MUST use the same transport protocol (AS1, AS2, or AS3) as 575 the Request. The Response URL MUST use this protocol. 577 579 3.2 EDIINTCertificateExchangeResponse element 580 EDIINTCertificateExchangeResponse contains the two elements 581 TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is 582 also found in EDIINTCertificateExchangeRequest, describes the trading 583 partner generating this response message. TrustResponse provides 584 information on the acceptance of a previously sent end entity 585 certificate. There can be multiple TrustResponse elements within an 586 EDIINTCertificateExchangeResponse. 588 589 590 591 592 595 596 597 599 600 601 602 603 605 606 608 A TrustResponse element identifies a certificate which has been 609 previously exchanged within the trading partner relationship through 610 a CEM Request and now has been either accepted or rejected by the 611 partner. The CertificateReference element is of the same type as the 612 CertificateIdentifier element. A CertificateReference element in a 613 CEM Response MUST be identical to its CertificateIdentifier 614 counterpart in the associated CEM Request since they identify the 615 same certificate in question. 617 The required element CertStatus has the enumerated values of 618 �Accepted� or �Rejected�. �Accepted� indicates the certificate was 619 trusted by the trading partner and is now ready for use within the 620 trading partner relationship, and �Rejected� indicates the 621 certificate is not trusted by the trading partner nor can it be 622 currently used with the trading partner relationship. If the value of 623 �Rejected� is chosen, the optional string element ReasonForRejection 624 may be included. If present, ReasonForRejection should contain a 625 brief description of why the certificate was not accepted. Since the 626 value for this element is not enumerated but open, it MUST be 627 interpreted through human means. 629 630 631 632 633 634 635 636 638 4. Use Case Scenarios 640 These scenarios illustrate how the request and response messages 641 described in Section 2 and 3 can be used to exchange certificates. 642 The requirements of this standard are in Section 2 and 3; this 643 section is only illustrative. 645 4.1 Maintenance Configuration Processing 647 This use case assumes an established relationship with currently 648 working certificates. Examples of this use case include, but are not 649 limited to a certificate with an expiration date approaching. If the 650 current certificate is used to sign the Certificate Exchange 651 messages, this signature can be used to establish a level of trust in 652 the transaction. For this example, the AS2 transport protocol is 653 used. 655 4.1.1. Step 1 657 Initiator creates an EDIINTCertificateExchangeRequest as described in 658 Section 2. Message Processing and Section 3. XML Schema Description 659 and sends it according to EDIINT-AS2 protocol. A positive MDN 660 received during this step indicates successful transmission of the 661 message but does not imply successful action on the certificate. In 662 the case of an encryption certificate, the initiator MUST be 663 immediately ready to receive documents encrypted with the new 664 certificate. In the case of a signing certificate, the initiator can 665 begin signing documents with the new certificate at the RespondByDate 666 or upon receipt of an EDIINTCertificateExchangeResponse from the 667 partner indicating acceptance of the certificate. If an acceptance 668 response is not received by the RespondByDate, the initiator may or 669 may not begin signing with the new certificate, depending on the 670 implementation�s capabilities and the policies of the initiator. 672 4.1.2. Step 2 674 Receiver validates the EDIINTCertificateExchangeRequest message at 675 the AS2 level and returns a correct MDN. If the message is a proper 676 AS2 document, the receiver MUST automatically accept or reject the 677 new certificate(s) or require manual intervention. If the certificate 678 is automatically accepted or rejected, an 679 EDIINTCertificateExchangeResponse MUST be generated and returned to 680 the initiator. Since the trading relationship could be hindered if 681 action is not taken prior to the RespondByDate, manual intervention 682 MUST be done before that date. When the manual intervention 683 determines to accept or reject the new certificate, an 684 EDIINTCertificateExchangeResponse MUST be generated and returned to 685 the initiator. Both automatic and manual 686 EDIINTCertificateExchangeResponses MUST be formatted according to 687 Section 2. Message Processing and Section 3. XML Schema Description 688 and sent according to EDIINT-AS2 protocol. A positive MDN received 689 for the response message indicates successful transmission of the 690 response message. 692 After the receiver accepts the new certificate and returns an 693 acceptance response, the receiver encrypts all messages to the 694 initiator with the new encryption certificate. The receiver 695 continues to accept messages from the initiator that are signed with 696 the old signing certificate, and also accepts messages signed with 697 the new signing certificate. The initiator may start signing with 698 the new certificate when it receives the acceptance response, or when 699 it receives acceptance responses from all its partners, or after the 700 RespondByDate, or when the old signing certificate expires. 702 4.1.3. Step 3 704 After the exchange is complete, some cleanup may be desirable, 705 including retiring or archiving the old certificates. This step is 706 considered an implementation detail that is left purely to the 707 vendors and users. 709 4.2 Initial Configuration Processing 711 This use case assumes all necessary elements of an EDIINT 712 relationship exist outside of the certificates, including an 713 understanding of the partner�s ability to support a CEM. 714 Establishing these elements may be accomplished via an automated 715 exchange, a manual process, or any other method desirable. No 716 methods of exchanging the additional information are described in 717 this specification. Examples of this use case include, but are not 718 limited to the first exchange of a certificate, or recovery from an 719 expired or compromised certificate. This case assumes no signing 720 certificate has been established, precluding a signature being used 721 to establish a level of trust. Therefore, extra precautions may be 722 appropriate in this use case. There are additional use cases 723 possible where some certificates are already established. It is not 724 practical to cover every case here, but this case and the maintenance 725 case should give sufficient guidance. 727 4.2.1. Step 1 729 Initiator creates an EDIINTCertificateExchangeRequest as described in 730 Section 2.0 Message Format and Section 3.0 XML Schema. The initiator 731 sends it according to EDIINT-AS2 protocol. Using a digital signature 732 on the AS2 message is optional, as the receiver will not be able to 733 verify until after accepting the signature certificate. If the 734 receiver supports this use case, they MUST accept this message 735 regardless of the presence of a signature. Unless the initiator 736 possesses the receiver�s encryption certificate, encryption MUST NOT 737 be used. Unless the initiator possesses the receiver�s signature 738 certificate, they SHOULD NOT request a signed MDN. If the MDN is not 739 signed, there is no legal proof the receiver received the message. 740 In addition, a positive MDN received during this step gives some 741 indication of successful transmission of the message, but does not 742 imply successful action on the certificate. In the case of an 743 encryption certificate, the initiator MUST be immediately ready to 744 receive documents encrypted with the new certificate. In the case of 745 a signing certificate, the initiator can begin signing documents with 746 the new certificate at the RespondByDate or upon receipt of an 747 EDIINTCertificateExchangeResponse from the partner indicating they 748 are ready. If an acceptance response is not received by the 749 RespondByDate, the initiator may or may not begin signing with the 750 new certificate, depending on the implementation�s capabilities and 751 the policies of the initiator. 753 4.2.2. Step 2 755 Receiver validates the EDIINTCertificateExchangeRequest message at 756 the AS2 level and returns an MDN according to the EDIINT-AS2 757 protocol. If the message is a proper AS2 document, the receiver MUST 758 automatically accept or reject the new certificate(s), or require 759 manual intervention. Caution should be used in automatically 760 accepting the certificate, as it may be impossible to verify the 761 sender is authentic. If the certificate is automatically accepted or 762 rejected, an EDIINTCertificateExchangeResponse MUST be generated and 763 returned to the initiator. Since the trading relationship could be 764 hindered if action is not taken prior to the RespondByDate, manual 765 intervention MUST be done before that date. When the manual 766 intervention determines to accept or reject the certificate, an 767 EDIINTCertificateExchangeResponse MUST be generated and returned to 768 the initiator. 770 In both the automatic and manual case, the 771 EDIINTCertificateExchangeResponses MUST be formatted according to 772 Section 2. Message Processing and Section 3. XML Schema Description 773 and sent according to EDIINT-AS2 protocol. If the original CEM 774 included the encryption certificate, or if the receiver has the 775 initiator encryption certificate on file, it may be used to encrypt 776 the AS2 message including the EDIINTCertificateExchangeResponse. 777 Otherwise, it may be necessary to send this 778 EDIINTCertificateExchangeResponse unencrypted. The message may be 779 signed, but it is possible the initiator will have no way to verify 780 the signature. The initiator MUST accept this response, regardless 781 of if it is signed. A positive MDN received for the response message 782 indicates successful transmission of the response message. 784 After the receiver accepts the certificate and returns an acceptance 785 response, the receiver may encrypt messages to the initiator with the 786 encryption certificate. The receiver begins to accept messages from 787 the initiator that are signed with the signing certificate. The 788 initiator may start signing with the certificate when it receives the 789 acceptance response, or when it receives acceptance responses from 790 all its partners, or after the RespondByDate. 792 4.2.3. Step 3 794 After the exchange is complete, additional certificates may need to 795 be exchanged before a complete trading relationship can be 796 successful. This step is considered an implementation detail that 797 is left purely to the vendors and users. 799 5. Profile Exchange Messaging 801 CEM provides the means to exchange certificates among trading 802 partners. However, other profile information, such as URLs and 803 preferred security settings, is needed to create a trading partner 804 relationship. A future standard is needed to describe profile 805 descriptions and how they will be exchanged. The format for this 806 profile attachment is not defined in this specification but is 807 planned for a future document. It will build upon the existing CEM 808 protocol with profile information stored with XML data. Both 809 certificate and profile description information will be placed into a 810 multipart/related [RFC2387] body part entity. A possible format for a 811 profile description message is as follows: 813 Various EDIINT headers 814 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company 815 Disposition-Notification-Options: signed-receipt-protocol=optional, 816 pkcs7-signature; signed-receipt-micalg=optional, sha1 817 Content-Type: multipart/signed; micalg=sha1; 818 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1" 820 ----BOUNDARY1 821 Content-Type: multipart/related; 822 start=�"; 823 type=�application/ediint-cert-exchange+xml�; 824 boundary="--BOUNDARY2" 826 ----BOUNDARY2 827 Content-Type: application/ediint-cert-exchange+xml 828 Content-ID: 830 [CEM XML data] 831 ----BOUNDARY2 832 [Profile information attachment] 833 ----BOUNDARY2-- 834 ----BOUNDARY1 836 Content-Type: application/pkcs7-signature 838 [Digital Signature] 839 ----BOUNDARY1-- 841 6. Security Considerations 843 Certificate exchange is safe for transmitting. However, implementers 844 SHOULD verify the received certificate to determine if it is truly 845 from the stated originator through out-of-band means for the initial 846 use case of 4.2 or whenever the request is not signed. 848 7. IANA Considerations 850 MIME Media type name: Application 852 MIME subtype name: EDIINT-cert-exchange+xml 854 Required parameters: None 856 Optional parameters: This parameter has identical semantics to the 857 charset parameter of the �application/xml� media type as specified 858 in [RFC3023]. 860 Encoding considerations: Identical to those of "application/xml" as 861 described in [RFC3023], section 3.2. 863 Security considerations: See section 6. 865 Interoperability Considerations: See section 2.2 867 Published specification: This document. 869 Applications which use this media type: EDIINT applications, such as 870 AS1, AS2 and AS3 implementations. 872 Additional Information: None 874 Intended Usage: Common 876 Author/Change controller: See Author�s section of this document. 878 8. References 879 8.1 Normative References 881 [AS1] RFC3335 �MIME-based Secure Peer-to-Peer Business Data 882 Interchange over the Internet using SMTP�, T. Harding, R. 883 Drummond, C. Shih, 2002. 885 [AS2] draft-ietf-ediint-as2-15.txt �MIME-based Secure Peer-to-Peer 886 Business Data Interchange over the Internet using HTTP�, D. 887 Moberg, R. Drummond, 2004. 889 [AS3] draft-ietf-ediint-as3-02.txt �MIME-based Secure Peer-to-Peer 890 Business Data Interchange over the Internet using FTP�, T. 891 Harding, R. Scott, 2003. 893 [RFC2119] RFC2119 �Key Words for Use in RFC's to Indicate Requirement 894 Levels�, S.Bradner, March 1997. 896 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen, 897 January 1999. 899 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 900 Levinson, August 1998. 902 [RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000. 904 [RFC2828] RFC2828 �Internet Security Glossary�, R. Shirley, May 2000. 906 [RFC3023] RFC3023 �XML Media Types�, M. Murata, January 2001. 908 [3821] RFC3821 �S/MIME Version 3.1 Message Specification�, B. 909 Ramsdell, July 2004. 911 [XML-DSIG] RFC3275 �XML-Signature Syntax and Processing�, D. 912 Eastlake, March 2002. 914 [X.520] ITU-T Recommendation X.520: Information Technology � Open 915 Systems Interconnection - The Directory: Selected Attribute 916 Types, 1993. 918 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 919 X.509 Public Key Infrastructure: Certificate and CRL Profile", 920 RFC 3280, April 2002. 922 8.2 Informative References 924 9. Acknowledgments 926 The authors wish to extend gratitude to the ecGIF sub-committee 927 within the EAN.UCC organization from which this effort began. Of 928 special note is John Duker who chaired the sub-committee and provided 929 valuable editing, Richard Bigelow who greatly assisted development of 930 the ideas presented, John Koehring with his insights on 931 implementation and James Zwyer for his contribution to the use case 932 scenarios. 934 Author's Addresses 936 Kyle Meadors 937 Drummond Group Inc. 938 4700 Bryant Irvin Court, Suite 303 939 Fort Worth, TX 76107 USA 940 Email: kyle@drummondgroup.com 942 Dale Moberg 943 Cyclone Commerce 944 8388 E. Hartford Drive, Suite 100 945 Scottsdale, AZ 85255 USA 946 Email: dmoberg@cyclonecommerce.com 948 Copyright Notice 949 Copyright (C) The Internet Society 2004. This document is subject 950 to the rights, licenses and restrictions contained in BCP 78, and 951 except as set forth therein, the authors retain all their rights. 953 This document and the information contained herein are provided on an 954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 956 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 957 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 958 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 961 Appendix 963 A.1 EDIINT Certificate Exchange XML Schema 965 966 968 975 977 978 979 980 981 983 984 985 986 987 988 989 990 992 993 994 995 996 997 998 999 1000 1001 1002 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1051 1052 1053 1054 1055 1056 1057 1059 1060 1061 1063 A.2 Example of EDIINT Certificate Exchange Request XML 1064 1065 1071 1072 Somewhere.com 1073 2005-05-17T07:21:00-03:00 1074 1075 1076 1077 digitalSignature 1078 2005-05-20T07:21:00-03:00 1079 http://somewhere.com/someplace 1080 1081 1082 CN=EDIINT WG; O=IETF; OU=EDIINT; 1083 L=New York; S=New York; C=US 1084 123454321 1085 1086 0001@example.org 1087 1088 1089 1090 1091 0002@example.org 1092 1093 1094 0003@example.org 1095 1096 1097 1098 1099 keyEncipherment 1100 2005-05-20T07:21:00-03:00 1101 http://foo.com/path 1102 1103 1104 CN=EDIINT WG; O=IETF; OU=EDIINT; 1105 L=New York; S=New York; C=US 1106 987654321 1107 1108 1109 0004@example.org 1110 1111 1112 1113 1114 0005@example.org 1115 1116 1117 0006@example.org 1118 1119 1120 1121 1123 A.3 Example of EDIINT Certificate Exchange Response XML 1125 1126 1132 1133 Rejected 1134 Invalid KeyUsage 1135 extension 1136 1137 CN=EDIINT WG; O=IETF; OU=EDIINT; 1138 L=New York; S=New York; C=US 1139 123454321 1140 1141 1142 1143 Accepted 1144 1145 CN=US;O=Somewhere.com 1146 987654321 1147 1148 1149