Closed srdavidson closed 7 months ago
In addition, the text in Appendix A:
The country code used in the Registration Scheme identifier SHALL match that of the subject:countryName in the Certificate as specified in Section 7.1.4.2.2.
should be amended to
With the exception of the LEI and INT Registration Schemes, the country code used in the Registration Scheme identifier SHALL match that of the subject:countryName in the Certificate as specified in Section 7.1.4.2.2.
Fine for me
De: Stephen Davidson @.> Enviado el: miércoles, 4 de octubre de 2023 11:54 Para: cabforum/smime @.> CC: Inigo Barreira @.>; Mention @.> Asunto: Re: [cabforum/smime] Clarity on LEI in organizationIdentifier (Issue
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
See proposed text at @.***
Reply to this email directly, view it on GitHub https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fcabforum%2Fsmime%2Fissues%2F216%23issuecomment-1747140257&data=05%7C01%7 Cinigo.barreira%40sectigo.com%7Cdae87974bc4b4df0976208dbc4f21291%7C0e9c48946 caa465d96604b6968b49fb7%7C0%7C0%7C638320316191022146%7CUnknown%7CTWFpbGZsb3d 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 C%7C%7C&sdata=TEe3%2Fvu5j3wVmdBGph1DViLETb3t4R3IgosyA4RaU9g%3D&reserved=0 , or unsubscribe. You are receiving this because you were mentioned. https://github.com/notifications/beacon/AWFQXOJAPPTX3CTUMIPM3BDX5WBADA5CNFS M6AAAAAA5RQOZSCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT IEM7KC.gif Message ID: @. @.> >
It may not need to be said because it doesn't impact the change that's needed here but I thought I'd add this for visibility and general community awareness. The SMIME BRs in their current form do not allow issuance of certificates with an "INTXG" or "LEIXG" subject:organizationIdentifier.
As @srdavidson rightly quotes, 7.1.4.2.2(d) says that there are cases where the country code in the subject:organizationIdentifier may be "XG". And Appendix A.1 says the country code in the registration scheme identifier must match the value in the subject:countryName.
But to go one step further, 7.1.4.2.2(n) which describes what can be set as the subject:countryName. That section does not allow the subject:countryName to be set to "XG", but it must be because it has to match the value in the organizationIdentifier which can be "XG". This contradiction is a problem.
tl;dr: it is, currently, impossible to validly issue SMIME certificates with an "INTXG" or "LEIXG" subject:organizationIdentifier.
I agree that the current language is tortured, but I don't believe the language prohibits the use of INT and LEI Registration Schemes.
Appendix A says:
The country code used in the Registration Scheme identifier SHALL match that of the subject:countryName in the Certificate as specified in Section 7.1.4.2.2
For the NTR, VAT, and PSD Registration Schemes, it is clear that the country code is part of the identifier (NTR Scheme identifiers need a country code to specify the country where the company is registered, etc). However, for INT and LEI, the "XG" country code is not part of the identifier itself. For example, LEIs are not prepended with "XG"; specifying "XG" in the organizationIdentifier
is merely an encoding convention to ensure consistency across Registration Schemes. Given that the "XG" element is not part of the INT and LEI identifier itself, there is no requirement for this "XG" element to be identical to the countryName
subject attribute value. The same holds for INT.
Hi @CBonnell, I see your point that the "XG" is merely an encoding convention and not a country code as part of the Registration Scheme. However, I'm still not convinced that LEI and INT schemes are allowed.
If I've understood you correctly, your argument is that for other schemes, the country code is a part of interpreting the identifier and for LEI and INT it's not. The argument being that because the "XG" code doesn't have any real meaning for the LEI/INT identifier and is pretty much two placeholder characters, it doesn't matter for the A.1 countryName rule. I am not convinced this argument holds water. The identification of the registration scheme includes that ISO3166-1 country code. It is how the scheme is identified in the subject:organizationIdentifier field even if it is just an encoding convention. "XG" is an ISO 3166-1 country code. The rule in A.1 says the country code in the bit of the organizationIdentifier identifying the registration scheme SHALL match the value in the subject:countryName. I don't think you can argue that because it isn't relevant for interpreting the registration of the organisation that the A.1 requirement doesn't apply. The proposed update to the A.1 rule would allow the the "XG"==subject:countryName comparison to be skipped, but the current text does not.
The rule in A.1 says the country code in the bit of the organizationIdentifier identifying the registration scheme SHALL match the value in the subject:countryName.
The language in A.1 does not say this. It merely speaks to an "identifier"; nowhere does it explicitly speak to the country code contained within the organizationIdentifier
attribute. Here's the exact verbiage of A.1 again for reference:
The country code used in the Registration Scheme identifier SHALL match that of the subject:countryName in the Certificate as specified in Section 7.1.4.2.2
I believe the intent is clear that the "identifier" as referenced in A.1 is speaking to the country code which is a constituent part of a Registration Scheme's identifier and not to elements added to maintain consistency in formatting, but I can see how this language can be read differently.
Another thing that we'll want to address as part of these language improvements is to import the definitions for Registration Scheme
and Registration Reference
from the EVGs into the SMBRs, as they're currently missing.
Hi @CBonnell and @srdavidson, thanks for your responses and further comments. I think from your comment @CBonnell that I can see how the text may be interpreted to allow for the "INTXG" and "LEIXG" issuances but I'll say that I think it's still a very particular interpretation that is not obvious. On this point, I thought I'd try to explain where my confusion came from in case it helps in future changes.
If I'm understanding you correctly, you're saying that the "Registration Scheme identifier" text in A.1 could be replaced to say "identifier of the Registration Scheme" at which point your interpretation is easier to see as the identifier of the Registration Schemes in "INTXG", "LEIXG", or "VATGB" are more obviously "INT", "LEI", and "VATGB".
I think the 7.1.4.2.2(d) section is pretty hard to parse as there's a lot to it. My confusion here primarily came from the fact that "Registration Scheme identifier" is used a fair few times in A.1 and 7.1.4.2.2(d) and so it looks like a defined term but it maybe isn't? In 7.1.4.2.2(d) it means just the first 3 characters of the organizationIdentifier. But in A.1, it means the first three characters if they are LEI or INT otherwise it means the first five. I came at this topic looking at the A.1 text and assuming it meant to say "Registration Scheme" rather than "Registration Scheme identifier", thinking the former included the country code and the latter didn't (or something like that anyway).
As a last point, I wonder if there is value in defining terms like (names TBC) Registration Scheme Identifier (the three letter code), Country-Sensitive Registration Scheme Identifier (a Registration Scheme plus an ISO country code), and any others that would help in/around organizationIdentifiers? That way the A.1 text could clearly identify the Country-Sensitive version rather than ending up overloading a term which means something else earlier in the document?
Hi @robplee,
If I'm understanding you correctly, you're saying that the "Registration Scheme identifier" text in A.1 could be replaced to say "identifier of the Registration Scheme" at which point your interpretation is easier to see as the identifier of the Registration Schemes in "INTXG", "LEIXG", or "VATGB" are more obviously "INT", "LEI", and "VATGB".
Yes, I read A.1 as saying something similar to this. From the descriptions of the NTR, VAT, and PSD schemes, the country code is a necessary part of the "identifier" that uniquely identifies the Subject, whereas for INT and LEI, the "XG" is wholly unnecessary in accomplishing this and is only present as a formatting element. So, for me, the requirement in A.1 reads that the countryName matching only needs to be done when using a scheme where the country code is part of the unique identifier. Additionally, the countryName
requirements prohibit the inclusion of XG
, which lends further credence to this interpretation.
As you mentioned, 7.1.4.2.2 (d) defines "Registration Scheme identifier" as the 3-letter code that identifies the Registration Scheme; it's impossible for it to also contain a country code. So "Registration Scheme identifier" in A.1 would need to mean something else.
As a last point, I wonder if there is value in defining terms like (names TBC) Registration Scheme Identifier (the three letter code), Country-Sensitive Registration Scheme Identifier (a Registration Scheme plus an ISO country code), and any others that would help in/around organizationIdentifiers? That way the A.1 text could clearly identify the Country-Sensitive version rather than ending up overloading a term which means something else earlier in the document?
I think this is a good idea. We might be able to add some specificity to the Registration Scheme to state it has a 3-letter identifier, or we can create a new Defined Term as you suggest. Additional Defined Terms would likely add clarity.
I checked ETSI EN 319 412-1, clause 5.1.4 for potential inspiration on defined terms, but unfortunately there are none defined there. So it appears we'll need novel terms for the SMBRs.
Section 7.1.4.2.2 (d) says:
But in Appendix A.1 it says:
The intent was that LEI is a global scheme and should use the 'XG' country code. Should consider clarifying the language in 7.1.4.2.2 (d).
Thanks to @barrini for pointing this out.