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

[Ryan Sleevi]

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

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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/1a04e30f/attachment.html>