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

[Jeremy Rowley]

I forgot to add that although I don’t understand why we need to separate the issues, I’d still support the language you proposed.  Would we still remove the language about a pre-cert not being a cert?

Jeremy

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Jeremy Rowley via Servercert-wg
Sent: Friday, October 18, 2019 9:44 AM
To: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

For Problem 1 – One issue I’ve always had is if a pre-certificate is not considered a certificate, then how is it governed by the baseline requirements? It no longer qualifies as a certificate intended for TLS authentication in that case and thus the CA should be following the RFC instead, meaning the only thing that controls is Mozilla policy and the RFC. I don’t see a conflict because the BRs no longer apply since they remove themselves by calling a pre-cert not a cert.

Problem 2 – This one seems pretty well established from the Mozilla forum and related incident reports. Is there still confusion? Is the only objection SC23 related to problem 1 or is problem 2 still an objection?

I’m curious why there’s a need to separate the two problems since problem 2 seems pretty well established based on historical precedent.



From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, October 17, 2019 12:34 PM
To: Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

On today's call, there was more discussion about SC23 and the objectives.

One thing that required a bit of discussion was how there were two issues which, while they share the same root cause, may be able to be teased apart and solved separately, if we're more interested in solving one of them sooner. I promised Wayne I'd write it up.

= Problem 1
A concern was raised during discussion of Mozilla Policy that if Mozilla required CAs provide status information for serials they had used in precertificates, that it might be seen as requiring CAs to violate the BRs. This is because the BRs presently say "OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates", where 'such certificates' refers to the prior paragraph, "If the OCSP responder receives a request for status of a certificate that has not been issued".

Because Ballot 134 / Section 7.1.2.5 say that "a Precertificate ... shall not be considered to be a 'certificate' ...", providing a GOOD status for a Precertificate, where the CA had not (potentially yet) issued the related Certificate, would be seen as a violation of 4.9.10.

= Problem 2
Ballot 134 / Section 7.1.2.5's language that "A precertificate ... shall not be considered to be a 'certificate' subject to the requirements of RFC 5280 under these Baseline Requirements" has lead to some confusion, particularly around new CAs, about what is required in the Precertificates they sign. Because several Root Programs treat the existence of a Precertificate as proof that there may be an equivalent Certificate, which matches in issuance parameters, and thus consider a Precertificate as proof of misissuance, this leads to confusion.
  - Reusing the same serial number in unrelated Precertificates (which implies duplicate serials)
  - Extensions within a Precertificate that would be invalid in a Certificate from that CA (e.g. junk data in the subjectAltName)
  - Signing with SHA-1
  - Not needing to provide CRL services (which is related to problem #1, but we'd have to tackle *that* issue separately as well if we didn't do it holistically)
The first three examples we've seen some CAs do. The last one is a logical extrapolation of the requirements as written.



Wayne's SC23 tries to tackle both problems, but there's some reasonable concern being highlighted. I suggested that we might be able to disentangle Problem 1 from Problem 2, if it's seen as more urgent/useful to tackle Problem 1. Problem 1 solves a conflict for Root Policy evolution; Problem 2 simply clarifies things for CAs.


The suggested resolution was a ballot that *only* changes 4.9.10, to say

If the OCSP responder receives an OCSP request for the status of a serial number that has not been reserved or assigned, using any current or previous issuing key for the CA subject, then the responder SHOULD NOT respond with a "good" status. A serial number is considered reserved if it has appeared within a Precertificate, as described within RFC 6962, associated with that CA subject, either directly or via a Precertificate Signing Certificate. A serial number is considered assigned if it has appeared within a Certificate associated with that CA subject. OCSP responders for CAs that are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates. The CA SHOULD monitor the responder for such requests as part of its security response procedures.


This doesn't tackle the CRL problem I mentioned above, so it's not perfect, but CRL is optional, while OCSP is implicitly required today (due to explicitly required by Microsoft)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191018/659c2b84/attachment-0001.html>