# STIR Working Group at IETF 114 {#stir-working-group-at-ietf-114} ## Actions: {#actions} * draft-ietf-stir-passport-rcd will be submitted to the IESG for publication. * Jon will add "AS may not include msgi in nonmsg passport and VSes must ignore msgi in nonmsg passports" to -05 of draft-ietf-stir-messaging, which will then be submitted to the IESG for publication. * Chris will update draft-ietf-stir-identity-header-errors-handling based on the discussion (and subsequent list discussion). WGLC continues. * The list will be polled on whether stapling should be included now in draft-ietf-stir-certificates-ocsp - the room felt it was not needed. If the list agrees, -02 will go to WGLC. ## Administrivia {#administrivia} * Agenda Bashing * Minute Taker - Jean Mahoney * Jabber Scribe - Jonathan Lennox * Bluesheets WG document status presented. No changes to agenda. ## PASSporT Extension for Rich Call Data {#passport-extension-for-rich-call-data} * Chris Wendt and Jon Peterson * draft-ietf-stir-passport-rcd-19 * Have all WG Last Call issues been resolved? Chris presented. Changes: normative text changed based on Ben's feedback. Ben - my comment was on the normativity - making requirements on the ecosystem. I'm ok with SHOULD. I don't want to push another revision unless other changes occur. Chris - want people to think of appropriate policies. Okay either way. Jon - we won't bless these policies in the IETF. An IETF spec shouldn't specify. The wording is tortuous here. Don't want to require that the ecosystem to comply. Lennox - (something about meeting the requirements trivially). There is something wrong grammatically with the statement. Jon - need an Englishing pass on this. Russ - we're in WGLC. Do you want to send -19 or -20 to the AD? Jon - okay with sending -19 to the AD. richard - agree. Send as soon as possible. There's a queue of implementers waiting for this. Russ - we'll leave the grammatical error in. Ben - the clearer it is, the quicker it will get through the review. Russ - we'll send today. Will the authors send me an IPR statement? ## STIR for Messaging {#stir-for-messaging} * Chris Wendt and Jon Peterson * draft-ietf-stir-messaging-03 (-04 published just before) * Have all WG Last Call issues been resolved? Jon presented. Ben (from queue) - I did not propose polymorphism. Glad we don't have it. Don't make it hard to specify another use for this. Jon - updates RFC-this - low cost. RjS - letting other passport types pick this up. This nice short name - will it be future proof? What do you mean "msg"? Jon - We have generic definition of msg. Can be taken pretty broadly. msg isn't email. I think it's okay. It could be a mime thing? RjS - willing to leave it alone, just wanted to kick it around. Confusion at the implementer's layer. Jon - no worse than rcd and rcdi. Jack - don't care from a message PoV. Odd side effects that I'm worried about. A question of enforcement on the verifier side. One that enforces will look very different than one that doesn't. If a future or weird AS creates a passport with a msgi on it. A verifier that doesn't implemnt the spec will carry on just fine - will ignore. A verifier that does implement it, can drop it. Jon - AS may not include msgi in nonmsg passport and VSes must ignore msgi in nonmsg passports. I can add that. Subir - ... do we need to do anything for those ppts? Jon - concerned about a security weakness if we don't clamp this down. non msg passport types. Chris - I like where we landed. Jon - Ben - I would like to keep it. Other message types might use oob. Might be worth to have disclaimer language - it's not solved in the draft. Jon - 8816 - whatever comm system you're using, don't need any Lennox - a crypto hash over message. Needs to be unambiguous, eg Unicode denormalisation. Jon - turn this into mime and it needs to be unambiguous before signing. Jon - any other changes before shipping? Ben - this version? I'll be doc shepherd. Jon - 04. Ben - you agreed to make changes Jon - Can we add that insertion after LC? Fine, I'll just make the change now. ## Identity Header Error Handling {#identity-header-error-handling} * Chris Wendt * draft-ietf-stir-identity-header-errors-handling-02 * WG Last Call is underway; discuss any open issues Chris presented. Jon - There's no supported for Reason, is there? RjS - it's a constant churn. Implied signaling of support. It's not helpful and agreed that we wouldn't do implied signaling. Lennox - Would anything go wrong if you inserted it? Chris - if you don't understand stir Reason headers, you ignore it. Richard Shockey - 607, 608, 603 reason codes. Ample precedent for reason codes. Chris - slightly different topic. Including the Reason header field and negotiating support. Chris - Should we wait for draft-ietf-sipcore-multiple-reasons before sending error-handling to WGLC? RjS - don't think so, let the process move forward this document. I'll get a new version of the draft out soon, but don't need to wait. Shockey - reason codes may or may not have privacy implications. Chris - we include the full passport, we recommend compact form. I think we're okay. Chris - use case for multiple errors. There can only be one cause code. Is there a case for multiple cause codes? Do we want to restrict? Jon - SIP cause codes indicate repairable conditions. There could be lots of things wrong in the SIP message. We decided that there would be a single expression of what is wrong. There can be cascading issues at other elements. Fine with having that constraint. Do single. Chris - only remove ppi and only for full form? Jon - makes sense Jack - what's the benefit? Jon - you leak info in full form, but not compact form. Chris - would it be useful for the AS to know there was an error upstream. Do we need to describe what happened? Roman - remove it completely. If a feature is implemented, ... makes it contained to the device implementing stir. Chris - if you get a Reason header without the ppi? Jon - one prior AS removes it, it makes sense that the AS removes it... Chris - stir-specific cause codes. Jon - is 603 stir specific? Shockey - how extensive to want extensibility? Chris - going forward, want to support new stir cause codes. Lennox - does the future spec says, hey I'm stir-specific. I'm in this category. Chris - yes. Chris - Bullet 3 - explicit about only 1 cause code. Bullet 4 - no change. Jon - we'll need to name some other status codes that are applicable. Chris - these are reason headers intended for consumption by the AS Jon - only thing that would help if the AS fixed it. Chris - I can make these changes and discuss on list. ## OCSP Usage for Secure Telephone Identity Certificates {#ocsp-usage-for-secure-telephone-identity-certificates} * Jon Peterson and Sean Turner * draft-ietf-stir-certificates-ocsp-02 * Early days; needs review and discussion Jon presented. Jon - what do people think of punting on stapling? Jack - what's the point of this without stapling? They're cacheable - speeds verification. Jon - instead of a massive list of TNs, just use OSCP, a single query - is number in scope. I was happy to do TN by ref. If the list is simple, and don't care if someone learns of your list. Attis pushed back. Jack - There was a discussion - we wanted something like OSCP or short-lived certs. We know how to do short-lived certs. Jon - short-lived certs - ACME which is a heavier list. Jack - without stapling, I'd be surprised if anyone used it. Chris - is it about roundtrips. Jack - roundtrips, cacheability. Jon - which side pays the cost. Chris - TN by ref -- inserting and removing TNs, is like revoking the TN being covered by the cert? Jon - hmmhmm. OCSP has a further issue do you do it stapled or not? We know how to do it without stapling. What's it look like with stapling? Who does it? AS vs VS side? Chris - short-term cert is mutually exclusive? Jon - not saying don't do short-term certs. It means doing ACME and people don't want to do ACME. Russ - OCSP includes a next-update field. You can cache between uses if you are verifying the same cert. Jon - there is no RTT gain on stapling vs not. Subir - Jon - the short-lived cert is.... short-lived certs done offline, once a day. Paid in cacheability. The VS has to dereference. It's less for call processing. Cost is ACME\*. Subir - how often are numbers are revoked? SOmething to consider. Jon - any given number can be revoked at any time. Sometimes where's it's static. Sometimes very dynamic. Subir - if this in place, do we need short-lived certs? Jon - I'm not saying abandon that path. It's easier to do. We need something to cover delegation cases. Lennox - how quickly does it change. How quickly do you need to say it's dead. If you're terminating, doesn't the CA know all the numbers calling the VS. That's a privacy consideration. Jon - it is leaking information. Stapling mitigates that. Changing the AS side, what if some AS implement it and some don't vs incomplete implementation by VSes. OCSP on the VS side is the easiest thing to implement. Russ - raise of hands: Is it worth doing OCSP without stapling? Jon - Initially. Not saying we're not going to do stapling. Russ - 8 people is fine. 2 think it's not. Jon - please speak? No one spoke up. Jon - We will get to the stapling part. If we're agreed, then we're pretty close to shipping. Russ - we'll give people time to look at it. If we don't hear anything, we'll WGLC. ## Any Other Business (if time permits) {#any-other-business-if-time-permits} Jack - In the cert rfc, the tnauthlist is only noncritical. If you ignore it, you don't understand the extension. Russ - we assumed that anything in the system would understand it. Jon - these are specialized CAs. Russ - are you asking to open the RFC? Lennox - hold for doc update, it will happen eventually. Jon - need energy behind connected id. We need it, but it's clunky, hard to solve. Don't know if people will do it. Do we need to figure out something weirder that people will actually implement. Chris - the whole messaging space is a different interaction model. The relationship is setup pre. Nonmedia invites establish the relationship. Jon - medialess dialogs updating to media dialogs, which was our best story. Whatever we do, it will go to sipcore. Prack path... Do you want to do it in the early media phase. It's clunky. Don't have to solve herfp to solve this. If you get a 200 ok, but what's in it is passport but there's something's wrong, ... you get pracks and you need to go into a sip drawing board. Ben - this is turning into offline discussion. Anytime herfp is mentioned, beer is required.