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

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> For example, the certificate used by https://mail.google.com/ appears to
> be rooted in a v1 CA certificate:

Sigh, one would have hoped they had more clue.

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

I realize 0) may not be ideal from a systems perspective, in particular
for etch, but I'm not the best person to judge that.

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

>  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)

I think you are correct, extensions require V3.  If there are any
extensions in a V1 cert, the cert should be rejected as invalid.

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

Nice idea.  Sounds like it could work.

> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set

This is essentially the (untested) patch I proposed earlier.

> (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)

Applications can still call gnutls_certificate_set_verify_flags to
override the default.

While I was negative initially, I think there are some arguments for
this solution: it only enables V1 CAs that the user has _explicitly_
marked as trusted.  So the user could be informed through documentation
that if he adds V1 CAs as a trusted certs, they may lead to the security
problems with V1 certs.  I don't think we'll make this change upstream,
the risks associated doesn't seem negligible and I think V1 certs should
just go away.

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

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

Personally, I don't have time to develop and maintain patches for 1) or
2), and prefer choosing between 0) and 3) -- however, that opinion is
biased because I'm a gnutls developer rather than a debian developer
with a focus on the behaviour of the entire distribution.

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

This is one of the reasons why I am for option 0) in the official GnuTLS
package, and strongly against any other option in the official package.
However, I realize that Debian may chose to patch the etch version of
GnuTLS differently.

/Simon