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 <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, April 17, 2019 12:52 PM To: Sándor dr. Szőke <szoke.san...@microsec.hu> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> 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 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.01_60/ts_119495v010301p.pdf [2] https://cabforum.org/pipermail/servercert-wg/2019-April/000700.html _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
