Exercise all four required attestation formats against real fixtures

[Bccorb]

Part of #155. Session 6. Split out of #169.

Problem

#169 listed "all four required formats verify correctly" as acceptance, and that
part was not done. #168 and #169 wired attestation and the metadata service, but
nothing exercises the individual attestation statement formats.

FIDO Server Requirements v2.3 requires a server to support Packed, TPM, U2F and
Android SafetyNet. @simplewebauthn/server ships verifiers for all four plus
Apple and Android Key, and they are now reachable under
authenticator_policy.attestation: 'direct', but no test drives any of them.

This is currently recorded only in the body of the pull request that closed
#168 and #169, which is not somewhere work gets found.

Why it was deferred

Exercising a format end to end needs real attestation fixtures: a genuine
statement, its certificate chain, and a matching metadata entry. Hand-rolling
those is close to reimplementing the authenticator. The FIDO conformance tools
supply them, which is why this belongs beside #171 and #172 rather than in the
change that enabled attestation.

What to do

• Take the attestation fixtures the conformance tools provide
• Cover Packed, TPM, U2F and Android Key, each verifying and each failing
  correctly when tampered with
• Cover a statement whose AAGUID is absent from the metadata service, in both
  requireKnownAuthenticator postures

Scope change: Android SafetyNet is out, Android Key is in

Amended 2026-09-03. SafetyNet cannot be covered, for two independent reasons
recorded in full in the comment below: the conformance tools no longer emit a
SafetyNet statement, and the verifier refuses any statement more than sixty
seconds old, so a committed fixture could only ever pass against a faked clock.

Android Key takes its place. It is a real attestation format with a real
statement from the same run, and covering it also pins the vendor root
certificate handling that #253 introduced.

If SafetyNet has to appear in the certification submission itself, that is a
question for the Certification Secretariat about what FIDO Server Requirements
v2.3 still expects in practice. It is not an engineering task in this repository.

Acceptance

• Packed, TPM, U2F and Android Key are each exercised against a real statement
• A tampered statement is refused
• The metadata-absent path is covered in both postures

Depends on

#171, which brings in the conformance interface and the local metadata
statements those tools expect.

[Bccorb]

PR #254 covers everything in the acceptance criteria except Android SafetyNet,
which cannot be met as written. Recording the evidence here so the decision is
not rediscovered later.

The conformance tools never emit a SafetyNet statement. Three runs on
2026-09-02 and 2026-09-03, the last with every test group selected, produced no
SafetyNet attestation at all. The string does not appear once in 347 captured
requests, even though Virtual RSA PKCS 1.5 SHA256 FIDO2 Conformance Testing CTAP2 Authenticator with SafetyNet attestation loads with the other 24 metadata
statements. Android Key, by contrast, did start firing once the wider group
selection was used, so the tools were genuinely exercising more. Google turned
down the SafetyNet Attestation API in favour of Play Integrity, which is the
likely reason it has left the server test suite.

A captured fixture could not work regardless. verifyAttestationAndroidSafetyNet
refuses any statement whose payload timestamp is more than sixty seconds old:

const timestampPlusDelay = timestampMs + 60 * 1000;
if (timestampPlusDelay < now) {
  throw new Error(`Payload timestamp "${timestampPlusDelay}" has expired (SafetyNet)`);
}

So a committed SafetyNet fixture is dead sixty seconds after capture. It could
only pass against a faked clock, which would prove nothing about the format and
would be a test of vi.setSystemTime rather than of attestation.

Suggested amendment. Replace the SafetyNet criterion with Android Key, which
PR #254 already covers against a real statement, and note that SafetyNet is
retired. If SafetyNet must stay in scope for the certification submission, that
is a question for the Secretariat about what FIDO Server Requirements v2.3 still
requires in practice, not an engineering task here.

What #254 does cover, all against statements captured from a real run:

• Packed, TPM and fido-u2f verify end to end, each reporting its format and AAGUID
• Each is refused with the attestation signature altered, and again with the
  authenticator data altered
• Android Key is refused against the real Google roots and verifies once the
  preset roots are cleared, pinning the behaviour from fix(conformance): load the metadata the tools ship, echo only requested extensions #253
• The metadata-absent path in both requireKnownAuthenticator postures, offline