In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target <del> Environment(s).  The lead Attester collects the Evidence of all other Attesters and then generates the Evidence of the whole Composite Attester. </del>  An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can

Updated paragraph describing collection of Evidence from sub-attesters
Should this section include an Informative Reference to the Trusted Computing Group “Guidance for Securing Network Equipment” URL It seems to repeat more or less the same thing, but using the RATS lexicon
Another comment I have on this section is about the trust model of a composite device: it looks like the lead attester needs to be trusted to collect the most fresh evidence from the other slots? Is this discussed anywhere?
Who do you mean the lead Attester needs to be trusted by? The Verifier/Relying Party or other slots/Attesters? The collecting capability is one of the characteristics the lead Attester has. So after the Verifier verifies the Evidence of the lead Attester successfully, it can trust the lead Attester's collecting capability. The Evidence of other slots are signed by these slots themselves, and these slots can send Evidence to the lead Attester just as the lead Attester sends Evidence to the on-path router to the Verifier.
I meant the latter - apologies for the lack of precision. In particular, I am interested in the scenario where a compromised lead that has cached some previously collected evidences, can forward those instead of fresh slots' attestations.

In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target  <ins> Environment(s).  The lead Attester collects the Evidence from the other Attesters and conveys it to a Verifier.  Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester.  The lead Attester generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can


generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. <del> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can be arbitrary.  For example, in this Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outside entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters, whether in the same conveyance protocol as the Evidence or not, to the outside Verifier. </del> In this situation, the trust model described in trustmodel is also suitable for this inside Verifier.  4. This document uses the following terms.

2nd to last para. in composite device section should be be given its own section heading - ## Entity
The second to last paragraph in Composite Device section is not describing composite devices. Instead it describes role-entity semantics. It should be given its own section heading e.g. "Entities" and the last paragraph / sentence should be moved up (into the composite device section).

generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules.  In this situation, the trust model described in trustmodel is also suitable for this inside Verifier. <ins> 3.6. An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can cooperate to implement a single RATS role as well.  The combination of roles and entities can be arbitrary.  For example, in the Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outer entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters to the outside Verifier, whether in the same conveyance protocol as the Evidence or not. </ins> 4. This document uses the following terms.


One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the <del> key is provisioned, is necessary.  This can be achieved in a number of ways. </del>  Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security

