<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Cambria">IMHO ETSI case needs some clarification - in
fact we have two different issues here:</font><br>
<ol>
<li>qualified and non-qualified certificate profiles (use of
"qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2 with
the SemanticsInformation syntax, see
<a class="moz-txt-link-freetext" 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>).</li>
<li>ETSI proposal related to certificates issued to payment
service operators (see
<a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/validation/2018-June/000948.html">https://cabforum.org/pipermail/validation/2018-June/000948.html</a>)</li>
</ol>
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 class="moz-txt-link-freetext" 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>
<br>
<br>
<div class="moz-cite-prefix">On 7/7/2018 12:36 AM, Ryan Sleevi via
Public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZ2zSUamYJbOtf7VN_tGi3SnEyTMQ-_aY78rns+RkBmYg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jul 6, 2018 at 4:29 PM Tim Hollebeek
via Public <<a href="mailto:public@cabforum.org"
moz-do-not-send="true">public@cabforum.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div class="m_3228958920226658631WordSection1">
<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><br>
</div>
<div>Could you explain how this information would be used by
Relying Parties?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>