Tuesday, 25 July 2023
Golden Gate 7-8; 1500-1630 PDT (UTC-6)
Notes: Yaron Sheffer
Admin and Agenda Bash (Chairs - 5 minutes)
JSON Web Proof Drafts (30 minutes)(David Waite)
JWS Multiple Payload Option (20 minutes) (David Waite)
Fully Specified Algorithms for JOSE and COSE (20 minutes) (Mike
Jones)
AOB and Way Ahead (Chairs - 10 minutes)
David described work towards -02 and beyond -02.
Karen: How many have reviewd: a handful. The mailing list has been
quiet.
David: trying to formalize Github issue process.
Open action item: Need to move the repo to IETF infrastructure, and
point to it.
JWP existing format: a simple syntax, semantics left to the application.
The multi-payload option turns it into a JWS extension, defines multiple
representations and multi-payload aware signatures etc.
If the draft is adopted, JWP drafts will be changed to use it.
Mike: do we have an issue on how MP can be used with JWE? David: not
yet.
Orie: it would be nice to know we have support for JSON/compact
serialization, in parallel with SD-JWT.
David: some mismatches, media types. Still mostly aimed at proof
algorithms.
David: JSON serialization is not great, but it is there for people to
use.
Michael P.: interesting use cases - embedding material (?), product
listings with regulatory meaning.
David: shouldn't become a generic document structure. But hard to define
what a "good" way.
Orie: difference between unprotected headers and unencoded payload. Both
are needed.
David: unencoded payloads are not appropriate to use here. We have
detached payloads. Need more guidance on unprotected headers.
Mike: welcome to propose text...
Brian: discusses unprotected headers and SD-JWT. JWS is already
overloaded: HMAC, non-signatures. Should not overload it even more.
Yaron: the optional mp:true + apps failing on new algorithms is
non-orthogonal.
Karen: please ask for discussion on the ML, then we can have a call for
adoption.
A proposal for a draft.
Brian: where do you put ECDH-ES?
John: supports fixing the algorithm (parameters).
Tobias: support having guidelines for people not to create new
polymorphic algs. Says the current COSE spec prevents polymorphism, the
room disagrees.
Michael P.: supportive. This has to do with work on naming of hybrid
schemes in PQUIP. Specifically hybrid signature schemes.
Justin: for HTTP signatures, discussed a similar thing with CFRG - there
may be other parameters and they all need to be locked, including wire
format. But, there will be two ways to create the same values. Should we
deprecate the underspecified algs?
Daisuke: supportive. It is relatively easy for signing, not so for ECDH.
Do you include the subsequent encryption algs for ECDH-ES?
Mike: this might be overcomplicated.
Brian: similar question for symmetric encryption algorithms.
Mike: "emc" should be as fully specified as "alg".
Orie: granularity of registries is different for different applications.
John: also consider Edwards encryption X25519. For encryption, we might
want to figure out on a case basis whether this is worth doing.
Justin: we can add columns (e.g. "status") to IANA registries. Or
"polymorphic".
(Carsten on chat, actually at the start of this segment:) Suggested
reading for the "fully specified" slides:
draft-bormann-cose-registration-principles-00.txt
https://www.ietf.org/archive/id/draft-bormann-cose-registration-principles-00.html
Brent: supportive of the approach.likes the direction Justin proposed.
Maybe coordinate some of the higher-level guidance with other WGs.
Next steps: write a draft.
Mike P.: reminder: we also have combiners in the PQ hybrid case.
Roman: need to recharter for "maintenance".
Orie: some recent docs are relevant: key formats for HPKE, key formats
for hybrid signatures.
See the following, regarding hybird / post quantum key formats:
https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/
https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/