Addressing Thomas' Review from list #56
Conversation
| @@ -160,11 +160,15 @@ A PKIX Certificate is an X.509v3 certificate as specified by {{RFC5280}}. | |||
| In the context of this document, the term "Remote" does not necessarily refer to a remote entity in the scope of network topologies or the Internet. | |||
| It rather refers to decoupled systems or entities that exchange the Conceptual Message type called Evidence {{-RATS}}. | |||
| This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system components of the same Composite Device (a single RATS entity), or the Verifier and Relying Party roles are hosted by the same entity, for example in a cryptographic key broker system. | |||
| Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity. Examples of such isolated 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)). Readers of this document should be familiar with the concept of Layered Attestation as described in {{Section 3.1 of {{-RATS}} and the definition of Attestation as described in {{-RIV}}. | |||
| Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity. Examples of such isolated 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)). It is useful but not necessary for readers of this document to be familiar with the Conceptual Data/Messages flows as described in {{Section 3 of {{-RATS}} and the definition of Attestation in general as described in {{-RIV}}. | |||
There was a problem hiding this comment.
- Why "Even"?
- s/{{Section 3 of {{-RATS}}/{{Section 3 of -RATS}}/
There was a problem hiding this comment.
- Why "Even"?
Not the slightest clue.
There was a problem hiding this comment.
OK, it can be safely removed then.
|
|
||
| # Scope and Intent | ||
|
|
||
| This document outlines the interaction models between Attesters and Verifiers to convey Evidence. | ||
| This document outlines three very common interaction models between RATS roles. | ||
| In this document the interaction models illustrated focus on the conveyance of Evidence about boot-time integrity from Attesters to Verifiers. |
There was a problem hiding this comment.
(same comment I made on the email reply)
Unsure why run-time measurements would be ruled out. The dynamicity and kind of the target environment seem orthogonal to the conveyance of associated evidence.
There was a problem hiding this comment.
They are not ruled out. The phrasing is off. How about:
| In this document the interaction models illustrated focus on the conveyance of Evidence about boot-time integrity from Attesters to Verifiers. | |
| This document illustrates interaction models focusing on conveying Evidence about boot-time integrity from Attesters to Verifiers. | |
| This document does not exclude application of those interaction models to runtime integrity or the conveyance of other RATS Conceptual Messages. These other applications are not illustrated in this document. |
There was a problem hiding this comment.
The dynamicity and kind of the target environment seem orthogonal to the conveyance of associated evidence.
I am not sure what you are eluding to, tbh. Could you help us and elaborate a bit?
There was a problem hiding this comment.
I am OK content-wise, but the phrasing is a bit awkward. My humble editorial suggestion:
The document illustrates the interaction models focusing on conveying Evidence about boot-time integrity from Attesters to Verifiers.
It does not exclude application to runtime integrity or other conceptual messages, but these are not illustrated.
There was a problem hiding this comment.
What I meant is that in the context of a framework that aims at describing the conveyance of CMs, it does seem odd to impose restrictions based on the internal details of one or more CMs. IOW, from the point of view of a conveyance protocol, Evidence is Evidence, be it runtime or boottime, dynamic or static.
There was a problem hiding this comment.
Please see the updated suggestion above. Does that work for you?
| In this document the interaction models illustrated focus on the conveyance of Evidence about boot-time integrity from Attesters to Verifiers. | ||
| In the scope of Evidence conveyance not every detail is covered in this document. | ||
| Details around Evidence about run-time integrity, for example, or not explicitly highlighted, but the included model descriptions still function as a basis to build corresponding model extensions on. | ||
| While the three interaction models (and their sub-variants) are not an exhaustive list of all potential models, they do cover a vast majority of conveyance models for Conceptual Messages implemented in the Internet. |
There was a problem hiding this comment.
This more nuanced description seems at odds with L146 which claims "total and unconfined coverage" :-)
There was a problem hiding this comment.
I am having a hard time gleaming "total and unconfined coverage" from L146. Could you help me identify the offender so we can deal with it together?
There was a problem hiding this comment.
The original L146 states:
"[t]he methods described in this document can also be applied to the conveyance of ${CONCEPTUAL_MESSAGE}"
which, at least to this reader, sounds like there are no limits to the potential coverage of the described methods.
The amended version of L146 that you propose in the comment above makes it more in line with L171.
There was a problem hiding this comment.
So, you are okay with the L146 as per this PR and this comment can be resolved? I mean, the intent was to address your comment, after all.
| @@ -300,7 +304,7 @@ The following subsections introduce and illustrate the interaction models: | |||
| 3. Streaming Remote Attestation | |||
|
|
|||
| Each section starts with a sequence diagram illustrating the interactions between Attester and Verifier. | |||
| While the presented interaction models focus on the conveyance of Evidence, the intention of this document is in support of future work that applies the presented models to the conveyance of other Conceptual Messages, namely Attestation Results, Endorsements, Reference Values, or Appraisal Policies. | |||
| While the presented interaction models focus on the conveyance of Evidence, the intention of this document is in support of any type of Conceptual Messages conveyance that is based on the presented models. | |||
There was a problem hiding this comment.
Unclear how the document can "[s]upport of any type of Conceptual Messages conveyance that is based on the presented models." without describing in practice how the models can be applied to other kinds of flows/CMs.
There was a problem hiding this comment.
see comment below, failed to reply here
There was a problem hiding this comment.
|
|
||
| : *mandatory* | ||
|
|
||
| : Reference Values as defined in {{-RATS}}. This specific type of Claims is used to appraise Claims incorporated in Evidence. For example, Reference Values MAY be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see Endorsements in {{-RATS}}). Reference Values typically represent (trusted) Claim sets about an Attester's intended platform operational state. | ||
| : Appraisal procedures implemented by Verifiers require certain inputs as defined in {{-RATS}}: Reference Values, Endorsements, and Appraisal Policy for Evidence. These Conceptual Messages can takes various forms. For example, Reference Values can be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (Endorsements). |
There was a problem hiding this comment.
- s/takes/take/
- The second sentence still purports Endorsements as a kind of Reference Value.
There was a problem hiding this comment.
see comment below, failed to reply here
There was a problem hiding this comment.
|
|
||
| : While a verifier does not necessarily have knowledge about an Attesting Environment's Attestation Key (ID), each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). | ||
| Consequently, an Attestation Key ID can also identify an Attesting Environment. | ||
| : While a verifier does not necessarily have knowledge about an Attesting Environment's identifiers, each distinguishable Attesting Environment typically has access to a protected capability that includes an Attesting Environment ID. |
There was a problem hiding this comment.
- s/verifier/Verifier/
|
|
||
| : Claim Selections act as optional filters to specify the exact set of Claims to be included in Evidence. For example, a Verifier could send a Claim Selection, among other elements, to an Attester. An Attester MAY decide whether or not to provide all requested Claims from a Claim Selection to the Verifier. If there is no way to convey a Claim Selection in a remote attestation protocol, a default Claim Selection (e.g., "all") MUST be defined be the Attester and SHOULD be known to the Verifier. |
There was a problem hiding this comment.
The following:
"In order to select Claims, Claims that can be potentially included in Evidence by an Attesting Environment have to be known by the Verifier."
is either stating the obvious, in which case it can be dropped without loss of information, or it's trying to state something about the need for a discovery function that is however not fully articulated.
There was a problem hiding this comment.
Hm, yes this is kind of "water is wet" and yes it could be dropped, but we were taking great care here to avoid confusion. This is really wet water - and if we do not have to tell you that it is wet, we can drop it.
There was a problem hiding this comment.
Drop it, please. Less is more :-)
|
|
||
| : *mandatory* | ||
|
|
||
| : Reference Values as defined in {{-RATS}}. This specific type of Claims is used to appraise Claims incorporated in Evidence. For example, Reference Values MAY be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see Endorsements in {{-RATS}}). Reference Values typically represent (trusted) Claim sets about an Attester's intended platform operational state. | ||
| : Appraisal procedures implemented by Verifiers require certain inputs as defined in {{-RATS}}: Reference Values, Endorsements, and Appraisal Policy for Evidence. These Conceptual Messages can takes various forms. For example, Reference Values can be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (Endorsements). |
There was a problem hiding this comment.
Yes. That does not read right. How about:
| : Appraisal procedures implemented by Verifiers require certain inputs as defined in {{-RATS}}: Reference Values, Endorsements, and Appraisal Policy for Evidence. These Conceptual Messages can takes various forms. For example, Reference Values can be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (Endorsements). | |
| : Appraisal procedures implemented by Verifiers require certain inputs as defined in {{-RATS}}: Reference Values, Endorsements, and Appraisal Policy for Evidence. These Conceptual Messages can take various forms. For example, Reference Values that can be expressed via Reference Integrity Measurements (RIM) or Endorsements that can range from trust anchors to assertions cryptographically bound to the public key associated with an Attesting Environment. |
There was a problem hiding this comment.
Clarifying question due to a temporary lapse of imagination. What do you mean by:
"[a]ssertions cryptographically bound to the public key associated with an Attesting Environment"
Can you provide a concrete example?
There was a problem hiding this comment.
For example, you create a different message, put public key material of the associated AE into that message, then seal it via object signing.
Now your message uses cryptographic binding (sign) of the AE's public key with other assertions about the AE.
| @@ -311,7 +303,7 @@ The following subsections introduce and illustrate the interaction models: | |||
| 3. Streaming Remote Attestation | |||
|
|
|||
| Each section starts with a sequence diagram illustrating the interactions between Attester and Verifier. | |||
| While the presented interaction models focus on the conveyance of Evidence, the intention of this document is in support of future work that applies the presented models to the conveyance of other Conceptual Messages, namely Attestation Results, Endorsements, Reference Values, or Appraisal Policies. | |||
| While the presented interaction models focus on the conveyance of Evidence, the intention of this document is in support of any type of Conceptual Messages conveyance that is based on the presented models. | |||
There was a problem hiding this comment.
How about:
| While the presented interaction models focus on the conveyance of Evidence, the intention of this document is in support of any type of Conceptual Messages conveyance that is based on the presented models. | |
| While the presented interaction models are illustrated by using the conveyance of Evidence as an example, the models presented may be adapted to the conveyance of other Conceptual Messages. |
Shorter, more crisp, and maybe less offending?
There was a problem hiding this comment.
Sorry to pester you but it's not about form. It's about the content.
My disagreement is about making the claim that "[t]he models presented can be adapted to the conveyance of other Conceptual Messages." without describing how such adaptation works in practice.
As an example that would need to be articulated clearly in order to claim that the model fits more widely: what does Handle mean in the context of conveyance of Reference Values?
There was a problem hiding this comment.
Handle would mean the exact same thing. It would be a Claim value used in the interaction model to demonstrate recent response and to prevent reply attack of RVs that might change the next session, so the requester of RV is able to tell that there has been a best effort to demonstrate freshness (an assertion in a message is reflecting reality) based on recentness (use of Handle).
There was a problem hiding this comment.
Would you be able to craft an appropriate example based on my illustration? I think it is important to get this right.
There was a problem hiding this comment.
Handle would mean the exact same thing. It would be a Claim value used in the interaction model to demonstrate recent response and to prevent reply attack of RVs that might change the next session, so the requester of RV is able to tell that there has been a best effort to demonstrate freshness (an assertion in a message is reflecting reality) based on recentness (use of Handle).
I don't expect freshness of RVs to be provided by handles - see CoRIM, which relies on synchronised clocks between RV provider and Verifier.
Addressing https://mailarchive.ietf.org/arch/msg/rats/3nJPexI-uG1wsIyGMsTBKoHGEL4