Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Authentication Secret IDs ('authSecID'): mandatory
A statement representing an identifier list that MUST be
associated with corresponding Authentication Secrets used to
protect Evidence.

Previous section says “Authentication Secret” is used to protect Claims, but here says it’s used to protect Evidence.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Reference Claims are used to appraise the Claims received from an
Attester via appraisal by direct comparison.

“Direct comparison” isn’t the correct expression, the comparison can have other rules.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

In Section 1, 3 Disambiguation

About “these types of co-located environments”, The previous sentences are about the Verifier and Attester don’t need to be remote. So “these” is weird here, because here is about the attesting environment and target environment.

Diagrams should be as close to UML as possible to improve understanding.
That is (this applies to all diagrams):

• Actions should be verbs, not nouns ("generateValues" instead of "valueGeneration").
• Returns of data should also be just arrows with data elements, i.e. nouns ("evidence --->" instead of "returnEvidence --->".

Uni-Directional Remote Attestation:

• Handle Distributor should be at the top as an actor.
• It should be indicated that the "claimsDelta" value generation is a loop.

In sections "9.6. License" and "9.7. Implementation Dependencies" the two mentions of "github" should be "GitHub".

It'd be helpful to include words on nonce handling for unsolicited and subscription models and how this varies for each role (since storage burden will vary for attester and verifier, for example).

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Authentication Secret IDs ('authSecID'): mandatory
In DAA, Authentication Secret IDs are represented by the Endorser
(DAA issuer)'s public key that MUST be used to create DAA
credentials for the corresponding Authentication Secrets used to
protect Evidence.
In DAA, an Authentication Secret ID does not identify a unique
Attesting Environment but associated with a group of Attesting
Environments. This is because an Attesting Environment should not
be distinguishable and the DAA credential which represents the
Attesting Environment is randomised each time it used.

In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the “Attester Identity” part, what does the DAA credential represent actually?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Attestation Evidence Authenticity: Attestation Evidence MUST be
correct and authentic.

Is it appropriate to say “correct Evidence”? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence.

This should also be described in the text.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Reference Claims ('refClaims') mandatory
Reference Claims are components of Reference Values as defined in
[I-D.ietf-rats-architecture]. [Editor's Note: Definition might
become obsolete, if replaced by Reference Values. Is there a
difference between Claims and Values here? Analogously, why is
not named Reference Claims in the RATS arch?]

I suggest using Reference Values to keep consistent with the RATS arch.

In all diagrams, valueGeneration should be replaced by produceClaims. The return type "claims" also indicates that claims are produced(/generated) somehow. Generated claims, e.g. could be Measured Boot data (TPM PCRs + the boot event log).

BTW: I don't see a passage in the text that describes valueGeneration.

See also #30.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

The associated private keys are used by the DAA Issuer to provide
an Attester with a credential that it can use to convince the
Verifier that its Evidence is valid. To keep their anonymity the
Attester randomizes this credential each time that it is used.

How to understand “Evidence is valid”? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)?

There exist some inconsistencies in the diagrams. For example:

• "evidence" and "signedEvidence" (the latter should be replaced).
• "evidenceGeneration" vs. "evidenceGeneration" (the latter is preferred since it denotes an action indicated by a verb, not a noun, as in UML)
• "collectClaims(claimSelection)" should be "collectClaims(claimsDelta, claimSelection)" since the claim selection requires the claims as input, too.
• Alignment of return arrows must be fixed.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology.

Examples of these types of co-located environments include: a Trusted
Execution Environment (TEE), Baseboard Management Controllers (BMCs),
as well as other physical or logical protected/isolated/shielded
Computing Environments (e.g. embedded Secure Elements (eSE) or
Trusted Platform Modules (TPM)).

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

I think it’s better to move this section to the bottom of the draft. DAA doesn’t introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it’s not.

An handle mustbe created/generated before it can be distributed. Adding a generateHandle() call would also strengthen understanding by readers.

The text must be reworked.

All above, the sequence in the diagram should be described entirely.

This may also apply to the other models.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Claim Selection ('claimSelection'): optional
A statement that represents a (sub-)set of Claims that can be
created by an Attester.
Claim Selections can act as filters that can specify the exact set
of Claims to be included in Evidence. An Attester MAY decide
whether or not to provide all Claims as requested via a Claim
Selection.

The “all Claims” may be ambiguous, I’d like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

In the sequence diagram, some elements in the bracket are not defined in the “Information Elements” section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

A credential is conveyed from an Endorser to an Attester in
combination with the conveyance of the public key certificates
from Endorser to Verifier.

Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

This document extends the duties of the Endorser role as defined by
the RATS architecture with respect to the provision of these Attester
Identity documents to Attesters. The existing duties of the Endorser
role and the duties of a DAA Issuer are quite similar as illustrated
in the following subsections.

Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn’t make sense to me.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

The zero-knowledge proofs required cannot be created by an Attester
alone - like the Endorsements of RoTs - and have to be created by a
trustable third entity - like an Endorser. Due to that semantic
overlap, the Endorser role is augmented via the definition of DAA
duties as defined below. This augmentation enables the Endorser to
convey trustable third party statements both to Verifier roles and
Attester roles.

For “the definition of DAA duties as defined below”, what is the definition of DAA duties?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Attester Identity: The provenance of Evidence with respect to a
distinguishable Attesting Environment MUST be correct and
unambiguous.

The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?

A publish-subscribe model for remote attestation would be nice to have.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Depending on the use cases covered, there can be additional
requirements. An exemplary subset is illustrated in this section.

Here starts to talk about “additional requirements”, but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Attester Identity ('attesterIdentity'): mandatory
In DAA, the Attester's identity is not revealed to the verifier.
The Attester is issued with a credential by the Endorser that is
randomized and then used to anonymously confirm the validity of
their evidence. The evidence is verified using the Endorser's
public key.

I think here means the DAA credential represents the Attester Identity.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Attester Identity ('attesterIdentity'): mandatory
A statement about a distinguishable Attester made by an Endorser
without accompanying evidence about its validity - used as proof
of identity.

Previous section says “Attester Identity” is about “a distinguishable Attesting Environment”, and here says it’s about “a distinguishable Attester”.

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Authentication Secret: An Authentication Secret MUST be available
exclusively to an Attester's Attesting Environment.

The Attester MUST protect Claims with that Authentication Secret,
thereby proving the authenticity of the Claims included in
Evidence. The Authentication Secret MUST be established before
RATS can take place.

Does the Authentication Secret represent the identity of the Attesting Environment?

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

In order to enable the use of DAA, an Endorser role takes on the
duties of a DAA Issuer in addition to its already defined duties.
DAA Issuers offer zero-knowledge proofs based on public key
certificates used for a group of Attesters [DAA]. Effectively, these
certificates share the semantics of Endorsements, with the following
exceptions:

In the first sentence, I suggest saying that “a DAA Issuer takes on the role of an Endorser”.