Re: DigiCert OCSP services returns 1 byte

Version 3 of my proposal replaces Jeremy's suggested examples with Andrew and Ryan's: The current implementation of Certificate Transparency does not provide any > way for Relying Parties to determine if a certificate corresponding to a > given precertificate has or has not been issued. It is

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of September 2019 Audit Reminder Emails Date: Tue, 17 Sep 2019 19:00:10 + (GMT) Mozilla: Your root is in danger of being removed CA Owner: AC Camerfirma, S.A. Root Certificates: Chambers of Commerce Root - 2008** Global Chambersign

Re: CRL for decommissioned CA

On Tue, Sep 17, 2019 at 8:23 AM nenyotoso--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi, > > While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and > is no longer in operation [2], > I become aware of CRL endpoint of both the CA and at least

Re: DigiCert OCSP services returns 1 byte

> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy > wrote: > > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy < > dev-security-policy@lists.mozilla.org > > wrote: > >> >> >>> On 17 Sep 2019, at 14:34, Rob

CRL for decommissioned CA

Hi, While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and is no longer in operation [2], I become aware of CRL endpoint of both the CA and at least one of sub-CA is unavailable. a sub-CA: https://crt.sh/?id=9341006 leaf certificate issued from the sub-CA:

Re: DigiCert OCSP services returns 1 byte

On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > Hi Kurt. I agree, hence why I proposed: > > > >

Re: DigiCert OCSP services returns 1 byte

> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy > wrote: > > Hi Kurt. I agree, hence why I proposed: > > "- I would also like to see BR 4.9.10 revised to say something roughly > along these lines: >'If the OCSP responder receives a status request for a serial number

Re: DigiCert OCSP services returns 1 byte

On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote: > On 2019-09-16 14:02, Rob Stradling wrote: >> >> ISTM that this "certificate presumed to exist" concept doesn't play >> nicely with the current wording of BR 4.9.10: >>     'If the OCSP responder receives a request for status of a

Re: DigiCert OCSP services returns 1 byte

On 16/09/2019 23:58, Wayne Thayer wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > And so at this point ISTM that the OCSP responder is expected to > implement two conflicting requirements for the serial number in > question: >    (1) MUST respond "good", because

Re: DigiCert OCSP services returns 1 byte

On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > > > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: > > > > > > If a certificate (with embedded SCTs and

Re: DigiCert OCSP services returns 1 byte

On 2019-09-16 14:02, Rob Stradling wrote: ISTM that this "certificate presumed to exist" concept doesn't play nicely with the current wording of BR 4.9.10: 'If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT

Re: DigiCert OCSP services returns 1 byte

On 17/09/2019 00:58, Wayne Thayer wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > >> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: >> >> >> If a certificate (with embedded SCTs and no CT poison extension) is >> "presumed to exist" but the CA has not actually