JOSE Working Group @ IETF 124

Wednesday, 5 November 2025
9:30 - 11:30 EST (UTC -5)
St Denis

Notes: https://notes.ietf.org/notes-ietf-124-jose

Please check https://datatracker.ietf.org/meeting/124/agenda for an
updated link to the meetecho session.

Draft Agenda

1. Admin, Agenda Bash, document status (Chairs, 5 min)

Minute taker: Mike Ounsworth

Working Group Documents

1. Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and
   COSE (Reddy (virtual), 10 min)
   https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/

Filip Skokan: Is slide 4 effectively the same thing as slide 3? i.e.
"alg" is required?

Tiru's audio is unintelligible.

Brian Campbell: Slide 4 is really the same as 3, except that the AEAD is
tied directly, so it's only different if you think of it as different.

Hannes: rather than going to solutions, maybe we should go back to the
design problem that we are trying to solve. For example, didn't we
decide a while ago that all sorts of bad security things happen if you
carry around the algorithm name? Shouldn't the client be able to decide
the set of algorithm that a given key can be used with?

Karen [Chair]: Can we please take this discussion to the List?

1. JSON Web Proof Drafts (Jones/Waite (virtual), 20 min)

   JSON Web Proofs
   https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
   JSON Proof Algorithms
   https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-algorithms/

   JSON Proof Token
   https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-token/

MikeO: point of clarification: To the point that this draft is at the
top of the stack with the CFRG Pairing-Friendly Curves at the bottom, is
this draft actually the top of the stack, or are other things waiting
for this draft?

MikeJones: Yes, this is not the top of the stack.

Leif: Mentioned a side-meeting earlier this week and SECDISPATCH
indicates that there is interest in working on ZKP schemes such as
Longfellow which operates on an unmodified MDOC in CBOR.
https://google.github.io/longfellow-zk/
https://github.com/abetterinternet/zk-cred-longfellow

Stefan Santesson: it turns out that you can make Longfellow much simpler
if you don't use any of the features of SD-JWT and just do it directly.

John Preuß Mattsson: this builds on top of elliptic curves. What about
PQC? Is there a plan for a PQ-safe version of this?

Leif: It's complex. A lot of the ZK schemes have perfect forward
properties that even a quantum computer can't break old things
backwards, but can still be forged forward. Of course these things will
need PQ equivalents, but this is still basic research and PQ ZK's don't
exist yet, so we don't really have a choice. But we might end up in a
place that we have to deploy ECC-based ZK because the alternative for
national MDOC systems would require so many cloud signatures that it
just won't scale for performance reasons.

John Bradley: I agree with Leif. There is a lot of pressure for both
performance and privacy reasons to implement something in this space. No
one ZK system has it all. If there are good reasons why these
pairing-based systems should not be used, then we should have that
debate, but I have not seen anything truely disquieting.

Deb [individual]: I see this as a progression to get better and better
procotols for selective disclosure. Don't let Perfect be the enemy of
Good. Don't leave people exposed while the standards community waits for
something better. Something standardized, even if it gets replaced
eventually, is better than delay. I could also make this comment with my
AD hat on, if necessary.

Leif: +1 to Deb.

Karen: due to time constraints, any open questions go to the List,
please.

1. Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing
   and Encryption (JOSE) (25 min)
   https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/
   Two presentations: Mike Jones, Brian Campbell

Mike Jones presenting.

MikeO: Clarifying question because I have not read the draft: HPKE is a
one-shot API -- ie crypto and content encryption are combined. Does
adding HPKE to JOSE / COSE mean that we can no longer do multiple
reciepients (ie encrypt the bulk content once for multiple recipients)?

Mike Jones: Great clarifying question. The draft specifies two modes:
the single-recipient "one-shot" mode, and also a mode where HPKE is used
to encrypt the content encryption key, and this supports multiple
recipients.

Brian Campbell presenting.
I gave feedback at 123 that I don't feel was acted upon or taken
seriously. I am here to reiterate this.

Karen: I think a side meeting to get everyone into the same room talking
as humans would be helpful. Let's go do the queue, but please focus on
the way forward, not on the history.

