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

[Tim Hollebeek]

Either #1 or #2 is fine.  I was being vague only because the proposals various people have run by me were similarly vague.  

 

As long as there is something that fairly clearly and reliably indicates that the context is ETSI semantics, I think that’s good enough.

 

The question I find far more interesting is the rules for how one validates that a tax id is correct for a particular entity.  What does ETSI have to say about that?

 

I really need to get around to reading the relevant ETSI standards one of these days …

 

-Tim

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, June 11, 2018 5:56 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>; Dimitris Zacharopoulos <jimmy at it.auth.gr>
Subject: Re: [cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

 

I'm having trouble parsing this.

 

I agree that expressing this as an OID in the policyQualifiers/qcStatements serves to unambiguously identify the case - that's different than the proposal as written, but ensures it stays away from overloading X.500 semantics in an ambiguous way. Fundamentally, that's the same as expressing a dedicated OID that indicates its ETSI in its context. This seems desirable - and aligns with the reality that we don't have the global DIT that X.500 imagined that would contextualize and disambiguate these fields.

 

That is, to recap:

1) Express it within the policyQualifiers for the qcStatements

2) Express it as a dedicated attribute OID (with a defined syntax) to indicate the context

 

Both achieve that purpose.

 

I'm not sure if you're suggesting a third option, as one possible read of your suggestion is:

3) Express it using an X.500 organizationIdentifier, and rely on a given policyQualifier being present to indicate the qcStatement, which, by proxy, expresses a semantic and syntactic interpretation that aligns with the ETSI piece.

 

Of course, #3 is unfortunately also problematic, in that now we'd have to indicate further ETSI QWAC-specificness into the BRs to indicate that the organizationIdentifier can only be present (and must contain the appropriately validated information) if and only if the ETSI policyQualifiers are asserted, and that further ensures the BRs carry ETSI-specificness for what is meant to be a general set of requirements.

 

This is why #1 and #2 are so much more preferable as solutions.

 

On Mon, Jun 11, 2018 at 12:55 PM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

Several people have suggested the qc OID already serves this purpose.

 

-Tim

 

Of course, I offered alternatives previously as well, if there's an insistence on subject attributes, which is to do the same thing Microsoft did with respect to EV certificates, which is not to overload the X.500 series of naming identifiers, and instead use an OID attribute appropriate for the naming context. There, the naming context itself (the OID) serves to unambiguously identify the semantic meaning of the content.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/c8512461/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/c8512461/attachment-0001.p7s>