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

["Jim Schaad" <[e-mail]>]

Blake, 

See in line comments. 

Jim


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

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Monday, March 08, 2004 2:34 AM
> To: 'Blake Ramsdell'
> Cc: Ietf-Smime
> Subject: 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.

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

Suggest language.

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


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

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

[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?
> 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?

[JLS] Is now started.

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

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.

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

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

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

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

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

18.

[JLS] - NAK

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

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

Ugh. MAY.

[JLS] - Yes Ugh - SHOULD.

Blake