On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling <r...@sectigo.com
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> > <snip>
> > If a certificate (with embedded SCTs and no CT poison extension) is
> > "presumed to exist" but the CA has not actually issued it, then to my
> > mind that's a "certificate that has not been issued"; and therefore, the
> > OCSP 'responder SHOULD NOT respond with a "good" status'.
> > However, this is Schrödinger's "certificate that has not been issued",
> > because a Precertificate has been issued that has the same serial number
> > (as the "certificate presumed to exist" that doesn't actually exist).
> > And so at this point ISTM that the OCSP responder is expected to
> > implement two conflicting requirements for the serial number in question:
> > (1) MUST respond "good", because an unrevoked/unexpired
> > precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> > response).
> > (2) SHOULD NOT respond "good" (see BR 4.9.10).
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, 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." (referring to 'certificates that have
> not been issued' from the prior paragraph)
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
We've had CAs argue, for better or worse, that they've "revoked" a
certificate by setting a revoked flag within their database, which then
will eventually result in the production of CRLs and signed OCSP responses
to reflect that status, and then distribute those responses to their CDNs
for the distribution points. In this model, the CA is arguing "revoked" is
on the basis of a change within their database, rather than the artifacts
produced from such a change. Some have even had online services (via HTML
forms) where you could check specific serial numbers, with CAPTCHAs, to
compare the database vs the produced/signed artifacts.
Similarly, we've had CAs argue that they've had certificates that were
issued, but were not active, based on a status change in their database,
where 'active' meant that they signed the certificate. This again suggests
a flow where "issued" is the status of committing to the database, rather
than producing the signed artifact.
For better or worse, if we accept that definition, which admittedly opens a
new set of issues to work through, the act of assigning the serial number
and TBSCertificate is the act of issuance, rather than the production of
the signed artifact. For better or worse, the BRs support as much with the
discussion of revocation, because the CAs that argued this highlighted that
the act of distributing OCSP/CRL responses is "publishing" the revocation
(hence the language in 4.9.5 regarding timeframes, and the language in
4.9.7 about publishing CRLs).
Recall that these issues highlighted here were not new or unexpected. If
you dig through the discussion of Ballot 134, you'll find Brian Smith
rightfully flagged these issues, which were the result of somewhat rushed
attempts to get language in the BRs. Much like Qualified Auditors within
Policy, it may be worth treating this as an exception and being deliberate
in how any matters of note or qualifications are treated, while better
language is proposed?
You can find the past discussion at
Smith, formerly of Mozilla, highlighted issues with the attempts to carve
out just duplicate serials, perhaps best in
If you look at that past discussion, you can also see debates about the
ASN.1 / SignedData approach being used, and how Precerts-are-not-Certs in
the same way that OCSPResponses-are-not-certs, even if all three used the
SignedData construct, is another interpretation, at which point, this issue
also washes out. You can also find discussions of alternative approaches,
which specified the exact encoding conditions in which a duplicate serial
would be permitted (treating precerts-as-actually-certs, rather than
> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that this is a violation. 
RFC 2560, Section 2.2, says "The "unknown" state indicates that the
responder doesn't know about the certificate being requested."
RFC 6960, Section 2.2, says "The "unknown" state indicates that the
responder doesn't know about the certificate being requested, usually
because the request indicates an unrecognized issuer that is not served by
this responder." with a rather lengthy NOTE.
This is captured in the algorithm for RFC 5280. The Algorithm in Section
6.3.3, which OCSP is meant to slot into, recognizes a status of
"UNDETERMINED", which is what UNKNOWN would map to. When encountering an
UNDETERMINED response, the idea is to continue processing other sources of
revocation - i.e., the provided revocation source does not actually provide
revocation data for that certificate. This is more relevant with CRLs and
the ability to segment them on reason codes, but was still carried over for
responders, as well as to support local responders which might be used in
preference to the configured/declared responders.
You're right to phrase the question separate from the discussion of
precertificates. If an issued certificate had only a single OCSP responder
configured in the certificates authorityInfoAccess, and that responder
returned UNKNOWN, then has the CA met the obligations of 18.104.22.168 (c) -
namely, to provide the issuer's responder? Based on reading 2560 and 6960,
the Unknown status is meant to indicate it is not the issuer's responder -
so returning Unknown seems to conflict with that, because the responder is
declaring it is not the issuer's responder.
I don't think it's reasonable to argue that 4.9.10 allows for delays in the
initial publication of the OCSP response, and that the update refers to the
time period from revocation by the CA and the publication of that
revocation, in line with 4.9.7. That is, a CA would not be complying with
4.9.9 and 22.214.171.124 (c) in providing services if it responds Unknown, even in
the initial 96 hours (4 days) allowed to delay updating the response. I
highlight this because the other interpretation "Does not know about this",
doesn't seem to fit the BRs definition of providing the service either. Of
course, if folks believe that is what should be permitted, then it's worth
taking up in the CA/B Forum.
Given that Relying Parties will, for example, actively reject Unknown
signatures if stapled in OCSP responses, because why bother stapling a
response in a first place, it seems completely unwise to release a
certificate into the ecosystem which may return Unknown status, especially
for up to 4 days. Ensuring the propagation and replication of those
responses seems to be a requirement of the BRs, and certainly within the
realm of common sense.