I’m in two minds about this draft. I’m fairly receptive to it in general, but I think it might be closing the stable door after the horse has already bolted.
Some questions and comments that come to mind: * A JWK “alg” constraint can only contain a single value. After this spec passes some algorithms may have two valid identifiers, leaving implementations a choice as to which to advertise (and risk breaking some clients) or to publish the key twice with different identifiers (wasteful and potentially causes other issues), or to drop the algorithm constraint entirely. None of these seem great. * In the example given of advertising algorithms in server metadata, I’m not sure how this helps. For compatibility, any server that supports EdDSA is going to have to continue supporting EdDSA or risk breaking existing clients. Likewise, any signature verification client that supports only Ed25519 may still have to support “EdDSA” and filter out any non-Ed25519 keys. * Does the usage of “enc” count as not being fully specified? I can well imagine that there are some clients that support, say, RSA-OAEP, but only support 128-bit content encryption algorithms, or only support GCM. So the same issue with not specifying the curve also applies when not specifying the content encryption algorithm. * The draft states that having different algorithm identifiers for different RSA key sizes is not useful, but actually some HSMs only support specific key sizes for RSA, and an implementation may want to restrict key sizes for efficiency reasons (even more so with PQC). If we take this draft to its logical conclusion, we’d surely end up with “alg” being more akin to TLS 1.2 ciphersuites. But that’s very different to where we are now, and I note that TLS 1.3 has moved in the opposite direction: negotiating curves and other parameters externally to the cipher suite. Otherwise, we’ll end up with a combinatorial explosion of new algorithm identifiers. So I think it’s a “no” from me on adopting this draft, and the effort should be spent rather fixing the negotiation mechanisms of the protocols that are having issues. Because they will need to do that anyway for all the degrees of freedom that are still not nailed down by these “fully specified” identifiers. — Neil > On 2 Jan 2024, at 19:13, Karen ODonoghue <[email protected]> wrote: > > > JOSE working group members, > > This email starts a two week call for adoption for: > https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/ > > As discussed at the November IETF meeting, with the approved expansion of the > charter to include maintenance items, this document is now within scope. > > Please reply to this email with your comments on the adoption of this > document as a starting point for the related JOSE work item. > > This call will end on Wednesday, 17 January 2024. > > Thank you, > JOSE co-chairs > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
