[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Ryan Sleevi]

On Tue, Nov 13, 2018 at 1:39 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> I'm sorry you thought I was singling out Google, you took it the wrong
> way. I searched through past minutes and the archives trying to find the
> position of other browsers and was unsuccessful. Of course, I might have
> missed something but in the public archives I didn't find a clear statement
> from other browsers.
>

Those past minutes show, for example, Mozilla supportive of the concerns.


> I understand your position and interpretation of 9.2.8 and the fact that
> you claim in "
> https://cabforum.org/pipermail/validation/2018-June/000928.html" that
> this is the correct read of the section. In the London meeting we agreed
> that it was ambiguous to the very least and that there were different
> interpretations even between Native English speakers in the room. In my
> plain (non-native) English read of the section, the part where it says
> "except as specified in Section 9.2" seems to include the part which allows
> optional sub fields.
>

Note that locality information is optional.


> If the intent was to only include the specified subjectDN attributes, why
> does it have (1) and (3) to *restate* that the optional subfields must be
> verified by the CA? It seems very redundant because for each one of these
> specified Subject fields, the EV Guidelines describe EXACTLY how the CA
> must verify the information.
>

Locality fields.


> I don't know how we can move forward with this. Would members support a
> ballot that attempts to add the organizationIdentifier with language
> specific to ETSI? This might need to be a majority vote as we clearly see
> conflicting opinions.
>
> In any case, HARICA would support a ballot that clarifies 9.2.8 either way
> (to explicitly disallow or allow other subjectDN attributes), regardless of
> the organizationIdentifier issue. I think the risk of CAs being confused by
> the current language is high enough that might lead to mis-issuances and
> must be dealt with some urgency.
>

There are a variety of options here. Much as we would approach the
situation if OASIS, ITU, ISO, ANSI, or some other
limited-membership/pay-for-play SDO attempted to define something
contradictory, we need to acknowledge that ETSI's documents are not
immutable - finding a solution necessarily involves finding a compromise.
Just because ETSI - a pay-for-play SDO that does not regularly solicit the
CA/Browser Forum for feedback, despite the ongoing participation by the ESI
vice-chairs - wrote it in a document doesn't mean it's inviolate truth.

I disagree that the situation requires urgency in resolving; CAs always
have a path here, which is when in doubt, don't issue. As we've seemingly
agreed on, there's no fundamental need for PTCs here, so the concerns to
the CA/Browser Forum regarding urgency are, at best, misstated.

We do not support attempts to normatively specify the ETSI documents
through the Baseline Requirements or EV Guidelines. These documents are not
designed with the Internet community in mind, nor are they developed in a
manner that permits participation through that broader community. In short,
attempting to specify normative guidance on particular fields, except those
as specified either through the IETF or the CA/Browser Forum, is something
we are fundamentally concerned with, and believe that all members concerned
with openness and transparency should be similarly concerned.

Further, given the particular problem of the ETSI specification for
organizationIdentifier fully 'squatting' the format and name space, there's
no path to compromise that would allow other uses of the
organizationIdentifier in a compatible way. That's because 319 412-1 (and
119 412) 'squat' all interpretations of the first three characters and
define semantics around them that are specific to the ETSI case. This is,
at best, disruptive towards an Internet-wide interoperability. In the case
of private PKIs, I take no issue with this approach from a policy
perspective - after all, private PKIs exist for such - but I do take
significant issue with developing it behind closed doors and attempting to
require it / squat on it for the Internet. There are technical issues with
that approach, which I've seen repeatedly from past professional
experiences attempting to define string identifiers with structured
semantics (rather than using ASN.1 as intended), but frankly, given we have
no interest in validating such, it's not particularly compelling to try to
specify in a way to avoid those issues.

Of the options that remain, we can see variations on "The CA/Browser Forum
change the rules for the Internet based on closed door negotiations at
ETSI" and "ETSI adapts to harmonize its profiles to better interoperate
with PTCs". Obviously, I have a preference, but for completeness, we can
consider some of the following as "options":

1) Permit arbitrary inclusion of Subject information in EV certificates,
similar to the BRs
  Pro: ETSI can now add whatever other fields to the Subject information
  Con: The premise and value of EV certificates having a consistent