It seems that all that’s relevant to RATS is “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value” ` This case does seem different – there is simply no known way to extract the key.
I agree with MCR's summary that “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value”. Can we replace the bulk of section 12.1.2 with this single sentence? The expectation is that private keys can't be extracted (read) once provisioned. That should be a stated security assumption. This section reads like a tutorial or primer. That isn't the goal IMO. Security Considerations should state our our security assumptions.
{not my comment. Guy's. If you like that part, generate a pull request please!}

One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the  <ins> key is provisioned, is necessary.  The manufacturer needs to take care to protect it with measures consistent with its value.  This can be achieved in a number of ways. </ins> Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security


be a significant problem, because it allows a fleet of devices to be held hostage for ransom. <del> In the case, the Relying Party is the watchdog timer in the TPM/ secure enclave itself, as described in TCGarch section 43.3.  The Attestation Results are returned to the device, and provided to the enclave. If the watchdog does not receive regular, and fresh, Attestation Results as to the systems' health, then it forces a reboot. </del>  The device that should be protected from being held hostage for a long period of time hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules <del> (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </del>  3.4.

Also improve wording of watchdog use case's discussion of TPMs. Signed-off-by: Dave Thaler
This section, as put, is kind of a big leap, no? I think the important part of this next level, is the introduction of a hardware root of trust like a TPM to eliminate the need to trust the device’s operating system software in reporting attestation results.
NAME How about "For strongest security,...." to avoid confusion with high level OS.
This also already fixed by existing text .
If a TPM is the Attesting environment, then in the case where this system had a TPM, this statement would not be true, no? In other words, shouldn’t this example be restricted to attestation without a TPM? (I think you can say something like “hardware root of trust for verification” or something if we should avoid naming technologies) In contrast, I think in a TPM system, the firmware initializes the Attesting Environment, the TPM is the attesting environment, and the same attesting environment is used by all layers.
For context, Guy's comment was on the first sentence in this paragraph: My understanding is that a TPM requires another entity to feed it measurements which the TPM measures, the TPM doesn't actively collect claims itself. Thus to me, the TPM is not the Attesting Environment. The Attesting Environment is the combination of the TPM + whatever is feeding it the measurements. Viewed that way, I believe the text is true as written.
Yes. We need text that captures that prominently and then also in that text start with "the composite of TPM & root of trust for measurement" forms an Attesting Environment instead of "he TPM is not the Attesting Environment". Starting with the latter seems to produce reflexive and unnecessary knee-jerk reactions that we can also easily resolve, finally. Does that sound like a feasible approach?
Yes I like that.
section: ## Two Types of Environments of an Attester now includes text: ~ What else do you want to say? Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection?

be a significant problem, because it allows a fleet of devices to be held hostage for ransom.  <ins> A solution to this problem is a watchdog timer implemented in a protected environment such as a Trusted Platform Module (TPM), as described in TCGarch section 43.3.  If the watchdog does not receive regular, and fresh, Attestation Results as to the system's health, then it forces a reboot. </ins> The device that should be protected from being held hostage for a long period of time hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules  <ins> (TPMs), or BIOS firmware. An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments.  For example, a TPM doesn't actively collect claims itself, it instead requires another component to feed various values to the TPM.  Thus, an Attesting Environment in such a case would be the combination of the TPM together with whatever component is feeding it the measurements. </ins> 3.4.


buffering incoming messages that might be associated with a handle that the receiver has not yet obtained.  Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or

The handle-related portion of the Freshness section should provide some guidance on the extent of the "epoch window", i.e., the number of previously received handles that need to be kept by an appraiser to deal with propagation delay.

buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. <ins> More generally, in order to prevent an appraising entity from generating false negatives (e.g., discarding Evidence that is deemed stale even if it is not), the appraising entity should keep an "epoch window" consisting of the most recently received handles.  The depth of such epoch window is directly proportional to the maximum network propagation delay between the first to receive the handle and the last to receive the handle, and it is inversely proportional to the epoch duration. The appraising entity shall compare the handle carried in the received Evidence or Attestation Result with the handles in its epoch window to find a suitable match. </ins> Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or


A more detailed discussion with examples appears in time- considerations.  11. The conveyance of Evidence and the resulting Attestation Results or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.  13. This document does not require any actions by IANA.

Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?

A more detailed discussion with examples appears in time- considerations. <ins> For a discussion on the security of handles see handles-sec. </ins> 11. The conveyance of Evidence and the resulting Attestation Results or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. <ins> 12.3. Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever, effectively freezing time.  This is problematic since it destroys the ability to ascertain freshness of Evidence and Attestation Results. To mitigate this threat, the transport should be at least integrity protected and provide origin authentication. Selective dropping of handles is equivalent to pinning the victim node to a past epoch.  An attacker could drop handles to only some entities and not others, which will typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence. Delaying or reordering handles is equivalent to manipulating the victim's timeline at will.  This ability could be used by a malicious actor (e.g., a compromised router) to mount a confusion attack where, for example, a Verifier is tricked into accepting Evidence coming from a past epoch as fresh, while in the meantime the Attester has been compromised. Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. </ins> 13. This document does not require any actions by IANA.


Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be <del> conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </del>  The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

The list in sec 3.2 didn't render properly. Also fix Pete's surname which got garbled for some reason.

Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be  <ins> conveyed in any number of ways, including: as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document


Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results <del> may only be as fresh as the previous epoch. </del>  16.4.

Biggest bug in the last pull request is that the diagram had the attester sending a different Attestation Result than the one the Verifier gave it, which would invalidate the signature. Second issue was that the lines didn't line up. Third issue was that it was missing the tie to the "epoch window" discussion in {{epochfreshness}} to explain how the Relying Party deals with the mismatched handles that the example diagram has. Signed-off-by: Dave Thaler
The appendix on Handles needs some work to better clarify the concepts and simplify the flow. Some things about the text: Clearly define what is a handle; Explain its relation with epoch establishment; Clarify network jitter impact on handle validity; Explain what are the base rules for working with handles; Some further points on the sequence diagram: Fix confusing legend; Add some accompanying prose to explain the depicted use case as it's not self-evident;
Thanks for aligning the diagram, I knew I had forgotten something. The changes look good to me.Ship it!

Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results  <ins> may only be as fresh as the previous epoch.  If the Relying Party remembers the previous handle H during an epoch window as discussed in epochfreshness, and the message is received during that window, the Attestation Result is accepted as fresh, and otherwise it is rejected as stale. </ins> 16.4.


that protocol constrain the serialization format of the Attestation Result.  The format of the Evidence on the other hand is only constrained by the Attester-Verifier remote attestation protocol.  5.2.

` Yes but for real passports, the Relying Party must separately evaluate the trustworthiness of 192 different Verifiers, i.e., nation states, no? This seems to imply that relying parties had better get ready to validate a limitless variety of Attestation Results? [mcr: yes, in fact, in real passports, Relying Parties do not treat all 192 nation states equally, which is why, I'm told, Israeli Mossad agents apprently like Canadian passports...]
The detail of how the Relying Party should trust the Verifiers is described in the "Trust Model" Section. Besides, there may be Appraisal Policies for Attestation Results, which will guide the Relying Party on validating the Attestation Results. I don't think an update is needed here.
The passport analogy shows that there is a cardinality of: Individual (1)(1) Passport Agency Individual (1)(N) Immigration Desk The text currently does not state that this implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence (in this model). The question I want to raise is, do we want to make that more explicit to the reader?

that protocol constrain the serialization format of the Attestation Result.  The format of the Evidence on the other hand is only constrained by the Attester-Verifier remote attestation protocol. <ins> This implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence. </ins> 5.2.


structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. <del> Claims about a root of trust typically are asserted by Endorsers. </del>  The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application

Once we added Reference Value Provider as a role, the diagram wasn't updated. The "A, B, and C" part is about reference values, not the endorsing of signing capabilities, which is just about A. Signed-off-by: Dave Thaler

structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  <ins> Claims about a root of trust typically are asserted by an Endorser. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application


richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. <del> The quality of the Attestation Results depend upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </del>  different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength. By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given <del> the Appraisal Policy for Attestation Results is satisfied, then the </del>  Attester is allowed to perform the prescribed actions or access.  The <del> simplest such Appraisal Policy might authorize granting the Attester </del>  full access or control over the resources guarded by the Relying <del> Party.  A more complex Appraisal Policy might involve using the </del>  information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- <del> and vendor-specific, Attestation Results can be vendor-neutral if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </del>  allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is <del> established in Attesters. </del>  12.2.

This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?

richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results.  <ins> The quality of the Attestation Results depends upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </ins> different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength. By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given  <ins> the Appraisal Policy for Attestation Results is satisfied, the </ins> Attester is allowed to perform the prescribed actions or access.  The  <ins> simplest such appraisal policy might authorize granting the Attester </ins> full access or control over the resources guarded by the Relying  <ins> Party.  A more complex appraisal policy might involve using the </ins> information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device-  <ins> and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </ins> allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is  <ins> established in Attesters.  For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. </ins> 12.2.


requires additional Claims about the signer's time synchronization mechanism.  10.2. A second approach places the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester <del> does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result.  After checking that the sent and received nonces are the same, the </del>  appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch <del> without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </del>  The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle

Signed-off-by: Dave Thaler
At the IETF 110 meeting, Brendan Moran asked why local clocks are a problem since even MCUs have them. Currently we have text in the doc like... in the nonce section: in the handles section: I answered this by saying in the TEE use case for example, attesting the TEE needs a trusted clock, and having a trusted clock is not common. Brendan suggested clarifying the clock text.
Isn't it synchronized clocks that are the requirement? When you say "trusted clocks", do you mean, I can trust that they are securely synchronized? (Or that I can trust that Cesium still has that frequency, and that the laws of physics haven't been altered?)
I mean a clock for which code outside the TEE cannot tamper with. Whether it's synchronized or not is not about whether the clock itself is trusted. If a TEE wants to know how much time has passed since a previous event, and it has to ask the REE, and the REE can lie, then that clock is not trusted by the TEE.
Add text to TEE section about how it needs a local clock, and then add to the example involving nonces.

