[Writing as an individual - not a chair]
The WebAuthn and FIDO2 working group members had thought that the COSE
algorithm semantics were the same as those for JOSE, where algorithm
identifiers are not polymorphic. They were wrong, but that's water under the
bridge now. The FIDO/WebAuthn usage of the algorithm identifiers requires that
the identifiers used unambiguously specify all algorithm parameters. (Note
that FIDO/WebAuthn does not use COSE signatures - only COSE algorithm
identifiers.) They have done what they needed to do to remove the ambiguities
arising in practice from use of polymorphic algorithm identifiers for their use
cases.
Note that by the time that we registered the ES256K algorithm for signing with
the secp256k1 curve in RFC 8812, we were aware of the problem and intentionally
made ES256K non-polymorphic - both for JOSE and for COSE.
I believe that we should create a policy requiring that all future algorithm
registrations should be non-polymorphic. Furthermore, I believe we should
consider defining and registering new non-polymorphic algorithm identifiers so
that use of the existing polymorphic algorithm identifiers can be avoided and
deprecated.
-- Mike
-----Original Message-----
From: COSE <[email protected]> On Behalf Of Ilari Liusvaara
Sent: Saturday, June 19, 2021 4:19 AM
To: Anders Rundgren <[email protected]>
Cc: [email protected]
Subject: Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm
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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
