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

[Ryan Sleevi]

On Tue, Jun 12, 2018 at 5:18 AM, Pope, Nick <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/ef1919cd/attachment.html>