RFC Errata
Found 8 records.
Status: Verified (2)
RFC 9711, "The Entity Attestation Token (EAT)", April 2025
Source of RFC: rats (sec)
Errata ID: 8528
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2025-08-09
Verifier Name: Deb Cooley
Date Verified: 2025-10-28
Section Appendix A says:
/ eat_nonce / 10: h'48df7b172d70b5a18935d0460a73dd71',
/ eat_nonce / 10: h'e253cabedc9eec24ac4e25bcbeaf7765',
/ eat_nonce / 10: h'd79b964ddd5471c1393c8888',
/ eat_nonce / 10: h'99b67438dba40743266f70bf75feb1026d5134
97a229bfe8',
/ eat_nonce / 10: h'8b0b28782a23d3f6',
/ eat_nonce / 10: h'5e19fba4483c7896',
/ eat_nonce / 10: h'3515744961254b41a6cf9c02',
It should say:
/ Nonce / 10: h'48df7b172d70b5a18935d0460a73dd71',
/ Nonce / 10: h'e253cabedc9eec24ac4e25bcbeaf7765',
/ Nonce / 10: h'd79b964ddd5471c1393c8888',
/ Nonce / 10: h'99b67438dba40743266f70bf75feb1026d5134
97a229bfe8',
/ Nonce / 10: h'8b0b28782a23d3f6',
/ Nonce / 10: h'5e19fba4483c7896',
/ Nonce / 10: h'3515744961254b41a6cf9c02',
Notes:
For all the CWT examples in Appendix A, where the claim name is "eat_nonce" it should be changed to "Nonce", as "eat_nonce" is only for JWT.
Errata ID: 8777
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2026-02-20
Verifier Name: RFC Editor
Date Verified: 2026-03-02
Section 4.3.1 says:
A 64-bit integer representation of the CBOR epoch-based time [RFC8949] used by this claim can represent a range of +/- 500 billion years, so the only point of a floating-point timestamp is to have precession greater than one second.
It should say:
A 64-bit integer representation of the CBOR epoch-based time [RFC8949] used by this claim can represent a range of +/- 500 billion years, so the only point of a floating-point timestamp is to have precision greater than one second.
Notes:
NA
Status: Reported (4)
RFC 9711, "The Entity Attestation Token (EAT)", April 2025
Source of RFC: rats (sec)
Errata ID: 8771
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2026-02-19
Section A.1.7 says:
"secboot": true,
It should say:
"oemboot": true,
Notes:
secboot was renamed to oemboot in https://github.com/ietf-rats-wg/eat/pull/340. The example was renamed in https://github.com/ietf-rats-wg/eat/pull/342 but somehow the final RFC did not include the change.
Errata ID: 8776
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2026-02-20
Section 7.3.1 says:
? heading => number,
It should say:
? heading => number / null
Notes:
From 4.2.10, "If the entity is stationary, the heading is 'null'."
Errata ID: 8782
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2026-02-25
Section A.1.7 says:
"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
It should say:
"ueid": "AJj1Ck_2wFhhyIYNE6Y46g",
Notes:
Per the definition of base64url encoding in https://www.rfc-editor.org/rfc/rfc9711.html#section-2-5.2.1, all trailing '=' characters are omitted. In addition, the regular expression for base64-url-text does not include the '=' character.
Errata ID: 8783
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steven Bellock
Date Reported: 2026-02-25
Section 4.2.3 says:
oemid-random-json = base64-url-text .size 24
It should say:
oemid-random-json = base64-url-text .size 22
Notes:
16 bytes encoded into base64url, with padding, results in 24 bytes. However, the two padding characters, '==', are removed as per the definition of base64url encoding in https://www.rfc-editor.org/rfc/rfc9711.html#section-2-5.2.1, resulting in 22 bytes.
Status: Rejected (2)
RFC 9711, "The Entity Attestation Token (EAT)", April 2025
Source of RFC: rats (sec)
Errata ID: 8401
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muhammad Usama Sardar
Date Reported: 2025-05-01
Rejected by: Deb Cooley
Date Rejected: 2025-06-27
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/
--VERIFIER NOTES--
Incorrectly specified errata. The corrected text is not actually correct.
Errata ID: 8404
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muhammad Usama Sardar
Date Reported: 2025-05-04
Rejected by: Deb Cooley
Date Rejected: 2025-06-27
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).
--VERIFIER NOTES--
Incorrectly formatted errata. The corrected text is not correct.