I would like to open a discussion about the criteria by which Mozilla
decides which CAs we should allow to apply for inclusion in our root store.
Section 2.1 of Mozilla’s current Root Store Policy states:
CAs whose certificates are included in Mozilla's root program MUST:
> 1.provide
What about the Mozilla CA communication that said that CAs had until 15
April 2018?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29
All,
I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I
are distributing the job of running Mozilla's CA Program between us, so
he will be actively working on both of these Modules.
Thanks,
Kathleen
[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations. Thanks!]
Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain
non-technically-constrained id-kp-emailProtection
To recap, we've established that this root was first BR audited on 26-April
2015 and has received clean period-of-time audits over the next two years.
ComSign has disclosed 36 certificates issued by this root prior to the BR
point-in-time audit, of which one remains unexpired. This does not
Ryan,
Here is some more information to continue the discussion.
- We will continue to post all certificates to CT logs so issuance can
be monitored.
- We will reduce validity period of OneClick certificates to 6 months.
- We will work with the hosting providers (on
It would come at the expense of a more streamlined and secure approach
(e.g. the ALPN proposal on the acme-wg list), which once standardized I
assume Let's Encrypt (and other ACME CAs) would want to fully migrate to.
Alex
On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <
7 matches
Mail list logo
