On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
<snip>
> Here's some suggested wording for the last paragraph:
>
>> This means, for example, that (i) a CA must provide OCSP services
>> and responses in accordance with Mozilla policy for all certificates
>> presumed to exist based on the presence of a Precertificate, even if the
>> certificate does not actually exist, and (ii) a CA must be able to revoke
>> a certificate presumed to exist, if revocation of the certificate is required
>> under Mozilla policy, even if the certificate does not actually exist.
[Speaking only for myself]
Wayne, Andrew,
Please treat this message as a sincere attempt both to understand what
the current requirements actually are and to seek to clarify what the
requirements should be.
ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respond with
a "good" status.'
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).
Clearly that's impossible, which leads to the question: Which of these
two conflicting requirements should a CA ignore in order to be as
un-non-compliant as possible? Which leads me to BR 7.1.2.5:
'For purposes of clarification, a Precertificate, as described in RFC
6962 – Certificate Transparency, shall not be considered to be a
“certificate” subject to the requirements of RFC 5280'
Since the first mention of "certificates" in the OCSP Protocol Overview
(RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
not be considered to be a "certificate"' declaration can be assumed to
extend to the OCSP requirements too. And therefore, the balance tilts
in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
respond "good"'.
I can't say I like this conclusion, but nonetheless it is the conclusion
that my reading of the BRs forces me to reach. I realize that what the
BRs actually say may not reflect precisely what was intended by
CABForum; nonetheless, CAs are measured by what the BRs actually say.
IDEAS FOR FIXING IT:
Long-term:
- In CT v2 (6962-bis), precertificates are not X.509 certificates,
which removes Schrödinger from the equation. :-)
Short-term:
- I think BR 7.1.2.5, as written, is decidedly unhelpful and should
be revised to have a much smaller scope. Surely only the serial number
uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
not the entirety of RFC5280?
- I would also like to see BR 4.9.10 revised to say something roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
that has not been allocated by the CA, then the responder SHOULD NOT
respond with a "good" status.'
P.S. Full disclosure: Sectigo currently provides an (unsigned)
"unauthorized" OCSP response when a precert exists but the corresponding
cert doesn't, but in all honesty I'm not currently persuaded that an
Incident Report is warranted.
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
