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

Hello Kai, On Friday, June 30, 2017 at 7:38:59 PM UTC+3, Kai Engert wrote: > Hello Gerv, > > I think the new format should be as complete as possible, including both trust > and distrust information, including EV and description of rules for partial > distrust. > > As of today, certdata.txt

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

On Thu, Jul 6, 2017 at 10:57 AM, Gervase Markham wrote: > On 05/07/17 18:08, Ryan Sleevi wrote: > > That is, the difference between, say: > > "label": "Verisign/RSA Secure Server CA" > > And > > CKA_LABEL "Verisign/RSA Secure Server CA" > > Not much, but you've picked the

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

On 05/07/17 18:08, Ryan Sleevi wrote: > That is, the difference between, say: > "label": "Verisign/RSA Secure Server CA" > And > CKA_LABEL "Verisign/RSA Secure Server CA" Not much, but you've picked the clearest part of certdata.txt to compare :-) > It isn't, because JSON can't. As Rob notes,

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

On 06/07/17 14:44, Kai Engert wrote: > My response was based on my interpretation of Gerv's suggestion, which I > understood as follows: > - certdata.txt remains the master, keeps maintained and published with NSS > - we define a new file format that's accepted as the standard for several > root

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

On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote: > On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote: > > > > > I suspect, means anyone could plug > > > > in a modern CI > > > > CI meaning Continuous Integration ? > > > > Yes. Gerv's proposal rests on the idea of having a

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

On 05/07/17 18:08, Ryan Sleevi wrote: On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote: That is, the difference between, say: "label": "Verisign/RSA Secure Server CA" And CKA_LABEL "Verisign/RSA Secure Server CA" I would argue there isn't a meaningful difference for "human readability",

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

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 29/06/17 16:27, Ryan Sleevi wrote: > > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? > > Human readability

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

On 03/07/17 16:09, Kai Engert wrote: > I'd prefer a simple open source tool that operates on files, which can be used > from a command line, with a free license, e.g. MPL2. Of course. > If the intention is to define a file format that is shared with other groups, > who would be the owner of the

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

On 03/07/17 16:53, Kai Engert wrote: > On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: >> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: >>> Well, the fact that we now use Git, > > NSS and the root store don't use Git, it uses HG/Mercurial.

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

On 29/06/17 16:27, Ryan Sleevi wrote: > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? Human readability is, of course, a little bit of a continuum. You can open it in a text editor and get some sense of what's going on, but it's

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

On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote: > > > I suspect, means anyone could plug > > > in a modern CI > > CI meaning Continuous Integration ? > Yes. Gerv's proposal rests on the idea of having a file committed that explains it in human-readable and machine-readable

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

On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: > On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > > Well, the fact that we now use Git, NSS and the root store don't use Git, it uses HG/Mercurial. > > I suspect, means anyone could plug > >

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

On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote: > > > I think the new format should be as complete as possible, including both > > trust > > and distrust information, including EV and description of rules for partial > > distrust. > > I agree, as long as we can stay away from defining

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

Hi Kai, On 30/06/17 17:38, Kai Engert wrote: > given that today we don't have a single place where all of Mozilla's > certificate > trust decisions can be found, introducing that would be a helpful. I'm glad you see the value in my goal :-) > I think the new format should be as complete as

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

On Fri, 2017-06-30 at 18:46 +, David Adrian wrote: > Censys validates certificates against multiple root stores. At the end of > the day, what we want is a reliable and repeatable way to get an up-to-date > version of a root store in PEM format. Can you please clarify if you're talking about

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

To be clear: I don't care what format the certificates are released in, I am primarily interested in a reliable URL to download for each root store. I personally will be converting them to OpenSSL-style PEM-encoded-DER to be used with common X.509 libraries. I suspect others will also be

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

Peter Gutmann via dev-security-policy writes: >You keep using that word... I do not think it means what you think it does. "... what you think it means". Dammit. Peter. ___ dev-security-policy mailing list

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

David Adrian via dev-security-policy writes: >I'd like to see either a reliable URL to fetch that can be converted to PEM >(i.e. what Microsoft does), or some API you can hit to the store (e.g. what >CT does). PEM. You keep using that word... I do not

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

I just want to drop in a couple thoughts from the perspective of Censys with regard purely to _obtaining_ root stores. Censys validates certificates against multiple root stores. At the end of the day, what we want is a reliable and repeatable way to get an up-to-date version of a root store in

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

Hello Gerv, given that today we don't have a single place where all of Mozilla's certificate trust decisions can be found, introducing that would be a helpful. I think the new format should be as complete as possible, including both trust and distrust information, including EV and description of

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

On Wednesday, June 28, 2017 at 7:39:37 PM UTC-4, Gervase Markham wrote: > Well, we should ask Kai what methods he uses to maintain it right now, > and whether he uses a tool. For the recent name constraints, it was a tool. > > You can have a JSON file, but that doesn't mean it's human-readable

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

On 28/06/17 15:08, Ryan Sleevi wrote: > It already (effectively) requires a tool to make sure it's done right, AIUI :) Well, we should ask Kai what methods he uses to maintain it right now, and whether he uses a tool. > You can have a JSON file, but that doesn't mean it's human-readable in the

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

On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > Well, the fact that we now use Git, I suspect, means anyone could plug > in a modern CI tool that did "Oh, you changed file X. Let me regenerate > file Y and check it in alongside". Without really needing anyone's >

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

On 28/06/17 06:38, Ryan Sleevi wrote: > Not really, at least from the NSS perspective. There's been the CVS -> > Mercurial -> Git(ish) transitions, but otherwise, the tools and > dependencies have largely remained the same. Well, the fact that we now use Git, I suspect, means anyone could plug in

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

On Tue, Jun 27, 2017 at 3:52 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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

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

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: Machine- and human-readable format for root store information?

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 root store information, and > that this would be a good

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

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 Thanks, M.D. On 6/26/2017 4:50 PM, Gervase Markham via dev-security-policy wrote: A few