On Thu, Mar 8, 2018 at 11:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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 th
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.
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
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.moz
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
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 t
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
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 p
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 th
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
11 matches
Mail list logo