[webauthn] Defining new OIDs to facilitate WebAuthn interoperability with CMS (#2026)

corrideat has just created a new issue for https://github.com/w3c/webauthn:

== Defining new OIDs to facilitate WebAuthn interoperability with CMS ==
This relates indirectly to #799.

Currently, WebAuth 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.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2026 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 16 February 2024 10:07:56 UTC