STIR Working Group at IETF 120

Summary

The chairs thank Jonathan Lennox for taking notes. We note that that
this is an extremely valuable service.

Post-WG Drafts

draft-ietf-stir-oob-servprovider and draft-ietf-stir-4916-update are
with the IESG. Orie Steele (Responsible AD) asked if the downref to RFC
8816 (REST interface) draft-ietf-stir-oob-servprovider is sufficient for
implementors.
After discussion, the sense of the room is that the document is
sufficient as is, but the chairs agreed to make a consensus call on the
mailing list.

Certificates

Jon Peterson noted that draft-ietf-stir-certificates-shortlived is now a
working group item. The group discussed whether x5c should be "MUST use"
for compliant implementations and generally agreed that it should.
Additionally x5u should probably be MUST for backwards compatibility.
People decided that x5c certificate chains should probably not include
the root certificate. Further investigation of RFC 7519 and consultation
with JOSE experts is needed.

Jon thinks that OCSP is ready for WGLC, but we need another spin on
shortlived. Jon also noted that the OCSP example uses a ".cer"
extension. This is incorrect for PEM certificates, but is consistent
with RFCs 8224 and 8225. This may require corrective action across
multiple RFCs, but the OCSP is probably not the right place to start
that.

Chris Wendt presented draft-wendt-stir-certificate-transparency. The
draft currently says that certificats MUST include SCT. The group
discussed whether this could be deployed incrementally as opposed to a
flag day. Chris wants verification to fail if an issuer uses SCT but it
is not seen at verification. The discussion did not resolve; interested
parties plan to have an informal offline discussion.

VESPER

Chris Wendt presented draft-wendt-stir-vesper. The draft allows a
Vetting Authority to sign a token to authenticate rich caller
information (AKA "Know your Customer" information). Callers can then use
selective disclosure JWTs to disclose a subset of the vetted information
for a specific call. The group discussed whether this disclosure would
change per-call and whether the information belonged in a separate token
or the certificate used to sign the information (which can be different
than certificate used to sign a PASSporT). People reacted generally
favorably, but some asked for a more detailed framework about how VESPER
would overlay with the ecosystem. More work is needed prior to
considering VESPER as a potential workgroup item. (Chair note: We would
need to discuss whether VESPER would fit into the existing STIR
charter.)

Call-Info

Chris Wendt gave an update on draft-ietf-sipcore-callinfo-rcd. This is a
SIPCORE document, but it is of interest to STIR because it is a
normative dependency for draft-ietf-stir-rcd. The draft is post-WGLC,
but contains material changes to include RCD verification status and
digests over referenced content. SIPCORE plans to repeat the WGLC; STIR
participants are encouraged to participate.

Raw Notes

1) Administrivia
- Note Well
- Agenda Bashing
- Minute Taker: Jonathan Lennox
- Jabber Scribe: Chairs
- Bluesheets - Meetecho tool

Jon Peterson:
Update on draft-ietf-stir-oob-servprovider (with the IESG) and
draft-ietf-stir-4916-update (PubReq)

For oob-servprovider: dowref to 8816 (REST interface), need to specify
what is mandatory to support, but could support other mechanisms as well

Orie Steele (responsible AD): want to make sure that there's enough
there in 8816 for implementors to reliably implement. Or pull material
in from 8816.

Jon: If we make that change, is that close enough to what the WG decided
on, or would we need a fresh WGLC?

Orie/Russ: We'd need to see the change, but probably.

Robert Sparks: You're putting more effort into this than it really
needs. Just go.

Orie: You think the existing ref is good enough, wouldn't cause any
implementation issues?

Jon: It's pretty brain-dead REST, we're not doing anything fancy here.

Robert: I don't object to doing the work, but we have finite cycles, I'm
not sure if it's worth it.

Orie: Bring it to the group; if that's the position of the wider group,
I'm fine with it.

Action item: Bring to the list the idea of not doing anything, make sure
that's okay.

2) Certificates

• draft-ietf-stir-certificates-ocsp-08
• draft-ietf-stir-certificates-shortlived-00
  • Jon Peterson

For shortlived: x5c is not a MUST. Should it be?

Jonathan Rosenberg: I don't see a problem with having it at MUST for
this document, it only applies to implementations implementing this
document.

Jon: x5u can provide value for short-lived even without x5u.

Chris Wendt: You're talking about MUST for a verification service?
Jon: No, for an authentication service - MUST use.
Chris: I'm good with that

Alec Fenichel: For x5c, we should drop root cert from the chain, they
need to already have it in order to trust it, we want to keep things
small.

Jon: That's probably reasonable, the root cert is big.

Jon: We just copied this from 7519, does anyone know why 7519 had the
root? We should probably ask its authors.

Chris: I thought it was general practice that you could have the root,
or not.

Jon: [ACTION ITEM] Let's take an action to check with JOSE people to
make sure we're not missing something.

JDR: Did we conclude on MUST/SHOULD for x5c?

Jon: Specifically, should this draft say that an AS MUST use x5c for
authentication serice for short-lived certs?

Subir Das: Does that imply changes for Shaken?

Jon: If they want to be compliant for this spec.

Chris: This only applies for delegate certs, not baseline Shaken.

Poll of the room: 8 YES, 1 NO

Pierce Gorman: I said NO because it wasn't clear it wasn't a MUST for
Shaken. If it isn't a MUST for Shaken, I'm willing to say yes.

Jon: Why shouldn't it be a MUST for Shaken?

Pierce: You'll end up with uninteroperable implementations, with no way
to clean it up.

Jon: Would it be better to say you MAY also have x5u if someone can't
parse x5c?

