[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re: IKEv2 Key Size Conformance Requirements



Hi List

There was some discussion on a recent issue of crytogram about recommended
key sizes - basically the opinion was that 1024 bits was no longer long
enough for "high" security requirements. Based on this, and published
research by PWC, we decided to use 1280 bit key sizes for our own certs.
I.e. least increase necessary (in steps of 256 bits) to give an "adequate"
level of security.

They are soft certs, and have been used in a number of S/MIME and SSL
implementations. The key size hasn't caused problems with any software yet.
It is still an open question as to how many smartcards would be able to
generate keys of any size larger than 1024.

Unfortunatly, we haven't used these certs with any IPsec devices, so I don't
know if they would cause problems with IPsec implementations out there.

In general, my experience of key lengths in deployment has been
user certs - 1024 bits
CA certs - 2048 bits

Pearse


-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Peter Gutmann
Sent: 30 October 2002 14:30
To: ipsec@lists.tislabs.com
Subject: Fwd: Re: IKEv2 Key Size Conformance Requirements


[Please CC replies to me, since I'm not on the list]

Paul Hoffman / VPNC <paul.hoffman@vpnc.org> writes:
>At 4:07 PM -0500 10/28/02, Stephen Kent wrote:
>>At 9:07 AM -0800 10/28/02, Paul Hoffman / VPNC wrote:
>>>At 12:01 PM -0500 10/28/02, Housley, Russ wrote:
>>>>No.  A CA, not a IPsec implementation, creates certificates.
>>>
>>>Er, right, of course. How about:
>>>
>>>>>A conforming implementation MUST be able to sign and authenticate with
X.509
>>>>>certificates containing and signed by RSA keys of size 1024, 1536, and
>>>>>2048 bits. It MAY process X.509 certificates of any size. If there is a
>>>>>limit on the length of a certificate chain, it MUST be at least 10.
>>>>>
>>>>>   A conforming implementation MAY accept X.509 certificates containing
>>>>>   and signed by non-RSA keys, such as DSS keys.
>>
>>I'd like to second Russ's suggestion of making 1024 & 2048-bit RSA keys
>>the only MUSTs for now, re the size of keys used for cert signing.
>
>The reason I included 1536 is that I see this setting in CA products (I
>haven't checked out "in the wild" and am not sure that such a survey would
>make any sense). Is there an issue with 1536 that makes us not want to
>include it?

I don't recall ever seeing a 1536-bit key being used, unless it was one that
I
archived without looking at it much (I'd need a grepasn1 alongside dumpasn1
to
actually check each cert).  As a rule of thumb, where a few years ago you
had
512-bit certs with the odd gold-plated 1024-bit one for CAs, you're now
seeing
1024-bit with 2048-bit gold-plated ones for CAs.  1536 seems to have been
skipped entirely (I know that in several cases 2048 is used because that's
the
biggest the CA hardware will do, rather than because of any real security
evaluation).  If anyone wants a rigorous check of certs, I'll see if I can
come up with a RE which lets me check dumpasn1 output for the key size.

Peter.