CEM Draft update
"Kyle Meadors" <[email protected]> Tue, 7 Mar 2006 14:10:26 -0600
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <00c701c64223$2f939ed0$7d01a8c0@KYLEDGILAPTOP> |
This is a multi-part message in MIME format.
------=_NextPart_000_00C8_01C641F0.E4F92ED0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_00C9_01C641F0.E4F92ED0"
------=_NextPart_001_00C9_01C641F0.E4F92ED0
Content-Type: text/plain;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
CEM Internet=96Draft has expired and can not be viewed until new version =
is
updated. However, IETF can not update until end of the month. I am =
posting
it here for temporary reference.
=20
Kyle Meadors
Principal, Test Process
Drummond Group Inc.
615.212.0826
=20
--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006
=20
=20
------=_NextPart_001_00C9_01C641F0.E4F92ED0
Content-Type: text/html;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1250">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CEM Internet–Draft has expired and can not be =
viewed
until new version is updated. However, IETF can not update until end of =
the
month. I am posting it here for temporary =
reference.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Kyle Meadors</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Principal, Test Process</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Drummond Group Inc.</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>615.212.0826</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
<BR>
<P><FONT SIZE=3D2>--<BR>
No virus found in this outgoing message.<BR>
Checked by AVG Free Edition.<BR>
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: =
3/6/2006<BR>
</FONT> </P>
<P><FONT SIZE=3D2 FACE=3D"Arial"> </FONT> </P>
------=_NextPart_001_00C9_01C641F0.E4F92ED0--
------=_NextPart_000_00C8_01C641F0.E4F92ED0
Content-Type: text/plain;
name="draft-meadors-certificate-exchange-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-meadors-certificate-exchange-03.txt"
Draft CEM for EDIINT March 2006=20
=20
=20
Private K. Meadors=20
Internet-Draft Drummond Group Inc.=20
Document: draft-meadors-certificate-exchange- D. Moberg=20
03.txt Cyclone Commerce=20
Expires: September 2006 March 2006=20
=20
=20
=20
Certificate Exchange Messaging for EDIINT=20
draft-meadors-certificate-exchange-03.doc=20
=20
By submitting this Internet-Draft, each author represents that any=20
applicable patent or other IPR claims of which he or she is aware=20
have been disclosed, or will be disclosed, and any of which he or she =
becomes aware will be disclosed, in accordance with Section 6 of BCP=20
79.=20
=20
Status of this Memo=20
=20
This document is an Internet-Draft and is in full conformance with=20
all provisions of Section 10 of RFC2026. =20
=20
Internet-Drafts are working documents of the Internet Engineering=20
Task Force (IETF), its areas, and its working groups. Note that =
other groups may also distribute working documents as Internet-
Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six months =
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as reference=20
material or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.html=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20
=20
Any questions, comments, and reports of defects or ambiguities in=20
this specification may be sent to the mailing list for the EDIINT=20
working group of the IETF, using the address <[email protected]>.=20
Requests to subscribe to the mailing list should be addressed to=20
<[email protected]>.=20
=20
=20
Abstract=20
=20
The EDIINT AS1, AS2 and AS3 message formats do not currently contain=20
any neutral provisions for transporting and exchanging trading=20
partner profiles or digital certificates. EDIINT Certificate Exchange =
=20
=20
Meadors, Moberg Expires - September 2006 [Page 1]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
Messaging provides the format and means to effectively exchange=20
certificates for use within trading partner relationships. The=20
messaging consists of two types of messages, Request and Response,=20
which allow trading partners to communicate certificates, their=20
intended usage and their acceptance through XML. Certificates can be=20
specified for use in digital signatures, data encryption or SSL/TLS=20
over HTTP (HTTPS). =20
=20
=20
Conventions used in this document=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =
document are to be interpreted as described in RFC-2119.=20
=20
Feedback Instructions=20
=20
NOTE TO RFC EDITOR: This section should be removed by the RFC editor =
prior to publication.=20
=20
If you want to provide feedback on this draft, follow these=20
guidelines:=20
=20
-Send feedback via e-mail to [email protected], with=20
"Certificate Exchange" in the Subject field.=20
=20
-Be specific as to what section you are referring to, preferably=20
quoting the portion that needs modification, after which you state=20
your comments.=20
=20
-If you are recommending some text to be replaced with your suggested =
text, again, quote the section to be replaced, and be clear on the=20
section in question.=20
=20
=20
Table of Contents=20
=20
1. Introduction...................................................3=20
1.1 Overview...................................................3=20
1.2 Terminology and Key Word Convention........................4=20
1.3 Certificate Lifecycle......................................5=20
2. Message Processing.............................................6=20
2.1 Message Structure..........................................6=20
2.2 EDIINT Features Header.....................................7=20
2.3 Certificate Exchanging.....................................7=20
2.4 Certificate Implementation.................................8=20
2.5 CEM Response...............................................9=20
3. XML Schema Description........................................10=20
3.1 EDIINTCertificateExchangeRequest element..................10=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 2]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
3.2 EDIINTCertificateExchangeResponse element.................13=20
4. Use Case Scenario.............................................14=20
5. Profile Exchange Messaging....................................16=20
6. Security Considerations.......................................16=20
7. IANA Considerations...........................................17=20
8. References....................................................17=20
8.1 Normative References......................................17=20
8.2 Informative References....................................18=20
9. Acknowledgments...............................................18=20
Author's Addresses...............................................18=20
Appendix.........................................................19=20
A.1 EDIINT Certificate Exchange XML Schema....................19=20
A.2 Example of EDIINT Certificate Exchange Request XML........21=20
A.3 Example of EDIINT Certificate Exchange Response XML.......22=20
Changes from Previous Versions...................................23=20
B.1 Updates from Version 00...................................23=20
B.2 Updates from Version 01...................................23=20
B.3 Updates from Version 02...................................23=20
=20
=20
1. =0D Introduction=20
=20
1.1 =0D Overview=20
=20
The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in=20
numerous supply-chains was due in part to the security feature which=20
was provided. The security is not possible without the digital=20
certificates which enable it. To maintain the level of security=20
necessary to transmit business documentation, existing certificates=20
must occasionally be replaced and exchanged with newer ones. The=20
exchanging of digital certificates is unavoidable given how=20
certificates can expire or become compromised. Complicating this is=20
supply-chains which cannot afford to shutdown their business=20
transactions while trading partners laboriously upload new=20
certificates. Certificate exchange must be accomplished in a reliable =
and seamless format so as not to affect ongoing business=20
transactions. =20
=20
This document describes how EDIINT products may exchange public-key=20
certificates. Since EDIINT is built upon the security provided by=20
public-private key pairs, it is vital that implementers are able to=20
update their trading partners with new certificates as their old=20
certificates expire, become outdated or insecure. EDIINT Certificate=20
Exchange Messaging (CEM) described here utilizes XML data to exchange =
the certificate and provide information on its intended usage and=20
acceptance within the trading partner relationship. There are two=20
types of CEM messages, the CEM Request which presents the new=20
certificate to be introduced into the trading partner relationship=20
and the CEM Response which is the recipient=92s response to the CEM=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 3]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or =
AS3 [AS3] message transports. However, it is possible to leverage CE=20
messaging through other transport standards besides EDIINT.=20
=20
1.2 =0D Terminology and Key Word Convention=20
=20
[RFC2818] provides a glossary of Internet security terms, and several =
of their definitions are listed here verbatim. However, some=20
definitions required for this document were undefined by [RFC2818] or =
rewritten to better explain their specific use within CEM. =20
=20
Certificate - A digital certificate contains the owner=92s (End=20
Entity=92s) name, the issuer=92s name, a serial number, expiration =
date,=20
and a copy of the owner=92s Public Key. The Public Key is used for=20
Encrypting messages and Verifying Signatures (verifying a signature=20
is also called Authentication). =20
=20
Certificate Revocation List (CRL) - A data structure that enumerates=20
digital certificates that have been invalidated by their issuer prior =
to when they were scheduled to expire. [RFC2828]=20
=20
Certification Authority (CA) - An entity that issues digital=20
certificates (especially X.509 certificates) and vouches for the=20
binding between the data items in a certificate. [RFC2828]=20
=20
CA Certificate - A certificate issued by a trusted certification=20
authority. CA certificates are not used to encrypt data but to sign=20
other certificates. CA certificates are signed by themselves, but are =
not considered self-signed certificates for the purpose of this=20
document.=20
=20
Certification Hierarchy - In this structure, one CA is the top CA,=20
the highest level of the hierarchy. The top CA may issue public-key=20
certificates to one or more additional CAs that form the second=20
highest level. Each of these CAs may issue certificates to more CAs=20
at the third highest level, and so on. The CAs at the second-lowest=20
of the hierarchy issue certificates only to non-CA entities, called=20
"end entities" that form the lowest level. Thus, all certification=20
paths begin at the top CA and descend through zero or more levels of=20
other CAs. All certificate users base path validations on the top=20
CA's public key. [RFC2828]=20
=20
CEM Request -The EDIINT Certificate Exchange Messaging (CEM) Request=20
is one of two possible CEM messages. It presents a certificate to be=20
introduced into the trading partner relationship along with relevant=20
information on how it is to be implemented.=20
=20
CEM Response -The EDIINT Certificate Exchange Messaging (CEM)=20
Response is one of two possible CEM messages. It is the response to=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 4]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
the CEM Request indicating whether or not the end entity certificate=20
present in the CEM Request was accepted. =20
=20
End Entity - A system entity that is the subject of a public-key=20
certificate and that is using, or is permitted and able to use, the=20
matching private key only for a purpose or purposes other than=20
signing a digital certificate; i.e., an entity that is not a CA.=20
[RFC2828]=20
=20
End Entity Certificate - A certificate which is used to encrypt data=20
or authenticate a signature. (The private key associated with the=20
certificate is used to decrypt data or sign data). The certificate=20
may be self-signed or issued by a trusted certificate.=20
=20
Intermediary Certificate - A certificate issued by a CA certificate=20
which itself issues another certificate (either intermediary or end=20
entity). Intermediary certificates are not used to encrypt data but=20
to sign other certificates.=20
=20
Public Key - The publicly-disclosable component of a pair of=20
cryptographic keys used for asymmetric cryptography. [RFC2828]=20
=20
Public Key Certificate - A digital certificate that binds a system=20
entity's identity to a public key value, and possibly to additional=20
data items. [RFC2828]=20
=20
Self-signed Certificate - A certificate which is issued by itself=20
(both issuer and subject are the same) and is an End Entity=20
certificate.=20
=20
1.3 =0D Certificate Lifecycle=20
=20
A certificate has five states.=20
=20
1. Pending - Upon receiving a certificate from a trading partner, the =
certificate is marked as Pending until a decision can be made to=20
trust it or if its validity period has not yet begun.=20
2. Rejected - If a Pending certificate is not trusted, it is=20
considered Rejected.=20
3. Accepted - Once a Pending certificate has been trusted, it is=20
considered Accepted. An Accepted certificate may be used in=20
secure transactions. =20
4. Expired - A certificate which is no longer valid because its=20
expiration date has passed. Expired certificates SHOULD be kept=20
in a certificate storehouse for decrypting and validating past=20
transactions.=20
5. Revoked - A certificate which has been explicitly revoked by its=20
owner or the certificate authority.=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 5]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
2. =0D Message Processing=20
=20
2.1 =0D Message Structure=20
=20
CEM messages use the underlying EDIINT transport, such as AS2, to=20
communicate information on the certificate, its intended use and its=20
acceptance. Both digital certifications and the XML data describing=20
their intended use are stored within a multipart-related MIME=20
envelope [RFC2387]. The certificates are stored in certificate chains =
through SMIME, certs-only MIME envelope [3851], and processing=20
information is XML data which is identified through the MIME content-
type of application/ediint-cert-exchange+xml. The format for CEM=20
messages is as follows:=20
=20
Various EDIINT headers=20
Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company=20
Content-Type: multipart/signed; micalg=3Dsha1;=20
protocol=3D"application/pkcs7-signature"; =20
boundary=3D"--OUTER-BOUNDARY"=20
=20
----OUTER-BOUNDARY=20
Content-Type: multipart/related; type=3D" application/ediint-cert-
exchange+xml"; boundary=3D"--INNER-BOUNDARY"=20
=20
----INNER-BOUNDARY=20
Content-Type: application/ediint-cert-exchange+xml=20
Content-ID: <[email protected]>=20
=20
[CEM XML data]=20
----INNER-BOUNDARY=20
Content-Type: application/pkcs7-mime; smime-type=3Dcerts-only=20
Content-ID: <[email protected]>=20
=20
[digital certificate]=20
----INNER-BOUNDARY--=20
=20
----OUTER-BOUNDARY=20
Content-Type: application/pkcs7-signature=20
=20
[Digital Signature]=20
----OUTER-BOUNDARY--=20
=20
One and only one MIME type of application/ediint-cert-exchange+xml=20
MUST be present in the multipart/related structure, and it MUST be=20
the root element. Multiple certs-only media types may be included,=20
but at least one MUST be present. A unique content-id header MUST be=20
present within each of the multipart structures.=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 6]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
If possible, both the CEM Request and CEM Response message SHOULD be=20
signed. Applying digital signatures will allow for automatic exchange =
based on a previous trust relationship. However, it may not be=20
possible in the initial exchange of a new trading partner. If a CEM=20
message is signed, the signing certificate MUST be included in the=20
digital signature. Extra security such as applying data encryption or =
compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and=20
SHOULD request a signed MDN. The MDN can be either synchronous or=20
asynchronous. The MDN response verifies the transport delivery but is =
not equivalent to the CEM Response message. All necessary headers=20
MUST be applied to the message per the underlying transport standard. =
=20
=20
2.2 =0D EDIINT Features Header=20
=20
To indicate support for CEM, an EDIINT application MUST use the=20
EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates =
the instance application can support various features, such as=20
certification exchange. The header is present in all messages from=20
the instance application, not just those which feature certification=20
exchange.=20
=20
For applications implementing certification exchange, the CEM-
Feature-Name MUST be used within the EDIINT Features header:=20
=20
CEM-Feature-Name =3D "CEM"=20
=20
2.3 =0D Certificate Exchanging=20
=20
After obtaining the desired certificate, the initiator of the=20
certificate exchange transmits the end-entity certificate in the CEM=20
Request message. If the end-entity certificate is not self-signed,=20
then the CA certificate and any other certificates needed to create=20
the chain of trust for the end-entity certificate MUST be included in =
the CEM Request message. Multiple end-entity certificates MAY also be =
present.=20
=20
The entire certificate trust chain is stored in a BER encoded P7C=20
format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs-
only MIME envelope which is then stored in a single part of the=20
multipart/related structure. Each P7C trust chain MUST include a=20
single end-entity certificate and its trust authorities. No other=20
certificates are to be part of this chain. The number of P7C trust=20
chains in a CEM Request message MUST be equal to the number of end-
entity certificates being communicated in the CEM XML document.=20
If different end-entity certificates have common trust authorities=20
certificates, each P7C cert chain still MUST included each=20
certificate necessary to create a trust anchor. Thus, if a recipient=20
can not create a trust relationship from the P7C cert chain, it MAY=20
reject the end-entity certificate in the CEM Request.=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 7]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
=20
End-entity certificates are referenced and identified in the XML data =
by their content-id used in the multipart-related structure.=20
Information on how the certificate is to be used, or certificate=20
usage, by the receiving user agent and other related information is=20
found in the XML data. A certificate can be used for a single=20
function, like digital signatures, or used for multiple functions,=20
such as both digital signatures and data encryption. If a certificate =
is intended for multiple usages, such as for both digital signatures=20
and data encryption, the certificate MUST be listed only once in the=20
CEM Request message and its multiple usage listed through the=20
CertUsage XML element.=20
=20
Upon receipt of the CEM Request, the recipient trading partner=20
processes the transport message as normal and returns the MDN. The=20
recipient MUST return the MDN before parsing and interpreting the CEM =
XML data or certificate chains. The returned MDN only provides=20
information on the veracity of the transport message and not the=20
acceptance of the certificate(s) being exchanged.=20
=20
=20
2.4 =0D Certificate Implementation=20
=20
The new certificate is considered to be in the Pending state for the=20
recipient who MUST decide whether to accept the certificate as=20
trustworthy. This decision is arbitrary and left to each individual=20
trading partner. Upon accepting the certificate, it is to be=20
considered an Accepted certificate within the trading partner=20
relationship. If the certificate is not accepted, it is considered=20
Rejected.=20
=20
When a certificate is intended for use in data encryption or TLS/SSL=20
server authentication, the initiator MUST consider the certificate to =
be Accepted and be prepared for its trading partner to begin using=20
the certificate upon generating the CEM Request message. After a=20
recipient generates a positive CEM Response message for a=20
certificate, the recipient MUST immediately begin using the=20
certificate in trading with the initiator of the request. The=20
recipient MAY apply encryption to the CEM Response message using the=20
new Accepted certificate or MAY apply encryption to the CEM Response=20
message using the previously Accepted encryption certificate.=20
=20
When a certificate is intended for use in digital signatures or=20
TLS/SSL client authentication, the initiator MUST NOT use the=20
certificate until the recipient trading partner generates a CEM=20
Response accepting the certificate or the respond by date, which is=20
listed in the RespondByDate XML element. The initiator MAY use the=20
certificate after the respond by date, regardless of whether the=20
partner has accepted it or not. The certificate used for the digital=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 8]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
signature of the CEM Request message MUST be the one which is=20
currently Accepted within the trading partner relationship.=20
=20
Since implementers of EDIINT often use the same certificate with=20
multiple trading partners, implementers of CEM MUST be able to keep=20
both the old and new certificates as Accepted. If the initiator has=20
generated a CEM Request and exchanged a new encryption certificate to =
multiple trading partners, it MUST be able to accept encrypted data=20
which uses either the older, existing encryption certificate or the=20
newly exchanged encryption certificate. Likewise, a recipient of a=20
CEM Request MUST be able to authenticate digital signatures using=20
either the new or old certificates, since the initiator may not be=20
able to switch certificates until all trading partners accept the new =
certificate. Similar provisions MUST be made for certificates=20
intended for TLS/SSL server and client authentication. Revoking a=20
certificate MUST be done outside of CEM.=20
=20
If a CEM Request message contains a certificate which is currently=20
Accepted and has the identical usage for the certificate that has=20
been Accepted, the recipient MUST NOT reject the duplicate=20
certificate but MUST respond with a CEM Response message indicating=20
the certificate has been accepted. For example, if Certificate A is=20
currently Accepted as the encryption certificate for a user agent,=20
any CEM Request message containing Certificate A with the usage as=20
encryption only MUST be accepted by an existing trading partner. This =
situation may be necessary for an implementation intending to verify=20
its current trading partner certificate.=20
=20
If two trading partners utilize multiple EDIINT protocols for=20
trading, such as AS2 for a primary transport and AS1 as the backup=20
transport, it is dependent upon implementation and trading partner=20
agreement how CEM messages are sent and which transports the=20
exchanged certificates affect.=20
=20
2.5 =0D CEM Response=20
=20
The CEM Response message contains a TrustResponse XML element.=20
TrustResponse provides information needed to match the end-entity=20
certificate sent in an earlier CEMRequest and indicate if the=20
certificate was accepted or rejected by the recipient. The=20
CertificateReference in a TrustResponse matches the=20
CertificateIdentifier value for the end-entity certificate in the CEM =
Request. CertStatus indicates if the certificate was accepted or=20
rejected. If a CEM Request is received, the recipient MUST respond=20
with a CEM Response message indicating if the certificate is Accepted =
or Rejected. More information about the XML attributes and value for=20
CEM Response can be found in 3.2.=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 9]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
If the certificate in the CEM Request message contains multiple=20
usages, such as for both digital signature and data encryption, only=20
a single TrustResponse is needed for that certificate. The CertStatus =
value in the TrustResponse is the response for both usages of the=20
certificate. A recipient can NOT choose to accept the certificate for =
one specified use and not the other.=20
=20
If multiple end-entity certificates were included within the CEM=20
Request, the recipient MAY generate individual CEM Response messages=20
for each certificate or the recipient MAY consolidate the=20
TrustResponse for multiple certificates into one CEM Response=20
message. A CEM Response may contain multiple TrustResponse elements=20
for different certificates but MUST NOT contain two or more=20
TrustResponses for the same certificate.=20
=20
If a second TrustResponses is received in different message matching=20
the same certificate as that of an earlier TrustRespnse but the=20
CertStatus have a different value than the other, the originator MAY=20
accept the CertStatus value in the most recent TrustResponse but MAY=20
choose to ignore it. If the CertStatus in both TrustResponses are the =
same, the originator should disregard the second TrustResponse.=20
=20
If the originator receives a CEM Response message which violates the=20
rules listed above or is invalid in any way, the originator MAY=20
reject the message entirely but MUST return an MDN if requested.=20
=20
=20
3. =0D XML Schema Description=20
=20
The CEM schema has two top-level elements,=20
EDIINTCertificateExchangeRequest and=20
EDIINTCertificateExchangeResponse. The=20
EDIINTCertificateExchangeRequest element is present only in the CEM=20
Request message, and the EDIINTCertificateExchangeResponse is present =
only in the CEM Response message. All other elements nest directly or =
indirectly from these. Please refer to the appendix for the actual=20
schema document.=20
=20
3.1 =0D EDIINTCertificateExchangeRequest element=20
=20
EDIINTCertificateExchangeRequest contains two elements,=20
TradingPartnerInfo, which can only appear once and TrustRequest,=20
which may be present multiple times. TrustRequest contains=20
information on a certificate and its intended usage.=20
TradingPartnerInfo exists to provide information on the publication=20
of the CEM Request message since processing of the XML data may occur =
apart from the handling of the accompanying transport message, for=20
example the AS2 request. =20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 10]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
<xs:element name=3D"EDIINTCertificateExchangeRequest">=20
<xs:complexType>=20
<xs:sequence>=20
<xs:element ref=3D"tns:TradingPartnerInfo"/>=20
<xs:element name=3D"TrustRequest" =20
type=3D"tns:TrustRequestType"=20
maxOccurs=3D"unbounded"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:element>=20
=20
TradingPartnerInfo identifies the entity that created the CEM message =
through the nested Name element. Both the optional qualifier=20
attribute and the element value of Name are left open to the=20
implementer, but some suggested choices are to list the EDI=20
identification or the transport trading partner relationship, for=20
example the qualifier of =93AS2=94 and the value of the AS2 system=20
identifier (AS2-From value). MessageOriginated is included in=20
TradingPartnerInfo to identify the time and date the message was=20
created. The MessageOriginated date and time values MUST follow XML=20
standard dateTime type syntax and be listed to at least the nearest=20
second and expressed in local time with UTC offset. For example, a=20
message originating from the US Eastern Standard timezone would use=20
2005-03-01T14:05:00-05:00.=20
=20
<xs:element name=3D"TradingPartnerInfo">=20
<xs:complexType>=20
<xs:sequence>=20
<xs:element name=3D"Name">=20
<xs:complexType>=20
<xs:simpleContent>=20
<xs:extension base=3D"xs:string">=20
<xs:attribute name=3D"qualifier" =20
type=3D"xs:string" use=3D"optional"/>=20
</xs:extension>=20
</xs:simpleContent>=20
</xs:complexType>=20
</xs:element>=20
<xs:element name=3D"MessageOriginated" =
type=3D"xs:dateTime"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:element>=20
=20
=20
The TrustRequest element contains the EndEntity, CertUsage,=20
RespondByDate and ResponseURL elements. The required EndEntity=20
element is found only once in a TrustRequest element and contains the =
content-id reference to the end-entity certificate being exchanged. =20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 11]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
<xs:complexType name=3D"TrustRequestType">=20
<xs:sequence>=20
<xs:element ref=3D"tns:CertUsage" maxOccurs=3D"unbounded"/>=20
<xs:element ref=3D"tns:RespondByDate"/>=20
<xs:element ref=3D"tns:ResponseURL"/>=20
<xs:element name=3D"EndEntity" type=3D"tns:EndEntityType"/>=20
</xs:sequence>=20
</xs:complexType>=20
=20
EndEntity contains the nested elements of CertificateIdentifier and=20
CertificateContentID. CertificateContentID is a string element which=20
references the content-id of the multipart/related structure where=20
the certificate is stored. CertificateIdentifier comes from the XML=20
Signature schema namespace [XML-DSIG]. =20
=20
<xs:complexType name=3D"EndEntityType">=20
<xs:sequence>=20
<xs:element name=3D"CertificateIdentifier" =20
type=3D"ds:X509IssuerSerialType"/>=20
<xs:element name=3D"CertificateContentID" =
type=3D"xs:string"/>=20
</xs:sequence>=20
=20
CertificateIdentifier contains the string element X509IssuerName and=20
the integer element X509SerialNumber. X509SerialNumber is the=20
assigned serial number of the end entity certificate as it is listed. =
X509IssuerName contains the issuer name information of the end-entity =
certificate, such as common name, organization, etc. This information =
MUST be describe in a string format per the rules of RFC 2253=20
[RFC2253]. This results in the attributes within the Issuer Name to=20
be listed with their attribute type followed by an "=3D" and the=20
attribute value. Each attribute type and value are separated by a "," =
and any escape characters in the value are preceded by a "\". Refer=20
to the appendix and the sample CEM Request message for an example of=20
the X509IssuerName.=20
=20
<complexType name=3D"X509IssuerSerialType"> =20
<sequence> =20
<element name=3D"X509IssuerName" type=3D"string"/> =20
<element name=3D"X509SerialNumber" =
type=3D"integer"/> =20
</sequence>=20
</complexType>=20
=20
CertUsage is an unbounded element which contains enumerated values on =
how the exchanged certificate is to be used. There are enumerated=20
values for SMIME digital signatures (digitalSignature), SMIME data=20
encryption (keyEncipherment), the server certificate used in TLS=20
transport encryption (tlsServer) and the client certificate used in=20
TLS transport encryption (tlsClient). While the element is unbounded, =
=20
=20
Meadors, Moberg Expires - September 2006 [Page 12]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
CertUsage only has a potential number of four occurrences due to the=20
limit of the enumerated values. =20
=20
<xs:element name=3D"CertUsage" type=3D"tns:CertUsageType"/>=20
<xs:simpleType name=3D"CertUsageType">=20
<xs:restriction base=3D"xs:string">=20
<xs:enumeration value=3D"tlsClient"/>=20
<xs:enumeration value=3D"tlsServer"/>=20
<xs:enumeration value=3D"keyEncipherment"/>=20
<xs:enumeration value=3D"digitalSignature"/>=20
</xs:restriction>=20
</xs:simpleType>=20
=20
RespondByDate is a required element of the XML standard dateTime type =
expressed in local time with UTC offset, which provides information=20
on when the certificate should be trusted, inserted into the trading=20
partner relationship and responded to by a CEM Response message. If=20
the certificate can not be trusted or inserted into the trading=20
partner relationship, the CEM Response message should still be=20
returned by the date indicated.=20
=20
<xs:element name=3D"RespondByDate" type=3D"xs:dateTime"/>=20
=20
ResponseURL is an element which indicates where the CEM Response=20
message should be sent. This value takes precedence over the existing =
inbound URL of the current trading partner relationship. The Response =
MUST use the same transport protocol (AS1, AS2, or AS3) as the=20
Request. =20
<xs:element name=3D"ResponseURL" type=3D"xs:anyURI"/>=20
=20
3.2 =0D EDIINTCertificateExchangeResponse element=20
=20
EDIINTCertificateExchangeResponse contains the two elements=20
TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is=20
also found in EDIINTCertificateExchangeRequest, describes the trading =
partner generating this response message. TrustResponse provides=20
information on the acceptance of a previously sent end entity=20
certificate. There can be multiple TrustResponse elements within an=20
EDIINTCertificateExchangeResponse.=20
=20
<xs:element name=3D"EDIINTCertificateExchangeResponse">=20
<xs:complexType>=20
<xs:sequence>=20
<xs:element ref=3D"tns:TradingPartnerInfo"/>=20
<xs:element name=3D"TrustResponse" =20
type=3D"tns:TrustResponseType"=20
maxOccurs=3D"unbounded"/>=20
</xs:sequence>=20
</xs:complexType>=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 13]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
</xs:element>=20
=20
<xs:complexType name=3D"TrustResponseType">=20
<xs:sequence>=20
<xs:element ref=3D"tns:CertStatus"/>=20
<xs:element ref=3D"tns:ReasonForRejection" minOccurs=3D"0"/> =
<xs:element name=3D"CertificateReference" =20
type=3D"ds:X509IssuerSerialType"/>=20
</xs:sequence>=20
</xs:complexType>=20
=20
A TrustResponse element identifies a certificate which has been=20
previously exchanged within the trading partner relationship through=20
a CEM Request and now has been either accepted or rejected by the=20
partner. The CertificateReference element is of the same type as the=20
CertificateIdentifier element. A CertificateReference element in a=20
CEM Response MUST be identical to its CertificateIdentifier=20
counterpart in the associated CEM Request since they identify the=20
same certificate in question.=20
=20
The required element CertStatus has the enumerated values of=20
=93Accepted=94 or =93Rejected=94. =93Accepted=94 indicates the =
certificate was=20
trusted by the trading partner and is now ready for use within the=20
trading partner relationship, and =93Rejected=94 indicates the=20
certificate is not trusted by the trading partner nor can it be=20
currently used with the trading partner relationship. If the value of =
=93Rejected=94 is chosen, the optional string element =
ReasonForRejection=20
may be included. If present, ReasonForRejection should contain a=20
brief description of why the certificate was not accepted. Since the=20
value for this element is not enumerated but open, it MUST be=20
interpreted through human means.=20
=20
<xs:element name=3D"CertStatus" type=3D"tns:CertStatusType"/>=20
<xs:simpleType name=3D"CertStatusType">=20
<xs:restriction base=3D"xs:string">=20
<xs:enumeration value=3D"Rejected"/>=20
<xs:enumeration value=3D"Accepted"/>=20
</xs:restriction>=20
</xs:simpleType>=20
<xs:element name=3D"ReasonForRejection" type=3D"xs:string"/>=20
=20
4. =0D Use Case Scenario=20
=20
This scenario illustrates how the CEM Request and CEM Response=20
messages described in Section 2 and 3 can be used to exchange=20
certificates. The scenario is only illustrative and any differences=20
between it and the rules above should defer to the rules in Section 2 =
and 3.=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 14]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
Two trading partners, TPA and TPB, have an established trading=20
partner relationship using AS2. TPA is using a single certificate,=20
CertA, for both digital signatures and data encryption. TPA wants to=20
issue a new certificate, CertB, for digital signatures but keep CertA =
for data encryption.=20
=20
TPB is using one certificate, Cert1, for digital signatures and=20
another certificate, Cert2, for data encryption. TPB wants to=20
introduce a new certificate, Cert3, for digital signature and a new=20
certificate, Cert4, for data encryption.=20
=20
TPA sends a CEM Request to TPB containing only CertB. The CertUsage=20
has a value of "digitalSignature". TPB immediately returns the MDN=20
but must make an internal security decision before accepting CertB.=20
In the mean time, TPA continues to send AS2 messages to TPB which=20
have been signed using CertA. The messages originating from TPB are=20
encrypted using CertA. After some point, TPB returns a CEMResponse=20
with the CertStatus of "Accepted" for CertB. Upon receipt, an MDN is=20
returned which is signed using CertA. TPB must be able to accept the=20
MDN if it has a digital signature from either CertA or CertB as TPA=20
may not be able to switch certificates simply upon receipt of the CEM =
Response message without parsing the XML payload. Also, TPA may need=20
to wait for other trading partners to accept the new CertB. TPB=20
should be prepared to accept digital signatures either from CertA or=20
CertB. However, soon as possible, TPA should being using CertB=20
exclusively for digital signatures. =20
=20
TPB sends a CEM Request to TPA containing both Cert3 and Cert4. The=20
CertUsage for Cert3 and Cert4 are "digitalSignature" and=20
"keyEncipherment", respectively. TPA returns an MDN immediately. TPB=20
is prepared to receive any encrypted inbound messages by either Cert2 =
or Cert4. All its digital signatures are done through Cert1. After=20
some time, TPA returns a single CEM Response message. It contains a=20
TrustResponse element for Cert3 and a TrustResponse element for=20
Cert4. The CertStatus for Cert3 is "Rejected" with the=20
ReasonForRejection field present and populated with the string=20
"KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted."=20
TPB returns the MDN signed through Cert1. Immediately after this, an=20
AS2 message is received from TPA which is encrypted using Cert2. TPB=20
returns the MDN signed with Cert3 and is only using Cert3 for digital =
signatures. After creating a new certificate, Cert5, which corrects=20
the previous keyUsage problem, TPB sends Cert5 in a CEM Request.=20
Shortly after this, TPA sends a CEM Response message for Cert5. It=20
contains a CertStatus of "Accepted". This CEM Response message was=20
encrypted using Cert4, but TPB was prepared for encryption from=20
either Cert2 or Cert4. The message is processed and a good MDN is=20
returned.=20
=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 15]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
5. =0D Profile Exchange Messaging=20
=20
CEM provides the means to exchange certificates among trading=20
partners. However, other profile information, such as URLs and=20
preferred security settings, is needed to create a trading partner=20
relationship. A future standard is needed to describe profile=20
descriptions and how they will be exchanged. The format for this=20
profile attachment is not defined in this specification but is=20
planned for a future document. It will build upon the existing CEM=20
protocol with profile information stored with XML data. Both=20
certificate and profile description information will be placed into a =
multipart/related [RFC2387] body part entity. A possible format for a =
profile description message is as follows:=20
=20
Various EDIINT headers=20
EDIINT=96Features: profile-exchange=20
Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company=20
Disposition-Notification-Options: signed-receipt-protocol=3Doptional, =
pkcs7-signature; signed-receipt-micalg=3Doptional, sha1=20
Content-Type: multipart/signed; micalg=3Dsha1;=20
protocol=3D"application/pkcs7-signature"; boundary=3D"--BOUNDARY1"=20
=20
----BOUNDARY1=20
Content-Type: multipart/related;=20
start=3D=94<[email protected]>"; =20
type=3D=94application/ediint-cert-exchange+xml=94; =20
boundary=3D"--BOUNDARY2"=20
=20
----BOUNDARY2=20
Content-Type: application/ediint-cert-exchange+xml=20
Content-ID: <[email protected]>=20
=20
[CEM XML data]=20
----BOUNDARY2=20
[Profile information attachment]=20
----BOUNDARY2--=20
----BOUNDARY1=20
=20
Content-Type: application/pkcs7-signature=20
=20
[Digital Signature]=20
----BOUNDARY1--=20
=20
=20
6. =0D Security Considerations=20
=20
Certificate exchange is safe for transmitting. However, implementers=20
SHOULD verify the received certificate to determine if it is truly=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 16]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
from the stated originator through out-of-band means or whenever the=20
request is not signed.=20
=20
=20
7. =0D IANA Considerations=20
=20
MIME Media type name: Application=20
=20
MIME subtype name: EDIINT-cert-exchange+xml=20
=20
Required parameters: None=20
=20
Optional parameters: This parameter has identical semantics to the=20
charset parameter of the =93application/xml=94 media type as =
specified=20
in [RFC3023].=20
=20
Encoding considerations: Identical to those of "application/xml" as=20
described in [RFC3023], section 3.2.=20
=20
Security considerations: See section 6. =20
=20
Interoperability Considerations: See section 2.2=20
=20
Published specification: This document.=20
=20
Applications which use this media type: EDIINT applications, such as=20
AS1, AS2 and AS3 implementations.=20
=20
Additional Information: None=20
=20
Intended Usage: Common=20
=20
Author/Change controller: See Author=92s section of this document.=20
=20
8. =0D References=20
8.1 =0D Normative References=20
=20
[AS1] RFC3335 =93MIME-based Secure Peer-to-Peer Business Data=20
Interchange over the Internet using SMTP=94, T. Harding, R.=20
Drummond, C. Shih, 2002.=20
=20
[AS2] RFC4130 =93MIME-based Secure Peer-to-Peer Business Data=20
Interchange over the Internet using HTTP=94, D. Moberg, R.=20
Drummond, 2005.=20
=20
[AS3] draft-ietf-ediint-as3-02.txt =93MIME-based Secure Peer-to-Peer=20
Business Data Interchange over the Internet using FTP=94, T.=20
Harding, R. Scott, 2003.=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 17]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
[EDIINT FEATURE] draft-meadors-ediint-feature-header-00.txt =
=93Feature=20
Header for EDI-INT=94, K. Meadors, 2005.=20
=20
[RFC2119] RFC2119 =93Key Words for Use in RFC's to Indicate =
Requirement=20
Levels=94, S.Bradner, March 1997.=20
=20
[RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,=20
January 1999.=20
=20
[RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8=20
String Representation of Distinguished Names", M. Wahl, S. Kille=20
and T. Howes, Decemeber 1997.=20
=20
[RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.=20
Levinson, August 1998.=20
=20
[RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000.=20
=20
[RFC2828] RFC2828 =93Internet Security Glossary=94, R. Shirley, May =
2000.=20
=20
[RFC3023] RFC3023 =93XML Media Types=94, M. Murata, January 2001.=20
=20
[3821] RFC3821 =93S/MIME Version 3.1 Message Specification=94, B.=20
Ramsdell, July 2004.=20
=20
[XML-DSIG] RFC3275 =93XML-Signature Syntax and Processing=94, D.=20
Eastlake, March 2002. =20
=20
[X.520] ITU-T Recommendation X.520: Information Technology - Open=20
Systems Interconnection - The Directory: Selected Attribute=20
Types, 1993.=20
=20
[PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet=20
X.509 Public Key Infrastructure: Certificate and CRL Profile",=20
RFC 3280, April 2002.=20
=20
8.2 =0D Informative References=20
=20
9. =0D Acknowledgments=20
=20
The authors wish to extend gratitude to the ecGIF sub-committee=20
within the GS1 organization from which this effort began. Of special=20
note is John Duker who chaired the sub-committee and provided=20
valuable editing, Richard Bigelow who greatly assisted development of =
the ideas presented and John Koehring with his insights on=20
implementation and Debra Petta for her review and comments.=20
=20
Author's Addresses=20
=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 18]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
Kyle Meadors=20
Drummond Group Inc.=20
4700 Bryant Irvin Court, Suite 303=20
Fort Worth, TX 76107 USA=20
Email: [email protected]=20
=20
Dale Moberg=20
Cyclone Commerce=20
8388 E. Hartford Drive, Suite 100=20
Scottsdale, AZ 85255 USA=20
Email: [email protected]=20
=20
=20
Copyright Notice=20
Copyright (C) The Internet Society 2005. This document is subject=20
to the rights, licenses and restrictions contained in BCP 78, and=20
except as set forth therein, the authors retain all their rights.=20
=20
This document and the information contained herein are provided on an =
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS =
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20
=20
Appendix=20
=20
A.1 EDIINT Certificate Exchange XML Schema=20
=20
<?xml version=3D"1.0">=20
<xs:schema targetNamespace=3D"EDIINTCertificateExchange.xsd"=20
xmlns:tns=3D"EDIINTCertificateExchange.xsd"=20
xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=20
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"=20
elementFormDefault=3D"qualified">=20
<xs:import namespace=3D"http://www.w3.org/2000/09/xmldsig#"=20
schemaLocation=3D"xmldsig-core-schema.xsd"/>=20
<xs:element name=3D"EDIINTCertificateExchangeRequest">=20
<xs:complexType>=20
<xs:sequence>=20
<xs:element ref=3D"tns:TradingPartnerInfo"/>=20
<xs:element name=3D"TrustRequest" =20
type=3D"tns:TrustRequestType" =
maxOccurs=3D"unbounded"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:element>=20
<xs:element name=3D"EDIINTCertificateExchangeResponse">=20
<xs:complexType>=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 19]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
<xs:sequence>=20
<xs:element ref=3D"tns:TradingPartnerInfo"/>=20
<xs:element name=3D"TrustResponse" =20
type=3D"tns:TrustResponseType" =
maxOccurs=3D"unbounded"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:element>=20
<xs:element name=3D"TradingPartnerInfo">=20
<xs:complexType>=20
<xs:sequence>=20
<xs:element name=3D"Name">=20
<xs:complexType>=20
<xs:simpleContent>=20
<xs:extension base=3D"xs:string">=20
<xs:attribute name=3D"qualifier" =20
type=3D"xs:string" use=3D"optional"/>=20
</xs:extension>=20
</xs:simpleContent>=20
</xs:complexType>=20
</xs:element>=20
<xs:element name=3D"MessageOriginated" =
type=3D"xs:dateTime"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:element>=20
<xs:element name=3D"CertUsage" type=3D"tns:CertUsageType"/>=20
<xs:simpleType name=3D"CertUsageType">=20
<xs:restriction base=3D"xs:string">=20
<xs:enumeration value=3D"tlsClient"/>=20
<xs:enumeration value=3D"tlsServer"/>=20
<xs:enumeration value=3D"keyEncipherment"/>=20
<xs:enumeration value=3D"digitalSignature"/>=20
</xs:restriction>=20
</xs:simpleType>=20
<xs:element name=3D"CertStatus" type=3D"tns:CertStatusType"/>=20
<xs:simpleType name=3D"CertStatusType">=20
<xs:restriction base=3D"xs:string">=20
<xs:enumeration value=3D"Rejected"/>=20
<xs:enumeration value=3D"Accepted"/>=20
</xs:restriction>=20
</xs:simpleType>=20
<xs:element name=3D"ReasonForRejection" type=3D"xs:string"/>=20
<xs:element name=3D"RespondByDate" type=3D"xs:dateTime"/>=20
<xs:element name=3D"ResponseURL" type=3D"xs:anyURI"/>=20
<xs:complexType name=3D"EndEntityType">=20
<xs:sequence>=20
<xs:element name=3D"CertificateIdentifier" =20
type=3D"ds:X509IssuerSerialType"/>=20
<xs:element name=3D"CertificateContentID" =
type=3D"xs:string"/>=20
</xs:sequence>=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 20]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
</xs:complexType>=20
<xs:complexType name=3D"TrustRequestType">=20
<xs:sequence>=20
<xs:element ref=3D"tns:CertUsage" maxOccurs=3D"unbounded"/>=20
<xs:element ref=3D"tns:RespondByDate"/>=20
<xs:element ref=3D"tns:ResponseURL"/>=20
<xs:element name=3D"EndEntity" type=3D"tns:EndEntityType"/>=20
</xs:sequence>=20
</xs:complexType>=20
<xs:complexType name=3D"TrustResponseType">=20
<xs:sequence>=20
<xs:element ref=3D"tns:CertStatus"/>=20
<xs:element ref=3D"tns:ReasonForRejection" minOccurs=3D"0"/> =
<xs:element name=3D"CertificateReference" =20
type=3D"ds:X509IssuerSerialType"/>=20
</xs:sequence>=20
</xs:complexType>=20
</xs:schema>=20
=20
A.2 Example of EDIINT Certificate Exchange Request XML=20
=20
<?xml version=3D"1.0" standalone=3D"yes"?>=20
<EDIINTCertificateExchangeRequest=20
xmlns=3D"EDIINTCertificateExchange.xsd"=20
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"=20
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=20
xsi:schemaLocation=3D"EDIINTCertificateExchange.xsd=20
EDIINTCertificateExchange.xsd">=20
<TradingPartnerInfo>=20
<Name qualifier=3D"AS2">DGI_Test_CEM</Name>=20
<MessageOriginated>=20
2005-08-30T00:30:00-05:00</MessageOriginated>=20
</TradingPartnerInfo>=20
<TrustRequest>=20
<CertUsage>keyEncipherment</CertUsage>=20
<CertUsage>digitalSignature</CertUsage>=20
<RespondByDate>2005-09-30T12:00:00-05:00</RespondByDate>=20
<ResponseURL>http://10.1.1.1/as2</ResponseURL>=20
<EndEntity>=20
<CertificateIdentifier>=20
<ds:X509IssuerName>CN=3DCleo-
SP,[email protected],O=3DDGI,OU=3DDGI,L=3DFt. =
Worth,S=3DTexas,C=3DUS</ds:X509IssuerName>
<ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>=20
</CertificateIdentifier>=20
<CertificateContentID>=20
[email protected]</CertificateContentID>=20
</EndEntity>=20
</TrustRequest>=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 21]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
<TrustRequest>=20
<CertUsage>tlsServer</CertUsage>=20
<RespondByDate>2005-09-30T12:00:00-05:00</RespondByDate>=20
<ResponseURL>http://10.1.1.1/as2</ResponseURL>=20
<EndEntity>=20
<CertificateIdentifier>=20
<ds:X509IssuerName>CN=3DVeriSign Class 1 CA Individual=20
Subscriber-Persona Not Validated,OU=3Dwww.verisign.com/repository/RPA =
Incorp. By Ref.\,LIAB.LTD(c)98,OU=3DVeriSign Trust =
Network,O=3DVeriSign\,=20
Inc.</ds:X509IssuerName>
<ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X50
9SerialNumber>=20
</CertificateIdentifier>=20
<CertificateContentID>=20
[email protected]</CertificateContentID>=20
</EndEntity>=20
</TrustRequest>=20
</EDIINTCertificateExchangeRequest>=20
=20
A.3 Example of EDIINT Certificate Exchange Response XML=20
=20
<?xml version=3D"1.0"?>=20
<EDIINTCertificateExchangeResponse=20
xmlns=3D"EDIINTCertificateExchange.xsd"=20
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"=20
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=20
xsi:schemaLocation=3D"EDIINTCertificateExchange.xsd=20
EDIINTCertificateExchange.xsd">=20
<TradingPartnerInfo>=20
<Name qualifier=3D"AS2">DGI_Test_CEM_Trading_Partner</Name>=20
<MessageOriginated>=20
2005-08-31T00:21:00-05:00</MessageOriginated>=20
</TradingPartnerInfo>=20
<TrustResponse>=20
<CertStatus>Accepted</CertStatus>=20
<CertificateReference>=20
<ds:X509IssuerName>CN=3DCleo-
SP,[email protected],O=3DDGI,OU=3DDGI,L=3DFt. =
Worth,S=3DTexas,C=3DUS</ds:X509IssuerName>=20
<ds:X509SerialNumber>9659684611094873474886</ds:X509SerialNumber>=20
</CertificateReference>=20
</TrustResponse>=20
<TrustResponse>=20
<CertStatus>Accepted</CertStatus>=20
<CertificateReference>=20
<ds:X509IssuerName>CN=3DVeriSign Class 1 CA Individual=20
Subscriber-Persona Not Validated,OU=3Dwww.verisign.com/repository/RPA =
Incorp. By Ref.\,LIAB.LTD(c)98,OU=3DVeriSign Trust =
Network,O=3DVeriSign\,=20
Inc.</ds:X509IssuerName>=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 22]=20
=0CDraft CEM for EDIINT March =
2006=20
=20
=20
<ds:X509SerialNumber>2673611014597817669550861744279966682</ds:X50
9SerialNumber>=20
</CertificateReference>=20
</TrustResponse>=20
</EDIINTCertificateExchangeResponse>=20
=20
Changes from Previous Versions=20
=20
B.1 Updates from Version 00=20
=20
. Updated security requirements in section 2.1, specifically in=20
regards to digital signatures.=20
. The XML element responseURL is now required. Modified section=20
3.1 and example messages in appendix accordingly.=20
. Certificates are exchanged within a full P7C cert chain. Section=20
2.3 reflects this.=20
. The XML element TrustChain is not longer necessary since the=20
entire cert chain is stored. Removed references in schema and=20
document.=20
. Added statement in 2.5 that multiple CEM Responses SHOULD NOT be=20
sent and that if this occurs, the action of the CEM Request=20
initiator is not defined. =20
. Updated the examples in Appendix B to reflect the current usage.=20
=20
B.2 Updates from Version 01=20
=20
. Added information for handling different scenarios with CEM=20
Response message.=20
. Rewrote use case scenarios.=20
. Added the EDIINT Features header information.=20
=20
B.3 Updates from Version 02=20
=20
. No changes =96 updated because Vs 02 expired.=20
=20
=20
Meadors, Moberg Expires - September 2006 [Page 23]=20
=0C
------=_NextPart_000_00C8_01C641F0.E4F92ED0--