Re: New undisclosed intermediates

On 09/06/17 16:37, Jakob Bohm wrote: > This seems to directly violate the often proposed (but apparently not > yet enacted) rule that different root certs must have different keys > (if that rule has been incorporated into a current policy). This has come up enough times now that I've filed an

Re: New undisclosed intermediates

> On Jun 8, 2017, at 05:17, Gervase Markham via dev-security-policy > wrote: > > On 08/06/17 00:42, Jonathan Rudenberg wrote: >> Yet another batch of undisclosed intermediates has shown up in CT: > > Like, seriously? Another one appeared this weekend:

Re: New undisclosed intermediates

On 08/06/17 14:15, Rob Stradling via dev-security-policy wrote: On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote: 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

Re: New undisclosed intermediates

On 2017-06-08 at 04:31 -0700, richmoore44--- via dev-security-policy 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

On 2017-06-08 at 04:31 -0700, richmoore44--- via dev-security-policy 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

On Friday, June 9, 2017 at 11:52:53 AM UTC-5, Ryan Sleevi wrote: > So that would be an arguement for disclosing both self-signed and > self-issued certificates, and align with the "Disclose what the key does" > mentality. That was essentially the point I was trying to make. Of all the things to

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 10:16 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are two important things about self-issued certificates: > > 1) They cannot expand the scope of what is allowed. > Cross-certificates can create alternative paths with

Re: New undisclosed intermediates

On Fri, Jun 9, 2017 at 9:11 AM, Matthew Hardeman via dev-security-policy wrote: > For these self-signed roots which have a certificate subject and key which > match to a different certificate which is in a trusted path (like an > intermediate to a trusted

Re: New undisclosed intermediates

For these self-signed roots which have a certificate subject and key which match to a different certificate which is in a trusted path (like an intermediate to a trusted root), the concern is that the mere existence of the certificate speaks to a signature produced by a private key which DOES

Re: New undisclosed intermediates

On 09/06/2017 12:29, Rob Stradling wrote: On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote: What in the policy says they become in-scope from a certificate chain that isn't "anchored" at a Mozilla trusted root? And would someone please post those alleged certificate chains

Re: New undisclosed intermediates

On 09/06/17 11:29, Rob Stradling wrote: > These two certs share the same Name and Key. Therefore, the signature > on the first can be verified by the public key in the second; and vice > versa. And clearly the Subject Name in each one matches the Issuer Name > in the other. This means that the

Re: New undisclosed intermediates

On 08/06/17 15:37, Jeremy Rowley wrote: > 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? Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy 2.5, is a week

Re: New undisclosed intermediates

On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote: What in the policy says they become in-scope from a certificate chain that isn't "anchored" at a Mozilla trusted root? And would someone please post those alleged certificate chains *explicitly* here, not just say they saw it

Re: New undisclosed intermediates

On 09/06/2017 11:57, Rob Stradling wrote: On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote: 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

Re: New undisclosed intermediates

On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote: 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:

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

Sent: Thursday, June 8, 2017 8:17 PM To: Jonathan Rudenberg <jonat...@titanous.com> Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New undisclosed intermediates On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via

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

ad a "root" certificate. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Kurt Roeckx via dev-security-policy Sent: Thursday, June 8, 2017 6:40 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject:

RE: New undisclosed intermediates

ty-pol...@lists.mozilla.org Subject: 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 3

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: 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

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: New undisclosed intermediates

> On Jun 7, 2017, at 21:56, Matthew Hardeman via dev-security-policy > wrote: > > On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote: > >> Yet another batch of undisclosed intermediates has shown up in CT: >> >> - >>

Re: New undisclosed intermediates

On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote: > Yet another batch of undisclosed intermediates has shown up in CT: > > - > https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8 > - >

Re: New undisclosed intermediates

> On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy > wrote: > > Happy Monday! > > Another week, another set of intermediate certs that have shown up in CT > without having been properly disclosed: >

Re: New undisclosed intermediates

On Tuesday, June 6, 2017 at 4:14:00 AM UTC-5, Gervase Markham wrote: > On 05/06/17 14:29, Alex Gaynor wrote: > > As I've expressed before, I find it baffling that this still happens. > > I am also disappointed. I have half a mind to keep track of how often > this happens per CA, and impose a

RE: New undisclosed intermediates

@lists.mozilla.org] On Behalf Of Stephen Davidson via dev-security-policy Sent: martes, 6 de junio de 2017 15:59 To: Alex Gaynor <agay...@mozilla.com>; MozPol <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: New undisclosed intermediates Hello: I acknowledge that QuoVadis Grid ICA2 was

RE: New undisclosed intermediates

Hello: I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB. The omission was human error (my own) when entering a group of issuing CAs into SalesForce. Ongoing, when new ICAs are created, the CCADB disclosure is part of our process. For the sake of clarity, that ICA is disclosed

Re: New undisclosed intermediates

On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote: On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy < Alex, do you have the specific list of CAs at the time of your posting? Yes, it was: * QuoVadis * AC Camerfirma, S.A. * Chunghwa Telecom Corporation * Start

Re: New undisclosed intermediates

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 05/06/17 14:29, Alex Gaynor wrote: > > > As I've

Re: New undisclosed intermediates

On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/06/17 14:29, Alex Gaynor wrote: > > As I've expressed before, I find it baffling that this still happens. > > I am also disappointed. I have half a mind to keep track of

Re: New undisclosed intermediates

On Tue, Jun 06, 2017 at 10:13:20AM +0100, Gervase Markham via dev-security-policy wrote: > Aside from taking a note of how often this happens and it perhaps > appearing in a future CA investigation as part of evidence of > incompetence, does anyone else have ideas about how we can further >

Re: New undisclosed intermediates

On 05/06/17 14:29, Alex Gaynor wrote: > As I've expressed before, I find it baffling that this still happens. I am also disappointed. I have half a mind to keep track of how often this happens per CA, and impose a mandatory delay of 1 month per incident to that CA's next attempt to include a new