[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu Nov 15 02:17:12 MST 2018
I definitely concur with Dimitris that the EVGLs need a revision in §9.2
in order - at least - to solve the ambiguity on optional Subject
attributes. The current wording in §9.2.8 is both recursive and
auto-contradictory, IMO, easily leading to different conclusions about
what is allowed or forbidden. A revision is definitely necessary.
However I would be totally favourable to explicitly allowing
organizationIdentifier, as an optional attribute, whose inclusion in the
Subject seems to me absolutely harmless - provided of course that we
clearly specify suitable rules for its use and encoding within EV certs.
I think I understand Ryan's arguments, but nontheless I would not see
any particular problem if the EVGL were to say that
organizationIdentifier is to be encoded according to some ETSI
specification. In as much as it's an optional attribute, CAs who do not
need to use it and/nor do not like the notion of implementing a European
specification, will just not include it in the certificate. 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. 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.
Adriano
Il 14/11/2018 20:11, Dimitris Zacharopoulos (HARICA) via Validation ha
scritto:
> I just realized that some CA/B Forum members have EV-supported sites
> with Certificates that include the OU field in the subjectDN.
> OrganizationalUnitName is not listed in 9.2. Just listing a few of them:
>
> * https://www.digicert.com
> * https://www.comodo.com
> * https://www.bundesdruckerei.de
> * https://www.certum.eu
>
> I hope the entire validation subcommittee can realize the urgency of
> clarifying this ambiguity in 9.2.8.
>
>
> Thanks,
> Dimitris.
>
>
> On 14/11/2018 7:49 μ.μ., Dimitris Zacharopoulos (HARICA) via
> Validation wrote:
>>
>>
>> On 13/11/2018 6:31 μ.μ., Ryan Sleevi wrote:
>>>
>>>
>>> On Tue, Nov 13, 2018 at 1:39 AM Dimitris Zacharopoulos (HARICA)
>>> <dzacharo at harica.gr <mailto: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 see. So, you are referring to attributes listed in 9.2.7 of the
>> EVGs, and point to the Baseline Requirements.
>>
>>> 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.
>>>
>>
>> All I said in my last email is that HARICA would support a ballot
>> that clarifies 9.2.8, to unambiguously describe one way or another.
>> Apparently, the current wording has mislead CAs into thinking that
>> they can add subjectDN attributes that are not specifically listed in
>> 9.2 so long as the information is verified. I think we need to fix
>> that particular issue soon. That's regardless of the other issues
>> about ETSI and PSD2 that we talked about. They should be considered
>> separately.
>>
>>
>>> 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.
>>
>> This is already the case with serialNumber. It doesn't have a
>> specific or consistent representation, as Daymion presented at the
>> last F2F. Is there any major harm to that? Isn't this just additional
>> validated information that Relying Parties can check manually if they
>> want to verify the Organization?
>>
>> May I suggest two more options?
>> 4) Specifically permit the /organizationIdentifier /field, and add
>> vetting rules no how to verify this information. These would be
>> similar rules as the serialNumber for Legal Entities.
>> Pro: ETSI can now use an "approved" attribute that contains
>> consistently vetted information and can suggest optional semantics
>> via the semanticsIdentifier in the qcStatements extension which is
>> already allowed and acceptable by the Browsers.
>> Con: Some CAs that will not choose the ETSI semantics, will add this
>> registry information with various representations just like it
>> happens today with the serialNumber field.
>> Con: Relying Parties might see the same information in 2 different
>> fields (serialNumber and organizationIdentifier)
>>
>> 5) Specifically permit the /organizationIdentifier /field, add
>> vetting rules no how to verify this information (similar rules as the
>> serialNumber for Legal Entities) and add a requirement to mandatory
>> include either /serialNumber /or /organizationIdentifier/, since they
>> both have the same information value.
>> Pro: ETSI can now use an "approved" attribute that contains
>> consistently vetted information and can suggest optional semantics
>> via the semanticsIdentifier in the qcStatements extension which is
>> already allowed and acceptable by the Browsers.
>> Con: Some CAs that will not choose the ETSI semantics, will add this
>> registry information with various representations just like it
>> happens today with the serialNumber field.
>>
>> Option #5 is a bit bolder but considering the fact that the
>> /serialNumber /and /organizationIdentifier/ contain some unique
>> registry identifiers that are vetted in a similar way, it sounds
>> reasonable to me to request one or the other.
>>
>>
>> Dimitris.
>>
>> _______________________________________________
>> Validation mailing list
>> Validation at cabforum.org
>> https://cabforum.org/mailman/listinfo/validation
>
>
> _______________________________________________
> 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/c17b7b71/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3849 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/validation/attachments/20181115/c17b7b71/attachment-0001.p7s>
More information about the Validation
mailing list