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 root store information, and
that this would be a good idea. More and more innovative services find
it useful to download and consume trust store data from multiple
parties, and at the moment there are various hacky solutions and
conversion scripts in use.


Gerv,

Do you anticipate this being used to build trust decisions in other
products, or simply inform what CAs are trusted (roughly)?

My understanding from the discussions is that this is targeted at the
latter - that is, informative, and not to be used for trust decision
capability - rather than being a full expression of the policies and
capabilities of the root store.

The reason I raise this is that you quickly get into the problem of
inventing a domain-specific language (or vendor-extensible, aka
'non-format') if you're trying to express what the root store does or what
constraints it applies. And that seems a significant amount of work, for
what is an unclear consumption / use case.

I'm hoping you can clarify with the concrete intended users you see Mozilla
wanting to support, and if you could share what the feedback these other
store providers offered.

FWIW, Microsoft's (non-JSON, non-XML) machine readable format is
http://unmitigatedrisk.com/?p=259

Hi Gerv. crt.sh consumes the various trust store data, so I may be interested in helping to write a spec. However, it depends very much on how the end product would be used.

If the aim is to replace certdata.txt, authroot.stl, etc, with this new format, then I'm more interested.

If the aim is to offer yet another mechanism for obtaining trust store data (which may fall out of sync with the "official" data), then I'm less interested.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to