MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
draft-ietf-ediint-as2-20

[Ballot comment]
I still find the signed receipt discussion confusing.  In Section 1.1,
  it would be very helpful to pointing out that the returned MIC value
  inside the MDN must be the same as the digest of the original message.
  I strongly believe that this needs to be explained early in the
  document.

[Ballot discuss]
The Security Considerations need to be revised.  Please change:
  >
  > In any case, records of the message content, its security basis,
  > and the digest value should be retained for the NRR process.
  >
  To:
  >
  > In any case, records of the message content, its security basis,
  > and the digest value needs to be retained for the NRR process.
  >
  Also, this document allows for the return of signed receipt that does
  not fulfill the NRR service, that is a signed receipt can be
  returned without the Returned-content-MIC.  There should be a discussion
  of this situation, and I would prefer a recommendation against using it.

[Ballot discuss]
I still find the signed receipt discussion confusing.  In Section 1.1,
  it would be very helpful to pointing out that the returned MIC value
  inside the MDN must be the same as the digest of the original message.
  I strongly believe that this needs to be explained early in the
  document.

  The Security Considerations need to be revised.  Please change:
  >
  > In any case, records of the message content, its security basis,
  > and the digest value should be retained for the NRR process.
  >
  To:
  >
  > In any case, records of the message content, its security basis,
  > and the digest value needs to be retained for the NRR process.
  >
  Also, this document allows for the return of signed receipt that does
  not fulfill the NRR service, that is a signed receipt can be
  returned without the Returned-content-MIC.

[Ballot comment]
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
for technical comments and will update this review if I find anything.

In summary, I'd issue a discuss on this because of formatting - I doubt this passes
the ID-Nits.

John

Major
1) What is AS2?  This needs to be explained somewhere.

Questions
1) The introduction discusses the relationship of this draft to other EDI RFCs.
  Does this document update / obsolete any of these RFCs? If so, it should mention
  it explicitly.

Nits
1) Header & footer on page 1 should be removed.
2) Lots of editing problems - bullet lists should be reformatted,
  sections should be left justified, blank lines should be inserted
  after section titles, ToC should list page numbers, bulleted lists
  have formatting problems (page 6, for example).

[Ballot discuss]
I find the signed receipt discussion confusing.  Sometimes, it seems
  that the signed receipt mechanism defined in RFC 2634 meets the needs
  of EDI and other times it appears that some EDI-specific content is
  needed.  In my opinion, the cryptographic binding provided by the
  mechanism in RFC 2634 is highly desirable.

  Section 1.1 says:
  :
  : Non-repudiation of receipt (NRR) - NRR is a "legal event" that occurs
  : when the original sender of an signed EDI/EC interchange has verified
  : the signed receipt coming back from the receiver. NRR IS NOT a
  : functional or a technical message.
  :
  This is not sufficient.  One must also match the values in the signed
  receipt against the retained copy of the original as is discussed in
  section 7.1.  Pointing out that the returned MIC value inside the MDN
  must be the same as the digest of the original message early in the
  document would greatly help the reader.

  Section 2.3.1, 1st bullet, says:
  :
  : -The organization sending EDI/EC data signs and encrypts the data   
  :  using S/MIME. In addition, the message will request a signed
  :  receipt to be returned to the sender of the message.
  :
  The sender must keep a copy of the original message or the message-id
  and digest value of the original message.  The receipt validation
  cannot be performed without these values.

  Section 2.3.1, 3rd paragraph says:
  :
  : The above describes functionality which, if implemented, will
  : satisfy all security requirements and implement nonrepudiation
  : of receipt for the exchange.
  :
  Section 1.1 says a signedReceipt is a receipt signed with a
  digital signature.  Then, section 7.4.3 says that a signed
  receipt does not have to include the Returned-content-MIC.
  Without the Returned-content-MIC NRR is unachievable.

  Section 2.3.2, 2nd paragraph, 2nd sentence says:
  :
  : NRR refers to a legal event which occurs only when the
  : original sender of an interchange has verified the signed
  : receipt coming back from recipient of the message.
  :
  This is not sufficient.  I suggest:

    NRR refers to a legal event which occurs only when the
    original sender of an interchange has verified the
    signature on the signed receipt as coming from the
    recipient and the returned MIC value inside the MDN is
    the same as the digest of the original message.

  Section 2.4.2 says:
  :
  : If a signed receipt notification is requested however, a MIC value
  : is REQUIRED as part of the returned receipt, unless an error
  : condition occurs in which a MIC value cannot be returned.  In error
  : cases, an unsigned receipt or MDN SHOULD be returned with the
  : correct "disposition modifier" error value.
  :
  And, Section 7.3.1 says:
  :
  : When a request for a signed receipt is made, but there is an error
  : in processing the contents of the message, a signed receipt MUST
  : still be returned. The request for a signed receipt SHALL still be
  : honored, though the transaction itself may not be valid. The reason
  : for why the contents could not be processed MUST be set in the
  : "disposition-field".
  :
  These seem contradictory.  The first says that a MIC is not required
  if there is an error, but the second says that a signed receipt MUST
  be returned.

  Section 7.3.1 says:
  :
  : When a request for a signed receipt is made, the "Received-content-
  : MIC" MUST always be returned to the requester.
  :
  And, Section 7.4.3 says:
  :
  : This field [in reference to the Received-content-MIC] is set only
  : when the contents of the message are processed successfully.
  :
  These seem contradictory.  The first says that a MIC always returned,
  but the second says that the MIC is only returned if the processing
  is successful.

  The Security Considerations needs to cover addition topics:

  - The NRR service supported by this document relies on the
    originator retaining a copy of either the original message or
    the MIC of the original message.

  - This document allows for the return of signed receipt that does
    not fulfill the NRR service, that is a signed receipt can be
    returned without the Returned-content-MIC.

