Re: Certinomis Issues

2019-04-17 Thread Paul Kehrer via dev-security-policy
A publicly trusted CA is expected to demonstrate technical competence around validation, issuance, and security of their infrastructure. When non-compliant issuance occurs the community should expect any well operated CA to rapidly detect, remediate the issue, and perform a root cause analysis

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-17 Thread Ryan Hurst via dev-security-policy
For what it is worth I agree with Brian. I would go a bit further and say certificates need to be issued for explicit usages anything else produces potentially unknown behaviors. What's most important though is that any certificate that is trusted as a result of membership in the Mozilla root

Re: Certinomis Issues

2019-04-17 Thread Wayne Thayer via dev-security-policy
Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates issued by Certinomis in February 2019 containing an unregistered domain name. Since the cause described in the incident report is similar, I added this under issue F.1. On Tue, Apr 16, 2019 at 11:44 AM Wayne Thayer wrote: >

Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Ryan Sleevi via dev-security-policy
On Wed, Apr 17, 2019 at 2:23 PM Doug Beattie wrote: > > The ETSI requirements for QWAC are complicated and not all that clear to > me, but is it possible to use OV certificate and Policy OIDs as the base > instead of EV? Since OV permits additional Subject Attributes, then that > approach would

Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Dimitris Zacharopoulos via dev-security-policy
I agree with Doug's interpretation. Dimitris. On 17/4/2019 9:23 μ.μ., Doug Beattie via dev-security-policy wrote: The ETSI requirements for QWAC are complicated and not all that clear to me, but is it possible to use OV certificate and Policy OIDs as the base instead of EV? Since OV

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-17 Thread Brian Smith via dev-security-policy
Wayne Thayer via dev-security-policy wrote: > My conclusion from this discussion is that we should not add an explicit > requirement for EKUs in end-entity certificates. I've closed the issue. > What will happen to all the certificates without an EKU that currently exist, which don't conform to

RE: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Doug Beattie via dev-security-policy
The ETSI requirements for QWAC are complicated and not all that clear to me, but is it possible to use OV certificate and Policy OIDs as the base instead of EV? Since OV permits additional Subject Attributes, then that approach would not be noncompliant. Certainly issuing a QWAC needs to

Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Ryan Sleevi via dev-security-policy
On Wed, Apr 17, 2019 at 11:20 AM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Extended Validation (EV) certificates and EU Qualified certificates for > website authentication (QWAC). > > > European Union introduced the QWAC certificates in the eIDAS

Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Sándor dr . Szőke via dev-security-policy
Extended Validation (EV) certificates and EU Qualified certificates for website authentication (QWAC). European Union introduced the QWAC certificates in the eIDAS Regulation in 2014. Technically the QWAC requirements are based on the CABF EVG and intended to be fully upper compatiable with

CPS publications under MRSP section 3.3

2019-04-17 Thread Matthias van de Meent via dev-security-policy
I noticed that the MRSP section 3.3 states that CPs and CPSes must be made available to Mozilla under a CC-BY -compatible licence, or are considered as licenced under CC-BY-SA v4 to Mozilla and the public when this action has not been taken (3.3 requirement 3). 1.) Does Mozilla re-publish the