Minutes interim-2025-lamps-01: Wed 17:00
minutes-interim-2025-lamps-01-202501081700-00

LAMPS Virtual Interim -- 8 Jan 2025 at 12:00 EST

0) Minute Taker and Bluesheets

Note taking: John and Michael.

1) Agenda Bash

No updates to agenda.
We are going over things we didn't get to at IETF121 (Dublin)

2) Special Topic: EUF-CMA for CMS SignedData
a) draft-vangeest-lamps-cms-euf-cma-signeddata (Daniel, Falko)

Russ: wouldn't it be better to write a BCP saying, "Going forward always
include SignedAttributes"
Daniel: does not support existing protocols...
Daniel: 4.2: ALways or Never, and we can make it Always.
Russ: I would personally advocate for Always, we'll see what others say.

Deb: What existing protocols can't use context strings?
Russ: We would have to update RFC for Ed448 to use the context string.

Russ: if we ALWAYS do SignedAttributes, then we don't need to do the
context string. It's always do SignedAttributes, or always have a
context string.

Michael (MCR): asks about impact to old stored messages (emails,
firmware, etc)
Discussion suggests that it might be possible, but unlikely that you'd
get a hash collision while still getting the rest of the structure to
parse correct. Attacks where the attacker can choose the message are
more likely.

Mike O: Are there practical attacks in the wild right now?
Russ: We don't know.

(the presentation on Root CA rekeying could not be made due to
connectivity issues, and is at the end)

3) Recently adopted or Under consideration for adoption
b) draft-harvey-cfrg-mtl-mode (John)

MCR asked about how this works for OCSP Stapling.
(MCR is unclear if he understood the answer)

Russ: this protocol is being discussed in CFRG, and the new use is
applying it to OCSP.
John: there are some additional conderations involving batch size that
need to be considered.

Rich Salz: there are some IPR declarations, can you link to them?
(They are linked in the presentation: 6174, 6176, 6501)

Alicja Kario: what are we optimizing for? The server generating the
signatures, or the client who is verifying?
John: yes, for the server doing the signing, but also for clients that
may have already cached the top-key.

Alicja: suggests that this is inefficient/does-not-scale when the client
needs to tell the server what it has cached. (Some discussion)

Russ: The hackathon can prove or disprove whether the performance gains
can be achieved in practice.

c)  draft-lamps-okubu-certdiscovery (John)  _Related Certificate Descriptor_

John is asking for adoption.

Russ: A potential con is that the both certificates have to exist.
Russ: But this makes it clear that the pair of certificates is intended
by the CA, which is a plus.

No objection to adoption.

d)  draft-lamps-bonnell-keyusage-crl-validation (Corey)

Corey is asking for adoption.

No objection.

e)  draft-ietf-lamps-automation-keyusages (Hendrik)

Early allocation requests, and no objection.

f)  draft-davidben-x509-alg-none (David)

David: Is this a joke? maybe not.
Russ: What is a KEM trust anchor?
David: explanation about how webrtc uses this... someone needed a
wrapper for a public key, and a certificate worked, but could have used
SubjectPublicKeyInfo.
SeanTurner: going to obsolete RFC5272, so the patient is on the table,
so let's do it now.
Alicja Kario: if we talk about things that consume the trust anchors,
and they do have the anchors distributed with them, and they are not
sent on the wire. Trust anchors stores already do not require
certificates, so there is no benefit to having that self-signed
signature. It seems like it only applies to end-users adding a new trust
anchors.
David: not true that only browser has trust anchor stores, many things
do. Preconfigured in the relying party, and we do not need to have a new
format.
David: "don't implement me"
Jonathan Lennox: wrote a document how to do webrtc with (made-up)
self-signed keys, so implemented this document, and it just worked,
since the signatures are irrelevant. Everyone uses EcDSA today, so it's
smallish, but when we go to Quantum-Safe algorithms, they will be too
big.

No objection to call for adoption.

g)  draft-sun-lamps-hybrid-scheme (Shuzhou)

MikeO: the tombstone notice has the problem that one has to transmit
both keys, and this draft attempts to solve this with a layer of
indirection. Another I-D exists (external public keys), and invitations
were extended to merge.
MikeO: the other problem is that these Truskovsky extensions are very
hard to use. It's very unclear if one should sign with the primary key
or the alt key? CMS... multiple signer infos? The point is backwards
compatibility, old clients will ignore it, and Truskovksy extensions
accomplish that for 5280 path validation, but to use it in protocols
requires new extensions to these protocols, which for most protocols
defeats the purpose. I don't think this new draft addresses those
concerns with draft-truskovksy.

Russ: Next step is for the author to try to address the objections, or
abandon the draft.

a)  draft-wang-lamps-root-ca-cert-rekeying (Guilin)

No comments.
Presenter asks for further review and comments for IETF122.

4) If time allows
a) draft-ietf-lamps-pq-composite-{kem,sigs} (Mike, John)

Russ: question about M' prefix.
MikeO: comments about if nobody in HPKE cares about FIPS --- someone
would have to convince me.
Discussion about how to get this document to last call....

5) Wrap up