Subject: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

From: Anders Rundgren <[email-masked]>
Date: Sat, 5 Jun 2021 08:17:48 +0200

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.

I don't know how FIDO/WebAuthn will get out of this quagmire but personally I have "hijacked" the currently unassigned -9 for a signature scheme which follows what I have previously done in JSON. Here is the algorithm table for what I call COSE Signature Format (CSF):
https://cyberphone.github.io/javaapi/org/webpki/cbor/package-summary.html#csf-algorithms

Ideally, two new algorithm identifiers could be defined which are better aligned with the EC and RSA schemes which do not suffer from this problem.

Thanx,
Anders

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 5 Jun 2021 10:49:58 +0300

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

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 5 Jun 2021 10:46:49 +0200

> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 19 Jun 2021 14:19:08 +0300

> 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).

> - follows (albeit in a reversed fashion) your ideas about key-driven

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.

> 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