requires additional Claims about the signer's time synchronization mechanism. <ins> In some use cases, however, a trustworthy clock might not be available.  For example, in many Trusted Execution Environments (TEEs) today, a clock is only available outside the TEE and so cannot be trusted by the TEE. </ins> 10.2. A second approach places the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester  <ins> does not have a trustworthy clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result. After checking that the sent and received nonces are the same, the </ins> appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch  <ins> without requiring a trustworthy clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </ins> The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle


Values, or membership in a set of Reference Values, or a check against values in other Claims, or any other test.  3.2. Reference Values used in appraisal come from a Reference Value via separate communication. The actual data format and semantics of any Reference Values are <del> specific to Claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. </del>  3.3.

Signed-off-by: Dave Thaler
While Reference Values have a strong focus on conveyance and data format, Appraisal Policies do not. Is there a specific reason for this asymmetry? Additionally, there is a statement on scope on the Reference Value that does not exist for Appraisal Policies. Does that imply something?
Add some additional words to Appraisal policy like: URL
Agreed to also move to section 6, about appraisal/etc. combinations.

Values, or membership in a set of Reference Values, or a check against values in other Claims, or any other test. <ins> The actual data format and semantics of any Appraisal Policy is implementation specific. </ins> 3.2. Reference Values used in appraisal come from a Reference Value via separate communication. The actual data format and semantics of any Reference Values are  <ins> specific to Claims and implementations. </ins> 3.3.


there are many Attesters owned, the use of an Endorser becomes more scalable. <del> That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </del>  firmware or software is true.  A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to

Signed-off-by: Dave Thaler
What is the “it” in “That is, it”

there are many Attesters owned, the use of an Endorser becomes more scalable.  <ins> That is, a Verifier might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </ins> firmware or software is true.  A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to


12.3. <del> Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. </del>  An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever,

by removing the sentence which didn't add any critical point. Also mention replaying in the list of potential nefarious activities. Signed-off-by: Dave Thaler
In context, I am not sure what that sentence is trying to tell me.
I think it means that an Attacker might or might not have actually received the epoch ids from the epoch id distributor.

12.3.  <ins> Handles, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. </ins> An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever,


How and if clocks are synchronized depends upon the model.  16.1. The following example illustrates a hypothetical Passport Model result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. <del> In the figures above and in subsequent sections, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </del> The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the

Maybe move this paragraph to the super-section? Maybe this is intentional due to the proximity to a syntax example? Yet, the suffix syntax style is not placed here, correspondingly.

How and if clocks are synchronized depends upon the model. <ins> In the figures below, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </ins> 16.1. The following example illustrates a hypothetical Passport Model result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps.  The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the


12.  12.1. Implementers need to pay close attention to the protection of the

Many of the things that we are writing in the security considerations are really security requirements on implementations, rather than concerns with the architecture.

12. <ins> This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.  The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). </ins> 12.1. Implementers need to pay close attention to the protection of the


protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence. <del> In many cases the user or owner of a device that takes on the role of Attester must not be able to modify or extract keys from its Attesting Environments.  For example, the owner or user of a mobile phone or FIDO authenticator might not be trusted to use the keys to report Evidence about the environment that protects the keys.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </del>  Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and

What is that sentence trying to tell me? Control over which keys? Not the attestation keys, I think.

protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence.  <ins> In many cases the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO authenticator.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and


they are presumed to exist in order to convey conceptual messages appropriately between roles. <del> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an Attester role. </del> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.

The example used in roles and entities actually do not illustrate two aggregated/collapsed roles that talk with each other, as they seem to be entities in two different RATS setups?
Agreed to delete paragraph:"For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles. As a wide-area network connected entity, it may implement an Attester role."

they are presumed to exist in order to convey conceptual messages appropriately between roles.  In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.


material and the Attesting Environment with equivalent strength protections.  See security-considerations for discussion on security strength. 7.5.

Maybe a sentence to tie unprotected Evidence to the "concept of trust" in the Verifier section of the Trust Model super-rsection might be useful in order to illustrate to the reader why that is covered there? At the moment it talks about "secure channels" and the ties to trust are mainly implied?

material and the Attesting Environment with equivalent strength protections. <ins> As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness.  If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility.  In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness. Generating and conveying unprotected Evidence always creates significant risk and the benefits of that approach have to be carefully weighed against potential drawbacks. </ins> See security-considerations for discussion on security strength. 7.5.


Owner, and/or are programmed into the Relying Party.  This procedure is called the appraisal of Attestation Results. <del> 3.1. The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some Claims against constraints specified in its appraisal policy.  Examples of such constraints checking include: comparison for equality against a Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check against values in other Claims. The actual data format and semantics of any Appraisal Policy is implementation specific. 3.2. Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the appraisal policy. The actual data format and semantics of any Reference Values are specific to Claims and implementations.  This architecture document does not define any general purpose format for Reference Values or general means for comparison. 3.3. </del>  As shown in twotypes-env, an Attester consists of at least one Attesting Environment and at least one Target Environment.  In some the combination of the TPM together with whatever component is feeding it the measurements. <del> 3.4. </del>  By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer that it measures, rather than only one as shown by example in layered. <del> 3.5. </del>  A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal In this scenario, the trust model described in trustmodel can also be applied to an inside Verifier. <del> 3.6. </del>  An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can 8.  8.1. Evidence is a set of Claims about the target environment that reveal 8.3.  Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester, and allow it to access some data or perform some operation. relationship with one entity, rather than a larger set of entities, for purposes of its appraisal policy.  9. The following diagram illustrates a relationship to which remote

This is about the text that describes layered attestation and Figure 3, the one with environments A, B and C. I think the critical point about layered attestation (if I understand it) is that the remote Verifier must evaluate the evidence for target environment B with a positive result as a precondition to evaluating the evidence for C. This critical point isn't mentioned in the text. The other possibility is Attesting Environment A is also the Verifier for the evidence from target environment B. There are two roles in the same box, Attester and Verifier. This seems to be implied by the paragraph after Figure 3. The paragraph that starts "Attesting Environment A... has to ensure the integrity of the boot loader (Target Environment B)". However, figure 3 only shows a remote Verifier. A third possibility is A does ensure integrity of B, but it's not Attestation. It is just typical staged boot that is being described. It is not layered attestation. I think we should distinguish staged boot from local Attestation Verification. It doesn't seem right to claim that all staged boot is local Attestation Verification and thus RATS applies to all staged boot. In the cases where A does locally ensure the integrity of B either via staged boot or a local Verifier, then the remote verifier can actually trust the evidence about C without first evaluating the evidence from B. Or, all three of the above could be intended. There is nothing wrong with implementations that do any of these or combinations of them. I think the text should decide which of the three it is going after here and be clear about them.
Agreedtrust relations between different layers should be clarified. It seems that the concept of trust chain could be used to describe this trust and attestation relations in different layers.
I think the intent of the text is the first approach, i.e., the one for which Laurence says:
In the first approach, if A is the BIOS (root of trust ?), and B is the bootloader, I'm not sure if bootloader has the ability to communicate with remote verifier via network or other methods.
Typically the evidence is provided to some service or application running in or on top of the kernel, that can send the evidence to the verifier or relying party.
I understand and agree with your opinion. But that means the fiuge 3 may be inaccurate. The arrow mark orignated from B and pointed to verifier may mislead readers. And the integrity and confidentiality of evidence also need to be protected carefully. : )
Rather than adjust the diagram to show conveyance of bootloader has no network stack, instead, we shall add note to the effect that the diagram is a conceptual flow of how the trust is conveyed, not how the data is "physically" transmitted.
See PR for EAT claims for layered attestation. URL This PR supports types of layered attestation: 1) the Verifier decided on the trust and 2) the Device / root / lower layer attesting environment decides.
NAME to validate that this was done.
Maybe closed in URL
Seems to have found consensus for WGLC

