Subject: RE: I-D ACTION:draft-ietf-smime-sha2-08.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 3 Oct 2008 13:43:43 -0700

Sean,

1.  Implenations MUST have absent parameters for SHA-2 -- there is no reason
to allow anything else to run.  I won't dispute the MUST read with NULL
parameters however much I would like to.  The defect does not really apply
as plenty of time has passed and this is a new algorithm.   The only
exception to this appears to be in OAEP and PSS where the parameters are
explicitly defined as being required.

2.  Why allow for optional parameters on the signature algorithms for rsa -
not permitted for sha-1WithRSAEncryption.

jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, September 26, 2008 3:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-smime-sha2-08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the S/MIME Mail Security Working Group of
> the IETF.
> 
> 	Title		: Using SHA2 Algorithms with Cryptographic Message
> Syntax
> 	Author(s)	: S. Turner
> 	Filename	: draft-ietf-smime-sha2-08.txt
> 	Pages		: 10
> 	Date		: 2008-9-26
> 
> This document describes the conventions for using the Secure Hash
>    Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-
> 384,
>    SHA-512) with the Cryptographic Message Syntax (CMS). It also
>    describes the conventions for using these algorithms with CMS and
> the
>    Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and
>    Elliptic Curve DSA (ECDSA) signature algorithms.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-08.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 3 Oct 2008 17:09:13 -0400

Jim,

1. I was just following the conventions for SHA-1.  I take it you're
suggesting we should break with those conventions?

2. I copied the last paragraph in 3.2 from RFC 4055 section 5.

spt

>From: Jim Schaad [mailto:[email-masked]] 
>Sent: Friday, October 03, 2008 4:44 PM
>To: Sean P. Turner
>Cc: [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-sha2-08.txt 
>
>Sean,
>
>1.  Implenations MUST have absent parameters for SHA-2 -- 
>there is no reason to allow anything else to run.  I won't 
>dispute the MUST read with NULL parameters however much I 
>would like to.  The defect does not really apply
>exception to this appears to be in OAEP and PSS where the 
>parameters are explicitly defined as being required.
>
>2.  Why allow for optional parameters on the signature 
>algorithms for rsa - not permitted for sha-1WithRSAEncryption.
>
>
>jim
>
>
>

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 3 Oct 2008 19:04:39 -0700

> suggesting we should break with those conventions?

This is something we debated back in the DSA days. The bottom line is
that we were younger and dumber back in the 90's for
AlgorithmIdentifier, and now we know that the parameters are an
optional field. So the bottom line is that new algorithms should be
absent parameters instead of encoded as NULL.

>From RFC 2633:

2.2 SignatureAlgorithmIdentifier

   Sending and receiving agents MUST support id-dsa defined in [DSS].
   The algorithm parameters MUST be absent (not encoded as NULL).

So yeah, we're kind of jerks for carting around some of this NULL for
the older algorithms, but the rule of thumb is that "for any new
algorithms, the parameters are absent if there aren't any".

Blake
-- 
Blake Ramsdell | http://www.blakeramsdell.com

---

From: "Turner, Sean P." <[email-masked]>
Date: Sat, 4 Oct 2008 15:15:54 -0400

In para 2, I'll remove the paragraph that starts "There are two possible
encodings for the SHA AlgorithmIdentifier ..." and I'll change the last
paragraph in 2 from:

 The AlgorithmIdentifier parameters field is OPTIONAL.  If present, 
 the parameters field MUST contain a NULL.  Implementations MUST 
 accept SHA2 AlgorithmIdentifiers with absent parameters.  
 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 
 parameters.  Implementations SHOULD generate SHA2 
 AlgorithmIdentifiers with absent parameters. 

To:

 The AlgorithmIdentifier parameters field is OPTIONAL. 
 Implementations MUST 
 accept SHA2 AlgorithmIdentifiers with absent parameters.  
 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 
 parameters.  Implementations MUST generate SHA2 
 AlgorithmIdentifiers with absent parameters. 

I'll post a new version Monday and I think we'll re-do a WGLC with a one
week period.  This time will give implementers with experience to chime in.

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Blake Ramsdell
>Sent: Friday, October 03, 2008 10:05 PM
>To: Turner, Sean P.
>Cc: Jim Schaad; [email-masked]
>Subject: Re: I-D ACTION:draft-ietf-smime-sha2-08.txt
>
>
>This is something we debated back in the DSA days. The bottom 
>line is that we were younger and dumber back in the 90's for 
>AlgorithmIdentifier, and now we know that the parameters are 
>an optional field. So the bottom line is that new algorithms 
>should be absent parameters instead of encoded as NULL.
>
>From RFC 2633:
>
>So yeah, we're kind of jerks for carting around some of this 
>NULL for the older algorithms, but the rule of thumb is that 
>"for any new algorithms, the parameters are absent if there 
>aren't any".
>
>Blake
>--

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 5 Oct 2008 14:17:21 -0700

> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Friday, October 03, 2008 2:09 PM
> To: 'Jim Schaad'
> Cc: [email-masked]

Yes we break with that convention.

> 2. I copied the last paragraph in 3.2 from RFC 4055 section 5.

These need to be kept as is, we pulled this forward from somebody else who
messed it up.  We can't change this.