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

[Dimitris Zacharopoulos]

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

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

>
> So as I said, this is explicitly worse, because it removes validation 
> requirements and does not address the CA needs to disambiguate between 
> ETSI and non-ETSI certs. The entire value proposition of using this 
> field is to that it's validated information - but as mentioned, we can 
> avoid this whole problem by not sticking it in the subject.

Please, allow me to repeat that we are all in agreement that we should 
address the validation of such information, which will be similar with 
the validation of the Registration Number that goes into the 
serialNumber field. Mr. Pope can work on this concern and add the 
required information.

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 discussed during the F2F, it seems that there's a far more
>>     viable option that's aligned with publicly trusted certificates,
>>     namely, that of aligning in the QcStatements. We spent quite some
>>     time trying to understand the rationale and necessity of encoding
>>     in the subject, as it seemed like it was based on both a
>>     misunderstanding of the value proposition and of the technical
>>     necessity.
>>
>>     I would again reiterate those concerns, to ask why this
>>     information cannot be encoded within the qcStatements.
>
>     As you said, both would be "viable" options so there is no
>     misunderstanding about the technical necessity. They should both
>     work. I believe that since this identifier is very specific
>     information directly-coupled with the Subject of the Certificate,
>     it should be in the designated extension which is the Subject DN.
>     For me, it doesn't make sense to include information related
>     uniquely to the Subject, in the qcStatements. All the existing
>     ETSI TS or EN documents related to the qcStatements extensions do
>     not contain identifiable information related to the Subject. Mr.
>     Pope can correct me if I'm wrong here.
>
>
> Are those concerns shared with subjectAltName? There's no technical 
> need to stuff that information in the subject, and ample and 
> compelling reason not to.

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.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/203d0247/attachment-0001.html>