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

Tue Jun 12 00:00:36 MST 2018

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.

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 <mailto: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 <mailto: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 list
>>     Validation at cabforum.org <mailto:Validation at cabforum.org>
>>     https://cabforum.org/mailman/listinfo/validation
>>     <https://cabforum.org/mailman/listinfo/validation>
>
>
>     _______________________________________________
>     Validation mailing list
>     Validation at cabforum.org <mailto:Validation at cabforum.org>
>     https://cabforum.org/mailman/listinfo/validation
>     <https://cabforum.org/mailman/listinfo/validation>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/a91a4e7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/validation/attachments/20180612/a91a4e7e/attachment.p7s>