[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Wayne Thayer]

I spent far too long this morning researching the origins of EVGL section
9.2.8 and came up mostly empty. The contradictory second sentence first
appeared in v1.4 when the EVGLs were reorganized in 2012, and that was
prior to the creation of searchable public mailing lists. I did find:

* A ballot explicitly permitting OU [1] was proposed back in 2008, but it
was withdrawn, apparently on a technicality.
* An informative document [2] from 2014 that was never adopted by the Forum
indicates that OU fields are permitted in EV certificates.

I suspect that this is another one of those gray areas that was never
clarified because no one could agree on it. Since we have become more
strict in our interpretation of the guidelines over the past few years, it
is difficult to continue to ignore the literal reading of the second
paragraph - I.e. no subject fields other than those listed in section 9.2
are allowed - regardless of the apparent contradictions.

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.

Regarding the ETSI requirement for inclusion of the organizationIdentifier
in EV certificates, I think that Dimitris' option #4 (specify
organizationIdentifier as an optional field in the EVGLs) is tolerable, but
Ryan's option #3 (put it in an extension) is preferred. I agree with Ryan's
arguments against arbitrary subject fields, and against adoption of the
ETSI-defined structure for this free-form field.

I'm also not moved by the urgency argument. The ETSI requirement is in a TS
document (119 495), so [my understanding is that] it's not so difficult to
update.

The only other argument I've heard for adopting the organizationIdentifier
approach is that existing certificate viewers will be able to display the
field. I don't find this argument terribly compelling either. Digging
through certificates looking for information is the work of experts, and
the ETSI-defined structure of the field requires special knowledge anyhow.

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.

- Wayne

[1] https://cabforum.org/2008/07/25/ballot-16-unverified-content/
[2]
https://cabforum.org/wp-content/uploads/Recommendations-for-the-Processing-of-EV-SSL-Certificates.v.2.0.pdf


On Thu, Nov 15, 2018 at 1:07 PM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

>
>
> On Thu, Nov 15, 2018 at 4:17 AM Adriano Santoni via Validation <
> validation at cabforum.org> wrote:
>
>> Maybe just because I am a European, I see no problem in referring to an
>> ETSI norm in the EVGLs. Besides, ETSI norms are already referred to in the
>> current EVGLs and in several RFCs. Some of them are even published as RFCs.
>>
> Can you provide citations, beyond the audit criteria?
>
>> But if mentioning an ETSI spec in the EVGLs was a problem, that could be
>> avoided by requiring that the content of organizationIdentifie "must
>> conform to a public specification, published by a international SDO and
>> freely available"... or something like that.
>>
> Right, and we're strongly opposed to this - which is the worst of all
> worlds. I think we can find options and reasonable compromise, but I don't
> think that, in the consideration of Internet-wide interoperability, we need
> to avoid that. An SDO that makes the results freely available, but is only
> pay-to-play - which, notably, includes ETSI - is not a productive outcome
> for the community or the users.
> _______________________________________________
> 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/20181115/9718a321/attachment.html>