Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

On 02/07/2020 13:31, Corey Bonnell via dev-security-policy wrote: > Wouldn't adding the nocheck extension make the subCA certificate irrevocable, > thus in the case of a subCA certificate with serverAuth and ocspSigning EKUs, > violate the spirit (and maybe the wording?) of sections 4.9.7 and

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 02/07/2020 12:52, Pedro Fuentes via dev-security-policy wrote: > If we look at the BR, it says: > "[^**]: Generally Extended Key Usage will only appear within end entity > certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate > CAs MAY include the extension to further

Re: GTS - OCSP serving issue 2020-04-09

On 19/04/2020 11:13, Nick Lamb via dev-security-policy wrote: On Sat, 18 Apr 2020 22:57:03 -0400 Ryan Sleevi via dev-security-policy wrote: The Baseline Requirements address this. See 9.16.3 (particularly item 5) and 9.6.1 (6). For better or worse, the situation is as Neil described and

Re: GTS - OCSP serving issue 2020-04-09

On 17/04/2020 14:22, Nick Lamb via dev-security-policy wrote: GOOD means_at least_ the good CertStatus (also 0) in OCSP. We'll see why in a moment. Fair enough. That's what I thought - so holding onto the last successful OCSP report you have, even if you get exception status codes

Re: GTS - OCSP serving issue 2020-04-09

On 16/04/2020 14:49, Kurt Roeckx via dev-security-policy wrote: On 2020-04-16 14:56, Neil Dunbar wrote: I would have thought that an OCSP-stapling implementation which got an OCSP status code 'successful' (0) with a 'revoked' status for the certificate would want to pass that on to the

Re: GTS - OCSP serving issue 2020-04-09

On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote: Specifically: You should cache your stapled GOOD answers in durable storage if practical, and when periodically refreshing you should report non-GOOD answers to the operator (e.g. logging them as an ERROR condition) but always

Re: DigiCert OCSP services returns 1 byte

> On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy > wrote: > > > […] it seems like one useful change for us > here may be to issue those final certs without the SCTs rather than > abandoning the pre-cert as we do today. We'd obviously still need to > re-attempt issuance of

Re: OCSP responder support for SHA256 issuer identifier info

I think that, if the responder is capable of understanding another hash (e.g. SHA-256), and has support for that built into its backend database, returning the CertID with those supported hashes is fine and good. IMO, there should be no prohibition on supporting alternative hash algorithms.

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 > <mailto:dev-security-policy@lists.mozilla.org>> wrote: > >>

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 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy > wrote: > > The language says you have to provide the response for the cert as if it > exists, but the reality is that sending a response for the precert is the > same as calculating the result for the certificate as if it

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

> On 30 Aug 2019, at 02:44, Kirk Hall via dev-security-policy > > wrote: > > OK, I'll try one last time to see if you are willing to share Google > information that you have with this group on the question at hand (Do browser > phishing filters

Misissuance Report: Incorrect CA-Issuers URI in some certificates

To m.d.s.p, The following contains an incident report, compiled as a result of the release of two example certificates with an incorrect CA-Issuers URI included. Any questions or observations on this incident are gratefully received, and I will endeavour to answer them as quickly as I can.

Incident Report: TrustCor Serial Number Entropy

All, Included is an incident report, formatted per the Mozilla recommendations, with timelines and resolutions. Wayne - if you want to create a bug to track this, I’m happy to respond either there or here on m.d.s.p. Regards, Neil Dunbar CA Administrator, TrustCor Systems S. de R.L. -

Re: question about DNS CAA and S/MIME certificates

> On 15 May 2018, at 07:59, Matthew Hardeman wrote: > > For that matter, can whoever is in charge of gmail.com > speak to their intent as to CAA for S/MIME? > > I've certainly held certificates which include my personal gmail address > before. At no

Re: question about DNS CAA and S/MIME certificates

> On 15 May 2018, at 05:56, Ryan Sleevi wrote: > > No. I am expressly opposed to any solution that is “ask the big guys and let > them decide what it means for the Internet”. > > While I can’t speak for Mozilla, that definitely seems against the spirit of > Mozilla’s

Re: question about DNS CAA and S/MIME certificates

> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy > wrote: > > If there are proponents of a 'fail open' model, > especially amongst CAs, then does it behove them to specify as quickly as > possible a 'fail closed' model, so that we don't

Re: question about DNS CAA and S/MIME certificates

But it also seems reasonable for organisations making CAA assertions to know the scope of their stipulations before they make them, no? So, if in the case of Yahoo, they make the assertion “All of our web certificates should come from DigiCert”, are they aware that they are also making the

Re: TrustCor root inclusion request

regards, Neil Dunbar TrustCor CA Administrator > On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Mon, 14 Aug 2017 20:27:05 +0100 > Neil Dunbar via dev-security-policy > <dev-security-policy@lists.moz

Re: TrustCor root inclusion request

Andrew, Many thanks for reading and commenting on the policy documents. In order to clarify and correct the issues which you highlight, new versions (at version 1.3.2) of both CP and CPS have been published. A summary of our actions follows. Paragraphs introduced with the text "" indicate our

Re: TrustCor root inclusion request

Andrew. Thank you for the review, comments and questions on TrustCor's policy documents. We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list. Have

Re: TrustCor root inclusion request

Andrew. Thank you for the review, comments and questions on TrustCor's policy documents. We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list. Have

Re: TrustCor root inclusion request

Andrew. Thank you for the review, comments and questions on TrustCor's policy documents. We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list. Have a

Re: TrustCor root inclusion request

> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy > wrote: > > On 18/05/17 23:40, Nick Lamb wrote: >> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong >> here? Judging from self-assessment document, TrustCor's actual >>