The best way to codify it is at the CAB forum since the CAB Forum language is the one that causes the problem (imo). We made a mistake by defining a precertificate as “not a certificate” when the intent was mostly to allow CAs to issue precertificates that had serial numbers duplicative with the actual certificate. I was thinking we should remove overly broad language and replace it with language that is more restrictive – something like all certificates must confirm to 5280 except precertificates which must conform to 6962. Needs work of course, but that was my initial idea.
From: Ryan Sleevi <r...@sleevi.com> Sent: Friday, August 30, 2019 12:58 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Jacob Hoffman-Andrews <j...@letsencrypt.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto: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 https://groups.google.com/d/topic/mozilla.dev.security.policy/Hk78klSv8AY/discussion ) 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
