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

[Ryan Sleevi]

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>
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/f89090ed/attachment.html>