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

[Ryan Sleevi]

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/20191017/1ffed0ac/attachment.html>