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

[Ryan Sleevi]

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 7.1.2.5 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
https://cabforum.org/pipermail/servercert-wg/2019-October/001189.html
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
different.

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>