Subject: Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 27 Feb 2008 14:58:51 +0100

There are obvious errors (intentionnaly left by the editor 
in order to know how many people read the document).

On page 1:

The message digest algorithms are defined in and [SHS].  
                                             ^^^
Also in section 2.4:

2.4. SHA-512 

   The SHA-256 message digest algorithm is defined in [SHS].

whereas it should be:

2.4. SHA-512 

   The SHA-512 message digest algorithm is defined in [SHS].

It would be valuable to explain why DSA cannot be used 
with SHA-384 and SHA-512.

In addition, it is not acceptable to reference in the *normative* 
references "work in progess", i.e.[ECCADD].

The same applies for [SHS]. The text states:

   NOTE [to be removed upon publication as an RFC]: NIST has not yet 
   finalized FIPS 186-3 and there is a chance that the draft may be 
   changed.  This may result in differences between what is documented 
   in the current version of this document and what is in the FIPS.  It 
   is intended to synchronize the final version of this draft with the 
   FIPS before publication as an RFC. 

There is a more substantive comment on the first paragraph of section 1. 
The text states:

   If an implementation chooses to support one of the algorithms 
   discussed in this document, then the implementation MUST do so as 
   described in this document. 

I believe the text should be:

   If an implementation chooses to support one of the algorithms 
   discussed in this document, then the implementation MUST do so as 
   described in [SHS]. 

A small discussion in the security considerations section on the advantages
(in particular in terms of performances versus security) of using one or 
another function from the SHA2 family would be helpful.

While I welcome this draft, everybody should take into consideration that, 
if the SHA2 family happens to be broken then we will be at risk. 
This should be mentioned into the security considerations section.

The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. 
WHIRLPOOL would be a good substitute to SHA-512 and I would encourage 
that "someone" drafts an RFC to specify OIDs for using WHIRLPOOL with CMS.

Denis

>The IESG has received a request from the S/MIME Mail Security WG (smime)
>to consider the following document:
>
>- 'Using SHA2 Algorithms with Cryptographic Message Syntax '
>   <draft-ietf-smime-sha2-03.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2008-03-07. Exceptionally, 
>comments may be sent to [email-masked] instead. In either case, please 
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16033&rfc_flag=0
>
>

Regards,

Denis Pinkas

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 29 Feb 2008 16:06:59 -0500

Denis,

Thanks for taking the time to review this ID. Responses are inline.

spt 

>-----Original Message-----
>
>There are obvious errors (intentionnaly left by the editor in 
>order to know how many people read the document).

If I was going to leave something intentionally in the document to see if
you'd read it, then it would have been a lot better ... something like (note
this isn't an actual offer) "if you mention this sentence to me I'll buy you
a beer".  This ID is way too short to sneak in this kind of phrase.

>                                             ^^^ Also in section 2.4:

Will remove the "and".

>   The SHA-512 message digest algorithm is defined in [SHS].

Will replace SHA-256 with SHA-512 in 2.4.

>It would be valuable to explain why DSA cannot be used with 
>SHA-384 and SHA-512.

I'll add some text.

>In addition, it is not acceptable to reference in the 
>*normative* references "work in progess", i.e.[ECCADD].

I'm pretty sure this is done all the time. There are 17 IDs in the RFC
editor queue with works-in-progress in normative references.

>   FIPS before publication as an RFC. 

The FIPS PUB 186-3 part that this ID needs has very little chance of
changing. The WG wanted this note to be safe.

>   discussed in this document, then the implementation MUST do so as 

The algorithms aren't defined in this document only the OIDs and where they
go in CMS ... so I still think it's actually "as described in this
document". But, Spencer suggests removing the sentences because they're not
needed and I tend to agree with him.

>A small discussion in the security considerations section on 
>the advantages (in particular in terms of performances versus 
>security) of using one or another function from the SHA2 
>family would be helpful.

I'll see if I can't get something from NIST (or at least point to it).

>While I welcome this draft, everybody should take into 
>consideration that, if the SHA2 family happens to be broken 
>then we will be at risk. 

If an algorithm is cracked then isn't it obvious that we're in trouble?  No
other algorithm document I could find says something like this so I'm
inclined to not include this in the security considerations section.

>WHIRLPOOL would be a good substitute to SHA-512 and I would 
>encourage that "someone" drafts an RFC to specify OIDs for 
>using WHIRLPOOL with CMS.
>
>Denis
>
>>The IESG has received a request from the S/MIME Mail Security WG 
>>(smime) to consider the following document:
>>
>comments may 
>>be sent to [email-masked] instead. In either case, please retain the 
>>beginning of the Subject line to allow automated sorting.
>>
>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag
>>=16033&rfc_flag=0

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Feb 2008 14:30:02 -0800

>editor queue with works-in-progress in normative references.

Sean is correct. This will cause the draft to be stuck in the RFC 
Editor publication queue until the other document becomes an RFC, but 
there is absolutely nothing wrong with this in a last-call draft.

>changing. The WG wanted this note to be safe.

Again, Sean is right. It is quite common to have comments like "This 
section to be removed upon publication" in documents going into the 
RFC Editor queue.

>needed and I tend to agree with him.

Spencer wins on this one. The sentence doesn't make much sense in a 
standards-track document.

>I'll see if I can't get something from NIST (or at least point to it).

I'll disagree with this. These are not security considerations; they 
are performance considerations. And pretty obvious ones at that.

>inclined to not include this in the security considerations section.

... or anywhere else. If any algorithm (hash, encryption, signing, 
...) is broken, it is broken. Sean's right here.

Date: Fri, 29 Feb 2008 14:30:02 -0800
To: "Turner, Sean P." <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
Cc: <[email-masked]>
Sender: [email-masked]

>editor queue with works-in-progress in normative references.

Sean is correct. This will cause the draft to be stuck in the RFC 
Editor publication queue until the other document becomes an RFC, but 
there is absolutely nothing wrong with this in a last-call draft.

>changing. The WG wanted this note to be safe.

Again, Sean is right. It is quite common to have comments like "This 
section to be removed upon publication" in documents going into the 
RFC Editor queue.

>needed and I tend to agree with him.

Spencer wins on this one. The sentence doesn't make much sense in a 
standards-track document.

>I'll see if I can't get something from NIST (or at least point to it).

