[Top] [All Lists]

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

2004-03-26 00:21:20


See in line comments. 


-----Original Message-----
From: Blake Ramsdell [mailto:blake(_at_)brutesquadlabs(_dot_)com] 
Sent: Thursday, March 25, 2004 8:44 PM
To: jimsch(_at_)exmsft(_dot_)com
Cc: 'Ietf-Smime'
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt

-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
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

[JLS] Is now started.

11:  Section  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 
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/



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:

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 

Ugh. MAY.

[JLS] - Yes Ugh - SHOULD.


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