Extension Idea: Support for SSH and Other Arbitrary Signed Challenges

Today's Challenge

I started a proof-of-concept SSH agent backed by a FIDO token. This mostly
went well: I use the "registration" process to generate a keypair, extract
the curve points, and even encode them for an SSH-format ECDSA key.

Things break down for signing the challenges, though. FIDO2 supports the
necessary algorithms and hashes, but the tokens always prefix challenges
with a counter, a small bitfield, and other data before signing [1], making
the signature unusable for any API that can't accommodate the signer adding
a prefix on the challenge.

SSH uses its own system of nonces that operates outside the signing API (in
the form of session IDs) [2]. Consequently, the SSH agent protocol doesn't
support the signer adding a prefix to the challenge before signing, at
least for ECDSA keys [3]. It would be possible to extend the SSH server and
client to support including prefix data in signatures, but that would
probably take 10+ years to roll out to a critical mass of servers and
clients. Similar problems exist for supporting X.509 and GPG signing
requirements.

Proposed Extensions

We should consider adding a FIDO extension for both registration and
authentication to support "raw signing" of bytes with no prefixing or other
alteration. To avoid risk to the primary signing functionality (e.g. replay
attacks or faking the existence of a clone), it could use a different
keypair than the main one for the RP+user. Use of a different keypair would
be why we would also need a registration extension: a different public key
necessitates a way to obtain that public key.

The protocol for the extensions would be straightforward. The registration
extension would return the second, raw-signing public key for the RP+user.
The authentication extension would return the challenge as signed by the
second, raw-signing private key without alteration. Neither would require
any request parameters (beyond those mandated in the FIDO2 spec).

This would allow major smart card-compatible APIs to support -- with
client-side changes alone -- what I hope will become the most widely
accessible and inexpensive smart card framework on the market.

[1] https://www.w3.org/TR/webauthn/#sctn-attestation
[2] https://tools.ietf.org/html/rfc4252#section-7
[3] https://tools.ietf.org/html/rfc5656#section-3.1.2