Subject: Re: Comments on RFC 3335

From: "Terry Harding" <[email-masked]>
Date: Mon, 5 Apr 2004 11:13:55 -0700

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" <[email-masked]>
To: <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>
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.
>
>

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 06 Apr 2004 09:43:10 -0400

Thanks Terry - Just trying to help.

Terry Harding wrote:

Sean,

Terry Harding
Cyclone Commerce
----- Original Message -----
From: "Sean P. Turner" <[email-masked]>
To: <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>
Sent: Thursday, March 25, 2004 12:12 PM
Subject: Comments on RFC 3335

All,

Cheers - spt

-----------comments---------------

MDN.