-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: Thursday, March 25, 2004 11:26 PM
To: 'Blake Ramsdell'
Cc: 'Ietf-Smime'
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
-----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.
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.
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.
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.
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.
"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.
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'
OK, next round.
20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
18.
[JLS] - NAK
"Same as your #18 and fixed".
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.
Next round.
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.
MIGHT next round?
Blake