ietf-smime
[Top] [All Lists]

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

2004-03-26 00:21:20

Blake, 

See in line comments. 

Jim


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




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