Hedge notes from IETF 121 STIR WG

Secure Telephony Identity Revisited (STIR) - IETF121

• 4 November 2024, Dublin, Ireland.

Summary

The chairs thank Simon Castle for taking notes.

Certificates

Jon Peterson presented draft-stir-certificates-shortlived-01 (Not
revision 00 as originally shown in agenda.) The update makes the support
and use of x5c MUST and the inclusion of a redundant x5u a MAY for
backwards compatibility. The WG discussed the root certificate should be
omitted from the x5c certificate chain, and decided to say it SHOULD be
omitted. The draft will go to WGLC after Jon submits an update with that
change.

Chris Wendt presented draft-wendt-stir-certificate-transparency-04. The
update is more self-contained than before. It references RFC 6962 but
does not depend on it. It focuses on the pre-certificate flow and
provides a set of APIs for the STIR/SHAKEN ecosystem.

VERifiable Sti PERsona (VESPER)

Chris presented draft-wendt-stir-vesper-02. VESPER extends the STIR
architecture with the use of PASSporTs as Selective Disclosure JWTs
(SD-JWT). It describes an architectural framework for the vetting and
registration of claims about callers. Chris envisions VESPER as mainly
focusing on business callers. The WG discussed that VESPER creates a
3-party architecture, which can be complex and may require updating the
STIR charter. Several participants wished to better understand use cases
before adopting the work, and expressed that it might need to be broken
into smaller points.

Conclusions

Neither VESPER or Certificate Transparency are ready for adoption. The
WG needs to discuss use cases and consider reframing the STIR charter.

Detailed Notes

Chairs

• Ben Campbell
• Robert Sparks
• Russ Housley

Agenda

1) Administrivia
- Agenda Bashing
- Minute Taker
- Jabber Scribe
- Bluesheets - Meetecho tool

2) Certificates
- draft-ietf-stir-certificates-shortlived-01
- Jon Peterson

- draft-wendt-stir-certificate-transparency-04 
    - Chris Wendt

3) VESPER - VErifiable STI Personas
- draft-wendt-stir-vesper-02
- Chris Wendt

4) Any Other Business (if time permits)

Actions (note-taking by Simon Castle)

draft-ietf-stir-certificates-shortlived-00

• Make the certificate chain to SHOULD exclude the root cert
• Push for last call as soon as this change is made.

draft-wendt-stir-certificate-transparency-04

• Is this ready for an adoption call?
  • Conclusion: probably not.
    • Chris doesn't want to bind this to VESPER.
    • Orie wants a further discussion around use-cases, tying to
      both and the overall charter.
    • In chat: Eric Rescola thinks further consideration and
      updates required before adoption

draft-wendt-stir-vesper-02

• Action required to clarify the language around the proposal.
• Additional discussion required before adoption call.
  • In particular, a requirements discussion to help agree what the
    value of this proposal is and whether it aligns with the current
    scope of STIR.

Additional notes

draft-ietf-stir-certificates-shortlived-00

• No immediate pushback for requiring the redundant x5u

• Questions about:

  • requiring or allowing the root cert to be omitted from x5c.

    • Inclination is it SHOULD be omitted but not required

  • using both the x5u and x5c for different parts of the chain?

    • not yet thought about in detail, might have some value but
      also space for security concerns.
      • Chris Wendt pushed against it - not standard JWT, would
        be a STIR specific thing

draft-wendt-stir-certificate-transparency-04

• How does verification actually apply the output of CT?

  • From the ecosystem - monitors and auditors keep things in check
    and report to then embed into certificate revocation.

  • Overall flow taken from RFC 6962 (more opinionated, only
    supporting pre-cert flow)

    • This draft is fully self-contained, referencing but not
      dependent on 6962.

  • Covers both SPC and TN Delegates

• No specific actions raised in discussion. Chris looking for the
  proposal to get adopted by STIR.

draft-wendt-stir-vesper-02

• Attempt to address the fact STIR currently relies on self-assertion
  of info by the call signing party
• VESPER introduces a set of Ecosystem actors

• Questions over selective disclosure from consumers

  • What sort of data? possible information to law enforcement, or
    choice of different info/profiles to different callees.
    • Possible challenges of how to make that available for the
      user to make those choices.
    • Careful choice of policies regarding what info would be
      shared with the Claim Agents in the first place.

• Rich Call Data can offer greater trust, fitting into the STIR
  ecosystem. Jon Peterson expressing concern about where
  STIR/PASSporTs might be going for this to be included; what threat
  does this help defeat?

  • This process is intended to formalise the vetting process rather
    than relying on the signing service.

    • We already have this with 'iss' in RCD
    • Still got concerns about the level of information that might
      be stored and generally kept.

  • Could cover consent as a recipient e.g. what calls you could
    receive

• Orie as individual contributor: Adding a three-party model into STIR
  around here could be challenging.

• Orie as Area Director: based on the current charter, STIR has
  largely been solved. Extensions are being applied but VESPER so far
  requires squinting to count; we'd need to re-establish the charter
  and milestones for this to be valid.

  • Chris's response: it's a new PASSporT extension, albeit a large
    one.
  • Chairs have had a discussion about this: initial discussion
    allowed for this.
    • Ben thinks the PASSporT extension is covered but maybe not
      the claim agents. Might make sense for STIR to take on but
      could require charter rework/extension
    • Robert thinks charter reframing is possible appropriate.

• Jon Peterson: recommendation to break this up into parts.

  • For example, Right to Use is something we should have but should
    be a different problem to most/all the other points put forward.

    • Other parts could then build on this, but make it
      independent!

  • Selective disclosure is a new element on top of the 'iss'
    behaviour already in RCD; maybe break this out as well. This is
    complicated!

    • Discrepancy on what selective disclosure means - in
      particular JWT vs intended in this presentation!

  • Could be a VESPER framework that takes this all in bitesize
    chunks, solving questions ike what they're individually solving
    and what the security and privacy concerns are. The presentation
    as given feels too big and scoped well outside of STIR's
    original plan.

    • Chris agrees it was intended to be extensible and didn't
      want to be all-inclusive in the first place.

• Questions around the motivating case. Why do you want to have a
  single mega-credential that you disclose parts of instead of just
  individual certs? Does this do anything that existing certs (and
  RCD/short-lived certs in particular) doesn't do, especially within
  the STIR WG?