Thanks! Rik
-----Original Message-----
From: Sean P. Turner [mailto:turners@xxxxxxxx]
Sent: Tuesday, April 13, 2004 3:07 PM
To: Rik Drummond
Cc: ietf-ediint@xxxxxxx
Subject: 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):
1. Section 1 - References - r RFC 2630/RFC 3369/
2. 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.
3. 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"?
4. 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]."
5. Section 2.3.1 - Synchronous and Asynchronous receipt - add periods
to end of sentences.
6. 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.
7. Section 2.3.1 - S/MIME - r Cryptographic signature/digital
signature.
8. Section 2.3.1 - SHA-1, MD5, and UA - add period to end of sentences.
9. 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.
10. 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.
11. Section 2.3.3 - Reference to NRR see comment from above about NRR
definition.
12. Section 2.4.2 - Reference to RFC 2630 replace with RFC 3369
13. 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.
14. 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?
15. Section 3.7 - r 2630/3369/
16. 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?
17. Section 5.1 - 1st para 3rd sentence - should the "should" be
"SHOULD"?
18. Section 5.1 - 3rd para last sentence - r However, encrypted message
bodies are not prohibited/However, encrypted message bodies sent using TLS
is permitted.
19. 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?
20. Section 6.0 - 1st sentence - If these are requirements r The
following are to be included/The following headers MUST be included/
21. Section 6.1 - AS2-Version 1.0 2nd paragraph - "WILL" is not keyword
... replace with "MUST"?
22. 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.
23. Section 7.1 - Required support for signed receipts - should there be
requirements for the errors in processing?
24. 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.
25. Section 7.3 - 2nd para - "WILL BE" is not keyword ... replace with
"MUST be"?
26. Section 7.3 - para after micalgs - "NOT" is not a keyword replace
with "MUST not be".
27. 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".
28. Section 7.3.1 - Rules - I think it would be clearer if you had one
rule for each case.
29. 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).
30. Section 7.4.4 - #9 - "MAY NOT" is not a valid combination for
keywords.
31. Section 7.5.2 - 2nd para 2nd sentence - r MUST not/MUST NOT/
32. Section 7.5.3 - There are lots of "shoulds" that sound like they
should be "SHOULD"s.
33. 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.
34. 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.
35. 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
|
