supplementalPubKeys attestation incompatible with most verification procedures

[emlun]

The supplementalPubKeys extension states for its attestation signing procedure:

Therefore when calculating an attestation for a supplemental public key, the inputs are:

• For authData, substitute the concatenation of the byte string h’737570706c656d656e74616c5075624b657973206174746573746174696f6e2e00ffffffff' and the value of aaguid from the extension output.
• For hash, substitute the concatenation of the spk and nonce fields from the extension output. (The nonce MAY be empty.)

However, this is incompatible with most of the attestation verification procedures since most of them extract one or more fields from the authData argument:

• packed attestation:

  • (If x5c is present:) If attestnCert contains an extension with OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) verify that the value of this extension matches the aaguid in authenticatorData.

  • The AAGUID does exist in its normal location in the modified authData argument, but the AT flag is set to zero, so implementations may refuse to access it and/or reject the data structure due to unknown trailing bytes.

  • (If x5c is not present:) Validate that alg matches the algorithm of the credentialPublicKey in authenticatorData.

• tpm attestation:

  • Verify that the public key specified by the parameters and unique fields of pubArea is identical to the credentialPublicKey in the attestedCredentialData in authenticatorData.

• android-key attestation: (Perhaps not relevant to supplementalPubKeys?)

  • Verify that the public key in the first certificate in x5c matches the credentialPublicKey in the attestedCredentialData in authenticatorData.

• android-safetynet attestation seems to be compatible.
• fido-u2f attestation: (probably not very relevant to supplementalPubKeys, but still)

  • Extract the claimed rpIdHash from authenticatorData, and the claimed credentialId and credentialPublicKey from authenticatorData.attestedCredentialData.

• apple attestation:

  • Verify that the credential public key equals the Subject Public Key of credCert.

So existing implementations of these verification procedures may fail to verify a supplementalPubKeys attestation. The extension may need to specify modifications to the verification procedures, or adjust the extension's signing procedure to take arguments with the same structure as the original signing procedures.