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

[Ryan Sleevi]

On Tue, Jun 12, 2018 at 5:39 AM, Pope, Nick <Nick.Pope at thalesesecurity.com>
wrote:

> 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?
>

Certainly, Google is concretely and directly opposed to this use case, of
repurposing organizationIdentifier for ETSI certificates, EV or otherwise.

1) It's not necessary.
  a) This is a feature wishlist of consumers of a particular market, not an
actual technical need.
  b) That feature wishlist is not well-founded for what is technically
achieved.
  c) That feature wishlist is not regulatory required, as you note.
2) It is technically inferior.
  a) Its repurposing of the X.500 organizationIdentifier introduces
ambiguity in the semantics that can be meaningfully addressed by using an
alternative subject OID specific for the purpose.
  b) Alternatively, constraining to a specific expression of ETSI QCs
avoids any ambiguity of overloading.

I mean, I think it's a reasonable request to make, and I don't want to
discourage requests, but I think related to PTCs, it's a suboptimal
solution. Given that it's merely forward thinking about the intersection
with PTCs, there's a distinct opportunity to do things correct.

I don't think it's a reasonable request to take another SDOs work product
and attempt to overlay that as-is on PTCs and not expect some pushback or
consideration about PTCs beyond the narrow ETSI scope. This is especially
true given the mounting concerns that multiple user agents have shared
regarding the ETSI audit and accreditation scheme, and the potential of
rejecting such audits outright in the future - which is very much a
pressing concern that multiple parties are working to resolve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/9a99e9a8/attachment.html>