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
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
___
dev-secur
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 t
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 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 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 that
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 issuan
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 requ
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 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
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 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
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
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 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
Let's also consider some of the companies that use the ubiquitous roots: Coca Cola, Pepsico, Nike, the CIA, all major US banks, and probably most major US companies and consumer brands. Consider, too, that in addi
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
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.
--
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
in
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. M
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, Symantec can actually
> issue from the new
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 new roots are generally accepted, Symante
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 polic
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"
certificat
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
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 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: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,
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 are
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
30 matches
Mail list logo