Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Feb 21 19:05:07 UTC 2009
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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 890 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20090221/4e5d8c75/attachment.pgp
More information about the Pkg-gnutls-maint