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

[Dimitris Zacharopoulos]

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 <mailto: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.


Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/6772f564/attachment.html>