They aren't well-specified, because they're privately extensible. On Mon, Jul 9, 2018 at 10:13 AM Tim Hollebeek <[email protected]> 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:[email protected]] > *Sent:* Sunday, July 8, 2018 9:18 AM > *To:* Ryan Sleevi <[email protected]>; CA/Browser Forum Public Discussion > List <[email protected]>; Tim Hollebeek <[email protected]> > *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 < > [email protected]> 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 > > [email protected] > > https://cabforum.org/mailman/listinfo/public > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
