Minutes for STIR at interim-2016-stir-1
Secure Telephone Identity Revisited
||Minutes for STIR at interim-2016-stir-1
Minutes - STIR Virtual Interim May 27, 2016
Slides and Bluesheets are available at
Recording is available at
draft-ietf-stir-rfc4474bis, draft-ietf-stir-passport, and
draft-ietf-stir-certificates are very close to ready to start
working group last call.
All three will be revised shortly reflecting list and call conversation.
Points of remaining pressure center on:
* making sure the signatures we are specifying will be useful when
interoperating with WebRTC deployments.
* enabling assertions about calls to multiple destinations
We discussed when to include the canon parameter, noting again the potential
privacy leakage including it brings. The question was whether to leave
including the parameter optional or to simplify thing and always include it. It
was noted that at least one implementer asked why we didn't always include it.
Jon noted again that having the redundant bits in the message may be
problematic in network constrained environments. The participants in the
discussion leaned primarily toward keeping the current approach of making its
inclusion optional, recognizing that operational realities may effectively
cause it to always be provided. Chris will start a thread on the list
asking whether we should make the parameter always be present.
Jon pointed to the recent rework of the text around Date - there were no
changes suggested on the call.
Jon walked through the changes to the status codes needed to reflect having
multiple Identity headers. Conversation confirmed support for the general
principal of generating an error only when there were no acceptable Identity
headers. There was not support for building mechanisms to speak about why
individual Identity headers are not acceptable when there are multiple.
There was a discussion about whether to add text to the requirements on other
credentialing systems (besides certificats) that would take advantage of the
modularity we currently support. Russ will start a thread on list to see if
anyone is considering such a mechanism.
Chris provided an example of the difference in size between an ES256 and RS256
signature. Jon pressed on whether we had a high degree of confidence that the
approach of requiring support for ECDSA only to allow everyone to get certificate,
even from CAs that only have RSA signed root certificates. Both Sean and Russ
are seeing real deployment.
There was a discussion about saving space in the passport json for mky. Chris
will shorten the "algorithm" and "digest" key names, and specify representing
the digest value without colons between each encoded octet. Concerns around
allowing STIR to be used by an IDP in WebRTC were raised (and revisited at the
end of the call).
Jon walked through the updates - no concerns were raised.
There was a discussion around providing certificates in a header field instead
of relying only on using cid and multipart/mime given concerns about the
feasibility of relying on multipart/mime . Robert noted that multipart/mime is
well implemented at recent SIPits. The conversation suggested continuing to
rely on multipart/mime, but state that future work may provide other ways to
carry certificates. There was support for exploring the idea of providing a new
header field alternative in a separate draft.
We discussed whether we needed to be able to speak to Level-of-Assurance.
There was support for being able to say something. After a brief discussion of
RF6711, Sean took an action to mock up the mechanics, particularly IANA
considerations text to get a new registry going, obtaining a sub-arc, and
discuss what would be necessary for registering a new OID.
There was no objection to simply removing the TBD for discussing methods of
partial delegation. There was no objection to shifting to IA5 for number
There was discussion around how to treat "unknown" OCSP responses. The proposal
was to profile the use of OCSP so that "unknown" was never returned. Russ asked
what the answer would be if you asked about a certificate that had never been
issued. Jon's proposal is that the answer is "No". Russ pointed out this was an
unusual use of OCSP and it would need to be highlighted and carefully explained.
After a brief recap of the space-saving formatting discussion above, there was
a discussion around making assertions about bare 822 names (firstname.lastname@example.org)
rather than URIs. It would be good to avoid having to know that these might be
mapped into, e.g., sip:email@example.com, or xmpp:firstname.lastname@example.org in order to
provide a useful assertion. The conversation wound down with the assertion that
passport is extensible, and new claims could be added to cover cases as they
arise rather than trying to engineer a one-size- fits-all solution. Cullen
notes that there is no WebRTC URI, so it is unclear what WebRTC would put in a
There was a discussion on the need to make assertions about multiple
destinations (to support PERC-like use cases for example). There was support
for allowing a list of destinations. Chris will propose a destination list in
The discussion continued into whether there was a need to make assertions about
multiple origins. Robert asserted that this was interesting, but not really
within the scope of STIR.
Cullen will organize a call with Jon, Chris, and the appropriate WebRTC experts
to determine how much alignment we need between passport and WebRTC
(particulary the security-arch document). The conversation noted that the goal
is to ensure we end up with a meaningful end-2-end assertion of integrity.
Summary of Action Items
draft-ietf-stir-rfc4474bis, draft-ietf-stir-passport, and
draft-ietf-stir-certificates will be revised shortly reflecting list and call
Chris Wendt will start a list conversation about always including the canon
Chris Wendt will propose passport syntax for representing a list of destinations.
Russ Housley will start a list conversation about whether anyone is actually
considering a credentialing mechanism that is not based on certificates.
Cullen Jennings will set up a call with the appropriate experts to discuss
what alignment between STIR and WebRTC is needed.
Sean Turner will provide an ASN.1 module for certs.
Sean Turner will mock up text around the mechanics of allowing STIR
certificates to speak to LoA.