Re: [FORGED] Re: P-521

[Peter Gutmann via dev-security-policy]

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 pokemon, you shouldn't
>try to catch 'em all".

"Elliptic Curve Cryptography in Practice", FC'14, for SSH P256 support is
99.9%, P521 support is 0.01%, P384 support is 0.00%.  So you can pretty much
just assume that if it supports ECC, it'll be P256.

Peter.
___
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?

[Peter Gutmann via dev-security-policy]

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 no, real-world evaluation before it was
declared ready.  It may or may not actually work, and may or may not (and
looking at its incredible complexity and flexbility, almost certainly "may
not") interoperate with any other implementation that turns up.  So you'd need
to write a second spec which is a profile of TAMP that nails down what's
expected by an implementation, and then run interop tests to see whether it
works at all.

(In case you're wondering why the CMP protocol, another PKIX cert management
protocol that in theory already does what TAMP does, starts at version 2, it's
because when attempts were made to deploy the initial spec it was found that
it didn't work, so they had to create a "version 2" that tried to patch up the
published standard.  Even then, try finding two CMP implementations that can
interop out of the box...).

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

Re: P-521

[Tom . via dev-security-policy]

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: "Ciphersuites aren't pokemon, you shouldn't
> try to catch 'em all". There's no real use cases P-521 enables, and not
> supporting it means one less piece of code to drag around as we move
> towards better curves/signature algorithms like Ed25519 and co.

But is that what we're talking about? I didn't think the question was
"Should we remove P-521 code from NSS" it's "Should we permit CAs to
use P-521?"

Limiting the policy to restrict P-521 would probably not affect the
code at all - a self-signed cert that uses it will still trigger the
code most likely (unless we were particularly clever about not hitting
those code paths until after the user trusted a self-signed cert.)

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

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

[reisinger.nate--- via dev-security-policy]

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?

[Jos Purvis (jopurvis) via dev-security-policy]

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 attributes
> for indicating age and expiration, and the ability to extend with
> vendor-specific attributes as needed. One perspective would be to say that
> Mozilla should just use this work.

That's one option. I would prefer something which is both human and
computer-readable, as certdata.txt (just about) is.

One possibility would be to look at the Trust Anchor Management Protocol (TAMP 
- RFC5934). It uses CMS, which would give you the flexibility to define usages 
and signed attributes, but it might not land well in terms of human 
readability, I don’t know. Ryan Hurst over at Google pointed us in that 
direction and mentioned he was looking at that for his tl-create tool 
(https://github.com/PeculiarVentures/tl-create), so it might be worth a look. 
An open standard like that might also allay concerns over something more 
proprietary like STL.


-- 
Jos Purvis (jopur...@cisco.com)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105 




smime.p7s
Description: S/MIME cryptographic signature
___
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?

[Gervase Markham via dev-security-policy]

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 we were a few years ago.

If you were able to elaborate on the relevant history here, as you
obviously know it, that would be helpful.

>> That's one option. I would prefer something which is both human and
>> computer-readable, as certdata.txt (just about) is.
> 
> Why? Opinions without justification aren't as useful ;)

:-) Because human-readable only is clearly silly, and computer-readable
only is harder to maintain (requires tools other than a text editor). I
want it to be easily maintainable, easily browseable and also
unambiguously consumable by tools.

> Apple suggested they'd like to make this data available; my hope would
>> be that if a format could be defined, they might be persuaded to adopt it.
> 
> And if they can't, is that justified?
> 
> That is, it sounds like you're less concerned about cross-vendor
> interoperability, and only concerned with Apple interoperability. Is that
> correct?

I'm after interoperability with whoever wants to interoperate. The other
benefits I see for Mozilla are being able to better (if not perfectly)
express our root store's opinions on our level of trust for roots in a
single computer-readable file, rather than the combination of a text
file, a C++ file and a wiki page.

Given that the plan is to auto-generate the old formats when necessary,
I didn't think that maintaining the data in a different format would
cause anyone significant difficulty or hardship.

>> Like, really? Developing a set of JSON name-value pairs to encode some
>> fairly simple structured data has potential IP issues? What kind of mad
>> world do we live in?
> 
> It doesn't matter the format - it matters how and where it was developed.

As in, if I just make it up and start using it, people will be scared
I'm going to sue them over its use?

Gerv
___
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?

[Jakob Bohm via dev-security-policy]

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 find that particular format
unsuited for general use, due to the following issues:

- Excessive inclusion of information duplicated from the certificates
 themselves.
- Complete repetition of all information for any root that is trusted
 for multiple purposes.
- The use of long ETSI/EU-specific uris to specify simply things such as
 "trusted"/"not trusted".
- Apparent lack of syntax for specifying scopes that are global but do
 not represent a global authority (such as the UN).

- A notable lack of fields to represent the trust data that real world
 commercial root programs typically need to specify for trusted CA
 certs.
- The apparent need to go through ETSI-specific registration procedures
 to add "extensions" and/or "identifiers" for anything missing.
- Mandatory provision of snail-mail technical support.

- EU specific oddities, such as alternative identifiers for some some EU
 member states.

That said, it could provide some inspiration.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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?

[Ryan Sleevi via dev-security-policy]

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 the txt to the c file
> > generated non-trivial concern among the NSS development team to support.
>
> I propose it be part of the checkin process (using a CI tool or similar)
> rather than part of the build process. Therefore, there would be no new
> build-time dependencies for NSS developers.


This was something the NSS developers explicitly moved away from with
respect to certdata.c

> For example, one possible suggestion is to adopt a scheme similar to, or
> > identical to, Microsoft's authroot.stl, which is PKCS#7, with attributes
> > for indicating age and expiration, and the ability to extend with
> > vendor-specific attributes as needed. One perspective would be to say
> that
> > Mozilla should just use this work.
>
> That's one option. I would prefer something which is both human and
> computer-readable, as certdata.txt (just about) is.



Why? Opinions without justification aren't as useful ;)

(To be fair, this is broadly about articulating and agreeing use cases
before too much effort is spent)

Apple suggested they'd like to make this data available; my hope would
> be that if a format could be defined, they might be persuaded to adopt it.



And if they can't, is that justified?

That is, it sounds like you're less concerned about cross-vendor
interoperability, and only concerned with Apple interoperability. Is that
correct?

> 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 to occur somewhere with
> > appropriate IP protections.
>
> Like, really? Developing a set of JSON name-value pairs to encode some
> fairly simple structured data has potential IP issues? What kind of mad
> world do we live in?


It doesn't matter the format - it matters how and where it was developed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: P-521

[Alex Gaynor via dev-security-policy]

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
supporting it means one less piece of code to drag around as we move
towards better curves/signature algorithms like Ed25519 and co.

Alex

On Tue, Jun 27, 2017 at 2:40 PM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 get replaced, but it's currently
> better to have it then not.
>
> I currently only count 222 certificate using P-521 that chain to
> the Mozilla root store, and I guess some of those would fall back
> to RSA.
>
> I see no reason to say that they shouldn't be used at this time.
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: P-521

[Kurt Roeckx via dev-security-policy]

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 get replaced, but it's currently
better to have it then not.

I currently only count 222 certificate using P-521 that chain to
the Mozilla root store, and I guess some of those would fall back
to RSA.

I see no reason to say that they shouldn't be used at this time.


Kurt

___
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?

[Jakob Bohm via dev-security-policy]

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 to occur somewhere with
appropriate IP protections.


Like, really? Developing a set of JSON name-value pairs to encode some
fairly simple structured data has potential IP issues? What kind of mad
world do we live in?



I think he was referring to possible IP concerns with reusing
Microsoft's ASN.1 based format.

P.S.

Note that Microsoft has two variants of their "Certificate Trust List"
format:

One that actually includes all the trusted certificates, which is more
useful as inspiration for this effort.

Another that contains only metadata, but not the actual certs.  This is
the one loosely described at http://unmitigatedrisk.com/?p=259



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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?

[Gervase Markham via dev-security-policy]

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 checkin process (using a CI tool or similar)
rather than part of the build process. Therefore, there would be no new
build-time dependencies for NSS developers.

> For example, one possible suggestion is to adopt a scheme similar to, or
> identical to, Microsoft's authroot.stl, which is PKCS#7, with attributes
> for indicating age and expiration, and the ability to extend with
> vendor-specific attributes as needed. One perspective would be to say that
> Mozilla should just use this work.

That's one option. I would prefer something which is both human and
computer-readable, as certdata.txt (just about) is.

> Yet if the goal is cross-vendor compatibility, one can argue that is the
> best approach, as t changes the number of vendors implementing it to 2,
> from the present 1, and thus achieves that goal. As you introduce the
> concept of Apple, but which has historically been a non-participant here,
> it makes it hard to design a system acceptable to them.

Apple suggested they'd like to make this data available; my hope would
be that if a format could be defined, they might be persuaded to adopt it.

> 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 to occur somewhere with
> appropriate IP protections.

Like, really? Developing a set of JSON name-value pairs to encode some
fairly simple structured data has potential IP issues? What kind of mad
world do we live in?

> These criticisms are not meant to suggest I disagree with your goal, merely
> that it seems there would be a number of challenges in achieving your goal
> that discussion on m.d.s.p. would not resolve. The way to address these
> challenges seems to involve getting firm commitments and collaboration with
> other vendors (since that is your primary goal), 

Well, if there was some chance of someone taking on the work - which
perhaps there seems to be, based on other replies - then that would be a
good next step. But there's no point in me having those discussions if
there's no-one willing to do the work. Hence my original question.

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

Re: P-521

[Gervase Markham via dev-security-policy]

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
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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 other providers, but if such a spec existed, I would
> be pushing for Mozilla to maintain our root store in that format, and
> auto-generate certdata.txt (and perhaps ExtendedValidation.cpp) on
> checkin for legacy uses.
>


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.

For example, one possible suggestion is to adopt a scheme similar to, or
identical to, Microsoft's authroot.stl, which is PKCS#7, with attributes
for indicating age and expiration, and the ability to extend with
vendor-specific attributes as needed. One perspective would be to say that
Mozilla should just use this work.

However, the NSS developer would rightfully point out the complexity
involved in this - such as what language or tools should be used to
translate this form into the native code. Perl or Python (part of MozBuild)
may be acceptable to the Mozilla developer, but challenging for the NSS
developer. A native tool integrated into the build system (as signtool is
for updating the chk tool) presents a whole host of challenges for
cross-compilers.

Yet if the goal is cross-vendor compatibility, one can argue that is the
best approach, as t changes the number of vendors implementing it to 2,
from the present 1, and thus achieves that goal. As you introduce the
concept of Apple, but which has historically been a non-participant here,
it makes it hard to design a system acceptable to them. 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 to occur somewhere with
appropriate IP protections.

These criticisms are not meant to suggest I disagree with your goal, merely
that it seems there would be a number of challenges in achieving your goal
that discussion on m.d.s.p. would not resolve. The way to address these
challenges seems to involve getting firm commitments and collaboration with
other vendors (since that is your primary goal), as well as to explore the
constraints and limits of the NSS (and related) build systems, since the
combination of those two factors will determine whether this is just
another complex transition (as changing certdata.c to be generated and not
checked in was) with limited applicability.


> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: P-521

[Kurt Roeckx via dev-security-policy]

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 keep it for now.

You should probably allow ed25519 and ed448.


Kurt

___
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?

[Gervase Markham via dev-security-policy]

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
auto-generate certdata.txt (and perhaps ExtendedValidation.cpp) on
checkin for legacy uses.

Gerv
___
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?

[Gervase Markham via dev-security-policy]

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, people use
certdata.txt for the latter purpose even though
https://wiki.mozilla.org/CA/Additional_Trust_Changes
exists...

> 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.

I want it to be at least as capable as certdata.txt; I agree with the
issues raised in previous discussions about a domain-specific language,
and I don't want to go down the route of attempting something which can
specify arbitrarily-complex restrictions. But it could certainly have
reasonably simple mods like "only trusted for certs issued before date
X", or "name constrained in this way".

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

P-521

[Gervase Markham via dev-security-policy]

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
https://github.com/mozilla/pkipolicy/issues/5 because I was under the
impression that Firefox and/or NSS didn't support it. But I now see (not
sure how I didn't notice before) that the relevant bugs are unfixed or
WONTFIXed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1129077
https://bugzilla.mozilla.org/show_bug.cgi?id=1128792

And I notice that the P-521/SHA-512 combination is recommended, or at
least specced, in TLS 1.3:
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.3

But it seems like BoringSSL doesn't support it:
https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2

So what should we be doing in our policy (which, by principle, looks to
Mozilla's needs first)? Banning it? Discouraging it but allowing it?
Permitting it? Something else?

Gerv
___
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?

[Ivan Ristic via dev-security-policy]

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 (a free comprehensive security testing
tool I am now building), we extracted the roots from a bunch of stores and
we try to determine if a particular leaf would be trusted. You can see it
here (some recent stores are missing), bottom right:
https://www.hardenize.com/report/hardenize.com#www_certs


On Tue, Jun 27, 2017 at 12:16 PM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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



-- 
Ivan
___
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?

[Rob Stradling via dev-security-policy]

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

Re: Auditor Qualifications

[Jakob Bohm via dev-security-policy]

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 when entering their Audit Cases to provide their annual updates. The root 
store operator members of the CCADB will update this data as we encounter audit 
statements from new auditor/locations that we are able to verify.

I have started the master list based on auditors encountered in the CCADB for 
root certificates.

https://ccadb-public.secure.force.com/mozilla/AuditorQualificationsReport

I will greatly appreciate it if you will review the list and let me know if 
I've made any mistakes in the data. Also, I will greatly appreciate good links 
to the qualifications to the ETSI auditors (I'm not sure if the 
links/qualifications I've used are the best).

Thanks,
Kathleen




Maybe add an extra column indicating if this auditor is currently
distructed by Mozilla (and thus not accepted for new audits on Mozilla
trusted roots).  Alternatively a list of CCADB-based root programs
distrusting an auditor.

This could become the canonical place for Mozilla and other CCADB-based
root programs to indicate when they override the trust programs
(WebTrust, ETSI, ...) decision on this.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy