idnits 2.17.1
draft-meadors-certificate-exchange-13.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
** There is 1 instance of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Unrecognized Status in '', assuming Proposed Standard
(Expected one of 'Standards Track', 'Full Standard', 'Draft Standard',
'Proposed Standard', 'Best Current Practice', 'Informational',
'Experimental', 'Informational', 'Historic'.)
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 16, 2011) is 4697 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '3851' on line 337
== Missing Reference: 'EDIINT-FEATURE' is mentioned on line 418, but not
defined
== Unused Reference: 'EDIINT FEATURE' is defined on line 1073, but no
explicit reference was found in the text
== Unused Reference: 'RFC2119' is defined on line 1076, but no explicit
reference was found in the text
== Unused Reference: 'RFC2246' is defined on line 1079, but no explicit
reference was found in the text
== Unused Reference: 'PROFILE' is defined on line 1100, but no explicit
reference was found in the text
-- Unexpected draft version: The latest known version of
draft-ietf-ediint-as3 is -04, but you're referring to -05.
** Downref: Normative reference to an Informational draft:
draft-ietf-ediint-as3 (ref. 'AS3')
** Downref: Normative reference to an Informational RFC: RFC 6017 (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: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 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 Intended status: Informational D. Moberg
5 Axway, Inc.
6 Expires: December 18, 2011 June 16, 2011
8 Certificate Exchange Messaging for EDIINT
9 draft-meadors-certificate-exchange-13.txt
10 Abstract
12 The EDIINT AS1, AS2 and AS3 message formats do not currently contain
13 any neutral provisions for transporting and exchanging trading
14 partner profiles or digital certificates. EDIINT Certificate Exchange
15 Messaging provides the format and means to effectively exchange
16 certificates for use within trading partner relationships. The
17 messaging consists of two types of messages, Request and Response,
18 which allow trading partners to communicate certificates, their
19 intended usage and their acceptance through XML. Certificates can be
20 specified for use in digital signatures, data encryption or SSL/TLS
21 over HTTP (HTTPS).
23 Status of this Memo
25 This Internet-Draft is submitted to IETF in full conformance with
26 the provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on December 18, 2011.
40 Copyright Notice
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 This document may contain material from IETF Documents or IETF
56 Contributions published or made publicly available before November
57 10, 2008. The person(s) controlling the copyright in some of this
58 material may not have granted the IETF Trust the right to allow
59 modifications of such material outside the IETF Standards Process.
60 Without obtaining an adequate license from the person(s) controlling
61 the copyright in such materials, this document may not be modified
62 outside the IETF Standards Process, and derivative works of it may
63 not be created outside the IETF Standards Process, except to format
64 it for publication as an RFC or to translate it into languages other
65 than English.
67 Conventions used in this document
69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
71 document are to be interpreted as described in RFC-2119.
73 Table of Contents
75 1. Introduction...................................................3
76 1.1 Overview...................................................3
77 1.2 Terminology and Key Word Convention........................4
78 1.3 Certificate Lifecycle......................................5
79 1.4 Certificate Exchange Process...............................6
80 2. Message Processing.............................................7
81 2.1 Message Structure..........................................7
82 2.2 EDIINT Features Header.....................................9
83 2.3 Certificate Exchanging.....................................9
84 2.4 Certificate Implementation................................10
85 2.5 CEM Response..............................................12
86 3. CEM XML Schema Description....................................13
87 3.1 EDIINTCertificateExchangeRequest element..................13
88 3.2 EDIINTCertificateExchangeResponse element.................17
89 4. Use Case Scenario.............................................18
90 5. Profile Exchange Messaging....................................20
91 6. Implementation Considerations.................................21
92 7. Future Considerations for CEM I-D.............................21
93 8. Security Considerations.......................................21
94 9. IANA Considerations...........................................22
95 10. References...................................................22
96 10.1 Normative References.....................................22
97 10.2 Informative References...................................23
98 11. Acknowledgments..............................................23
99 Author's Addresses...............................................23
100 Appendix.........................................................24
101 A.1 EDIINT Certificate Exchange XML Schema....................24
102 A.2 Example of EDIINT Certificate Exchange Request XML........27
103 A.3 Example of EDIINT Certificate Exchange Response XML.......28
104 Changes from Previous Versions...................................28
105 B.1 Updates from Version 00...................................28
106 B.2 Updates from Version 01...................................29
107 B.3 Updates from Version 02...................................29
108 B.4 Updates from Version 03...................................29
109 B.5 Updates from Version 04...................................29
110 B.6 Updates from Version 05...................................29
111 B.7 Updates from Version 06/07/08/09/10.......................29
113 1.
114 Introduction
116 1.1
117 Overview
119 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in
120 numerous supply-chains was due in part to the security feature which
121 was provided. The security is not possible without the digital
122 certificates which enable it. To maintain the level of security
123 necessary to transmit business documentation, existing certificates
124 must occasionally be replaced and exchanged with newer ones. The
125 exchanging of digital certificates is unavoidable given how
126 certificates can expire or become compromised. Complicating this is
127 supply-chains which cannot afford to shutdown their business
128 transactions while trading partners laboriously upload new
129 certificates. Certificate exchange must be accomplished in a reliable
130 and seamless format so as not to affect ongoing business
131 transactions.
133 This document describes how EDIINT products may exchange public-key
134 certificates. Since EDIINT is built upon the security provided by
135 public-private key pairs, it is vital that implementers are able to
136 update their trading partners with new certificates as their old
137 certificates expire, become outdated or insecure. Certificate
138 Exchange Messaging (CEM) described here utilizes XML data to exchange
139 the certificate and provide information on its intended usage and
140 acceptance within the trading partner relationship. There are two
141 types of CEM messages. The CEM Request which presents the new
142 certificate to be introduced into the trading partner relationship
143 and the CEM Response which is the recipient's response to the CEM
144 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or
145 AS3 [AS3] message transports. However, it is possible to leverage CE
146 messaging through other transport standards besides EDIINT.
148 1.2
149 Terminology and Key Word Convention
151 [RFC2828] provides a glossary of Internet security terms, and several
152 of their definitions are listed here verbatim. However, some
153 definitions required for this document were undefined by [RFC2828] or
154 rewritten to better explain their specific use within CEM.
156 Certificate - A digital certificate contains the owner's (End
157 Entity's) name, the issuer's name, a serial number, expiration date,
158 and a copy of the owner's Public Key. The Public Key is used for
159 Encrypting messages and Verifying Signatures (verifying a signature
160 is also called Authentication).
162 Certificate Revocation List (CRL) - A data structure that enumerates
163 digital certificates that have been invalidated by their issuer prior
164 to when they were scheduled to expire. [RFC2828]
166 Certification Authority (CA) - An entity that issues digital
167 certificates (especially X.509 certificates) and vouches for the
168 binding between the data items in a certificate. [RFC2828]
170 CA Certificate - A certificate issued by a trusted certification
171 authority. CA certificates are not used to encrypt data but to sign
172 other certificates. CA certificates are signed by themselves, but are
173 not considered self-signed certificates for the purpose of this
174 document.
176 Certification Hierarchy - In this structure, one CA is the top CA,
177 the highest level of the hierarchy. The top CA may issue public-key
178 certificates to one or more additional CAs that form the second
179 highest level. Each of these CAs may issue certificates to more CAs
180 at the third highest level, and so on. The CAs at the second-lowest
181 of the hierarchy issue certificates only to non-CA entities, called
182 "end entities" that form the lowest level. Thus, all certification
183 paths begin at the top CA and descend through zero or more levels of
184 other CAs. All certificate users base path validations on the top
185 CA's public key. [RFC2828]
187 CEM Request - The EDIINT Certificate Exchange Messaging (CEM) Request
188 is one of two possible CEM messages. It presents a certificate to be
189 introduced into the trading partner relationship along with relevant
190 information on how it is to be implemented.
192 CEM Response - The EDIINT Certificate Exchange Messaging (CEM)
193 Response is one of two possible CEM messages. It is the response to
194 the CEM Request indicating whether or not the end entity certificate
195 present in the CEM Request was accepted.
197 End Entity - A system entity that is the subject of a public-key
198 certificate and that is using, or is permitted and able to use, the
199 matching private key only for a purpose or purposes other than
200 signing a digital certificate; i.e., an entity that is not a CA.
201 [RFC2828]
203 End Entity Certificate - A certificate which is used to encrypt data
204 or authenticate a signature. (The private key associated with the
205 certificate is used to decrypt data or sign data). The certificate
206 may be self-signed or issued by a trusted certificate.
208 Intermediary Certificate - A certificate issued by a CA certificate
209 which itself issues another certificate (either intermediary or end
210 entity). Intermediary certificates are not used to encrypt data but
211 to sign other certificates.
213 Public Key - The publicly-disclosable component of a pair of
214 cryptographic keys used for asymmetric cryptography. [RFC2828]
216 Public Key Certificate - A digital certificate that binds a system
217 entity's identity to a public key value, and possibly to additional
218 data items. [RFC2828]
220 Self-signed Certificate - A certificate which is issued by itself
221 (both issuer and subject are the same) and is an End Entity
222 certificate.
224 1.3
225 Certificate Lifecycle
227 A certificate has five states.
229 1. Pending - Upon receiving a certificate from a trading partner, the
230 certificate is marked as Pending until a decision can be made to
231 trust it or if its validity period has not yet begun.
232 2. Rejected - If a Pending certificate is not trusted, it is
233 considered Rejected.
234 3. Accepted - Once a Pending certificate has been trusted, it is
235 considered Accepted. An Accepted certificate may be used in
236 secure transactions.
237 4. Expired - A certificate which is no longer valid because its
238 expiration date has passed. Expired certificates SHOULD be kept
239 in a certificate storehouse for decrypting and validating past
240 transactions.
241 5. Revoked - A certificate which has been explicitly revoked by its
242 owner or the certificate authority.
244 1.4
245 Certificate Exchange Process
247 This section describes a process whereby a company can distribute
248 certificates to its partners, and the company and its partners can
249 put the certificates into use. Later sections describe the specific
250 CEM protocol, which is an implementation of this process.
252 The exchange process can be used even when CEM is not useable, for
253 example, when the transport protocols or installed software systems
254 do not support CEM. It is RECOMMENDED that this process be followed
255 in distributing certificates.
257 The company that owns the certificates initiates the process. For a
258 certificate that is to be used (by the partners) to encrypt messages,
259 the initiator first prepares his system to decrypt messages that are
260 encrypted with this certificate. The initiator must also be able to
261 decrypt messages using the old certificate. The initiator company
262 distributes the new certificates by some means. The distribution MUST
263 describe the purposes of the certificates and MAY contain a respond
264 by date, the date when the distributor expects to put the
265 certificates in use. The respond by date SHOULD be present for
266 certificates that are used to sign messages or to authenticate
267 TLS/SSL connections.
269 When a partner receives a certificate, the partner should
270 authenticate the distribution message by some means. (CEM provides
271 for automatic authentication. Partners can use manual methods,
272 either with or without CEM.)
274 When a partner receives a certificate for use in encrypting messages
275 and has authenticated the certificate, the partner SHOULD begin
276 using that certificate to encrypt messages. The initiator MUST be
277 prepared to receive messages encrypted with either the old or new
278 certificate.
280 When a partner receives a certificate for use in digitally signing
281 messages or for TLS/SSL authentication and has authenticated the
282 certificate, the partner MUST prepare his system to accept messages
283 that are signed or authenticated with the new certificate. The
284 partner MUST also accept messages signed or authenticated with the
285 old certificate.
287 The partner MAY return a response to the initiator, indicating that
288 the partner has accepted the new certificate and put it in use. The
289 initiator can use these responses to track which partners are ready
290 to use the new certificate.
292 When the partner has sent a response indicating acceptance of the new
293 certificate, or when the respond by date has passed, the initiator
294 can begin using the new certificate to digitally sign messages or
295 authenticate TLS/SSL messages. The initiator MUST NOT sign or
296 authenticate messages with the new certificate until the partner has
297 accepted it or until the respond by date has passed. The initiator
298 MAY wait until the respond by date or until all partners have
299 accepted. The partners MUST accept messages signed or authenticated
300 with either the old or new certificate.
302 When the process is fully automated, it is not necessary to have a
303 specific time when both the initiator and partners switch to the new
304 certificate.
306 The initiator MUST be able to decrypt messages with both the old and
307 new certificates as soon as the new certificates are distributed.
308 The partners MUST be able to accept messages signed or TLS/SSL
309 authenticated with either the old or new certificates after they have
310 accepted the new certificate. The initiator SHOULD allow a
311 reasonable time after distributing a new signing or authenticating
312 certificate before putting it in use, so that partners have time to
313 authenticate the new certificate and prepare their systems for it.
315 For a certificate used to digitally sign messages or authenticate
316 TLS/SSL messages, there must be some way for the initiator to know
317 when partners are ready to receive the certificate. For example, this
318 may be a response from the partners, an explicit respond by date in
319 the initial distribution, an implied respond by date based on partner
320 agreements, or the expiration date of the old certificate. For a
321 certificate used to encrypt messages, the respond by date and
322 responses are less important, but responses may be useful to track
323 partners' acceptances.
325 2.
326 Message Processing
328 2.1
329 Message Structure
331 CEM messages use the underlying EDIINT transport, such as AS2, to
332 communicate information on the certificate, its intended use and its
333 acceptance. Both digital certificates and the XML data describing
334 their intended use are stored within a multipart/related MIME
335 envelope [RFC2387]. For the CEM Request message, the certificates are
336 stored in certificate chains through SMIME, certs-only MIME envelope
337 [3851], and processing information is XML data which is identified
338 through the MIME content-type of application/ediint-cert-
339 exchange+xml. The format for a CEM Request message is as follows:
341 Various EDIINT headers
342 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company
343 Content-Type: multipart/signed; micalg=sha1;
344 protocol="application/pkcs7-signature";
345 boundary="--OUTER-BOUNDARY"
347 ----OUTER-BOUNDARY
348 Content-Type: multipart/related; type="application/ediint-cert-
349 exchange+xml"; boundary="--INNER-BOUNDARY"
351 ----INNER-BOUNDARY
352 Content-Type: application/ediint-cert-exchange+xml
353 Content-ID: <20040101-1.alpha@example.org>
355 [CEM XML data]
356 ----INNER-BOUNDARY
357 Content-Type: application/pkcs7-mime; smime-type=certs-only
358 Content-ID: <20040101-2.alpha@example.org>
360 [digital certificate]
361 ----INNER-BOUNDARY--
363 ----OUTER-BOUNDARY
364 Content-Type: application/pkcs7-signature
366 [Digital Signature]
367 ----OUTER-BOUNDARY--
369 One and only one MIME type of application/ediint-cert-exchange+xml
370 MUST be present in the multipart/related structure, and it MUST be
371 the root element. Multiple certs-only media types may be included,
372 but at least one MUST be present. A unique content-id header MUST be
373 present within each of the multipart structures.
375 For the CEM Response message, a multipart/related MIME structure is
376 also used. However, no certificates are present in a CEM Response,
377 and the multipart/related structure only contains one MIME type of
378 application/ediint-cert-exchange+xml. The format for a CEM Request
379 message is as follows:
381 Various EDIINT headers
382 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company
383 Content-Type: multipart/signed; micalg=sha1;
384 protocol="application/pkcs7-signature";
385 boundary="--OUTER-BOUNDARY"
387 ----OUTER-BOUNDARY
388 Content-Type: multipart/related; type="application/ediint-cert-
389 exchange+xml"; boundary="--INNER-BOUNDARY"
391 ----INNER-BOUNDARY
392 Content-Type: application/ediint-cert-exchange+xml
393 Content-ID: <20040201-1.alpha@example.org>
395 [CEM XML data]
396 ----INNER-BOUNDARY--
398 ----OUTER-BOUNDARY
399 Content-Type: application/pkcs7-signature
401 [Digital Signature]
402 ----OUTER-BOUNDARY--
403 If possible, both the CEM Request and CEM Response message SHOULD be
404 signed. Applying digital signatures will allow for automatic exchange
405 based on a previous trust relationship. However, it may not be
406 possible in the initial exchange of a new trading partner. If a CEM
407 message is signed, the signing certificate MUST be included in the
408 digital signature. Extra security such as applying data encryption or
409 compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and
410 SHOULD request a signed MDN. The MDN can be either synchronous or
411 asynchronous. All necessary headers MUST be applied to the message
412 per the underlying transport standard.
414 2.2
415 EDIINT Features Header
417 To indicate support for CEM, an EDIINT application MUST use the
418 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates
419 the instance application can support various features, such as
420 certification exchange. The header is present in all messages from
421 the instance application, not just those which feature certification
422 exchange.
424 For applications implementing certification exchange, the CEM-
425 Feature-Name MUST be used within the EDIINT Features header:
427 CEM-Feature-Name = "CEM"
429 An example of the EDIINT Features header in a CEM Message:
431 EDIINT-Features: CEM
433 2.3
434 Certificate Exchanging
436 After obtaining the desired certificate, the initiator of the
437 certificate exchange transmits the end-entity certificate in the CEM
438 Request message. If the end-entity certificate is not self-signed,
439 then the CA certificate and any other certificates needed to create
440 the chain of trust for the end-entity certificate MUST be included in
441 the CEM Request message. Multiple end-entity certificates MAY also be
442 present.
444 The entire certificate trust chain is stored in a BER encoded P7C
445 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs-
446 only MIME envelope which is then stored in a single part of the
447 multipart/related structure. Each P7C trust chain MUST include a
448 single end-entity certificate and its trust authorities. No other
449 certificates are to be part of this chain. The number of P7C trust
450 chains in a CEM Request message MUST be equal to the number of end-
451 entity certificates being communicated in the CEM XML document.
452 If different end-entity certificates have common trust authorities'
453 certificates, each P7C cert chain still MUST include each certificate
454 necessary to create a trust anchor. Thus, if a recipient can not
455 create a trust relationship from the P7C cert chain, it MAY reject
456 the end-entity certificate in the CEM Request.
458 End-entity certificates are referenced and identified in the XML data
459 by their content-id used in the multipart/related structure.
460 Information on how the certificate is to be used, or certificate
461 usage, by the receiving user agent and other related information is
462 found in the XML data. A certificate can be used for a single
463 function, like digital signatures, or used for multiple functions,
464 such as both digital signatures and data encryption. If a certificate
465 is intended for multiple usages, such as for both digital signatures
466 and data encryption, the certificate MUST be listed only once in the
467 CEM Request message and its multiple usage listed through the
468 CertUsage XML element.
470 Upon receipt of the CEM Request, the recipient trading partner
471 processes the transport message as normal and returns the MDN. The
472 recipient MAY parse the CEM XML data prior to returning the MDN. If
473 the XML is not well-formed and can not be interpreted, the UA MAY
474 return the MDN with the error disposition modifier of "error:
475 unexpected-processing-error". The returned MDN does not provide
476 information on the acceptance of the certificate(s) being exchanged.
477 An UA who receives an MDN with an error disposition modifier MUST
478 consider the CEM Message was not understood and needs to be corrected
479 and retransmitted.
481 2.4
482 Certificate Implementation
484 The new certificate is considered to be in the Pending state for the
485 recipient who MUST decide whether to accept the certificate as
486 trustworthy. This decision is arbitrary and left to each individual
487 trading partner. Upon accepting the certificate, it is to be
488 considered an Accepted certificate within the trading partner
489 relationship. If the certificate is not accepted, it is considered
490 Rejected.
492 When a certificate is intended for use in data encryption, the
493 initiator MUST consider the certificate to be Accepted and be
494 prepared for its trading partner to begin using the certificate upon
495 generating the CEM Request message. After a recipient generates a
496 positive CEM Response message for a certificate, the recipient MUST
497 immediately begin using the certificate in trading with the initiator
498 of the request. The recipient MAY apply encryption to the CEM
499 Response message using the new Accepted certificate or MAY apply
500 encryption to the CEM Response message using the previously Accepted
501 encryption certificate.
503 When a certificate is intended for use in digital signatures or
504 TLS/SSL authentication, the initiator MUST NOT use the certificate
505 until the recipient trading partner generates a CEM Response
506 accepting the certificate or the respond by date, which is listed in
507 the RespondByDate XML element. The initiator MAY use the certificate
508 after the respond by date, regardless of whether the partner has
509 accepted it or not. The certificate used for the digital signature of
510 the CEM Request message MUST be the one which is currently Accepted
511 within the trading partner relationship.
513 Since implementers of EDIINT often use the same certificate with
514 multiple trading partners, implementers of CEM MUST be able to keep
515 both the old and new certificates as Accepted. If the initiator has
516 generated a CEM Request and exchanged a new encryption certificate to
517 multiple trading partners, it MUST be able to accept encrypted data
518 which uses either the older, existing encryption certificate or the
519 newly exchanged encryption certificate. Likewise, a recipient of a
520 CEM Request MUST be able to authenticate digital signatures using
521 either the new or old certificates, since the initiator may not be
522 able to switch certificates until all trading partners accept the new
523 certificate. Similar provisions MUST be made for certificates
524 intended for TLS/SSL server and client authentication. Revoking a
525 certificate MUST be done outside of CEM.
527 If a CEM Request message contains a certificate which is currently
528 Accepted and has the identical usage for the certificate that has
529 been Accepted, the recipient MUST NOT reject the duplicate
530 certificate but MUST respond with a CEM Response message indicating
531 the certificate has been accepted. For example, if Certificate A is
532 currently Accepted as the encryption certificate for a user agent,
534 any CEM Request message containing Certificate A with the usage as
535 encryption only MUST be accepted by an existing trading partner. This
536 situation may be necessary for an implementation intending to verify
537 its current trading partner certificate.
539 If two trading partners utilize multiple EDIINT protocols for
540 trading, such as AS2 for a primary transport and AS1 as the backup
541 transport, it is dependent upon implementation and trading partner
542 agreement how CEM messages are sent and which transports the
543 exchanged certificates affect.
545 2.5
546 CEM Response
548 The CEM Response message is a multipart/related envelope which
549 contains the CEM XML under the MIME type of application/ediint-cert-
550 exchange+xml. If a requestId is used in a CEM Request, then the
551 requestId MUST be present in the CEM Response with the same value.
552 The requestId allows for the CEM Response to be matched to the CEM
553 Request. If the CEM Request contains multiple TrustRequest elements
554 and the corresponding TrustResponse elements are returned in multiple
555 CEM Response messages, each CEM Response message MUST use the same
556 requestId from the originating CEM Request message. This is critical
557 when multiple CEM Requests are sent with the same certificate and the
558 CEM Response can not be matched solely through the TrustResponse
559 elements.
561 A TrustResponse XML element provides information needed to match the
562 end-entity certificate sent in an earlier CEM Request and indicate if
563 the certificate was accepted or rejected by the recipient. The
564 CertificateReference in a TrustResponse matches the
565 CertificateIdentifier value for the end-entity certificate in the CEM
566 Request. CertStatus indicates if the certificate was accepted or
567 rejected. If a CEM Request is received, the recipient MUST respond
568 with a CEM Response message indicating if the certificate is Accepted
569 or Rejected. More information about the XML attributes and value for
570 CEM Response can be found in 3.2.
572 If the certificate in the CEM Request message contains multiple
573 usages, such as for both digital signature and data encryption, only
574 a single TrustResponse is needed for that certificate. The CertStatus
575 value in the TrustResponse is the response for both usages of the
576 certificate. A recipient MUST NOT choose to accept the certificate
577 for one specified use and not the other.
579 If multiple end-entity certificates were included within the CEM
580 Request, the recipient MAY generate individual CEM Response messages
581 for each certificate or the recipient MAY consolidate the
582 TrustResponse for multiple certificates into one CEM Response
583 message. A CEM Response may contain multiple TrustResponse elements
584 for different certificates but MUST NOT contain two or more
585 TrustResponses for the same certificate.
587 If a second TrustResponse is received in a different message matching
588 the same certificate as that of an earlier TrustRespnse but the
589 CertStatus has a different value than the other, the originator MAY
590 accept the CertStatus value in the most recent TrustResponse but MAY
591 choose to ignore it. If the CertStatus in both TrustResponses are the
592 same, the originator should disregard the second TrustResponse.
594 If the originator receives a CEM Response message which violates the
595 rules listed above or is invalid in any way, the originator MAY
596 reject the message entirely but MUST return an MDN if requested.
598 3.
599 CEM XML Schema Description
601 The CEM schema has two top-level elements,
602 EDIINTCertificateExchangeRequest and
603 EDIINTCertificateExchangeResponse. The
604 EDIINTCertificateExchangeRequest element is present only in the CEM
605 Request message, and the EDIINTCertificateExchangeResponse is present
606 only in the CEM Response message. All other elements nest directly or
607 indirectly from these. CEM XML data must be well-formed and valid
608 relative to the CEM XML Schema. Please refer to the appendix for the
609 actual schema document.
611 3.1
612 EDIINTCertificateExchangeRequest element
614 EDIINTCertificateExchangeRequest contains element TradingPartnerInfo,
615 which can only appear once, and TrustRequest, which may be present
616 multiple times. TrustRequest contains information on a certificate
617 and its intended usage. TradingPartnerInfo exists to provide
618 information on the publication of the CEM Request message since
619 processing of the XML data may occur apart from the handling of the
620 accompanying transport message, for example the AS2 request.
622
623
624
625
626
629
631
632
634
635
636
638 EDIINTCertificateExchangeRequest also contains the attribute
639 requestId. RequestId uniquely identifies each CEM Request message.
641 Its value MUST be between 1 and 255 characters. The requestId is
642 returned in the CEM Response message to assist the UA in matching the
643 CEM Response with the CEM Request.
645
646
647
648
649
650
652 An optional Extension element is also present along with the
653 anyAttribute attribute. They exist to provide future extendibility
654 for new features which may be developed but not yet defined within
655 CEM. They are present in several locations in the schema for this
656 future extendibility.
658
659
660
661
663
664
665
667 TradingPartnerInfo identifies the entity that created the CEM message
668 through the nested Name element. Both the qualifier attribute and the
669 element value of Name follow mandatory naming conventions. The
670 qualifier attribute is to be the transport standard utilized. For
671 example, "AS1", "AS2" or "AS3". The value of the Name element is the
672 same value in the From header utilized by the transport. For AS2 and
673 AS3, this is the value in the AS2-From and AS3-From headers,
674 respectively. For AS1, this is the value of the From header. If other
675 transports besides AS1, AS2, AS3 are used, the same naming convention
676 SHOULD be followed.
678 MessageOriginated is included in TradingPartnerInfo to identify the
679 time and date the message was created. The MessageOriginated date and
680 time values MUST follow XML standard dateTime type syntax and be
681 listed to at least the nearest second and expressed in local time
682 with UTC offset. For example, a message originating from the US
683 Eastern Standard timezone would use 2005-03-01T14:05:00-05:00.
685
686
687
688
689
690
691
692
694
695
696
697
698
699
701
702
703
704
706 The TrustRequest element contains the EndEntity, CertUsage,
707 RespondByDate and ResponseURL elements. The required EndEntity
708 element is found only once in a TrustRequest element and contains the
709 content-id reference to the end-entity certificate being exchanged.
711
712
713
714
715
716
717
719
720
721
723 EndEntity contains the nested elements of CertificateIdentifier and
724 CertificateContentID. CertificateContentID is a string element which
725 references the content-id of the multipart/related structure where
726 the certificate is stored. CertificateIdentifier comes from the XML
727 Signature schema namespace [XML-DSIG].
729
730
731
734
735
737
738
739
741 CertificateIdentifier contains the string element X509IssuerName and
742 the integer element X509SerialNumber. X509SerialNumber is the
743 assigned serial number of the end entity certificate as it is listed.
744 X509IssuerName contains the issuer name information of the end-entity
745 certificate, such as common name, organization, etc. This information
746 MUST be described in a string format per the rules of RFC 2253
747 [RFC2253]. This results in the attributes within the Issuer Name to
748 be listed with their attribute type followed by an "=" and the
749 attribute value. Each attribute type and value are separated by a ","
750 and any escape characters in the value are preceded by a "\". Refer
751 to the appendix and the sample CEM Request message for an example of
752 the X509IssuerName.
754
755
756
757
758
759
761 CertUsage is an unbounded element which contains enumerated values on
762 how the exchanged certificate is to be used. There are enumerated
763 values for SMIME digital signatures (digitalSignature), SMIME data
764 encryption (keyEncipherment), the server certificate used in TLS
765 transport encryption (tlsServer) and the client certificate used in
766 TLS transport encryption (tlsClient). While the element is unbounded,
767 CertUsage only has a potential number of four occurrences due to the
768 limit of the enumerated values.
770
771
772
773
774
775
776
777
778
780 RespondByDate is a required element of the XML standard dateTime type
781 expressed in local time with UTC offset, which provides information
782 on when the certificate should be trusted, inserted into the trading
783 partner relationship and responded to by a CEM Response message. If
784 the certificate can not be trusted or inserted into the trading
785 partner relationship, the CEM Response message should still be
786 returned by the date indicated.
788
790 ResponseURL is an element which indicates where the CEM Response
791 message should be sent. This value takes precedence over the existing
792 inbound URL of the current trading partner relationship. The Response
793 MUST use the same transport protocol (AS1, AS2, or AS3) as the
794 Request.
795
797 3.2
798 EDIINTCertificateExchangeResponse element
800 EDIINTCertificateExchangeResponse contains the two elements
801 TradingPartnerInfo and TrustResponse and the attribute requestId.
802 TradingPartnerInfo, which is also found in
803 EDIINTCertificateExchangeRequest, describes the trading partner
804 generating this response message. TrustResponse provides information
805 on the acceptance of a previously sent end entity certificate. There
806 can be multiple TrustResponse elements within an
807 EDIINTCertificateExchangeResponse. The requestId is the same value
808 from a previously sent CEM Request message. The requestId from the
809 CEM Response is matched up with the CEM Request.
811
812
813
814
815
818
820
821
823
824
825
827
828
829
830
831
833
835
836
837
839 A TrustResponse element identifies a certificate which has been
840 previously exchanged within the trading partner relationship through
841 a CEM Request and now has been either accepted or rejected by the
842 partner. The CertificateReference element is of the same type as the
843 CertificateIdentifier element. A CertificateReference element in a
844 CEM Response MUST be identical to its CertificateIdentifier
845 counterpart in the associated CEM Request since they identify the
846 same certificate in question.
848 The required element CertStatus has the enumerated values of
849 "Accepted" or "Rejected". "Accepted" indicates the certificate was
850 trusted by the trading partner and is now ready for use within the
851 trading partner relationship, and "Rejected" indicates the
852 certificate is not trusted by the trading partner nor can it be
853 currently used with the trading partner relationship. If the value of
854 "Rejected" is chosen, the optional string element ReasonForRejection
855 may be included. If present, ReasonForRejection should contain a
856 brief description of why the certificate was not accepted. Since the
857 value for this element is not enumerated but open, it MUST be
858 interpreted through human means.
860
861
862
863
864
865
866
867
869 4.
870 Use Case Scenario
872 This scenario illustrates how the CEM Request and CEM Response
873 messages described in Section 2 and 3 can be used to exchange
874 certificates. The scenario is only illustrative and any differences
875 between it and the rules above should defer to the rules in Section 2
876 and 3.
878 Two trading partners, Alpha Arrows and Bravo Bows, have an
879 established trading partner relationship using AS2. Alpha Arrows is
880 using a single certificate, CertA, for both digital signatures and
881 data encryption. Alpha Arrows wants to issue a new certificate,
882 CertB, for digital signatures but keep CertA for data encryption.
884 Bravo Bows is using one certificate, Cert1, for digital signatures
885 and another certificate, Cert2, for data encryption. Bravo Bows wants
886 to introduce a new certificate, Cert3, for digital signature and a
887 new certificate, Cert4, for data encryption.
889 1. Alpha Arrows sends a CEM Request to Bravo Bows containing only
890 CertB. The CertUsage has a value of "digitalSignature". Bravo Bows
891 immediately returns the MDN but must make an internal security
892 decision before accepting CertB.
894 2. While waiting for a CEM Response, Alpha Arrows continues to send
895 AS2 messages to Bravo Bows which have been signed using CertA. The
896 messages originating from Bravo Bows are encrypted using CertA.
898 3. Eventually, Bravo Bows returns a CEM Response with the CertStatus
899 of "Accepted" for CertB. Upon receipt, an MDN is returned which is
900 signed using CertA. Bravo Bows MUST be able to accept the MDN if it
901 has a digital signature from either CertA or CertB as Alpha Arrows
902 may not be able to switch certificates simply upon receipt of the CEM
903 Response message without parsing the XML payload. Also, Alpha Arrows
904 may need to wait for CEM Responses from other trading partners before
905 switching to the new CertB. However, as soon as possible, Alpha
906 Arrows should use CertB exclusively for digital signatures.
908 4. Bravo Bows sends a CEM Request to Alpha Arrows containing both
909 Cert3 and Cert4. The CertUsage for Cert3 and Cert4 are
910 "digitalSignature" and "keyEncipherment", respectively. Alpha Arrows
911 returns an MDN immediately. Bravo Bows is now prepared to receive any
912 inbound messages encrypted by either Cert2 or Cert4, but all its
913 digital signatures are still done through Cert1.
915 5. Eventually, Alpha Arrows returns a single CEM Response message. It
916 contains two TrustResponse elements: one for Cert3 and another for
917 Cert4. The CertStatus for Cert3 is "Rejected" with the
918 ReasonForRejection field present and populated with the string
919 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted."
920 Bravo Bows returns the MDN signed through Cert1.
922 6. Immediately after this, an AS2 message is received from Alpha
923 Arrows which is encrypted using Cert4, and Bravo Bows is able to
924 decrypt the message successfully. Because Alpha Arrows rejected
925 Cert3, Bravo Bows is only using Cert1 for digital signatures and
926 returns the MDN signed with Cert1.
928 7. After creating a new certificate, Cert5, which corrects the
929 previous keyUsage problem, Bravo Bows sends Cert5 in a CEM Request.
931 8. Shortly after this, Alpha Arrows sends a CEM Response message for
932 Cert5. It contains a CertStatus of "Accepted". This CEM Response
933 message was encrypted using Cert4, but Bravo Bows was prepared for
934 encryption from either Cert2 or Cert4. The message is processed and a
935 good MDN is returned signed with Cert1. While, Bravo Bows can now
936 sign messages to Alpha Arrows with either Cert1 or Cert5, Bravo Bows
937 should use Cert5 exclusively as soon as possible.
939 5.
940 Profile Exchange Messaging
942 CEM provides the means to exchange certificates among trading
943 partners. However, other profile information, such as URLs and
944 preferred security settings, is needed to create a trading partner
945 relationship. A future standard is needed to describe profile
946 descriptions and how they will be exchanged. The format for this
947 profile attachment is not defined in this specification but is
948 planned for a future document. It will build upon the existing CEM
949 protocol with profile information stored with XML data. Both
950 certificate and profile description information will be placed into a
951 multipart/related [RFC2387] body part entity. A possible format for a
952 profile description message is as follows:
954 Various EDIINT headers
955 EDIINT-Features: profile-exchange
956 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company
957 Disposition-Notification-Options: signed-receipt-protocol=optional,
958 pkcs7-signature; signed-receipt-micalg=optional, sha1
959 Content-Type: multipart/signed; micalg=sha1;
960 protocol="application/pkcs7-signature"; boundary="--BOUNDARY1"
962 ----BOUNDARY1
963 Content-Type: multipart/related;
964 start="";
965 type="application/ediint-cert-exchange+xml";
966 boundary="--BOUNDARY2"
968 ----BOUNDARY2
969 Content-Type: application/ediint-cert-exchange+xml
970 Content-ID:
972 [CEM XML data]
973 ----BOUNDARY2
974 [Profile information attachment]
975 ----BOUNDARY2--
976 ----BOUNDARY1
978 Content-Type: application/pkcs7-signature
980 [Digital Signature]
981 ----BOUNDARY1--
983 6.
984 Implementation Considerations
986 This section contains various points to explain practical
987 implementation considerations.
989 * If the EDIINT transport message carrying a CEM Request or CEM
990 Response fails resulting in a negative MDN, the CEM message, its
991 contents and instructions are to be ignored. The User Agent receiving
992 the negative MDN is to consider the CEM message to be ignored and
993 retransmit as needed.
995 * While a single end-entity certificate can be only be used once in a
996 single CEM Request message, the same certificate can be sent multiple
997 times in multiple CEM Request messages. The requestId is used for
998 matching the CEM Request and CEM Response messages.
1000 * Certificate usage is cumulative. Thus, if a User Agent receives a
1001 valid CEM Request message with Certificate A with certUsage set to
1002 digitalSignature and then a second valid CEM Request message with
1003 Certificate A with certUsage set to keyEncipherment, then the User
1004 Agent MUST configure the certificate to be used both for
1005 digitalSignature and keyEncipherment. As well, if at a later time a
1006 valid CEM Request message is received with Certificate A with
1007 certUsage set only to digitalSignature, Certificate A is still valid
1008 for keyEncipherment.
1010 7.
1011 Future Considerations for CEM I-D
1012 This section contains ideas for consideration in future versions of
1013 CEM and addressed in the future. If deemed necessary, they will be
1014 added into the I-D else they will be removed. This section will be
1015 removed prior to RFC submission.
1017 8.
1018 Security Considerations
1020 Certificate exchange is safe for transmitting. However, implementers
1021 SHOULD verify the received certificate to determine if it is truly
1022 from the stated originator through out-of-band means or whenever the
1023 request is not signed.
1025 9.
1026 IANA Considerations
1028 MIME Media type name: Application
1030 MIME subtype name: EDIINT-cert-exchange+xml
1032 Required parameters: None
1034 Optional parameters: This parameter has identical semantics to the
1035 charset parameter of the "application/xml" media type as specified
1036 in [RFC3023].
1038 Encoding considerations: Identical to those of "application/xml" as
1039 described in [RFC3023], section 3.2.
1041 Security considerations: See section 6.
1043 Interoperability Considerations: See section 2.2
1045 Published specification: This document.
1047 Applications which use this media type: EDIINT applications, such as
1048 AS1, AS2 and AS3 implementations.
1050 Additional Information: None
1052 Intended Usage: Common
1054 Author/Change controller: See Author's section of this document.
1056 10.
1057 References
1058 10.1
1059 Normative References
1061 [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data
1062 Interchange over the Internet using SMTP", T. Harding, R.
1063 Drummond, C. Shih, 2002.
1065 [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data
1066 Interchange over the Internet using HTTP", D. Moberg, R.
1067 Drummond, 2005.
1069 [AS3] draft-ietf-ediint-as3-05.txt "MIME-based Secure Peer-to-Peer
1070 Business Data Interchange over the Internet using FTP", T.
1071 Harding, R. Scott, 2003.
1073 [EDIINT FEATURE] Meadors, K., "Electronic Data Interchange - Internet
1074 Integration (EDIINT) Features Header Field", RFC 6017, September 2010.
1076 [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement
1077 Levels", S.Bradner, March 1997.
1079 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,
1080 October 1999.
1082 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8
1083 String Representation of Distinguished Names", M. Wahl, S. Kille
1084 and T. Howes, Decemeber 1997.
1086 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.
1087 Levinson, August 1998.
1089 [RFC2828] RFC2828 "Internet Security Glossary", R. Shirley, May 2000.
1091 [RFC3023] RFC3023 "XML Media Types", M. Murata, October 2001.
1093 [XML-DSIG] RFC3275 "XML-Signature Syntax and Processing", D.
1094 Eastlake, March 2002.
1096 [X.520] ITU-T Recommendation X.520: Information Technology - Open
1097 Systems Interconnection - The Directory: Selected Attribute
1098 Types, 1993.
1100 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1101 X.509 Public Key Infrastructure: Certificate and CRL Profile",
1102 RFC 3280, April 2002.
1104 10.2
1105 Informative References
1107 11.
1108 Acknowledgments
1110 The authors wish to extend gratitude to the ecGIF sub-committee
1111 within the GS1 organization from which this effort began. Many have
1112 contributed to the development of this specification, but some
1113 deserve special recognition. John Duker who chaired the sub-committee
1114 and provided valuable editing. John Koehring with his work on the
1115 reference ID and shared important insights on implementation. Aaron
1116 Gomez in the coordinating of vendors testing CEM. Richard Bigelow who
1117 greatly assisted development of the ideas presented, and Debra Petta
1118 for her review and comments.
1120 Author's Addresses
1122 Kyle Meadors
1123 Drummond Group Inc.
1124 4700 Bryant Irvin Court, Suite 303
1125 Fort Worth, TX 76107 USA
1126 Email: kyle@drummondgroup.com
1128 Dale Moberg
1129 Axway, Inc.
1130 8388 E. Hartford Drive, Suite 100
1131 Scottsdale, AZ 85255 USA
1132 Email: dmoberg@us.axway.com
1134 Appendix
1136 A.1 EDIINT Certificate Exchange XML Schema
1138
1139
1145
1147
1148
1149
1150
1151
1153
1155
1156
1158
1159
1160
1161
1162
1163
1164
1165
1167
1169
1170
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1184
1185
1186
1187
1188
1189
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1224
1225
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1238
1239
1240
1241
1242
1243
1244
1245
1247
1249
1250
1251
1252
1253
1254
1255
1257
1258
1259
1260
1262 A.2 Example of EDIINT Certificate Exchange Request XML
1264
1265
1270
1271 DGI_Test_CEM
1272
1273 2005-08-30T00:30:00-05:00
1274
1275
1276 keyEncipherment
1277 digitalSignature
1278 2005-09-30T12:00:00-05:00
1279 http://10.1.1.1/as2
1280
1281
1282 CN=Cleo-
1283 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft.
1284 Worth,S=Texas,C=US
1285 9659684611094873474886
1286
1287
1288 SignEncCert-Example_vs02@example.org
1289
1290
1291
1292 tlsServer
1293 2005-09-30T12:00:00-05:00
1294 http://10.1.1.1/as2
1295
1296
1297 CN=VeriSign Class 1 CA Individual
1298 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA
1299 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\,
1300 Inc.
1301 2673611014597817669550861744279966682
1303
1304
1305 SSLCert-Example_vs02@example.org
1306
1307
1308
1310 A.3 Example of EDIINT Certificate Exchange Response XML
1312
1313
1318
1319 DGI_Test_CEM_Trading_Partner
1320
1321 2005-08-31T00:21:00-05:00
1322
1323
1324 Accepted
1325
1326 CN=Cleo-
1327 SP,E=as2selfpacedsupport@drummondgroup.com,O=DGI,OU=DGI,L=Ft.
1328 Worth,S=Texas,C=US
1329 9659684611094873474886
1330
1331
1332
1333 Accepted
1334
1335 CN=VeriSign Class 1 CA Individual
1336 Subscriber-Persona Not Validated,OU=www.verisign.com/repository/RPA
1337 Incorp. By Ref.\,LIAB.LTD(c)98,OU=VeriSign Trust Network,O=VeriSign\,
1338 Inc.
1339 2673611014597817669550861744279966682
1341
1342
1343
1345 Changes from Previous Versions
1347 B.1 Updates from Version 00
1349 . Updated security requirements in section 2.1, specifically in
1350 regards to digital signatures.
1351 . The XML element responseURL is now required. Modified section
1352 3.1 and example messages in appendix accordingly.
1353 . Certificates are exchanged within a full P7C cert chain. Section
1354 2.3 reflects this.
1355 . The XML element TrustChain is not longer necessary since the
1356 entire cert chain is stored. Removed references in schema and
1357 document.
1358 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be
1359 sent and that if this occurs, the action of the CEM Request
1360 initiator is not defined.
1361 . Updated the examples in Appendix B to reflect the current usage.
1363 B.2 Updates from Version 01
1365 . Added information for handling different scenarios with CEM
1366 Response message.
1367 . Rewrote use case scenarios.
1368 . Added the EDIINT Features header information.
1370 B.3 Updates from Version 02
1371 . Modified use of SSL certificates to match real-world needs.
1372 . Modified schema in changing namespace value and removed schema
1373 location.
1374 . Added statement that CEM XML must be well-formed and valid to
1375 schema.
1376 . Modified Use Case to correct an error and improve clarity.
1377 . Added section 1.4 to describe CEM process.
1379 B.4 Updates from Version 03
1380 . None. Update done because vs03 expired.
1382 B.5 Updates from Version 04
1383 . Clarified requirement of using multipart/related for CEM
1384 Response.
1385 . Added sections on Implementation Considerations and Future
1386 Implementation.
1387 . Modified schema to allow future extensions.
1388 . Changed requirements on qualifier attribute in the Name
1389 element.
1390 . Changed functionality to allow error MDN to be returned when
1391 CEM XML can not be parsed.
1393 B.6 Updates from Version 05
1394 . Added requestId to CEM.
1395 . Removed normative reference to RFC 3821.
1397 B.7 Updates from Version 06/07/08/09/10/11/12
1398 . None. Updated for 6-month I-D expiration.