profile, particularly in Subject, is meaningfully undermined. Presented
with two certificates from two different CAs, both representing the same
field, users can no longer be assured that the vetting is consistent.
2) Permit inclusion of Subject information in EV certificates, similar to
the BRs, provided it uses an OID arc that the CA is explicitly authorized
by the OID arc authority to issue, and both the formatting and validation
requirements are defined by the OID arc authority
  Pro: ETSI can now add whatever other fields to the Subject information
  Pro: Users can be assured that the level of assurance for such asserted
fields will be consistent for all assertions of that given OID
  Con: ETSI will need to update
  Con: Users may still be confused through the display of subject
information that is not validated to a consistent and interoperable
(Internet-wide) definition.
  Con: CAs may still (incorrectly) misread this as permitting squatting on
common fields, despite those common fields not defining the formatting or
validation requirements
3) Do not permit additional Subject fields (status-quo); ETSI can add the
data as appropriate in necessary extensions
  Pro: Structurally and semantically cleaner, ensuring the correct
functioning of, for example, name constraints
  Con: ETSI will need to update

On the extensions space, whether it be through the QCStatements (where
assertions about the qualified status are already being made) or through a
separate, ETSI-defined extension, they functionally achieve the goal.

I understand that ETSI created this mess, and it's unfortunate that the
CA/Browser Forum is being asked to clean it up. It's important to
recognize, however, that extending the Subject field is, in general, a
structurally unsound idea. This has been well known and part of the
motivation for the development of the X.509v3 extension space; the notion
of the X.500 DIT model for naming does not align well with the practical or
intended use cases of PKI or certificates. Consider, for example, the
semantic meaning attached to the ordering of the AVAs within the Subject.
These reflect the presumed hierarchy of the X.500/X.520 DIT model -
intended to be organized from least-specific aggregation (e.g. country) to
most-specific aggregation. The application of organizationIdentifier and
the semantics being proposed for it are, structurally, at odds with the
purpose and construction of the Subject. To achieve those semantics, one
would need to express the organizationIdentifier as part of a sibling SET
of the RDN containing the country, since the organizationIdentifier itself
contains the country-specifier under ETSI. That is, rather than

SEQUENCE {
  SET {
    SEQUENCE {
      Type = countryName
      value = DE
     }
 }
 SET {
   SEQUENCE {
     Type = stateOrProvinceName
     Value = ...
   }
 }
 ...
 SET {
  SEQUENCE {
    Type = organizationIdentifier
    Value = ...
  }
 }

The correct - that is, adhering to the purpose and intent of X.509 (by
virtue of X.500/X.520) - encoding would be instead
SEQUENCE {
  SET {
    SEQUENCE {
      Type = countryName
      Value = DE
    }
    SEQUENCE {
      Type = organizationIdnetifier
      Value = ...
    }
 }
}

That is, the organizationIdentifier is semantically equivalent to the
totality of the other asserted identity. Except multi-value sets in the RDN
are not well 'supported' by clients, nor displayed well - and there's
already a structurally and semantically correct way of expressing
'alternative' subject names - a subject alternative name (with a
directoryName of just the organizationIdentifier) - or expressing the
context in which a given qualified certificate is to be interpreted - the
qcStatements.

Why am I belaboring this point? Because the choice of #1 or #2 is to ignore
all of this and favor expediency. While I'm sympathetic to the argument
that it doesn't matter what X.500/X.520 intended, since the DIT never
materialized, and sympathetic to arguments to suggest it's an intentional
thing to avoid, that's not the case here - the argument for why this is to
be placed in the subject is based, fundamentally, on a lack of context or
awareness about the 'correct' or 'intended' way of doing things. And I take
issue with that, because that's a mistake resulting from the process
(pay-to-play participation), and there are so many ways that could have
been avoided - including circulating for specific feedback and review, but
more meaningfully, developing within an open-participation, Internet-wide,
multi-stakeholder model like the IETF.

Of these options, I clearly have a preference for #3, and have hopefully
made it clear the potential lasting and negative effects other options can
have on the legitimacy and value of the CA/Browser Forum, particularly when
considering other pay-to-play or nationalized SDOs, but of the remainder, I
find #2 more compelling than #1 in terms of protecting the user and
providing consistent assurance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181113/4c97f5b0/attachment.html>