Re: [jose] [COSE] Call for Adoption: draft-jones-jose-fully-specified-algorithms

[Orie Steele <[e-mail]>]

David, also commented on EdDSA &  ECDSA design in a follow up post:

> Since I suspect this is where some of the confusion comes from, let me
point something out from RFC 8032: Ed25519 is *not* an elliptic curve in
the way that P-256 is. RFC 8032 uses edwards25519 to refer to the elliptic
curve in Ed25519. This is a name you've probably never seen used because it
is an implementation detail of Ed25519. When using the primitive, you don't
actually care how it is defined, just the name (Ed25519) and interface.

Now, sometimes people are a bit sloppy and say "Ed25519" to mean the curve.
The original Ed25519 paper didn't formally give a name to the curve itself,
and if you know you're talking about an elliptic curve instead of a
signature scheme, this is unambiguous. There's only one curve in Ed25519,
realistically, we'll probably never instantiate another signature scheme
with that curve. SHA-512 is fine.

*But due to the history of people tryingto separate key and use (always a
mistake), it's helpful to have precisenames for individual components when
this confusion comes up.*



*The fact that P-256-based primitives leak their parameterization is a
flawin how we defined those primitives, not an analogy to apply to
otherschemes. We should move away from that as much as possible.* This is
analogous to how the X.509 work shifted from a heavily parameterized in
draft-ietf-curdle-pkix-00 to distinct top-level OIDs in RFC 8410

- https://mailarchive.ietf.org/arch/msg/tls/wX-vDRr8Kbxa2zK1CyTsXsl9_hI/

I'd argue JOSE and COSE got Ed25519 / Ed448 registration for RFC8032 about
as wrong as you can get it, something that better guidance can help guard
against happening in the future.

crv: Ed25519, alg: EdDSA / crv: Ed448, alg: EdDSA

When in reality it is: crv: edwards25519, alg: Ed25519, and crv:
edwards448, alg: Ed448

The specific names don't matter here, what matters is full specification
eddsa-2021 would have been a better name if it implied Ed25519.

I have found several of the arguments against duplication registrations
compelling, and I admit that encryption has its own set of unique
challenges.

I really appreciate the comments we have gotten on this topic.

Regards,

OS




On Mon, Jan 8, 2024 at 11:04 AM Ilari Liusvaara <[e-mail]>
wrote:

> On Mon, Jan 08, 2024 at 09:15:48AM -0600, Orie Steele wrote:
> >
> > > The fact that Ed25519 and
> > Ed448 are both EdDSA instantiations, or that the X25519 algorithm and the
> > Ed25519 algorithm have a similar structure are just useful properties
> when
> > analyzing, specifying, or implementing a primitive. It is not relevant to
> > protocols that *use* a primitive. As far as we're concerned, these are
> just
> > names that conform to the signature scheme interface (KeyGen() -> (pk,
> sk),
> > Sign(sk, msg) -> sig, and Verify(pk, msg, sig)).
> >
> > To me this last part is most compelling.
> >
> > If changing a part of the named algorithm, breaks this interface, then
> the
> > algorithm is fully specified.
> >
> > key-gen (signature type) --> private-key --> public-key --> signature
> > (signature type)
> >
> > in data integrity, changing the hash function used, or the
> canonicalization
> > algorithm breaks the signature verification.
> >
> > the attacker can change these before verification succeeds.
> >
> > As a practical matter, I cannot generate a key pair with just the word
> > "EdDSA", I need to know the curve.
> >
> > The same is also true of ECDSA.
> >
> > Differences in registries for algorithms can impact how easy it is to
> build
> > safe APIs or negotiate, for example:
> >
> >
> https://github.com/panva/jose/blob/main/docs/functions/key_generate_key_pair.generateKeyPair.md
> >
> > For none fully specified algorithms, the crv property is required to
> > generate a key.
>
> I think part of confusion is confusing encryption and signing.
> Encryption in JOSE, let alone COSE, is very flexible, making fully
> specified approach infeasible. But signing is relatively simple.
>
> However, there is a subtle difference between ECDSA and EdDSA. Both
> are paramerized by curve and hash function. However, ECDSA keys only
> depend on curve, while EdDSA keys depend on both curve and hash.
>
> ML-DSA ("Dilithium") and SLH-DSA ("SPINCS+") work like EdDSA despite
> completely different parametrizations. RSA works like ECDSA.
>
> Thus:
> - EdDSA keys are always fully specified.
> - ML-DSA/SLH-DSA keys are always fully specified.
> - In COSE, ECDSA keys are fully specified iff there is "alg".
> - In JOSE, ECDSA keys are currently fully specified (only one hash
>   function is allowed for each curve).
> - In COSE and JOSE, RSA keys are fully specified iff there is "alg".
>
> And I think a second source of confusion is keys being fully specified
> versus algorithms implying key type. For signing, the latter fails for
> EdDSA in COSE and JOSE (alg overloading), and ECDSA in COSE (multiple
> allowed curves).  Some applications misuse signature algorithms in COSE
> and JOSE to imply key types.
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>