Re: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-01.txt

[Michael Jones <[e-mail]>]

Thanks for reading the new draft and commenting, Ilari.  Replies inline below...

-----Original Message-----
From: jose <[e-mail]> On Behalf Of Ilari Liusvaara
Sent: Wednesday, February 28, 2024 12:19 PM
To: [e-mail]
Subject: Re: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-01.txt

On Wed, Feb 28, 2024 at 09:44:00AM -0800, [e-mail] wrote:
> Internet-Draft draft-ietf-jose-fully-specified-algorithms-01.txt is
> now available. It is a work item of the Javascript Object Signing and
> Encryption
> (JOSE) WG of the IETF.
>
>    Title:   Fully-Specified Algorithms for JOSE and COSE
>    Authors: Michael B. Jones
>             Orie Steele
>    Name:    draft-ietf-jose-fully-specified-algorithms-01.txt
>    Pages:   12
>    Dates:   2024-02-28

Some comments that still look relevant:

1) The encryption case seems like it would be difficult and delay the document by a lot. There have been requests to get this done quick, so I think that should be punted on.

Indeed, an open question called out in https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-01.html#name-ecdh-es-and-its-ephemeral-k is whether to introduce fully-specified algorithm identifiers for ECDH and possibly other encryption algorithms.  I expect this to be one of the discussion topics in Brisbane.

2) Abstract: I don't think the current encryption stuff is fully specified (the behavior of algorithms does depend on the key), so statements about new identifiers need to be qualified to only apply to signatures.

You're right that (as called out by the cited text above) some of the current encryption algorithms aren't fully specified.  This specification does two things.
(a)  It requires that all algorithms registered in the future be fully specified.
(b)  It creates fully-specified algorithm identifiers that can be used instead of polymorphic algorithm identifiers.

(a) is still very valuable, both for signing and encryption, even if we tactically decide that we don't want to do (b) for all encryption algorithms at this time.

3) Section 3.3.*: For the same reasons as above, the instructions need to be qualified to only apply to signatures.

Per the previous answer, (a) is still very valuable (and I view it as being the core mission of the specification), even if we don't do a comprehensive job of (b) immediately.  Again, I expect we'll discuss how much of (b) to do in Brisbane.

4) Section 6.3: I don't think anything in COSE or JOSE currently uses KEMs. And the requirement for single KDF goes beyond what fully specified means.

https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/ uses KEMs.  https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/ uses KEMs.  https://csrc.nist.gov/projects/post-quantum-cryptography uses KEMs.  I agree with Orie that it's good to include a discussion of KEMs now, since they're clearly coming to both COSE and JOSE.

5) I think that all the non-encryption stuff might stand (double-)WGLC.

Thanks.

                                -- Mike

-Ilari

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose