Rik Drummond | 2 Sep 22:14 2004

I just submitted, I hope, the final draft of the AS2 document to the draft section on the IETF site.


Next step final call... If you all approve.... rik

Internet-Drafts | 7 Sep 18:15 2004
Picon

I-D ACTION:draft-ietf-ediint-as2-16.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF.

	Title		: MIME-based Secure Peer-to-Peer Business Data Interchange 
			  over the Internet Using HTTP AS2
	Author(s)	: D. Moberg, R. Drummond
	Filename	: draft-ietf-ediint-as2-16.txt
	Pages		: 84
	Date		: 2004-9-3
	
This document describes how to exchange structured business
data securely using HTTP transfer for XML, Binary,
Electronic Data Interchange, (EDI - either the American
Standards Committee X12 or UN/EDIFACT,  Electronic Data
Interchange for Administration, Commerce and Transport) or
other data describable in MIME used for business to business
data interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by
using Cryptographic Message Syntax (S/MIME) security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the original HTTP message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-16.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

(Continue reading)

Kyle Meadors | 25 Sep 01:04 2004

need for certificate exchange standard

EDIINT,

 

Part of the EDIINT WG charter is the intention to produce secure transactions of EDI over the Internet. Within AS1, AS2 and AS3, this security has been realized through encryption which relies on trusted digital certificates. The AS1, AS2 and AS3 standards all contain sections discussing certificate handling and each have this statement…

 

“In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship.”

 

I will soon be submitting a RFC standards track Internet draft dealing with certificate exchange within EDIINT. This standard was first proposed by the ecGIF subcommittee within the UCC. Through ecGIF, several AS2 vendors and implementers contributed to its development. It is being brought to EDIINT for discussion and consideration as an Internet draft. There is a great interest among supply-chains for an effective means of exchanging certificates within a trading partner relationship.

 

I look forward to your comments and suggestions on this initiative.

 

Kyle Meadors

Program Manager

Drummond Group Inc.

615.384.5006

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004

Kyle Meadors | 25 Sep 01:13 2004

draft-ediint-certificate-exchange-00.txt


Draft                       CEM for EDIINT              September 2004 
 
 
   EDIINT Working Group                                                 
   Internet Draft                                            K. Meadors 
   Document: draft-ietf-ediint-certificate-         Drummond Group Inc. 
   exchange-00.txt                                            D. Moberg 
   Expires: March 2005                                 Cyclone Commerce 
                                                         September 2004 
    
    
                 Certificate Exchange Messaging for EDIINT 
                 Draft-ediint-certificate-exchange-00.doc 
    
    
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 <at> imc.org>. 
   Requests to subscribe to the mailing list should be addressed to 
   <ietf-ediint-request <at> imc.org>. 
    
   Copyright Notice 
    
   Copyright (c) The Internet Society (2004). All rights reserved. 
    
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 
   Messaging provides the format and means to effectively exchange 
   certificates for use within trading partner relationships. The 
 
 
Meadors, Moberg          Expires - March 2005                 [Page 1] 


Draft                       CEM for EDIINT              September 2004 
 
 
   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 the ietf-ediint list for discussion, 
   with "Certificate Exchange" in the Subject field. To enter or follow 
   the discussion, you need to subscribe to ietf-ediint <at> imc.org. 
    
   -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........................3 
      1.3 Certificate Lifecycle......................................5 
   2. Message Processing.............................................5 
      2.1 Message Structure..........................................5 
      2.2 Version Header.............................................6 
      2.3 Messaging Exchange.........................................6 
      2.4 Certificate Implementation.................................7 
   3. XML Schema Description.........................................8 
      3.1 EDIINTCertificateExchangeRequest element...................9 
      3.2 EDIINTCertificateExchangeResponse element.................12 
   4. Use Case Scenarios............................................14 
 
 
Meadors, Moberg          Expires - March 2005                 [Page 2] 


