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

["Blake Ramsdell" <[e-mail]>]

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]] 
> 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:[e-mail]] 
> Sent: Thursday, March 25, 2004 8:44 PM
> To: [e-mail]
> Cc: 'Ietf-Smime'
> Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
> 
> > -----Original Message-----
> > From: Jim Schaad [mailto:[e-mail]]
> > 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