Minutes - STIR Virtual Interim May 27, 2016 Slides and Bluesheets are available at https://www.ietf.org/proceedings/interim/2016/05/27/stir/proceedings.html Recording is available at https://ietf.webex.com/ietf/ldr.php?RCID=d54a724ec7f7d9cf9914f7859dbb90ad Summary ------- 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 Discussion Details ------------------ RFC4474bis: 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. Passport: 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). Certificates: 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 encoding. 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. WebRTC interaction: After a brief recap of the space-saving formatting discussion above, there was a discussion around making assertions about bare 822 names (foo@example.com) rather than URIs. It would be good to avoid having to know that these might be mapped into, e.g., sip:foo@example.com, or xmpp:foo@example.com 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 passport assertion. 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 syntax. 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 conversation. Chris Wendt will start a list conversation about always including the canon parameter. 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.