Owner, and/or are programmed into the Relying Party.  This procedure is called the appraisal of Attestation Results.  <ins> See messages for further discussion of the conceptual messages shown in dataflow.  ## Two Types of Environments of an Attester </ins> As shown in twotypes-env, an Attester consists of at least one Attesting Environment and at least one Target Environment.  In some the combination of the TPM together with whatever component is feeding it the measurements.  <ins> 3.1. </ins> By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer that it measures, rather than only one as shown by example in layered.  <ins> 3.2. </ins> A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal In this scenario, the trust model described in trustmodel can also be applied to an inside Verifier.  <ins> 3.3. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can 8. <ins> dataflow illustrates the flow of a conceptual messages between various roles.  This section provides additional elaboration and implementation considerations.  It is the responsibility of protocol specifications to define the actual data format and semantics of any relevant conceptual messages. </ins> 8.1. Evidence is a set of Claims about the target environment that reveal 8.3. <ins> Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the Verifier to compare to Evidence.  Reference Values with matching Evidence produces acceptable Claims.  Additionally, appraisal policy may play a role in determining the acceptance of Claims. 8.4. </ins> Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester, and allow it to access some data or perform some operation. relationship with one entity, rather than a larger set of entities, for purposes of its appraisal policy. <ins> 8.5. The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of matched Claims against constraints specified in its appraisal policy.  Examples of such constraints checking include: comparison for equality against a Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check against values in other Claims. Upon completing all appraisal policy constraints, the remaining Claims are accepted as input toward determining Attestation Results, when appraising Evidence, or as input to a Relying Party, when appraising Attestation Results. </ins> 9. The following diagram illustrates a relationship to which remote


A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment <del> (TEE) of a client device.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </del>  A device with a TEE capable of running trusted applications that can be updated. of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules <del> (TPMs), or BIOS firmware. </del>  An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.  Execution

added reference to TEEP, cited TPM reference in section 3.3.
First mentioning of TEE, eSE, and TPM need reference in section Two Types of Environments of an Attester.
These terms need to have references: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.
We don't think we need to expand BIOS, and that it should be on the RFC editor Acronym list.

A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment  <ins> (TEE) of a client device, as described in TEEParch.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </ins> A device with a TEE capable of running trusted applications that can be updated. of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules  <ins> (TPMs) TCGarch, or BIOS firmware. </ins> An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.  Execution


of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of <del> trust can be established either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by an Endorser. </del>  The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to <del> appraise the trustworthiness of that manufacturer's devices.  In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence. </del>  In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Uses text copied from the TEEP arch draft. Addresses Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.

of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of  <ins> trust can be established in various ways as discussed in verifier. In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to  <ins> appraise the trustworthiness of that manufacturer's devices.  Such trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material


previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by an Endorser. <del> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application or workload. Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims relating to the integrity of the bootloader have to be measured securely.  At this stage of the boot-cycle of the device, the Claims collected typically cannot be composed into Evidence. </del>  After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that <del> the successfully measured Target Environment B now becomes (or contains) an Attesting Environment for the next layer.  This procedure in layered attestation is sometimes called "staging".  It is important that the new Attesting Environment B not be able to alter any Claims about its own Target Environment B.  This can be ensured having those Claims be either signed by Attesting Environment A or stored in an untamperable manner by Attesting Environment A. </del>  Continuing with this example, the bootloader's Attesting Environment <del> B is now in charge of collecting Claims about Target Environment C, which in this example is the kernel to be booted.  The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS, plus a set of Claims about the kernel as measured and signed by the bootloader. </del>  This example could be extended further by making the kernel become another Attesting Environment for an application as another Target environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments <del> that it measures, rather than only one as shown in layered. </del>  3.5.

Signed-off-by: Dave Thaler
The relatively abstract text in Layered Attestation Environments could really benefit from a common real world example, e.g. the thing formerly referred to as Secure Boot.
Are you saying that layered attestation is a form of staged boot with Verifiers on the local device? If so, Figure 3 is wrong since it doesn't show the local Verifiers. I think it is an overreach for RATS to classify all staged boot as a form of layered Attestation. See .
The example is so long that the reader misses that it's an example, and the details are too deep.
The illustration is no longer an abstract example.

previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by an Endorser.  <ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system kernel. The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims relating to the integrity of the bootloader have to be measured securely.  At this stage of the boot-cycle of the device, the Claims collected typically cannot be composed into Evidence. </ins> After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that  <ins> the successfully measured bootloader now becomes (or contains) an Attesting Environment for the next layer.  This procedure in layered attestation is sometimes called "staging".  It is important that the bootloader not be able to alter any Claims about itself that were collected by the BIOS.  This can be ensured having those Claims be either signed by the BIOS or stored in a tamper-proof manner by the BIOS. </ins> Continuing with this example, the bootloader's Attesting Environment  <ins> is now in charge of collecting Claims about the next Target Environment, which in this example is the kernel to be booted.  The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS, plus a set of Claims about the kernel as measured and signed by the bootloader. </ins> This example could be extended further by making the kernel become another Attesting Environment for an application as another Target environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments  <ins> that it measures, rather than only one as shown by example in layered. </ins> 3.5.


