[cabfpub] LEI information in web certificates
Moudrick M. Dadashov
md at ssc.lt
Sun Jul 8 06:18:22 MST 2018
IMHO ETSI case needs some clarification - in fact we have two different
1. qualified and non-qualified certificate profiles (use of
"qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2 with the
SemanticsInformation syntax, see
2. ETSI proposal related to certificates issued to payment service
In short, the first one says: if combined with the OID
id-qcspkixQCSyntax-v2 the syntax of serial-number is:
where TTT is a type of registry (from the list below);
CC - an ISO 3166 country code;
identifier means whatever we use today as a serial-number.
The predefined types of registries (TTT) are:
VAT - national VAT registry;
NTR - national trade registry;
PAS - national passport registry;
IDC - national ID card registry;
PNO - national civic registry;
TIN - Tax Identification registry
but we can add more TTTs e.g. SSN, IRS etc., so the composite
serial-number in a certificate would look like this: IRSUS-123456789
Also, TTT allows you to identify the subjects from country specific
registries (explicitly identified in certificate, see details in RFC 3739).
As for the second ETSI proposal, I suspect a little misunderstanding -
in the scenario where third party payment (TPP) service providers play
their role (see attached) they need *client* authentication certificates.
On 7/7/2018 12:36 AM, Ryan Sleevi via Public wrote:
> On Fri, Jul 6, 2018 at 4:29 PM Tim Hollebeek via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> As many of you are aware, the GLEIF foundation recently invited
> CA/Browser Forum members to its identity management workshop.
> Some people have contacted us about the possibility of putting LEI
> identifiers into web certificates. This is in some ways similar
> to the recent proposal from ETSI to put additional identity
> information into certificates, though it has the advantage that we
> are free to determine ourselves how best to encode it.
> CAs are already allowed to include this information in
> certificates, assuming it has been appropriately validated. There
> is a Global Legal Entity Identifier Index that is authoritative
> for LEIs. However it would be valuable if there were a
> standardized CABF OID and extension so that every CA that chooses
> to include this information includes it in an interoperable way.
> This also allocates the OID in a namespace we control, allowing us
> to state in the BRs the purpose and semantics of the extension,
> and require that it only be used for authentic and validated LEIs.
> It seems to me that it would be worthwhile to standardize this,
> instead of every CA coming up with their own way of doing it.
> What do other people think?
> Could you explain how this information would be used by Relying Parties?
> The GLEIF model effectively relies on third-party RAs, with all of the
> attendant issues, and without a clear framework for addressing many of
> the issues that has been held in the CA ecosystem. I'm not sure the
> value proposition here, or that the information is something RPs
> should necessarily use. As to whether or not it's appropriate, I think
> that's going to be very much contingent upon what the intended
> semantics being introduced are - that is, what relationship, if any,
> is being expressed between the LEI ID and the domain - and that opens
> a host of complexity that could easily detract from the far more
> pressing and meaningful work on improving the domain and information
> I'm not sure why a CABF OID would be more useful than a GLEIF OID
> (which seems far more appropriate), and with a defined syntax relevant
> for GLEIF. I can think of no good reason to use the CABF arc, so I'm
> hoping you could explain more that thinking.
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 18603 bytes
Desc: not available
More information about the Public