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
> 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:
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
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.
>
>
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.
>
>
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
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
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
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
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
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
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
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
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
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:
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
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
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
> 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
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
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
>
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:
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
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
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:
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.
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
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
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
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:
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:
> 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:
>>
>> -
>>
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
> -
>
> 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:
>
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
@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
, 2017 10:30 AM
To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: New undisclosed intermediates
Happy Monday!
Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undis
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
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
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
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
>
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
Happy Monday!
Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed
There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.
As
43 matches
Mail list logo