I'll disagree with this. These are not security considerations; they 
are performance considerations. And pretty obvious ones at that.

>inclined to not include this in the security considerations section.

... or anywhere else. If any algorithm (hash, encryption, signing, 
...) is broken, it is broken. Sean's right here.

From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
Date: Fri, 29 Feb 2008 16:06:59 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Denis,

spt 

Will remove the "and".

I'll add some text.

w_id&dTag
>Denis Pinkas

Date: Wed, 27 Feb 2008 14:58:51 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
Sender: [email-masked]

On page 1:

2.4. SHA-512 

whereas it should be:

2.4. SHA-512 

Denis

Regards,

Denis Pinkas

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-00.txt 
Date: Fri, 22 Feb 2008 15:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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		: Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-rfc3278-update-00.txt
	Pages		: 8
	Date		: 2008-2-12
	
RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  
   This document updates RFC 3278 to add support for the SHA2 family of 
   hash algorithms. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-rfc3278-update-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms with  Cryptographic Message Syntax) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 22 Feb 2008 14:29:21 -0800 (PST)
Sender: [email-masked]

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-smime-multisig (Multiple Signatures in  S/MIME) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 22 Feb 2008 14:28:43 -0800 (PST)
Sender: [email-masked]

- 'Multiple Signatures in S/MIME '
   <draft-ietf-smime-multisig-04.txt> as a Proposed Standard

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15544&rfc_flag=0

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3850bis-01.txt 
Date: Thu, 21 Feb 2008 12:15:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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		: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
	Author(s)	: S. Turner, B. Ramsdell
	Filename	: draft-ietf-smime-3850bis-01.txt
	Pages		: 18
	Date		: 2008-2-21
	
This document specifies conventions for X.509 certificate usage by 
   Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.  S/MIME 
   provides a method to send and receive secure MIME messages, and 
   certificates are an integral part of S/MIME agent processing.  S/MIME 
   agents validate certificates as described in RFC 3280bis, the 
   Internet X.509 Public Key Infrastructure Certificate and CRL Profile.  
   S/MIME agents must meet the certificate processing requirements in 
   this document as well as those in RFC 3280bis. This document 
   obsoletes RFC 3850.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-3850bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Key Sizes in S/MIME v3.2
Date: Thu, 21 Feb 2008 06:58:46 -0500
From: "Carl Wallace" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Turner, Sean P." <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Maybe the DSSC draft could be of use here:
http://tools.ietf.org/html/draft-ietf-ltans-dssc-01.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, February 20, 2008 1:39 PM
To: Turner, Sean P.; 'Denis Pinkas'; [email-masked]
Subject: RE: Key Sizes in S/MIME v3.2

The point is that we should be able to validate a signature that was
generated by a key pair that was generated under the previous
recommendations.

Russ

At 12:10 PM 2/20/2008, Turner, Sean P. wrote:

>As I dig around, I find that 1024 is pretty much the minimum that is 
>recommended. Both NIST (SP 800-78) and RSA
>(http://www.rsa.com/rsalabs/node.asp?id=2004) recommend at least 1024
now.
>Also, I'm not sure I've ever actually seen a 768-bit key in a 
>certificate - all I've seen for years now is 1024.
>
>spt
>
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Denis Pinkas
> >Sent: Wednesday, February 20, 2008 11:34 AM
> >To: [email-masked]
> >Subject: Re: Key Sizes in S/MIME v3.2
> >
> >
> >
> >
> >>How about for 3851bis: A user agent SHOULD generate RSA key
> >pairs at a
> >>minimum key size of 1024 bits.  A user agent MUST NOT
> >generate RSA key
> >>pairs less than 1024 bits long.
> >
> >With these two sentences there is no more room for key sizes less 
> >than 1024 bits.
> >768 bits is still fully adequate, even we can recommend to use
> >1024 bits as the minimum.
> >
> >Denis
> >
> >>I'll move the 768 back to 512 as suggested by Simon.
> >>
> >>spt
> >>>From: Russ Housley [mailto:[email-masked]]
> >>>Sent: Wednesday, February 20, 2008 9:16 AM
> >>>To: Turner, Sean P.
> >>>Cc: [email-masked]
> >>>Subject: RE: Key Sizes in S/MIME v3.2
> >>>
> >>>Sean:
> >>>
> >>>Given the proposed text, it sounds like you really want to say that

> >>>key sizes from 768 to 2048 bits must be supported, even
> >though you are
> >>>recommending 1024 bits as the minimum for newly generated keys.
> >>>
> >>>Russ
> >>>
> >>>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
> >>>
> >>>>I should have been clearer.
> >>>>
> >>>>RFC 3850 current says (sec 4.3):
> >>>>
> >>>>  Key sizes from 512 bits to 2048 bits MUST be supported.
> >>>>
> >>>>Suggesting it be replaced with:
> >>>>
> >>>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
> >>>>
> >>>>Here are the suggested changes RFC 3851 (sec 4.1):
> >>>>
> >>>>  If an S/MIME agent needs to generate an RSA key pair,  then the 
> >>>> S/MIME agent or some related administrative  utility or function 
> >>>> SHOULD generate RSA key pairs  using the following
> >>>guidelines.  A user
> >>>> agent SHOULD  generate RSA key pairs at a minimum key size of
1024
> >>>>                                          was 768 ^^^^
> >bits.  A user
> >>>> agent MUST NOT generate RSA key pairs  less than 768 bits long.
> >>>> Creating keys longer than
> >>>>            ^^^ was 512
> >>>>  1024 bits can cause some older S/MIME receiving agents  to not 
> >>>> be able to verify signatures, but gives better  security and is
> >>>therefore
> >>>> valuable.  A receiving agent  SHOULD be able to verify
> >>>signatures with
> >>>> keys of any  size over 768 bits. Some agents created in the
United
> >>>>            ^^^ was 512
> >>>>  States have chosen to create 512 bit keys in order to  get more 
> >>>> advantageous export licenses.  However, 512  bit keys are
> >considered
> >>>> by many to be cryptographically  insecure. Implementers SHOULD be

> >>>> aware that multiple
> >>>>  (active) key pairs can be associated with a single
> >>>individual.  For
> >>>> example, one key pair can be used  to support
> >>>confidentiality, while a
> >>>> different key pair  can be used for authentication.
> >>>>
> >>>>Thoughts?
> >>>>
> >>>>spt
> >>>>
> >>>> >From: [email-masked] 
> >>>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
> >>>> >Sent: Tuesday, February 19, 2008 1:42 PM
> >>>> >To: Turner, Sean P.; [email-masked]
> >>>> >Subject: Re: Key Sizes in S/MIME v3.2
> >>>> >
> >>>> >
> >>>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
> >>>> >>  >From the mail discussion we had in December, it's pretty
> >>>> >clear to me
> >>>> >>that key sizes from 1024-2048 ought to be the MUST and other
> >>>> >key sizes are MAY.
> >>>> >>I'm suggesting the following text:
> >>>> >>
> >>>> >>Key sizes from 1024 bits to 2048 buts MUST be supported.
> >>>Keys sizes
> >>>> >>larger than 2048 MAY be supported.
> >>>> >
> >>>> >Sure.
> >>>> >
> >>>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
> >>>> >smaller than 1024?
> >>>> >
> >>>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
> >>>> >
> >>>
> >>
> >>
> >
> >Regards,
> >
> >Denis Pinkas
> >
> >
> >

Date: Wed, 20 Feb 2008 13:38:54 -0500
To: "Turner, Sean P." <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Sender: [email-masked]

The point is that we should be able to validate a signature that was 
generated by a key pair that was generated under the previous recommendations.

Russ

At 12:10 PM 2/20/2008, Turner, Sean P. wrote:

>As I dig around, I find that 1024 is pretty much the minimum that is
>recommended. Both NIST (SP 800-78) and RSA
>(http://www.rsa.com/rsalabs/node.asp?id=2004) recommend at least 1024 now.
>Also, I'm not sure I've ever actually seen a 768-bit key in a certificate -
>all I've seen for years now is 1024.
>
>spt
>
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Denis Pinkas
> >Sent: Wednesday, February 20, 2008 11:34 AM
> >To: [email-masked]
> >Subject: Re: Key Sizes in S/MIME v3.2
> >
> >
> >
> >
> >>How about for 3851bis: A user agent SHOULD generate RSA key
> >pairs at a
> >>minimum key size of 1024 bits.  A user agent MUST NOT
> >generate RSA key
> >>pairs less than 1024 bits long.
> >
> >With these two sentences there is no more room for key sizes
> >less than 1024 bits.
> >768 bits is still fully adequate, even we can recommend to use
> >1024 bits as the minimum.
> >
> >Denis
> >
> >>I'll move the 768 back to 512 as suggested by Simon.
> >>
> >>spt
> >>>From: Russ Housley [mailto:[email-masked]]
> >>>Sent: Wednesday, February 20, 2008 9:16 AM
> >>>To: Turner, Sean P.
> >>>Cc: [email-masked]
> >>>Subject: RE: Key Sizes in S/MIME v3.2
> >>>
> >>>Sean:
> >>>
> >>>Given the proposed text, it sounds like you really want to say that
> >>>key sizes from 768 to 2048 bits must be supported, even
> >though you are
> >>>recommending 1024 bits as the minimum for newly generated keys.
> >>>
> >>>Russ
> >>>
> >>>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
> >>>
> >>>>I should have been clearer.
> >>>>
> >>>>RFC 3850 current says (sec 4.3):
> >>>>
> >>>>  Key sizes from 512 bits to 2048 bits MUST be supported.
> >>>>
> >>>>Suggesting it be replaced with:
> >>>>
> >>>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
> >>>>
> >>>>Here are the suggested changes RFC 3851 (sec 4.1):
> >>>>
> >>>>  If an S/MIME agent needs to generate an RSA key pair,  then the
> >>>> S/MIME agent or some related administrative  utility or function
> >>>> SHOULD generate RSA key pairs  using the following
> >>>guidelines.  A user
> >>>> agent SHOULD  generate RSA key pairs at a minimum key size of 1024
> >>>>                                          was 768 ^^^^
> >bits.  A user
> >>>> agent MUST NOT generate RSA key pairs  less than 768 bits long.
> >>>> Creating keys longer than
> >>>>            ^^^ was 512
> >>>>  1024 bits can cause some older S/MIME receiving agents  to not be
> >>>> able to verify signatures, but gives better  security and is
> >>>therefore
> >>>> valuable.  A receiving agent  SHOULD be able to verify
> >>>signatures with
> >>>> keys of any  size over 768 bits. Some agents created in the United
> >>>>            ^^^ was 512
> >>>>  States have chosen to create 512 bit keys in order to  get more
> >>>> advantageous export licenses.  However, 512  bit keys are
> >considered
> >>>> by many to be cryptographically  insecure. Implementers SHOULD be
> >>>> aware that multiple
> >>>>  (active) key pairs can be associated with a single
> >>>individual.  For
> >>>> example, one key pair can be used  to support
> >>>confidentiality, while a
> >>>> different key pair  can be used for authentication.
> >>>>
> >>>>Thoughts?
> >>>>
> >>>>spt
> >>>>
> >>>> >From: [email-masked]
> >>>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
> >>>> >Sent: Tuesday, February 19, 2008 1:42 PM
> >>>> >To: Turner, Sean P.; [email-masked]
> >>>> >Subject: Re: Key Sizes in S/MIME v3.2
> >>>> >
> >>>> >
> >>>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
> >>>> >>  >From the mail discussion we had in December, it's pretty
> >>>> >clear to me
> >>>> >>that key sizes from 1024-2048 ought to be the MUST and other
> >>>> >key sizes are MAY.
> >>>> >>I'm suggesting the following text:
> >>>> >>
> >>>> >>Key sizes from 1024 bits to 2048 buts MUST be supported.
> >>>Keys sizes
> >>>> >>larger than 2048 MAY be supported.
> >>>> >
> >>>> >Sure.
> >>>> >
> >>>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
> >>>> >smaller than 1024?
> >>>> >
> >>>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
> >>>> >
> >>>
> >>
> >>
> >
> >Regards,
> >
> >Denis Pinkas
> >
> >
> >

From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Date: Wed, 20 Feb 2008 12:10:44 -0500
Organization: IECA, Inc.
Sender: [email-masked]

As I dig around, I find that 1024 is pretty much the minimum that is
recommended. Both NIST (SP 800-78) and RSA
(http://www.rsa.com/rsalabs/node.asp?id=2004) recommend at least 1024 now.
Also, I'm not sure I've ever actually seen a 768-bit key in a certificate -
all I've seen for years now is 1024.

spt 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Wednesday, February 20, 2008 11:34 AM
>To: [email-masked]
>Subject: Re: Key Sizes in S/MIME v3.2
>
>
>
>
>>How about for 3851bis: A user agent SHOULD generate RSA key 
>pairs at a 
>>minimum key size of 1024 bits.  A user agent MUST NOT 
>generate RSA key 
>>pairs less than 1024 bits long.
>
>With these two sentences there is no more room for key sizes 
>less than 1024 bits.
>768 bits is still fully adequate, even we can recommend to use 
>1024 bits as the minimum.
>
>Denis
>
>>I'll move the 768 back to 512 as suggested by Simon.
>>
>>spt
>>>From: Russ Housley [mailto:[email-masked]]
>>>Sent: Wednesday, February 20, 2008 9:16 AM
>>>To: Turner, Sean P.
>>>Cc: [email-masked]
>>>Subject: RE: Key Sizes in S/MIME v3.2
>>>
>>>Sean:
>>>
>>>Given the proposed text, it sounds like you really want to say that 
>>>key sizes from 768 to 2048 bits must be supported, even 
>though you are 
>>>recommending 1024 bits as the minimum for newly generated keys.
>>>
>>>Russ
>>>
>>>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
>>>
>>>>I should have been clearer.
>>>>
>>>>RFC 3850 current says (sec 4.3):
>>>>
>>>>  Key sizes from 512 bits to 2048 bits MUST be supported.
>>>>
>>>>Suggesting it be replaced with:
>>>>
>>>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
>>>>
>>>>Here are the suggested changes RFC 3851 (sec 4.1):
>>>>
>>>>  If an S/MIME agent needs to generate an RSA key pair,  then the 
>>>> S/MIME agent or some related administrative  utility or function 
>>>> SHOULD generate RSA key pairs  using the following
>>>guidelines.  A user
>>>> agent SHOULD  generate RSA key pairs at a minimum key size of 1024
>>>>                                          was 768 ^^^^  
>bits.  A user 
>>>> agent MUST NOT generate RSA key pairs  less than 768 bits long.
>>>> Creating keys longer than
>>>>            ^^^ was 512
>>>>  1024 bits can cause some older S/MIME receiving agents  to not be 
>>>> able to verify signatures, but gives better  security and is
>>>therefore
>>>> valuable.  A receiving agent  SHOULD be able to verify
>>>signatures with
>>>> keys of any  size over 768 bits. Some agents created in the United
>>>>            ^^^ was 512
>>>>  States have chosen to create 512 bit keys in order to  get more 
>>>> advantageous export licenses.  However, 512  bit keys are 
>considered 
>>>> by many to be cryptographically  insecure. Implementers SHOULD be 
>>>> aware that multiple
>>>>  (active) key pairs can be associated with a single
>>>individual.  For
>>>> example, one key pair can be used  to support
>>>confidentiality, while a
>>>> different key pair  can be used for authentication.
>>>>
>>>>Thoughts?
>>>>
>>>>spt
>>>>
>>>> >From: [email-masked] 
>>>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>>> >Sent: Tuesday, February 19, 2008 1:42 PM
>>>> >To: Turner, Sean P.; [email-masked]
>>>> >Subject: Re: Key Sizes in S/MIME v3.2
>>>> >
>>>> >
>>>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>>> >>  >From the mail discussion we had in December, it's pretty
>>>> >clear to me
>>>> >>that key sizes from 1024-2048 ought to be the MUST and other
>>>> >key sizes are MAY.
>>>> >>I'm suggesting the following text:
>>>> >>
>>>> >>Key sizes from 1024 bits to 2048 buts MUST be supported. 
>>>Keys sizes
>>>> >>larger than 2048 MAY be supported.
>>>> >
>>>> >Sure.
>>>> >
>>>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
>>>> >smaller than 1024?
>>>> >
>>>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>>> >
>>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Date: Wed, 20 Feb 2008 11:41:27 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Denis,

Comments inline...

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Wednesday, February 20, 2008 10:49 AM
>To: [email-masked]
>Subject: Re: Key Sizes in S/MIME v3.2
>
>
>Sean,
>
>I like the proposed text, with two exceptions:
>
>A - " A receiving agent SHOULD be able to verify signatures 
>with keys of any  size over 768 bits".
>
>1 - The upper limit is unlimited, so I would not like that sentence 
>    to be interpreted so that we SHOULD support 4096 bits keys :-(

In December we talked about keys large than 2048 and most people felt that
they should be a MAY.

>2 - With that sentence, there is no MUST for a receiving agent.
>  
>We should have sentences like:
>
>A receiving agent SHALL ...
>A receiving agent SHOULD ...
>
>The following is a try:
>
>A receiving agent SHALL be able to verify signatures with keys 
>of any size between 768 bits and 2048 bits.
>
>A receiving agent SHOULD be able to verify signatures with 
>keys of any size between 512 bits and 767 bits, for backwards 
>compatibility.
>
>OR
>
>A receiving agent SHALL be able to verify signatures with keys 
>of any size between 1024 bits and 2048 bits.
>
>A receiving agent SHOULD be able to verify signatures with 
>keys of any size between 512 bits and 1023 bits.

The reason I think it's a SHOULD as opposed to SHALL is that they didn't
want to limit the upper bounds. If we change this to a SHALL then we have to
decide where the upper bounds is. I actually prefer to leave this as SHOULD
verify signatures with keys any size over 512 bits.

>B - Then the following text should be improved and moved in 
>the security considerations section:
>
>" Implementers SHOULD be aware that multiple
>(active) key pairs can be associated with a single individual. 
> For example, one key pair can be used to support 
>confidentiality, while a different key pair can be used for 
>authentication".

We can move the text.

>I suggest to use the material sent in my earlier e-mail.
>
>Denis
>
>===============================================================
>
>>I should have been clearer.
>>
>>RFC 3850 current says (sec 4.3):
>>
>> Key sizes from 512 bits to 2048 bits MUST be supported. 
>>
>>Suggesting it be replaced with:
>> 
>> Key sizes from 1024 bits to 2048 bits MUST be supported. 
>>
>>Here are the suggested changes RFC 3851 (sec 4.1):
>>
>> If an S/MIME agent needs to generate an RSA key pair, then 
>the S/MIME 
>> agent or some related administrative utility or function SHOULD 
>> generate RSA key pairs using the following guidelines.  A user agent 
>> SHOULD generate RSA key pairs at a minimum key size of 1024
>>                                         was 768 ^^^^ bits.  A user 
>> agent MUST NOT generate RSA key pairs less than 768 bits long. 
>> Creating keys longer than
>>           ^^^ was 512
>> 1024 bits can cause some older S/MIME receiving agents to 
>not be able 
>> to verify signatures, but gives better security and is therefore 
>> valuable.  A receiving agent SHOULD be able to verify 
>signatures with 
>> keys of any size over 768 bits. Some agents created in the United
>>           ^^^ was 512
>> States have chosen to create 512 bit keys in order to get more 
>> advantageous export licenses.  However, 512 bit keys are 
>considered by 
>> many to be cryptographically insecure. Implementers SHOULD be aware 
>> that multiple
>> (active) key pairs can be associated with a single individual.  For 
>> example, one key pair can be used to support 
>confidentiality, while a 
>> different key pair can be used for authentication.
>>
>>Thoughts?
>>
>>spt
>>
>>>From: [email-masked]
>>>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>>Sent: Tuesday, February 19, 2008 1:42 PM
>>>To: Turner, Sean P.; [email-masked]
>>>Subject: Re: Key Sizes in S/MIME v3.2
>>>
>>>
>>>At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>>>  >From the mail discussion we had in December, it's pretty
>>>clear to me
>>>>that key sizes from 1024-2048 ought to be the MUST and other
>>>key sizes are MAY.
>>>>I'm suggesting the following text:
>>>>
>>>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes 
>>>>larger than 2048 MAY be supported.
>>>
>>>Sure.
>>>
>>>>Should we put a MUST NOT or SHOULD NOT in for key sizes
>>>smaller than 1024?
>>>
>>>MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Date: Wed, 20 Feb 2008 17:34:03 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Sender: [email-masked]

>How about for 3851bis: A user agent SHOULD generate RSA key pairs at a
>minimum key size of 1024 bits.  A user agent MUST NOT generate RSA key pairs
>less than 1024 bits long.

With these two sentences there is no more room for key sizes less than 1024 bits.
768 bits is still fully adequate, even we can recommend to use 1024 bits as the minimum.

Denis

>I'll move the 768 back to 512 as suggested by Simon.
>
>spt
>>From: Russ Housley [mailto:[email-masked]] 
>>Sent: Wednesday, February 20, 2008 9:16 AM
>>To: Turner, Sean P.
>>Cc: [email-masked]
>>Subject: RE: Key Sizes in S/MIME v3.2
>>
>>Sean:
>>
>>Given the proposed text, it sounds like you really want to say 
>>that key sizes from 768 to 2048 bits must be supported, even 
>>though you are recommending 1024 bits as the minimum for newly 
>>generated keys.
>>
>>Russ
>>
>>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
>>
>>>I should have been clearer.
>>>
>>>RFC 3850 current says (sec 4.3):
>>>
>>>  Key sizes from 512 bits to 2048 bits MUST be supported.
>>>
>>>Suggesting it be replaced with:
>>>
>>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
>>>
>>>Here are the suggested changes RFC 3851 (sec 4.1):
>>>
>>>  If an S/MIME agent needs to generate an RSA key pair,  then the 
>>> S/MIME agent or some related administrative  utility or function 
>>> SHOULD generate RSA key pairs  using the following 
>>guidelines.  A user 
>>> agent SHOULD  generate RSA key pairs at a minimum key size of 1024
>>>                                          was 768 ^^^^  bits.  A user 
>>> agent MUST NOT generate RSA key pairs  less than 768 bits long. 
>>> Creating keys longer than
>>>            ^^^ was 512
>>>  1024 bits can cause some older S/MIME receiving agents  to not be 
>>> able to verify signatures, but gives better  security and is 
>>therefore 
>>> valuable.  A receiving agent  SHOULD be able to verify 
>>signatures with 
>>> keys of any  size over 768 bits. Some agents created in the United
>>>            ^^^ was 512
>>>  States have chosen to create 512 bit keys in order to  get more 
>>> advantageous export licenses.  However, 512  bit keys are considered 
>>> by many to be cryptographically  insecure. Implementers SHOULD be 
>>> aware that multiple
>>>  (active) key pairs can be associated with a single  
>>individual.  For 
>>> example, one key pair can be used  to support 
>>confidentiality, while a 
>>> different key pair  can be used for authentication.
>>>
>>>Thoughts?
>>>
>>>spt
>>>
>>> >From: [email-masked]
>>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>> >Sent: Tuesday, February 19, 2008 1:42 PM
>>> >To: Turner, Sean P.; [email-masked]
>>> >Subject: Re: Key Sizes in S/MIME v3.2
>>> >
>>> >
>>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>> >>  >From the mail discussion we had in December, it's pretty
>>> >clear to me
>>> >>that key sizes from 1024-2048 ought to be the MUST and other
>>> >key sizes are MAY.
>>> >>I'm suggesting the following text:
>>> >>
>>> >>Key sizes from 1024 bits to 2048 buts MUST be supported. 
>>Keys sizes 
>>> >>larger than 2048 MAY be supported.
>>> >
>>> >Sure.
>>> >
>>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
>>> >smaller than 1024?
>>> >
>>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>> >
>>
>
>

Regards,

Denis Pinkas

From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Date: Wed, 20 Feb 2008 11:05:00 -0500
Organization: IECA, Inc.
Sender: [email-masked]

How about for 3851bis: A user agent SHOULD generate RSA key pairs at a
minimum key size of 1024 bits.  A user agent MUST NOT generate RSA key pairs
less than 1024 bits long.

I'll move the 768 back to 512 as suggested by Simon.

spt
>From: Russ Housley [mailto:[email-masked]] 
>Sent: Wednesday, February 20, 2008 9:16 AM
>To: Turner, Sean P.
>Cc: [email-masked]
>Subject: RE: Key Sizes in S/MIME v3.2
>
>Sean:
>
>Given the proposed text, it sounds like you really want to say 
>that key sizes from 768 to 2048 bits must be supported, even 
>though you are recommending 1024 bits as the minimum for newly 
>generated keys.
>
>Russ
>
>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
>
>>I should have been clearer.
>>
>>RFC 3850 current says (sec 4.3):
>>
>>  Key sizes from 512 bits to 2048 bits MUST be supported.
>>
>>Suggesting it be replaced with:
>>
>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
>>
>>Here are the suggested changes RFC 3851 (sec 4.1):
>>
>>  If an S/MIME agent needs to generate an RSA key pair,  then the 
>> S/MIME agent or some related administrative  utility or function 
>> SHOULD generate RSA key pairs  using the following 
>guidelines.  A user 
>> agent SHOULD  generate RSA key pairs at a minimum key size of 1024
>>                                          was 768 ^^^^  bits.  A user 
>> agent MUST NOT generate RSA key pairs  less than 768 bits long. 
>> Creating keys longer than
>>            ^^^ was 512
>>  1024 bits can cause some older S/MIME receiving agents  to not be 
>> able to verify signatures, but gives better  security and is 
>therefore 
>> valuable.  A receiving agent  SHOULD be able to verify 
>signatures with 
>> keys of any  size over 768 bits. Some agents created in the United
>>            ^^^ was 512
>>  States have chosen to create 512 bit keys in order to  get more 
>> advantageous export licenses.  However, 512  bit keys are considered 
>> by many to be cryptographically  insecure. Implementers SHOULD be 
>> aware that multiple
>>  (active) key pairs can be associated with a single  
>individual.  For 
>> example, one key pair can be used  to support 
>confidentiality, while a 
>> different key pair  can be used for authentication.
>>
>>Thoughts?
>>
>>spt
>>
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
>> >Sent: Tuesday, February 19, 2008 1:42 PM
>> >To: Turner, Sean P.; [email-masked]
>> >Subject: Re: Key Sizes in S/MIME v3.2
>> >
>> >
>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>> >>  >From the mail discussion we had in December, it's pretty
>> >clear to me
>> >>that key sizes from 1024-2048 ought to be the MUST and other
>> >key sizes are MAY.
>> >>I'm suggesting the following text:
>> >>
>> >>Key sizes from 1024 bits to 2048 buts MUST be supported. 
>Keys sizes 
>> >>larger than 2048 MAY be supported.
>> >
>> >Sure.
>> >
>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
>> >smaller than 1024?
>> >
>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
>> >
>

Date: Wed, 20 Feb 2008 16:49:07 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Sender: [email-masked]

Sean,

I like the proposed text, with two exceptions:

A - " A receiving agent SHOULD be able to verify signatures with keys of any
 size over 768 bits".

1 - The upper limit is unlimited, so I would not like that sentence 
    to be interpreted so that we SHOULD support 4096 bits keys :-(

2 - With that sentence, there is no MUST for a receiving agent.
  
We should have sentences like:

A receiving agent SHALL ...
A receiving agent SHOULD ...

The following is a try:

A receiving agent SHALL be able to verify signatures with keys of any
size between 768 bits and 2048 bits.

A receiving agent SHOULD be able to verify signatures with keys of any
size between 512 bits and 767 bits, for backwards compatibility.

OR

A receiving agent SHALL be able to verify signatures with keys of any
size between 1024 bits and 2048 bits.

A receiving agent SHOULD be able to verify signatures with keys of any
size between 512 bits and 1023 bits.

B - Then the following text should be improved and moved in the security 
considerations section:

" Implementers SHOULD be aware that multiple
(active) key pairs can be associated with a single
individual.  For example, one key pair can be used
to support confidentiality, while a different key pair
can be used for authentication".

I suggest to use the material sent in my earlier e-mail.

Denis

===============================================================

>I should have been clearer.
>
>RFC 3850 current says (sec 4.3):
>
> Key sizes from 512 bits to 2048 bits MUST be supported. 
>
>Suggesting it be replaced with:
> 
> Key sizes from 1024 bits to 2048 bits MUST be supported. 
>
>Here are the suggested changes RFC 3851 (sec 4.1):
>
> If an S/MIME agent needs to generate an RSA key pair,
> then the S/MIME agent or some related administrative
> utility or function SHOULD generate RSA key pairs
> using the following guidelines.  A user agent SHOULD
> generate RSA key pairs at a minimum key size of 1024
>                                         was 768 ^^^^
> bits.  A user agent MUST NOT generate RSA key pairs
> less than 768 bits long. Creating keys longer than
>           ^^^ was 512
> 1024 bits can cause some older S/MIME receiving agents
> to not be able to verify signatures, but gives better
> security and is therefore valuable.  A receiving agent
> SHOULD be able to verify signatures with keys of any
> size over 768 bits. Some agents created in the United
>           ^^^ was 512
> States have chosen to create 512 bit keys in order to
> get more advantageous export licenses.  However, 512
> bit keys are considered by many to be cryptographically
> insecure. Implementers SHOULD be aware that multiple
> (active) key pairs can be associated with a single
> individual.  For example, one key pair can be used
> to support confidentiality, while a different key pair
> can be used for authentication. 
>
>Thoughts?
>
>spt
>
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>Sent: Tuesday, February 19, 2008 1:42 PM
>>To: Turner, Sean P.; [email-masked]
>>Subject: Re: Key Sizes in S/MIME v3.2
>>
>>
>>At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>>  >From the mail discussion we had in December, it's pretty 
>>clear to me 
>>>that key sizes from 1024-2048 ought to be the MUST and other 
>>key sizes are MAY.
>>>I'm suggesting the following text:
>>>
>>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes 
>>>larger than 2048 MAY be supported.
>>
>>Sure.
>>
>>>Should we put a MUST NOT or SHOULD NOT in for key sizes 
>>smaller than 1024?
>>
>>MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>
>
>

Regards,

Denis Pinkas

Date: Wed, 20 Feb 2008 09:16:02 -0500
To: "Turner, Sean P." <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Cc: [email-masked]
Sender: [email-masked]

Sean:

Given the proposed text, it sounds like you really want to say that 
key sizes from 768 to 2048 bits must be supported, even though you 
are recommending 1024 bits as the minimum for newly generated keys.

Russ

At 07:17 AM 2/20/2008, Turner, Sean P. wrote:

>I should have been clearer.
>
>RFC 3850 current says (sec 4.3):
>
>  Key sizes from 512 bits to 2048 bits MUST be supported.
>
>Suggesting it be replaced with:
>
>  Key sizes from 1024 bits to 2048 bits MUST be supported.
>
>Here are the suggested changes RFC 3851 (sec 4.1):
>
>  If an S/MIME agent needs to generate an RSA key pair,
>  then the S/MIME agent or some related administrative
>  utility or function SHOULD generate RSA key pairs
>  using the following guidelines.  A user agent SHOULD
>  generate RSA key pairs at a minimum key size of 1024
>                                          was 768 ^^^^
>  bits.  A user agent MUST NOT generate RSA key pairs
>  less than 768 bits long. Creating keys longer than
>            ^^^ was 512
>  1024 bits can cause some older S/MIME receiving agents
>  to not be able to verify signatures, but gives better
>  security and is therefore valuable.  A receiving agent
>  SHOULD be able to verify signatures with keys of any
>  size over 768 bits. Some agents created in the United
>            ^^^ was 512
>  States have chosen to create 512 bit keys in order to
>  get more advantageous export licenses.  However, 512
>  bit keys are considered by many to be cryptographically
>  insecure. Implementers SHOULD be aware that multiple
>  (active) key pairs can be associated with a single
>  individual.  For example, one key pair can be used
>  to support confidentiality, while a different key pair
>  can be used for authentication.
>
>Thoughts?
>
>spt
>
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
> >Sent: Tuesday, February 19, 2008 1:42 PM
> >To: Turner, Sean P.; [email-masked]
> >Subject: Re: Key Sizes in S/MIME v3.2
> >
> >
> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
> >>  >From the mail discussion we had in December, it's pretty
> >clear to me
> >>that key sizes from 1024-2048 ought to be the MUST and other
> >key sizes are MAY.
> >>I'm suggesting the following text:
> >>
> >>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes
> >>larger than 2048 MAY be supported.
> >
> >Sure.
> >
> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
> >smaller than 1024?
> >
> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
> >

Date: Wed, 20 Feb 2008 09:09:29 -0500
To: "Denis Pinkas" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Cc: [email-masked]
Sender: [email-masked]

Denis:

>As far as interoperability is concerned the current text is:
>"A user agent SHOULD generate RSA key pairs at a minimum key size of 
>768 bits".

This statement is in conflict with the consensus call that the WG 
Chair made at the beginning of the thread.  Sean said:

 >> From the mail discussion we had in December, it's pretty clear to me that
 >>key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.

Russ 

From: Simon Josefsson <[email-masked]>
To: "Turner\, Sean P." <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 20 Feb 2008 13:59:39 +0100
Sender: [email-masked]

"Turner, Sean P." <[email-masked]> writes:

> I should have been clearer.
>
> RFC 3850 current says (sec 4.3):
>
>  Key sizes from 512 bits to 2048 bits MUST be supported. 
>
> Suggesting it be replaced with:
>  
>  Key sizes from 1024 bits to 2048 bits MUST be supported. 
>
> Here are the suggested changes RFC 3851 (sec 4.1):
>
>  If an S/MIME agent needs to generate an RSA key pair,
>  then the S/MIME agent or some related administrative
>  utility or function SHOULD generate RSA key pairs
>  using the following guidelines.  A user agent SHOULD
>  generate RSA key pairs at a minimum key size of 1024
>                                          was 768 ^^^^
>  bits.  A user agent MUST NOT generate RSA key pairs
>  less than 768 bits long. Creating keys longer than
>            ^^^ was 512
>  1024 bits can cause some older S/MIME receiving agents
>  to not be able to verify signatures, but gives better
>  security and is therefore valuable.  A receiving agent
>  SHOULD be able to verify signatures with keys of any
>  size over 768 bits. Some agents created in the United
>            ^^^ was 512

I agree with your proposed change except for the last one -- is there
any motivation to drop the SHOULD regarding verification of signatures
done with 512 bit keys?  I don't think there is one.  Alerting the user
that the key is insecure, or other user interface considerations, is
orthogonal to the actual verification.

/Simon

>  States have chosen to create 512 bit keys in order to
>  get more advantageous export licenses.  However, 512
>  bit keys are considered by many to be cryptographically
>  insecure. Implementers SHOULD be aware that multiple
>  (active) key pairs can be associated with a single
>  individual.  For example, one key pair can be used
>  to support confidentiality, while a different key pair
>  can be used for authentication. 
>
> Thoughts?
>
> spt
>
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>Sent: Tuesday, February 19, 2008 1:42 PM
>>To: Turner, Sean P.; [email-masked]
>>Subject: Re: Key Sizes in S/MIME v3.2
>>
>>
>>At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>>  >From the mail discussion we had in December, it's pretty 
>>clear to me 
>>>that key sizes from 1024-2048 ought to be the MUST and other 
>>key sizes are MAY.
>>>I'm suggesting the following text:
>>>
>>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes 
>>>larger than 2048 MAY be supported.
>>
>>Sure.
>>
>>>Should we put a MUST NOT or SHOULD NOT in for key sizes 
>>smaller than 1024?
>>
>>MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Date: Wed, 20 Feb 2008 07:50:20 -0500
Organization: IECA, Inc.
Sender: [email-masked]

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Turner, Sean P.
>Sent: Wednesday, February 20, 2008 7:17 AM
>To: [email-masked]
>Subject: RE: Key Sizes in S/MIME v3.2
>
>
>I should have been clearer.
>
>RFC 3850 current says (sec 4.3):
>
> Key sizes from 512 bits to 2048 bits MUST be supported. 
>
>Suggesting it be replaced with:
> 
> Key sizes from 1024 bits to 2048 bits MUST be supported. 
>
>Here are the suggested changes RFC 3851 (sec 4.1):
>	
> If an S/MIME agent needs to generate an RSA key pair,  then 
>the S/MIME agent or some related administrative  utility or 
>function SHOULD generate RSA key pairs  using the following 
>guidelines.  A user agent SHOULD  generate RSA key pairs at a 
>minimum key size of 1024 bits.
>            was 768 ^^^^    
>A user agent MUST NOT generate RSA key pairs  less than 768 
>                                                was 512 ^^^ 
>bits long. Creating keys longer than
> 1024 bits can cause some older S/MIME receiving agents  to 
>not be able to verify signatures, but gives better  security 
>and is therefore valuable.  A receiving agent  SHOULD be able 
>to verify signatures with keys of any  size over 768 bits. 
>                                         was 512 ^^^
>Some agents created in the United
> States have chosen to create 512 bit keys in order to  get 
>more advantageous export licenses.  However, 512  bit keys are 
>considered by many to be cryptographically  insecure. 
>Implementers SHOULD be aware that multiple
> (active) key pairs can be associated with a single  
>individual.  For example, one key pair can be used  to support 
>confidentiality, while a different key pair  can be used for 
>authentication. 
>
>Thoughts?
>
>spt
>
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>Sent: Tuesday, February 19, 2008 1:42 PM
>>To: Turner, Sean P.; [email-masked]
>>Subject: Re: Key Sizes in S/MIME v3.2
>>
>>
>>At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>>  >From the mail discussion we had in December, it's pretty
>>clear to me
>>>that key sizes from 1024-2048 ought to be the MUST and other
>>key sizes are MAY.
>>>I'm suggesting the following text:
>>>
>>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes 
>>>larger than 2048 MAY be supported.
>>
>>Sure.
>>
>>>Should we put a MUST NOT or SHOULD NOT in for key sizes
>>smaller than 1024?
>>
>>MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>
>

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: Key Sizes in S/MIME v3.2
Date: Wed, 20 Feb 2008 07:17:07 -0500
Organization: IECA, Inc.
Sender: [email-masked]

I should have been clearer.

RFC 3850 current says (sec 4.3):

 Key sizes from 512 bits to 2048 bits MUST be supported. 

Suggesting it be replaced with:
 
 Key sizes from 1024 bits to 2048 bits MUST be supported. 

Here are the suggested changes RFC 3851 (sec 4.1):

 If an S/MIME agent needs to generate an RSA key pair,
 then the S/MIME agent or some related administrative
 utility or function SHOULD generate RSA key pairs
 using the following guidelines.  A user agent SHOULD
 generate RSA key pairs at a minimum key size of 1024
                                         was 768 ^^^^
 bits.  A user agent MUST NOT generate RSA key pairs
 less than 768 bits long. Creating keys longer than
           ^^^ was 512
 1024 bits can cause some older S/MIME receiving agents
 to not be able to verify signatures, but gives better
 security and is therefore valuable.  A receiving agent
 SHOULD be able to verify signatures with keys of any
 size over 768 bits. Some agents created in the United
           ^^^ was 512
 States have chosen to create 512 bit keys in order to
 get more advantageous export licenses.  However, 512
 bit keys are considered by many to be cryptographically
 insecure. Implementers SHOULD be aware that multiple
 (active) key pairs can be associated with a single
 individual.  For example, one key pair can be used
 to support confidentiality, while a different key pair
 can be used for authentication. 

Thoughts?

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Tuesday, February 19, 2008 1:42 PM
>To: Turner, Sean P.; [email-masked]
>Subject: Re: Key Sizes in S/MIME v3.2
>
>
>At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>  >From the mail discussion we had in December, it's pretty 
>clear to me 
>>that key sizes from 1024-2048 ought to be the MUST and other 
>key sizes are MAY.
>>I'm suggesting the following text:
>>
>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes 
>>larger than 2048 MAY be supported.
>
>Sure.
>
>>Should we put a MUST NOT or SHOULD NOT in for key sizes 
>smaller than 1024?
>
>MUST NOT or SHOULD NOT *what*? Generate, or validate?
>

Date: Wed, 20 Feb 2008 11:24:35 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Sender: [email-masked]

>Sean:
>
>> From the mail discussion we had in December, it's pretty clear to me that
>>key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.
>>I'm suggesting the following text:
>>
>>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes larger
>>than 2048 MAY be supported.
>
>s/buts/bits/
>
>>Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?
>
>I think we ought to be forgiving on receive.  Thus, I suggest:
>Message originators SHOULD NOT use key sizes smaller than 1024 bits 
>for private key operations.

Recommendations for key sizes depend on the usage of the key.

If the private key is to be used to sign data in the context of an authentication service 
or a non repudiation service, then the private key shall resist during the validity 
period of the certificate (usually one to three years). 

If the key size has been chosen too small, there is no security breach: 
it is only needed to revoke the certificate.

If the private key is to be used to decrypt data, than the key should resist 
as long as the encrypted data should be kept confidential. 

RFC 3161 is using S-MIME. If the key is to be used for a Time Stamping Unit (TSU), 
it had better to resist quite longer and 2048 bits would be recommended. 

These kinds o recommendations should be included in the security considerations section.

As far as interoperability is concerned the current text is:
"A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits".

This key size is still safe for authentication and non repudiation and thus 
there is no reason to raise this value.

>Russ

Denis

Date: Tue, 19 Feb 2008 17:08:30 -0500
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Sender: [email-masked]

Sean:

> From the mail discussion we had in December, it's pretty clear to me that
>key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.
>I'm suggesting the following text:
>
>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes larger
>than 2048 MAY be supported.

s/buts/bits/

>Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?

I think we ought to be forgiving on receive.  Thus, I suggest:
Message originators SHOULD NOT use key sizes smaller than 1024 bits 
for private key operations.

Russ

Date: Tue, 19 Feb 2008 10:42:17 -0800
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Key Sizes in S/MIME v3.2
Sender: [email-masked]

At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>  >From the mail discussion we had in December, it's pretty clear to me that
>key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.
>I'm suggesting the following text:
>
>Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes larger
>than 2048 MAY be supported.

Sure.

>Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?

MUST NOT or SHOULD NOT *what*? Generate, or validate?

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: Key Sizes in S/MIME v3.2
Date: Tue, 19 Feb 2008 11:34:59 -0500
Organization: IECA, Inc.
Sender: [email-masked]

>From the mail discussion we had in December, it's pretty clear to me that
key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.
I'm suggesting the following text:

Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes larger
than 2048 MAY be supported.

Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?

I also removed the ECDSA text so the key sizes only refer to RSA/DSA keys.

spt

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: SMIME Agenda
Date: Thu, 14 Feb 2008 12:27:38 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0134_01C86F04.FC95B0C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

If anyone would like a slot on the SMIME agenda please let me know.

spt

------=_NextPart_000_0134_01C86F04.FC95B0C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>SMIME Agenda</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">If anyone would like a slot on the =
SMIME agenda please let me know.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0134_01C86F04.FC95B0C0--