summaryrefslogtreecommitdiff
path: root/PROTOCOL.u2f
diff options
context:
space:
mode:
authordjm@openbsd.org <djm@openbsd.org>2020-01-28 08:01:34 +0000
committerDamien Miller <djm@mindrot.org>2020-01-29 18:52:55 +1100
commit24c0f752adf9021277a7b0a84931bb5fe48ea379 (patch)
treecd1b9474e73ad7647b4ad88775365e7430d3fe64 /PROTOCOL.u2f
parent156bef36f93a48212383235bb8e3d71eaf2b2777 (diff)
upstream: 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@ OpenBSD-Commit-ID: 457dc3c3d689ba39eed328f0817ed9b91a5f78f6
Diffstat (limited to 'PROTOCOL.u2f')
-rw-r--r--PROTOCOL.u2f21
1 files changed, 12 insertions, 9 deletions
diff --git a/PROTOCOL.u2f b/PROTOCOL.u2f
index 58f75ba28..748111d56 100644
--- a/PROTOCOL.u2f
+++ b/PROTOCOL.u2f
@@ -141,17 +141,20 @@ least manufacturer and batch number granularity. For this reason, we
141choose not to include this information in the public key or save it by 141choose not to include this information in the public key or save it by
142default. 142default.
143 143
144Attestation information is very useful however in an organisational 144Attestation information is useful for out-of-band key and certificate
145context, where it may be used by a CA as part of certificate 145registration worksflows, e.g. proving to a CA that a key is backed
146issuance. In this case, exposure to the CA of hardware identity is 146by trusted hardware before it will issue a certificate. To support this
147desirable. To support this case, OpenSSH optionally allows retaining the 147case, OpenSSH optionally allows retaining the attestation information
148attestation information at the time of key generation. It will take the 148at the time of key generation. It will take the following format:
149following format: 149
150 150 string "ssh-sk-attest-v00"
151 string "sk-attest-v00"
152 uint32 version (1 for U2F, 2 for FIDO2 in future)
153 string attestation certificate 151 string attestation certificate
154 string enrollment signature 152 string enrollment signature
153 uint32 reserved flags
154 string reserved string
155
156OpenSSH treats the attestation certificate and enrollment signatures as
157opaque objects and does no interpretation of them itself.
155 158
156SSH U2F signatures 159SSH U2F signatures
157------------------ 160------------------