[Servercert-wg] [External Sender] Re: [EXTERNAL]- Subject attribute encoding order requirement (rationale for)

[Clint Wilson]

Hi Adriano,

I haven’t looked through minutes and such yet, but as I recall this ordering was discussed a number of times on Validation Subcommittee calls during the creation of SC-062 (i.e. sometime in 2020-2023). The resultant ordering originated from the combination of 3 primary sources:
1. X.509/X.520
2. RFC 5280
3. WG Consensus

I think there’s additional discussion in the link that Jaime provided that’s relevant as well:

chrisbn May 13, 2022
How would fields need to be handled that are not in the current list? E.g. subject:businessCategory or subject:jurisdictionLocalityName from EVG? I'm also interested to know if there's a source for this requirement, or what's the driver for the ordering?

sleevi May 13, 2022
You mean, where would these be sorted?
These are requirements derived from the semantics of RFC 5280 and X.509. A DN is hierarchical in semantic naming, and an RDN with multiple elements is saying that these names are semantically equivalent hierarchically.
For the name forms listed, they are not semantically equivalent (e.g. a countryName is not the same hierarchy as a localityName / interchangeable with), and there is a semantic hierarchy.
These are already existing logical requirements, just being made explicit.

chrisbn May 13, 2022
Yes, I wonder about the order of fields not in this list.
I understand the hierarchy to order logic, but is the order defined in Section 7.1.4.2 based on an existing specification, or how did we come to this ordering?

sleevi May 13, 2022
It is based on the definitions within X.509 and X.520, given these fields are generally geographical in nature.
That said, there’s definitely flexibility here to get us closer to consistency among CAs, which is a key point of profiling, so if there are changes and concerns, it’s totally appropriate to highlight.
Prior relevant art includes RFC 2377 [https://datatracker.ietf.org/doc/html/rfc2377], RFC 1218 [https://www.rfc-editor.org/rfc/rfc1218.html], and RFC 1255 [https://www.rfc-editor.org/rfc/rfc1255]

Cheers,
-Clint



> On Mar 21, 2024, at 2:06 AM, Adriano Santoni via Servercert-wg <servercert-wg at cabforum.org> wrote:
> 
> Thank you Jaime , but I had already checked that.
> 
> At that link I can only find the following very short exchange between chrisbn and sleevi:
> 
> 
>> @chrisbn chrisbn May 13, 2022
>> Yes, I wonder about the order of fields not in this list.
>> I understand the hierarchy to order logic, but is the order defined in Section 7.1.4.2 based on an existing specification, or how did we come to this ordering?
>> @sleevi sleevi May 13, 2022
>> It is based on the definitions within X.509 and X.520, given these fields are generally geographical in nature.
>> That said, there’s definitely flexibility here to get us closer to consistency among CAs, which is a key point of profiling, so if there are changes and concerns, it’s totally appropriate to highlight.
> 
> That does not seem to clarify much, so I suppose there is more somewhere else.
> 
> No discussion of the mailing list? No discussion in SCWG calls?
> 
> Adriano
> 
> 
> 
> 
> 
> Il 21/03/2024 09:52, Jaime Hablutzel ha scritto:
>> The discussion in https://github.com/sleevi/cabforum-docs/pull/36#discussion_r872103477 could help.
>> 
>>> On 21 Mar 2024, at 09:39, Adriano Santoni via Servercert-wg <servercert-wg at cabforum.org> <mailto:servercert-wg at cabforum.org> wrote:
>>> 
>>> All, can anyone help me find the past email discussion, or at least the rationale that someone wrote somewhere (e.g. on Github?), supporting the Subject attributes encoding relative order requirement that was introduced in BR 2.0.0 (Ballot SC-062) ? 
>>> 
>>> I am talking about §7.1.4.2 Subject Attribute Encoding, and specifically about this language:
>>> 
>>> "CAs that include attributes in the Certificate subject field that are listed in the table below
>>> SHALL encode those attributes in the relative order as they appear in the table and follow the
>>> specified encoding requirements for the attribute."
>>> 
>>> I do not recall, and cannot find, a discussion on this mailing list on this particular topic. Maybe I just missed a whole bunch of email messages due to some otherwise undetected email problem. I also did a search on Github, starting from the links provided at https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/), but was unable to figure out who proposed it and, above all, for what reason.
>>> 
>>> Adriano
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=TmnUymVu4aN7JJUi7E4FNf5W7JAuYX7-j6JtyhXK9EAAxJqhk7RvTa9sOsMmibge&s=pzZ-HMcq_CggzRO87gqT5_XxYy9n5hIbsxrERd7c_so&e=
>> 
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240321/843d36a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240321/843d36a5/attachment.p7s>