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

[Wayne Thayer]

On Tue, Oct 15, 2019 at 3:41 PM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

>
> 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.
>
>
I haven't fully absorbed that ballot yet, but in terms of effective dates I
would draw a distinction between the [hopefully] clear requirements imposed
by root programs in that ballot and this precertificates ballot where there
is general agreement that the requirements aren't clear.

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.
>
>
The difference, at least in theory, is that CAs are committed to comply
with the latest version of the BRs, and hence, any CA that fails to comply
by the effective date of this ballot should report the compliance issue to
their auditor, who should in turn consider that incident in their next
audit. This is regardless of any leeway offered by root programs.

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.
>
>
While this proposal has merit on its own, I don't see how this solves the
current problem. It takes us back to defining a precertificate as "not a
certificate", which solves the duplicate serial number issue in a way that
doesn't override RFC 5280. Then section 4.9.10 would need to be modified to
permit "good" OCSP responses for precertificates. However, no other BR
requirements would be imposed on precertificates, leaving that up to root
store policies like [1]. Is that the intent? If so, I'm open to that
approach, but I don't see the need to enumerate the things a CA private key
can sign to accomplish it.

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191015/4f0f441c/attachment.html>