Re: [stir] current draft charter

["Peterson, Jon" <[e-mail]>]

> The liability you described above for ENUM is the same liability for
>caller-id: we need the
> carriers to agree to do this.


The purpose of the proposed work is not to change or extend the authority
of end users - and make no mistake, that was the purpose of public ENUM.
Politically, that ambition was a significant barrier to carrier adoption.
What we're proposing to do here instead is to leverage existing authority
structures to the fullest capacity to increase the security of caller ID.
There are roles carriers could play in this that would help, if they are
interested and able. There are also techniques like iMessage that could
help where carriers are not, or where things are just too early for
carrier involvement. But I don't think this all reduces to just "we need
the carriers to agree to do this," and nor that this has the same
implications for carrier adoption that public ENUM did.

Today there are use cases where carriers delegate some of their authority
over numbers to entities like service bureaus or enterprises. Arguably,
end users in many jurisdictions have certain authority over their numbers
(like the authority to port) and in the future it's possible that
regulators would broaden it. I can't readily speak to the question of
whether or not carriers want to extend the authority of users over numbers
except to say that some probably do and others probably don't. If we look
at a service like Google Voice, say, and how carriers support that
service, we can see at least some evidence for carriers who would benefit
from increasing the authority of users in certain deployments. For the
purposes of securing caller ID, I think activities at many of these
different levels could be effective and that we shouldn't rule them out.


> In what way is DNS with DNSSEC/DANE *not* a PKI?

That is a fair question, I agree, and I don't mean to create some
artificial distinction here. As I've suggested previously, I think the
public DNS dictates a particular delegation and enrollment model for the
pseudo-PKI that is DNSSEC/DANE. It may be that model is a fit for some of
our use cases and not others. In any event, I think the charter and
problem statement should be broad enough to encompass "key management" as
Stephen suggested rather than limiting this to certificates.


Jon Peterson
Neustar, Inc.

On 6/12/13 9:42 PM, "Hadriel Kaplan" <[e-mail]> wrote:

>
>On Jun 12, 2013, at 6:01 PM, "Peterson, Jon" <[e-mail]>
>wrote:
>
>> It's always hard to say with any certainty why something failed. We can
>> point to various causes and effects, one of which in this case certainly
>> would be the difficulty of getting every world government to implement
>>the
>> system. ENUM was also designed from the start to empower end users to
>> control how their numbers would be associated with Internet services,
>>yet
>> because of its built-in regulatory structures it required that
>>empowerment
>> to be driven by carriers with different interests.
>> 
>> But we don't even have to be asking ourselves about the relevance of
>> public ENUM to the proposed work here in STIR unless we want to try to
>> base everything on keying in the public DNS for telephone numbers. There
>> are other models for this that don't have the liabilities I described
>> above, anyway.
>
>The liability you described above for ENUM is the same liability for
>caller-id: we need the carriers to agree to do this.  We don't need *all*
>of them to, at least not at the start, but we need a critical mass within
>at least one country, preferably more than one country.  Convincing just
>Enterprises to do it is neither necessary nor sufficient.
>
>
>> Keying in private DNS is more viable, for example. I think
>> a PKI is more viable.
>
>In what way is DNS with DNSSEC/DANE *not* a PKI?
>
>-hadriel
>