Re: WG Last Call for AS2

Rik Drummond wrote:

Please review the AS2 document and make comments. It is finished and ready
for the WG last call. Please make comments by the end of April. May 1, 2004
I would like to formally submit it to IETF for consideration as an RFC.

Best regards, Rik Drummond
EDIINT WG Chair

Some comments (many of the same comments I made on RFC 3335):

- Section 1 - References - r RFC 2630/RFC 3369/

- Section 2.1 - 3rd sentence says "This request/reply transactional
interchange provides secure, reliable, and authenticated
transport for EDI or other business data which use HTTP." I'm not sure
what the "This" refers to - is it the "request-uri" or mdn/multipart
report, signed/unsiged, etc. from the previous sentence? If it's the
laundry list of things then the sentence should say "This request/reply
transactional
interchange could provide secure, reliable, and authenticated
transport for EDI or other business data which use HTTP." I stress the
could because if it's exchanging something unsigned then it's not
authenicatable.

- Section 2.1 - last sentence - Keeping auditable records of the
transmission - are you suggesting the entire transmission is retained?
Also, I guess I don't understand what you mean when you say you can
audit the "authentication"?

- Section 2.3.1 - Signed Receipt definition - Same comment as a I
had on RFC 3335 - CMS has a "signed receipt" service too. I think to
avoid confusion you should add "The signed Receipt service defined
herein is NOT the same as the S/MIME Extended Security Service (ESS)
Signed Receipt service as defined in ESS [RFC2634]."

- Section 2.3.1 - Synchronous and Asynchronous receipt - add
periods
to end of sentences.

- Section 2.3.1 - NRR (same comment as I had on RFC 3335) - I think
the NRR definition needs to be tweaked a bit. It's not just that
verification of the signed receipt. Rationale:

a. It's only really a signed receipt service if the original message
was also signed.

b. It's not just the signing of the receipt that gives you the service
it's that you included the mic from the original message in the signed
MDN.

- Section 2.3.1 - S/MIME - r Cryptographic signature/digital
signature.

- Section 2.3.1 - SHA-1, MD5, and UA - add period to end of
sentences.

- Section 2.3.1 - SHA-1 and MD5 - If the support requirements are
specified here then there ought to MUSTs and MAYs in the definitions.
If the requirements are specified elsewhere remove the last sentence of
each definition.

- Section 2.3.2 - If this section is copied directly from RFC 3335
can we just point there? If not I've got comments on the section.

- Section 2.3.3 - Reference to NRR see comment from above about NRR
definition.

- Section 2.4.2 - Reference to RFC 2630 replace with RFC 3369

- Section 2.4.2 - Hash function requirements: If SHA-1 is a
RECOMMENDED - what is the hash function that is required? 2633 makes
SHA-1 a MUST on both orig/rec? The requirements language is
incorrect for the incoming hash functions - need to use MAY/SHOULD to
explicitly state the processing requirement.

- Section 2.4.2 - Permutation Summary - Should the error cases be
included or at least alluded to? ie. sender asked for signed receipt,
recipient unable to process and send back an unsigned receipt?

- Section 3.7 - r 2630/3369/

- Section 4.2 - MIME Content support - It says "While all MIME
contents SHOULD be supported." I think that you're going to have a
devil of a time testing that - you ought to at least say where the list
of "all" is coming from - how are you going to test some privately
defined content?

- Section 5.1 - 1st para 3rd sentence - should the "should" be
"SHOULD"?

- Section 5.1 - 3rd para last sentence - r However,
encrypted message bodies are not prohibited/However, encrypted message
bodies sent using TLS is permitted.

- Section 5.2.1- 5.5 - It is unclear whether you are describing
requirements or summarizing what is done. Must and shoulds should be
"MUST" and "SHOULDs"? Recommend search for each instance of a
requirements word and verifying whether it ought to be capitalized - if
not maybe rephrasing sentence to not use lowercase word would be best?

- Section 6.0 - 1st sentence - If these are requirements r The
following are to be included/The following headers MUST be included/

- Section 6.1 - AS2-Version 1.0 2nd paragraph - "WILL" is not
keyword ... replace with "MUST"?

- Section 7.1 - To support non repudiation of receipt the receipt
generator also needs to retain a copy of the receipt which they later
use to refute the originator's claim that they never got the receipt.

- Section 7.1 - Required support for signed receipts - should there
be requirements for the errors in processing?

- Section 7.1 - trading partner UA's requirements #3 - I guess I'd
like to see more about verifying the signer's certificate up to a trust
point. Sounds like all you MUST do is verify the math on the cert.

- Section 7.3 - 2nd para - "WILL BE" is not
keyword ... replace with "MUST be"?

- Section 7.3 - para after micalgs - "NOT" is not a keyword replace
with "MUST not be".

- Section 7.3.1 - Rule #2 - If the recipient can't support the
protocol or micalg how is it going to be able to send a receipt back?
Seems like it shouldn't be a "SHOULD".

- Section 7.3.1 - Rules - I think it would be clearer if you had
one rule for each case.

- Section 7.3.1 - Error processing - I do not understand how you
can claim that a returned signed receipt gives you all these services
in 7.1 but then say if there's a error in processing you still have to
send back a signed receipt - this strikes me as wrong. I think 7.1
ought to at least say assuming the MDN is not received with a
disposition-notification of failed (or whatever it is).

- Section 7.4.4 - #9 - "MAY NOT" is not a valid combination for
keywords.

- Section 7.5.2 - 2nd para 2nd sentence - r MUST not/MUST NOT/

- Section 7.5.3 - There are lots of "shoulds" that sound like they
should be "SHOULD"s.

- Section 7.5.3-4 - There seems to be an inconsistency between
7.3.1 and 7.5.3-4. &.3.1 says that reason for processing the
contents could not be processed MUST be included. Then 7.5.3 and 7.5.4
say that they "should" be included. I believe that the "should"s ought
to be "MUST"s.

- Section 9 - S/MIMEv2 security considerations - Since the RFC you
reference are the version 3 specs I'd suggest pointing to the S/MIMEv3
security considerations.

- Section 9 - I think you have to add that signed receipts may be
returned even though processing failed - to me this is a huge omission.

spt