COSE IETF 125

Connection details

Decisions and Action Items

Minutes

[15 min] Opening Remarks - The Chairs

Presentation slides

Mike presents the slides.

[05 min] draft-ietf-cose-c509-test-vectors - Göran Selander

[10 min] draft-ietf-cose-falcon and draft-ietf-cose-sphincs-plus - Hannes Tschofenig

Presentation slides

Orie Steele (in the chat): don't register things unless someone says
they need it.

Mike Jones: NIST SLH-DSA specification is finalized, but still
waiting for FN-DSA? Answers from the WG: Yes.

Carsten Bormann: I support option 2. When we decided to not use
polymorphic identifiers, we essentially decided for a combinatory
explosion. We should not put fluf there.

Scott Fluhrer: not sure how common support for HashSLH-DSA there
will be in crypto modules. ...

Filip Skokan: good not to register too many algos. Not sure about
the general applicability of SLH-DSA compared to ML-DSA/FN-DSA. Is it
supposed to become a general signature, or only for specific use cases?
Hannes: SLH-DSA is good contender for securing firmware updates, and
not a generic signature scheme. For FN-DSA, it's more a backup choice.

Tiru: regarding SLH-DSA uses, confidence in the security of ML-DSA
is lower, and pure ML-DSA has some non repudiation issues. Hannes:
... We could reference the stateful guidance drafts. Tiru:
HashSLH-DSA doesn't seem popular in the LAMPS WG, nor in IPSecME.

John GRAY: for SLH-DSA, the choice of the variants depends on the
use case. Agree with Tiru regarding ML-DSA.

Interest in the chat about smaller signatures for SLH-DSA

Poll 1: Add HashSLH-DSA to the draft?
Yes: 7
No: 14
No Opinion: 19

Carsten: We shouldn't be using this as a vote. Even if more people
don't want it, it may be useful for some. Mike: I'm basing
conclusions on previous concensus, and this poll is to understand
whether we should expand the scope. If there is reason to use it, then
bring it to the list.

Poll 2: Take draft-ietf-cose-sphincs-plus (SLH-DSA) to WGLC?
Yes: 14
No: 3
No Opinion: 16

John GRAY: just based on the small parameter sets coming, maybe we
could do it in a different draft and I would change my opinion. Could we
just wait for those smaller parameters? Scott FLUHRER: Those
parameters are very early in the process, NIST may even change their
mind so we shouldn't wait or endorse here.

John Mattsson (in chat): Smaller is at least a year away and likely
more. Make a second draft. Tiru (in chat): Yes, keep it separate; no
need to stall this one.

Mike: we may be preparing for a WGLC (for the SLH-DSA document).

[15 min] draft-ietf-cose-hpke - Mike Jones

Presentation slides

[10 min] draft-reddy-cose-jose-pqc-hybrid-hpke - Tirumal Reddy

Will not be presented based on JOSE discussion. Will be a small design
team to figure out the best way forward.

[15 min] draft-lundberg-cose-two-party-signing-algs - Mike Jones

Presentation slides

Emil Lundberg (in chat): Caveat on "there are no more TBDs": There
are actually a couple of new TBDs that came in with the import of the
alg IDs from the ARKG draft.

[10 min] draft-lemmons-cose-composite-claims - Chris Lemmons

Never requested for this IETF, Ivo's mistake.

[10 min] draft-ochkas-cose-ascon - Alexander Pelov

Not presented. Probably a miscommunication.

[10 min] draft-sipos-cose-cmac - Brian Sipos

Presentation slides

John Mattsson: just register CMAC and save deprecating CBC-MAC to
another draft. Carsten Bormann and Adam Wiethuechter agreed in
the chat.

Russ Housley (in the chat): I support adding AES-CMAC.+1's from
Carsten Borman and Adam Wiethuechter.

Scott Fluhrer: Given the choice between CMAC and CBC-MAC, I would
always go with CMAC. CBC-MAC has weaknesses that can result in forgery
in some situations. That may not apply to COSE, but it doesn't matter.

Mike Jones: who has read the draft?
No one answered in the room. John Mattsson said (on the chat) he read
in. Russ Housley and John Gray agreed to read it.

[20 min] AOB

Appendix

Abbreviations for participants