<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1785030131;
mso-list-template-ids:-1432476970;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:windowtext'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>-Tim<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='color:windowtext'>From:</span></b><span style='color:windowtext'> Moudrick M. Dadashov [mailto:md@ssc.lt] <br><b>Sent:</b> Sunday, July 8, 2018 9:18 AM<br><b>To:</b> Ryan Sleevi <sleevi@google.com>; CA/Browser Forum Public Discussion List <public@cabforum.org>; Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Subject:</b> Re: [cabfpub] LEI information in web certificates<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-family:"Cambria",serif'>IMHO ETSI case needs some clarification - in fact we have two different issues here:</span><o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>qualified and non-qualified certificate profiles (use of "qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2 with the SemanticsInformation syntax, see <a href="http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf">http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf</a>).<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>ETSI proposal related to certificates issued to payment service operators (see <a href="https://cabforum.org/pipermail/validation/2018-June/000948.html">https://cabforum.org/pipermail/validation/2018-June/000948.html</a>)<o:p></o:p></li></ol><p class=MsoNormal style='margin-bottom:12.0pt'>In short, the first one says: if combined with the OID id-qcspkixQCSyntax-v2 the syntax of serial-number is:<br><br>TTTCC-identifier<br><br>where TTT is a type of registry (from the list below);<br>CC - an ISO 3166 country code;<br>identifier means whatever we use today as a serial-number.<br><br>The predefined types of registries (TTT) are: <br> <br>VAT - national VAT registry;<br>NTR - national trade registry;<br>PAS - national passport registry;<br>IDC - national ID card registry;<br>PNO - national civic registry;<br>TIN - Tax Identification registry (<a href="https://ec.europa.eu/taxation_customs/tin/tinByCountry.html">https://ec.europa.eu/taxation_customs/tin/tinByCountry.html</a>).<br><br>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<br>Also, TTT allows you to identify the subjects from country specific registries (explicitly identified in certificate, see details in RFC 3739).<br><br>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 <b>client</b> authentication certificates.<br><br>Thanks,<br>M.D.<br> <o:p></o:p></p><div><p class=MsoNormal>On 7/7/2018 12:36 AM, Ryan Sleevi via Public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Jul 6, 2018 at 4:29 PM Tim Hollebeek via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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?<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Could you explain how this information would be used by Relying Parties?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Public mailing list<o:p></o:p></pre><pre><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>