COSE IETF 123

Connection details

• Date and time: July 21, 2025 - 17:00-19:00
• Chat: https://zulip.ietf.org/#narrow/channel/9-cose/topic/ietf-123/
• Meeting materials:
  https://datatracker.ietf.org/meeting/123/session/cose
• Meeting URL:
  https://meetings.conf.meetecho.com/ietf123/?session=34239
• Recording URL: https://youtu.be/NX4g4oUJFPw?si=2GUsNxPdnKnDl-cU&t=21

Action Items

• SS: Write a paragraph for HPKE
• HT et al: update HPKE draft from the feedback.
• chairs: HPKE second WGLC after the update
• GS et al: Publish a new version of c509 and then chairs to follow up
  with shepherd review and request for publication
• Renzo Navas, Marco Tiloca, Robert Moskowitz (remote), maybe Quynh
  Dang, John Mattsson: review and provide feedback for Ascon-AEAD128
  draft
• CA, SF, SS: Review Split Signing Algorithms
• CA: Follow up on the idea of not providing new algorithm
  ideantifiers

Minutes

• Jabber scribe:
• Minutes taken by: Marco Tiloca, Hannes Tschofenig

[15 min] Opening Remarks - The Chairs

Presentation slides

IP doing introduction; overview of document status

HB: On -tsa-tst-header-parameter, the rechartering should have been
completed. I understood that the draft would have been re-entered where
it was stopped.
MJ: No, you start over.
PW: We don't have to start over necessarily.I am checking with Roman.
Nothing changed in this document since we stopped it.
HB: Actually, it did change as to the comments received during the
previous Last Call.
PW (on chat): to clarify: It will go back on to an IESG telechat, just
not doing another IETF Last Call.

MJ: There are no normative changes to the BBS+ draft.

IP: Still interest in sphincs-plus? If yes, we need new editors.

HT raised his hand.

HT: Sphincs-plus is useful for software update with SUIT.
QD: I'd be interested to help editors with technical review. Happy to
help.

SS: Falcon is hard to implement in constant-time, we should reconsider
if we need it.

SF: This is not going to be compatible with what NIST would eventually
do. I would hold on.
JPM: We should work on this. As soon as NIST publishes Falcon, this
should progress. It shouldn't need so much detailed work on the format
in COSE.

Hannes: Is your comment also applicable to Sphincs-plus ?
Sophie: No.

QD: Draft will be published in the very near future. Draft will contain
a lot of technical details and the issue of constant time
implementation. There will be many important things to key generation. I
encourage anyone to look at the draft when it comes out.

Poll: "Who would like to see the Sphincs-plus document be finished?" 17
persons say "yes" and 11 persons say "no opinion"
(Fixed considering: MO (on chat): Minute-takers: I would change my vote
for SLH-DSA from "No Opinion" to "Yes" :P)

Poll: "Who would like to see the Falcon document be finished?" 15
persons say "yes", 2 persons say "no", and 17 persons say "no opinion"
SS: Falcon is not ready for deployment at this point (implementation
concerns).

MO: Out of personal curiosity, what are the uses for SLH-DSA in COSE?
HT: We had HSS-LMS, it's good but with limitations, some of which are
addressed. Negative characteristics in terms of size are traded off by
the size of the firmware that is distributed.
JPM (on chat): Firmware update was mentioned as a COSE use case for
SLH-DSA. NIST is expected to release more optimized parameters in the
future.
SS (on chat): Afaik some firmware signing use cases use cose

RN: I can also help for editing both drafts sphincs-plus and falcon.

[30 min] draft-ietf-cose-hpke - Hannes Tschofenig

Presentation slides

HT presenting

HT: We had a WGLC with a lot of feedback. Some points were addressed in
version -15. There are new issues.
HT (p3): Updates in version -15 on addressed points.
HT (p4): Still open points. Some are clear, some need discussion. No
issue with "fully specified algorithms". No issue with multiple
invocations of HPKE open()/seal() as they are not covered; we will
mention that explicitly.

HT (p6): Some examples have to be re-generated. Other examples have to
be created and added. The code to generate examples is there. Also need
to add an example using COSE_Sign1 to authenticate the sender.

HT (p7): LL is not satisfied with the confidence we have on the security
achieved with Recipient_structure. Detailed explanation of the
different fields in Recipient_structure. Does anyone have any issue, or
what are we waiting for to happen?
LL: On the security of this, I was concerned there was enough review.
But since then, there have been more comments, so I am less concerned
now. I imagined this used somewhere else in COSE, not just in HPKE.
HT: That would be a major change in COSE.
LL: Basically a new COSE algorithm.
HT: More than that, an actual bridging with COSE.
LL: Yes, it's substanstial. Let's not stick on pursuing it.

