Re: [FORGED] Re: P-521

Alex Gaynor via dev-security-policy writes: >I'll take the opposite side: let's disallow it before it's use expands :-) >P-521 isn't great, and there's really no value in proliferation of crypto >algorithms, as someone told me: "Ciphersuites aren't

Re: Machine- and human-readable format for root store information?

Jos Purvis (jopurvis) via dev-security-policy writes: >One possibility would be to look at the Trust Anchor Management Protocol >(TAMP - RFC5934). Note that TAMP is one of PKIX' many, many gedanken experiments that were created with little, most likely

Re: P-521

On 27 June 2017 at 11:44, Alex Gaynor via dev-security-policy wrote: > I'll take the opposite side: let's disallow it before it's use expands :-) > P-521 isn't great, and there's really no value in proliferation of crypto > algorithms, as someone told me:

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

That's a good point. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Machine- and human-readable format for root store information?

On 2017-Jun-27, 13:49 , "dev-security-policy on behalf of Gervase Markham via dev-security-policy" wrote: On 27/06/17 10:35, Ryan Sleevi wrote: > For example, one possible suggestion is to adopt a scheme similar to, or > identical to, Microsoft's authroot.stl, which is PKCS#7, with

Re: Machine- and human-readable format for root store information?

On 27/06/17 12:17, Ryan Sleevi wrote: > This was something the NSS developers explicitly moved away from with > respect to certdata.c It would be interesting to know the history of that; but we are in a different place now in terms of the SCM system we use and the CI tools available, versus what

Re: Machine- and human-readable format for root store information?

On 26/06/2017 23:53, Moudrick M. Dadashov wrote: Hi Gerv, FYI: ETSI TS 119 612 V2.2.1 (2016-04), Electronic Signatures and Infrastructures (ESI); Trusted Lists http://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.02.01_60/ts_119612v020201p.pdf Having skimmed through this document, I

Re: Machine- and human-readable format for root store information?

On Tue, Jun 27, 2017 at 1:49 PM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/06/17 10:35, Ryan Sleevi wrote: > > If that is the goal, it may be useful to know what the proposed > limitations > > / dependencies are. For example, the translation of

Re: P-521

I'll take the opposite side: let's disallow it before it's use expands :-) P-521 isn't great, and there's really no value in proliferation of crypto algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't try to catch 'em all". There's no real use cases P-521 enables, and not

Re: P-521

On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote: > On 27/06/17 07:17, Kurt Roeckx wrote: > > I suggest you keep it for now. > > An opinion without a rationale is not all that useful :-) A lot of software supports it, including NSS / Firefox. It's not an ideal curve, and it should

Re: Machine- and human-readable format for root store information?

On 27/06/2017 19:49, Gervase Markham wrote: On 27/06/17 10:35, Ryan Sleevi wrote: > ... Further, one could reasonably argue that an authroot.stl approach would trouble Apple, much as other non-SDO driven efforts have, due to IP concerns in the space. Presumably, such collaboration would need

Re: Machine- and human-readable format for root store information?

On 27/06/17 10:35, Ryan Sleevi wrote: > If that is the goal, it may be useful to know what the proposed limitations > / dependencies are. For example, the translation of the txt to the c file > generated non-trivial concern among the NSS development team to support. I propose it be part of the

Re: P-521

On 27/06/17 07:17, Kurt Roeckx wrote: > I suggest you keep it for now. An opinion without a rationale is not all that useful :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Machine- and human-readable format for root store information?

On Tue, Jun 27, 2017 at 9:58 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/06/17 04:16, Rob Stradling wrote: > > If the aim is to replace certdata.txt, authroot.stl, etc, with this new > > format, then I'm more interested. > > I can't speak for

Re: P-521

On 2017-06-27 15:51, Gervase Markham wrote: This issue seems to come up regularly, and I can never find the discussion I'm sure we had about it, so I'm starting a thread here with "P-521" in the subject so it'll be clear. Should we be permitting use of this curve in our policy? I suggest you

Re: Machine- and human-readable format for root store information?

On 27/06/17 04:16, Rob Stradling wrote: > If the aim is to replace certdata.txt, authroot.stl, etc, with this new > format, then I'm more interested. I can't speak for other providers, but if such a spec existed, I would be pushing for Mozilla to maintain our root store in that format, and

Re: Machine- and human-readable format for root store information?

On 26/06/17 17:36, Ryan Sleevi wrote: > Do you anticipate this being used to build trust decisions in other > products, or simply inform what CAs are trusted (roughly)? I don't have strong opinions about what people use the data for; I would hope it would be usable for either purpose. After all,

P-521

This issue seems to come up regularly, and I can never find the discussion I'm sure we had about it, so I'm starting a thread here with "P-521" in the subject so it'll be clear. Should we be permitting use of this curve in our policy? I removed it from the policy in

Re: Machine- and human-readable format for root store information?

I concur with Rob. If this is something the root stores might officially adopt, then I'd be willing to help with the work. I think it would be useful for the ecosystem to make it easier to understand the root stores' contents; it's a lot of work to do otherwise. For some background, for Hardenize

Re: Machine- and human-readable format for root store information?

On 27/06/17 01:36, Ryan Sleevi via dev-security-policy wrote: On Mon, Jun 26, 2017 at 9:50 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: A few root store operators at the recent CAB Forum meeting informally discussed the idea of a common format for

Re: Auditor Qualifications

On 27/06/2017 06:47, Kathleen Wilson wrote: All, We've added new Auditor objects to the Common CA Database. Previously auditor information was just in text fields, and the same auditor could be represented different ways. Now we will have a master list of auditors that CAs can select from