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 iss
> 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:
https://crt.sh/?sha256=0330286df3612c0e9
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
https:/
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.
>
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9
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.
>
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9
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 diff
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 root), the concern is that the mere exis
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 ha
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
*explici
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 f
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 (sectio
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 "someho
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
wrote:
I don't believe that disclosure of
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:
I don't believe that disclosure of root certificates is the responsibility
of
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 CCADB interface
talks in terms of "Intermed
..@gmail.com]
Sent: Thursday, June 8, 2017 8:17 PM
To: Jonathan Rudenberg
Cc: Ben Wilson ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates
On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy
wrote:
>
>> On Jun 8, 2017, a
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 is the responsibility
>> of a CA that has cross-certified a key. For instance,
> 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 "Intermediate CAs". Root CAs are the responsib
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 cross-certified a key. For instance, the CCADB inter
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
> br
ss to upload 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.or
ozilla.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 30th, 2016:
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
https://crt.sh/?id=12729173 were observed in other certs issued by
the
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
I
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:
http://www.cert.fnmt.es/crls/ARLFNMTRC
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.
https://crt.sh/?sha256=b82210cd
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 amp
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:
https://ccadb-public.se
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:
https://ccadb-public.secure.force.com/mozillacommunications/CA
> 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:
>>
>> -
>> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0
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
> -
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade3
> 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:
> https://crt.sh/mozilla-disclosures#undisclosed
Yet another batch of undisclosed i
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 manda
@lists.mozilla.org]
On Behalf Of Stephen Davidson via dev-security-policy
Sent: martes, 6 de junio de 2017 15:59
To: Alex Gaynor ; MozPol
Subject: 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
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 in
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 C
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
> incent
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 r
43 matches
Mail list logo
