Sorry for being late to this.  I was asked to review this document on behalf of the OPS DIR.  Overall, I found the document well-written, though dense.  It does describe a high-level architecture for remote attestation, and I tried to divine what impact this architecture might have on operators.  I had some initial confusion (for example, what endorsements are provided in the ROM example), and I think moving Section 4 up closer to the beginning will help the reader set some of that initial context.

Operator-wise I was a bit concerned about what some of the process might mean for troubleshooting and overall system performance.  For example, the TLS handshake verification, if implemented would add more parties and more time as it's verified (if I understand that correctly).  That said, I debated about whether it's useful to raise it as an issue here or later on when such implementation is defined.  If here, I think expanding on the desire operators might have for remote attestation and the considerations it presents on overall system understanding might be useful.

On the security front, I'm not an expert, but I was expecting to see something about any risks with combining roles such as Attester and Verifier on the same system.  Maybe there aren't any, but that hybrid example got me thinking what would be the risk if the system doing my background check also evaluated the data.

On the nits front:

Section 3:

You have a "Section Section 4" double word.

===

Section 5.1:

Double "the"

===

Section 8.4

You have a "section Section 11" double word.