LEI Ballot #139
LEI Ballot #139
Conversation
BR 7.1.5(c) references 7.1.2.4 and 7.1.2.5. These sections talk about the applicability of RFC 5280 and don't make sense in the context of 7.1.5(c). The pre-3647 version of the BRs reference was to the old 9.2.2 Subject Distinguished Name Fields, and that makes more sense. 9.2.2 is now 7.1.4.2.2
Fix references in 7.1.5(c)
Add a contributing.md file for GitHub (cabforum#136)
Ballot sc17 alternative registration numbers for ev certificates (#…
| @@ -180,6 +180,10 @@ Capitalized Terms are defined in the Baseline Requirements except where provided | |||
|
|
|||
| **Extended Validation Certificate:** See EV Certificate. | |||
|
|
|||
| **Global Legal Entity Identifier Foundation:** Established by the Financial Stability Board in June 2014, the Global Legal Entity Identifier Foundation (GLEIF) is tasked to support the implementation and use of the Legal Entity Identifier (LEI). The foundation is backed and overseen by the LEI Regulatory Oversight Committee, representing public authorities from around the globe that have come together to jointly drive forward transparency within the global financial markets. GLEIF is a supra-national not-for-profit organization headquartered in Basel, Switzerland. | |||
There was a problem hiding this comment.
None of this marketing copy is necessary. This provides no definitional value, especially for the purpose of the EVGs.
Suggestion: Delete Entirely.
There was a problem hiding this comment.
At least a significant portion of it is factual information. I'm not sure that deleting all of it actually helps anything.
There was a problem hiding this comment.
It may be factual, but it's entirely irrelevant in order to implement or comply with the EVGs.
| @@ -180,6 +180,10 @@ Capitalized Terms are defined in the Baseline Requirements except where provided | |||
|
|
|||
| **Extended Validation Certificate:** See EV Certificate. | |||
|
|
|||
| **Global Legal Entity Identifier Foundation:** Established by the Financial Stability Board in June 2014, the Global Legal Entity Identifier Foundation (GLEIF) is tasked to support the implementation and use of the Legal Entity Identifier (LEI). The foundation is backed and overseen by the LEI Regulatory Oversight Committee, representing public authorities from around the globe that have come together to jointly drive forward transparency within the global financial markets. GLEIF is a supra-national not-for-profit organization headquartered in Basel, Switzerland. | |||
|
|
|||
| **Global Legal Entity Identifier Index:** The Global Legal Entity Identifier (LEI) Index contains historical and current LEI records including related reference data in one authoritative, central repository. The reference data provides the information on a legal entity identifiable with an LEI. | |||
There was a problem hiding this comment.
This is also marketing copy, and can/should be deleted. It does not disambiguate in any meaningful sense, which is normally what these definitions should be used for.
| @@ -200,6 +204,8 @@ Capitalized Terms are defined in the Baseline Requirements except where provided | |||
|
|
|||
| **Legal Entity**: A Private Organization, Government Entity, Business Entity, or Non-Commercial Entity. | |||
|
|
|||
| **Legal Entity Identifier**: The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code based on the ISO 17442 standard developed by the International Organization for Standardization (ISO). It connects to key reference information that enables clear and unique identification of legal entities participating in financial transactions. Each LEI contains information about an entity’s ownership structure and thus answers the questions of 'who is who’ and ‘who owns whom’. | |||
There was a problem hiding this comment.
Similarly, marketing copy is included here.
This part is wholly unnecessary, because the only salient piece of definitional requirement, namely that it complies with ISO17442, is duplicated in the actual normative requirement.
Suggestions:
- Delete this text entirely
- Meaningfully define it. What are the salient bits? Possible answers include:
- Complies with the format set forth in ISO 17442
- Assigned by an entity approved entity
- For example, if the intent is that it complies with the LEI Regulatory Oversight Committee's requirements and uses an LOU recognized by the LEI ROC, then let's try to find out how to say that.
- Alternatively, it might mean assigned by an LOU accredited by GLEIF
| @@ -1864,3 +1872,20 @@ guidelines: | |||
| jurisdiction as specified in Section 9.2.4. The stated address of the organisation | |||
| combined with the organization name SHALL NOT be the only information used to | |||
| disambiguate the organisation. | |||
|
|
|||
| **LEI**: The Legal Entity Identifier (LEI) as specified in the ISO 17442 and registered | |||
| in the Global LEI Index. | |||
There was a problem hiding this comment.
So it's ambiguous here as to what "registered in the Global LEI Index" means. It implies that an accredited-by-GLEIF LOU can withhold data from the Global LEI System, and thus some additional requirement is required.
If the changes to LEI are made within the definitions (e.g. does it have to be an LEI defined by an LOU accredited by GLEIF/the LEI ROC), then I think this entire first sentence may be unnecessary.
Alternatively, if we want to avoid normative requirements within the definition, such that LEI is merely the number that conforms to ISO 17442, then this is where we'd introduce the requirement that the LEI be issued by an LOU recognized by the Global Legal Entity Identifier Foundation.
No definition for "who" the foundation is is necessary.
There was a problem hiding this comment.
We certainly do want to avoid normative requirements within definitions. That's always a bad idea. Also, while I don't think it's actually possible for an LOU to issue an LEI that isn't in the Global LEI Index (holding all the LEIs is pretty much the point of the index), in the event that it is possible, I don't think we'd want to recognize them, as they were likely issued in error.
There was a problem hiding this comment.
Different specs take different approaches with respect to definitions. To date, the BRs and the EVGs have fundamentally placed normative requirements within definitions, because many of the normative requirements themselves depend on the definitions. So I don't agree that it's always a bad idea.
Basically, I think we can get away from this potential confusion by indicating that an LEI, in terms of definition, is an Legal Entity Identifier that was issued by an LOU accredited by GLIEF (assuming I got the terms right), and then this all flows out of that (registered in the index, complies with ISO 17442, etc)
| 1. This information SHALL be validated by matching the organization name and | ||
| registration number found in the Global LEI Index against the Subject Organization | ||
| Name Field (see 9.2.1) and Subject Registration Number Field (see 9.2.5) within the | ||
| context of the subject’s jurisdiction as specified in Section 9.2.4. |
There was a problem hiding this comment.
It's completely undefined here what "matching" means, and this is where I wanted to flesh out more comprehensive normative requirements.
Before including an LEI within a certificate, the CA SHALL
- Confirm that the ValidationSources field of the associated LEI record, as reported by GLEIF, contains FULLY_CORROBORATED
- That the RegistrationAuthority of the associated LEI Record is the same entity as the Incorporating Agency or Registration Agency used in validating the information within the Subject Jurisdiction of Incorporation or Registration Field (see Section 9.2.4) and the Subject Registration Number Field (see Section 9.2.5)
- That the Subject Organization Name Field (see Section 9.2.1) is contained, exactly as entered, within either the LegalName, OtherEntityNames, or TransliteratedOtherEntityNames of the associated LEI Record
- That the Subject Registration Number (see Section 9.2.5) is equal, exactly as entered, to the RegistrationAuthorityEntityID of the associated LEI Record
That said, I'm concerned about whether or not we need to worry about the Registration Details - in particular, the registration status - e.g. should a lapsed or canceled LEI Registration be used? What about challenges to the data source? Should we worry about the LegalJursidiction code and matching it?
There was a problem hiding this comment.
The bullet points look fine to me.
I'd be fine with disallowing lapsed or canceled registrations.
There was a problem hiding this comment.
I think it'd be great if you could get the GLIEF folks to provide a bit of context (here, or to the questions@ list) about the state flow. Maybe I missed it on gleif.org
Basically, I want to make sure we've got an allowlist in place for what makes a "good" LEI, and the inter-relationship between the states means I'm not too confident I fully understand it. But it sounds like that sounds good to you, and so perhaps we should sync up with them to nail this down?
| 2. The address information SHALL be compared in order to detect potential | ||
| matching errors or errors in the registration information. If errors are found, | ||
| they SHALL be reported to the GLEIF Foundation and/or relevant registration | ||
| authority. |
There was a problem hiding this comment.
I'm actually not a fan of this. I think, if anything, any matching errors should PREVENT the CA from issuing such a certificate.
There was a problem hiding this comment.
I'd be fine with removing this. It was actually suggested by another CA.
|
LEI is now in an ISO standard. See: |
|
@dzacharo Could you clarify what you mean about “now”? ISO 17442 bas existed before the discussions even began, and that of course has factored into the discussions. However, it also has zero bearing whatsoever on the discussions here, inasmuch as ISO 17442 is with respect to the numbering format and syntax. Even the recognition of GLEIF with respect to the LEI ROC predates our discussions, and similarly has no bearing. The existence of a naming authority is orthogonal to the core questions at play, which apply to validation, purpose, and the demonstrable negative security impact to relying parties by inclusion within certificates used for an inherently separate trust framework. I wasn’t sure if there was something you believed had changed, or whether this was just catching up with understanding the details we’ve been discussing from the beginning. |
|
As I was going over the open pull requests, I just thought it was relevant, that's all :-) |
No description provided.