Bug#514807: statistics about V1 CA Certs / general assumptions about the state of the network

[Daniel Kahn Gillmor]

Hey folks--

a bit of background on the proposals i just made, to explain where i was
coming from:

Of the certificate authorities included in ca-certificates in lenny, 20
of them (14.1%) are v1 certs:

0 dkg at pip:~$ for foo in /usr/share/ca-certificates/*/*.crt; do
> certtool -i < "$foo" 2>/dev/null | grep Version
> done | sort | uniq -c
     20 	Version: 1
    122 	Version: 3
0 dkg at pip:~$

(there are 141 certificate files, but
/usr/share/ca-certificates/cacert.org/cacert.org.crt appears to contain
two (Version 3) certificates)


My proposals were based on a few assumptions.  I hope people will
vocally disagree with any of them that they think are wrong:

 * no one that we want to support is actively making new V1 Certs
intended for use as Certificate Authorities

 * People using private Certificate Authorities (i.e. not one of the big
public ones) tend in general to have more immediate access to the people
who control the relevant CAs.

 * CA certificates do not make use of the SubjectAltName extension (i
think the use of extensions might be a V3 feature anyway)

 * When CA Certificates have a CN in their Subject, it is *not* a valid
hostname.

Here is the list of V1 certificates:

0 dkg at pip:~$ for foo in /usr/share/ca-certificates/*/*.crt; do
>     if [ $(certtool -i < "$foo" 2>/dev/null |
>            grep Version: | tr -d -c '13') = 1 ] ; then
>      echo "$foo" | sed 'sx/usr/share/ca-certificates/xx'
>     fi
> done
mozilla/Digital_Signature_Trust_Co._Global_CA_2.crt
mozilla/Digital_Signature_Trust_Co._Global_CA_4.crt
mozilla/GTE_CyberTrust_Global_Root.crt
mozilla/GTE_CyberTrust_Root_CA.crt
mozilla/IPS_Servidores_root.crt
mozilla/RSA_Root_Certificate_1.crt
mozilla/ValiCert_Class_1_VA.crt
mozilla/ValiCert_Class_2_VA.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_RSA_Secure_Server_CA.crt
0 dkg at pip:~$


Note that they're all from mozilla -- perhaps Mozilla has updated V3
certificates available from some/all of these CAs?  Verisign in
particular seems like a common culprit, but i can't find a fresh
download on their site, only fingerprints:

 https://www.verisign.com/repository/root.html

(is it even possible to transform a self-signed V1 cert into a
self-signed V3 cert?)

	--dkg

-------------- 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/2f67dc94/attachment-0001.pgp