Hedge notes from IETF 121 STIR WG
The chairs thank Simon Castle for taking notes.
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.
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.
Neither VESPER or Certificate Transparency are ready for adoption. The
WG needs to discuss use cases and consider reframing the STIR charter.
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)
Questions about:
requiring or allowing the root cert to be omitted from x5c.
using both the x5u and x5c for different parts of the chain?
How does verification actually apply the output of CT?
Overall flow taken from RFC 6962 (more opinionated, only
supporting pre-cert flow)
Covers both SPC and TN Delegates
No specific actions raised in discussion. Chris looking for the
proposal to get adopted by STIR.
Questions over selective disclosure from consumers
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.
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.
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.
Selective disclosure is a new element on top of the 'iss'
behaviour already in RCD; maybe break this out as well. This is
complicated!
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.
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?