definition of a webauthn varsig type #11
Conversation
|
We require contributors to sign our Contributor License Agreement, and we don't have you on file. In order for us to review and merge your code, either PR in your signature like so if you have no other disclosures to make or reach out to one more of the codeowners (@bumblefudge @expede @oed) to get yourself added manually. |
README.md
Outdated
| sig-bytes = OCTET | ||
| ``` | ||
|
|
||
| The Webauthn varsig header notifies the consumer that the signature is generated via webauthn. Verification must therefor rely on the [`client-data-json`][Webauthn Client Data JSON] JSON object and the [`authenticator-data`][Webauthn Authenticator Data] bytestring. The `client-data-json` object is self-describing and thus does not need to have a length prefix, however it must include the required fields as specified by the Webauthn spec. The `authenticator-data` can vary in length but must have at least 37 bytes, and so requires the `authenticator-data-length` varint to specify it's length. The length of `sig-bytes` can be known via the [`attestedCredentialData`][Webauthn Attested Credential Data] portian of the [`authenticator-data`][Webauthn Authenticator Data] byte string. In order to keep the varsig verifiable and concise, the signed payload MUST be included via CID as the `challenge` field of the [`client-data-json`][Webauthn Client Data JSON]. |
There was a problem hiding this comment.
reminder: say this isn't the PRF thing that's currently an extension but will be core webauthn some day (as per brook's comment in today's meeting)
|
|
||
| The Webauthn varsig header notifies the consumer that the signature is generated via webauthn. Verification must therefor rely on the [`client-data-json`][Webauthn Client Data JSON] JSON object and the [`authenticator-data`][Webauthn Authenticator Data] bytestring. The `client-data-json` and `authenticator-data` byte strings must conform to the formats specified by the Webauthn spec. To enable the inclusion of the varsig in a byte stream, they each require a varint-encoded length prefix (`client-data-length` and `authenticator-data-length` respectively). | ||
|
|
||
| The signature itself is encoded as a varsig-body, containing hash and encoding info in the `signature` field. For example, a webauthn authenticator using `P-256` keys would result in a `signature` field which is a varsig-body conforming to the [`ES256` varsig body defined in section 5.3.1](#5.3.1-example:-es256). The signed payload is included in the signed data as the `challenge` field of the `client-data-json` as a [Multihash][Multihash]. This multihash MUST be made using the result of encoding the payload according to the parameters defined by the `signature` varsig body (for example, a DAG-CBOR encoded payload must have `signature.encoding-info` set to match). The `signature` field MUST be a signature type supported by the WebAuthn specification. |
There was a problem hiding this comment.
Why use challenge = multihash and not challenge = cid? This way we would not need the signature.encoding-info field. (Afaik, the challenge can be longer than 32 bytes).
There was a problem hiding this comment.
so that the other defined varsigs could be entirely reused instead of defining cut-down versions specific to webauthn. there will also be a tiny saving on length as the encoding won't be part of a base64 string, but that wasn't my main reason
There was a problem hiding this comment.
Ok, it would be helpful if you provided an example here to make the discussion easier.
Not sure what you mean by "base64 string"
There was a problem hiding this comment.
will add an example 👍. For the base64 string, the client-data-json's challenge field which gets signed over is always a base64 encoding of the challenge which is passed in (as a byte array). Because the client-data-json is passed back as a byte array of what was signed, we can't repack it to make anything in there smaller.
There was a problem hiding this comment.
Btw, it might make sense to sign over the CID regardless in light of #12
There was a problem hiding this comment.
the CID doesnt capture the signature algorithm though, and indeed when it comes to webauthn there is no way to embed the signature algorithm in the challenge as the authenticator selection is up to the user via the UI. I can though see how it might be useful to capture the payload encoding in the signed data
This PR specifies the format and verification process of a varsig representing the result of a Webauthn assertion, the output of a Webauthn authentication ceremony. There are still some open questions but I think the general shape is there.