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@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@cabforum.org> <mailto:servercert-wg@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@cabforum.org <mailto:Servercert-wg@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@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
