[stir] Comments on rfc4916-update

[Jonathan Rosenberg <[e-mail]>]

In advance of our meeting today:

There is another interesting use case for this spec that is not mentioned
in the intro. Specifically, when calls are placed by automata for the
purposes of verifying ownership of phone numbers, it is really important
that the call has not actually been forwarded. One can imagine that the
entity performing the call to verify ownership of the number, would want to
receive the rsp passport and check that it matches the called number. This
would actually address some of the concerns that have been raised about the
insecurity of forward routability checks for verifying number ownership.

On this:
> An "rsp" PASSporT that signs a different "dest" than the one that
appeared in the PASSporT of the dialog-forming request MUST send at least
one "div" PASSporT with it. If no "div" PASSporTs were received in the
dialog-forming request, then "rsp" PASSporTs MUST NOT be used in responses.

I think this MUST is overly harsh. The entity sending the rsp passport has
no control over whether intermediaries inserted div passports along the
way. If none of them do, it means that the rsp passport can never be sent
and this spec is useless. Indeed, for the use case I outline above, the
originator of the call doesnt need the div passports at all, just the rsp
passport.

On this:
> The use of the connected identity mechanism here specified is not limited
to provisional dialog requests. Once a dialog has been established with
connected identity, any re-INVITEs from either the originating and
terminating side, as well as any BYE requests, MUST contain Identity
headers with valid PASSporTs.

It seems odd to me that this spec would require the originator of the call
to take extra actions (namely, including passports in mid-dialog requests)
just because the terminating side decided to add an rsp passport in the 200
OK response to the INVITE.

Along similar lines, this seems a bit onerous as it introduces requirements
on the caller that have nothing to do with connected identity per se:

> It is however REQUIRED by this specification that if a UAC sends a CANCEL
for its own PASSporT-protected INVITE request, that it include an Identity
header with a valid PASSporT in the CANCEL.

This too, seems like it is more appropraite as a SHOULD, in cases like I
outline above where the div chain itself is not interesting to the caller:

> Mid-dialog requests also require special handling in diversion cases.
Implementations compliant with this specification MUST validate the "div"
chain back to the "rsp" PASSporT on any Identity header field values
received in responses.

-- 
Jonathan Rosenberg, Ph.D.
[e-mail]
http://www.jdrosen.net