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.
Call for note takers.
Note well
Agenda Bash: BBS document will be done third due to a conflict
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.
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
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.
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.
Will remove JOSE aspects and move it to the COSE working group. To be presented on Thursday.
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.
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
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.)