On 7 May 2024, at 10:29, Ilari Liusvaara <[email protected]> wrote:
>
> On Mon, May 06, 2024 at 02:40:32PM +0100, Neil Madden wrote:
>
>> So the draft needs to be substantially rewritten to reflect what it
>> is actually now proposing. It also, ironically, needs to flesh out
>> what “fully-specified” means, because that description is very vague.
>> (eg it seems key sizes do not need to be specified, but curves do, and
>> it refers to KDFs and other things that are not in scope). Perhaps
>> rewrite it as a more focused draft saying that *elliptic curve
>> signature* algorithms should specify the curve specifically.
>
> I find the distinction between "fully-specified" and "polymorphic"
> clear. It is about if "alg" value alone is enoguh to specify the
> cryptographic operation the layer performs.
>
> For RSA, it is still the same formula regardless how many bits e, d and
> n have, so RSA key size does not factor in. Thus, RS256 can be fully
> specified regardless of lacking key size.
>
> And I think most RSA verifiers should be able to deal with any key size
> multiple of 8 bits between 2048 and 8192 bits. However, there are flawed
> RSA key generators that can generate keys with one less bit than
> intended (e.g., product of two 1024-bit primes might only be 2047-bit).
>
> For EdDSA, there is huge difference between Ed25519 and Ed448, so those
> are definitely different crpytographic operations.
Is there a huge difference? RFC 8032 (which I’m sure you’re familiar with!)
says that it is a single algorithm (EdDSA), instantiated with two different
curves.
What about applications that only accept canonical signatures for EdDSA (eg for
consensus)? Is that a change in the cryptographic operation or not? (It is if
you consider multiplying out the cofactor or not). So that choice should be
reflected in any fully-specified algorithm.
>
> For ECDSA, one could argue if curve factors into cryptographic operation
> performed or not. However, for each curve, there is single preferred
> hash function, and anything else gives interoperability problems.
> E.g., P-256 should always go with SHA256. So those should still be
> treated together.
Indeed, curve doesn’t really factor into the cryptographic operation performed,
so this undermines the idea that it is about fully-specifying the cryptographic
algorithm. I’m not really sure the situation is very different between ECDSA
and EdDSA on this respect.
And if we’re going to fully-specify the hash function, then that suggests that
for encryption algorithms that “enc” should be smushed into the algorithm
identifier. Otherwise, why are we saying one use of symmetric cryptography is
somehow essential to the algorithm and the other isn’t? Both can be varied
independently.
I’ll leave you all with this quote from the Cloudflare blog post that welcomed
TLS 1.3 into the world [1]:
"Ciphersuites in previous versions of TLS had grown into monstrously large
alphabet soups. Examples of commonly used cipher suites are: DHE-RC4-MD5 or
ECDHE-ECDSA-AES-GCM-SHA256. Each ciphersuite was represented by a code point in
a table maintained by an organization called the Internet Assigned Numbers
Authority (IANA). Every time a new cipher was introduced, a new set of
combinations needed to be added to the list. This resulted in a combinatorial
explosion of code points representing every valid choice of these parameters.
It had become a bit of a mess."
I look forward to us correcting the same mistake currently being made in JOSE
in a few years time. Or we could just update the draft to match what seems to
be the reality: nobody actually wants encryption algorithms to be fully
specified, because it would lead to an explosion of new identifiers. All people
really want to do is to add a couple of new signature identifier values to hack
around a mis-design of various protocols.
[1] https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
— Neil
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
