Rework entity definition to align with RAT architecture

[gmandyam]

Do we need to say anything at all about layered attestation as defined in RFC 9334?

For instance, with layered attestation the following requirement appears in the definition in RFC 9334: "The bottom layer of an Attester has an Attesting Environment that is typically designed to be immutable or difficult to modify by malicious code." It is conceivable that a mutable attester that may be vulnerable to runtime modification by an attacker (e.g. Android SafetyNet) could provide a EAT token with nesting. It would not be an ideal implementation of EAT, but depending on the application it may be considered sufficient. Tying EAT nesting to the 9334 definition of layered attestation may restrict intended applications of EAT.

[laurencelundblade]

I know layered attestation in 9334 is not the best description, but I think the text I proposed works OK and doesn't cause any problems. We'll definitely sail through better if we align as much as we can with 9334 and particularly if we don't make any fuss about it.

Let me know if you think the text I propose has any problems.