Re: Certinomis Issues
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 focused on how to prevent that entire class of problems in the future. Issues E and F argue that Certinomis is technically incapable of operating a certificate authority in compliance with the expectations we have for such trust. In issue E we see non-compliance with a BR requirement for OCSP responder behavior for over 4 years. Incidentally, the requirement in question was explicitly added to the BRs in response to a major CA security incident. Issue F lists a pattern of repeated misissuance that suggests repeated human typos with no systemic improvement. Similarly, issues A through D show an apparent disinterest in policy, compliance, and communications. Issuing a cross-certification for a CA that was in the middle of major sanctions, having repeated audit gaps, ignoring Mozilla root store policies for years, and generally declining to engage with the community to help resolve these issues is not the action of an organization that understands the responsibility of being a CA. I believe the issues highlighted by Mozilla represent, in aggregate, extremely strong evidence that Certinomis is unfit to operate a trusted certificate authority. -Paul On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: Mozilla has decided that there is sufficient concern [1] about the activities and operations of the CA Certinomis to collect together a list of issues. That list can be found here: https://wiki.mozilla.org/CA/Certinomis_Issues Note that this list may expand or contract over time as issues are investigated further, with information either from our or our community's investigations or from Certinomis. We expect Certinomis to engage in a public discussion of these issues and give their comments and viewpoint. We also hope that our community will make comments, and perhaps provide additional information based on their own investigations. When commenting on these issues, please clearly state which issue you are addressing on each occasion. The issues have been given identifying letters and numbers to help with this. At the end of a public discussion period between Mozilla, our community, and Certinomis, which we hope will be no longer than a couple of weeks, Mozilla will move to make a decision about how to respond to these concerns, based on the picture which has then emerged. - Wayne [1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues ___ 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: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
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 program that can technically be used for SSL on the public web is subject to the program requirements intent or not. It seems since MSFT already requires leaves to have an EKU it wouldn't be breaking to apply the same rule in Mozilla's program. Ryan On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote: > 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 the program requirements? > > For what it's worth, I don't object to a requirement for having an explicit > EKU in certificates covered by the program. Like I said, I think every > certificate that is issued should be issued with a clear understanding of > what applications it will be used for, and having an EKU extension does > achieve that. > > The thing I am attempting to avoid is the implication that a missing EKU > implies a certificate is not subject to the program's requirements. > > Cheers, > Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
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: > Mozilla has decided that there is sufficient concern [1] about the > activities and operations of the CA Certinomis to collect together a list > of issues. That list can be found here: > https://wiki.mozilla.org/CA/Certinomis_Issues > > Note that this list may expand or contract over time as issues are > investigated further, with information either from our or our community's > investigations or from Certinomis. > > We expect Certinomis to engage in a public discussion of these issues and > give their comments and viewpoint. We also hope that our community will > make comments, and perhaps provide additional information based on their > own investigations. > > When commenting on these issues, please clearly state which issue you are > addressing on each occasion. The issues have been given identifying letters > and numbers to help with this. > > At the end of a public discussion period between Mozilla, our community, > and Certinomis, which we hope will be no longer than a couple of weeks, > Mozilla will move to make a decision about how to respond to these > concerns, based on the picture which has then emerged. > > - Wayne > > [1] > https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
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 not be noncompliant. > > Certainly issuing a QWAC needs to have vetting done in alignment with the > EVGL, but by virtue of including the QualifiedStatement, you've asserted > that, even if the certificate Policy OID claims only OV (OV being a subset > EV, so it’s not a lie to say it’s OV validated). > - CertificatePolicy: CA can specify OV and also include this Policy OID: > 0.4.0.194112.1.4 > - qualifiedStatement: qcs-QcCompliance is specified > > Is that contradictory? If not, then I'm probably just missing the > statement that a QWAC MUST be an EV certificate with EV Policy OIDs. > What you describe is not contradictory, but my understanding of the existing ETSI EN requirements is that would present challenges. That is, if the TSP has EV-enabled their QWAC OID, then they would not be able to do that, because their EV-enablement is a committment to follow the EVGs. If the TSP has not EV-enabled their QWAC OID, then they may be able to, with caveats. However, it's unclear, from a 319 403 perspective, whether or not TS 119 495 can override the requirements of EN 319 411-2, which incorporate the EVGs for QWACs. This question is not something we could answer - it would be the responsibility of each member states supervisory body when assessing the CARs provided by the CAB as to whether or not the CAB's assessment evaluated against EN 319 411-2 and whether the modifications of requirements by TS 119 495 are allowed to override those. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
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 permits additional Subject Attributes, then that approach would not be noncompliant. Certainly issuing a QWAC needs to have vetting done in alignment with the EVGL, but by virtue of including the QualifiedStatement, you've asserted that, even if the certificate Policy OID claims only OV (OV being a subset EV, so it’s not a lie to say it’s OV validated). - CertificatePolicy: CA can specify OV and also include this Policy OID: 0.4.0.194112.1.4 - qualifiedStatement: qcs-QcCompliance is specified Is that contradictory? If not, then I'm probably just missing the statement that a QWAC MUST be an EV certificate with EV Policy OIDs. Doug -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, April 17, 2019 12:52 PM To: Sándor dr. Szőke Cc: mozilla-dev-security-policy Subject: Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9 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 Regulation in 2014. Technically the QWAC requirements are based on the CABF EVG and intended to be fully upper compatiable with the EV certificates, but ETSI has set up some further requirements, like the mandatory usage of the QC statements. ETSI TS 119 495 is a further specialization of the QWAC certificates dedicated for payment services according to the EU PSD2 Directive. The PSD2 certificates need to consist amoung others the Organization Identifier [(OrgId) – OID: 2.5.4.97] field in the Subject DN field, which contains PSD2 specific data of the Organization. Till yesterday the usage of this field was not forbidden in the EV certificates, altough as I know there has been discussion about this topic due to the different interpretation of the EVG requirements. As I know there is an ongoing discussion in the CABF about the inclusion of the OrgId field in the definitely allowed fields in the Subject DN of the EV certificates. Today morning I got an email from the CABF mailing list with the new version of the BR ver. 1.6.5 and the EVG ver. 1.6.9. The new version of the BR has already been published on the CABF web site but the new EVG version hasn't been published yet. I would like to ask the current status of this new EVG ver 1.6.9. It is very important for us to have correct information because our CA has begun to issue PSD2 certificates to financial institutions which are intended to fulfil also the EVG requirements. The new version of the EVG definitely states that only the listed fields may be used in the Subject DN and the list doesn't contain the OrgId field. We plan to fulfil both the QWAC and the EVG requirements simultaneuosly but after having the change in the EVG requirements it seems to be impossible in case of PSD2 QWAC certificates. The separation of the EV and the QWAC certificates wouldn't be good for the Customers and it would rise several issues. Do you have any idea how to solve this issue? Will the new version of the EVG ver 1.6.9 be published soon? Isn't it possible to wait with the issuance the result of the ballot regarding the inclusion of the OrgId field? (Writing in a Google capacity) At present, the ETSI TS 119 495 is specified incompatibly with the requirements of the EV Guidelines. The latest version of that TS [1], acknowledges that it is fundamentally incompatible with the EV Guidelines, in Section 5.3, by placing the ETSI TS version as superseding that of the requirements of the EVGs. Unfortunately, this means that a TSP cannot issue a PSD2 certificate from a publicly trusted certificate and claim compliance with the EV Guidelines, and as a consequence, cannot claim compliance with the relevant root store requirements, including Mozilla's and Google's. If a TSP issues a certificate using the profile in TS 119 495, they must do so from a certificate hierarchy not trusted by user agents - and as a result, such certificates will not be trusted by browsers. ETSI and the Browsers have been discussing this for over a year, and the browsers offered, within the CA/Browser Forum, a number of alternative solutions to ETSI that would allow for these two to harmoniously interoperate. ETSI declined to take the necessary steps to resolve the conflict while it was still possible. As a consequence, the CA/Browser Forum has attempted to address some of these issues itself - however, it still requires action by ETSI to harmonize their work.
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
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 the program requirements? For what it's worth, I don't object to a requirement for having an explicit EKU in certificates covered by the program. Like I said, I think every certificate that is issued should be issued with a clear understanding of what applications it will be used for, and having an EKU extension does achieve that. The thing I am attempting to avoid is the implication that a missing EKU implies a certificate is not subject to the program's requirements. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
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 have vetting done in alignment with the EVGL, but by virtue of including the QualifiedStatement, you've asserted that, even if the certificate Policy OID claims only OV (OV being a subset EV, so it’s not a lie to say it’s OV validated). - CertificatePolicy: CA can specify OV and also include this Policy OID: 0.4.0.194112.1.4 - qualifiedStatement: qcs-QcCompliance is specified Is that contradictory? If not, then I'm probably just missing the statement that a QWAC MUST be an EV certificate with EV Policy OIDs. Doug -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, April 17, 2019 12:52 PM To: Sándor dr. Szőke Cc: mozilla-dev-security-policy Subject: Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9 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 > Regulation in 2014. > > Technically the QWAC requirements are based on the CABF EVG and > intended to be fully upper compatiable with the EV certificates, but > ETSI has set up some further requirements, like the mandatory usage of the QC > statements. > > ETSI TS 119 495 is a further specialization of the QWAC certificates > dedicated for payment services according to the EU PSD2 Directive. > The PSD2 certificates need to consist amoung others the Organization > Identifier [(OrgId) – OID: 2.5.4.97] field in the Subject DN field, > which contains PSD2 specific data of the Organization. > > Till yesterday the usage of this field was not forbidden in the EV > certificates, altough as I know there has been discussion about this > topic due to the different interpretation of the EVG requirements. > As I know there is an ongoing discussion in the CABF about the > inclusion of the OrgId field in the definitely allowed fields in the > Subject DN of the EV certificates. > > Today morning I got an email from the CABF mailing list with the new > version of the BR ver. 1.6.5 and the EVG ver. 1.6.9. The new version > of the BR has already been published on the CABF web site but the new > EVG version hasn't been published yet. > > I would like to ask the current status of this new EVG ver 1.6.9. > > It is very important for us to have correct information because our CA > has begun to issue PSD2 certificates to financial institutions which > are intended to fulfil also the EVG requirements. > The new version of the EVG definitely states that only the listed > fields may be used in the Subject DN and the list doesn't contain the OrgId > field. > > We plan to fulfil both the QWAC and the EVG requirements > simultaneuosly but after having the change in the EVG requirements it > seems to be impossible in case of PSD2 QWAC certificates. > The separation of the EV and the QWAC certificates wouldn't be good > for the Customers and it would rise several issues. > > Do you have any idea how to solve this issue? > > Will the new version of the EVG ver 1.6.9 be published soon? > > Isn't it possible to wait with the issuance the result of the ballot > regarding the inclusion of the OrgId field? > (Writing in a Google capacity) At present, the ETSI TS 119 495 is specified incompatibly with the requirements of the EV Guidelines. The latest version of that TS [1], acknowledges that it is fundamentally incompatible with the EV Guidelines, in Section 5.3, by placing the ETSI TS version as superseding that of the requirements of the EVGs. Unfortunately, this means that a TSP cannot issue a PSD2 certificate from a publicly trusted certificate and claim compliance with the EV Guidelines, and as a consequence, cannot claim compliance with the relevant root store requirements, including Mozilla's and Google's. If a TSP issues a certificate using the profile in TS 119 495, they must do so from a certificate hierarchy not trusted by user agents - and as a result, such certificates will not be trusted by browsers. ETSI and the Browsers have been discussing this for over a year, and the browsers offered, within the CA/Browser Forum, a number of alternative solutions to ETSI that would allow for these two to harmoniously interoperate. ETSI declined to take the necessary steps to resolve the conflict while it was still possible. As a consequence, the CA/Browser Forum has attempted to address some of these issues itself - however, it still requires action by ETSI to harmonize their work. The pr
Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
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 Regulation in > 2014. > > Technically the QWAC requirements are based on the CABF EVG and intended > to be fully upper compatiable with the EV certificates, but ETSI has set up > some further requirements, like the mandatory usage of the QC statements. > > ETSI TS 119 495 is a further specialization of the QWAC certificates > dedicated for payment services according to the EU PSD2 Directive. > The PSD2 certificates need to consist amoung others the Organization > Identifier [(OrgId) – OID: 2.5.4.97] field in the Subject DN field, which > contains PSD2 specific data of the Organization. > > Till yesterday the usage of this field was not forbidden in the EV > certificates, altough as I know there has been discussion about this topic > due to the different interpretation of the EVG requirements. > As I know there is an ongoing discussion in the CABF about the inclusion > of the OrgId field in the definitely allowed fields in the Subject DN of > the EV certificates. > > Today morning I got an email from the CABF mailing list with the new > version of the BR ver. 1.6.5 and the EVG ver. 1.6.9. The new version of > the BR has already been published on the CABF web site but the new EVG > version hasn't been published yet. > > I would like to ask the current status of this new EVG ver 1.6.9. > > It is very important for us to have correct information because our CA has > begun to issue PSD2 certificates to financial institutions which are > intended to fulfil also the EVG requirements. > The new version of the EVG definitely states that only the listed fields > may be used in the Subject DN and the list doesn't contain the OrgId field. > > We plan to fulfil both the QWAC and the EVG requirements simultaneuosly > but after having the change in the EVG requirements it seems to be > impossible in case of PSD2 QWAC certificates. > The separation of the EV and the QWAC certificates wouldn't be good for > the Customers and it would rise several issues. > > Do you have any idea how to solve this issue? > > Will the new version of the EVG ver 1.6.9 be published soon? > > Isn't it possible to wait with the issuance the result of the ballot > regarding the inclusion of the OrgId field? > (Writing in a Google capacity) At present, the ETSI TS 119 495 is specified incompatibly with the requirements of the EV Guidelines. The latest version of that TS [1], acknowledges that it is fundamentally incompatible with the EV Guidelines, in Section 5.3, by placing the ETSI TS version as superseding that of the requirements of the EVGs. Unfortunately, this means that a TSP cannot issue a PSD2 certificate from a publicly trusted certificate and claim compliance with the EV Guidelines, and as a consequence, cannot claim compliance with the relevant root store requirements, including Mozilla's and Google's. If a TSP issues a certificate using the profile in TS 119 495, they must do so from a certificate hierarchy not trusted by user agents - and as a result, such certificates will not be trusted by browsers. ETSI and the Browsers have been discussing this for over a year, and the browsers offered, within the CA/Browser Forum, a number of alternative solutions to ETSI that would allow for these two to harmoniously interoperate. ETSI declined to take the necessary steps to resolve the conflict while it was still possible. As a consequence, the CA/Browser Forum has attempted to address some of these issues itself - however, it still requires action by ETSI to harmonize their work. The provisions of Section 9.16.3 of the Baseline Requirements, or of 8.1 of the EV Guidelines, does not trigger in this regard, as the PSD2 regulation is with respects technology neutral. It is merely the specific implementation defined by ETSI that is incompatible, as there are compatible ways for TSPs to meet their obligations under PSD2 and those to browsers and root programs. The change in EVG 1.6.9 did not change these requirements - they merely clarified longstanding and existing requirements. TSPs affected by this should be raising concerns with ETSI ESI as to why ESI did not more actively engage and solicit feedback as to the design of PSD2 certificates early on, so as to prevent this issue. The CA/Browser Forum, and more generally, browsers participating both there and in this Forum, remain committed to helping prevent situations like this present one, to ensure TSPs are able to participate in issuing QWACs that are publicly trusted. However, we rely on those engaging in such SDOs to ensure they do not specify things in a way that conflicts or contradicts existing standards and requirements. [1] https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.03
Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
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 the EV certificates, but ETSI has set up some further requirements, like the mandatory usage of the QC statements. ETSI TS 119 495 is a further specialization of the QWAC certificates dedicated for payment services according to the EU PSD2 Directive. The PSD2 certificates need to consist amoung others the Organization Identifier [(OrgId) – OID: 2.5.4.97] field in the Subject DN field, which contains PSD2 specific data of the Organization. Till yesterday the usage of this field was not forbidden in the EV certificates, altough as I know there has been discussion about this topic due to the different interpretation of the EVG requirements. As I know there is an ongoing discussion in the CABF about the inclusion of the OrgId field in the definitely allowed fields in the Subject DN of the EV certificates. Today morning I got an email from the CABF mailing list with the new version of the BR ver. 1.6.5 and the EVG ver. 1.6.9. The new version of the BR has already been published on the CABF web site but the new EVG version hasn't been published yet. I would like to ask the current status of this new EVG ver 1.6.9. It is very important for us to have correct information because our CA has begun to issue PSD2 certificates to financial institutions which are intended to fulfil also the EVG requirements. The new version of the EVG definitely states that only the listed fields may be used in the Subject DN and the list doesn't contain the OrgId field. We plan to fulfil both the QWAC and the EVG requirements simultaneuosly but after having the change in the EVG requirements it seems to be impossible in case of PSD2 QWAC certificates. The separation of the EV and the QWAC certificates wouldn't be good for the Customers and it would rise several issues. Do you have any idea how to solve this issue? Will the new version of the EVG ver 1.6.9 be published soon? Isn't it possible to wait with the issuance the result of the ballot regarding the inclusion of the OrgId field? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CPS publications under MRSP section 3.3
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 latest disclosed CPs and CPSes in a central repository? Or, is there a place I can find these documents other than the certificate issuer's website? This same section 3.3 also reads that a change in the CPS must be added to a changelog via a dated changelog entry. 2.) Is there a guideline on where to find such changelog? The BR does not seem to have any guidance on this, and "... CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, ..." is the only mention of such changelog. Question 1 arose when I compared the Sectigo CPS with that of LetsEncrypt: Sectigo has an 'all rights reserved' copyright notice on their latest CPS 5.1 [^2], while LetsEncrypt publicly licences it under the CC-BY v4 [^3] As an example interpretation on how my question 2 arose; Sectigo has an archive of CPSes[^4], but these CPSes not seem to have dated changelog entry, not in the archive list, nor in the CPS itself (there is no changelog in the CPS), but do have an 'effective from' date. LetsEncrypt hosts its CPS repository with versions and dates[^5], and has a datestamped changelog in the CPS[^6] - Matthias van de Meent [^1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses [^2] https://sectigo.com/uploads/audio/Sectigo-CPS-v5.1.pdf [^3] https://letsencrypt.org/documents/isrg-cps-v2.5/#1-1-overview [^4] https://sectigo.com/certificate-practice-statement-archive [^5] https://letsencrypt.org/repository/#isrg-certification-practice-statement [^6] https://letsencrypt.org/documents/isrg-cps-v2.5/#1-2-document-name-and-identification ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
