Re: [stir] current draft charter

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

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

>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?

It's in RFC4474, and as far as I remember not nuked (yet anyway) from
RFC4474bis.

>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. The relying party only
dereferences the Identity-Info header if they don't already have the cert
by some other means. What happens if the guy being validated provides a
problem cert in that link? Then the validation fails and nothing untoward
happens. This is not a problem.

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

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

There are harder edges in this neighborhood when we look at subdomains
(sip.example.com) and other delegation structures, but at the level you're
discussing, it doesn't have the properties you're describing.

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

I've already explained above (and in my previous mail) that the ability to
supply a pointer to a certificate does not cause relying parties to trust
that certificate - trust anchors provisioned at the relying parties do. If
the signer provides an untrustworthy certificate, then it won't be trusted.

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. That potential would
exist regardless of the presence of the Identity-Info header and its URI.
The problem statement draft already discusses this and talks about how, if
there would be certificates for telephone numbers, we should try to
address it.

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

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

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

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. Definitely agreed
something needs to be deployed, and that it needs to be openly accessible.
Global integration will come if it's successful, it won't come if it's not.

Jon Peterson
Neustar, Inc.

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