and the validation key material off the device.  Sometimes this is procedure is referred to as personalization or customization.  One way to provision key material is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality protection of the generator, as well as for the path needs to take care to protect corresponding key material with measures appropriate for its value. <del> Confidentiality protection can be realized via physical provisioning facility security involving no encryption at all.  For low-security use cases, this might be simply locking doors and limiting personnel that can enter the facility.  For high-security use cases, this might involve a special area of the facility accessible only to select security-trained personnel. Typically, cryptography is used to enable confidentiality protection. This can result in recursive problems, as the key material used to </del>  provision attestation keys must again somehow have been provisioned securely beforehand (requiring an additional level of protection, and so on). <del> In general, a combination of some physical security measures and some cryptographic measures is used to establish confidentiality protection. Another way to provision key material is to generate it on the device and export the validation key.  If public-key cryptography is being used, then only integrity is necessary.  Confidentiality of public keys is not necessary. In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is established in Attesters.  For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. </del>  12.2.

and
A few words on the “why that is the case” are needed here.
Both examples basically seem to be the same here?

and the validation key material off the device.  Sometimes this is procedure is referred to as personalization or customization. <ins> 12.1.2.1. </ins> One way to provision key material is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality protection of the generator, as well as for the path needs to take care to protect corresponding key material with measures appropriate for its value.  <ins> The degree of protection afforded to this key material can vary by device, based upon considerations as to a cost/benefit evaluation of the intended function of the device.  The confidentiality protection is fundamentally based upon some amount of physical protection: while encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical protection can therefore vary from situations where the key is unencrypted only within carefully controlled secure enclaves within silicon, to situations where an entire facility is considered secure, by the simple means of locked doors and limited access. The cryptography that is used to enable confidentiality protection of the attestation key comes with its own requirements to be secured. This results in recursive problems, as the key material used to </ins> provision attestation keys must again somehow have been provisioned securely beforehand (requiring an additional level of protection, and so on).  <ins> So, this is why, in general, a combination of some physical security measures and some cryptographic measures is used to establish confidentiality protection. 12.1.2.2. When key material is generated within a device and the secret part of it never leaves the device, then the problem may lessen.  For public- key cryptography, it is, by definition, not necessary to maintain confidentiality of the public key: however integrity of the chain of custody of the public key is necessary in order to avoid attacks where an attacker is able get a key they control endorsed. To summarize: attestation key provisioning must ensure that only valid attestation key material is established in Attesters. </ins> 12.2.


an Attester.  Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in the Verifier's <del> certificate chain. </del>  The Relying Party might implicitly trust a Verifier, such as in a Verifier/Relying Party combination where the Verifier and Relying policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to appraise the trustworthiness of that manufacturer's devices.  Such <del> trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. </del>  In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner.  13. This document does not require any actions by IANA.

Also add a brief security considerations section, based on text from the TEEP architecture draft. Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.

an Attester.  Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in the Verifier's  <ins> certificate path.  Such trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. </ins> The Relying Party might implicitly trust a Verifier, such as in a Verifier/Relying Party combination where the Verifier and Relying policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to appraise the trustworthiness of that manufacturer's devices.  Such  <ins> trust is expressed by storing one or more trust anchors in the Verifier's trust anchor store. </ins> In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. <ins> 12.4. As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation.  See Section 6 of RFC5280 for details. </ins> 13. This document does not require any actions by IANA.


16.  The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time, such as the Coordinated

Note that section 10.4 (Freshness.Discussion) already said: So the intro text tries to be consistent with that phrasing. Signed-off-by: Dave Thaler
pushed 7c75ffe to fix the CI
Appendix A needs more introduction text to highlight its value to the reader.
LGTM

16. <ins> freshness discussed various issues and requirements around freshness of evidence, and summarized three approaches that might be used by different solutions to address them.  This appendix provides more details with examples to help illustrate potential approaches, to inform those creating specific solutions. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time, such as the Coordinated


Produces: Appraisal Policy for Evidence A role performed by an entity (typically a manufacturer) whose <del> Endorsements help Verifiers appraise the authenticity of Evidence. </del>  Produces: Endorsements 8.2. An Endorsement is a secure statement that some entity (e.g., a <del> manufacturer) vouches for the integrity of the device's signing capability.  For example, if the signing capability is in hardware, then an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware.  Thus, when Evidence and such an Endorsement are used together, an appraisal procedure can be conducted based on appraisal policies that may not be specific to the device instance, but merely specific to the manufacturer providing the Endorsement. For example, an appraisal policy might simply check that devices from a given manufacturer have information matching a set of Reference Values, or an appraisal policy might have a set of more complex logic on how to appraise the validity of information. </del>  However, while an appraisal policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it