LL: How does this fit in HPKE? Touching the "info" parameter perturbs
the key generation. That's not the case if you touch the external_aad.

HT: Beyond the LAMPS attack (which is addressed now), I am not aware of
other issues like on Diffie-Hellman. The "info" parameter is there to be
used for providing additional context information.
LL: But HKDE has a lot of HKDF step with mixing.
HT: But, for example, HPKE does not know about things like the identity
of the recipient.
LL: It's really use-case dependent.
HT: Yes.
LL: There was also a comment from IL about not feeding something large
to HPKE, although Recipient_structure might be.
HT: Not sure if it's a concern (will be hashed anyway), and this is a
common construct.

LL: This is working as a layer outside HPKE. It's not really involved
with operations based on public keys. A lot of information becomes less
relevant here. It's probably intrinsic of the way COSE is structured.

SS: You mentioned about not knowing the full context. HPKE can still do
some prefixing. I don't see cross-protocol attacks, but if there's a
separate way to provide information, that should be preferred (so
"context" preferred to external_aad). So this deviates from the best
practice but still does not seem to break anything. I would put it in
the "info" parameter.
HT: LL also thumbs-up. It sounds good.

MJ: SS, please write a paragraph with your proposal to the mailing list.

HT (p8): Do we neeed COSE_MAC here? Do we have a use case? If used, it
would roughly correspond to HPKE with PSK (and it's not that good to
provide the same thing in two ways). Anyone with a use case?
LL: COSE_MAC is not useful here at all. In base mode, there's no secret
on the sender side that the attacker does not know. I second a comment
from IL on the list on a broken part. It's not an issue if you use the
PSK mode. COSE HPKE is an encryption solution and you don't need
COSE_MAC; I'd like it removed.
HT: I think "broken" is incorrect. It's more about not using mechanisms
that you don't want.
LL: COSE_MAC is not useful unless you have something like a shared key.
COSE HPKE does not create that key.
HT: It does. There is an example.
LL: The example in RFC 9052 is ECDH-SS. That's different.
HT: It's a non relevant difference in this context. The question here is
if we have a use case that justifies keeping COSE_MAC in this document.
This is not a bug.
SF: Problem is that the authenticated encryption is not malleable, but a
simple authentication is.
HT: Good argument.

Poll "Do you support retaining the COSE_Mac feature in the draft?": 0
yes, 8 no, 20 no opinion

HT (p9): We'll work on a new version of the draft based on today's
feedback. We'll also update the implementation. I guess we'll need a
second WG Last call.

MJ (as an individual): Moving content to the "info" structure might
affect how things are meant to be consistently done in JOSE (that meets
on Friday).

[15 min] draft-ietf-cose-cbor-encoded-cert - Göran Selander

Presentation slides

GS presenting.

GS (p2): Overview of updates in the latest version.
GS (p3): Changes due to the certificate request template.
GS (p4): ... and on certificates in chains, ...
GS (p5): ... and more on different uses of CBOR encoding ...
GS (p6): ... and on the IANA considerations ...
GS (p7): ... and many editorial fixes
GS (p8): Inputs from WGLC have been processed; there are PRs at
https://github.com/cose-wg/CBOR-certificates

RM: Thanks for the update. I do see any changes required for aviation.

Chairs are planning to proceed the draft once a new version has been
published.

[10 min] Ascon-AEAD128 for JOSE and COSE - Dmytro Ochkas

Presentation slides

DO presenting.

DO (p3): Enabling the use of Ascon-AEAD 128 in COSE. Ascon selected by
NIST as lightweight cryptography. It's potentially an alternative to
other AEAD algorithms currently available for constrained stacks, such
as when using OSCORE.

DO (p4-5): Concrete proposal of what this means in COSE structures.
DO (p6): Related IANA considerations.
DO (p7-8): Available implementations in C and Java, used to produce
examples

DO (p9): It can be easily extended to JOSE; we welcome feedback and
collaborations.

Chairs: Any question?

JPM: Good to add Ascon to COSE once standardized by NIST (it's still a
public draft). We can still work on it in parallel. The lack of KDF in
ASCON is limited. From your tests, do you see any performance benefit,
e.g., compared with HKDF SHA-256?

DO: There were comparisons with HW implementation of AES. Ascon is 25
times more efficient energy-wise, and 5 times more efficient in terms of
throughput.

CA (on chat): Looking forward to using this. As John said: can work on
it already. Ideally, I'd like this to go out of this WG once it is
confirmed that the test vectors from the released NIST don't differ from
the version that the draft was built on.

