A quick follow-up to close this out.
The push to fully address the issue was completed globally shortly before 16:00
UTC on 2019-09-02.
After additional review, we're confident the only certificates affected were
Thank you for the report and follow-up Andy. I created
https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue.
On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy <
> A quick follow-up to close this out.
Yes, but I think this clarifies things in the wrong direction.
> -Original Message-
> From: Rob Stradling
> Sent: Friday, September 13, 2019 4:22 AM
> To: Tim Hollebeek ; Jeremy Rowley
> ; Alex Cohn
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
Tim Shirley did a good job of pointing it out. The relevant OCSP RFCs talk
about issued certificates, which pre-certificates aren’t. This isn’t a policy
matter, it’s a matter of a plain reading of the relevant RFCs, and trying to
align that with what people want them to say as opposed to what
We’ve been following the discussions regarding how OCSP responders should
handle Precertificates without corresponding certificates and what the
appropriate response indicator should be (good, revoked, or unknown).
Based on the recent clarifications at , we want to inform the community that
> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with Mozilla policy for all Precertificates as if
> > the corresponding certificate exists, and (ii) a CA must be able to revoke
> > a Precertificate if revocation of the certificate is
Rich: I want to acknowledge your question, which I think is really "what is
the right forum for Mozilla TRR (DNS over HTTPS) policy  discussions?" I
don't currently have an answer for you, but will respond when I do.
Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:
* Accepted Jeremy's proposed language for the examples in the last
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a
On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> So, this is something that would be helpfully clarified via either an IETF
There's already a 6962-bis draft  in IESG Last Call, which (when we
finally complete it!) will obsolete RFC6962. 6962-bis redefines
Mail list logo