Skip to main content

The Entity Attestation Token (EAT)
draft-ietf-rats-eat-31

Yes

Orie Steele

No Objection

Erik Kline
Jim Guichard
John Scudder
Zaheduzzaman Sarker
Éric Vyncke

Note: This ballot was opened for revision 27 and is now closed.

Orie Steele
Yes
Roman Danyliw
Yes
Comment (2024-06-13 for -27) Not sent
Note: this document is returning for a second IESG Review.  -24 was previously approved and sent to the RFC Editor.  It was pulled from the RFC Editor queue to remove a dependency causing a MISREF that was not likely to resolve in the near future.  This document saw a new WG and IETF LC to confirm consensus on this approach.  See IESG Write-Up for more details.
Deb Cooley
No Objection
Comment (2024-06-20 for -27) Sent
I agree with Paul Wouter's comments: 

1.  on references to certification sources in 4.2.14 (this should be easy for Common Criteria)

2.  random quality based directly off the hardware randomizers in Appendix B.2. Although, my rationale for this comment is slightly different.  Classically a system uses a combination of hardware and software combiners and conditioners.  Good quality random data should be taken from the combination vice directly from the hardware.  While this may mask hardware failures, it definitely produces data that is smoother.  My suspicion is that this is what was meant, so a slight tweak in the sentence should clarify it.

In addition, I have this one nit: 
Section 4.2.1.1, para 8:  produce/product? and 'another type for other' add the word 'items' to the end?
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2024-06-19 for -27) Sent
Thank you for the work on this document, which despite its length I found very clear and an easy read. Kudos to the authors and the working group.

I didn't have a chance to review the doc when it passed IESG for the first time, so a couple of minor nits and comments.

Section 4.2.15.

>  The second item is MUST be the actual manifest.

s/is MUST/MUST

Section 4.3.3.

>  5 possible values for "intuse" are currently defined, but an IANA registry can be created in the future to extend these values based on new use cases of EAT.

I would have created this registry already in this document. I trust that the wg has discussed this and decided against it?

Section 10.1.

> All new EAT claims defined subsequently should be placed in both registries.

why not shall (or must) instead of should here?
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2024-06-19 for -27) Not sent
I balloted No Objection on -21, and the delta between that and this raises no new issues for me (and thanks for taking my comments last time).
Paul Wouters
No Objection
Comment (2024-06-19 for -27) Sent
Some very minor comments only:


        The claims set includes a nonce or some other means to assure freshness

Does this mean "includes a received nonce from the verifier to assure
freshness" ? as in the device itself doesn't generate the nonce right?

        Examples of certifications represented by a DLOA include those
        issued by Global Platform and those based on Common Criteria.

Should there be an informative reference added for Global Platform and
Common Criteria ?

        Today, cryptographic-quality random numbers are available from
        common CPUs and hardware. This hardware was introduced between 2010
        and 2015. Operating systems and cryptographic libraries give access to
        this hardware. Consequently, there is little need for implementations
        to construct such random values from multiple sources on their own.

I disagree with this claim. Hardware can become faulty. RNG generators could
contain a backdoor by being seeding with known seed. This is why the Linux
kernel random subsystem takes various sources and mixes the random in an
entropy pool, and does not really allow direct hardware rng access.
Warren Kumari
No Objection
Comment (2024-06-19 for -27) Sent
I've said it before, an' I'll say it again: No Objection.

(https://mailarchive.ietf.org/arch/msg/rats/YLQ3WLwFiMFqb-7nWFXdbQZR2O0/)
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection