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

[Edward Allcutt]

Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> 
>>  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.
> 
> This appears to be the Right Thing in general, and happens to also be
> the simplest for me as GnuTLS maintainer, so it is what the upstream
> GnuTLS package will use.  Or rather, it is what upstream will continue
> to use, nothing in the documentation or intended behaviour has changed
> in the last few years here.
This seems like a reasonable approach for upstream. For etch I believe 
it's too disruptive a change. For lenny... well I'm not sure. It may be 
possible to patch all the relevant apps for the first point release but:
a) I don't know if this is an acceptable "fix" now that lenny is stable.
b) A number of systems will break on upgrade until the fixes get out.
c) This should probably be added to the release notes, is that still 
possible?

>>  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.
> 
> Sounds pragmatic to me, although somewhat complex and I suspect we'll
> see increasing requests to add to that list of exceptions.  I won't
> produce a patch for this, it seems somewhat messy.
Too messy to get into etch certainly. Probably too messy for lenny too.

>>  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:
Sounds reasonable, but I'm suspicious that these special case rules 
won't turn out to match the exact set of certs that we'd wish. It also 
sounds less messy than 1) but still adding a big chunk of new code.

>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
> 
> This is essentially the (untested) patch I proposed earlier.
I have tested it. See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=144;bug=514807

I've had no issues in my (limited) testing. I'm going to deploy it to a 
more heavily used system and see if anything crops up.

>> 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.
> 
> Yes, I am beginning to think that possibly 3) may be appropriate for
> etch, although I'm not sure how large of a problem this actually is.  If
> it is not a large problem, maybe the answer should just be that they
> need to renew their certificates with a better CA (or set up their own
> CA).
I think my views for etch are clear. I should add that this is not 
simply an issue with checking my own organization's certificates. Some 
libgnutls-linked apps need to verify 3rd-party certificates which I (and 
other Debian users) have no control over. I think mail.google.com was 
mentioned as an example.

For lenny I'm far more flexible. So long as the issue gets resolved 
(soon) I don't particularly mind how. Whether 0) or 3) or some 
compromise is chosen will depend more on what changes are acceptable now 
that lenny is stable.

>> 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.
I don't disagree with your views of the big players, however I think 
this is a red herring. There does seem to be an ongoing transition away 
from v1 certs but it appears to be rather a slow process. I don't think 
GnuTLS is really in a position to strong-arm the big players into 
hurrying things along.

-- 
Edward Allcutt