[cabf_validation] EVG 9.8.2. cabfOrganizationIdentifier

[Tim Hollebeek]

No, the reason it exists is exactly as I described.  One individual refused to support SC-17 unless it was included, and SC-17 was very important to allow publicly-trusted PSD2 certificates to be issued.  So everybody just sort of cringed and included it, despite the fact that it wasn’t necessary and no one else wanted it.  I actually got a lot of private criticism for accepting the compromise, despite the fact that I still believe it was the right thing to do at the time.

 

It’s not entirely clear why ETSI should have to explain why they failed to discuss or adopt a certificate extension they never asked for or wanted.  If someone wanted that discussion, they could have made a proposal there, but no one did.

 

Since no software exists that consumes this extension, and the information is entirely redundant with another field, and as I mentioned, most X.509 tools and APIs can’t deal with extensions that aren’t encoded in a string-based format … why exactly is it a required field in EV certificates?

 

-Tim

 

From: Clint Wilson <clintw at apple.com> 
Sent: Wednesday, October 11, 2023 4:48 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] EVG 9.8.2. cabfOrganizationIdentifier

 

Hi Tim,

 

I had thought the point of including cabfOrganizationIdentifier was to enable deprecation of subject:organizationIdentifier, rather than the inverse. It seems it would be minimally appropriate to understand the discussions and/or actions ETSI has taken post SC17 to address the topic of adoption of the CABFOrganizationIdentifier (for example, an explanation of why its adoption was rejected or additional background on why it’s unsuited for ETSI’s use-case(s)) prior to considering moving forward with such a ballot. 

FWIW, I attempted to find something along those lines, but was unable to (most likely due to insufficient Google-fu, but perhaps such discussions are not public or perhaps they have not occurred).

 

Thanks!

-Clint





On Oct 11, 2023, at 12:57 PM, Tim Hollebeek via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

 

 

Ballot SC17 added the cabfOrganizationIdentifer, which duplicates the information encoded in the subject:organizationIdentifier field, just in a different format/encoding.  The subject:orgID field is standardized by ETSI and used in the processing of eIDAS certificates; on the other hand, to the best of my knowledge, no software has ever been written that processes or uses the cabfOrganzationIdentifier field.

 

Is there a good reason to keep requiring the field?  It was added as a political compromise to get ballot SC17 passed, but that’s not a good reason to keep around a clunky alternative encoding for information already present in the certificate, in an obscure bespoke ASN.1 format that no tools support or use.

 

I’m tempted to write a quick ballot to make it optional, so CAs can start leaving it out.

 

-Tim

_______________________________________________
Validation mailing list
 <mailto:Validation at cabforum.org> Validation at cabforum.org
 <https://lists.cabforum.org/mailman/listinfo/validation> https://lists.cabforum.org/mailman/listinfo/validation

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231011/fee81925/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231011/fee81925/attachment.p7s>