<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Cambria">Which of those two proposals are "privately
      extensible"?</font><font face="Cambria"><br>
      <br>
      The first one (with </font><font face="Cambria">SemanticsInformation),
    </font><font face="Cambria"><font face="Cambria">once implemented,
        should</font> work for any identifiers (LEI etc.) with almost no
      code change. Let's discuss those ETSI proposals separately :)<br>
      <br>
      Thanks,<br>
      M.D.<br>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 7/9/2018 5:18 PM, Ryan Sleevi wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACvaWvaSBzwAdpHBuBGD_f-HaRuAW3NZ9gLNGoSe_EyLic11qw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div dir="ltr">They aren't well-specified, because they're
        privately extensible.</div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Mon, Jul 9, 2018 at 10:13 AM Tim Hollebeek
          <<a href="mailto:tim.hollebeek@digicert.com"
            moz-do-not-send="true">tim.hollebeek@digicert.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="white" link="blue" vlink="purple" lang="EN-US">
            <div class="m_5670336531759571604WordSection1">
              <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.</span></p>
              <p class="MsoNormal"><span style="color:windowtext"> </span></p>
              <p class="MsoNormal"><span style="color:windowtext">-Tim</span></p>
              <p class="MsoNormal"><span style="color:windowtext"> </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:<a href="mailto:md@ssc.lt"
                          target="_blank" moz-do-not-send="true">md@ssc.lt</a>]
                        <br>
                        <b>Sent:</b> Sunday, July 8, 2018 9:18 AM<br>
                        <b>To:</b> Ryan Sleevi <<a
                          href="mailto:sleevi@google.com"
                          target="_blank" moz-do-not-send="true">sleevi@google.com</a>>;
                        CA/Browser Forum Public Discussion List <<a
                          href="mailto:public@cabforum.org"
                          target="_blank" moz-do-not-send="true">public@cabforum.org</a>>;
                        Tim Hollebeek <<a
                          href="mailto:tim.hollebeek@digicert.com"
                          target="_blank" moz-do-not-send="true">tim.hollebeek@digicert.com</a>><br>
                        <b>Subject:</b> Re: [cabfpub] LEI information in
                        web certificates</span></p>
                  </div>
                </div>
                <p class="MsoNormal"> </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></p>
                <ol start="1" type="1">
                  <li class="MsoNormal">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"
                      target="_blank" moz-do-not-send="true">http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf</a>).</li>
                  <li class="MsoNormal">ETSI proposal related to
                    certificates issued to payment service operators
                    (see <a
                      href="https://cabforum.org/pipermail/validation/2018-June/000948.html"
                      target="_blank" moz-do-not-send="true">https://cabforum.org/pipermail/validation/2018-June/000948.html</a>)</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"
                    target="_blank" moz-do-not-send="true">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>
                   </p>
                <div>
                  <p class="MsoNormal">On 7/7/2018 12:36 AM, Ryan Sleevi
                    via Public wrote:</p>
                </div>
                <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                  <div>
                    <p class="MsoNormal" style="margin-bottom:12.0pt"> </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"
                            target="_blank" moz-do-not-send="true">public@cabforum.org</a>>
                          wrote:</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"> </p>
                            <p class="MsoNormal">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.</p>
                            <p class="MsoNormal"> </p>
                            <p class="MsoNormal">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.</p>
                            <p class="MsoNormal"> </p>
                            <p class="MsoNormal">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?</p>
                          </div>
                        </div>
                      </blockquote>
                      <div>
                        <p class="MsoNormal"> </p>
                      </div>
                      <div>
                        <p class="MsoNormal">Could you explain how this
                          information would be used by Relying Parties?</p>
                      </div>
                      <div>
                        <p class="MsoNormal"> </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.</p>
                      </div>
                      <div>
                        <p class="MsoNormal"> </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.</p>
                      </div>
                    </div>
                  </div>
                  <p class="MsoNormal"><br>
                    <br>
                    <br>
                  </p>
                  <pre>_______________________________________________</pre>
                  <pre>Public mailing list</pre>
                  <pre><a href="mailto:Public@cabforum.org" target="_blank" moz-do-not-send="true">Public@cabforum.org</a></pre>
                  <pre><a href="https://cabforum.org/mailman/listinfo/public" target="_blank" moz-do-not-send="true">https://cabforum.org/mailman/listinfo/public</a></pre>
                </blockquote>
                <p class="MsoNormal"> </p>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>