[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Tue Nov 20 07:53:18 MST 2018

We’re getting too many different topics into one email thread, and honestly, section 9.2 is a mess.

EV GL section 9.2 lists a number of fields that can be in the EV certificates, but has anyone noticed that it doesn’t include Country, Local, State/Prov?  Does this mean these fields are prohibited when we say “..and SHALL NOT include any Subject Organization Information except as specified in Section 9.2.”?  

Is there a reference somewhere that permits the use of all of the BR Subject DN fields and states that those listed in section 9.2. are supplemental to what’s defined in the BRs?  If so, then there is no need to add a qualifier for OU as that is already defined in the BRs (just like C, L, S)

I suggest we update the intro in section 9.2 to say that the requirements in this section are additive to those in BR section 7.1.4.2.2 and remove the SAN description which is in section 7.1.4.2.1 (unless we need to specify no wildcard values in that description explicitly).

***Topic 2: OU field

We should look at the OU field use separately.  The use is currently:

*	You can’t put in a value that might be mis-interpreted as a DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity 
*	unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, , subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1.   has verified this information, in which case you can put DBA, tradename, trademark, address, location, etc.

How is a relying party supposed to know if they can rely on this or not?  

*	Validated info can only go in when there is an Org field present
*	Non-validated (and not misleading) information can to in for any certificate type.

I’d recommend we define this field in the BRs as unvalidated information and let any values be placed in it.  If necessary, require “This is unvalidated info:” as the first portion of the OU field.

***Topic 3: Other subject fields

Lastly, to Jeremy’s point: How do we get new Subject information added to certificates?  We’ve had requests to include Logos, Bitcoin account names, and other values from customers, but currently that is not permitted. Do we need to create a ballot for each new field and define the vetting rules for it?  It seems dangerous to permit new fields without an agreed-to validation rule for it.  I wonder if the community would permit additional values to be added to the Subject DN when the use is outside of typical WebPKI.

Doug

From: Validation <validation-bounces at cabforum.org> On Behalf Of Jeremy Rowley via Validation
Sent: Tuesday, November 20, 2018 1:17 AM
To: Wayne Thayer <wthayer at mozilla.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Why do we forbid other subject attributes? I’ve never really been sure why we prohibit additional fields, so why not permit other subjects if they are covered by an RFC? 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Wayne Thayer via Validation
Sent: Monday, November 19, 2018 2:35 PM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

On Thu, Nov 15, 2018 at 2:00 PM Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > wrote:

I would propose that the best solution to OU issue is a ballot that clarifies section 9.2.8’s language forbidding subject fields other than those listed in section 9.2. If there is consensus, that ballot could also explicitly add organizationUnit to section 9.2. My opinion is that we should tightly control what information is included in the subject of EV certificates, but OU fields - if validated and not misleading - are okay.

Here's a simple proposal for clarifying section 9.2.8 and explicitly permitting OU: https://github.com/wthayer/documents/commit/d0b3da38b3a7d950f48661dce5a9f0a0d90b50ae

Comments appreciated.

Defining a new extension provides a clear path forward for ETSI without any CAB Forum dependencies. It also allows the information to be properly structured as Ryan described. I would encourage ETSI to adopt this approach and to get busy updating 119 495. If ETSI representatives want to continue to pursue the use of the organizationIdentifier attribute, I would like to request a detailed explanation of why the "new extension" alternative is inferior and unworkable.

Four days have gone by without any response to my request for more information about this **urgent** issue.

- Wayne

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