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

[Ryan Sleevi]

On Mon, Jun 11, 2018 at 11:26 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I think it can be encoded in qcStatements or something similar, and I have
> encouraged the ETSI and qualified cert folks to consider options like that
> going forward.  At this point, though, that would require them changing
> their standards, and as we all know, that can take a while.
>

>From the presentation, however, it was clear that this current use is
relegated to non-public-trust, and they were exploring this for public
trust. Thus, I think it's reasonable to state that public trust has a
different degree of expectation, and such changes can and should be
expected for public trust.


> So qcStatements does not solve the problem of the existing conflict
> between the ETSI requirements and the BRs.  It seems like something along
> the lines of what Nick proposes should be acceptable, if we point to all
> the appropriate ETSI clauses for format and validation requirements.  As
> you correctly note, we don’t want unvalidated information being tossed into
> the field.
>
>
>
> I suspect the ETSI folks are going to be far more willing to listen to us
> on qcStatements if we are willing to find a way to accommodate their needs
> on organizationIdentifiers.
>

I'm not sure how that follows - the current standards are not relevant for
public trust, thus we have a path forward to do the right thing where
everyone gets what they want. Is there a reason not to take it, and is that
reason anything other than "We want it sooner"?


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