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

Tue Jun 12 02:39:19 MST 2018

Ryan,

In response to your points:

“My understanding is none of this requires the use of Publicly Trusted Certificates. If it does, can you provide supporting information to that fact?”

The requirement currently under discussion goes beyond the regulatory requirement for securing TPP (Third Party Payment Service Provider) to Bank  and looks at the practical need to secure customer (ie. public) access.  Unfortunately, I am unable to provide information on the considerations of banks regarding their security requirements.

“The issue is not about prohibiting QCStatement, but rather about prohibiting organizationIdentifier, so I wasn't sure how to parse your request for forbearance.”

Do I take it that your belief is that it is not possible to extend EV to include organizationIdentifier.  What is the reason for this prohibition?  Is this a general CABF consensus view?

Nick

________________________________
 [cid:image22af5c.PNG at a1ec0f56.478b7cf1] <http://www.thalesesecurity.com>
Nick Pope
Principal Consultant, Advanced Solutions Group
Tel: +44 1844 203585
Mob: +44 7880 787940
[cid:image7d91e5.PNG at bc4d7ff8.4ca1284a]<https://www.twitter.com/thalesesecurity>@thalesesecurity

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

[cid:imageeed30e.PNG at ee959c63.4c8b6a39]<https://gdpr.thalesesecurity.com/>

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

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: 12 June 2018 10:25
To: Pope, Nick
Cc: Tim Hollebeek; CA/Browser Forum Validation WG List
Subject: Re: [cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

On Tue, Jun 12, 2018 at 5:18 AM, Pope, Nick <Nick.Pope at thalesesecurity.com<mailto:Nick.Pope at thalesesecurity.com>> wrote:
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.

My understanding is none of this requires the use of Publicly Trusted Certificates. If it does, can you provide supporting information to that fact?

The issue is not about prohibiting QCStatement, but rather about prohibiting organizationIdentifier, so I wasn't sure how to parse your request for forbearance.

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.

I don't think it's possible to reasonably accomodate this request. Had we been involved earlier, through the ETSI liason function, it sounds like we could have provided input and advice to prevent this unnecessary conflict between PTCs. However, as you indicate above, this is merely a 'consideration' or 'desire', and as such, is not an explicit or legally-mandated need - and, if it were, would itself be just as problematic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/d00f5e7a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image22af5c.PNG
Type: image/png
Size: 1385 bytes
Desc: image22af5c.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/d00f5e7a/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image7d91e5.PNG
Type: image/png
Size: 498 bytes
Desc: image7d91e5.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/d00f5e7a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageeed30e.PNG
Type: image/png
Size: 61132 bytes
Desc: imageeed30e.PNG
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/d00f5e7a/attachment-0005.png>