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. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
