[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Tue Nov 20 14:04:53 MST 2018

From: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > 
Sent: Tuesday, November 20, 2018 11:10 AM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >
Cc: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Subject: Re: [cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

On Tue, Nov 20, 2018 at 7:53 AM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

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

Good point on the length of this thread - I'll start a new thread if/when I update the proposal.

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.”?  

As Dimitris stated, section 9.2.7 references these fields, so they don't fall under the SHALL NOT in section 9.2.8.

 Thanks Wayne and Dimitris, I missed the details in section 9.2.7.  That was the reference I was looking for.

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)

Not that I'm aware of.

 Section 9.2.7 is basically the reference.

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

This seems messy given all the references to validation methods in the BRs that don't apply for EV.

 OK

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

For EV, section 9.2.8 requires "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA.". Are you suggesting that we allow the OU field in EV certs and allow unvalidated information - as long as it's not "misleading" - to be placed in that field? That would be a more significant change than what I was proposing and one that IMO goes against the concept of EV.

There is a lot of confusion about that 9.2.8 applies to, imo, even with your proposed ballot.  What does the “other’ apply to? Section 9.2.1-8 list fields, some of which area optional.  9.2.8 applies to “other” optional fields, of which there should be none.

I also think that CAs have assumed that the processing rules for OUs in EV is the same as OV.  Your ballot support this by permitting non-validated information as long as it’s not misleading or contains “a name, 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 11.”  All you need to do is look at some EV certificates and see non-validated content like:

*	OU= IT Department
*	OU=Admin
*	OU=Web Service
*	OU=COMODO EV SSL 
*	OU=Information System Div.
*	OU=Global IT

If fields are optional, then that should be defined within the applicable section (9.2.1-8) and not within a catch-all section so we can be  very clear.  If the intent of 9.2.1.8 is to permit CAs to add new fields to the subject, as long as it’s validated, then that is another story (Jeremy’s question).  I recommend we remove the verbiage in 9.2.8 and say: “No other Subject attributes are permitted”.

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

(responding to Jeremy's question) The thinking for my proposal is that we want to tightly define what information is placed in the subject of EV certificates and how it is validated to ensure that the information can be relied upon. Isn't that what fundamentally distinguishes EV? New fields can be added by working with the Forum to gain approval for them.

Sure – so then it looks like you agree that no other Subject Attributes should be permitted, and if we want to add them, then we need a ballot to specifically add them as new fields in 9.2.  This implies that the ESTI organizationIdentifier attribute (OID 2.5.4.97) should be balloted to be added as a new Subject Attribute along with the rules for validation.

Doug

From: Validation <validation-bounces at cabforum.org <mailto: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 <mailto:wthayer at mozilla.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Ryan Sleevi <sleevi at google.com <mailto: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 <mailto: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 <mailto:sleevi at google.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto: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/03634a4f/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/03634a4f/attachment-0001.p7s>