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