[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

Tue Jun 12 02:18:35 MST 2018

All,

Thanks for spending time to consider this proposal.

May I firstly clarify how the current definition in ETSI TS 119 412-1 v1.2.1 clause 5.1.4 works:

a)      As part of the definition of the semantics of the identifier carried in organizationIdentifier defined in this clause there is an OID for the semantics “id-etsi-qcs-SemanticsId-Legal”.

b)      This OID for semantics is carried within a QCStatement extension QCStatement-2 as specified in in clause 3.2.6.1 of IETF RFC 3739

c)       RFC 3739 its scope is directed at “qualified certificates” and was written with EU legislation in mind.  However, it is not aimed specifically for EU Qualified Certificates

Looking back it is unfortunate that ETSI adopted the use of the RFC 3739 QCStatement-2 and did not define a more neutral extension to carry this information.

Regarding the two choices that Tim and Ryan identify below I am personally open to moving to a more neutral extension.  But given the timescale of the implementation of EU PSD2 placed on banks and Third Party Payment Service Providers (test service by March 2019, operational September 2019) we ask for the forbearance of CAB Forum members to allow the existing use of RFC 3739 QCStatement-2 recognising that this does not in fact place any requirements to follow EU regulations.

As I mentioned banks are considering the use of EV with this extension to protect public facing interfaces to customers for PSD2.  They have little time to decide on whether this is possible or whether alternative approaches to enabling customers to check the formal authorisation of payment services need to be considered.  So at least clarity of the ambiguity mentioned by Adriano is needed.  If this is best achieved by specific text referencing the relevant ETSI specification as I have proposed then the situation would be greatly clarified and this would be much appreciated.

Any further suggestions as to how this might be speedily progressed would be appreciated.

Nick

________________________________
 [cid:image81f781.PNG at 8172e876.41b525a4] <http://www.thalesesecurity.com>
Nick Pope
Principal Consultant, Advanced Solutions Group
Tel: +44 1844 203585
Mob: +44 7880 787940
[cid:imagefff56e.PNG at 3b47d070.4087dd27]<https://www.twitter.com/thalesesecurity>@thalesesecurity

Thales eSecurity
Meadow View House, Long Crendon
Aylesbury HP18 9EQ
United Kingdom

[cid:image9dbd82.PNG at 8bb524e1.41a00f2f]<https://gdpr.thalesesecurity.com/>

www.thalesesecurity.com<http://www.thalesesecurity.com>

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Tim Hollebeek via Validation
Sent: 11 June 2018 23:57
To: Ryan Sleevi
Cc: CA/Browser Forum Validation WG List
Subject: Re: [cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

Either #1 or #2 is fine.  I was being vague only because the proposals various people have run by me were similarly vague.

As long as there is something that fairly clearly and reliably indicates that the context is ETSI semantics, I think that’s good enough.

The question I find far more interesting is the rules for how one validates that a tax id is correct for a particular entity.  What does ETSI have to say about that?

I really need to get around to reading the relevant ETSI standards one of these days …

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, June 11, 2018 5:56 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>; Dimitris Zacharopoulos <jimmy at it.auth.gr>
Subject: Re: [cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

I'm having trouble parsing this.

I agree that expressing this as an OID in the policyQualifiers/qcStatements serves to unambiguously identify the case - that's different than the proposal as written, but ensures it stays away from overloading X.500 semantics in an ambiguous way. Fundamentally, that's the same as expressing a dedicated OID that indicates its ETSI in its context. This seems desirable - and aligns with the reality that we don't have the global DIT that X.500 imagined that would contextualize and disambiguate these fields.

That is, to recap:
1) Express it within the policyQualifiers for the qcStatements
2) Express it as a dedicated attribute OID (with a defined syntax) to indicate the context

Both achieve that purpose.

I'm not sure if you're suggesting a third option, as one possible read of your suggestion is:
3) Express it using an X.500 organizationIdentifier, and rely on a given policyQualifier being present to indicate the qcStatement, which, by proxy, expresses a semantic and syntactic interpretation that aligns with the ETSI piece.

Of course, #3 is unfortunately also problematic, in that now we'd have to indicate further ETSI QWAC-specificness into the BRs to indicate that the organizationIdentifier can only be present (and must contain the appropriately validated information) if and only if the ETSI policyQualifiers are asserted, and that further ensures the BRs carry ETSI-specificness for what is meant to be a general set of requirements.

This is why #1 and #2 are so much more preferable as solutions.

On Mon, Jun 11, 2018 at 12:55 PM, Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>> wrote:
Several people have suggested the qc OID already serves this purpose.

-Tim

Of course, I offered alternatives previously as well, if there's an insistence on subject attributes, which is to do the same thing Microsoft did with respect to EV certificates, which is not to overload the X.500 series of naming identifiers, and instead use an OID attribute appropriate for the naming context. There, the naming context itself (the OID) serves to unambiguously identify the semantic meaning of the content.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/ae0c956a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image81f781.PNG
Type: image/png
Size: 1385 bytes
Desc: image81f781.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/ae0c956a/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagefff56e.PNG
Type: image/png
Size: 498 bytes
Desc: imagefff56e.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/ae0c956a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image9dbd82.PNG
Type: image/png
Size: 61132 bytes
Desc: image9dbd82.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/ae0c956a/attachment-0005.png>