Apply emlun's suggestions from code review

Co-authored-by: Emil Lundberg <emil@yubico.com>

index.bs

@@ -6874,15 +6874,15 @@ The weight that [=[RPS]=] give to the presence of a signature from a [=device-bo
         ;
         ; Attestation statement formats define the \`fmt\` and \`attStmt\` members of
         ; $$attStmtType.
-        ; Note that `fmt` and `attStmt` are top-level members of `attObjForDevicePublicKey`.
+        ; Note that \`fmt\` and \`attStmt\` are top-level members of \`attObjForDevicePublicKey\`.
         ;
         ; In summary, the \`attStmt\` will (typically) contain:
         ;   (1) a SIGNATURE value calculated (using the attestation private key)
         ;       over (prefix || aaguid || dpk || nonce) where \`prefix\` is
         ;       h'64657669636520626f756e64206b6579206174746573746174696f6e20736967
         ;         00ffffffff'.
         ;       (See the attestation calculations section, below, for a discussion
-        ;       about the purpose of this `prefix` value.)
+        ;       about the purpose of this \`prefix\` value.)
         ;   (2) the attestation certificate or public key, and supporting certificates,
         ;       if any.
         ;
@@ -6963,12 +6963,12 @@ The weight that [=[RPS]=] give to the presence of a signature from a [=device-bo
 
 ##### Attestation calculations ##### {#sctn-device-publickey-attestation-calculations}
 
-When computing attestations, the process in [[#sctn-generating-an-attestation-object]] takes two inputs: `authData` and `hash`. When calculating an attestation for a [=device-bound key=], the typical value for `hash` hashes over the attestation signature itself, which is impossible. Also the attestation of a [=device-bound key=] is potentially used repeatedly, thus may want to be cached. But signing over values that include [=[RP]=]-chosen nonces, like the [=hash of the serialized client data=], make that impossible.
+When computing attestations, the process in [[#sctn-generating-an-attestation-object]] takes two inputs: `authData` and `hash`. When calculating an attestation for a [=device-bound key=], the typical value for `hash` hashes over the attestation signature itself, which is impossible. Also the attestation of a [=device-bound key=] is potentially used repeatedly, thus may want to be cached. But signing over values that include [=[RP]=]-chosen nonces, like the [=hash of the serialized client data=], makes that impossible.
 
 Therefore when calculating an attestation for a [=device-bound key=], the inputs are:
 
     * For `authData`, substitute the concatenation of the byte string h'64657669636520626f756e64206b6579206174746573746174696f6e2073696700ffffffff' and the value of |aaguid| from the extension output.
-    * For `hash`, substitute the concatenation of the |dpk| and |nonce| fields from the extension output. (The nonce may be empty.)
+    * For `hash`, substitute the concatenation of the |dpk| and |nonce| fields from the extension output. (The nonce MAY be empty.)
 
 The attestation signature is thus typically calculated over the bytes of <code>(h'64657669636520626f756e64206b6579206174746573746174696f6e2073696700ffffffff' || |aaguid| || |dpk| || |nonce|)</code>. The 37-byte prefix ensures domain separation: it takes the place of the RP ID hash, flags, and signature counter fields in those messages and ensures that no attestation signature for a [=device-bound key=] can be confused with a signature for a [=user credential=].
 
@@ -7054,7 +7054,7 @@ If the `devicePubKey` extension was included on a {{CredentialsContainer/get()|n
 
                 <dl class="switch">
                     : If |fmt|'s value is "none":
-                    :: There is no attestation signature to verify and this is a new device. Store the extracted |aaguid|, |dpk|, |scope|, |fmt|, |attStmt| values indexed to the <code>|credential|.{{Credential/id}}</code> in the [=user account=]. Terminate these verification steps.```
+                    :: There is no attestation signature to verify and this is a new device. Store the extracted |aaguid|, |dpk|, |scope|, |fmt|, |attStmt| values indexed to the <code>|credential|.{{Credential/id}}</code> in the [=user account=]. Terminate these verification steps.
 
                     : Otherwise:
                     :: Optionally, if attestation was requested and the RP wishes to verify it, verify that |attStmt| is a correct [=attestation statement=], conveying a valid [=attestation signature=], by using the [=attestation statement format=] |fmt|'s [=verification procedure=] given |attStmt|. See [[#sctn-device-publickey-attestation-calculations]].