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 d...@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 d...@pip:~$ cd /usr/share/ca-certificates/mozilla/ 0 d...@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 d...@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.
signature.asc
Description: OpenPGP digital signature