On 02/21/2009 04:16 AM, Andreas Metzler wrote: > On 2009-02-19 Daniel Kahn Gillmor <d...@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.
> ametz...@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
signature.asc
Description: OpenPGP digital signature