[Ballot comment]
Please use include a hyphen in "non-repudiation" throughout the
  document. This is the accepted spelling when referring to the security
  service.

  In section 2.3.1, 3rd bullet: s/message,indicating/message, indicating/

  In section 2.4.2, Permutation Summary, please add the following options,
  as the previous paragraphs indicate that if an error occurs an unsigned
  receipt can be returned:

    1) Sender sends un-encrypted data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    2) Sender sends encrypted data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    3) Sender sends signed data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    4) Sender sends encrypted and signed data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

  In section 7.4.3: s/algorith/algorithm/

  In section 7.6: s/varydepending/vary depending/

  Please add a reference for S/MIME Version 3 Certificate Handling, it is
  referred to in Security Considerations.  I would like for this to be
  a normative reference, with the following text appearing in the
  beginning of the Security Considerations:

    The following are the additional security considerations to those
    listed in [4] and [X]:  The following certificate types MUST ...

  Where [X] refers to the S/MIME Version 3 Certificate Handling document.

FOLLOW-UP LAST CALL COMMENTS:
Hi Dale,

1) The registration of the HTTP Headers should be specifically
stated in the IANA Considerations section.  Other than the
2 registries mentioned below, I don't see any other "http headers"
registry.  Do you know what RFC would have defined such a
registry?

2) You are right!  If you want this document to refer to
those registrations, you can say that RFC3335 has registered
them.  Otherwise, there should not be instructions to the
IANA to register these in this document.

Thanks,

Michelle
IANA

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Monday, October 25, 2004 10:20 AM
To: Michelle S. Cotton
Cc: rvd2@drummondgroup.com; Terry Harding
Subject: RE: Last Call: 'MIME-based Secure Peer-to-Peer Business Data
Interchange over the Internet Using HTTP' to Proposed Standard


Hi Michelle,

A couple of quick questions:

1. AS2 requires three HTTP headers: -Version, AS2-To, AS2-From
Is there an Icann registry for HTTP headers that we can register these
in?

2. AS1 has apparently registered the mdn disposition extensions.
Should we also do this for AS2 or would this be redundant and/or
confusing?

Thanks

Dale Moberg



-----Original Message-----
From: Terry Harding
Sent: Monday, October 25, 2004 10:13 AM
To: Dale Moberg
Cc: 'rvd2@drummondgroup.com'
Subject: RE: Last Call: 'MIME-based Secure Peer-to-Peer Business Data
Interchange over the Internet Using HTTP' to Proposed Standard

You probably will unless you precede the headers with an "x-"

AS1 did register the required mdn disposition extensions.

-----Original Message-----
From: Dale Moberg
Sent: Monday, October 25, 2004 10:04 AM
To: Terry Harding
Cc: rvd2@drummondgroup.com
Subject: FW: Last Call: 'MIME-based Secure Peer-to-Peer Business Data
Interchange over the Internet Using HTTP' to Proposed Standard

Hi Terry and rik,

Won't we also need to register headers like AS2-Version, AS2-To,
AS2-From?

And did AS1 already register the stuff Michelle mentions below?

Thanks
Dale

[Ballot discuss]
I think the asynchronous MDNs text is confusing, and I think it could be cleared up
fairly easily (at least I hope so!).  First, my understanding is that an asynchronous
MDN is essentially any MDN which can be later correlated to the original message.
As the document notes, this means that the MDN must contain enough  data
to ensure that it uniquely identifies the original message.

