On 2021-06-05 9:49, Ilari Liusvaara wrote:
On Sat, Jun 05, 2021 at 08:17:48AM +0200, Anders Rundgren wrote:
F.Y.I.
When a key is to be generated, the FIDO/WebAuthn "create" API provides
a list of COSE signature algorithms. To save some bytes they
overloaded EdDSA so that it would mean EdDSA with an Ed25519 key.
Seen in retrospect this was obviously a mistake since this doesn't
extend to Ed448.
However, I believe the mistake was really making EdDSA a signature
algorithm. The "family" concept fits squarely with most
cryptographic APIs that typically only deals with specific
algorithms.
IMO, the mistake is using signature algorithm to specify a key type.
That is not just wrong for EdDSA, it is also wrong for ECDSA (e.g,
ES512 does not have unique key type).
The key create command should take the algorithm of the key as
parameter, and the sole cryptogrphic algorithm it is intended for, in
case there are multiple possibilities (using the same key with multiple
algorithms is not cryptographically kosher).
Almost every signature framework I have ever seen contains the mistake
that the framework lets message and key contradict each other. Usually
the specification says something like "MUST check", but in practice this
is a major source of security issues. Then some folks have weaponized
these issues to fuel anti-algorithm-agility agenda. For COSE, I spot 6
classes (RSA, ECDSA, ECDSA with bitcoin curve, Ed25519/Ed448, HSS-LMS
and WalnutDSA) of incompatible non-overlapped signature algorithms.
In one of my projects, I had case of flawed signature key create command
(it was not this, but some other interface flaw). I ended up creating
another key create command with saner semantics.
Leaving broken cryptographic frameworks aside, how about a
"historical compromise" where EdDSA without any specific key
information would default to Ed25519 keys?
In the same vein the currently unassigned -9 could do the same for
Ed448 just to keep the symmetry :)
The revised identifiers could for example be called something like
EdDSA[Ed25519] and EdDSA[Ed448] respectively.
This is indeed a bit ugly but it
- doesn't break existing code
- follows (albeit in a reversed fashion) your ideas about key-driven
signature algorithms.
The only viable alternative (AFAICT...), is either stalling progress
by forcing API upgrades, or continued "misuse" of existing standards.
It is a bit like choosing between pest or cholera :)
Anders
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
