when writing an attestation blob for a FIDO key, record all the data
needed to verify the attestation. Previously we were missing the
"authenticator data" that is included in the signature.

spotted

when writing an attestation blob for a FIDO key, record all the data
needed to verify the attestation. Previously we were missing the
"authenticator data" that is included in the signature.

spotted by Ian Haken
feedback Pedro Martelletto and Ian Haken; ok markus@

show more ...

Add RCS IDs to the few files that are missing them;
from Pedro Martelletto

Add support for FIDO webauthn (verification only). webauthn is a
standard for using FIDO keys in web browsers. webauthn signatures are
a slightly different format to plain FIDO signatures - this supp

Add support for FIDO webauthn (verification only). webauthn is a
standard for using FIDO keys in web browsers. webauthn signatures are
a slightly different format to plain FIDO signatures - this support
allows verification of these. Feedback and ok markus@

show more ...

fix non-ASCII quote that snuck in; spotted by Gabriel Kihlman

clarify role of FIDO tokens in multi-factor authentictation;
mostly from Pedro Martelletto

when signing a challenge using a FIDO toke, perform the hashing in the
middleware layer rather than in ssh code. This allows middlewares that
call APIs that perform the hashing implicitly (including

when signing a challenge using a FIDO toke, perform the hashing in the
middleware layer rather than in ssh code. This allows middlewares that
call APIs that perform the hashing implicitly (including Microsoft's
AFAIK). ok markus@

show more ...

Fix some typos and an incorrect word in docs. Patch from itoama at live.jp
via github PR#172.

changes to support FIDO attestation

Allow writing to disk the attestation certificate that is generated by
the FIDO token at key enrollment time. These certificates may be used
by an out-of-band wor

changes to support FIDO attestation

Allow writing to disk the attestation certificate that is generated by
the FIDO token at key enrollment time. These certificates may be used
by an out-of-band workflow to prove that a particular key is held in
trustworthy hardware.

Allow passing in a challenge that will be sent to the card during
key enrollment. These are needed to build an attestation workflow
that resists replay attacks.

ok markus@

show more ...

improve the error message for u2f enrollment errors by making
ssh-keygen be solely responsible for printing the error message and
convertint some more common error responses from the middleware to
a

improve the error message for u2f enrollment errors by making
ssh-keygen be solely responsible for printing the error message and
convertint some more common error responses from the middleware to
a useful ssherr.h status code. more detail remains visible via -v
of course.

also remove indepedent copy of sk-api.h declarations in sk-usbhid.c
and just include it.

feedback & ok markus@

show more ...

Extends the SK API to accept a set of key/value options for all
operations. These are intended to future-proof the API a little by
making it easier to specify additional fields for without having to

Extends the SK API to accept a set of key/value options for all
operations. These are intended to future-proof the API a little by
making it easier to specify additional fields for without having to
change the API version for each.

At present, only two options are defined: one to explicitly specify
the device for an operation (rather than accepting the middleware's
autoselection) and another to specify the FIDO2 username that may
be used when generating a resident key. These new options may be
invoked at key generation time via ssh-keygen -O

This also implements a suggestion from Markus to avoid "int" in favour
of uint32_t for the algorithm argument in the API, to make implementation
of ssh-sk-client/helper a little easier.

feedback, fixes and ok markus@

show more ...

document SK API changes in PROTOCOL.u2f

ok markus@

basic support for generating FIDO2 resident keys

"ssh-keygen -t ecdsa-sk|ed25519-sk -x resident" will generate a
device-resident key.

feedback and ok markus@

SSH U2F keys can now be used as host keys. Fix a garden path sentence.
ok markus@

add a note about the 'extensions' field in the signed object

some more corrections for documentation problems spotted by Ron Frederick

document certifiate private key format
correct flags type for sk-ssh-ed25519@openssh.com keys

loading security keys into ssh-agent used the extension constraint
"sk-provider@openssh.com", not "sk@openssh.com"; spotted by Ron Frederick

chop some unnecessary and confusing verbiage from the security key
protocol description; feedback from Ron Frederick

tweak wording

adjust on-wire signature encoding for ecdsa-sk keys to better match
ec25519-sk keys. Discussed with markus@ and Sebastian Kinne

NB. if you are depending on security keys (already?) then make sure yo

adjust on-wire signature encoding for ecdsa-sk keys to better match
ec25519-sk keys. Discussed with markus@ and Sebastian Kinne

NB. if you are depending on security keys (already?) then make sure you
update both your clients and servers.

show more ...

document ed25519-sk pubkey, private key and certificate formats

correct order or ecdsa-sk private key fields

correct description of fields in pub/private keys (was missing curve
name); spotted by Sebastian Kinne

remove extra layer for ed25519 signature; ok djm@

update sk-api to version 2 for ed25519 support; ok djm

fix miscellaneous text problems; ok djm@