JOSE Working Group @ IETF 126

Tuesday 21 July 2026
14:00-16:00 CEST (UTC +2)
Park Suite 7

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

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

Draft Agenda

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

Call for note takers.
Note well
Agenda Bash: BBS document will be done third due to a conflict

1. Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption
   (JWE)
   https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/

HPKE + JWE document in 2nd WGLC after went through IESG. Limited to just
scope of removing two algorithms. No oppositions on mailing list so want
to close WGLC today.

1. JOSE: Deprecate 'none' and 'RSA1_5'
   https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/

JOSE: Deprecate none also in WGLC. After extension of WGLC, no
opposition and some positive responses. Will do a poll to verify there
is no opposition. Would be nice to have more responses/reviews to WGLC.

"I support publication of JOSE Deprecate None"
27 yes, 0 no, 8 no opinion

1. BBS and Modular Sub-proofs with JSON Web Proofs (Christian Bormann)

   https://datatracker.ietf.org/doc/draft-bormann-jwp-modular-bbs/
   [Taken early]

Is there workgroup interest?

Brent Zundel:
Likes it, mentioned on list. Would like to see it happen and makes sense
that it happens in this WG.

Frederik Jaconseb:
Also likes, it. Some sub proofs could be removed and have one with
framework and another with the subproofs.

Christian Bormann: Agree, can move the sub proofs elsewhere. This draft
should register with IANA.

Philip Hallam-Baker: like the draft, allow to do interesting stuff with
PQC without being on the critical path.

Paul Bastian:
Great work, important. A ZKP will be more likely adopted in restricted
spaces as alternative to Longfellow is a good idea.

John Bradley:
Read the draft, working on implementations. Good for working group to
take this up.

Orie Steele:
Like it. BBS layer, what is the modularity of the front part?

Christian Bormann: Front part works for any proof system that can do
committed output. Should work with LaZer (from IBM
https://eprint.iacr.org/2024/1846). Some of the circuit based proofs
would be difficult, output not in appropriate form.

Karen (Chair):
No opposition to adoption. Can start call for adoption.

1. JOSE HPKE PQ & PQ/T Algorithm Registrations
   https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-pq-pqt/
   Presented by Filip Skokan

Tirumaleswar Reddy K: x25519-mlkem768 should be the recommended cipher
suite, like TLS.

Filip: IANA registry table, have many ciphers as optional. At some point
will expect to update. But can recommend some cipher suites. Will be up
to WG.

Quynh Dang: From NIST, general security recommendation is to use
strongest cipher that has reasonable performance. MLKEM512 is level 1,
and confident in its security. On hashes, happy with SHA2 and SHA3

Filip: Is this a request to include MLKEM512? Does anyone need it?

Sophie Schmieg: I believe that at the moment nobody can break mlkem512
at the moment but I don't recommend to use it and not put it in the
draft unless we have a usecase.

Filip: It remains in COSE part because they target contrained devices,
but we don't have signal to include in JOSE.

Brian Campbell: Is there a compelling reason to use SHAKE other than it
is newer vs availability? Is this not the problem with browser support?

Filip: All ciphersuites internally use SHA3. Users should not have any
problems of support. SHAKE256 can be inconvenient, but it is possible to
use it for key derivation.

Brian Campbell: Do you find it odd that we are aligning with naming
scheme with in COSE.

Filip: If there is a need for 512, can be included. We can pick up
naming in COSE.

Brian Campbell: On to cha-cha. Big push to trim down algorithm list.
Would like a discussion on cha-cha. We removed from this document
intentionally. I think that it's odd for base HPKE document to use
cha-cha AEAD, while this doesn't. I would like us to have overarching
viewpoint from the WG.

Deb Cooley: TLS did recommend MLKEM786-x25519, could consider following
this as well. They also added notes on choice of random sources is
important, see NIST guidelines.

Filip: Additions can go in HPKE spec that we depend on.

Deb Cooley: On cha-cha, I understand the drive for consistency. What I
expect as time moves on is that JOSE HPKE draft may fall away, expect
this to be the driving standard, so you'll be back to consistent state.
If JOSE WG decides to have cha-cha as an AEAD as a fall back then you
can decide to

Brian Campbell: Vastly underestimates how long registry entries last and
impact on community.

Deb Cooley: Registry entries can be changed.

Brian Campbell: Hard to get review through.

Deb Cooley: Not my fault. I think it's ok, you just haven't used
Cha-cha. Is there a performance reason to include MLKEM512? If not,
don't include it.

Orie Steele: On recommended or not, if that's a big discussion we can go
back and fix it. If the goal is to get PQ algorithms deployed, best to
do these fixes in a separate document.

Karen (chair): Ask for more comments on mailing list, ideally want a
WGLC in September.

1. Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) COSE
   https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/

