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

[Ryan Sleevi]

On Tue, Jun 12, 2018 at 3:14 PM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

>
>
> On 12/6/2018 1:32 μμ, Ryan Sleevi via Validation wrote:
>
>
>
> 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.
>
>
>
> Please allow me to summarize HARICA's point of view.
>
> As we have discussed in the past, Technical Standards like the products of
> IETF or ITU-T usually don't describe policy. The CA/B Forum on the other
> hand, uses some technical "product" work and apply policy which provides a
> level of consistency at a global scale, for the ultimate benefit of Relying
> Parties that can make trust decisions based on information included in
> Publicly-Trusted Certificates.
>
> The way I read the proposal (and I don't think I'm the only one with that
> interpretation), it does not repurpose organizationIdentifier as described
> in X.520 (http://www.alvestrand.no/objectid/submissions/2.5.4.97.html).
>
> "An attribute of type organizationIdentifier holds an identification of
> an organization different from the organization name. It is an unstructured
> string, much like serialNumber is, except it is not limited to
> PrintableString. organizationIdentifier ATTRIBUTE ::= { WITH SYNTAX
> UnboundedDirectoryString EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS
> MATCHING RULE caseIgnoreSubstringsMatch SINGLE VALUE TRUE ID
> id-at-organizationIdentifier }".
>
> IMO, the proposal tries to apply some policy on how this attribute can be
> used in a way that is aligned with the rest of the attributes included in
> Publicly-Trusted Certificates. It just tries to include a Nationally unique
> identifier which is uniquely linked with the Subject of the Certificate. It
> is much like the *subject:serialNumber* along with the *subject:jurisdictionCountryName
> *field combined into one.
>
>    - Do we want to know how this information is validated? Of course we
>    do, this is definitely something that needs to be addressed.
>    - Do we need to add semantic description to formalize this policy? My
>    proposal was more lax (included a "MAY" to reference the strict semantics
>    identifiers of ETSI documents). However, it appears that the majority
>    prefers a more structured and more detailed description if these semantics
>    over a looser description.
>    - Do we see any use of this new attribute if it were to be included in
>    a PTC Certificate? As demonstrated by mr. Pope in his presentation at the
>    recent F2F, the answer is yes. It could very well be expanded for QWACs as
>    well and Relying Parties could have additional well-validated information
>    to assist them in their trust decision.
>
> We have talked many times in the past about the Web PKI being used as a
> "Transport" of a security layer and there are arguments describing why this
> is generally a bad idea. However, this case the way I read it, describes a
> TLS authentication between a Subscriber (it could be a Bank that adheres to
> the PSD2 directive or a Company that adheres to some regulation that
> mandates the use of QWACs which include an additional layer of scrutiny by
> Supervisory Bodies, and possibly other examples) and a Relying Party. How
> does this Relying Party make use of the extra information included in the
> EV Certificate? This brings back the nice discussions about EV which I
> don't want to recycle :)
>
> Generally speaking, if this was not about changing the EV Guidelines and
> the proposal was to use the organizationIdentifier in OV Certificates, it
> would probably be allowed with the existing Baseline Requirements rules.
> HARICA does not currently issue EV Certificates but after reading the EV
> Guidelines, and the additional information that is validated and included
> in EV Certificates, I believe that this new attribute deserves a place in
> there :)
>
> We may not have unanimous agreement on this topic which means that if
> other members feel very strong about this proposal (HARICA does not), they
> could proceed with a ballot and risk a possible vote failure or a majority
> pass. It will not be the first time.
>
I think that's actively detrimental towards the goal of finding a solution,
and could just as easily result in browsers changing to explicitly reject
certificates with organizationIdentifiers from being publicly trusted, if
their validation fails to meet sufficient goals.

I appreciate your arguments in favor, but you've not really addressed the
meaningful criticisms. I agree that we may be going in circles at this
point, and it may be that simply adopting whatever ETSI says is good to
adopt is a viable solution for HARICA, but it doesn't seem viable for the
Web at large.

Could you help clarify: What do you find deficient in the two viable
technical alternatives that are proposed that resolve all complaints. Could
you indicate why, besides that's not what Nick asked for (noting, most
importantly, that the status quo does *not* apply to PTCs, as clearly
stated), you find those problematic?

It doesn't feel like the conversation is moving, if viable alternatives are
being ignored and not even responded to. I feel like I'm doing all I can to
help find a solution here, but please help me understand why you feel
that's not possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/3ca9c590/attachment-0001.html>