trusted intermediate CAs [was: Re: The _gnutls_x509_verify_certificate fix]

[Daniel Kahn Gillmor]

On Tue 2008-11-11 10:51:45 -0500, Simon Josefsson wrote:

> RFC 3280 section 6 contains one algorithm, and I think we need good
> arguments to deviate from it.
>
> I believe it is useful to explicitly trust an intermediate CA
> certificate rather than the root CA though: consider if I purchase a
> CA certificate from VeriSign: on some environments, I may want to
> configure applications to trust my CA (whose private key I control)
> rather then VeriSign's.

I fully agree with Simon on this.  There are many circumstances where
you'd like your systems to be able to trust *only* a narrower CA that
*you* control, while still letting external parties who trust a
broader CA cleanly validate the certificate chain.  Explicit trust in
a CA who happens to be intermediate in a specific chain must be
allowed to validate the target certificate for this to work.

i think certtool(1) is problematic in that way, fwiw:

      -e, --verify-chain
              Verify a PEM encoded certificate chain.  The last certificate in
              the chain must be a self signed one.

> Opens up for problems with revocation of my CA certificate, but
> still...

Revocation of the cert for the intermediate CA is only meaningful if
you trust the parent CA in the first place.  Your intermediate CA
could actually have several certificates (each from a different root
CA), and one root CA should be able to revoke its certificate without
affecting people who don't care about it.

It does raise an interesting question of what to do if you "trust"
both the intermediate CA and the root CA, and the root CA has revoked
the cert that you have for the intermediate CA, though.  Should the
intermediate CA still be trusted in that case?

The proper way to handle this kind of flexibility is with OpenPGP
certificates, but we've still got work to do before that
infrastructure is widely adopted.

        --dkg

pgpGYpRsfS3Ik.pgp
Description: PGP signature