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