[cabfpub] LEI information in web certificates

[Moudrick M. Dadashov]

IMHO ETSI case needs some clarification - in fact we have two different 
issues here:

 1. qualified and non-qualified certificate profiles (use of
    "qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2 with the
    SemanticsInformation syntax, see
    http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf).
 2. ETSI proposal related to certificates issued to payment service
    operators (see
    https://cabforum.org/pipermail/validation/2018-June/000948.html)

In short, the first one says: if combined with the OID 
id-qcspkixQCSyntax-v2 the syntax of serial-number is:

TTTCC-identifier

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 
(https://ec.europa.eu/taxation_customs/tin/tinByCountry.html).

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.

Thanks,
M.D.


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 
> validation.
>
> 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
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180708/73ff2e4b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital-transformation-through-psd2-and-open-banking-figure1.png
Type: image/png
Size: 18603 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180708/73ff2e4b/attachment-0003.png>