[Top] [All Lists]

RE: Comments draft-ietf-smime-rfc2633bis-07.txt

2004-03-26 07:47:52


> 1.  I just realized there is no abstract for this document.  Is one
> required?

Don't know -- someone comment.

There is supposed to be one. RFC 2633 got through without one. Today's IESG would not have let it happen. I suggest:

This document defines S/MIME (Secure/Multipurpose Internet Mail Extensions) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity and non-repudiation with proof of origin. Encryption provides data confidentiality.

> 2.  Section 2, p1:  s/[CMS] provides/[CMSALG] provides/


> 3.  Section 1.1, p 4: Should there be a dependency/reference
> to CMSALG here
> as well?

Dunno. "No" for now.

I think it is a good idea to include the reference.


> 18.  Section 2.4.1, p1:  s/signedData/SignedData/
>       - also envelopedData vs EnvelopedData and compressedData vs
> CompressedData.
>       signedData does not actually exist in the CMS
> documents.  The type
> is SignedData or the concept is signed data.  I think we need
> to clean this
> up.
>       Russ:  Please note there is one section in CMS that needs to be
> cleaned up in the same way.

Thanks.  It will be fixed in rfc3369bis-02.

> 21.  Section 2.4.2, p1: Should add "This content type does not provide
> privacy."

And also add "and does not provide compression"? Should we just remove
"does not provide authentication" from the EnvelopedData section? Not

I think we should be talking about "confidentiality" not "privacy." See the definitions of these words in RFC 2828.



<Prev in Thread] Current Thread [Next in Thread>