Re: New undisclosed intermediates

On 09/06/2017 04:09, Jonathan Rudenberg wrote: On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy wrote: I don't believe that disclosure of root certificates is the responsibility of a CA that has cross-certified a key. For instance, the

RE: New undisclosed intermediates

That's right, Peter. They should be out of scope unless browsers want to trust them and/or they are submitted to browsers for that purpose, in which case browsers should be responsible for inputting them into the CCADB. Aside from treating these as "intermediates" or "subordinates", there

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy wrote: > >> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy >> wrote: >> >> I don't believe that disclosure of root certificates

Re: New undisclosed intermediates

> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy > wrote: > > I don't believe that disclosure of root certificates is the responsibility > of a CA that has cross-certified a key. For instance, the CCADB interface > talks in terms of

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:02 PM, Matthew Hardeman via dev-security-policy wrote: > On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote: >> I don't believe that disclosure of root certificates is the responsibility >> of a CA that has

Re: New undisclosed intermediates

On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote: > I don't believe that disclosure of root certificates is the responsibility > of a CA that has cross-certified a key. For instance, the CCADB interface > talks in terms of "Intermediate CAs". Root CAs are the responsibility of >

RE: New undisclosed intermediates

I don't believe that disclosure of root certificates is the responsibility of a CA that has cross-certified a key. For instance, the CCADB interface talks in terms of "Intermediate CAs". Root CAs are the responsibility of browsers to upload. I don't even have access to upload a "root"

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 08/06/2017 18:47, David E. Ross wrote: On 6/8/2017 2:38 AM, Gervase Markham wrote: On 02/06/17 11:28, Gervase Markham wrote: Proposal: add a bullet to section 2.3, where we define BR exceptions: "Insofar as the Baseline Requirements attempt to define their own scope, the scope of this

Re: Mozilla requirements of Symantec

On 08/06/2017 18:52, Peter Bowen wrote: On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy wrote: As the linked proposal was worded (I am not on Blink mailing lists), it seemed obvious that the original timeline was: Later: Once the

Re: Mozilla requirements of Symantec

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy wrote: > > As the linked proposal was worded (I am not on Blink mailing lists), it > seemed obvious that the original timeline was: > > Later: Once the new roots are generally accepted,

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 6/8/2017 2:38 AM, Gervase Markham wrote: > On 02/06/17 11:28, Gervase Markham wrote: >> Proposal: add a bullet to section 2.3, where we define BR exceptions: >> >> "Insofar as the Baseline Requirements attempt to define their own scope, >> the scope of this policy (section 1.1) overrides that.

Re: Mozilla requirements of Symantec

On 08/06/2017 11:09, Gervase Markham wrote: On 07/06/17 22:30, Jakob Bohm wrote: Potential clarification: By "New PKI", Mozilla apparently refers to the "Managed CAs", "Transition to a New Symantec PKI" and related parts of the plan, not to the "new roots" for the "modernized platform" / "new

RE: New undisclosed intermediates

If you added them automatically to OneCRL, how would you create new intermediates? Would it be anything over X days old and undisclosed is automatically added? If so, +1 from us. I'm pretty sure the two CAs listed from the Baltimore root don't believe these are publicly trusted intermediates.

Re: New undisclosed intermediates

On 2017-06-08 14:09, wiz...@ida.net wrote: But Censys lists it as a trusted intermediate chaining to a root ( ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation

Re: New undisclosed intermediates

On 2017-06-08 14:16, Rob Stradling wrote: crt.sh collates revocation information from all known CRL Distribution Point URLs for each CA. The CDP URLs listed at https://crt.sh/?id=12729173 were observed in other certs issued by the > same CA: That shows:

Re: Symantec response to Google proposal

On Tuesday, June 6, 2017 at 10:03:29 AM UTC-4, Gervase Markham wrote: > On 02/06/17 15:53, Gervase Markham wrote: > > https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal > > I'm slightly surprised to see no engagement here. I think many of us are worn out with the

Re: New undisclosed intermediates

On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote: On 2017-06-08 13:31, richmoor...@gmail.com wrote: This one is interesting since the domain name of the CRL resolves to an RFC 1918 IP address. Surely that is a violation of the baseline requirements.

Re: New undisclosed intermediates

But Censys lists it as a trusted intermediate chaining to a root ( ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation With respect to Gerv's question: given the

Re: New undisclosed intermediates

On 2017-06-08 13:31, richmoor...@gmail.com wrote: This one is interesting since the domain name of the CRL resolves to an RFC 1918 IP address. Surely that is a violation of the baseline requirements. https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca That

Re: New undisclosed intermediates

This one is interesting since the domain name of the CRL resolves to an RFC 1918 IP address. Surely that is a violation of the baseline requirements. https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca Regards Rich. On Thursday, June 8, 2017 at 12:45:25 AM

Root Store Policy 2.5: Call For Review and Phase-In Periods

Hi everyone, I've made the last change I currently intend to make for version 2.5 of Mozilla's Root Store Policy. The last task before shipping it is to assess whether any of the changes require a phase-in period, i.e. for some reason, they can't be applicable immediately. CAs and others are

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 02/06/17 11:28, Gervase Markham wrote: > Proposal: add a bullet to section 2.3, where we define BR exceptions: > > "Insofar as the Baseline Requirements attempt to define their own scope, > the scope of this policy (section 1.1) overrides that. Mozilla expects > CA operations relating to

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 04/06/17 03:03, Matt Palmer wrote: > For whatever it is worth, I am a fan of this way of defining "misissuance". This is an "enumerating badness" vs. "enumerating goodness" question. My original draft attempted to (without limitation) enumerate some badness, and you and Ryan are suggesting

Re: New undisclosed intermediates

On 08/06/17 10:17, Gervase Markham wrote: > What downsides would there be, other than the obvious "some sites might > break", to us just adding any such intermediate certs directly to OneCRL? We provide reports which allow CAs to download the stored intermediate cert data:

Re: New undisclosed intermediates

On 08/06/17 00:42, Jonathan Rudenberg wrote: > Yet another batch of undisclosed intermediates has shown up in CT: Like, seriously? Every CA in our program indicated that they would disclose all their intermediates by June 30th, 2016:

Re: Mozilla requirements of Symantec

On 07/06/17 22:30, Jakob Bohm wrote: > Potential clarification: By "New PKI", Mozilla apparently refers to the > "Managed CAs", "Transition to a New Symantec PKI" and related parts of > the plan, not to the "new roots" for the "modernized platform" / "new > infrastructure". I expect those things

Re: An alternate perspective on Symantec

On 07/06/17 06:14, userwithuid wrote: > 2. Having Symantec inform their subscribers, as David mentions, is a great > idea. I believe Ryan has pointed out, here or elsewhere, why "must notify customers" requirements are problematic. Gerv ___

Re: Symantec response to Google proposal

On 06/06/17 19:59, Jakob Bohm wrote: > I don't see a problem in access to this being subject to a reasonable > NDA that allows Mozilla to show it to their choice of up to 50 external > experts (I don't expect to be one of those 50). The problem with an NDA is that if the audit reports significant