Draft                       CEM for EDIINT              September 2004 
 
 
      4.1 Maintenance Configuration Processing......................14 
      4.2 Initial Configuration Processing..........................15 
   5. Profile Exchange Messaging....................................17 
   6. Security Considerations.......................................18 
   7. IANA Considerations...........................................18 
   8. References....................................................19 
   9. Acknowledgments...............................................19 
   Author's Addresses...............................................20 
   Appendix.........................................................20 
    
    
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 
   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 

 
 
Meadors, Moberg          Expires - March 2005                 [Page 3] 


Draft                       CEM for EDIINT              September 2004 
 
 
   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 
   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] 
 
 
Meadors, Moberg          Expires - March 2005                 [Page 4] 


Draft                       CEM for EDIINT              September 2004 
 
 
    
   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. 
    
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. The information is XML data which is identified through 

 
 
Meadors, Moberg          Expires - March 2005                 [Page 5] 


Draft                       CEM for EDIINT              September 2004 
 
 
   the MIME content-type of application/ediint-cert-exchange+xml. The 
   simple 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="--BOUNDARY" 
    
   ----BOUNDARY 
   Content-Type: application/ediint-cert-exchange+xml 
    
   [CEM XML data] 
   ----BOUNDARY 
    
   Content-Type: application/pkcs7-signature 
    
   [Digital Signature] 
   ----BOUNDARY-- 
    
   Both the CEM Request and CEM Response message SHOULD be signed. If it 
   is desired to enable automatic exchange based on a previous trust 
   relationship, then both the CEM Request and CEM Response message MUST 
   be signed. Also, CEM messages SHOULD request a MDN and SHOULD request 
   a signed MDN. Extra security such as applying data encryption is 
   OPTIONAL. 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    Version Header 
    
   Before a CEM Request message is generated, the initiator MUST 
   determine if the recipient can accept the CEM Request message. For 
   both AS2 and AS3, the version header value of 1.2 or greater (e.g. 
   1.3) indicates the implementation can both initiate and receive CEM 
   message exchanges. AS2 and AS3 implementers of CEM MUST utilize the 
   proper version header in all of their messages, both CEM messages and 
   normal document transport messages. Since there is no AS1 version 
   header, trading partners using AS1 MUST decide within the trading 
   partner agreement whether to utilize CEM. 
    
   For CEM Request messages of initial trading partner configurations, 
   the initiator MUST decide within the trading partner agreement if the 
   recipient can accept the CEM Request. 
    
2.3    Messaging Exchange 
    

 
 
Meadors, Moberg          Expires - March 2005                 [Page 6] 


Draft                       CEM for EDIINT              September 2004 
 
 
   After obtaining the desired certificate, the initiator of the 
   certificate exchange transmits the certificate in the CEM Request 
   message. Multiple certificates may be included with the XML of the 
   CEM Request. 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 are included in the XML 
   payload. Multiple end-entity certificates may also be present. 
    
   Information on how the certificate is to be used, or certificate 
   usage, is also 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 a CEM Request message and its multiple usage listed through 
   the CertUsage 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. The returned MDN only provides information on the veracity 
   of the transport message and not the acceptance of the certificate 
   being exchanged. 
    
   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. The recipient MUST respond with a CEM Response message 
   indicating its acceptance or rejection of the certificate. If 
   multiple certificates were included within the CEM Request, the 
   recipient MAY generate individual CEM Response messages for each 
   certificate or the recipient MAY consolidate responses for multiple 
   certificates in one or more CEM Response messages. The recipient MUST 
   NOT generate more than one CEM Response for a given certificate. 
   Based on the CEM Response message, the initiator determines if the 
   exchanged certificate may be used in future trading with the 
   recipient partner. 
    
2.4    Certificate Implementation 
    
   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 
 
 
Meadors, Moberg          Expires - March 2005                 [Page 7] 


