JOSE Working Group @ IETF 122

Thursday, 20 March 2025
9:30 - 11:30 13:00 - 15:00 (UTC+7)
Chitlada 3

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

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

Draft Agenda

1. Admin and Agenda Bash (Chairs, 5 min)

WG Documents @ IESG

1. Fully Specified Algorithms for JOSE and COSE (Jones)
   https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/

Mike Jones presented
Comments from Security AD are addressed.
Deleted Appendix on full-specified ECDH.
Updated draft says that HSS/LMS is not fully specified.
Directorate reviews received saying "Ready"
ISEG review initiated.
A telechat date is being requested by Deb Cooley.

WG Documents

1. Use of HPKE with JOSE (Reddy, Jones)
   https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/

Tiru Reddy presented
Described updates clarifying draft since IETF 121
One open issue: Create header parameter for HPKE Setup info value
Ready for WGLC after open issue addressed?
Filip: Asked about use of "enc":"dir"
... "dir" is not a fully-specified AEAD algorithm
Tiru: Integrated encryption is fully specified
Filip: The draft should update the "dir" description in the registry
Brian Campbell: I don't think there's consensus to use an "enc" value
that not's an AEAD algorithm
... I've raised concerns about this in the past
Brian: You need to update the base specs
Tiru: In the past meetings we'd proposed several options
... We could propose additional possibilities
John Mattson: There's no such thing as an authenticated KEM
... You need to correct the terminology
... HPKE is not a KEM
... It uses KEMs for some things but not the authenticated mode
Mike: If we used the value "int" rather than "dir", would you be
happier, Filip?
Filip: Yes
Brian: I'd rather that HPKE use a different serialization than JWE
... But if you're going to override the meaning of "enc", I'd rather
that you used a different value
John Mattson: There was a suggestion to remove the authenticated mode of
HPKE
... By Martin Thompson and Richard Barnes on the SAAG list
Deb Cooley: We had a request to offload HPKE from the CFRG by forming a
new HPKE working group
... We are going to talk to the CFRG chairs
... The plan is for this to be a short-lived working group to produce
one or two document
... This should be quick
Joph: Tiru talked about the authenticated encryption mode
Deb: My suggestion is that if you're doing HPKE work, that you get
involved in the new working group, if formed

1. JSON Web Proof Drafts (Mike Jones)

   • 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/

Defined CBOR representation of JSON Proof Token (JPT)
Defined media types for JPT and CPT
BBS updated in response to cryptographic review comments
Dependent upon CFRG BBS signatures doc
New related CFRG docs adopted: Blind BBS signature and BBS per Verifier
Linkabilty
Parameter unification discussion
Drafts currently use parameters from three registries, JWP Header
Parameters, JWT/CWT claims.
Selectively disclosing header parameters is application specific, raised
issue in github.
Use of params from same new registry in both headers and payload, has
both pros/cons; it requires feedback from the WG.
Open Issue: Abandon JSON serialization, use only JWE compact
serialization.
Unlike JWS JSON Serialization, JWP JSON Serialization adds no new
capabilities
Open Issue: Posible use of new BBS extensions with JWP
Can these be used with JWP with no updates to JWP?
Are these useful to JWP use cases?
Open Issue: ZKP Using ECDSA
Should we add this as JWP algorithm?
It will be used for Google EUDI wallet application
We should explore use of this possiblity
Feedback is required on CBOR representation
Adding more cryptographic algoirthms
Adding Post-quantum safe algorithms (post-quantum ZKP)
Brian Campbell: Supportive of only having compact serialization
Whether ZKP Using ECDSA is suitable for JOSE. The discussion was to take
it as a seperate draft to see if the draft can be useful with other ZKP.
There are other categories of ZKP to check for compatilibity with the
JWP architecture.
John Bradley: I suggest having a session on ECDSA-based ZKP and JWP at
the Internet Identity Workshop (IIW)

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

