headers
Scott Hollenbeck | 4 Oct 2004 18:43

FW: draft-ediint-certificate-exchange-00


WG members:

Some follow-up on my own notes from a week or so ago.  One of the security
area directors also has questions about the ediint-certificate-exchange I-D.
Would anyone care to respond to Russ' comment about PKIX overlap?

-Scott-

-----Original Message-----
From: Russ Housley [mailto:housley <at> vigilsec.com] 
Sent: Wednesday, September 29, 2004 9:43 AM
Subject: draft-ediint-certificate-exchange-00

The Abstract of this document says: "... EDIINT Certificate Exchange 
Messaging provides the format and means to effectively exchange 
certificates for use within trading partner relationships. ..."

This seems to overlap with the charter of PKIX WG, and I do not think that 
an additional mechanism for certificate distribution is desirable.

Can someone provide background that would make me fee comfortable about 
this work?

Russ
Permalink | Reply | 2 comments |
headers
Internet-Drafts | 6 Oct 2004 21:32
Picon
Favicon

I-D ACTION:draft-ietf-ediint-as2-17.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
	Author(s)	: D. Moberg, R. Drummond
	Filename	: draft-ietf-ediint-as2-17.txt
	Pages		: 42
	Date		: 2004-10-6
	
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-17.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.

Internet-Drafts are also available by anonymous FTP. Login with the username
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 6 Oct 2004 23:25
Picon
Favicon

Last Call: 'MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet Using HTTP' to Proposed Standard


The IESG has received a request from the Electronic Data Interchange-Internet 
Integration WG to consider the following document:

- 'MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet 
   Using HTTP '
   <draft-ietf-ediint-as2-17.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2004-10-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-17.txt
Permalink | Reply | 0 comments |
headers
Kyle Meadors | 13 Oct 2004 22:53

RE: draft-ediint-certificate-exchange-00


This is from Dale Moberg, co-author of the CEM draft.

In reply to:

"Some follow-up on my own notes from a week or so ago.  One of the security
area directors also has questions about the ediint-certificate-exchange I-D.

"Would anyone care to respond to Russ' comment about PKIX overlap? 
 -Scott-

"The Abstract of this document says: "... EDIINT Certificate Exchange
Messaging provides the format and means to effectively exchange certificates
for use within trading partner relationships. ..."

"This seems to overlap with the charter of PKIX WG, and I do not think that
an additional mechanism for certificate distribution is desirable.

===

Here is some context that should indicate how ediint-certificate-exchange
differs from the PKIX CMP and related initiatives.

===

Here is my understanding of EDIINT conventions and requirements and its
relation to CMP.

This is from a developer's perspective but also from one who helped users
formulate the draft in EDIINT about certificate exchange.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Bigelow | 19 Oct 2004 20:58
Favicon

Certificate Exchange - Use Cases


Comment on draft-ediint-certificate-exchange-00.txt.

I have 2 comments on section 4.

1. The beginning of section 4 says that it is "only illustrative".  However, section 4 contains several uses
of MUST and SHOULD, which are prescriptive words.  These words should be in lower case, to indicate that
they are not stating additional requirements, or different language should be used.
2. Section 4.2 does state some requirements that were not stated earlier in section 2 or 3.  These
requirements should be in section 2.  The requirements in 4.2 on accepting signed messages should be modified.

1.
In 4.1.1 Step 1, change
   In the case of an encryption certificate, the initiator MUST be 
   immediately ready to receive documents encrypted with the new 
   certificate. 
to
   In the case of an encryption certificate, the initiator is
   immediately ready to receive documents encrypted with the new 
   certificate. 

Change the first paragraph of 4.1.2 to
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns a correct MDN.  If the message is a proper 
   AS2 document, the receiver automatically accepts or rejects the 
   new certificate(s) or requires manual intervention. If the certificate 
   is automatically accepted or rejected, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  Since the trading relationship could be hindered if 
   action is not taken prior to the RespondByDate, manual intervention
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Bigelow | 19 Oct 2004 20:28
Favicon

Certificate Exchange - Negative MDN


Comment on draft-ediint-certificate-exchange-00.txt.

Please clarify the behavior in the case of a negative MDN.

After this paragraph of section 2.3
   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. 

add this
	If the recipient rejects the Request message at the transport level, the recipient MUST return a negative
MDN if an MDN is requested, and the recipient MUST NOT return a CEM Response.  The recipient has rejected the
Request at the transport level, and does not process the Request further.  The initiator's behavior when
receiving a negative MDN is not defined.  The initiator MAY retransmit the Request, after taking some
action to correct the transport problem, or it may take some other action.

At the end of section 2.3, add
	If the initiator rejects the Response message at the transport level, the initiator MUST return a
negative MDN if an MDN is requested.  The initiator has rejected the Response at the transport level, and
does not process the Response further.  The recipient's behavior when receiving a negative MDN is not
defined.  The recipient MAY retransmit the Response, after taking some action to correct the transport problem.
Permalink | Reply | 0 comments |
headers
Scott Hollenbeck | 29 Oct 2004 14:00

RE: ID Tracker State Update Notice: draft-ietf-ediint-as2


>  what do I have to do?.... .anything? Hey thanks from all of 
> us for being an
> AD.... Imagine how much work it is... rik

Rik,

You can find all of the IESG review comments in the public I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi

I've included them here for completeness.  All marked "Discuss" MUST be
addressed; those marked "Comment" SHOULD be addressed.  If you have any
questions about any of them you should contact the appropriate AD with
follow-up questions.  Each will have to review and approve any updates to
get the document to move forward.

-Scott-
----------
Harald Alvestrand:
Comment:
[2004-10-28] Reviewed by John Loughney, Gen-ART

His review:

Formatting problems are so severe, I'd recommend a revision before
considering
this draft.  The text is somewhat dense and hard to parse, so the formatting
problems really make this impossible to read.  I can try to re-read the
draft
(Continue reading)

Permalink | Reply | 0 comments |

Gmane