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

[Daniel Kahn Gillmor]

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
Authority
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.

Thoughts?

	--dkg

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