On Sat, Jun 05, 2021 at 10:46:49AM +0200, Anders Rundgren wrote: > 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 :)
Is my understanding correct that FIDO/WebAuthn create key API takes in COSE _algorithm_ number and uses it to decide type of key to create? If so, FIDO/WebAuthn create key API is just plain flawed. I do not think it is good idea to try "fix" that in COSE, especially given that the changes seem to increase risk of error in other contexts. One really nasty hack that would not cause too much security trouble would be to reserve algid -9 so that FIDO/WebAuthn create key API interprets any request with algid=-9 as request to create Ed448 key that is to be used with EdDSA(algid=-8). But nothing else recognizes that as anything valid. In practicular, a message with algid -9 gets rejected as unknown signature algorithm (even if key is Ed448). > 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. IMO: Reversing key-driven signature algorithms is VERY bad idea. The whole purpose is to force implementation do needed checks, instead of allowing implementation to skip them and that being a potential security problem. I have coded signature validation, and found that I need to plub in the type of key. Extra code yes, but if I did not have to do that, I might have forgotten to check the key type, possibly resulting in an security issue. And for not breaking existing code, all EdDSA signatures must use the -8 algid, so the Ed448 algid can not appear in any message. > 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 :) If my understanding of the issue is correct, the API should be deprecated and replaced by new one. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
