[cabfpub] LEI information in web certificates

[Ryan Sleevi]

They aren't well-specified, because they're privately extensible.

On Mon, Jul 9, 2018 at 10:13 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Right.  My original objection was that the semantics weren’t specified,
> but as you and others (privately) have pointed out to me, they’re actually
> specified quite well.  We just need to point to the relevant ETSI standards
> documents.
>
>
>
> -Tim
>
>
>
> *From:* Moudrick M. Dadashov [mailto:md at ssc.lt]
> *Sent:* Sunday, July 8, 2018 9:18 AM
> *To:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion
> List <public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>
> *Subject:* Re: [cabfpub] LEI information in web certificates
>
>
>
> 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> 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/20180709/5168098c/attachment-0003.html>