<div dir="ltr">I have been involved in both the STIR
work and CABF, so let me provide some additional context, first with
regard to STIR and then with regard to how it relates to CABF.<br><br>First,
some more references: This work is being done in the IETF STIR working
group [1]. The document Tony refers to is the STIR certificate profile
[2].<br><br><div>The use case that STIR is addressing [3] is
pretty different from the Web PKI use case. Namely, to combat call
fraud, they want to be able to authenticate telephone numbers, vs.
domain names or organization names. The STIR certificates draft is
focused on the latter case, and especially the case where PKI's
hierarchy aligning with the TN allocation hierarchy. So this is a PKI
that would work more like the RPKI [4] than the Web PKI.<br></div><div><br></div><div>What
I believe Tony is referring to is the possibility that has been raised
by some in the WG that Web PKI certificates could be used to indirectly
authenticate a TN by authenticating the holder of the TN. Note,
however, that this requires some additional trusted service to map DV/EV
identities to TN holdings. The STIR validation model [5] doesn't
require the use of one or the other style of authentication, but the WG
wanted to define a more direct model so as to have a complete story
(without some unspecified name-to-TN mapping service [6]).<br></div><div><br></div><div>To
Tony's question, "Why not EV?", the answer is simple: EV doesn't make
the attestation that STIR needs. It might be useful in combination with
some other technology, but it is not a solution itself.<br></div><div><br></div>Now
as to how this relates to CABF, a lot of it depends on the model in
which STIR is deployed. In the "authoritative" model, where the holders
of blocks of TNs are the CAs, there is probably not a need for anything
like the BRs. The RPKI, which follows this model for IP addresses, has
gotten along fine without such rules. In the "EV" model, where TNs
are only authenticated indirectly, STIR actors can just use normal EV
certs.<br><br><div>The only scenario where I see a need arising
for some sort of CABF work is if we end up in a situation like the web,
where third-party, non-authoritative CAs are attesting to possession of
TNs (as is done with domain names today). If this situation arises and
there is a need for some BR-like rules in this space, then we will need
to address many of the same governance questions as with code signing,
email, etc. -- who are the right CAs and relying parties to have
collaborate on these new rules. In any case, my personal read of the
situation right now is that this is the least preferred scenario among
the various parties currently involved.<br><br></div><div>Hope this
helps provide some more context for Tony's comments. Glad to provide
more information if people are interested, though this is probably not
the right mailing list to discuss.<br></div><div><br></div><div>--Richard<br></div><div><div><div><br><br>[1] <a href="https://datatracker.ietf.org/wg/stir/documents/" target="_blank">https://datatracker.ietf.org/<wbr>wg/stir/documents/</a> <br>[2] <a href="https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/" target="_blank">https://datatracker.ietf.org/<wbr>doc/draft-ietf-stir-<wbr>certificates/</a><br>[3] <a href="https://datatracker.ietf.org/doc/rfc7340/" target="_blank">https://datatracker.ietf.org/<wbr>doc/rfc7340/</a><br></div><div>[4] <a href="https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure" target="_blank">https://en.wikipedia.org/wiki/<wbr>Resource_Public_Key_<wbr>Infrastructure</a><br></div><div>[5] <a href="https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/" target="_blank">https://datatracker.ietf.org/<wbr>doc/draft-ietf-stir-<wbr>rfc4474bis/</a><br></div><div>[6]
Note that if you were to specify the name-to-TN mapping service, you
would need the same direct TN authentication that the STIR certs draft
defines, so you might as well use those certificates directly, without
the mapping service! So the name-to-TN mapping service only makes sense
to the degree that it's private; this lack of interoperability is
another reason that some in the IETF WG want to have a more direct
authentication mechanism.<br></div></div></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 28, 2016 at 10:00 AM, Tony Rutkowski <span dir="ltr"><<a href="mailto:tony@yaanatech.com" target="_blank">tony@yaanatech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Dean and CABF members,<br>
<br>
Some of you may be aware - if nothing else through the<br>
press coverage - that efforts have been stepped up to deal<br>
with so-called robocalls that is more generally known<br>
within the many industry communities involved as <br>
anti-spoofing.<br>
<br>
Much of the work currently revolves around associating<br>
X.509 certs with telephone numbers - in blocs or individually.<br>
Central to this approach is the attached Internet Draft in<br>
a group known as stir. Although it is being treated as <br>
"last call," concerns have been raised as to its suitability.<br>
Indeed, the obvious question is why don't they simply<br>
use the Forum's specification and a class of EVcert for<br>
this purpose, including its OCSP provisions. That <br>
question hasn't been answered, and there is no known<br>
collaboration with the CABF.<br>
<br>
Some of the statements in this draft are flat wrong,<br>
such as that introduction statement that "...telephone <br>
numbers have long been a part of the X.509...." In addition,<br>
the identity construct "Service Provider Identifier (SPID)"<br>
is fuzzy at best and has no consistent global use. Also<br>
omitted is any treatment of Rec. ITU-T E.164 which is<br>
the global telephone identifier number space to which <br>
the certificates are being bound.<br>
<br>
Why should the CABF and its members care? For the <br>
CABF itself, that answer is that the EVcert specification<br>
is best of breed, scales well, and has many years of<br>
experience and evolution behind it.<br>
<br>
The OS/browser vendors should care because their <br>
platforms, tables, and apps will make use of the <br>
stir certificates. The CAs should care because the<br>
provision of certificates globally for this purpose<br>
is a major business opportunity that in many national<br>
jurisdictions will be the subject of regulatory provisions.<span class="HOEnZb"><font color="#888888"><br>
<br>
--tony<br>
<br>
<br>
<br>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>