[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Wayne Thayer]

On Tue, Nov 20, 2018 at 7:53 AM Doug Beattie <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.

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.

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.

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

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

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> 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/e8ae827b/attachment-0001.html>