[cabf_validation] OrganisationIdentifier mandated by ETSI TSt119 495

Tim Hollebeek tim.hollebeek at digicert.com
Wed Nov 21 11:54:53 MST 2018


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

 

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 <mailto:sleevi at google.com> > 
Sent: Wednesday, November 21, 2018 12:34 AM
To: jeremy rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Doug Beattie <doug.beattie at globalsign.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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? 

  _____  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181121/8506135a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20181121/8506135a/attachment-0001.p7s>


More information about the Validation mailing list