JOSE Working Group @ IETF 125

Tuesday 17 March 2025 @ 9:00 - 11:00 (UTC +8)
Auditorium

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

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

Draft Agenda

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

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

Working Group Documents

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

2. JSON Web Proof Drafts (Jones (onsite)/Waite (remote), 30 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/

3. PQ/T Hybrid Composite Signatures for JOSE and COSE (Prabel (onsite),
   15 min)
   https://datatracker.ietf.org/doc/draft-ietf-jose-pq-composite-sigs/

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

Individual Submissions

1. JOSE HPKE PQ & PQ/T Algorithm Registrations (Campbell
   (onsite)/Skokan (remote), 10 min)
   https://datatracker.ietf.org/doc/draft-skokan-jose-hpke-pq-pqt/

2. Post-Quantum and Hybrid KEMs for HPKE with JOSE and COSE (Reddy
   (onsite), Tschofenig (remote), 10 min)
   https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke/

3. Way forward for PQ HPKE new drafts (Chairs, 15 min)

4. AOB (Any Other Business) (Chairs, 5 min)

Notes

Admin

Michael P welcomed as new chair, John Mattsson thanked as outgoing
chair.
Deb to continue as responsible AD for JOSE.

JOSE HPKE

https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/
Has been forwarded to the IESG. Is in Deb's queue

Deprecate None

https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/
Has been updated following concensus call on the mailing list on
particular wording.
Chairs suggest moving "Deprecate None" to WGLC. There were no objections
in the room.

JSON Web Proofs

https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-algorithms/

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

Mike Jones presented

Some improvements since Montreal:

1. JWP algorithms are in a different registry to JWA/COSE algorithm
   registries, so need to have different algorithm identifier,
   introduced 'proof_alg'. Seeing what it looks like to keep these
   distinct and asked WG for their opinion on this.
2. Building examples is now deterministic and consistent between drafts

Things they might do next:

1. Implementer feedback: comparison between sd-jwt/cwt and JWP -> those
   allow disclosing only part of a claim. There is now an open issue
   for figuring out how to do this. Structured claims like addresses
   make this tricky, e.g., maybe users want to reveal just country, not
   the whole address. No PR yet. Want to keep this as much like the
   other things as possible.
2. Also looking at BBS extensions. These drafts are underway, but not
   as mature as the core spec. Require verifier support even if the
   extensions aren't used. This require a code change, and a lot of
   set-up between parties. One of these is BBS blind signatures draft
   (used for holder confirmation keys). We need to decide whether we
   work on support for this or not. This would probably need to be a
   different draft regardless. Also considering BBS Per-Verifier
   Identifiers. Both could be useful, but looking for feedback whether
   implementers feel support for these extensions would be useful.

Any Feedback?
Brent said: Yes to support BBS Blind signatures. Without these BBS isn't
as useful. Not sure about Per-Verifier identifiers.
Mike Jones noted that we should check on progress of Blind Signatures in
CFRG.
John Bradley agrees with Brent on needing BBS Blind signatures, not just
BBS. Points out use case on pseudonym work in Europe. Also some BBS work
in ETSI that needs to be coordinated so that things stay consistent.
Mike: Are Tobias and Vasilis looped into that? Not sure.
David Waite: Since there are people interested in blind signatures.
Knowing there's a secret value involved, and payloads that are holder
provided and captured in the message. We need feedback on whether to
include non-issuer payloads in presentations.

PQ KEMs

https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/
Tiru presented.

So far, all comments have been addressed.

Seems to be consensus to use AKP over OKP. There are also clear
distinction between direct key agreement and key wrap modes. This draft
is independent of HPKE, so it does not rely on those modes. Instead
follows ECDH-ES model.

Authors believe document is ready for WGLC.

John Mattsson has reviewed the draft and agrees with WGLC

Mike Jones raises topic: we have HPKE, lots of PQ algorithms happening
in that space. Not clear to me that this isn't an unnecessary way of
doing the same thing as done elsewhere. Why use this when we can use
HPKE variants
Tiru: this proivdes a simple migration path due to the similarities
between previous methods.
Mike: but why use this?
Tiru: These are two different techniques.
Mike: yes, but why support two?
Tiru: This mode is for KEM migration.

John: LAKE needs an independent KEM that isn't bound to other
algorithms. Needs a COSE algorithm, some of the messages are further
optimized and needs a COSE algorithm for KEM.

Brian Campbell: Just to clarify, LAKE needs a COSE alg and is coming to
JOSE?

John: We didn't ask for it, but this is where the work happenned and we
are depending on the draft.

Brian: I think this is representative of the problems of deeply coupling
JOSE and COSE algs in the same document. We get into problems when we
couple work in unnatural ways. The use cases differ between each of
these things. To reiterate Mike's comment. Agree with Mike's point; Why
are we introducing two distinct mechanisms to do the same thing? This
came up before and is coming up again. This will cause interop problems
and fracture the ecosystem. If LAKE needs something special, then they
should go to COSE for that.

Hannes: In some situations it seems convenient to relationship between
the two groups. John was quite clear that he has different design
requirements and why this is needed. Other may need different
algorithms. If you don't want to use it, don't

Mike Jones: Before we would do a WGLC on this, I would like to have a
good list discussion on the COSE use cases that require this. I know
it's different, why do we need it?

Brian Campbell: At the risk of being dramatic, there is a real cost to
the ecosystem of having multiple algorithms that do the same thing.
There are broader costs and implications, so we should be intentional.
This needs ot be a deliberate choice if we're going to do it.

Hannes: I don't see that great a cost to the ecosystem. Not to long ago,
for example in the OAuth ecosystem, the need was mostly for digital
signatures, there were mutliple mechanisms and some people use and
others people don't. Nowadays, implementation costs are nearly zero, so
this is even less a problem.

Filip: Library sizes and bundle sizes are directly dependent on the
number of algorithms supported. Inmplementation cost is beside the
point. Fragmentation is real and will be a problem. Multiple systems not
working together is a problem. We should avoid two ways of doing the
same thing.

Yaroslav: implementer's perspective. I would need to implement both,
because I don't know what others are doing. Maintaining both and fixing
bugs in both is a problem.

Karen: Unresolved question is what is positive use case for JOSE vs
COSE. Any answers there?

Tiru: mobile networks are interested. Hybrid schemes we only have HPKE,
but if someone want to jump straight to pure PQ, this provides the
easiest transition path. Some implementers are just doing that.

John Bradley: Question for Deb: some people have skepticism about
hybrid, in particular for signing. Are these people going to use HPKE in
purely PQ mode? or is there a desire to use just PQ?

Deb: I haven't looked closely at this, Original HPKE wasn't PQ hybrid.
If you wanted pure PQ, what are the options in JOSE?

John: Can HPKE be used in a purely PQ way without hybrid? If so there's
an argument, if not? In general people move to HPKE because it improves
the security model and a desire to standardize there. Having two
different models goes against that. In the constraint environment space,
more algorithms costs money. Is there something that can't be done with
HPKE that the other algs provide?

Deb: I don't know

Tiru: HPKE does support pure-PQ. Initial draft was hybrid, but now pure
PQ too.

John: then maybe we don't need it this draft if we can use HPKE.

Michael: agree with Tiru. Can do pure-PQ in HPKE.Just a terminology
issue.

John Gray: wouldn't this fit with composite KEM in LAMPS? if you want
hybrid, isn't that a way to do it? It is a KEM wrapper. You can do KEM
things with it. That would fit right into this.

Tiru: I am aware of that draft, it is only for PQ KEMs.

Karen: Two ways forward: WGLC or have a discussion prior to that. Chairs
and authors will sync and decide.

Brian: I don't know what it would mean to go to WGLC after this
discussion. Sounds like there's still a lot of concerns. WGLC may not be
right call.

Deb: One option is to split the draft and do COSE part in COSE WG.
Question is do we need HPKE way and pure KEM way? Needs to be a
compelling reason to do it two ways. Need to decide what to do with the
JOSE piece. COSE pice can always be split out.

We will take it to the list.

PQ/T Hybrid Composite Signatures

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

Adopted in January and updated since adoption. Draft defines JOSE & COSE
hybrid algorithms. Aligns with LAMPS and COSE pure ML-DSA draft. Added
security considerations and test vectors.
Plan to still address point compression issue.

Question to the group:

1. Is the set of algorithms complete?
2. Security considerations enough?
3. what is left before WGLC?

Any Questions?
Any reviewers? Mike Jones raised his hand. Others please review

Mike Jones: One thing I don't have the expertise to answer is whether
this is the right list of algorithms. I thing the draft itself is solid.

Request to WG to please review the draft

JOSE HPKE PQ & PQ/T Algorithm Registrations

https://datatracker.ietf.org/doc/draft-skokan-jose-hpke-pq-pqt/
Brian Campbell presents

Focused algorithm registration doc, nothing else. Just code point
registrations for JOSE for both PQ and PQ/T. Test vectors for all
algorithms. Builds on established mechanisms from this group. Registers
algs in HPKE model and relies on HPKE WG documents. No new crypto.

Why does this draft exists? As HPKE work progressed in JOSE WG, Filip
asked why we don't use this new HPKE framework for PQ and PQ/T moving
forward? Didn't want to hold up HPKE framework. Now we have these
registrations.

Choices of algoritms were made. 5 KEMs (listed on slides), one KDF, two
AEADs. Each suite has two modes: integrated encryption and key
encryption. Omitting ML-KEM-512 due to potential future security
concerns and to keep the list as small as possible: some libraries are
choosing to not support it e.g., boring-ssl.

John Gray: Composite-KEM draft in LAMPS is in alignment with this on
ML-KEM-512

John: do we still need 3 hybrid KEMS? maybe we can cut the P curves?

We have a slide about cutting down algs.

Choosing algorithms is hard. Slide about current menu of algorithms
slide.

Mialing list discussions: AES-256-GCM may support all use cases that
would use Chachapoly1305. There is no chacha in JOSE currently, might
make sense to drop these.
Orie suggests maybe leaving out P-384 varients. and points out
ML-KEM-P256 already covers security level.
There was discussion of AES-128 and AES-256 on list. Author's feeling
using higher key length is enough?

Deb: AES Question. Don't we already have AES-128?

Brian: Only for content encryption, but we wanted to keep the number of
options small. This supports either content or key encryption.
Also thinking about dropping chachapoly.

Deb: agree that if you're not using it for content encryption, don't use
it for key encryption. My main question was that I wanted to know why
using AES-256. Would often like security levels to match.

Filip: Just to reduce set of algs

Deb: that is fine, maybe also ditch chacha

Michael: Deb's point is the one I made on list, but also fine with
keeping it simple.

Brian: This is more of a suite format so want to keep list small.

Yaroslav: AES-128 vs 256, there' also minimal performance hit to use
256. slight preference is to match TLS in determining what looks good to
keep.

John Gray: KDF is SHAKE? In composite-KEM draft SHA3 is used. What is
KDF used for here?

Filip: Part of HPKE construct

John: just want to make things are compatible, I'll look at the draft.

Brian: Shouldn't be a compatibility thing. Just want to limit options.

Mike Ounsworth: XWing is SHA3 not SHAKE.I'll take a look at the draft

Back to the presentation. Lots of content generation is happening here,
so changing the alg set is no big deal.

Filip has done some work in COSE variant of the automation work if folks
want to contact Filip about it

Also comments on JOSE COSE PQ PQ/T draft from Tiru and Hannes. This is
different than that draft. May be some duplicate content between that
draft on others. Also has both JOSE and COSE. (see slide 9)

Karen noted the similarities and asked drafts to see where they can be
combined.
Maybe we don't need to keep JOSE and COSE so aligned. They have already
drifted. Now at the HPKE layer forcing alignment may not make sense.
Alignment should happen where it's natural. COSE and JOSE HPKE were
separate documents, not tightly bound.
Proposal is to adopt this draft, keep it in JOSE and keep the scope to
JOSE. Add Authors of other draft to this draft and move COSE piece to
COSE.

Post-Quantum and Hybrid KEMs for HPKE with JOSE and COSE

https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke/

Tiru presenting

draft has been worked on for 2 years. Held up until HPKE work matured.
Supports PQ/T and pure PQ modes.
Updated to align with JOSE and COSE HPKE drafts. Uses AKP for
representing PQC and PQ/T keys
has table about security levels of each combination. Does include
ML-KEM-512. This is supported in TLS and IPsec and in various libraries,
included for constrained environments. Should this be excluded? should
be useful for COSE.
Uses SHAKE256.
Uses AES-128 for ML-KEM-512
ML-KEM-1024 paired with P-384 over P-521
Not just about adding new code points. Also discusses trade-offs of
different hybrid combinations and security thereof.
Has been presented multiple times and adjusted to address WG feedback.
Was deferred until HPKE

The authors of the other draft decided to publish their own rather than
comment on this one.
Proposal is to add other authors to this document and move forward with
a single document.

Comments?

Mike Jones: looking at current draft, one surprise is it is trying to
register polymorphic algorithms. not in line with HPKE drafts. That
would need to happen for this draft to move forward.

Tiru: Latest version adds this, you may be looking at an old version.

Mike Jones: Sorry about that. Other point is that don't think we should
blindly keep JOSE and COSE aligned because use cases are different. That
said, to the extent that the same functionality is need in both, they
should stay aligned. Both WGs should consider algorithm alighment.

Karen: Thought the objective is to keep them aligned. But do they need
to be in the same documents?

We will start one thread of conversation about that.

Other thread is what to do with these documents. Original proposal is to
combine authors into one document, Brian has proposed splitting JOSE and
COSE.

Brent: Please limit algorithm choice. Slight preference for keeping
first document that was presented and splitting out COSE piece.

Nick Sullivan: want to point folks to CFRG - want to point IETF to
useful pathways for coordintating across groups. Maybe that document
will be helpful in this WG finding a path forward.

Hannes: In the past, I thought there was a desire to keep the JOSE and
COSE groups aligned. There are a number of drafts trying to do things in
both. PQ signatures document does both groups in one document. If the WG
wants to do it separate, than keeping authors apprised of the strategy
would be helpful. It would be nice for people to share more often when
they are unhappy with something and communicate more. It was bad
behavior to produce a totally new draft instead of commenting on the old
one.

Tiru: We have several docs for PQ that include both JOSE and COSE, why
is this one different? Not just about algorithms, it's about the
transition path. The whole discussion in TLS was why PQ vs PQ/T and that
people need guidance on how to choose. This is important. Registering
code points is straightforward. It is needed to provide more
information. If you haven't even commented on the old draft, why write a
whole new draft? Bad precedent to start in this group.

Filip: We did bring up those concerns in December on the list. At that
time, there was no HPKE doc in JOSE or COSE that would do pure PQ. Tiru
said pure PQ goes through KEM and hybrid goes through HPKE. We did bring
it up to he mailing list and there were discussions asking for a
separate draft.

Deb: As AD. You 4 authors need to get together and decide what to do. If
possible to do JOSE and COSE together that is clear, concise and
well-constructed, keeping in mind needs and differences of both. If one
draft makes sense, that is fine. If two drafts are simpler, do that. I
do want to see test vectors in both, and small number of options. You
need to get together and sort this out. I'm not there to force a
cage-match, but AD hat and Mom hat on, get along and figure it out.

Mike Jones: Karen's recollection is correct. We explicitly wanted to
coordinate JOSE and COSE. We've done that in a lot of places, especially
algorithms drafts that cover both. I thing reviewers and implementers
will find it easier to do both in one. Doesn't have to be idential but I
expect a common core set.

Tiru: thanks to Deb for the direction, we will figure out a way forward.

Karen: We will continue to keep JOSE and COSE aligned where possible,
but avoid unnecessary shackling. The authors will figure out a path
forward and follow Deb's guidance on test vectors and reducing options.

AOB

Anything else?

Thanks all, see you in Vienna!