Re: [stir] current draft charter

[Dave Crocker <[e-mail]>]

On 6/16/2013 11:56 PM, Peterson, Jon wrote:
>> As I understand it, this model of thousands of trust anchors is showing
>> some very rough edges for scaling, accuracy, and scope. I believe it
>> also has had a single semantic, unrelated to the one being proposed.
>
> Right, the rough edges there are why the current problem statement for
> STIR suggests we do things a bit differently.

In looking over the draft charter that you circulated last Tuesday, I'm 
not seeing text that obviously covers this.  In contrast, all of the 
list discussion about CAs appears to be based on the current model that 
uses very large numbers of anchors.

Even with text in the charter, the deeper question is what changes are 
feasible to the current model that are viable with the scale, diversity 
and reliability needed for the proposed service?  Absent a vetted design 
approach, it won't mean much to have a charter task covering it; in fact 
it will be more appropriate as an IRTF task...


>> I think I'm beginning to understand:  The provider that is giving SIP
>> service is the one that vouches for its use.  In effect, the provider
>> has the authority of the number owner, rather than the user to whom the
>> number is assigned.
...
>> That's not subtle; it's quite basic.  It would be like requiring that my
>> ISP be the one that vouches for my use of my domain name.
>
> If your ISP actually owned your domain name instead of you, sure. If in
> fact you own your own domain name, RFC4474 lets you (as in, your UA) act
> as your authentication service. The authentication service is a logical
> function that can be instantiated by either the UA or an intermediary. Who
> should do it depends pretty much entirely on who owns the domain name.
>
> Do I own the email address "[e-mail]"? No, Neustar owns
> it.

Number portability changes this. The number does not belong to the 
service provider.


>> This sounds like a transitive trust model based on trust amongst telcos.
>
> Not really. example.com gets to vouch for example.com addresses, and the

Unlike email addresses, the relationship between the service provider 
and the user is not built into the identifier.  What you've been 
describing is an unspecified service in the background that establishing 
this relationship.  It's key because it authorizes the provider to vouch 
for use of the number.



>>> I'm not sure it's a new cert semantic, or a new trust structure, or that
>>> something needs to be "invented" to support this.
>>
>> Feel free to point to instances of each that are deployed and used.
>
> The structures that underly trust in the proposed STIR work are simply the
> extent ones in the telephone network.

By way of considering edge cases, to the extent that this mechanism is 
going to validate uses of numbers for calls that do not originate from 
their home -- such as the mobile physician calling from someone else's 
phone -- the extant trust mechanisms don't cover them.

In any event, the considerable barrier to adoption you've just described 
is adoption by all telcos.


> There are currently number block
> assignees, delegates of those assignees, and ultimately end users who
> possess numbers. Databases exist that contain all that information, and
> credentials exist that reflect those scopes of authority. The proposed
> work is only to leverage those structures.

Forgive me but I don't see any of that in the charter or discussions so 
far.  It seems to be left as the "then a miracle happens" part of the 
specification.  As such, it isn't possible to evaluate its practicality.




On 6/17/2013 12:07 AM, Peterson, Jon wrote:>
> I think the advantages below, with the exception of 4, would be true
> of any golden root we created for whatever protocol, be it HTTP or
> something else. I'm sure I could define an HTTP golden root such that

The real point of practical leverage here is existing deployment.  It's 
easy to 'define' almost anything.  Getting deployment and adequate 
operational service is the hard part.


> the verification service could synthesize the proper fetch request
> from the URI in the From with an Identity-Info, one that updated in
> real time so you never needed to worry about revocation, one for

For any existing capability, I'm sure one can define a new service that 
contains it.  The question is what risks and benefits come with that new 
effort?




On 6/17/2013 5:03 AM, Henning Schulzrinne wrote:
> It might be helpful to explicitly distinguish three models,
 > independent of whether the cert is stored in DNS or some HTTP-accessed
 > data store:

Big +1 for this sort of analytic discipline in the effort...


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net