Incorrect ASN.1 tagging (INTEGER vs ENUMERATED) in Android Key Attestation test vector

[Unknown-Robot]

I am currently implementing WebAuthn verification logic and using the W3C test vectors for validation. I encountered an ASN.1 schema mismatch in the test case "Android Key Attestation with ES256 Credential".

The KeyDescription sequence in the x5c certificate extension seems to use an incorrect ASN.1 tag for the SecurityLevel fields.

According to the Android Key Attestation specification, the attestationSecurityLevel and keymintSecurityLevel fields are defined as ENUMERATED :

KeyDescription ::= SEQUENCE {
    attestationVersion           INTEGER,
    attestationSecurityLevel     SecurityLevel,
    keyMintVersion               INTEGER,
    keyMintSecurityLevel         SecurityLevel,
    attestationChallenge         OCTET_STRING,
    uniqueId                     OCTET_STRING,
    softwareEnforced             AuthorizationList,
    hardwareEnforced             AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
    Software                     (0),
    TrustedEnvironment           (1),
    StrongBox                    (2),
}

However, in the provided test vector, these fields are encoded as INTEGER (Tag 0x02) instead of ENUMERATED (Tag 0x0A).

After analyzing the extnValue of the KeyDescription extension from the test vector reveals the following structure:

• attestationVersion: INTEGER (Correct)
• attestationSecurityLevel: INTEGER (Tag 0x02) -> INCORRECT
• keymintVersion: INTEGER (Correct)
• keymintSecurityLevel: INTEGER (Tag 0x02) -> INCORRECT

The test vector should be updated or re-generated to use the correct ASN.1 DER encoding (Tag 0x0A) for SecurityLevel fields, aligning it with the official Android specifications and modern device behavior.

References

• Android Key Attestation Extension Schema :
  https://source.android.com/docs/security/features/keystore/attestation#attestation-v400

• Android Key Attestation with ES256 Credential :
  https://w3c.github.io/webauthn/#sctn-test-vectors-android-key-es256

[arnar]

Confirming that output from a real Android device matches the Android documentation, and the value is tagged with ENUMERATED (0x0A).

283:d=5 hl=4 l= 386 prim: OCTET STRING [HEX DUMP]:3082017E020201900A0101020201900A01010420503AD32CC69A89710BEF721917D4EB1921C87FEBF8504C8C107C812E83207A2E040030819DBF853D080206019BBDF7F89DBF85456704653063313D301B0416636F6D2E676F6F676C652E616E64726F69642E677366020124301E0416636F6D2E676F6F676C652E616E64726F69642E676D7302040F82CF7B31220420F0FD6C5B410F25CB25C3B53346C8972FAE30F8EE7411DF910480AD6B2D60DB83BF8554220420EA96ED85BB81529E0E932592D2822527B41A3FF46F602F70BB908496E6018FFE3081A9A1053103020102A203020103A30402020100A5053103020104AA03020101BF837803020103BF83790302010ABF853E03020100BF85404C304A0420ACB5A4DD184E2C44CFA6A53D2D5C5E8674C9498A59F8AE8019942AC1FCEB1E6C0101FF0A01000420B1ECA34C41D308C91ABCEA66CF5852814CD526020041A590BD7F865AAA0900B6BF8541050203027100BF8542050203031769BF854E06020401352509BF854F06020401352509

    0:d=0  hl=4 l= 382 cons: SEQUENCE
    4:d=1  hl=2 l=   2 prim:  INTEGER           :0190
    8:d=1  hl=2 l=   1 prim:  ENUMERATED        :01
   11:d=1  hl=2 l=   2 prim:  INTEGER           :0190
   15:d=1  hl=2 l=   1 prim:  ENUMERATED        :01
   18:d=1  hl=2 l=  32 prim:  OCTET STRING      [HEX DUMP]:503...

[emlun]

Thanks Arnar! And thanks @Unknown-Robot for finding and reporting this!