[cabfpub] CABF role for anti-spoofing certificates

[Richard Barnes]

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.

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].

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.

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]).

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.

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.

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.

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.

--Richard


[1] https://datatracker.ietf.org/wg/stir/documents/
[2] https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/
[3] https://datatracker.ietf.org/doc/rfc7340/
[4] https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure
[5] https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/
[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.


On Sun, Aug 28, 2016 at 10:00 AM, Tony Rutkowski <tony at yaanatech.com> wrote:

> Dean and CABF members,
>
> Some of you may be aware - if nothing else through the
> press coverage - that efforts have been stepped up to deal
> with so-called robocalls that is more generally known
> within the many industry communities involved as
> anti-spoofing.
>
> Much of the work currently revolves around associating
> X.509 certs with telephone numbers - in blocs or individually.
> Central to this approach is the attached Internet Draft in
> a group known as stir.  Although it is being treated as
> "last call," concerns have been raised as to its suitability.
> Indeed, the obvious question is why don't they simply
> use the Forum's specification and a class of EVcert for
> this purpose, including its OCSP provisions.  That
> question hasn't been answered, and there is no known
> collaboration with the CABF.
>
> Some of the statements in this draft are flat wrong,
> such as that introduction statement that "...telephone
> numbers have long been a part of the X.509...."  In addition,
> the identity construct "Service Provider Identifier (SPID)"
> is fuzzy at best and has no consistent global use.  Also
> omitted is any treatment of Rec. ITU-T E.164 which is
> the global telephone identifier number space to which
> the certificates are being bound.
>
> Why should the CABF and its members care?  For the
> CABF itself, that answer is that the EVcert specification
> is best of breed, scales well, and has many years of
> experience and evolution behind it.
>
> The OS/browser vendors should care because their
> platforms,  tables, and apps will make use of the
> stir certificates.  The CAs should care because the
> provision of certificates globally for this purpose
> is a major business opportunity that in many national
> jurisdictions will be the subject of regulatory provisions.
>
> --tony
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160828/b1071de8/attachment-0003.html>