Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)

[Daniel Kahn Gillmor]

On 02/21/2009 04:16 AM, Andreas Metzler wrote:
> On 2009-02-19 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> I've done a bit of research on this bug (dealing with V1 CA certificates
>> for gnutls in etch and/or lenny), and i do think that it is potentially
>> quite serious.
> 
>> For example, the certificate used by https://mail.google.com/ appears to
>> be rooted in a v1 CA certificate:
> [...]
> 
> Shouldn't gnutls-cli mark the certificate as unverified in that case?

I believe gnutls-cli (appropriately) sets
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, because the semantics of its
invocation indicate that the certificates passed to the trusted store
are explicitly limited to CA certificates, and cannot possibly be
end-entity certificates.

> ametzler at argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem  -p https mail.google.com
> Processed 1 CA certificate(s).

Your invocation told gnutls-cli that the certificate *was* a CA, so it
didn't have to guess whether you'd intended to use the attached
certificate as an end-entity certificate or not.

> cu and- mystified -reas

Hope this helps de-mystify somewhat.  Frankly, the V1 vs. V3 business
seems to me to be as much a problem with the GnuTLS API as it does with
the crusty old X.509v1 specification.  If GnuTLS certificate validation
were to use two different user-provided lists of certificates: one of
explicit CAs and one of potential peers (End Entities), this whole
discussion would be moot.

But of course, that's not what it does: applications provide the
verification code with a single list of pre-verified "trusted"
certificates, and GnuTLS distinguishes between End Entities and CAs
based on attributes *within* each cert in the list (and apparently V1
certs have no such distinguishing attributes).  In practice, i suspect
that many software authors who use GnuTLS haven't been aware of this
subtle distinction.

hth,

	--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/20090221/4e5d8c75/attachment.pgp