Subject: Comments on S/MIME v3.2

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 5 Dec 2007 09:00:23 -0800

At the meeting we had some comments on the S/MIME v3.2 specs
(draft-ietf-smime-3850bis-00.txt and draft-ietf-smime-3851bis-00.txt):
 1. Define SHOULD+, SHOULD-, and MUST-.
 2. Update key size requirements and make sure you differentiate between
RSA/DSA and EC key sizes.
 3. Check that there's no IPR wrt to ECDSA signed certificates and using
them with S/MIME.

For #1 - I'm going to copy the text from RFC4307.

For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of any kind)
so we've got our feelers out to see what we can shake loose.

For #2 RSA/DSA key sizes - There was some discussion that the RSA key size
that MUST be supported should be 1024-3076 and others felt that it should be
1024-2048.  What do people think?

For #2 EC key size - This discussion may be premature but what should we
make the sizes?  Min 256 max 384?

Other comments are welcome.

spt

---

From: "Luther Martin" <[email-masked]>
Date: Wed, 5 Dec 2007 10:20:49 -0800

With respect to the RSA key sizes, I see lots of demand for 3072-bit keys, but not much for 2048-bit, so I'd be very inclined to make the range 1024 to 3072. To be compatible with AES, you need at least 3072, after all. 
 
If that's the case, then the corresponding range for EC should be 160 to 256. 

	-----Original Message----- 
	From: [email-masked] on behalf of Turner, Sean P. 
	Sent: Wed 12/5/2007 9:00 AM 
	To: [email-masked] 
	Cc: 
	Subject: Comments on S/MIME v3.2

	At the meeting we had some comments on the S/MIME v3.2 specs (draft-ietf-smime-3850bis-00.txt and draft-ietf-smime-3851bis-00.txt):

	 1. Define SHOULD+, SHOULD-, and MUST-. 
	 2. Update key size requirements and make sure you differentiate between RSA/DSA and EC key sizes. 
	 3. Check that there's no IPR wrt to ECDSA signed certificates and using them with S/MIME. 

	For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of any kind) so we've got our feelers out to see what we can shake loose.

	For #2 RSA/DSA key sizes - There was some discussion that the RSA key size that MUST be supported should be 1024-3076 and others felt that it should be 1024-2048.  What do people think?

	For #2 EC key size - This discussion may be premature but what should we make the sizes?  Min 256 max 384? 

	spt

---

From: Russ Housley <[email-masked]>
Date: Wed, 05 Dec 2007 16:30:19 -0500

RE #1: Seems right to copy text from RFC 4307.

RE #2: I think that 1024 and 2048 ought to be MUST.  Other sizes MAY 
be supported.

RE #3:  This seems to be the license agreement in question:
http://www.ietf.org/ietf/IPR/certicom_smime_license.pdf

At 12:00 PM 12/5/2007, Turner, Sean P. wrote:

>For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of 
>any kind) so we've got our feelers out to see what we can shake loose.
>
>For #2 RSA/DSA key sizes - There was some discussion that the RSA 
>key size that MUST be supported should be 1024-3076 and others felt 
>that it should be 1024-2048.  What do people think?
>
>For #2 EC key size - This discussion may be premature but what 
>should we make the sizes?  Min 256 max 384?
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 06 Dec 2007 16:11:52 +1300

"Luther Martin" <[email-masked]> writes:

>With respect to the RSA key sizes, I see lots of demand for 3072-bit keys,
>but not much for 2048-bit, so I'd be very inclined to make the range 1024 to
>3072. To be compatible with AES, you need at least 3072, after all.

How widely supported are values > 2K bits in hardware and crypto toolkits?
The last time I looked (which admittedly was a few years ago), you ran into
problems if you assumed that everyone could handle > 2K bit keys.

Peter.

---

From: "Luther Martin" <[email-masked]>
Date: Wed, 5 Dec 2007 20:21:18 -0800

I can't vouch for the rest of the world, but our toolkit supports 3K keys, as does the HSM that we use. 

	-----Original Message----- 
	From: Peter Gutmann [mailto:[email-masked]] 
	Sent: Wed 12/5/2007 7:11 PM 
	To: [email-masked]; Luther Martin; [email-masked] 
	Cc: 
	Subject: RE: Comments on S/MIME v3.2

	
	
	Peter.

---

From: Blake Ramsdell <[email-masked]>
Date: Thu, 6 Dec 2007 11:23:58 -0800

> How widely supported are values > 2K bits in hardware and crypto toolkits?

While I was sitting on a beach drinking Mai Tais listening to the audio of the
WG meeting, I was concerned about this exact issue.

> problems if you assumed that everyone could handle > 2K bit keys.

So there's two halves that I think should be treated separately:

* HSMs (hardware).

* Software implementations.

As for hardware, there's some amount of "it is what it is". That is, a
deployed hardware module will essentially never grow more processing power or
breed more memory. He's stuck with the algorithms and lengths that he has, for
the most part -- I imagine that there's probably some hardware module out
there that is securely upgradeable to new algorithms and keylengths. But I
would think that the nature of hardware is that it automatically obsoletes
itself every few years in general.

As for software, why is there a limitation? I admit that all of my applied
cryptogruffer experience with my own RSA implementations has been academic
(implement multi-precision integer library, modpow, admire result), but are
implementations arbitrarily stopping at some keylength, or is there some
limitation due to the implementation choice that causes a bad performance
issue, or an optimization that doesn't work over a particular keysize, or
what? I guess this is an open-ended question.

