Re: Process of including ca root in mozilla
On 09/03/2018 05:28, westmai...@gmail.com wrote: It's bad that 70% of the root certificates in the discussion thread are certificates of governments that are not needed to anyone except these governments. Andrew And the citizens under those governments. And anyone elsewhere checking out things in that country for any reason. (how much depends how much of the stuff in that country uses it, for example, some years ago, every citizen in Denmark could get a free(ish) e-mail/client certificate under the TDC root, this was later taken over by a banking services company that changed it into a two-factor login with private keys on their server!). But yes, country-specific CAs should be restricted to trust for entities in that country only (domains under the country TLDs, subject DN country code in that country etc.). And this should be technically enforced even if the country-folk don't add that restriction themselves. 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: Process of including ca root in mozilla
It's bad that 70% of the root certificates in the discussion thread are certificates of governments that are not needed to anyone except these governments. Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
On Thu, Mar 08, 2018 at 12:42:13PM -0800, Anis via dev-security-policy wrote: > why not put a single recognition platform for all this will save time What did Microsoft and Apple say when you pitched this obviously very well thought-out and detailed proposal to them? If you want a single platform, all the existing players need to agree to it... - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
for example there is some root not recognized by mozilla but recognized by microsoft after an Etsi or webtrust audits why not put a single recognition platform for all this will save time ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
So it benefits the CA (potentially hostile CAs) to getting in quicker, but at profound risk to users, even if the CA is removed. If a CA takes more than 2 years to get included, it's almost always because they're not actually keeping the checks, documentation, and audits. On Thu, Mar 8, 2018 at 3:36 PM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > we keep the checks and the audits according to cabf. We reduce the > discussion time to 6 months. After the inclusion is set a period of one > year of compliance testing. while controlling the certificates issued by > this authority. we can exclude the root ca in the next versions. > you do not notice the heaviness of the procedure which now takes more than > 2 years. > ___ > 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: Process of including ca root in mozilla
we keep the checks and the audits according to cabf. We reduce the discussion time to 6 months. After the inclusion is set a period of one year of compliance testing. while controlling the certificates issued by this authority. we can exclude the root ca in the next versions. you do not notice the heaviness of the procedure which now takes more than 2 years. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
What benefit does this provide, given the profound and lasting risk this introduces? On Thu, Mar 8, 2018 at 2:49 PM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > root CA inclusion procedures are very long, so do not simplify them to > encourage the certification culture. > for example give root the chance to be included for a period of one year > during this time it is decided that it remains or not while respecting the > norms course. > if in the course of this period the root ca will make an error it will be > excluded in the next update or version of mozilla. > the first checks are carried out as usual but instead of consuming years > we will fix for example 6 months. > at the end of these 6 months a vote will be made to decide. > Anis > ___ > 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
Process of including ca root in mozilla
root CA inclusion procedures are very long, so do not simplify them to encourage the certification culture. for example give root the chance to be included for a period of one year during this time it is decided that it remains or not while respecting the norms course. if in the course of this period the root ca will make an error it will be excluded in the next update or version of mozilla. the first checks are carried out as usual but instead of consuming years we will fix for example 6 months. at the end of these 6 months a vote will be made to decide. Anis ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Subscriber Certificate Structure
On Thu, Mar 8, 2018 at 10:57 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > I tried to dive into the best certificate structure and there are two > things that bother me: > > In both the CA\B F BR and the EV guidelines it clearly states that the > SubjectCN is deprecated, so I learn from that that the best subscriber > certificate structure would simply not include this field > I did a small survey and I couldn’t find not even one certificate without > the SubjectCN - so my question is: > should we issue certificates without this field? why doesn’t any other CA > has removed this field? > See https://cabforum.org/pipermail/public/2017-October/012321.html > > In addition - the CertificatePolicies extension: > It says in the BR and the EV guidelines that this extension MUST appear at > a subscriber certificate > yet I failed to find this extension in any EV certificate I checked... > Can you provide an example? Every single EV cert I've ever seen has included this. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Subscriber Certificate Structure
Hi everyone, I tried to dive into the best certificate structure and there are two things that bother me: In both the CA\B F BR and the EV guidelines it clearly states that the SubjectCN is deprecated, so I learn from that that the best subscriber certificate structure would simply not include this field I did a small survey and I couldn’t find not even one certificate without the SubjectCN - so my question is: should we issue certificates without this field? why doesn’t any other CA has removed this field? In addition - the CertificatePolicies extension: It says in the BR and the EV guidelines that this extension MUST appear at a subscriber certificate yet I failed to find this extension in any EV certificate I checked... am I missing something? I would appreciate your input on those matters. Thanks Yair ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
