Minutes IETF120: jose: Mon 22:30
minutes-120-jose-202407222230-01

Meeting Minutes Javascript Object Signing and Encryption (jose) WG
Date and time 2024-07-22 22:30
Title Minutes IETF120: jose: Mon 22:30
State Active
Other versions markdown
Last updated 2024-08-09

minutes-120-jose-202407222230-01

JOSE Working Group @ IETF 120

Monday, 22 March 2024
15:30 - 17:00 PDT (UTC -7)
Georgia A

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

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

Draft Agenda

  1. Admin and Agenda Bash

Note-takers: Mike Ounsworth, David Waite (after his talk). Much thanks
from the chairs!

No agenda bashes.

  1. JSON Web Proof Drafts

No comments at the mic.

Chairs would like to see additional discussion on-list. These drafts
should move into the jose-wg github space
(https://github.com/orgs/ietf-wg-jose).

David Waite: FWIW, JSON Web Proofs are currently under their own org, at
http://github.com/json-web-proofs/json-web-proofs

David moved them over before the end of the meeting.

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

Filip Skokan: It was the German Health Institute who wanted to do
brainpool curves in JOSE. I can help find out who wants to use this and
ping Mike Jones.
MJ: We intentionally did not add new functionality; we only added things
that are already registered.

Kristina Yasuda: Where did you get the allocation ranges?
MJ: We used the 2-byte ranges and followed the convention of negative
codepoints for signatures laid down by Jim Schaad. We are aligned with
the ISO 18013-5 driver's license doc on curve codepoints.

Brian Campbell: I don't recall anyone actually asking for algorithms to
be registered. IMO registering a small set feels like the worst possible
outcome here: if we're going to register some then we should register
them all. I would rather register nothing because nobody seems to need
this in practice, creating maintenance issues for library maintainers.

Filip Skokan: Agree with Brian. We should register X25519 as a modern
alternative to P256; but I would rather that we simply not have these
registrations (speaking as a maintainer as several libraries).
MJ: Ok. We will revisit the people who asked for this.

Hannes Tschofenig: We (SUIT) like the 4 algorithms you have; they
represent a practical approach -- referring to existing hardware
acceleration for P-256.

Kathleen Moriarty (KM): "Deprecated" means "please don't do this
anymore" -- ex as used by TLS WG or as used by the IETF process for the
status of drafts. Using a different defition of "Deprecated" here would
be confusing.
MJ: these uses of the terms were suggested at the time by Sean Turner,
and they are already in the spec. If we change "Deprecated" to mean
"Prohibited", then we have to update a bunch of things. This would be
good for an on-list discussion.

Brian Campbell: I am very much opposed to the introduction of a new
algorithm that was not asked for during WGLC. There was fairly limited
requests during WGLC, but the changes are much broader than that. I
don't think we're ready for a second WGLC. This draft seems to have
gotten caught up in solved parallel ECDH problems, and is holding up
progressing this good work.
MJ: you're right that the only on-list response was Neil Madden who said
that this does not do what it was asked to do. There was a request to
remove the ECDH stuff from the scope.

Hannes: On the discussion about whether signatures or encryption are
more important ... there are uses for JOSE encryption mechanisms,
particularly in the firmware world.

Laurence Lundblade: In Prague there was an AES ciphertext binding attack
presented at LAMPS. We've been discussing this quite a bit in COSE and
we believe that JOSE and COSE are similarly vulnerable, and we probably
should not register a new codepoint -54 until we figure out how to
address the attack, which probably needs a new codepoint.

Chairs: one possible approach is to separate out the contentious part of
this draft.

MJ: suggestion for how to proceed: my personal opinion is that we should
not do new ECDH registrations in this draft. But we have gained a lot of
WG knowledge around ECDH, so it would be unfortunate to pull that text
out.

Filip: I wouldn't mind if the appendix remained in a version of the
document with the registrations gone -- except for removing the concrete
references from the table in the appdx.

Chairs: the result of all this is that we are not ready for another
WGLC.

  1. Use of HPKE with JOSE
    https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt-01

Chairs: everyone please take a look at the last two slides (or look at
Orie's email with essentially the same content).

The chairs will be coming back to the list with questions to help define
the open questions.

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

Chairs: I see some thumbs-ups. We will do a call-for-adoption on the
list.

  1. Guidance for COSE and JOSE Protocol Designers and Implementers
    https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/

Hannes: I will re-submit the document with this new title and abstract,
then post to the list.

Chairs: I see people doing thumbs-up. I assume they will look at the
document.

  1. AOB and Way Ahead

Chairs: We have created an IETF-owned github space for JOSE. I would ask
all authors to move your documents over. https://github.com/ietf-wg-jose

No Updates, but still on our radar:
JOSE-COSE HPKE Cookbook
https://datatracker.ietf.org/doc/draft-steele-jose-cose-hpke-cookbook/