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

[Russ Housley <[e-mail]>]

Blake:

> > 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/
>
>Done.
>
> > 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.

>[snip]
>
> > 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
>changed.

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

>[snip]

Russ