On Fri, Aug 30, 2019 at 11: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.

Citation needed ;-)

> 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.

That would be... inadvisable, as you'd be unrevoking a certificate, which
would definitely Be An Issue (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1532333 )

I definitely want to make sure any confusion is resolved. Can you point to
any Mozilla policies or comms that use the phrase "promise to issue a
certificate" so we can clarify? It's unclear to me if it's being used as an
unfortunate shorthand (and special apologies if I've contributed to that).

RFC 6962, Section 3.1, phrases it as such:
   "The signature on the TBSCertificate indicates the certificate
    authority's intent to issue a certificate. This intent is considered
    binding (i.e., misissuance of the Precertificate is considered equal
    to misissuance of the final certificate)."

(Some past discussion at

In various discussions, this has been attempted to be further clarified: If
a precertificate exists, for all intents and purposes of all policy
obligations, an equivalent certificate is presumed to exist, as the CA has
signaled a binding intent to do so. As a consequence, regardless of whether
or not we "see" the certificate, it should be presumed to exist, and the
OCSP status and any other certificate services, databases, or other should
be presumed to exist.

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.
> 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". 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.

Agreed that it's nonsense, but I don't see how the strict reading can lead
to that conclusion. There's more statuses than the binary Good/Revoked, and
that's extremely relevant (and the BRs Have Opinions on which statuses you
can and should use for certs you don't know about)

Despite all of the writing above, I'm too lazy to copy/paste my comment
from the Let's Encrypt issue, but I would hope any CA contemplating things
should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in
terms of a possible 'ideal' flow, and to share concerns or considerations
with that. Even better would be CAs that have suggestions on how best to
codify and memorialize that suggestion, if it's sensible and correct.
dev-security-policy mailing list

Reply via email to