[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Tue Nov 20 08:34:32 MST 2018

On 20/11/2018 4:53 μ.μ., Doug Beattie via Validation wrote:
>
> 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.”?
>

9.2.7 which defers to the BRs for specific fields. I mentioned that in 
https://cabforum.org/pipermail/validation/2018-November/001140.html.

Dimitris.

> 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
>
>
> _______________________________________________
> 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/20181120/7672a593/attachment.html>