Align Section 8.2 with the definition in Section 4.2 Relax the definition of Endorser in Section 4.1 to drop the exclusive coupling between Endorsements and authenticity appraisal
In §4.2 Endorsement is defined as: "A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and Evidence signing." uses a more restrictive description: "An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing capability.", which seems to limit the scope of an Endorsement to the verification of the Attester's signature on Evidence. I think §8.2 should be rephrased to align with §4.2 so to allow Endorsements to be more than just verification keys. Besides, the definition of Endorser in §4.1: "[…] Endorsements help Verifiers appraise the authenticity of Evidence" could be relaxed to drop the (seemingly) exclusive coupling of Endorsements with authenticity appraisal.
+1 Re: §4.1 the alignment of "Endorsements" with "Evidence" seems overly constraining since Reference Values are expected to match Evidence while Endorsements are not expected to be compared to Evidence. The wording "authenticity of Evidence" is what Endorsements qualify but that is too narrow as it could also appraise other Attesting Environment functionality such as Claims Collection, key generation, signing as well as launching code, transitioning to other environments, storing secrets and there could be more.
Huh. I checked both sections and... I think you both might be right here. While it's not the intent of Section 8.2, factually it seems to be artificially constraining (by accident?). I have to admit, I did not catch that discrepancy. My initial assessment is that - as we took great care with the "normative anchor" that is Section 4.2 - we did not pay enough attention to align Section 8.2 with that. Taking into account NAME and NAME assessment, I think this is an editorial issue. Could NAME please provide a proposal and NAME please review that first, so that we can address this issue along the upcoming next review phase. This action depends on this change remaining to be a editorial harmonization (again, which I think it is). If there are any counter indications that this is bordering on normative impact, please highlight so.
"In some cases, an Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing capability."
reads good to me

Produces: Appraisal Policy for Evidence A role performed by an entity (typically a manufacturer) whose  <ins> Endorsements may help Verifiers appraise the authenticity of Evidence and infer further capabilities of the Attester. </ins> Produces: Endorsements 8.2. An Endorsement is a secure statement that some entity (e.g., a  <ins> manufacturer) vouches for the integrity of the device's various capabilities such as claims collection, signing, launching code, transitioning to other environments, storing secrets, and more.  For example, if the device's signing capability is in hardware, then an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware.  Thus, when Evidence and such an Endorsement are used together, an appraisal procedure can be conducted based on appraisal policies that may not be specific to the device instance, but merely specific to the manufacturer providing the Endorsement.  For example, an appraisal policy might simply check that devices from a given manufacturer have information matching a set of Reference Values, or an appraisal policy might have a set of more complex logic on how to appraise the validity of information. </ins> However, while an appraisal policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it


operational status, health, configuration or construction that have security relevance.  Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.  Claims need to be <del> collected in a manner that is reliable.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </del>  8.2.

`
This is trying say that the Target Environment can't lie to the Attesting Environment about its trustworthiness properties.
Spot on. A text proposal (NEW) based on Ned's comment:

operational status, health, configuration or construction that have security relevance.  Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.  Claims need to be  <ins> collected in a manner that is reliable such that a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </ins> 8.2.


Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If <del> confidentiality protection of the conceptual messages is omitted or unavailable, the protecting protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </del>  As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Fixes line in privacy section that was unclear about using encryption as a privacy protection approach.
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
I suggest sticking to defined terminology such as 'conveyance protocol' instead of 'protecting protocols'. The 'kinds of information disclosed' is terminology for 'Claims'. It might make sense to include the line "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."
"for example, if there isn't object-level confidentiality protection of messages, then the transport protocol should provide it" "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."

Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If  <ins> there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted


that a device is running a weak version of firmware provides a way to aim attacks better. <del> Many Claims in Evidence and Attestation Results are potentially Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that goes up to include containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </del>  In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the

Fixes issue
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
Yes. However, without a suitable privacy tracking identifier, it might not be possible to correlate privacy sensitive information in the policy with the actions of the Attester.
We should add privacy applies to appraisal policy to Privacy section.

that a device is running a weak version of firmware provides a way to aim attacks better.  <ins> Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </ins> In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the


the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is,

Section 10. I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test. In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted. This section delves into specific implementation choices. In particular, Is the WG sure that it needs all of the details of Section 10.3. Even among all of the Section in 10., this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept. Section 12.3
I agree with the observation, but don't believe it requires any changes.
This was carefully discussed and weighed over the entire editorial WG phase, actually. We found delicate consensus that might have also resulted in an unusual high level of attention to detail, but that detailed is most certainly warranted here especially. I think the text reflects the WG consensus building in an appropriately nuanced fashion today and am very hesitant with trying to refactor it again (even if it suddenly spikes to a maybe surprising level of detail) as I deem it unlikely that it will improve by that, tbh.
"This section is intended for those creating protocols or solutions to understand the options available to ensure freshness"

the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. <ins> This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract. This section is intended for those creating protocols and solutions to understand the options available to ensure freshness.  The way in which freshness is provisioned in a protocol is an architectural decision.  Provisioning of freshness has an impact on the number of needed round trips in a protocol, and therefore must be made very early in the design.  Different decisions will have significant impacts on resulting interoperability, which is why this section goes into sufficient detail such that choices in freshness will be compatible across interacting protocols, such as depicted in multievidence_diag. </ins> Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is,


expected values, or to apply complex analysis of other information contained in the Attestation Result. <del> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </del>  Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer, if Endorsements are used), Attestation Results are

maybe unclear if this was what was intended
massaged the change a bit to retain the previous statement better
` I'm not convinced this analogy is helpful. Yes, it conveys the need for detailed information but it also immediately suggests Attestation Results might include PII or privacy sensitive identifiers.
I agree that the analogy to physical passports is misleading. The paragraph tries to justify AR as being detailed and privacy sensitive then in the next paragraph tries to describe them as not needing to be too specific; "Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence." It is sufficient to say that both Evidence and Attestation Results can contain privacy sensitive content. The Attester may rely on the Verifier to obfuscate privacy sensitive Claims that were shared as part of Evidence.
It should be clear that appraising Evidence involves various procedures that are part of the appraisal and that these can be quite resource intensive (like creating a passport), in contrast to Attestation Results that are intended to be easily digestible and universal understood (like using a passport)!
add, "URL contain privacy sensitive information as discussed in section {Privacy}"

