Minutes - Secure Telephone Identity Revisited (STIR) - IETF 103
MONDAY, 5 November 2018 at 1120

Chris Wendt (Comcast) talked about draft-ietf-stir-passport-shaken.  The
document is in IETF Last Call, and this discussion focused on resolving issues
that were raised.  The origid field carries an opaque value that identifies
the service provider, not the call originator, so it does not leak personal
information.  Chris to add text to Privacy Considerations pointing to base
PASSporT specification and explaining that the use of origid.

Jon Peterson (Neustar) talked about draft-ietf-stir-passport-divert.  A recent
question came up about having a signature over R-URIs.  This document was
created to handle a change to the administrative domain. Note that there are
two very different use cases.  The first one is call forwarding.  The second
one is a call to 1-800-United that us redirected to a geographic phone number.
In the second case, the end user knows that the recipient is representing
1-800-United.  The core mechanism handles both use cases, and there is no need
to change the mechanism to address the R-URI.  In exceptional cases, the R-URI
changes, but for the standard call forwarding scenarios,  the use of div is
straightforward. Further, if a div includes a R-URI that is radically
different than the original To field, then it is easier for a verification
service to determine that it is not a cut-and-paste attack.  The document is
ready for WG Last Call. 

Jon Peterson (Neustar) talked about draft-ietf-stir-oob. This document is
already in WG Last Call, but the WG Chairs haven't made a consensus call yet.
The WG is going to publish this framework, but not protocol that implements
the framework.

Chris Wendt (Comcast) talked about draft-ietf-stir-passport-rcd.  The group
discussed whether it would be better to include a jCard by reference or value.
A reference would be a URL to fetch the jCard.  A value would include the
jCard in the PASSporT directly.  Alternatively, the whole jCard could be
carried a SIP request, but the PASSporT signature could cover it.  In
addition, a reference naturally supports many formats, not just jCard.  If
integrity of the referenced jCard is needed, the reference can include a hash
of the expected jCard.  Of course, a jCard itself can have URLs inside them,
and the hash value does not provide integrity for the objects that they
reference.  There is concern that including a jCard by value will make the
PASSporT too large.  The next version of the document will support both value
and reference, and then we will see what actually gets used.