Found 2 records.

Status: Reported (2)

RFC 9711, "The Entity Attestation Token (EAT)", April 2025

Errata ID: 8401
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muhammad Usama Sardar
Date Reported: 2025-05-01

Section 1 says:

For attestation, the keys are associated with
specific devices and are configured by device manufacturers. 

It should say:

The quoted text is inaccurate and just an opinion of the editors. 
It should preferably be removed from the RFC.

Notes:

In SGX, the keys are not configured by the manufacturer alone. The platform owner can provide a random value called OWNER_EPOCH.

See this for technical details: https://mailarchive.ietf.org/arch/msg/rats/4V2zZHhk5IuxwcUMNWpPBpnzpaM/

Errata ID: 8404
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muhammad Usama Sardar
Date Reported: 2025-05-04

Section 8.4 says:

The nonce claim is based on a value usually derived
   remotely (outside of the entity).

It should say:

See notes

Notes:

Attester-generated nonce does not provide any replay protection since the Attester can pre-generate an Evidence that might not reflect the actual system state, but a past one.

See the attack trace for Attester-generated nonce at:
https://mailarchive.ietf.org/arch/msg/rats/jcAv9FKbYSIVtUNQ8ggEHL8lrmM/

For replay protection, nonce should *always* be derived remotely (for example, by the Relying Party).

Report New Errata