[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard
adriano.santoni at staff.aruba.it
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
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:
> 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" ?
> 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 22.214.171.124.2 wasn't aligned with the
>> 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>
> Validation mailing list
> Validation at cabforum.org <mailto:Validation at cabforum.org>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4025 bytes
Desc: Firma crittografica S/MIME
More information about the Validation