This PR instantiates the `getDevicePublicKey` extension.

RPs desiring to have a guaranteed device-bound public key returned on `create()` and `get()` need to simply include this extension on their `create()` and `get()` calls.

On `create()`, a device-bound public key pair is created in addition to the [credential key pair](https://www.w3.org/TR/webauthn-2/#credential-key-pair), and the extension result conveys the devicePublicKey to the RP.

On `get()`, a device-bound public key pair is created if one does not yet exist, and the resulting devicePublicKey is conveyed in the extension result to the RP.

…on of dbPK

This adds a ProVerif model for the device-bound public key (device-bound key pair) extension.

revise model to have discrete message components and to leverage named_tuples.pvl and crypto.pvl.

this is the stage of development I first shared with internal colleagues post the original hand-wavy prose writeup.

Co-authored-by: Emil Lundberg <[email protected]>

Co-authored-by: Emil Lundberg <[email protected]>

Co-authored-by: J Pascoe <[email protected]>

Co-authored-by: Emil Lundberg <[email protected]>

…ion procedures

The text said that the DPK was stored on the client device, but the
client device is the device that the browser is running on, not the
authenticator. That _might_ be the same device, but it's unclear.
Clarify that the DPKs come from the authenticator.

Mirror the attestation controls for user credentials into the DPK
extension.

This change adds a section about calculating DPK attestations and
references that each time rather than duplicating the rules. It also
adds a prefix to the signed messages to ensure that DPK and user
credential attestations clearly cannot be confused.

Signing over too little is a common problem in protocols and the DPK
wasn't signing over very much. The problem is that the signature was
within the extension itself and thus couldn't easily cover the
authenticator data.

This change puts the DPK signature next to the normal signature in an
assertion, transforming that field into a CBOR array. That's fine for
assertions, but registration doesn't have such a signature output. Thus
this change drops exercising the DPK during registration:

Firstly, this is in line with the user credential which doesn't sign
during registration unless "self" attestation is used. (And "self"
attestation can be use with the DPK if desired.)

Secondly, adding an extra signature output for registration is awkward.
Putting it in the user credential attestation statement is awkward and
conflicts when user-agents replace attestation statements. Adding a new
CTAP field is possible but seems excessive since, as noted, there has
never been a signature by the user credential.