Re: [stir] current draft charter

[Dave Crocker <[e-mail]>]

On 6/16/2013 4:27 PM, Peterson, Jon wrote:
>>> If I understand the RFC 4474 model correctly, a validated Identity
>>> field has the semantics of asserting that the From field is valid.  So
>>> the assertion is not limited to the owner of the From field value.
>>> Correct?  While such a model is understandable, it dramatically
>>> increases the reputation-management complexity of the task.  I'm not
>>> aware of an extant service over the public Internet of similar
>>> complexity.
>
> We weren't exactly proposing a domain assurance council or something like

DAC merely worked on a standardized query mechanism; it was not a 
service.  But as far as defining a reputation-reporting service, 
actually you are.

You are defining the ability of a third-party to vouch for a caller-id 
value that is not (necessarily) their own.

That's different from defining a mechanism that let's someone assert 
direct ownership.


> that. The authorization decision was supposed to be checking the reference
> integrity of the domain in the From header field against the domain in the
> subjectAltName of the cert (provided the cert is valid and the root
> trusted): if there's a match, then this was signed for by the right

That seems to be the first reference to the specific field in the cert, 
and assigning specific semantics to it. Any chance this is part of an 
existing spec relating to STIR?

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.


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

    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.


> Correct. The entity making the assertion tells the verifier where a cert
> can be fetched, in the case that the verifier doesn't already have a cert
> for the signer. Whether the cert is valid, or the CA itself is trusted by
> the verifier, is however a different and prior question.

When I ask someone for money, I think it's really nice that I get to 
tell them who to talk to, to vouch for my credit-worthiness...



> Right. At the risk of waxing philosophical about it, I'd say that RFC4474
> took for granted the baseline assumption that RFC3263 would be how SIP
> requests were routed.

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.


>> So one proposal so far is that there would be certs which identify the
>> E.164 numbers they're authoritative for (in a CN/SAN field for example),
>> and that cert would be signed by some CA (or chain leading to one) that
>> you trust.  If it's a chain rather than directly signed by a CA, then
>> it's not clear how one goes about retrieving the certs for the chain's
>> links, and doing so could cause unacceptable delay.  It also means we
>> need revocation checks for the chain.  And I'd argue the management
>> aspects for this thing would be just as difficult as anything else
>> proposed so far.
>
> Although I'm not the expert, my understanding is that there are various
> cert chain compression techniques that could be applicable here. I've
> squinted a bit at OCSP and other possible real-time revocation checks for
> this as well.

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.


> But I do agree that there's no such thing as a free lunch, and that
> implementing a credential system for telephone numbers, even just in a
> single nation state, is operationally complex.

+1

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net