Re: [stir] current draft charter

[Dave Crocker <[e-mail]>]

On 6/16/2013 6:50 PM, Peterson, Jon wrote:
>
>
>> You are defining the ability of a third-party to vouch for a caller-id
>> value that is not (necessarily) their own.
>
> I'll speak this below, but I don't think we're on the same page here about
> who is a third party versus a first party to the names in question.

Note that I'm not stating my own preference, but rather what the spec says.


>> In any event, note that a premise of the model you've been describing is
>> that the guy being validated gets to tell you where to look for the
>> validation.  That seems an odd trust model. I'd normally expect the
>> verifying agent to choose the server with validation information
>> separately.
>
> I addressed that in my last mail. The "guy being validated" provides a
> pointer to the cert, yes, but whether or not you trust that cert is a fact
> about your relationship to the CA that issued it.

Then what is the point in having the pointer, rather than letting the 
validator decide where to get the cert from?

I suspect the answer is that it's a search efficiency hack, rather than 
a required mechanism, helping to find a knowledgeable CA amongst 
potentially thousands.


>>> entity, if not, then not. I'm not sure what you mean by "not limited to
>>> the owner of the From field value." In so far as the originating domain
>>> is
>>> the "owner," then only they can sign it, if that's the limitation you're
>>> concerned about.
>>
>> That's not what RFC 4474 specifies, according to my reading of it:
>>
>>     Section 4:
>>
>>     The authentication service authenticates Alice (possibly by sending a
>>     Digest authentication challenge) and validates that she is authorized
>>     to assert the identity that is populated in the From header field.
>>
>>
>> "authorized to assert" does not have the same semantics as "is the owner
>> of".
>
> Alice is not the signer, or owner, in this use case; the authentication
> service is implemented by an intermediary. The intermediary is the "owner"
> (in the sense I'm guessing you) of the domain name that appears in the URI
> Alice puts in her From header field. I don't want to get too entrenched in
> terminology that we're unlikely to use here, but Alice only "owns" her URI
> to my mind in so far as it was allocated to her by the owner of the domain
> name  - they get to choose who gets to be [e-mail] and who gets to
> be [e-mail]. If they decide they don't like me anymore,
> [e-mail] can vanish in the blink of an eye.

That has become nicely confusing (for me.)

The basic entity of interest is the phone number.  The basic ownership 
of internet is for the phone number.

Who owns the validating service is (or, for this topic, should be) 
secondary.


>>     Section 5, Step 2:
>>
>>     The authentication service MUST determine whether or not the sender
>>     of the request is authorized to claim the identity given in the
>>     identity field.
>>
>> ditto.
>>
>> What you've defined permits multiple, separate third-parties to be able
>> to make validity assertions about the use of the caller-id value.
>
> What we've defined allows the owner of example.com to decide who gets to
> be [e-mail] and who gets to be [e-mail]. It doesn't allow
> multiple entities to be example.com.

That's not the constraint I read in the RFC.  What you've just described 
here is ownership of the string being validated.  In the SIP case, that 
means ownership of the phone number.  RFC 4474 does not specify that, 
according to my reading of it.



> Now that much said, if the relying party trusts thousands of trust anchors
> a la web PKI and we're in that space, then sure, there's always the
> potential for mischief we've seen lately in web PKI.

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.


>> The idea that an authorization-checking mechanism would somehow depend
>> upon the SIP routing service doesn't make obvious sense to me.
>> Consequently I do not see how it should/can/will affect choice of the
>> validation query service.
>
> It's a subtle point, again dancing around the questions you were raising
> about "owning" names. One of the reasons RFC4474 adopted the design it did
> was because the "owner" of example.com controls what traffic goes to jon
> versus dave in the RFC3263 model, and authenticates jon or dave when they
> register to receive traffic.

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.


> The trust relationships that were built for
> that served as a model for the use case you were reviewing above, where
> Alice authenticates to a local intermediary that instantiates the RFC4474

This sounds like a transitive trust model based on trust amongst telcos.


> authentication service role. In cases where those registration concepts
> and routing concepts don't conform to the expectations of RFC3263 (which
> includes routing to E.164 numbers), the assumptions of RFC4474 break down.
> Just giving more color on why RFC4474 didn't set the world on fire.

+1


>> The essential point behind this line of discussion is that an entirely
>> new cert semantic and trust structure will need to be invented and
>> deployed.
>>
>> Note that this must be globally integrated and openly accessible.
>
> 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.

Absent that, we can all be quite sure that all three assertions are... 
valid.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net