Will remove JOSE aspects and move it to the COSE working group. To be
presented on Thursday.

1. PQ/T Hybrid Composite Signatures for JOSE and COSE
   https://datatracker.ietf.org/doc/draft-ietf-jose-pq-composite-sigs/

Lucas Prabel presents

Filip Skokan: I did an implementation of this, it's realy simple without
ASN.1. I don't think it will be too much work to go to ASN.1, but either
choice will make people unhappy. Overall I don't care.

Andrei Popov: Already have an implementation of LAMPS format. Composite
is an atomic entity, we want to discourage people taking things apart.
Would prefer what is in LAMPS, fewer reimplementation bugs.

Filip Skokan: Understand we don't want people to decompose ASN.1 but we
already have that.

Michael P: Pure ML-DSA was recently published and did not have ASN.1, so
would prefer not to do DER encoding to have consistency.

John Bradley: Microsoft has implmeneted ML-DSA65 + P384 and would like
that registered in this draft. If not, should explain if/why it is a bad
idea and why it is not being registered. Hybrid sceptical myself. Has
seen criticisms of how combining things, is there a rebuttal to
potential reduction in security?

Lucas Prabel: Good question, long discussion in LAMPS WG regarding
combiners, security and best parameters. Wanted to keep list shorter.

John Gray: Author of Composite Signatures in LAMPS. Had many debates in
LAMPS, ended up with many combinations based on need. With regards to
question, we have implementation of LAMPS composites at LAMPS, OpenSSL
said they are doing the same. Let's not have 2 key formats. Makes
interoperability more complicated.

Philip Hallam-Baker: On the DER. You're not doing DER here, doing a
small subset. Not doing variable length encoding nested inside variable
length encoding. Has implemented both options. Need to do all public key
things the same way.

Michael Jones: One of the goals in JOSE was not to use ASN.1
certificates unless we chose to. JWK format defined alternate
representations for keys, and worked ok. Should default to not using
ASN.1 here as well if possible.

Sophie Schmieg: Deal with keys as an opaque blob, ideally do not try to
do all things. Keep same as LAMPS, makes it easier to interoperate.

Lucas Prabel: No needed knowledge of ASN.1 If we choose the ASN1 option
we can provide the necessary information in the doc to make it opaque

Mike Ounsworth: Just a question of where the DER encoder should be.

Brian Campbell: No real preference. Depends on what is provided, so
someone will be unhappy - just need to be honest about decision we are
making.

Chair: Poll
"I prefer aligning with LAMPS"
yes: 21
no: 12
no opinion: 10

Please also ask question on mailing list.

1. JSON Web Proof Document set
   https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-algorithms/

   https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-token/
   https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
   Michael B. Jones presents

John Bradley: Wallet curious person. Working with Google on Longfellow
and German entities about BBS. Was hoping JWT would be a common
container for BBS and Longfellow. Progressing this to where we can use
ZKP when presenting verifiable credentials would be beneficial. E.g. for
child protection/age verfication. Pseudonymization can come from ZKP,
but need a standard format to allow for interoperability.

Hannes Tschofenig: Have chairs spoken to CFRG to expedite processing of
BBS document? That's the blocker

Karen (chair) : Have not spoken to CFRG as chairs.

Deb Cooley: Have spoken to CFRG in the past, but not recently.

John Bradley: I've had previous discussion that there would be more
focus on ZKPs.

Michael P: There is some work, can also follow up.

Deb Cooley: May not be chairs, so may need to also follow up with
document authors.

Karen (chair): if JOSE is concerned about BBS we can help CFRG get it
done

1. Long-Term Validation for JSON Web Signature (LTV-JWS)
   https://datatracker.ietf.org/doc/draft-miyachi-ltv-jws/

Stefan Santesson: There is RFC9321, signature validation token, can be
put in a JWS, so can do long term validation. LAMPS group also has One
Signature certs, which can solve this by tailoring a certificate at
signing time. Interested in status at time of signing. SVT follows same
principle, interested in validity status at time when receive it. There
are other simple solutions that address same problem.

Scott Fluhrer: In certificates, attributes come from certificate
authority. Here they are generated by signer. How does this change the
trust model? Signer could put in any value. In a PKI you trust the
certificate authority, not the holder of leaf private key. Not clear how
can be misused or changes things.

Karen (chair): Take discussion to the mailing list.

Naoto Miyachi: Feedback welcome (positive and negative.)

1. Any Other Business (AOB)