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

[Michael Jones <[e-mail]>]

Thanks again for engaging on this topic, Ilari.  I value your perspectives.

You wrote:  "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."  I would appreciate it if you could list the algorithms that you have in mind.  That could help inform future updates to the specification.

You may be right about KEMs. Right now the authors are erring on the side of providing guidance in areas that may benefit from it, but it's a working group decision whether to keep, modify, or delete the current KEM text.

                                Thanks again,
                                -- Mike

-----Original Message-----
From: jose <[e-mail]> On Behalf Of Ilari Liusvaara
Sent: Thursday, February 29, 2024 7:04 AM
To: [e-mail]
Subject: Re: [jose] I-D Action: draft-ietf-jose-fully-specified-algorithms-01.txt

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.i/
> etf.org%2Farchive%2Fid%2Fdraft-ietf-jose-fully-specified-algorithms-01
> .html%23name-ecdh-es-and-its-ephemeral-k&data=05%7C02%7C%7C456f507a355
> 44371d11308dc3937ad98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638
> 448158544780474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eNPm2Nz3i2ekQG
> fcJRiDVwx8nGysX2QI3gOYWyUM2dU%3D&reserved=0
> 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

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