Thanks Terry - Just trying to help.

Terry Harding wrote:

Sean, Thank you for taking the time to review RFC 3335 and posting your comments. I agree with your comments and believe it may be time to clarify some of the wording in this RFC and the AS2, AS3 drafts. The original draft for RFC 3335 was created back in 1996 and since then several companies have implemented this RFC and AS2 in their B2B products. Again thanks for the constructive comments and i will submit my proposed changes based upon your comments to the EDIINT WG for their approval. Terry Harding Cyclone Commerce ----- Original Message ----- From: "Sean P. Turner" <turners <at> ieca.com> To: <ietf-ediint <at> imc.org> Cc: "Housley, Russ" <housley <at> vigilsec.com> Sent: Thursday, March 25, 2004 12:12 PM Subject: Comments on RFC 3335

All, This is my first post to this list so please take all my comments as constructive. And I apologize for this being so long. A recent message by Alberti on the S/MIME WG list compelled me to go off and read RFC3335. I ended up with some major and minor concerns on RFC 3335. The major ones deal with: - processing requirements for signed receipt requester (#28). I may have missed this (I thought I did a pretty good job of scouring the documents for MUSTs), but I can't seem to find where requirements for signed receipt requester to process the returned signed receipt. - processing requirements for errors (#31 and 32). Again I may have missed it or misunderstood it, but I think the requirements for the error processing could result in a recipient having an error, generating a signed receipt, but not supporting the fields necessary to indicate that processing failed in the signed receipt that is returned. - defining "signed receipts" differently that S/MIME ESS. Since S/MIME has a specific service called "signed receipts" I think it is really confusing to say that a signed MDN is also a "signed receipt" - without at least saying somewhere in the document that the service provided by RFC 3335 is not the same as in ESS. - retaining copies of original message/signed receipt. There are lots of places where it says what's needed to get the NRR service but they never say that the originator has to retain a copy of the original signed message or that the recipient has to retain a copy of the signed receipt. I had 38 comments (attached below) most were editorial, but the major ones I noted above I believe would result in a compliant implementation not providing a true NRR service. I think that if my comments are not refuted (and I hope they are) that RFC 3335 needs to be obsoleted and new ID fixing the issues needs to be produced. I tried to provide rationale for most of the comments, but some were either straight forward or were questions. I am curious to see what people think of my comments and how they ought to be addressed. Cheers - spt -----------comments--------------- 1. Abstract, 3rd sentence – Replace existing sentence with "Data authentication, integrity, non-repudiation of origin, and confidentiality for the interchanges can be obtained by using S/MIME or PGP security protocols." Rationale: a. Confidentiality is the common name of the service provide via encryption (in CMS) vice privacy. b. CMS and S/MIME are not the same thing, S/MIME is a profile of CMS. c. S/MIME and PGP, I think, are security protocols vice body parts. d. Purposely used the word "can" because if you don't pick the right services you don't get the services. 2. Abstract, 4th sentence – Replace existing sentence with "Interchanges can request message digest notifications (MDNs), which can also be provided data authentication, integrity, and non-repudiation of origin, to ensure the original interchange was received." Rationale: a. I think the rewording more closely aligns with the previous sentence. b. "Authenticated acknowledgments" is confusing because a) the rest of the document talks about receipts b) an acknowledgment to me is a human types message while a receipt is automatic c) to me an acknowledgment is something some types that says something like "right I got your message and I'm going to do what it says." c. Note that the S/MIME WG has a Signed Receipt service defined in Extended Security Services (ESS) [RFC2634] – it is definitely not the same thing you're talking about. 3. 1, 2nd sentence – Replace existing sentence with "This document expands on RFC 1767 to specify how to use other protocols to support data security features for business data interchanges and message digest notifications specifically data confidentiality, authentication, integrity, non-repudiation of origin." a. "confidentiality" is the service as described in PGP and S/MIME. b. What is specified herein is the 4 services for interchanges and MDNs. Later explain that by providing non-repudiation of origin (digital signatures) to an MDN the recipient of the MDN is provided non-repudiation of receipt. 4. 1, 1st para 3rd sentence and 2nd para 1st sentence – Signed Receipts from ESS, which was a standard in 1999, was reinvented – why? Was the idea to use the same concept for both PGP and S/MIME? 5. 2.2.1, Receipt – Remove "functional." Rational: Word is unneeded. 6. 2.2.1, Signed Receipt – Add the following "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]." 7. 2.2.1, NRR – 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.

c. The last sentence is unneeded. Additionally a "functional message" is not defined anywhere. 8. 2.2.1, S/MIME: Replace with "Digital envelope security based on RSAsig, DSA, 3DES, and RSAenc standards, integrated with MIME Security Mutliparts." Rationale: Aligns definitions of PGP and S/MIME. 9. 2.2.2: Why are the other combinations listed? 2.2.2 should be elevated to be 2.3, 2.2.3 renumbered to 2.2.2. The new 2.3 should include the combinations of signed/encrypted and unsigned receipt/signed receipt that are supported and what services are supported when the services are invoked. 10. 2.2.2: Add to 1st step "The sending organization retains copy of signed original message." Rationale: You cannot provide non-repudiation of origin or NRR without at least retaining a copy of the original signed message! 11. 2.2.2: Add to 3rd step 1st sentence - "….in the form of a signed message digest notification message." Rationale: It's got to be a signed MDN if you're going to get your signed receipt. 12. 2.2.2, last para: Replace "would satisfy all security requirements" with "would provide data confidentiality, authentication, integrity, non-repudiation of origin, and NRR." Rationale: "all security requirements" is incorrect. 13. 2.2.2: Add to 3rd step "The signed receipt is saved by the originating organization." Rationale: You cannot provide non-repudiation of origin or NRR without at least retaining a copy of the signed receipt. 14. 2.2.2, last para: move it to the 2nd paragraph. Rationale: Provides a better stage that that following is only optional. 15. 2.2.3, 1st bullet: Add "digital" in front of the last word. 16. 2.2.3, 3rd bullet: Replace "may" and "may not" with "MAY" and "MAY not" respectively Rationale: Seems like these ought to use capitols. 17. 2.2.3, last para, 1st sentence: Add " at the end of the 1st sentence. 18. 2.3.2, Encrypted or Unencrypted: Replace "…either be un-protected or protected by means of encryption." with "… is or is not encrypted." Rationale: Wording is better aligns with following definition. 19. 2.3.2, Formatting choices, 2nd para: Replace "2633/2630" with "2633/2632" and "S/MIME Version 3 Message Specification/Cryptographic Message Syntax" with "S/MIME Version 3.1 Message Specification/S/MIME Certificate Handling". Rationale: 2632/2633 are the "S/MIME" specs. Additionally, it's version 3.1 not 3. 20. 2.3.3, Eight Permutations: Move these to the new section 2.2.3. Keeps all the options and what services are provided together. 21. 3: Why isn't ESMTP listed? 22. 3.3: Replace "document" with "RFC" 23. 3.9: RFCs 2633 and 2632 not 2630 describe S/MIME. To match the PGP stuff which includes associated key management stuff you need to reference 2632. Don't worry the short term approach is still good, but you still need to make PKCs in an agreed format. 24. 3.9: Replace "This specifications describe how MIME shall carry CMS objects" with "These RFCs define how to send and receive secure MIME data and what certificate processing requirement must be followed". 25. 3.9: Add the following: "There is an S/MIME Extended Security Service (ESS) called Signed Receipts. This specification does not use the service as described in [2674]." 26. 4.2, Replace "RFC822/2045" with "RFC822/2045/2298". Rationale: The point of the RFC is to indicate which RFCs get used at what layer and you can't request a signed MDN with 2298. This does raise an interesting question: If there are multiple signature layers where does the signed MDN request go and which layer does it correspond to? If only one is allowed at the top then certain scenarios most notably the triple wrapping scenario (signed(encrypted(signed))) will result in an ambiguous MIC value. 27. 5.1, 1st para, 2nd sentence: Replace with "The message digest notification [5] is digital signed by the receiving trading partner. Two copies are produced one is sent to the originating trading partner and the other is retained by the receiving trading partner." Rationale: In order to get an NRR service the signed receipt must be retained. 28. 5.1, REQUIRED receipt support: There are no requirements (i.e., MUSTs or REQUIREDs) for the signed receipt requester to process the signed receipt. There are thing they can use it for but not requirements. 29. 5.1, basic processing bullets: Add processing that covers what occurs in case of failed steps. Rationale: MUST processing rules ought to include the error case(s) too. 30. 5.1, basic processing bullets: Add "9) Save originally signed message and receipts and signed receipts." Rationale: It's going to be hard for the recipient to refute the originator if they don't save a copy of the signed message(s) and the receipt(s) they generated. 31. 5.1, what an signed MDN can be used for and 5.2.1 1st paragraph after NOTE: If an error occurs and a signed receipt is returned anyway with a disposition notification – the signed MDN can't do any of the things listed in the last part of 5.1. Recommend replacing "The signed MDN, …" with "The signed MDN without any disposition-field=failed, …" in the last part of 5.1. 32. 5.3.2: As best I can tell there is no requirement for the disposition-type/mode to send back any indication that the processing failed – it's all SHOULDs – but the disposition-type:failed…blah.blah is how the originator knows that the signed receipt he got really doesn't mean they get all the things they said they were going to get at the bottom of 5.1. All of this is because a signed receipt can be returned even if processing of the message failed and no indication that it failed is required. Some of them ought to be MUST to get the appropriate behavior. 33. 5.3.1, There are no support requirements for the "Received-content-MIC". Is "will be added" a "MUST", if so use MUST. 34. 5.3.1, 1st para, last sentence: Add " before the word extension. 35. 5.3.2.1: 1st sentence is confusing. 36. 6.1, 1st para, 1st sentence: What is self-certify? 37. 6.1, 1st para, last sentence: Replace "this" with "that". 38. 7: Assuming you don't believe you've added any new security issues just say there are no additional security considerations to those already defined in .. and list ALL the standards you refer to for security – both the PGP and S/MIME ones.

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

