Hi Wayne,
> > 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
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 [1], we want to inform the community that
Rich: I want to acknowledge your question, which I think is really "what is
the right forum for Mozilla TRR (DNS over HTTPS) policy [1] discussions?" I
don't currently have an answer for you, but will respond when I do.
- Wayne
[1] https://wiki.mozilla.org/Security/DOH-resolver-policy
On Wed,
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
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a
Yes, but I think this clarifies things in the wrong direction.
-Tim
> -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
>
> Subject:
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
Thank you for the report and follow-up Andy. I created
https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue.
- Wayne
On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A quick follow-up to close this out.
>
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
these two:
https://crt.sh/?id=760396354
https://crt.sh/?id=759833603
Google
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
> draft,
There's already a 6962-bis draft [1] in IESG Last Call, which (when we
finally complete it!) will obsolete RFC6962. 6962-bis redefines
9 matches
Mail list logo
