[cabf_validation] OrganisationIdentifier mandated by ETSI TSt119 495

[Wayne Thayer]

On Wed, Nov 21, 2018 at 11:55 AM Tim Hollebeek via Validation <
validation at cabforum.org> wrote:

> Doug,
>
>
>
> I want to agree with you.  I think that would be the right way of doing
> things.
>
>
>
> Unfortunately, we have seen that there is substantial opposition to adding
> new fields, even if they have already been standardized by another
> standards body.  I think that’s unfortunate.
>
>
>
> If we can get consensus that new fields can be added as long as
> appropriate vetting rules or standards are referenced, I would be in favor
> of that.
>
>
 Tim - are you arguing for doing nothing to clarify 9.2.8 and the OU field?
Given the context, I'm having a hard time interpreting your statement any
other way.

>
>
> -Tim
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Doug
> Beattie via Validation
> *Sent:* Wednesday, November 21, 2018 6:17 AM
> *To:* Ryan Sleevi <sleevi at google.com>; Jeremy Rowley <
> jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] OrganisationIdentifier mandated by ETSI
> TSt119 495
>
>
>
> Jeremy,
>
>
>
> I think we should define a new field along with validation rules for LEI
> (and any other fields we think are important including the ETSI OrganisationIdentifier
> that started this thread).  That would be the cleanest way to get
> consistent use of new important fields like this.  The validation rules
> don’t need to be particularly strong (look at the OU field), but they
> should be defined and used consistently.
>
>
>
> The alternative is that the CAs come up with a new extension outside of
> CABF to include “Supplemental Org Information”.  Either way, the format and
> validation guidelines need to be agreed to so we end up with a constant
> approach for conveying this information to those that want it.
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Wednesday, November 21, 2018 12:34 AM
> *To:* jeremy rowley <jeremy.rowley at digicert.com>
> *Cc:* Wayne Thayer <wthayer at mozilla.com>; CA/Browser Forum Validation WG
> List <validation at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com>
> *Subject:* Re: [cabf_validation] OrganisationIdentifier mandated by ETSI
> TSt119 495
>
>
>
> Is there any rule that prohibits issuing an OV cert verified to the same
> level as EV? If not, why would a CA not simply do that?
>
>
>
> As Wayne mentioned, the value proposition of an EV certificate has been
> that the Subject for such certificates is consistent among industry, and
> verified to the same level of rigor. Adding arbitrary information -
> including that verified using arbitrary standards - seems to remove that
> value proposition. This is especially relevant for those CAs that suggest
> the certificate viewer should be made more prominent, or display more of
> the Subject, in order to deal with the messiness of the real world (such as
> two entities incorporated in the same country sharing the same name, but
> different jurisdictions of incorporation - the "Stripe, Inc" problem).
>
>
>
> If a user inspects this certificate in a viewer, as suggested by some
> members' CP/CPS, are they likely to be mislead by this information? If not,
> why not?
>
> If the user is expected to be capable of recognizing which fields are
> relevant to EV, and the validation standards the CA is specifically
> applying to those other fields, would they also be capable of recognizing
> the CA's OV++ OID? If not, why not?
>
>
>
> I don't believe the burden of proof for "it wouldn't hurt anyone" has been
> demonstrated. Users that are required to inspect the certificate - e.g. by
> CA's CP/CPSes - seem most at risk for such certificates.
>
>
>
> On Tue, Nov 20, 2018 at 7:24 PM Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> If it's not necessarily for browser use, does that matter? If it is for
> browser use, then we can define standards for it. For example, gleif has an
> oid for lei. Only thing stopping its use is the cab forum because of the
> odd rule regarding inclusion. Wouldn't hurt anyone if it was included and
> the lack of permission to include it hinders adoption by browsers who may
> want to use it. If the browsers or CAs care about the validation of a
> particular field, defining criteria is easy.
> ------------------------------
>
> *From:* Wayne Thayer <wthayer at mozilla.com>
> *Sent:* Tuesday, November 20, 2018 4:13:12 PM
> *To:* Jeremy Rowley
> *Cc:* CA/Browser Forum Validation WG List; Ryan Sleevi; Doug Beattie
> *Subject:* Re: [cabf_validation] OrganisationIdentifier mandated by ETSI
> TSt119 495
>
>
>
> There are no standards for verifying arbitrary subject attributes, so each
> CA will make up their own policies and the information in those fields will
> be inconsistent, at best.
>
> On Tue, Nov 20, 2018 at 5:04 PM Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> The level of verification is different.  As long as all information is
> verified to the relevant standard, what's the risk of including additional
> subject fields?
> ------------------------------
>
> *From:* Wayne Thayer <wthayer at mozilla.com>
> *Sent:* Tuesday, November 20, 2018 4:02:54 PM
> *To:* Jeremy Rowley
> *Cc:* CA/Browser Forum Validation WG List; Ryan Sleevi; Doug Beattie
> *Subject:* Re: [cabf_validation] OrganisationIdentifier mandated by ETSI
> TSt119 495
>
>
>
> By that logic, OV certs are as good as EV - the information is all
> verified.
>
>
>
> On Tue, Nov 20, 2018 at 3:49 PM Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> Why is it dangerous? These are subject fields. What's the risk in
> permitting them of they are verified?
> ------------------------------
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181121/a3df8fe0/attachment.html>