Dale Moberg wrote:

Message

 

 Sean P. Turner  writes: 
 

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

  [snip]

 

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]."  

 

[snip]

 

The requirements for Applicability Statements of the EDIINT WG has included a goal of accomodating both PGP-based and PKCS7/CMS-based message level security. The rough consensus of this WG has been to try to both reuse available RFCs when possible and appropriate, and not to adopt radically different AS profiles for differing security underpinnings or transfer protocols. Because ESS is inextricably linked to the PKCS7/CMS applied crypto technology, and  no PGP analog exists for it, it is not something we chose to profile within EDIINT. Additionally, both AS1 and AS2 drafts had been implemented and were in interoperability trials well before ESS was available.

 

I'm actually not proposing that you switch to the ESS signed receipt.  I think it's fine that you did what you did.  I am just concerned that when people read EDIINT with S/MIME drafts and they say they get a signed receipt that it's not the same thing as the ESS signed receipt. That's all I just want a heads up notice.

I have seen no one else on this WG list suggest that ESS be considered even for future applicability statement profiles. The large existing end user and vendor base using EDIINT WG Applicability Statements probably would not welcome your call for deprecation also. 

 

Again I'm acutally not asking that using PGP be deprecated.  In the latest version of CMS (3369bis) we added a key management extension mechanisms primarily to to supports the use of PGP with CMS and I think they're looking at it.  So who knows maybe S/MIME and PGP will coexist peacefully in the future.

I think there is no danger of confusing the signing of a MDN (including the received content mic) with any ESS construct, and a reference to ESS is not required for implementers to understand either AS1, AS2 or AS3.

 

I have actually.  One buyer was looking for an signed receipt (ESS variety) and the vendor claimed they had one but it was a signed receipt (MDN variety).  Would have been fine except the other folks they were trying to interoperate with were all using signed receipts (ESS variety).  They didn't realize until they started doing testing that the two were different.

Other comments you provide may be addressed separately in other messages. There is almost certain to be some delay in my responses.

 

I'm available to clarify anything I sent along.

Since we are close to WG last call, and we have an abundance of working code and rough consensus among both endusers and development communities, I would encourage other WG members who wish to see specific points of Mr Turner addressed, to please post to the list the points you wish to see addressed and the language you wish to see included.