Re: Comments on RFC 3335

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@xxxxxxxx>
To: <ietf-ediint@xxxxxxx>
Cc: "Housley, Russ" <housley@xxxxxxxxxxxx>
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.