[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

[Ryan Sleevi]

On Tue, Jun 12, 2018 at 3:00 AM, Adriano Santoni <
adriano.santoni at staff.aruba.it> wrote:

> I appreciate your interpretation, but then it seems to me that the current
> EVGL wording in §9.2 (Other Subject Attributes) is not crystal-clear.
>
> What are those "all other optional attributes", and when can they be
> present (as §9.2.8 seems to allow them to be present: "when present...") ?
>
> If no other attributes can ever be present, then the first sentence of
> §9.2.8 is misleading.
>
Agreed. It should be clarified, as it collectively refers to the set of
optional v mandatory elements.


Besides, the sentence "[CAs]... SHALL NOT include any Subject Organization
> Information except as specified in Section 9.2." leads to an infinite loop
> :) when one starts reading from the beginning of §9.2 and arrives at the
> first sentence of §9.2.8 ("All other optional attributes, when present
> within the subject field, ...")
>
>
>
> Il 11/06/2018 16:43, Ryan Sleevi ha scritto:
>
> https://cabforum.org/pipermail/public/2018-May/013531.html covers this.
>
> All other optional attributes, when present within the subject field, MUST
> contain information that has been verified by the
> CA. CAs SHALL NOT include Fully-Qualified Domain Names in Subject
> attributes except as specified in Sections 9.2.1
> and SHALL NOT include any Subject Organization Information except as
> specified in Section 9.2.
>
> organizationIdentifier is Subject Organization Information.
> Section 9.2 does not specify that organizationIdentifier is permitted.
> Ergo, organizationIdentifier is not permitted.
>
> This is the correct read of the section, as it aligns with the intent,
> especially of browsers, to ensure that information presented to users has a
> consistent validation standard applied to it.
>
> On Mon, Jun 11, 2018 at 9:56 AM, Adriano Santoni via Validation <
> validation at cabforum.org> wrote:
>
>> All,
>>
>> do not the current EVGLs already allow the inclusion of extra attributes
>> (such as, for instance, the organizationIdentifier) in the Subject,
>> provided that they contain "information that has been verified by the
>> CA" ?
>>
>> Adriano
>>
>>
>>
>> Il 11/06/2018 15:37, Ryan Sleevi via Validation ha scritto:
>>
>>
>>
>> On Mon, Jun 11, 2018 at 9:25 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr
>> > wrote:
>>
>>>
>>>
>>> On 11/6/2018 4:00 μμ, Ryan Sleevi wrote:
>>>
>>> That seems like a strictly worse proposal, because it does not define
>>> any validation requirements. Also, the interpretation of BRs 7.1.4.2.2
>>> wasn't aligned with the discussion.
>>>
>>>
>>> My proposal tried to address specific concerns about the "exclusive" use
>>> of the organizationIdentifier by ETSI. If you are concerned about the
>>> validation requirements, we should address those but I wouldn't expect them
>>> to be materially different than the validation of the "Registration Number".
>>>
>>
>> I'm afraid it may not have been explained well, then, because the core of
>> the issue was that
>> 1) It restricts this field to exclusive use of ETSI without defining the
>> context for where it's identified as such
>> 2) For the ETSI case, it doesn't prevent other organizations for issuing
>> in this in a way that can be seen as confusing/misleading
>>
>> So as I said, this is explicitly worse, because it removes validation
>> requirements and does not address the CA needs to disambiguate between ETSI
>> and non-ETSI certs. The entire value proposition of using this field is to
>> that it's validated information - but as mentioned, we can avoid this whole
>> problem by not sticking it in the subject.
>>
>>
>>> As discussed during the F2F, it seems that there's a far more viable
>>> option that's aligned with publicly trusted certificates, namely, that of
>>> aligning in the QcStatements. We spent quite some time trying to understand
>>> the rationale and necessity of encoding in the subject, as it seemed like
>>> it was based on both a misunderstanding of the value proposition and of the
>>> technical necessity.
>>>
>>> I would again reiterate those concerns, to ask why this information
>>> cannot be encoded within the qcStatements.
>>>
>>>
>>> As you said, both would be "viable" options so there is no
>>> misunderstanding about the technical necessity. They should both work. I
>>> believe that since this identifier is very specific information
>>> directly-coupled with the Subject of the Certificate, it should be in the
>>> designated extension which is the Subject DN. For me, it doesn't make sense
>>> to include information related uniquely to the Subject, in the
>>> qcStatements. All the existing ETSI TS or EN documents related to the
>>> qcStatements extensions do not contain identifiable information related to
>>> the Subject. Mr. Pope can correct me if I'm wrong here.
>>>
>>
>> Are those concerns shared with subjectAltName? There's no technical need
>> to stuff that information in the subject, and ample and compelling reason
>> not to.
>>
>>
>> _______________________________________________
>> Validation mailing listValidation at cabforum.orghttps://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/20180612/c022fc80/attachment-0001.html>