[Pkg-openssl-devel] Bug#487152: Propose default_bits increase to 2048

[Steven Chamberlain]

Tags: patch

Hi,

I propose that maybe now is a good time to increase default_bits in 
/etc/ssl/openssl.cnf from 1024 to 2048.

As of this month, apparently "neither Comodo nor RapidSSL will be 
issuing certificates that are less than 2048 bit key lengths", and this 
reflects a trend among certification authorities, also including Thawte 
from September 2010, and Entrust and GoDaddy as far back as around 
December 2009.

Microsoft will supposedly expect end entity certificates (and the 
signing CA certificate) *issued* from 2011 to be a minimum of 2048-bit 
length, perhaps meaning that their Windows SSL implementations (and 
applications that make use of it, such as Internet Explorer) will 
possibly reject such certificates otherwise:

* http://www.entrust.net/knowledge-base/technote.cfm?tn=7710

NIST recommendations are cited for this change.  They advised that 
2048-bit keys be used in place of 1024-bit asymmetric keys after 2010:

* http://www.keylength.com/en/4/

Some users may have their reservations about the performance impact of 
using larger key lengths, but I think it's safe to assume 2048-bit keys 
are now set to become prevalent for HTTPS and in all places where SSL 
certificates are issued from the major CAs.

I think changing this setting in Debian would not only be a convenience 
to Debian users generating CSRs with 'openssl req -new', without having 
to manually specify a longer key length, but it is also consistent with 
Debian's 'secure by default' approach.

My attached patch updates /etc/ssl/openssl.cnf as well as the relevant 
examples in the man page req(5).  The description of the 'default_bits' 
configuration setting in that document (quoted below) is still accurate, 
in that if unspecified in the configuration file then only a 512-bit key 
would be generated.

> =item B<default_bits>
>
> This specifies the default key size in bits. If not specified then
> 512 is used. It is used if the B<-new> option is used. It can be
> overridden by using the B<-newkey> option.

I have tested my patch to confirm that the default_bits setting is 
modified correctly during a package upgrade, and that it does indeed 
result in 2048-bit instead of 1024-bit keys being generated along with 
the CSR.

The CSR for a 2048-bit key can still be signed by a pre-existing 
1024-bit CA certificate, so I don't think this change should cause 
issues with backward-compatibility.

Many thanks,
Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-default-bits-2048.patch
Type: text/x-patch
Size: 1780 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20101210/a69174e2/attachment.bin>