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

From: "Jim Schaad" <[email-masked]>
Date: Mon, 8 Mar 2004 02:34:02 -0800

Hi Blake,

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

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?

4.  Section 2.5.2, p1: Need to add text for Compression Algorithms.

5.  Section 2.5.2:  The following statement is no longer true (please
delete):
Note that all OIDs associated with the MUST and SHOULD implement algorithms
are included in section A of this document.

6.  section 3, p 1: s/[ESS] document provides examples/[ESS] document
provides descriptions/
			s/ESS provides an example of/ESS provides a
description of/

7.  Section 3.1, p 5, s/implementor/implementer/
    Section 3.6, p 3: ditto
    Section 4.1, p 2: ditto
	- I don't know if that is really an incorrect spelling, but MS Word
does not know it.

8.  Section 3.2.1, s/Application/pkcs7-signature/Application/pkcs7-signature
(SignedData)/

9.  Section 3.2.2, p last:  Suggest adding the text:  "An smime-type
parameters is not intended to give indications of security layers applied in
the event of multiple levels of wrapping."

10. Section 3.4: In general, the multipart/signed form is preferred for
sending, and
receiving agents SHOULD be able to handle both. --- what is the MUST handle?
Otherwise there is no interop.

11:  Section 3.4.3.2:  The text 
"The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently supported in S/MIME, and are included here for completeness."
Is only partially correct.  They are supported, just not required by this
document.  I would like to clean this up by saying this in a tighter
fashion.

12.  Section 4, p 1: s/certification/certificate/

13.  Section A:  s/prefered/preferred/

14.  References:  CMSAES = RFC 3565

15.  Section 1.1, p 4: s/the Cryptographic Message Syntax/the Cryptographic
Message Syntax document/

16.  Is a specification MUST/SHOULD (section 1.1, p4) or the document
(section 1.1, p3) (The same word is used, but in completely different
meanings.  Would not be a problem but for the MUST in p4 potentially wanting
to force meaning into p3).

17.  Section 2.2, p 3: s/the algorithms/the hash algorithms/

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.

19.  Section 2.4.1, p1: s/encryptedContentInfo
ContentType/encryptedContentInfo contentType/

20.  Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/

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

22.  Section 2.5 title, s/Attribute/Attributes and the/

23.  Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/

24.  I heard this comment at the last IETF meeting from somebody.  As I have
had the same problem in a number of cases (esp with doing interop matrixes)
I am throwing it out for your consideration:

The use of the words must, should and may in lower case causes some
confusion dealing with the question of - did the author just forget to
uppercase this or is it really not a protocol statement.  SHOULD examine all
instances of these words to see if a different word works just as well.

Jim

---

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 25 Mar 2004 20:44:23 -0800

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Monday, March 08, 2004 2:34 AM
> To: 'Blake Ramsdell'
> Cc: Ietf-Smime
> Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
> 

Don't know -- someone comment.

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

Done.

> 3.  Section 1.1, p 4: Should there be a dependency/reference 

Dunno. "No" for now.

> 4.  Section 2.5.2, p1: Need to add text for Compression Algorithms.

Suggest language.

> are included in section A of this document.

Entire paragraph removed.

> 			s/ESS provides an example of/ESS provides a

Done.

> 	- I don't know if that is really an incorrect spelling, 

This is like "advisor" vs. "adviser" I think. In any case, can't have
Word upset, so modified.

> 8.  Section 3.2.1, 
> s/Application/pkcs7-signature/Application/pkcs7-signature
> (SignedData)/

Done.

> the event of multiple levels of wrapping."

What do you see as the confusion here? Not done.

> Otherwise there is no interop.

Don't know -- bees nest. Start a discussion... If you say MUST send
SignedData, I imagine that's going to be an issue. Maybe MUST
multipart/signed?

> document.  I would like to clean this up by saying this in a tighter

Could use some language, but this may have been handled when I fixed it
for someone else.

> 12.  Section 4, p 1: s/certification/certificate/

Done.

> 13.  Section A:  s/prefered/preferred/

Done.

