On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good. However, if "a promise to issue a
> certificate" is not the same as issuance, the BRs don't apply to the OCSP
> until the certificate issues and the correct response is "Revoked" per the
> RFC.
> The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.

It seems reasonable to me to assume that if the contents of a
precertificate are in-scope for the BRs, the OCSP responses would be
likewise in-scope.

> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good".

I agree. A CA cannot prove they didn't issue the final certificate. Given
existence of a pre-certificate, it is reasonable for a relying party to
assume that the final certificate exists and therefore that OCSP services
will be functional. I personally would view arguments such as "we didn't
actually issue that, so we don't need to provide sane OCSP responses" with
a great deal of skepticism, especially from CAs that do not automatically
CT log their final certificates (nudge nudge DigiCert, Amazon, Entrust).

However, a very strict reading of the RFC and BR interaction means you need
> to respond "Revoked" until the cert issues. I don't like that outcome
> because it's complicated and leads to confusion.

Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the
requirement to respond "revoked" for unknown or non-issued certificates -
can you explain further? 4.9.10 forbids replying "good" for non-issued
certificates, but I don't see any stipulations surrounding replying
"unknown." The certificateHold + 1970-1-1 revocation date method of
indicating a non-issued certificate in 6960 2.2 might be forbidden by an
especially strict reading of BRs 4.9.13, but it's not mandated by 6960. In
the absence of a precertificate signing certificate, OCSP queries for
precertificate and certificate are identical, so it could be argued that
the precertificate itself means it's not a "non-issued" certificate?

>From a RP's perspective, I can easily envision problems resulting from an
OCSP response for a given serial number transitioning from revoked to good,
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests
for precertificates from final certificates. How do these CAs handle OCSP
for precertificates? Trustwave appears to always answer "unauthorized
<https://crt.sh/?id=1827579322&opt=ocsp>" and NetLock "malformed
<https://crt.sh/?id=1826448700&opt=ocsp>", which is...curious.

dev-security-policy mailing list

Reply via email to