ietf-smime
[Top] [All Lists]

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

2004-03-26 01:39:46

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


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