expected values, or to apply complex analysis of other information contained in the Attestation Result.  <ins> Thus, Attestation Results can contain detailed information about an Attester, which can include privacy sensitive information as discussed in section privacy-considerations.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </ins> Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer, if Endorsements are used), Attestation Results are


In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for <del> the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </del>  In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Reworded paragraph following the word 'vouch' to better explain the how Endorsements affect Verifier's trust in the Attester.
`
"... vouch for the Attester's ability to securely generate Evidence by asserting endorsement claims regarding the ways in which attestation keys are protected. Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be included in the Verifier's appraisal."
This proposal is definitely a step into the right direction. We should not overload this, but I think this is appropriately improved.
"attestation keys are protected" is too narrow
See PR

In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for  <ins> the Attester's ability to securely generate Evidence through Endorsements (see endorsements).  Endorsements might describe the ways in which the Attester resists attack, protects secrets and measures Target Environments.  Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be authenticated and used in the Verifier's appraisal process. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material


value of specific Claims if it knew that only certain values were accepted by the Relying Party. <del> Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </del>  As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Signed-off-by: Dave Thaler
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.

value of specific Claims if it knew that only certain values were accepted by the Relying Party.  <ins> Conceptual messages carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted


and the validation key material off the device.  Sometimes this procedure is referred to as personalization or customization.  12.1.2.1. One way to provision key material is to first generate it external to

** Section 12.1.2. I didn't see any of the obvious text that regardless of whether the key is generated on or off device, high quality randomness is needed.

and the validation key material off the device.  Sometimes this procedure is referred to as personalization or customization. <ins> The keys generated in the factory, whether generated in the device or off-device by the factory SHOULD be generated by a Cryptographically Strong Sequence (RFC4086, Section 6.2). </ins> 12.1.2.1. One way to provision key material is to first generate it external to


attestation defined by RATS is thus a candidate for use in the FIDO protocol. <del> Every FIDO Authenticator contains an Attester. </del>  Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.

The current attester description in §2.7 is ambiguous and inconsistent with the earlier ones. Right now it reads: "Attester: Every FIDO Authenticator contains an Attester." To clarify and align the attested description with the earlier ones, I suggest replacing this text with: "Attester component contained in a FIDO authenticator".
Both definitions seem OK to me. The goal of the use cases isn't to provide a technical decomposition of the FIDO device IMHO. Rather, it is to provide a cursory level mapping to the abstract roles / role messages. In fact, if a change is needed I would simply have it say "Attester: FIDO Authenticator".
I agree that a technical decomposition is not the goal, however the current formulation just differs too much from the other ones. The change you suggested - "Attested: FIDO Authenticator" - is a good alternative.
"Attester: A FIDO Authenticator".

attestation defined by RATS is thus a candidate for use in the FIDO protocol.  <ins> FIDO Authenticator. </ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.


12.4. As noted in trustmodel, Verifiers and Relying Parties have trust <del> anchor stores that must be secured.  Specifically, a trust anchor </del>  store must resist modification against unauthorized insertion, deletion, and modification.

Section 12.4. Is there any read sensitivity for the trust anchor store? Section 12.4. Since RFC5280 is being invoked here, is there an expectation that certificates in RATS would confirm to this profile?
-> "For example, see Section 6 of [RFC5280]" Discussion ensued about whether there is read sensitivity vs audit requirements, and whether this is even specific to RATS at all.
RFC6024 URL ?
"As noted in Section 7, Verifiers and Relying Parties have trust anchor stores that must be secured. RFC6024 contains more discussion of trust anchor store requirements."

12.4. As noted in trustmodel, Verifiers and Relying Parties have trust  <ins> anchor stores that must be secured.  RFC6024 contains more discussion of trust anchor store requirements.  Specifically, a trust anchor </ins> store must resist modification against unauthorized insertion, deletion, and modification.


This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security <del> threats listed below have been mitigated well.  The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). </del>  12.1. Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO <del> authenticator.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </del>  Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and

purpose statement into beginning of Security Considerations. I moved the statement to the beginning of section 12, but maybe some wanted it moved to the beginning of 12.1.
** Section 12.1.1 An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted"
Section 12.1.1 Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted" I think the statement is closer to "A foundational security assumption of a RATS architecture it that a Relying Party is able to establish the basis for trusting the Attester functions, or Attester users.
Remove word "assumption", as this is an input, and we are talking about the output. move this sentence to the beginning of that section. "The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester."

This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security  <ins> threats listed below have been mitigated well. The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester. </ins> 12.1. Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO  <ins> authenticator. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and