[Rats] Re: [Technical Errata Reported] RFC9711 (9193)

[Jeremy O'Donoghue <[e-mail]>]

Hi all,

I confirm this erratum and note similar issues with some of the JSON examples. All are CDDL-compliant but fail against normative text.

Location: A.1.2, A.1.3, A.1.5, A.2.2
Value: h'0198f50a4ff6c05861c8860d13a638ea'
Decoded bytes: 16 bytes
Type byte: 0x01 RAND
Unique-part size: 15 bytes = 120 bits
CDDL (7–33 / 10–44): passes (16∈[7,33])
Prose: fails — RAND unique part MUST be ≥128 bits; this is 1 byte short

Location: A.1.6 (JSON)
Value: "AZj1Ck_2wFhhyIYNE6Y4"
Decoded bytes: 15 bytes
Type byte: 0x01 RAND
Unique-part size: 14 bytes = 112 bits
CDDL (7–33 / 10–44): passes (20 chars ∈[10,44])
Prose: fails, worse than above — 112 bits

Location: A.1.7 (JSON)
Value: "AJj1Ck_2wFhhyIYNE6Y46g=="
Decoded bytes: 16 bytes
Type byte: 0x00 (undefined)
Unique-part size: 15 bytes
CDDL (7–33 / 10–44): passes (24 chars ∈[10,44])
Prose: fails — 0x00 isn't RAND/IEEE/IMEI; not a registered type

Best regards
Jeremy

________________________________
From: Thomas Fossati <[e-mail]>
Sent: Thursday, October 01, 2026 07:52
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Jeremy O'Donoghue <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Rats] [Technical Errata Reported] RFC9711 (9193)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On Tue, Sep 29, 2026 at 6:00 PM <[e-mail]> wrote:
>
> The following errata report has been submitted for RFC9711,
> "The Entity Attestation Token (EAT)"
>
> --------------------------------------
> You may review the report below and at:
> https://errata.rfc-editor.org/eid9193/
>
> --------------------------------------
> Type: Technical
> Reported by: Sergei Trofimov <[e-mail]>
>
> Section A.1.1.2 says:
>
> Original Text
> -------------
> / ueid /           256: h'0198f50a4ff6c05861c8860d13a638ea',
>
> Corrected Text
> --------------
> / ueid /           256: h'0198f50a4ff6c05861c8860d13a638eaaa',
>
> Notes
> -----
> In various places throughout the examples in Appendix A,  the `ueid` value is show to be 16 bytes, including the initial "type" byte, 0x01 (indicating random generation). As per description in section 4.2.1.1, the random value itself should be 16 (or 24, or 32) bytes, so the whole `ueid` should be 17 bytes, including the initial type byte.

Sergei is correct.  UEID can never be an even number of bytes.
* RAND (T=0x01) is 17, 25 or 33 bytes
* EUI (T=0x02) is 7 or 9 (+)
* IMEI (T=0x03) is 15

(+) re-reading Table 1 of RFC9711 it's unclear to me how the 60 bits
of EUI-60 are supposed to be padded into the 64-bit slot.  However,
from a consumer perspective that's irrelevant [1].

cheers!

[1] https://www.rfc-editor.org/info/rfc9711/#section-4.2.1.2-3

> Instructions:
> -------------
> This erratum is currently posted as "Reported". Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9711 (draft-ietf-rats-eat)
> --------------------------------------
> Title               : The Entity Attestation Token (EAT)
> Publication Date    : April 2025
> Author(s)           : L. Lundblade, G. Mandyam, J. O'Donoghue, C. Wallace
> Category            : Proposed Standard
> Source              : rats (sec)
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



--
Thomas