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

[Ryan Sleevi]

On Mon, Jun 11, 2018 at 12:21 PM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

>
>
> On 11/6/2018 4:37 μμ, Ryan Sleevi wrote:
>
>
>
> On Mon, Jun 11, 2018 at 9:25 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
> wrote:
>
>>
>>
>> On 11/6/2018 4:00 μμ, Ryan Sleevi wrote:
>>
>> That seems like a strictly worse proposal, because it does not define any
>> validation requirements. Also, the interpretation of BRs 7.1.4.2.2 wasn't
>> aligned with the discussion.
>>
>>
>> My proposal tried to address specific concerns about the "exclusive" use
>> of the organizationIdentifier by ETSI. If you are concerned about the
>> validation requirements, we should address those but I wouldn't expect them
>> to be materially different than the validation of the "Registration Number".
>>
>
> I'm afraid it may not have been explained well, then, because the core of
> the issue was that
> 1) It restricts this field to exclusive use of ETSI without defining the
> context for where it's identified as such
>
>
> My recommendation does not restrict this field exclusively for ETSI. On
> the other hand, I think Mr. Pope's proposal describes only the ETSI way.
>

Correct. I understand your proposal, and I was describing the "it" as
Nick's proposal.

On its face, Nick's proposal is objectively better than yours, because it
at least describes the possible values that can be had. As linked to
previously from the minutes, we discussed this on the call as an extremely
desirable property to have. So it is unquestionably worse to go from a
state where "It can mean only this" to "it can mean whatever you want".

As discussed in the F2F, the desired state is "It unambiguously means this
in this context, while can be used unambiguously in other contexts". The
counter-proposal you advanced achieves the rather opposite effect of that,
which is why I think it's failing to address one of the cores of the
problem.


> 2) For the ETSI case, it doesn't prevent other organizations for issuing
> in this in a way that can be seen as confusing/misleading
>
>
> I do not agree with this interpretation. It is no more
> "confusing/misleading" than the serialNumber attribute. For Subscribers
> that want to abide by some kind of regulation that requires the
> organizationIdentifier field to be completed in a semantic-specific way,
> the associated TSP will know how to encode this information in the
> Certificate. IMHO there is no need to add more complex rules (like
> describing the entire ETSI qcStatements requirements) in the EV guidelines.
> A simple reference to the relevant ETSI documents and a "MAY", should be
> sufficient.
>

Except the serialNumber has a defined context to disambiguate, as was also
pointed out in the F2F - namely, that jurisdictionOfIncorporation serves to
disambiguate the context of the serialNumber is an extensible and
unambiguous way that is unified.

As discussed during the F2F, describing the ETSI qcStatements *is*
desirable, if we go down that route of including it in the subject (which
is not, as discussed, a technical necessity nor a desirable outcome),
because then you can ensure unambiguously that "If X is present, then Y
MUST be interpreted as such". That's the very thing we should be striving
for regarding subject context in the X.520 series.

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.

This is fundamentally an issue of overloading the X.500 series naming, and
it's exactly why during the development of the EVGs that the existing name
types were not used (as they would otherwise have been ambiguous).


> In addition to the PSD2 requirement that was raised in the F2F
> presentation, this field is also part of the ETSI EN 319 412-3 Certificate
> Profile related to Legal Entities and could also be used for QWACs in the
> future. And just to avoid any misunderstanding, I don't think there are any
> expectations from the browser members that this information must be viewed
> in a UI-friendly way. However, relying parties should be able to write
> their own applications or manually parse a TLS certificate to verify
> additional attributes if they desire to do so.
>
> Even though the minutes are not finalized, I think mr. Pope expressed the
> fact that these must be Publicly-Trusted Certificates and part of the Web
> PKI. He can correct me of course if I didn't hear that right.
>

As stated during the F2F, that necessity is not present. It was desired, to
go along with browser UI changes, but the context and usage is not related
to PTCs. Even if it was, there would still be the similar objection.

There are viable paths forward here that don't involve an unnecessary
ambiguous overloading.


> It should be processed no different than the currently used serialNumber.
> The only difference is that the organizationIdentifier field MAY contain
> additional semantics where the serialNumber does not. If we could turn back
> time, and able to recommend a way forward to ETSI, I would probably propose
> using the existing serialNumber field to allow possible semantics.
>

Similarly, that seems like a distinctly worse scenario. This is
semantically different information than the serialNumber, as repeatedly
stated in the F2F and in the ETSI documents. Again, the issue relates to
the fundamental usage of X.500 naming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/c394a86a/attachment.html>