Require separation between Issuing CAs and Policy CAs

[Peter Bowen]

Today the Mozilla CA policy and the CAB Forum categorize CAs as either
Root CAs or Intermediate CAs. However the reality is that the line is
not always clear between the two and this leads to uncertainty of what
requirements apply in various circumstances. For example, the Baseline
Requirements require that CAs do not issue Subscriber (End-Entity)
certificates from Root CAs, but a "cross-signed" CA might be able to
argue that its root is a subordinate CA.

One possible solution is to require that all certificates for CAs that
issue Subscriber certificates (those without CA:TRUE) have zero path
length constraint in the basic constraints extension. All CAs with
certificates with a longer allowed path length or no length constraint
would only be allowed to issue certificate types that a Root CA is
allowed to issue.

I think that this already is best practice for CAs and moving it to
requirement would make it possible to technically enforce the
practice.

It would not have prevented the most recent issue, but would help
prevent a whole class of other issues.

Thanks,
Peter

[Brian Smith]

Peter Bowen <pzb...@gmail.com> wrote:
> One possible solution is to require that all certificates for CAs that
> issue Subscriber certificates (those without CA:TRUE) have zero path
> length constraint in the basic constraints extension. All CAs with
> certificates with a longer allowed path length or no length constraint
> would only be allowed to issue certificate types that a Root CA is
> allowed to issue.

Consider a wildcard certificate for *.example.com. Now, consider an
intermediate CA certificate name constrained to .example.com. I don't
see why it is bad for the same CA certificate to be used to issue
both. In fact, I think it would be problematic to do so, because it
would add friction for websites to switch from wildcard certificates
to name-constrained intermediate certificates. That switch is
generally a good thing.

However, I do see how it could be valuable to separate non-constrained
intermediate CA certificates from the rest, because that would make
HPKP more effective. However, that would require not only that a
different CA certificate is used, but also that different keys were
used by the CA certificates.

Cheers,
Brian