Draft                       CEM for EDIINT              September 2004 
 
 
   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 start of 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 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 Implementation 
   X, any CEM Request message containing Certificate A with the usage as 
   the 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. 
    
3.   XML Schema Description 
    

 
 
Meadors, Moberg          Expires - March 2005                 [Page 8] 


Draft                       CEM for EDIINT              September 2004 
 
 
   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.  
    
      <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. 
    
      <xs:element name="TradingPartnerInfo"> 
         <xs:complexType> 
            <xs:sequence> 
               <xs:element name="Name"> 
                  <xs:complexType> 
                     <xs:simpleContent> 
 
 
Meadors, Moberg          Expires - March 2005                 [Page 9] 


Draft                       CEM for EDIINT              September 2004 
 
 
                        <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, TrustChain, 
   CertUsage, RespondByDate and ResponseURL elements. The required 
   EndEntity element is found only once in a TrustRequest element and 
   contains the end entity certificate being exchanged. TrustChain 
   contains any certificates necessary to complete the chain of trust 
   for the end entity certificate. For example, if the end entity 
   certificate being exchanged is self-signed then there would not be a 
   TrustChain element. However, if the end entity certificate is issued 
   by an intermediary certificate which is issued by a root CA 
   certificate, both the intermediary certificate and the CA certificate 
   would be placed in the same X509Data element within the same 
   TrustChain element. 
    
      <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:element name="TrustChain" type="tns:TrustChainType"  
                        minOccurs=”0”/> 
         </xs:sequence> 
      </xs:complexType> 
    
   EndEntity contains the nested elements of CertificateIdentifier and 
   X509Data, and TrustChain only contains X509Data. Both 
   CertificateIdentifier and X509Data come from the XML Signature schema 
   namespace [XML-DSIG].  
    
      <xs:complexType name="EndEntityType"> 
         <xs:sequence> 
            <xs:element name="CertificateIdentifier"  
                type="ds:X509IssuerSerialType"/> 
            <xs:element ref="ds:X509Data"/> 
         </xs:sequence> 
    
 
 
Meadors, Moberg          Expires - March 2005                [Page 10] 


Draft                       CEM for EDIINT              September 2004 
 
 
      <xs:complexType name="TrustChainType"> 
         <xs:sequence> 
            <xs:element ref="ds:X509Data"/> 
         </xs:sequence> 
      </xs:complexType> 
    
   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 
   can be described in any format, but it is RECOMMENDED to list each 
   issuer attribute abbreviation [X.520] [PROFILE] followed by the equal 
   sign (i.e. “=”), then separating each attribute listing by a single 
   semi-colon (e.g. CN=The Common Name;O=Organization;…). 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> 
    
   X509Data element contains the digital certificate. For both the 
   EndEntity and TrustChain elements, the choice for displaying the 
   certificate MUST be the X509Certificate element within X509Data. The 
   certificate MUST be encoded in base64. 
    
         <element name="X509Data" type="ds:X509DataType"/>  
         <complexType name="X509DataType"> 
               <sequence maxOccurs="unbounded"> 
                     <choice> 
                           <element name="X509IssuerSerial"  
                              type="ds:X509IssuerSerialType"/> 
                           <element name="X509SKI" type="base64Binary"/> 
                           <element name="X509SubjectName"  
                              type="string"/> 
                           <element name="X509Certificate"  
                              type="base64Binary"/> 
                           <element name="X509CRL" type="base64Binary"/> 
                           <any namespace="##other"  
                              processContents="lax"/> 
                     </choice> 
               </sequence> 
         </complexType> 
    

 
 
Meadors, Moberg          Expires - March 2005                [Page 11] 


Draft                       CEM for EDIINT              September 2004 
 
 
   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, 
   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 optional 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. If 
   the element is absent, the CEM Response message is returned according 
   to the URL stipulated in the trading partner relationship. The 
   Response MUST use the same transport protocol (AS1, AS2, or AS3) as 
   the Request. The Response URL MUST use this protocol. 
    
      <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. 
    
 
 
