[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

Ryan Sleevi sleevi at google.com
Tue Oct 15 15:40:26 MST 2019

On Tue, Oct 15, 2019 at 5:57 PM Wayne Thayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> I think the concern here is that some CAs have interpreted the current
> section as placing no OCSP requirements on precertificates (because
> they are not within the scope of the BRs because they are not
> certificates). With the new language, this argument becomes mirky (because
> we remove the statement that precertificates are not certificates). Hence
> the assertion that this ballot does place new requirements on CAs and thus
> should include a reasonable effective date. I understand that the picture
> changes when we add root program requirements into the mix, but the scope
> of this discussion is the BRs and CA's ability to comply with them.
> Am I missing something?

Thanks, that's a helpful framing for the concern.

I agree that this becomes complex with root policies. I think it's useful
to discuss, if only for also assessing an approach that might be useful or
usable for
https://cabforum.org/pipermail/servercert-wg/2019-October/001189.html ,
which collects a number of effective requirements, some of which have
existed for 3+ years.

A phase-in certainly helps, from a BR-compliance perspective, avoid any
heartburn that things are suddenly changing. But an explicit statement like
that wouldn't resolve any of the policy compliance issues. Just because a
CA is compliant with the BRs wouldn't necessarily mean they're compliant
with root policy (as
captures). Unfortunately, an explicit statement might cause greater
confusion than its absence, as CAs may mistakenly think the BRs overriding
policy/expectations. However, it's totally possible to include a transition
date, and for individual programs to move sooner than that date; it's
functionally no different than simply permitting a transition, and leaving
individual programs to move on a similar schedule to requiring a transition.

However, to walk back a level, I think we're getting into the same question
raised during Ballot 134: "What is a precertificate?" and I can appreciate
the desire and need for precision here, and so maybe it's time to revisit
an old idea.

As mentioned, RFC 6962 tried to make it clear that a Precertificate is
not-a Certificate, but apparently didn't do as swimmingly as one would have
hoped. So how do we tackle that confusion? An approach like
https://cabforum.org/pipermail/public/2016-November/008966.html , which
Peter Bowen proposed back in November 2016, would likely address this much
clearer, and much more precisely and unambiguously.

Specifically quoting from that mail:

> Private Keys which are CA private keys must only be used to generate
> signatures
> that meet the following requirements:

1. The signature must be over a SHA-256, SHA-384, or SHA-512 hash
> 2. The data being signed must be one of the following:
>   * Self-signed CA Certificate
>   * Transitive CA Certificate
>   * End-entity Certificate
>   * Certificate Revocation Lists (as defined in [RFC 5280](
> https://tools.ietf.org/html/rfc5280))
>   * OCSP response (as defined in [RFC 6960](
> https://tools.ietf.org/html/rfc6960))
>   * Precertificate (as defined in draft-ietf-trans-rfc6962-bis)
> 3. Data that does not meet the above requirements must not be signed.

While there's definitely bit-rot in that language, the skeleton remains the
same, as the high-level concept is to explicitly enumerate the types of
things that a CA signs. While Peter only mentioned 6962-bis, we could make
it clear here that a Precertificate is not-a Certificate, provided it meets
the definition set forth in RFC 6962; that is, it's something "different"
that a CA signs, just like a SIGNED{TBSCertList} is something different, or
a BasicOCSPResponse (which doesn't use the SIGNED{} template) is something

While I realize that's a markedly different approach than what you propose
here, it's actually important and relevant to answering the 'real' question
here, which Ballot 134 imprecisely tried to resolve: "What is a
Precertificate". It does this by being much more precise if we enumerated
that the things a CA private key is used for is (Certificate,
Precertificate, CRL, OCSP), referencing the relevant RFCs. This would make
it clear a Precertificate is not-a Certificate, provided it complies with
RFC 6962/RFC 6962-bis, and any policy implications imposed for Certificates
(excluding signatures) are different. Whether or not a given browser
treated a Precertificate as proof of an equivalent Certificate can be left
for Browser/Root Policy, while the BRs could simply emphasize that there
must not be more than one serial number among all potential
SIGNED{TBSPrecertificate} and SIGNED{TBSCertificate} pairs.

I realize that may seem like a hard-left turn, but it's relevant to other
elements root programs have seen, such as SHA-1 signed Precertificates, or
on SHA-1 signed OCSP responses-with-nonces from CA certificates, by making
it clearer that policies are on what a CA key signs, and making it clear
that Precertificates and Certificates are "different" things a CA signs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191015/dcb22211/attachment-0001.html>

More information about the Servercert-wg mailing list