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

[Sándor dr. Szőke]

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?

[Ryan Sleevi]

(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

[Doug Beattie]

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

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Dimitris Zacharopoulos]

I agree with Doug's interpretation.


Dimitris.

[Ryan Sleevi]

On Wed, Apr 17, 2019 at 2:23 PM Doug Beattie <doug.b...@globalsign.com>

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.

[Sándor dr. Szőke]

Thank you for the valuable information.


I try to summarize the possibilities to issue PSD2 QWAC certificates.

- If a CA issues PSD2 QWAC certificate now, it SHALL NOT include the CABF EV CPOID in it, but instead of that the certificate should contain the CABF OV CPOID value.
- If the CA issues PSD2 QWAC certificate with CABF OV CPOID, the issuing CA can not be EV enabled by the browsers and it will never be EV enabled because it has already issued not EVG compliant certificate (is it correct?).
- If the Ballot SC17 will be accepted it will be possible to issue PSD2 QWAC certificate with the CABF EV CPOID in it, so the issuer CA can be EV enabled AND EU Qualified at the same time.

As a consequence,
- if a CA issues PSD2 certificate now, it shall set up new intermediate CA-s for the issuance of EV certificates which shall be audited and asked for the EV enabled status

It seeems to me that the best would be to wait for the result of the Ballot SC17 voting and not to issue PSD2 certificates now.

Do you have any information about the planned date/schedule of the voting?

[Doug Beattie]

Hi Sandor,

You can follow the ballot status in the Server Certificate Working Group
mail archives here:
https://cabforum.org/pipermail/servercert-wg/
and specifically in this thread:
https://cabforum.org/pipermail/servercert-wg/2019-April/000723.html

Voting will start at least a week after the final proposal is reviewed and
no comments are made to change it.

Doug


-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Sándor dr. Szoke via dev-security-policy
Sent: Thursday, April 18, 2019 5:11 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Organization Identifier field in the Extended Validation
certificates accordinf to the EVG ver. 1.6.9

[Ryan Sleevi]

On Thu, Apr 18, 2019 at 9:56 AM Sándor dr. Szőke via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thank you for the valuable information.
>
>
> I try to summarize the possibilities to issue PSD2 QWAC certificates.
>
> - If a CA issues PSD2 QWAC certificate now, it SHALL NOT include the CABF
> EV CPOID in it, but instead of that the certificate should contain the CABF
> OV CPOID value.
>

More clearly: It shall not contain any CP OID that indicates that the
certificate will comply with the EV Guidelines. In practice, this
specifically means the CABF EV CP OID and any other CP OIDs that may be
specific to the CA which it has EV enabled.

> - If the CA issues PSD2 QWAC certificate with CABF OV CPOID, the issuing
> CA can not be EV enabled by the browsers and it will never be EV enabled
> because it has already issued not EVG compliant certificate (is it
> correct?).
>

Ish. Issuing CAs can issue both OV and EV certificates; what matters is
what OIDs are used and if and whether they will be enabled for EV
treatment. As such, provided that the OID used for the PSD2 QWAC is not an
OID enabled for EV treatment, and provided that the CA's CP/CPS does not
indicate that the particular OID used for the PSD2 QWAC complies with the
CA/Browser Forum's EV Guidelines, then that should be acceptable.

> - If the Ballot SC17 will be accepted it will be possible to issue PSD2
> QWAC certificate with the CABF EV CPOID in it, so the issuer CA can be EV
> enabled AND EU Qualified at the same time.
>

Ish. Note that SC17 does make some modifications to address the concerns
that were raised with ETSI ESI, which ETSI ESI declined to address. As a
consequence, if Ballot SC17 passes, then certificates MAY be issued that
comply with the profile restriction specified in the EV Guidelines by SC17,
and such profile MAY be compatible with PSD2 QWAC.

Put differently: If you comply ONLY with PSD2 QWAC, then NO. If you comply
with the profile in SC17, which MAY comply with (be a super-set of) the
profile in PSD2 QWACs, then yes.

> As a consequence,
> - if a CA issues PSD2 certificate now, it shall set up new intermediate
> CA-s for the issuance of EV certificates which shall be audited and asked
> for the EV enabled status
>

This doesn't follow. Intermediate CAs are not enabled for EV, the root CA
is, based on the root CA's CP/CPS and stated policies (and associated
audits).

>From the perspective of audits based on ETSI EN 319 411-1 / 319 411-2, an
ETSI auditor MUST NOT indicate that a TSP has complied with the EV
Guidelines for a particular CP OID if that particular CP OID has been used
to issue PSD2 QWACs. Audit reports that (incorrectly) indicate such SHOULD
be rejected by browsers as not meeting the requirements of browser root
programs.

However, a TSP MAY be able obtain an audit indicating their PSD2 QWAC CP
OID complies with 319 411-2 as modified by TS 119 495, thus meeting the
obligations of PSD2 QWACs, while only meeting the assurance level of the
CA/Browser Forum's OV CP, and indicate a *separate* OID complies with 319
411-2 and the CA/Browser Forum's EV Guidelines. A PSD2 QWAC certificate
MUST NOT contain the latter EV OID unless and until SC17 has been adopted.
However, PSD2 QWACs can be issued with ONLY the former OID - indicating
it's a PSD2 QWAC but a CABF OV - until then.

Hopefully that made sense?

[Sándor dr. Szőke]

>
> Hopefully that made sense?

Thanks for the information, the situation is not so bad as we thougth before.

If I understand well, the same intermediate CA may issue EV and OV certificates, but the proper CP OID shall be included in the TLS certificate. It menas that the service provider doesn't have to set up a new intermediate CA due to this PSD2 issue.

According to the present requirements the CA may issue PSD2 certificates, but instead of the CABF EV CP OID it shall contain the CABF OV CP OID and this shall be clearly stated in the CP and CPS documents too.

After having the result of the Ballot SC17 the CA shall review the new requirements and make the necessary changes if there will be any.

We hope that it will be possible to issue PSD2 certificates with CABF EV CP OID by the same intermediate CA from June 2019.