Meadors, Moberg          Expires - March 2005                [Page 12] 


Draft                       CEM for EDIINT              September 2004 
 
 
      <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> 
      </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"/> 
 
 
Meadors, Moberg          Expires - March 2005                [Page 13] 


Draft                       CEM for EDIINT              September 2004 
 
 
    
4.   Use Case Scenarios 
    
   These scenarios illustrate how the request and response messages 
   described in Section 2 and 3 can be used to exchange certificates.  
   The requirements of this standard are in Section 2 and 3; this 
   section is only illustrative. 
    
4.1    Maintenance Configuration Processing 
    
   This use case assumes an established relationship with currently 
   working certificates. Examples of this use case include, but are not 
   limited to a certificate with an expiration date approaching.  If the 
   current certificate is used to sign the Certificate Exchange 
   messages, this signature can be used to establish a level of trust in 
   the transaction. For this example, the AS2 transport protocol is 
   used. 
    
   4.1.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sends it according to EDIINT-AS2 protocol.  A positive MDN 
   received during this step indicates successful transmission of the 
   message but does not imply successful action on the certificate.  In 
   the case of an encryption certificate, the initiator MUST be 
   immediately ready to receive documents encrypted with the new 
   certificate.  In the case of a signing certificate, the initiator can 
   begin signing documents with the new certificate at the RespondByDate 
   or upon receipt of an EDIINTCertificateExchangeResponse from the 
   partner indicating acceptance of the certificate. If an acceptance 
   response is not received by the RespondByDate, the initiator may or 
   may not begin signing with the new certificate, depending on the 
   implementation’s capabilities and the policies of the initiator. 
    
   4.1.2. Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns a correct MDN.  If the message is a proper 
   AS2 document, the receiver MUST automatically accept or reject the 
   new certificate(s) or require manual intervention. If the certificate 
   is automatically accepted or rejected, an 
   EDIINTCertificateExchangeResponse MUST be generated and returned to 
   the initiator.  Since the trading relationship could be hindered if 
   action is not taken prior to the RespondByDate, manual intervention 
   MUST be done before that date. When the manual intervention 
   determines to accept or reject the new certificate, an 
   EDIINTCertificateExchangeResponse MUST be generated and returned to 
   the initiator. Both automatic and manual 
 
 
Meadors, Moberg          Expires - March 2005                [Page 14] 


Draft                       CEM for EDIINT              September 2004 
 
 
   EDIINTCertificateExchangeResponses MUST be formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  A positive MDN received 
   for the response message indicates successful transmission of the 
   response message. 
    
   After the receiver accepts the new certificate and returns an 
   acceptance response, the receiver encrypts all messages to the 
   initiator with the new encryption certificate.  The receiver 
   continues to accept messages from the initiator that are signed with 
   the old signing certificate, and also accepts messages signed with 
   the new signing certificate.  The initiator may start signing with 
   the new certificate when it receives the acceptance response, or when 
   it receives acceptance responses from all its partners, or after the 
   RespondByDate, or when the old signing certificate expires. 
    
   4.1.3.  Step 3 
    
   After the exchange is complete, some cleanup may be desirable, 
   including retiring or archiving the old certificates.  This step is 
   considered an implementation detail that is left purely to the 
   vendors and users. 
    
