Bug#703587: libnss3 update disables some (self signed) certs (with Icedove)

[Daniel Kahn Gillmor]

Hi Philonous--

On 03/24/2013 08:40 AM, Philonous Atio wrote:

> Perhaps my phrasing was not quite clear, but the remote server's
> certificate was NOT loaded into the Authorities section -- I wanted to
> avoid the need to load the server's certificate at all. I meant to
> convey that a self-signed Certificate Authority (CA) signed the server's
> certificate. It was the self-signed Certificate Authority's certificate
> that was loaded into the "Authorities" section (i.e. root key store) of
> Icedove.

In X.509, all Root Certificate Authority Certificates are self-signed,
but not all self-signed certificates are Root Certificate Authority
Certificates.  Self-signed certificates that identify services directly
are "self-signed End Entity Certificates".  "End Entity" is sometimes
referred to as "EE" and "Certificate Authority" is sometimes referred to
as "CA".

> That CA has signed multiple certificates used in various
> places. The key material for the Certificate Authority is well guarded.

The certificates issued by this CA for services that end users connect
to are regular End Entity certificates.  If that End Entity certificate
is signed by any CA using MD5 as the signature digest algorithm, then
NSS *should* reject it.  Using MD5 for X.509 signatures of intermediate
CAs and EE certificates has been a bad idea for years (and was actively
exploited as far back as 2008 [0].

The reason that MD5 is acceptable for the root CA certificate is that
the digest algorithm in a root CA certificate is irrelevant -- the full
raw public key material is available in the certificate itself, so it
doesn't matter what kind of wrapping it has.

So: if you're operating a certificate authority, you really need to
ensure that all of the certificates issued by that authority which you
expect to be in use on the 'net today use signatures over digest
algorithms that are at least as strong as SHA-1.

NSS is among the TLS libraries that enforce this requirement, so that
the users of these libraries can't lose their communications integrity
and privacy via this sort of attack.

If you ask Icedove to connect to a server like this, it will provide a
message like "Certificate is not trusted, because it hasn't been
verified by a trusted authority using a secure signature" or "The
certificate was signed using a signature algorithm that is disabled
because it is not secure."

This is the Right Thing for NSS to do.  It would be irresponsible for
NSS to consider intermediate CA or EE certificates as legitimate if they
are using MD5 as the signature digest algorithm.

Regards,

	--dkg

[0] http://www.win.tue.nl/hashclash/rogue-ca/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/attachments/20130324/cce5da65/attachment.pgp>