STIR 122 Minutes
Summary
The chairs would like to thank Robert Sparks for taking notes, and going
above and beyond to summarize discussion from the meeting recording
after the fact.
Certificates
Chris Wendt presented draft-wendt-stir-certificate-transparency-05 on
Certificate Transparence (CT). The group discussed whether CT as defined
in RFC 9162 could be used as-is and whether the I-D should be treated as
a fork or a profile and whether it could be informational. People also
discussed how a verifier can determine if a certicate is actually
logged. The sense of the room was that the intent is to use CT with no
protocol change but be clear about how the relying parties look at the
result. The document will be restructured to reflect that. Any adoption
call will be made on a restructured document.
Chris briefed the room on
draft-wendt-acme-authority-token-jwtclaimcon-00, to be "officially"
presented in ACME.
VESPER
Chris presented VESPER Use Cases (draft-wendt-stir-vesper-use-cases-00).
People discussed the differences in conveying display names and other
caller details in STIR verses in the WebPKI, and the potential for
verification by accountable verication authorities. The authority might
be different for different display elements, for example calling numbers
vs display names. The chairs asked people to focus the conversation on
what we need to figure out in order to decide whether to adopt a
document on this problem. Discussion concluded that interested parties
should talk more and refine the use-cases and trust model and bring that
back for further discussion.
Caller ID Verification (CIV)
Feng Hao presented draft-hao-civ-00. This was originally submitted to
DISPATCH, but redirected to STIR because of the domain expertise of the
group. The chairs suggested that people think about the DISPATCH
question. Several people raised objections to the premise that STIR does
not do real-time caller authentication and that the STIR/SHAKEN
difficiencies described in the draft might apply to SHAKEN, but not
necessarily for STIR in other contexts. Time ran out with no resulting
action items.
AoB
Orie Steele (as AD) announced that Robert Sparks would step down as
chair, and thanked Robert for his service. Russ and Ben will continue as
co-chairs.
Detailed Notes
Chair overview
Certificates
STI Certificate Transparency
Chris Wendt leading the discussion
-
Eric Rescorla - why can't you just use CT?
- Discussion around whether this is a different protocol (a fork)
or is intended to be a profile.
- Discussion of logs, mis-issuance, and persona.
- Jon Peterson - Expects that we would use CT, and that this
would be a foundational technology that could be built on to
do more in the future.
- Eric - Any PDU that appears in this document for any purpose
other than providing informational clarity a problem.
Copying things from the CT spec is a problem.
-
Eric - how do you expect relying parties to verify that the
certificate was actally put into the log as opposed to the SCT was
issued? This has been a huge problem in the web PKI.
- Chris - the verification service would rely on auditing.
- Eric - doesn't work - the immutability claim relies on the
verification service actually verifying that the certification
is in the log. See
https://educatedguesswork.org/posts/transparency-part-2/
- Jon - the extent that we proscribe the conditions under which
the entries in the ledger are valid invalid might not be the
IETF’s job. Example: interpreting two delegate certificates in
the ledger covering the same number may require different
policies in different environments.
- Alec Fenichel - Less of a problem for the verifying service to
verify the logs than in the web world as the volume of
information the verification service needs to look at is orders
of magnitude smaller than in the web world. It would be
realistic to have a large number of verification services also
be monitors.
- Eric - the issue to consider isn’t scale, it’s privacy.
- Alec - don’t think there’s a privacy concern in shaken with
verifying certificates with service provider codes in them. If
the certificates actually had phone numbers in them it would be
more of a problem.
-
Ben Campbell - if this document is recast as only a profile of CTI
does it really need to progress in the IETF?
- Chris argued that there is value in working on this in the IETF.
-
Jon - can this document be Informational?
- Room had general agreement that it could.
-
Alec - agree that this should not be a fork of CT, but wouldn’t call
it the exact same thing as CT in the web world as it’s a bit of a
subset in the sense that there’s a slight difference in the parties.
The CT spec is written in the lens of TLS, specifically TLS clients
and handshakes vs relying parties.
- Eric - I’m not flustered about the parts of the CT spec you don’t
use, and I think this document can briefly say things like
“everywhere the CT spec says TLS clients this document means
verifier” and the ADs can work out PS vs Informational.
Summary of result:
- The sense in the room was that the intent is to use CT with no
protocol change but be clear about how the relying parties would be
looking at the result. The document would be restructured to reflect
that. Any adoption call would be made on a restructured document.
Brief STIR regarding draft to be presented in ACME
Chris Wendt
- +1s on continuing discussion and encouraging acme to adopt this work
from several people in the room
VESPER - VErifiable STI Personas
VESPER Use Cases
Chris Wendt
- Eric - What exactly would appear in the PDU? (Home Depot was used as
an example for discussion). The web pki largely abandoned a similar
idea of putting a name string in the cert for display to the end
user because it is trivially easy to get an official name that
sufficiently, even exactly, matching any given string by registering
it another jurisdiction.
- Chris - I recognize the issue, and the industry is working on
addressing this kind of confusion in other fora.
- Jon - This is very complicated - see CNAM, branded calling,
call-reasons, etc. But what makes this different from the web PKI
and EV is the set of Know-Your-Customer vetters that are
accountable for vouching for the assertion. But looking at PKI
through the lens of whether it has all the slots we need would be
useful. Is there actually any new tooling that needs to be specified
to carry the information we need to cary, or should this effort be
recast in how to use the tools we already have? Why do we need a new
token rather than using existing fields in the certificate?
- Eric - consider the trust model. Is the entity who validates I’m
entitled to use this number the same entity who validates the name
(dicussion: it can be but doesn’t have to be, but that won’t be part
of what the IETF stipulates). If these are different entities, we
have to figure out how to hoist the validation decision on the mark
into the credential signing the phone number binding.
- Jon - We have tools that address different models of how to hoist
that validation. We don’t have a protocol mechanism that’s missing -
just specification of policy.
- Russ Housley - can we focus the conversation on what we need to
figure out in order to decide whether to adopt a document on this
problem?
Summary of result:
- Jon, Chris and Eric should discuss more and refine the
use-cases/trust model and bring that back for further discussion
Caller ID Verification (CIV)
draft-hao-civ-00
Feng Hao
Summary: Time ran out - no action items resulted.
AOB
- Orie Steele (as AD): Thanks Robert as the outgoing STIR chair.