4.2    Initial Configuration Processing 
    
   This use case assumes all necessary elements of an EDIINT 
   relationship exist outside of the certificates, including an 
   understanding of the partner’s ability to support a CEM.  
   Establishing these elements may be accomplished via an automated 
   exchange, a manual process, or any other method desirable.  No 
   methods of exchanging the additional information are described in 
   this specification.  Examples of this use case include, but are not 
   limited to the first exchange of a certificate, or recovery from an 
   expired or compromised certificate.  This case assumes no signing 
   certificate has been established, precluding a signature being used 
   to establish a level of trust.  Therefore, extra precautions may be 
   appropriate in this use case.  There are additional use cases 
   possible where some certificates are already established.  It is not 
   practical to cover every case here, but this case and the maintenance 
   case should give sufficient guidance. 
    
   4.2.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator 
   sends it according to EDIINT-AS2 protocol.  Using a digital signature 
   on the AS2 message is optional, as the receiver will not be able to 
   verify until after accepting the signature certificate.  If the 
   receiver supports this use case, they MUST accept this message 
 
 
Meadors, Moberg          Expires - March 2005                [Page 15] 


Draft                       CEM for EDIINT              September 2004 
 
 
   regardless of the presence of a signature.  Unless the initiator 
   possesses the receiver’s encryption certificate, encryption MUST NOT 
   be used.  Unless the initiator possesses the receiver’s signature 
   certificate, they SHOULD NOT request a signed MDN.  If the MDN is not 
   signed, there is no legal proof the receiver received the message.  
   In addition, a positive MDN received during this step gives some 
   indication of successful transmission of the message, but does not 
   imply successful action on the certificate.  In the case of an 
   encryption certificate, the initiator MUST be immediately ready to 
   receive documents encrypted with the new certificate.  In the case of 
   a signing certificate, the initiator can begin signing documents with 
   the new certificate at the RespondByDate or upon receipt of an 
   EDIINTCertificateExchangeResponse from the partner indicating they 
   are ready. If an acceptance response is not received by the 
   RespondByDate, the initiator may or may not begin signing with the 
   new certificate, depending on the implementation’s capabilities and 
   the policies of the initiator. 
    
   4.2.2.   Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns an MDN according to the EDIINT-AS2 
   protocol.  If the message is a proper AS2 document, the receiver MUST 
   automatically accept or reject the new certificate(s), or require 
   manual intervention.  Caution should be used in automatically 
   accepting the certificate, as it may be impossible to verify the 
   sender is authentic.  If the certificate is automatically accepted or 
   rejected, an EDIINTCertificateExchangeResponse MUST be generated and 
   returned to the initiator.  Since the trading relationship could be 
   hindered if action is not taken prior to the RespondByDate, manual 
   intervention MUST be done before that date. When the manual 
   intervention determines to accept or reject the certificate, an 
   EDIINTCertificateExchangeResponse MUST be generated and returned to 
   the initiator.  
    
   In both the automatic and manual case, the 
   EDIINTCertificateExchangeResponses MUST be formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  If the original CEM 
   included the encryption certificate, or if the receiver has the 
   initiator encryption certificate on file, it may be used to encrypt 
   the AS2 message including the EDIINTCertificateExchangeResponse.  
   Otherwise, it may be necessary to send this 
   EDIINTCertificateExchangeResponse unencrypted.  The message may be 
   signed, but it is possible the initiator will have no way to verify 
   the signature.  The initiator MUST accept this response, regardless 
   of if it is signed.  A positive MDN received for the response message 
   indicates successful transmission of the response message. 
    
 
 
Meadors, Moberg          Expires - March 2005                [Page 16] 


Draft                       CEM for EDIINT              September 2004 
 
 
   After the receiver accepts the certificate and returns an acceptance 
   response, the receiver may encrypt messages to the initiator with the 
   encryption certificate.  The receiver begins to accept messages from 
   the initiator that are signed with the signing certificate.  The 
   initiator may start signing with the certificate when it receives the 
   acceptance response, or when it receives acceptance responses from 
   all its partners, or after the RespondByDate. 
    
   4.2.3.   Step 3 
    
   After the exchange is complete, additional certificates may need to 
   be exchanged before a complete trading relationship can be 
   successful.   This step is considered an implementation detail that 
   is left purely to the vendors and users. 
    
    
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 
   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 <at> foo.com>";  
     type=”application/ediint-cert-exchange+xml”;  
     boundary="--BOUNDARY2" 
    
   ----BOUNDARY2 
   Content-Type: application/ediint-cert-exchange+xml 
   Content-ID: <aayxdfl01012000 <at> foo.com> 
    
   [CEM XML data] 
   ----BOUNDARY2 
 
 
