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