TPM Attestation Statement Format: Missing COSE Key algorithm Identifier and clarification.

[akshayku]

Many TPM attestations implementations ONLY supports RSASSA-PKCS1-v1_5 w/SHA1 and there is no COSE algorithm identifier defined currently. Here is the proposed addition to list of COSE algorithms.

• Name: RS1
• Value: -262 (This is the next value in this section.)
• Description: RSASSA-PKCS1-v1_5 w/ SHA1. Applicable to some current implementations of TPM 2.0 attestation signatures.
• Reference: Section 8.2 of [RFC8017]
• Recommended: No

Clarification to attToBeSigned in https://w3c.github.io/webauthn/#tpm-attestation

Existing sentence:

• Generate a signature using the procedure specified in [TPMv2-Part3] Section 18.2, using the attestation private key and setting the qualifyingData parameter to attToBeSigned.

This qualifyingData is also called extraData in the TPM Spec where it is has the following definition:

• extraData : TPM2B_DATA external information supplied by caller. NOTE A TPM2B_DATA structure provides room for a digest and a method indicator to indicate the components of the digest. The definition of this method indicator is outside the scope of this specification.

Proposed change:

• Generate a signature using the procedure specified in [TPMv2-Part3] Section 18.2, using the attestation private key and setting the extraData parameter to the digest of the attToBeSigned using the hash algorithm corresponding to the “alg” signature algorithm. For RS256 this would be a SHA256 digest.

[selfissued]

The corresponding validation procedure currently includes:
Verify that extraData is set to |attToBeSigned|.

Should this be changed to:
Verify that extraData is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg".

It seems like this would be required to be consistent with the signing procedure.

[jyasskin]

Double-checking: does the existence of SHA-1 collisions make these attestations fundamentally insecure? If so, it probably doesn't make sense to support RPs trusting them. If not, please ignore me. :)

[selfissued]

I know of no effective means of creating or utilizing SHA-1 collisions in the RSASSA-PKCS1-v1_5 w/ SHA1 context.