Hannes: 1) We are updating RFC 7516 semantics in the draft with the
appropriate close (see first page - header). 2) We can change the
semantics of the alg field.

Mike Jones: the reason that we retained enc is that there is protocol
implementation history that presense of the enc header indicates the
difference between a JWS and a JWE. I'm not saying that has to be that
way, but just saying that the authors were trying not to break that.

Deb [AD]: It's not a "Side Meeting", we're doing to call it a Design
Team. Process words matter.

1. JOSE: Deprecate 'none' and 'RSA1_5' (Madden, 10 min)
   https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/

MikeJones: the problem that I have with the current text about None is
that it lists 9 ways that None was used illegitimately, but it does not
list the 2 legitimate uses of None. I find it problematic and an
unbalanced view of the situation on the ground by only listing the
illegitimate uses and not the legitimate ones.

Neil: I believed that people had responded to that on the list and
consensus was to not add it.

MJ: I believe that there were few-to-no responses to my Sept comment
on-list.

Brian: I think the text is already well-written and even-handed. I do
not agree with expanding the text to legitimize something that was a bad
idea.

Individual Submissions

1. PQ/T Hybrid Composite Signatures for JOSE and COSE (Prabel, 10 min)

   https://datatracker.ietf.org/doc/draft-prabel-jose-pq-composite-sigs/

Deb [invididual]: What's the usecase for signatures for JOSE? Signing
firmware, authentication?

MikeO: brought up OIDC

Brian: OIDC assumes that you can and will rotate IdP signing keys
frequently.

MikeO: I am certainly aware of uses of JWS where the root keys are
embedded in stuff and can't be easily rotated.

MikeJones: It's all over the map and there are certainly things with
long-lived roots.

Deb [individual]: I suggest that before running to Composites, we
should consider whether the use cases for JWS ecosystems that we
support. Possibly, long lived root structures could be stood up one for
multiple algorithm technologies. When it comes time to deploy one could
shut down vulnerable options. would be equally well-served by making two
root keys. My issue with Composites is not that it's necessarily hard to
implement, but that it's hard to maintain -- lots of algorithms that
will need to be supported in libraries, applications, etc etc. I worry
about the maintenance tail.

Lucas: Some governments do want hybrid security everywhere.

Jonathan Hammell: Multiple signatures are already supported in COSE
(COSE_Sign). Doesn't force both to be used, like composites, though.

John Bradley: my fear is that if we don't standardize these, then people
will go around us either with custom mechanisms, or just not use JOSE at
all.

John Preuß Mattsson: +1 to what Deb is saying. And if we should do
composites anywhere in IETF lets not do these composites that are
garantueed to decrease the security properties of ML-DSA (minute-taker:
this is a comment on the lack of SUF security properties on this
specific composite signature construction).

Michael P: Agree with Deb and others in this chat. Also one of the
motivates stated in the slides was to align with other parts of IETF but
TLS, for example, have not decided how to do hybrid authentication

1. Public Key Derived HMAC for JOSE (Santesson, 10 min)
   https://datatracker.ietf.org/doc/draft-bastian-jose-pkdh/

Clarification at mic / chat: this is authenticated due to static-static
ECDH.

Paul Bastian: The spec does not require Static-Static, it could equally
be Ephemeral-Static or Ephemeral-Ephemeral.

Hannes: but in the case where there are ephemeral keys, then you don't
necessarily get authentication, or you don't get it with the security
properties that you expect. So you have to be very careful.

MikeO: +1 Hannes

Emil Lundberg: "Derive basic config from name?" - my impression has been
things are moving away from parsable alg identifiers, in favour of
instead looking up fully-specified algs (a la RFC 9864) in a registry,
to prevent malicious or accidental bad combinations of algorithms

From DISPATCH

1. Data At Rest Envelope (DARE) (Hallambaker, 10 min)
   https://datatracker.ietf.org/doc/draft-hallambaker-dare/

2. Encrypted Authenticated Resource Locator (Hallambaker, 10 min)
   https://datatracker.ietf.org/doc/draft-hallambaker-earl/

3. AOB