Alec: It's not clear to me how this impacts Shaken. There would be an
advantage if people could use x5c today, but it's not clear how this
impacts interop. The current documents don't reference this, so it
doesn't immediately change Shaken.

Alec: For short-lived CERT, you'd probably want x5c, for long-lived,
x5u.

Jon: The division between those is Shaken's problem.

Chris: This is a specifically separate tool for your toolbag. Just
because an x5u has a short lifetime doesn't mean you're using this
mechanism.

Chris: In JWT can you have x5c and x5u at the same time?

Jon: I don't recall anything saying you couldn't, but we should check.
Not clear what happens if they disagree.

JDR: If the AS doesn't know if the VS supports this, you MUST always
include the x5u as well as the x5c for backward compatibility.

Jon: That would be a change from what we have now. The alternative is
verification fails for being unsupported. Could happen even for x5u if
you don't support a certificate chain.

Jon: It sounds like we need MUST for both x5c and x5u. And we need to do
some study of 7519. [ACTION ITEM]

Alec: I think in many deployments the intermediate will be wasted bytes
too, it would be nice you could have an embedded end cert and a
reference intermediate. The intermediate will be long-lived, it seems
silly to put it in millions of passports.

Jon: Whose job is it in Shaken for you to know who the intermediates
are?

Alec: You don't pre-have the intermediates; the x5u is the chain without
the root, the x5c is the end certificate only.

Ben Campbell: It sounds like you're doing engineering at the mic, better
to take this offline, I'm closing the queue

Jon: Russ, explain how root chains work to me?

Russ: As long as they don't have the same public key, you're fine.

Russ: The x5c and the x5u MUST have the same leaf, but there can be
multiple paths to a root.

Jon: I think OSCP is good to go, need another spin on shortlived. Note
that the OCSP still uses a ".cer" extension in the example, which is not
an appropriate extension for PEM certificates. But RFCs 8224 and 8225
use ".cer", and this document may not be the right place to fix that.

• draft-wendt-stir-certificate-transparency-03
  • Chris Wendt

Russ: What do you use from 9162? No one implements 9162 in the web PKI.
They use 6962, no one uses version 2.

Chris: That's fine.

Jon Peterson: This seems like a good idea, especially as we have more
intermediate certs. I'm interested in monitors, and the TN collision
problem. I can see cases of people depolying certs for multiple carries
for the same number. How do you see the role of the monitor in
mitigating this?

Chris: I don't want to prevent that, the onus is on the one who cares
about the telephone number to know, if they see a new cert for a TN, if
it's one they originated.

JDR: I made comments to the list as to how you would deploy this
incrementally, the document as written requires at MUST the inclusion of
the SCT, so there's a backward compatibility problem, you need a flag
day.

Chris: The intent of the MUST is that if I'm creating certs with an SCT,
I want all verification services to fail if one isn't present.

JDR: But how do you communicate that fact securely?

Chris: It could be part of the ecosystem.

Rob: The purpose of adding the SCT to the cert is to get the SCT, you
wouldn't go the log to get it. For backward compatibility, an updated
verifier will pay attention to the SCT.

JDR: It sounds like having it in the cert is just an optimization?

Chris: The log is only meant to be verification, not to be referenced
per-call.

Alec: The log isn't fast enough.

Alec: Roll-out is hard, Chrome just said "if your cert doesn't have SCT
by this day, it won't be trusted."

JDR: The verifier gets an SCT from the log if it isn't in the cert?

Alec: The logs are used by the monitor only, not the verification
serivce.

Alec: I think there's an issue with the SCT: there could be multiple
certs in the chain that use transparency, you need multiple SCTs per
passport. CT can be used for certs other than the end entity. I don't
know how to solve this problem, but we need to solve it.

Jon: Suggest we have a call about this.

Ben: An informal side meeting?

Jon: Sure

Chris: It's a complex topic so more discussion is always good.

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

(Vesper is the preferred martini of James Bond.)

Selective disclosure tokens for STIR

Jon: I've felt like we need this, selective disclosure is cool. Know
your customer is a thing that's arisen on top of STIR/Shaken. But this
isn't information about the call, it's information about the entity
behind the call - I was always envisioning this would be in the cert,
not in the passport.

Chris: I started in the same place, but ultimitely the jwt is a
framework

Chris: this is included per-call, but not created per-call.

Jon: If it were created per-call the case for putting it in the jwt is
stronger. This seems more like things that are checked when a cert is
issued.

Chris: The certs signing passports are different from the certs that
verify vesper info.

Rob Sliwa: The main idea about the Vesper token is a standard way to
share KYC/KYB information. SD-JWT has nice properties of
issuer/holder/verifier.

Chris: You may want to use selective disclosure to disclose different
information per call.

Jon: I think the requirements about whether it's different on a per-call
basis can help determine where the right place to do it is. There is SD
in X.509 certs too. This needs more list discussion. For intermediate
certs I want the opinion of the issuer of the cert about KYC issues.

JDR: This is missing a framework about we overlay it on the real world.
How many actors are there? Who are they? What decisions do they make?
I.e., what are we trying to solve?

Chris: I think there's a little more than what you said, but I agree
more needs to be added.

Pierce Gorman: +1 JDR and to Jon Peterson, you want to use it at call
time but you don't want to generate it then. Reference the W3C
verifiable credentials work. But I like that you're working on this.

Chris: We want to align ourselves with other working groups.

4) Update on RCD in CallInfo (Update from SIPCORE if time permits)
- draft-ietf-sipcore-callinfo-rcd-11

Jean Mahoney (SIPCORE co-chair): We've had technical updates to this, we
need another WGLC, are there further updates?

Chris: No

Jean: So we can do another WGLC.

5) Any Other Business (if time permits)