**Session Date/Time:** 21 Jul 2026 12:00 # [JOSE](../wg/jose.html) ## Summary The JOSE Working Group met at IETF 126 to discuss several active drafts and cryptographic updates. The session was chaired by Karen O'Donoghue, with assistance from John Bradley. Key outcomes of the meeting included closing the Working Group Last Call (WGLC) for the HPKE with JWE specification and confirming consensus to publish `draft-ietf-jose-deprecate-none-rsa15` to deprecate "none" and "RSA1_5". The group also agreed to run a Call for Adoption for a new proposal on BBS and modular sub-proofs with JSON Web Proofs (JWP), and discussed key representation alignment for post-quantum hybrid composite signatures. Lastly, the group decided to hand off the JOSE-specific parts of `draft-ietf-jose-pqc-kem` entirely to the COSE Working Group. --- ## Key Discussion Points ### 1. Chair Updates and Working Group Last Calls Karen O'Donoghue presented the [IETF 126 JOSE Chair slides](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-ietf-126-jose-chair-slides-00). * **HPKE with JWE**: The second/third WGLC is closing. There is a parallel IETF Last Call focused on removing two specific algorithms. No opposition has been raised, and the document is being returned to the IESG. * **Deprecating 'none' and 'RSA1_5' (`draft-ietf-jose-deprecate-none-rsa15`)**: The draft recently concluded its WGLC with positive reviews from Phillip Hallam-Baker and Brian Campbell on the list. Sophie Schmieg noted in the chat that while deprecation is a positive step, poor implementations of "none" are still likely to persist. To establish formal consensus, a room poll was conducted. * **Poll 1**: *I support publication of this document* — yes: 27, no: 0, no_opinion: 8 (total: 66) ### 2. BBS and Modular Sub-proofs with JSON Web Proofs Christian Paquin presented [BBS and Modular Sub-proofs with JSON Web Proofs](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-bbs-and-modular-sub-proofs-with-json-web-proofs-00). * **Overview**: The proposal introduces a modular zero-knowledge proof (ZKP) framework on top of JWP. By introducing a cryptographic commitment layer, it decouples the core signature/proof system (e.g., BBS) from specialized sub-proof schemes (e.g., range proofs or device binding). * **Discussion**: * Brent Zundel and John Bradley strongly supported the work. John Bradley noted that they are prototyping this with P-256 and Schnorr bindings. * Frederik Janssen cautioned that sub-proof definitions should be separated from the core framework to ensure agility. Christian Paquin agreed that the specific algorithms should be moved out, keeping only the IANA registry and core framework in this draft. * Andrey Popov spoke in favor of the work as a viable alternative to other systems like Longfellow, especially for regulated environments. * Orie Steele asked about the modularity of the front part (core proof system) versus the back part. Christian explained that it can support other systems like Lazer (post-quantum lattice-based proof). * In the chat, Emil Lundberg supported the JWP claims mapping approach but emphasized the need for strict header encoding controls to prevent de-anonymization. Orie Steele, Brent Zundel, and Emil Lundberg discussed volunteering to help CFRG progress the core BBS specifications to unblock this work. * **Chairs' Action**: The chairs decided to initiate a Call for Adoption for this proposal. ### 3. JOSE HPKE PQ & PQ/T Algorithm Registrations Philip presented [JOSE HPKE PQ & PQ/T Algorithms](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-jose-hpke-pq-pqt-algorithms-01), discussing `draft-ietf-jose-hpke-pq-pqt`. * **Overview**: The combined draft registers ALG values for JWE using five HPKE cipher suites (totalling 10 algorithms across two key management modes: key encryption and integrated encryption). The ML-KEM-512 variant is excluded from the JOSE draft but remains in the COSE draft. * **Web Crypto API**: Origin trials are commencing in Chrome/Chromium for ML-KEM-768, ML-KEM-1024, and Xwing. No browser support is planned for ML-KEM-512 or other hybrid curves. * **KDF Selection**: The draft currently specifies SHAKE-256. Browser feedback is mixed: Firefox lacks native SHAKE support, while Safari is open to its inclusion. * **Discussion**: * Tirumaleswar Reddy requested aligning with TLS by designating the X25519 + ML-KEM-768 suite (Xwing equivalent) as "recommended" or "required" in the IANA registry. AD Deb Cooley agreed that mirroring the TLS designation is a sensible path forward. * Quynh Dang (NIST) recommended prioritizing strength (Level 5 down to Level 3, and then Level 1/ML-KEM-512) depending on performance requirements. Sophie Schmieg recommended against using ML-KEM-512 unless there is an explicit performance justification. * Brian Campbell questioned the inconsistency of completely removing ChaCha AEADs from this draft when the base HPKE JWE document still supports them. Deb Cooley responded that if JOSE intends to move away from ChaCha in the future, omitting it now is acceptable. ### 4. Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE Tirumaleswar Reddy gave an update on `draft-ietf-jose-pqc-kem`. * **Status**: It was unanimously agreed by the working group that JOSE does not want to support pure post-quantum KEMs without HPKE. * **Decision**: The JOSE-specific portions will be removed from `draft-ietf-jose-pqc-kem`, and the draft will be transitioned entirely to the COSE working group. ### 5. PQ/T Hybrid Composite Signatures for JOSE and COSE Lucas presented [PQ/T Hybrid Composite Signatures for JOSE and COSE](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-pqt-hybrid-composite-signatures-for-jose-and-cose-00), detailing updates to `draft-ietf-jose-pq-composite-sigs`. * **Serialization and Encoding Controversy**: A key discussion arose over whether the ECDSA component within the composite keys and signatures should be encoded as raw, fixed-length bytes (Option 1) or as ASN.1 DER (Option 2), to align with the LAMPS composite signature drafts. * **Discussion**: * Philip noted that implementing without ASN.1 is simpler but acknowledged that diverging from LAMPS would disappoint some implementers. * Andrey Popov advocated for Option 2 (aligning with LAMPS), explaining that composite keys should be treated as atomic, opaque entities to prevent implementers from decomposing and reusing individual keys. * Co-Chair John Bradley preferred avoiding ASN.1, highlighting that `RFC 9964` (the pure ML-DSA specification) does not use ASN.1 DER. Mike Jones agreed that a core design goal of JOSE is avoiding ASN.1. * John Gray (representing LAMPS and Entrust) and Sophie Schmieg supported Option 2. Sophie argued that treating keys as opaque blobs is better design, and Mike Ellsworth added that choosing Option 1 merely forces developers to write transcoders between the crypto libraries (using DER) and JOSE. * The chairs called a room poll to gauge preferences. * **Poll 2**: *I prefer aligning with LAMPS Composite document?* — yes: 21, no: 12, no_opinion: 10 (total: 76) ### 6. JSON Web Proofs (JWP) Mike Jones presented [JSON Web Proofs](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-json-web-proofs-00), covering: * `draft-ietf-jose-json-web-proof` * `draft-ietf-jose-json-proof-token` * `draft-ietf-jose-json-proof-algorithms` * **Status**: The drafts have received editorial cleanups and automated cryptographic example generation. * **CFRG Dependency**: The main blocker is the slow progress of the BBS signatures draft in the CFRG. Mike Jones urged the WG to help progress the BBS specifications in CFRG. * **Discussion**: John Bradley noted that Google (working on Longfellow) and German entities (working on BBS) are prototyping with these formats. Having a standardized container format like JWP is essential to enable interoperable zero-knowledge presentations for use cases like age verification and pseudonyms. ### 7. Long-Term Validation for JSON Web Signature (LTV-JWS) Yuzuru Someya presented [Long-Term Validation for JSON Web Signature (LTV-JWS)](https://datatracker.ietf.org/meeting/126/materials/slides-126-jose-long-term-validation-for-json-web-signature-ltv-jws-02). * **Overview**: The draft introduces lightweight, offline long-term validation capabilities and algorithm renewal mechanisms for JWS utilizing recursive archive timestamps. This aims to be a simpler, more lightweight alternative to JAdES (the European XML-based system). * **Discussion**: * Stefan Santesson pointed out related work, such as RFC 9321 (Signature Validation Token) and the LAMPS "one signature certs" draft, which solve similar offline validation issues without needing complex recursive timestamp structures. * Scott Fluhrer questioned the trust model, noting that the attributes are generated by the signer rather than a CA. Yuzuru Someya invited further feedback on the mailing list. --- ## Decisions and Action Items ### Decisions 1. **`draft-ietf-jose-deprecate-none-rsa15`**: The WGLC concluded with strong consensus to publish. The document will be progressed to the IESG. 2. **`draft-ietf-jose-pqc-kem`**: The JOSE working group decided to remove all JOSE-specific elements from the draft and officially hand the document over to the COSE working group. ### Action Items 1. **Chairs**: Initiate a Working Group Call for Adoption for the BBS and Modular Sub-proofs JWP work presented by Christian Paquin. 2. **Lucas (and draft authors)**: Take the ASN.1 DER key serialization question for `draft-ietf-jose-pq-composite-sigs` to the mailing list for final resolution, noting the room's preference (from Poll 2) to align with the LAMPS composite draft. --- ## Next Steps 1. **HPKE JWE**: Chairs to officially submit the core HPKE JWE document back to the IESG. 2. **`draft-ietf-jose-hpke-pq-pqt`**: Aiming for a Working Group Last Call by mid-September 2026, following list discussions on default "recommended" algorithm suites and KDF engine compatibility. 3. **CFRG / BBS Alignment**: Interested working group members (including Brent Zundel and Emil Lundberg) are encouraged to contribute to the core BBS draft in the CFRG to resolve JWP's normative dependency.