> 14.  References:  CMSAES = RFC 3565

Done.

> 15.  Section 1.1, p 4: s/the Cryptographic Message Syntax/the 

Done.

> to force meaning into p3).

No idea -- reword and I'll try and parse it again.

> 17.  Section 2.2, p 3: s/the algorithms/the hash algorithms/

Done. "the digest algorithms" I believe is more correct.

> cleaned up in the same way.

Done.

> ContentType/encryptedContentInfo contentType/

Done.

> 20.  Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/

18.

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

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

> 22.  Section 2.5 title, s/Attribute/Attributes and the/

Done.

> 23.  Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/

Done.

> instances of these words to see if a different word works 

Ugh. MAY.

Blake

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 25 Mar 2004 23:25:55 -0800

Blake, 

See in line comments. 

Jim

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]] 
Sent: Thursday, March 25, 2004 8:44 PM
To: [email-masked]
Cc: 'Ietf-Smime'
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt

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

Dunno. "No" for now.

[JLS] - OK -- I think there needs to be an equivalent statement for [CMSALG]
for algorithm parameter encoding.

Suggest language.

[JLS]  Never mind -- I missed it on the first read for some reason.

> parameters is not intended to give indications of security layers 
> applied in the event of multiple levels of wrapping."

[JLS] If you do a E(S(Receipt)) - The correct smime-type under the current
rules is "enveloped-data" not "signed-receipt".  I think this makes it more
explicit what is done for multiple layered messages.

> 10. Section 3.4: In general, the multipart/signed form is preferred 
> for sending, and receiving agents SHOULD be able to handle both. --- 
> what is the MUST handle?

[JLS] Is now started.

> Is only partially correct.  They are supported, just not required by 
> this document.  I would like to clean this up by saying this in a 
> tighter fashion.

Could use some language, but this may have been handled when I fixed it for
someone else.

[JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in
[FIBS180-2][PKIX-RSA-PKALGS].  Support is not currently required in S/MIME
and the micalg values are included here for completeness.

> meanings.  Would not be a problem but for the MUST in p4 potentially 
> wanting to force meaning into p3).

[JLS] Change specification to document in p3 and I'll be happy.

'This specification also discusses'
'MUST follow the specifications in this document'

18.

[JLS] - NAK

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

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

[JLS] Works for me.

> 
> 24.  I heard this comment at the last IETF meeting from somebody.  As 
> I have had the same problem in a number of cases (esp with doing 
> interop matrixes) I am throwing it out for your consideration:
> 

Ugh. MAY.

[JLS] - Yes Ugh - SHOULD.

Blake

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 26 Mar 2004 00:39:40 -0800

> Sent: Thursday, March 25, 2004 11:26 PM
> To: 'Blake Ramsdell'
> Cc: 'Ietf-Smime'

I may not understand this. Are you saying that I need to recursively
include all of the PKIX and CMS references? CMSALG is implicitly
required by CMS in this case, I think. Maybe this paragraph just needs
to go away, or I need to understand better why CMSALG (which is required
by CMS) needs to be called out explicitly.

> explicit what is done for multiple layered messages.

There is existing guidance:

It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or
"encrypted" without having to tunnel into the CMS payload.

I think that this paragraph is sufficient as-is -- what would you
modify? Should it be something like:

It is explicitly intended that this field be a suitable hint for mail
client applications to indicate the "essence" of the message without
having to tunnel into the CMS payload.

Or something like that? I need more help.

"The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently recommended in S/MIME, and are included here for
completeness."

Is the language change I made for someone else.

> 'MUST follow the specifications in this document'

OK, next round.

> > 20.  Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/

"Same as your #18 and fixed".

> not provide authentication" from the EnvelopedData section? 

Next round.

> [JLS] - Yes Ugh - SHOULD.

MIGHT next round?

Blake

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Mar 2004 09:47:27 -0500

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

> > 3.  Section 1.1, p 4: Should there be a dependency/reference

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

>[snip]

Thanks.  It will be fixed in rfc3369bis-02.

>"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.

>[snip]

Russ