Meadors, Moberg          Expires - March 2005                [Page 17] 


Draft                       CEM for EDIINT              September 2004 
 
 
   [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 
   from the stated originator through out-of-band means for the initial 
   use case of 4.2 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. 
    

 
 
Meadors, Moberg          Expires - March 2005                [Page 18] 


Draft                       CEM for EDIINT              September 2004 
 
 
8.   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] draft-ietf-ediint-as2-15.txt “MIME-based Secure Peer-to-Peer 
      Business Data Interchange over the Internet using HTTP”, D. 
      Moberg, R. Drummond, 2004. 
    
   [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. 
            
   [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. 
    
   [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. 
    
   [S/MIME] RFC2633 “S/MIME Version 3 Message Specification”, 
      B.Ramsdell, June 1999. 
    
   [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. 
    
9.   Acknowledgments 
    
   The authors wish to extend gratitude to the ecGIF sub-committee 
   within the EAN.UCC 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 
 
 
Meadors, Moberg          Expires - March 2005                [Page 19] 


Draft                       CEM for EDIINT              September 2004 
 
 
   the ideas presented, John Koehring with his insights on 
   implementation and James Zwyer for his contribution to the use case 
   scenarios. 
    
Author's Addresses 
    
   Kyle Meadors 
   Drummond Group Inc. 
   4700 Bryant Irvin Court, Suite 303 
   Fort Worth, TX  76107 USA 
   Email: kyle <at> drummondgroup.com 
     
   Dale Moberg 
   Cyclone Commerce 
   8388 E. Hartford Drive, Suite 100 
   Scottsdale, AZ  85255 USA 
   Email: dmoberg <at> cyclonecommerce.com 
     
Appendix 
    
   A.1 EDIINT Certificate Exchange XML Schema 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <!--W3C Schema generated by XMLSPY v2004 rel. 3 U 
   (http://www.xmlspy.com)--> 
   <xs:schema 
   targetNamespace="http://www.ietf.org/schemas/EDIINTCertificateExchang
   e.xsd" 
   xmlns:tns="http://www.ietf.org/schemas/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> 
            <xs:sequence> 
               <xs:element ref="tns:TradingPartnerInfo"/> 
               <xs:element name="TrustResponse"  
                   type="tns:TrustResponseType" maxOccurs="unbounded"/> 
 
 
Meadors, Moberg          Expires - March 2005                [Page 20] 


Draft                       CEM for EDIINT              September 2004 
 
 
            </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> 
      <!-- should this be an enumeration or left open --> 
      <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 ref="ds:X509Data"/> 
         </xs:sequence> 
      </xs:complexType> 
      <xs:complexType name="TrustChainType"> 
         <xs:sequence> 
 
 
Meadors, Moberg          Expires - March 2005                [Page 21] 


Draft                       CEM for EDIINT              September 2004 
 
 
            <xs:element ref="ds:X509Data"/> 
         </xs:sequence> 
      </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:element name="TrustChain" type="tns:TrustChainType"   
                 minOccurs=”0”/> 
         </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" encoding="UTF-8" standalone="yes"?> 
   <EDIINTCertificateExchangeRequest 
   xmlns="http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd" 
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.ietf.org/schemas/EDIINTCertificateExch
   ange.xsd EDIINTCertificateExchange.xsd"> 
      <TradingPartnerInfo> 
         <Name qualifier="ZZ">Somewhere.com</Name> 
         <MessageOriginated>2005-05-17T07:21:00-03:00 
         </MessageOriginated>            
         </TradingPartnerInfo> 
      <TrustRequest> 
         <CertUsage>digitalSignature</CertUsage> 
         <RespondByDate>2005-05-20T07:21:00-03:00</RespondByDate> 
         <ResponseURL>http://somewhere.com/someplace</ResponseURL> 
         <EndEntity> 
            <CertificateIdentifier> 
               <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT; 
                   L=New York; S=New York; C=US</ds:X509IssuerName> 
               <ds:X509SerialNumber>123454321</ds:X509SerialNumber> 
            </CertificateIdentifier> 
            <ds:X509Data> 
               <!--Signer cert --> 
 
 
Meadors, Moberg          Expires - March 2005                [Page 22] 


Draft                       CEM for EDIINT              September 2004 
 
 
               <ds:X509Certificate>MIICXTCCA..</ds:X509Certificate> 
            </ds:X509Data> 
         </EndEntity> 
         <TrustChain> 
            <ds:X509Data> 
               <!-- Intermediate cert --> 
               <ds:X509Certificate>MIICPzCCA...</ds:X509Certificate> 
               <!-- Root cert  --> 
               <ds:X509Certificate>MIICSTCCA...</ds:X509Certificate> 
            </ds:X509Data> 
         </TrustChain> 
      </TrustRequest> 
      <TrustRequest> 
         <CertUsage>keyEncipherment</CertUsage> 
         <RespondByDate>2005-05-20T07:21:00-03:00</RespondByDate> 
         <ResponseURL>http://foo.com/path</ResponseURL> 
         <EndEntity> 
            <CertificateIdentifier> 
                  <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT; 
                     L=New York; S=New York; C=US</ds:X509IssuerName> 
                  <ds:X509SerialNumber>987654321</ds:X509SerialNumber> 
            </CertificateIdentifier> 
            <ds:X509Data> 
              <!--Key exchange encryption cert --> 
                    <ds:X509Certificate>MIICXTCCA..</ds:X509Certificate> 
            </ds:X509Data> 
         </EndEntity> 
         <TrustChain> 
            <ds:X509Data> 
               <!-- Intermediate cert --> 
               <ds:X509Certificate>MIICPzCCA...</ds:X509Certificate> 
               <!-- Root cert  --> 
               <ds:X509Certificate>MIICSTCCA...</ds:X509Certificate> 
            </ds:X509Data> 
         </TrustChain> 
      </TrustRequest> 
   </EDIINTCertificateExchangeRequest> 
    
   A.3 Example of EDIINT Certificate Exchange Response XML 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <EDIINTCertificateExchangeResponse 
   xmlns="http://www.ietf.org/schemas/EDIINTCertificateExchange.xsd" 
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.ietf.org/schemas/EDIINTCertificateExch
   ange.xsd EDIINTCertificateExchange.xsd"> 
      <TrustResponse> 
         <CertStatus>Rejected</CertStatus> 
 
 
Meadors, Moberg          Expires - March 2005                [Page 23] 


Draft                       CEM for EDIINT              September 2004 
 
 
         <ReasonForRejection>Invalid KeyUsage  
            extension</ReasonForRejection> 
         <CertificateReference> 
            <ds:X509IssuerName>CN=EDIINT WG; O=IETF; OU=EDIINT; 
                 L=New York; S=New York; C=US</ds:X509IssuerName> 
            <ds:X509SerialNumber>123454321</ds:X509SerialNumber> 
         </CertificateReference> 
      </TrustResponse> 
      <TrustResponse> 
         <CertStatus>Accepted</CertStatus> 
         <CertificateReference> 
            <ds:X509IssuerName>CN=US;O=Somewhere.com</ds:X509IssuerName> 
            <ds:X509SerialNumber>987654321</ds:X509SerialNumber> 
         </CertificateReference> 
      </TrustResponse> 
      </EDIINTCertificateExchangeResponse> 

































 
 
Meadors, Moberg          Expires - March 2005                [Page 24] 



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
 




Gmane