Very few coments are on the mailing list, good to deprecate, is it ready
for WGLC ?
The chairs requested another round of reviews
Mike, Brian, and Yaron Sheffer volunteered to review
Security AD Deb Cooley suggested asking for early directorate reviews,
for instance Security Directorate.

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

Not presented

Individual Submissions

1. Enhanced JWE Security with Detached Additional Authenticated Data
   (AAD) (Reddy)
   https://datatracker.ietf.org/doc/draft-reddy-jose-detached-aad/

Tiru Reddy presented
New security mechanism distinct from HPKE
Introduces detached AAD in JWE
Allowing AAD to be derived from context-specific information, rather
than being in-band
Use case: OpenID for Verifiable Credentials
Brian Campbell: This has not been extensively discussed by the OpenID4VC
people
... There's a small group who are interested in this
... The use cases they would get from this are questionable
... I urge caution in pursuing this
Tiru: Introduces detached_aad boolean parameter
... Defines serialization updating how AAD is computed
Security Consideration: Both parties must use the same detached AAD
Brian: I'm not convinced this is a problem nor that this is the right
way to address it
... JSON canonicalization is something else I hope that we don't do
... This seems like looking for a solution to a problem that isn't
actually a problem
... This probably shouldn't be worked on in the first place
Mike: I was in the discussions in the OpenID4VC world.
... There's not consensus there that this is an actual problem.

1. PQ/T Hybrid KEM: HPKE with JOSE/COSE (Reddy)
   https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke/

Not presented
Tiru reported that the COSE chairs have decided not to do an adoption
call on this until draft-ietf-cose-hpke has completed WGLC

Other Presentations

1. Modern Algorithms in the Web Cryptography API (Filip Skokan
   (remote), 15 min)

Daniel Huigens current editor of WebCrypto API
Extension defines new algorithms for WebCrypto
Incluing PQ algorithms
Intersection is that WebCrypto uses JWKs
"It is not the most convenient API"
CryptoKey instances used for signing, etc.
ML-DSA JWK format defined in draft-ietf-cose-dilithium
ML-KEM new SubtleCrypto methods for encapsulate/decapsulate
SLH-DSA JWK format defined by draft-ietf-cose-sphincs-plus
Mike: To the extent that the COSE-defined JWK representations don't meet
all the needs, please file issues on the draft
Mike: W3C drafts can define and register JWK representations
John Mattson: Algorithm registrations are "Specificaiton Required"
Deb Cooley: John, have you looked up OCB mode?
... Is it secure?
... Not all versions are secure.
... OCB3 is AEAD - Described in RFC 7253
... OCB2 is broken
Jonathan Hammell: Confirmed that RFC 7253 describes OCB3
Filip resumed...
SHA-3 being added to WebCrypto as hash algorithms
Using SHA-3 with existing algorithms would introduce unnecessary
combinatorial combinations
cSHAKE - Same interactions as with SHA-# but more complicated because of
variable-length output
KMAC as specified by NIST SP 800-185
I will send this to the list for feedback
I will summarize the feedback for Daniel to incorporate in his draft
John Mattson: You didn't mention Aragonne2
Filip: There isn't an interaction between Aragonne2 and JOSE because
WebCrypto does not allow export for key derivation keys
Daniel Huigens: Thanks for presenting on this here
... I look forward to the feedback
... I agree that we won't mandate support for all combinations
... For instance, we won't mandate support for RSA-SHA-3
Filip: The API allows for algorithms to not be supported
Jonathan Hammell: With SHAKE, you wouldn't use the mask generation
function
Filip: Yes, I just copied the slide from the previous

1. AOB and Way Ahead (Chairs, 5 min)

Meeting Notes

The PQ/T Hybrid KEM: HPKE with JOSE/COSE draft recently went through a
WG adoption call in the COSE WG, and the chairs will decide on the
adoption after the WGLC of draft-ietf-cose-hpke ends.

The authors didn't get a chance to work on the other draft, Post-Quantum
Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE, but will plan
to submit a revised draft sometime next month.