The document refers to RFC 3789 on MDNs, but it seems to
want only the definition of message/disposition-notification from that; even
in the case of SMTP-based asynchronous notifications, the document should
look to RFC 3355?  Are there other aspects of 3789 that are needed for this?
If not, can the limitation be clarified?

The diagram in 7.2 contains:

  Asynchronous AS2-MDN
  [C] ----( connect )----> [S]
  [C] -----( send )------> [S]  [HTTP Request [AS2-Message]]
  [C] <---( receive )----- [S]  [HTTP Response]
   
  [C]*<---( connect )----- [S]
  [C] <--- ( send )------- [S]  [HTTP Request [AS2-MDN]]
  [C] ----( receive )----> [S]  [HTTP Response]
  * Note: An AS2-MDN may be directed to a different host than that of
  the sender of the AS2 message and may utilize a different transfer
  protocol than that used to send the original AS2 message.

The server initiates an HTTP connection to the client?  I think this
actually confuses "client/server" roles with "party1/party2" roles.
If [S] is actually "party2", this makes sense, but [C]/"party1" must
be an HTTP server, capable of handling the HTTP Request.

An additional issue here is that the document doesn't seem to say
whether the HTTP Request [AS2-MDN] is sent via a POST request or
something else (e.g. PUT).  I think POST, but this should be clarified.

I'm also a bit concerned about how the mail-address in Disposition-notification-to
is being treated.  If it MUST be present and MUST be ignored, why not give
it a specific address in .invalid or recommend addresses in .invalid for use
here?

[Ballot discuss]
Nit: there are two sections numbered 1.1

Nit: in the second of those sections, there's text that speaks of MD5's small key size.  MD5 is a hash algorithm and doesn't have keys.  I believe what was meant is "short block size".  If possible, I'd leave MD5 out; if you must leave it in, say that it SHOULD NOT be used except for compatibility, because of cryptographic weaknesses in MD5.

4.1: "AS" is never expanded

There's no discussion of replay detection or prevention, nor of checking the message date to see if it's stale.  I assume, from the text on reusing Message-IDs, that they could function as replay detectors; in that case, some notion of when a message is stale should be included, so that the list of previously-seen Message-IDs can be pruned.

IANA LAST CALL COMMENTS:
Upon approval of this document, we understand the IANA will
register the following:
2 content disposition parameters in the "Mail Content Disposition Parameters"
registry found at:


1 MDN extension field name in the following registry:

Info from the chair before starting IETF last call:

1. Have the chairs personally reviewed this version of the ID and do they
believe this ID is sufficiently baked to forward to the IESG for
publication?

Rik: We completely rewrote the document 18 months ago because we did not
think it was clear enough. It is clear now in that over 30 vendors have
implemented with few to none perceptional or interpretation problems.

2. Has the document had adequate review from both key WG members and key
non-WG members? Do you have any concerns about the depth or breadth of the
reviews that have been performed?

Rik: Thirty + developers have implemented the software described in the
document -- many from the WG and others not from the WG. I would say is has
very in-depth review.

3. Do you have concerns that the document needs more review from a
particular (broader) perspective? Rik: No

4. Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or whether there
really is a need for it, etc., but at the same time these issues have been
discussed in the WG and the WG has indicated it wishes to advance the
document anyway.

Rik: I do not have any concerns with the document. Its coverage of the
information necessary to implement the AS2 standard is "necessary and
sufficient" -- no more or less in my view.

5. How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent,
or does the WG as a whole understand and agree with it?

Rik: Solid consensus demonstrated by 30+ implementations in multimillion
dollar software products. It has wide concurrence in the WG. It has been
implemented across the world. I am not aware of an active or previously
active member that has any issues with it.

6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

Rik: No

7. Have the chairs verified that the document adheres to _all_ of the ID
nits? (see http://www.ietf.org/ID-nits.html,
http://ietf.levkowetz.com/tools/idnits/idnits.pyht)

Rik: we seriously believe so. We have made a significant effort to ensure it
is so.

8. Does the document a) split references into normative/informative, and
b) are there normative references to IDs, where the IDs are not also ready
for advancement or are otherwise in an unclear state?

Rik: Yes

9. Please write a few sentences summarizing the working group's experience
with this document.  Are there any known implementations?

Rik: There are 30+ software companies who have implemented this document.
Companies from India, Europe, USA, Canada and Japan have implemented to name
a few. There are tens of thousands of production implementations carrying
ebusiness information between companies especially in the retail and
consumer packaged goods environments. Wal*mart, target, and many others
across the world have chosen it as their preferred internet based ebusiness
standard for supply chain related information movement.

State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by freed