QD: This is a good item for the group to consider. It's a good option to
use in the future. NIST will finalize it soon.
CA: Thanks for doing this, I like it. As we work in the draft, I also
hope we can work on the (truncated) hash.
DO: We have focused on encryption for now, but nothing stops us to
consider hashes too.
RM (on chat): My connection broke. I am interested in seeing this draft
advanced in the wg.

MJ: Who has read the draft.
(4 hands raised)

MJ: Who plans to read the draft and review and give feedback?
("a lot" of hands raised)

• Renzo Navas
• Marco Tiloca
• Robert Moskowitz (remote)
• (Quynh Dang? John Mattsson?)

[10 min] Split signing algorithms for COSE - Mike Jones

Presentation slides

MJ presenting (as an individual)

MJ (p2): The name appeared to be misleading, so we changed the algorithm
to say "split" signing algorithms.
MJ (p3): Overview of updates since IETF 122.

SF: You are discarding hash ML-DSA in this use case, although it's
exactly the use case for which the hash was designed. I think
certificates can carry the hash.
EL: The use case is valid, that's why we had an example in the draft. We
can put it back in. No strong opinion either way.

SS: Even if it's a strong use case, I don't think there's a strong use
case anyway. Use external Mu.
DC (on chat): What Sophie said. external Mu does exist and is real. by
real I mean FIPS approved
EL: It's not about particular use cases at the moment, more about
algorithms. Our current interest is in ECDSA, and a variant of BBS+.
SS (on chat): Basically, why have two algorithms, when you can have one
algorithm instead?

MJ (p4-5): Motivation for split signing - instead of signing large data
only a hash is signed. Use case: signing with WebAuthn/FIDO2
authenticators.
MJ (p6): Pre-hash modes

SS: On pre-hashing, with RSA you can split, but depending on what you
do, you get different security properties. For the most part the two
alternatives produce the same results but with RSA there are different
security properties - it is not clear whether anyone cares about these
security properites.
SF: That was a bad idea with Falcon.

MJ (p7): New algorithm identifiers.
MJ (p8): There are algorithms that are incompatible with this approach.
They cannot be used.
MJ (p9-10): New algorithms proposed in the draft (ECDSA-based or
EdDSA-based)
MJ (p11): A new structure COSE_Sign_Args can be used by the digester
to instruct the signer on parameters to use when signing.
MJ (p12-13): Showing examples
CA (on chat): Reiterating from last time: If we introduce a channel to
convey extra parameters, I don't quite see why we create new
registrations of numbers -- we could just use the same numbes, and the
presence of an (even empty) "things you need to know when doing a split
hash" clues things off.
SS (on chat): For Falcon, when I say I'm pretty sure there is a key
recovery attack, I mean, I think there is, but my attempt at actually
reducing the lattice failed

MJ: Who is willing to review?

SF, SS, and CA (on chat): Willing to review, pester me if I don't.
MO (on chat): Hand up for helping Mike Jones with this draft.

MJen: Re-asking since IETF 122. I read the previous version, not this
latest one. This document explains from the signer's point of view, but
not from the verifier. How is the verifier sure that the signer did not
lie? The checked data is always the same, irrespective of doing that in
one or multiple parts.
MJ: Intentionally.
MJen: How can I be sure that what happened is what is claimed?
EL: You can't distinguish.
MO (on chat): You should not be able to tell the difference between "I
streamed the whole cat video to my HSM" and "CAPI pre-hashed it first".
This is "implementation detail" of the internals of the signer.
MJ: Flipping phrases doesn't matter because the verified checks input
data and signatures and then, in case of success, proceeds with whatever
the data was meant for. What exactly happened does not matter.
DKG (on chat): why do i care as a verifier how many steps were used?
MJen: I'll review.
SS: It's multi-party computation with two trusted parties, where one
holds a private key, and there's prevention of leakage of the private
key.
JH (on chat): The Digester and the channel between the Digester and
Signer must be trusted.
SS (on chat): Yes, that's why forgery attacks do not matter, but key
recovery attacks do
AC (on chat): Is there a construction that would enable a verifier to
check in how many steps the computation was done? It doesn't seem like
there is?
SS (on chat): That's why I dislike hash ML-DSA. The fact that there are
multiple steps and the verifier can tell
JB: You can tell what algorithm was used but nothing about the signature

CA: This document can be made simpler by not introducing new algorithms
on instructing the signer, but just relying on additional parameters for
that.
EL: So the presence of the Sign structure is enough?
CA: Yes.
EL: It would not work for our use case, where we want to have algorithm
negotiation and offer both split-signing and signing in one step.
CA: Let's take that on the mailing list, I don't see how the interface
could not be enhanced to avoid doubling the algorithm registrations.

MJ: We'll integrate this feedback in the draft.

[40 min] AOB

(no points raised)

Appendix

Abbreviations for participants