Bug#514807: Regression in libgnutls security update

[Daniel Kahn Gillmor]

On 02/11/2009 06:05 PM, Florian Weimer wrote:
> I think it is somewhat debatable if this also applies to the root CA
> container, where the X.509 structure is just use as a transport for
> key material.  The RSA-MD5 signature does not hurt there, and the DN
> doesn't really matter, either.  The risk I see is that someone adds a
> v1 *server* certificate to the trusted list, without realizing that it
> will act as a *CA* certificate in this place.

if the trusted certificate list were simply a "root CA container", then
i'd agree with you that V1 certificates are acceptable there.  But
that's not how the list is treated (or has ever been treated, to my
knowledge) in GnuTLS.

I think your last sentence makes it clear what the risks are.  GnuTLS
declares that the trusted certificate list is for holding *any type of*
trusted certificate.  If a given trusted certificate is a server
(end-entity) cert, then the remote party will be validated if it offers
that exact certificate (and if its name matches, and it can prove
possession of the corresponding secret key, presumably).  If a given
trusted certificate is a CA cert, then any certificate chain where the
end entity certificate matches the name of the remote party, and which
is rooted in the trusted CA cert will be accepted.

These are two different ways to use the trusted certificate list, and
they are distinguished by the *type* of certificate added to the list.
IIUC, Nikos' post indicates that there is no way to distinguish a V1 CA
certificate from an end-entity certificate.  So adding one to any
trusted store is inherently a risky activity, particularly if you're
adding a certificate that you expect to be an end-entity instead of a
CA.  GnuTLS has no way of knowing what the user's intent is here.

One option, of course, is to change the interface of GnuTLS to cleanly
separate out trusted peer certificates from trusted CA certificates in
the API.  This would permit users to specify how they intend to use a
given V1 cert.  Of course, this would also require an API change,
potentially an soname bump, etc.  In the absence of such a change, i
think it's safer to strongly deprecate V1 certificates (as has been
documented for years, if not enforcced), and let applications which
choose to treat the trusted certificate list solely as a CA store
specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20090211/fc8a0fe1/attachment.pgp