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.