Defining new OIDs to facilitate WebAuthn interoperability with CMS

[corrideat]

trafficstars

This relates indirectly to #799.

Currently, WebAuthn signatures are constructed in a 'special' way, which includes a hash of the user-provided data and another parameters. Generally, this is:

dataToBeSigned <- authenticatorData || DIGEST(data).

For example reference:

From 8.3. TPM Attestation Statement Format

Let authenticatorData denote the authenticator data for the attestation, and let clientDataHash denote the hash of the serialized client data.

Concatenate authenticatorData and clientDataHash to form attToBeSigned.

From 8.2. Packed Attestation Statement Format

the authenticator produces the sig by concatenating authenticatorData and clientDataHash, and signing the result using

And so on from the rest of spec, where FIDO seems to be an exception:

From 8.6. FIDO U2F Attestation Statement Format

(0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F)

Now, I'm currently working on interoperating with CMS (i.e., RFC 5652 or PKCS#7) and handling WebAuthn assertions is challenging because there is no 'proper' way to indicate how they should be validated, as compared with algorithms that are well-known in ASN.1. For instance, setting the algrithm to ecdsa-with-SHA256 (1.2.840.10045.4.3.2) would almost work, but the data need to be treated in a special way, as 'regular' ecdsa-with-SHA256 doesn't go over a hash of the message.

Proposed Change

This is not a change that affects WebAuthn per se, but rather a request to collaborate with IANA (or altenatively, ISO / ITU-T) to define OIDs and their respective parameters that can be used to handle WebAuthn assertions in CMS and the rest of the ASN.1 world.

For the common case of dataToBeSigned <- authenticatorData || DIGEST(data), this may or may not require a new algorithm OID to be defined (likely yes, for backwards compatibility), but it would require at least creating a new algorithm parameter to include authenticatorData, and for any other parameters needed.

[agl]

From the WG call of 2024-02-28: we agree that you would probably want some specific OIDs for this case. If you can get them assigned from a reasonably canonical arc, we would consider listing them in the spec. We don't know that the W3C itself has an arc however.