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

[Ilari Liusvaara <[e-mail]>]

On Wed, Feb 28, 2024 at 09:03:18PM +0000, Michael Jones wrote:
> 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.

I think if this applies to encryption, then new ECDH algorithms are
required.

The RSA stuff looks fully specified, and I don't see anything else
for asymmetric encryption than RSA and ECDH.


> 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.

I think that solving one but not the other is the worst option. That is,
one should solve neither or both.

Otherwise everything using JWE/COSE_Encrypt is left with having to
support both. Which is obviously harder than having to support just one,
whichever it might be.

I think adding all the fully-specified algorithms for encryption is 12
new and 4 deprecated algorithms for JOSE, 24 new algorithms and 10
deprecated algorithms for COSE.


> 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. 

No, those use HPKE. Internal details of HPKE are irrelevant, That is the
entire point of HPKE.


> 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.

Isn't requiring fully specified algorithms going forward enough?
(And if not doing that, then one should not do anything with KEMs
either.)




-Ilari