docs: Update crypt{enroll,setup} limitations regarding FIDO2

diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml
index 1e9a4457c2cabccc2502a5e1ab10bf8f4dba3dad..8af75d1523bcce49d134bf2dd8d89159e5a45e86 100644 (file)
--- a/man/systemd-cryptenroll.xml
+++ b/man/systemd-cryptenroll.xml
@@ -64,17 +64,17 @@
     <title>Limitations</title>
 
     <para>Note that currently when enrolling a new key of one of the five supported types listed above, it is
-    required to first provide a passphrase or recovery key (i.e. one of the latter two key types). For
-    example, it's currently not possible to unlock a device with a FIDO2 key in order to enroll a new FIDO2
-    key. Instead, in order to enroll a new FIDO2 key, it is necessary to provide an already enrolled regular
-    passphrase or recovery key. Thus, if in future key roll-over is desired it's generally recommended to
-    combine TPM2, FIDO2, PKCS#11 key enrollment with enrolling a regular passphrase or recovery key.</para>
-
-    <para>Also note that support for enrolling multiple FIDO2 tokens is currently not too useful, as while
-    unlocking <command>systemd-cryptsetup</command> cannot identify which token is currently plugged in and
-    thus does not know which authentication request to send to the device. This limitation does not apply to
-    tokens enrolled via PKCS#11 — because tokens of this type may be identified immediately, before
-    authentication.</para>
+    required to first provide a passphrase, a recovery key or a FIDO2 token. It's currently not supported to
+    unlock a device with a TPM2/PKCS#11 key in order to enroll a new TPM2/PKCS#11 key. Thus, if in future key
+    roll-over is desired it's generally recommended to ensure a passphrase, a recovery key or a FIDO2 token
+    is always enrolled.</para>
+
+    <para>Also note that support for enrolling multiple FIDO2 tokens is currently limited. When multiple FIDO2
+    tokens are enrolled, <command>systemd-cryptseup</command> will perform pre-flight requests to attempt to
+    identify which of the enrolled tokens are currently plugged in. However, this is not possible for FIDO2
+    tokens with user verification (UV, usually via biometrics), in which case it will fall back to attempting
+    each enrolled token one by one. This will result in multiple prompts for PIN and user verification. This
+    limitation does not apply to PKCS#11 tokens.</para>
   </refsect1>
 
   <refsect1>