From: Daniel Kahn Gillmor <d...@fifthhorseman.net>
Date: Sat, 21 Feb 2009 20:20:07 +0100
Local: Sat, Feb 21 2009 2:20 pm
Subject: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
> On 2009-02-19 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:I believe gnutls-cli (appropriately) sets
>> 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
> Shouldn't gnutls-cli mark the certificate as unverified in that case?
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@argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem -p https mail.google.comYour invocation told gnutls-cli that the certificate *was* a CA, so it
> Processed 1 CA certificate(s).
didn't have to guess whether you'd intended to use the attached
certificate as an end-entity certificate or not.
> cu and- mystified -reasHope 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
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.