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

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Feb 19 01:12:06 UTC 2009

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:

0 dkg at pip:~$ echo | gnutls-cli --print-cert -p https mail.google.com |
> certtool -i | egrep '(Issuer|Subject):' | tr -d '\t'
Issuer: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
Subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=mail.google.com
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification
Subject: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
0 dkg at pip:~$ cd /usr/share/ca-certificates/mozilla/
0 dkg at pip:.../mozilla$ for foo in Verisign_Class_3_*.crt; do
>  printf "%s %d\n" $foo \
>  $(certtool -i <$foo | grep Version: | tr -d -c '13')
> done
Verisign_Class_3_Public_Primary_Certification_Authority.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt 1
0 dkg at pip:.../mozilla$

I have two alternate proposals that could be considered for etch and/or
Lenny.  So including the current state of the package and a full revert,
i see 4 options, and i'd be really happy to get feedback:


 0) Leave the library as it is; tools must use GnuTLS in the documented
way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
trust V1 certificates as certificate authorities.

 1) same as 0, but we special-case the limited set of publically-known
V1 CA certificates shipped in the ca-certificates package: if any of
those exact certificates are included in the trusted certificates list,
they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is not set.

 2) same as 1, but rather than test exact matches against the specific
V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
if they meet the following requirements:

 a) The V1 certificate must not have any SubjectAltName extensions (i
think extensions in general require X.509v3, so this may be moot)

 b) If the V1 certificate Subject has a CN, the CN must not be a
syntactically-valid hostname.  For example, it should have spaces or
slashes or some other character that is forbidden A RR labels in DNS.

3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set (this may
mean that there is *no way* to turn this flag off -- hopefully people
who know gnutls better than myself can say if this is the case)


2a and 2b are intended to weed out certificates that were originally
issued with the intent of being an end-entity certificate for a host or
public service.  I tried to come up with some limit 2c, to reject
certificates that had been issued to non-host end entities (usually end
user client certificates), or to come up with some other matching rule
(e.g. "the Subject should contain the string 'Authority'") but i haven't
come up with anything satisfactory.  Suggestions are welcome.

These are listed in the order that i personally prefer them (that is, i
prefer 0 to the others, 1 over 2 and 3, and 2 over 3).  Do other people
have opinions here?  I have no code ready to implement 1 or 2, but i
would be happy to try to help folks generate or assess such a patch if
there are people willing to advocate for it.

Also: maybe we want to use one approach for etch, and a different one
for lenny.  With a well-thought out transition strategy, we could
minimize some of the potential pain.



PS i really don't like the monopolistic/money-grubbing/unethical
behavior of most of the dominant commercial CAs; i feel like their
general motives are at odds with my personal goals of having end-to-end
secure connections available for any netizen.  So explicitly
grandfathering these groups into gnutls X.509 verification (option 1)
irks me not a little bit.  However, newer CAs can (and do) use V3 root
certs, so i don't feel that we would be further entrenching the
800-pound gorillas.

-------------- 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/20090218/07681e5b/attachment-0003.pgp 

More information about the Pkg-gnutls-maint mailing list