[Bug 3516] ssh-keygen when creating sk fido keys does not create sufficient data for attestation verification.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3516

--- Comment #4 from William Brown <william.brown at suse.com> ---
> The client data part of the attestation payload can be specified out-of-band through ssh-keygen -O challenge=, https://man.openbsd.org/ssh-keygen#challenge.

This doesn't help when the challenge *isn't* specified though, meaning
that if attestation is requested, challenge either has to be a
mandatory argument and ssh-keygen should error or that the challenge
needs to be added to the attestation format so that the attestation can
be validated. 

> in most cases involving USB or NFC security keys, the format will be "packed" or "fido-u2f", and the root CA published by the vendor of the security key (e.g. https://developers.yubico.com/U2F/yubico-u2f-ca-certs.txt). What is current in place should be enough to satisfy that scenario.

In packed https://w3c.github.io/webauthn/#sctn-packed-attestation the
specification states:

"""
x5c
The elements of this array contain attestnCert and its certificate
chain (if any), each encoded in X.509 format. The attestation
certificate attestnCert MUST be the first element in the array.
"""

However the current attest format that is created by ssh-keygen does
not contain the full x5c chain, it only contains the attestation (leaf)
certificate meaning that it is not always true that the vendors CA
certificate is sufficient to validate the attestation since the chain
may be missing. 


> Going forward, we might want to embed the attestation format and the entire attestation statement (fido_cred_fmt() and fido_cred_attstmt_ptr() respectively) in the attestation blob.

Yes this would resolve the issues I have raised with regard to x5c
chains as well as the current inability to validate ecdaa attestations
(which do not use x5c).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.