The fact of the matter is that we need to keep increasing keylengths and
changing algorithms. Do we need to start putting in SHOULD+ recommendations
for a couple of years before putting it in as a MUST? My hope is that this
would give implementors enough time to revise for the higher keylengths.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Dec 2007 15:46:24 -0800

>>  3. Check that there's no IPR wrt to ECDSA signed certificates and 

I don't see the connection. #3 is about ECDSA, but the IPR statement 
you link to says:

     More specifically, by way of example and without limiting the generality
     of the exclusions stated above, "Field of Use" does not include any
     elliptic curve implementations or Key  Exchange Algorithm (KEA)
     implementations.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Dec 2007 16:24:50 -0800

What the document says is "You need to do this" not "This is what the world
currently does"

Personally I think we should probably push the limit to 4096 on the upper
end.

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Gutmann
> Sent: Wednesday, December 05, 2007 7:12 PM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: "Luther Martin" <[email-masked]>
Date: Thu, 6 Dec 2007 16:56:27 -0800

Why would 4096 be useful? The standard levels of bit strength that NIST,
X9 and IETF documents seem to define include:

80-bit symmetric, which corresponds to 1024-bit RSA (obsolete NLT 2010)
112-bit symmetric, which corresponds to 2048-bit RSA (obsolete NLT 2030)
128-bit symmetric, which corresponds to 3072-bit RSA 
192-bit symmetric, which corresponds to 7680-bit RSA
256-bit symmetric, which corresponds to 15360-bit RSA

So I'm not sure why a 4096-bit key would be of much interest aside from
the obvious "bigger is better" argument. 

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Thursday, December 06, 2007 4:25 PM
> To: 'Peter Gutmann'; [email-masked]; Luther Martin;
[email-masked]
> > >With respect to the RSA key sizes, I see lots of demand for
3072-bit
> > keys,
> > >but not much for 2048-bit, so I'd be very inclined to make the
range
> > 1024 to
> > The last time I looked (which admittedly was a few years ago), you
ran
> > into

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 7 Dec 2007 14:00:09 -0500

Many existing common hardware tokens appear to be limited to 2048 (iKey 2032 and
4000); so making anything more than 2048 mandatory may be a problem today.
Possibly there is hidden support for bigger keys in the newer products, but with
processing proportional to the cube of the key length this would have
significant impacts because of existing smartcard technology power/processing
limits.

While 3072 might gain traction (for AES-128), one wonders about 4096 or higher.
7680 is needed for AES-192 which would make this (not 4096) the next size anyway
for encryption.

NIST, with SuiteB, is promoting a switch to EC to avoid bigger RSA keys:

http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

So making anything bigger than 2048 mandatory does not make sense to me.
Including 3072 as optional would be fine, even recommending a migration by xx
date if desired.  But RSA may not live beyond 3072 (????).

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luther Martin
Sent: December 6, 2007 7:56 PM
To: Jim Schaad; Peter Gutmann; [email-masked]; [email-masked]
Subject: RE: Comments on S/MIME v3.2

Why would 4096 be useful? The standard levels of bit strength that NIST, X9 and
IETF documents seem to define include:

80-bit symmetric, which corresponds to 1024-bit RSA (obsolete NLT 2010) 112-bit
symmetric, which corresponds to 2048-bit RSA (obsolete NLT 2030) 128-bit
symmetric, which corresponds to 3072-bit RSA 
192-bit symmetric, which corresponds to 7680-bit RSA
256-bit symmetric, which corresponds to 15360-bit RSA

So I'm not sure why a 4096-bit key would be of much interest aside from the
obvious "bigger is better" argument. 

[email-masked]
> What the document says is "You need to do this" not "This is what the 
> world currently does"
> 
3072-bit
range
> > How widely supported are values > 2K bits in hardware and crypto 
> > toolkits? The last time I looked (which admittedly was a few years 
> > ago), you
ran

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 09 Dec 2007 20:06:40 +1300

Blake Ramsdell <[email-masked]> writes:
>While I was sitting on a beach drinking Mai Tais listening to the audio of
>the WG meeting, I was concerned about this exact issue.

While I was lounging on the deck of my yacht with dusky-haired maidens
whispering a summary of the WG meeting notes in ear I had exactly the same
concerns.

>what?

Many implementations set some sort of common-sense upper limit, typically (I'd
guess) to prevent idiots who want keys that go up to 12 or even 13 from doing
just that.  See the PGP patch for using 16Kbit keys (!!!) as an example (and
this was in about 2000, when it probably would have taken half an hour just to
decrypt with one of these things).

(There's also an interop issue, if your code generates 8Kbit keys you're going
to have a serious support headache when they're not interoperable with
anything else, so there'd be a natural incentive to limits things to a sane
size).

>would give implementors enough time to revise for the higher keylengths.

That might be the best otion.

Peter.

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 10 Dec 2007 21:18:16 -0500

We also have http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA

spt 

>From: Russ Housley [mailto:[email-masked]] 
>Sent: Wednesday, December 05, 2007 4:30 PM
>To: Turner, Sean P.; [email-masked]
>Subject: Re: Comments on S/MIME v3.2
>
>RE #2: I think that 1024 and 2048 ought to be MUST.  Other 
>sizes MAY be supported.
>
>>For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of any 
>>kind) so we've got our feelers out to see what we can shake loose.
>>
>>For #2 RSA/DSA key sizes - There was some discussion that the RSA key 
>>size that MUST be supported should be 1024-3076 and others 
>felt that it 
>>should be 1024-2048.  What do people think?
>>