Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable <del> of claims collection for a given Target Environment.  Attesting Environments are designed specifically with claims collection in mind. </del>  4.3.

Kathleen's review Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure. The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "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." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended. Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "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 hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. " Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen

Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable  <ins> of claims collection for a given Target Environment.  Execution environments that are designed to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 4.3.


attestation is desired to be added: In this diagram, the protocol between Attester and a Relying Party <del> can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x, OPC UA, etc.), depending on the use case.  Such protocols typically already have mechanisms for passing security information for purposes of authentication and authorization.  Common formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates. </del>  To enable remote attestation to be added to existing protocols, enabling a higher level of assurance against malware for example, it

This proposes to add ROLIE to the list of potential conveyance protocols.
Kathleen's review Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure. The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "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." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended. Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "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 hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. " Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen

attestation is desired to be added: In this diagram, the protocol between Attester and a Relying Party  <ins> can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE RFC8322, 802.1x, OPC UA, etc.), depending on the use case.  Such protocols typically already have mechanisms for passing security information for purposes of authentication and authorization.  Common formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates. </ins> To enable remote attestation to be added to existing protocols, enabling a higher level of assurance against malware for example, it


The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a <del> device.  In many cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/software that the device is running.  This information might be particularly interesting to many attackers.  For example, knowing </del>  that a device is running a weak version of firmware provides a way to aim attacks better.  Evidence and Attestation Results data structures are expected to support integrity protection encoding (e.g., COSE, JOSE, X.509) and optionally might support confidentiality protection (e.g., COSE,

Kathleen's review Further privacy considerations: Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well.
Pull request tries to start. Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure. The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "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." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended. Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "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 hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. " Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen

The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a  <ins> device as well as any users the device is associated with.  In many cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/ software that the device is running.  This information might be particularly interesting to many attackers.  For example, knowing </ins> that a device is running a weak version of firmware provides a way to aim attacks better. <ins> Many claims in Attestation Evidence and Attestation Results are potentially PII (Personally Identifying Information) depending on the end-to-end use case of the attestation.  Attestation that goes up to include containers and applications may further reveal details about a specific system or user. In some cases, an attacker may be able to make inferences about attestations from the results or timing of the processing.  For example, an attacker might be able to infer the value of specific claims if it knew that only certain values were accepted by the Relying Party. </ins> Evidence and Attestation Results data structures are expected to support integrity protection encoding (e.g., COSE, JOSE, X.509) and optionally might support confidentiality protection (e.g., COSE,


might, for example, be configured in the Relying Party by an administrator.  5. There are multiple possible models for communication between an

This is a preliminary description of the remote attestation of composite attester
will introduce some new terms that can be used to explain this better.
There was confusion as to whether or not ‘leader’ and ‘subordinate’ were synonyms for ‘attesting environment’ and ‘attested environment’ or whether they were synonymous with ‘component’ and ‘sub-component’ (aka module and sub-module --> “submods”).
Ned suggests that the term Measure be added to connect the Attested Environment and Attesting Environment. There may be multiple Attested Environments that can measured by a single Attesting Environment (such as when there is a TPM, SGX, DICE).
There may be multiple Attested Environments that can measured by multiple Attesting Environment (DICE == TCG standard for generating layered claim sets).
Discussion about combining the two environments together leads to comments about having measuring code in ROM, and then this leads to discussion about having a Manufacturing Certificate. Issuing a manufacturing certificate is an operational way to keep the attesting environment separate from the attested environment.
"attesting" and "attested" are too alliteratively similar. "measure" is the process. "measuring environment"... discussed. "surveyor" is suggested. MW: implies that they are actively "going out" and doing it.
URL
Pretty sure "measurement" is taken to mean hashing some bytes of memory, a file or such for later comparison to expected values. Lots of claims are not of that nature, so I'm not so much in favor of this term.
I find that "Claim" is also widely mentioned/used but not yet defined in Terminology. This term may also need to be considered to be introduced in Terminology. Usage examples: The “attester” produces a set of “claims” about a “target”. The claims are known as “attestation evidence”. (From Laurence's email) Claim: A statement about the construction, composition, validation or behavior of an Entity that affects trustworthiness. Evidence, Reference Values and Attestation Results are expressions that consists of one or more Claims. (From draft-birkholz-rats-architecture) The evidence is typically a set of claims about its software and hardware platform. (From the abstract of the current arch draft)
Laurence Lundblade wrote: I believe that the term measurement was used rather than the term "hash"(ing), because not all evidence is in the form of a hash.
The term "claim" is somewhat inherited from JWT/CWT, but agree we need a definition here in RATS. Seems more like "claim: is an individual chunk of data about a target; the attestation evidence and attestation result is primarily made up of claims". Still don't like the term measurement. I don't think a SW Version, HW Version a GPS location, a public key, most of COSWID and such are measurements.
+1 “Claim” inherits baggage from elsewhere. There has been several threads about alternatives (e.g. “assertions”) as well. Given people are OK with its use, terminology section should include a definition. Arch also determined it is correct to use “assertion” generically to describe interactions between Roles. Claim has more specific context but it needs a definition so we can be on the same page about what that context is.
TCG use of the term ‘measure’ isn’t limited to hashing. The RIV draft / architecture / use case is heavily focused on inspecting SW/FW modules using hashing so it can come across as though that is the only interpretation. The important relevance is that ‘measuring’ is something that happens before ‘attesting’ (signing). Measuring could happen by an environment that is different from the ‘attesting environment’. However, the trust model semantics equate them as being equal, therefore for convenience and simplicity it is OK to avoid introducing another term.
The terms "collect" and "record" are also suggested. --> "record the values of claims"... "audit log" --> "collect the values of claims" HB: Claims are name/value pairs.. but not only this way. Are this way in JWT/CWT, but not in certificates. DT: Certificates are extension ID and and value, why isn't it the same? So, it's the "name" part which is wrong, so maybe it is ID/value pair? We should have a definition of claim, in the generic sense. The semantic meaning may be implied. We can not always find names without colliding, and we can't always invent new names.

might, for example, be configured in the Relying Party by an administrator. <ins> 4.1. A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can be called Lead Attesters, that have the communication functionality with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network connections, and they are evaluated via the Lead Attester's help. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TPM or TEE collecting the claims of its boot process, then it generates Evidence from the claims to prove its trustworthiness.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester and the main slot is the Lead Attester. Another example is a multi-chassis router which is composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the data that flows between the Composite Attester and Verifier for the remote attestation. In the Composite Attester, each Attester generates its own Evidence by its Attesting Environments collecting the claims from its Target Environments.  The Lead Attester collects the Evidence of all other Attesters and then generates the Evidence of the whole Composite Attester. Inside the Lead Attester, there may be an optional Verifying Environment.  The Verifying Environment can verify the collected Evidence of other Attesters to evaluate their trustworthiness. Therefore, there are two situations when the Lead Attester generates the final Evidence. One situation is that the Lead Attester has no Verifying Environment. In this situation, the Lead Attester just collects the Evidence of other Attesters but doesn't verify them.  It may just string all these Evidence into a whole one, or it may reorganize these Evidence with a new structure and sign this final Evidence.  Then it conveys the final Evidence to the Verifier and the Verifier evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester has a Verifying Environment.  After collecting the Evidence of other Attesters, the Lead Attester verifies these Evidence by using the Endorsements and Appraisal Policies, which are got from the Verifier or some reliable parties, for evaluating these Attesters' trustworthiness.  Then the Lead Attester makes the verification results as claims which are the input to the final Evidence of the whole Composite Attester.  Then the Lead Attester conveys the final Attestation Evidence to the Verifier on behalf of the Composite Attester.  Before receiving the Endorsements and Appraisal Policies for other Attesters, to increase the security, the Lead Attester may first generate Evidence about its trustworthiness and convey this Evidence to the Verifier for evaluating. </ins> 5. There are multiple possible models for communication between an


15.  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 Coordinated How and if clocks are synchronized depends upon the model. <del> 15.1. </del>  The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". <del> 15.2. </del>  The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". <del> 15.3. </del>  Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. <del> 15.4. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.5. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.

15. <ins> Thomas Hardjono created older versions of the terminology section in collaboration with Ned Smith.  Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows.  Monty Wisemen created the content structure of the first three architecture drafts.  Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model. 16. </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 Coordinated How and if clocks are synchronized depends upon the model.  <ins> 16.1. </ins> The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)".  <ins> 16.2. </ins> The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)".  <ins> 16.3. </ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role.  <ins> 16.4. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized The time considerations in this example are equivalent to those discussed under Example 1 above.  <ins> 16.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any


8.3. <del> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </del>  An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying

Address issue
Attestation Result is far more than compliance/non-compliance for many / most use cases. Attestation Results may contain lots claims that are passed through from the device (e.g., GPS location). I would also expect information from the Endorsement to be passed through, particularly in the case where the Verifier is an aggregator. Implied claims would also show up in the Attestation Result.
Section 7.3 starts out "Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy" implying binary yes/no results. Section 7.3 needs to get rewritten some so results can be very rich with dozens of claims that are input to the RP's risk engine.
The -05 draft with Attestation Results moved to section 8.3 still has too much emphasis on compliance/non-compliance.

8.3.  <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.  Attestation Results may be a Boolean simply indicating compliance or non-compliance with a Verifier's Appraisal Policy, or a rich set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </ins> An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying


A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time  4. dataflow depicts the data that flows between different roles,

Address . There are on the order of 1 billion users of biometric authentication
Discussion: everything you can do, RATS can do better :) Aka every authentication/access control use case is an attestation use case. Laurence to take a first shot at adding text into intro above use cases. Details would be in a doc from FIDO or W3C.
FIDO and Android are attestation use cases with billions of users today and are different from all the ones currently listed, so at least one of them should be added.
Ok to merge

A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time <ins> 3.7. In the Fast IDentity Online (FIDO) protocol WebAuthN, CTAP, the device in the user's hand authenticates the human user, whether by biometrics (such as fingerprints), or by PIN and password.  FIDO authentication puts a large amount of trust in the device compared to typical password authentication because it is the device that verifies the biometric, PIN and password inputs from the user, not the server.  For the Relying Party to know that the authentication is trustworthy, the Relying Party needs to know that the Authenticator part of the device is trustworthy.  The FIDO protocol employs remote attestation for this. The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added.  Remote attestation defined by RATS is thus a candidate for use in the FIDO protocol. Other biometric authentication protocols such as the Chinese IFAA standard and WeChat Pay as well as Google Pay make use of attestation in one form or another. Every FIDO Authenticator contains an Attester. Any web site, mobile application back end or service that does biometric authentication. </ins> 4. dataflow depicts the data that flows between different roles,


The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which <del> depends on using a secure clock synchronization mechanism. </del>  The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where solution that uses nonces and thus does not require that any clocks are synchronized.  In this example solution, the Verifier can check whether the Evidence <del> is fresh at time(RG) by verifying that "time(RG) - time(NS) < </del>  Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to <del> correctly provide the delta time(EG)-time(VG), then it can determine recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < Threshold". </del>  Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the <del> Attestation Result is fresh by checking "time(OP) - time(NS') + time(RR)-time(EG) < Threshold".  Although the Nonce2 and time(RR)- time(EG) values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </del>  The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(NS') < time(RX)-time(RG)". </del>  15.3. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that <del> "time(OP) - time(NR) < Threshold". </del>  The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(ER) < time(RX)-time(RG)". </del>

Per offline discussion between Henk and Dave, trying this annotation to see if it helps Also try combining VG and AA into VC since nothing in doc uses AA, and any example could use either VG or AA, so combining makes any example work for both. Signed-off-by: Dave Thaler

The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which  <ins> depends on using a secure clock synchronization mechanism.  As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. </ins> The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where solution that uses nonces and thus does not require that any clocks are synchronized. <ins> As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus we use a suffix (a for Attester, v for verifier, and r for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </ins> In this example solution, the Verifier can check whether the Evidence  <ins> is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < </ins> Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to  <ins> correctly provide the delta "time(EG_a)-time(VG_a)", then it can determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold". </ins> Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the  <ins> Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold".  Although the Nonce2 and "time(RR_a)-time(EG_a)" values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a  <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". </ins> 15.3. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that  <ins> "time(OP_r)-time(NR_r) < Threshold". </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a  <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- time(RG_v)". </ins>


15.3.  The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.4. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

This is an evolution of PR and based on Issue Attester Awareness time(AA) is not included in this PR (see ), but a concise definition of Handle received (HR). The included diagram might need more work. Also a "background-check version" might be perceived as missing. Do we need one? (oh and the compilations errors due to malformed references are also fixed in this PR. pls always make sure your commit compiles before push)
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is. 7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this. 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .
Much better than previous PR but needs some cleanup

15.3. <ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to all RATS roles that interact with each other, such as the Attester or Verifier, in specified intervals.  To enable this availability, handles are distributed centrally by the Handle Distributor role over the network.  As any other role, the Handle Distributor role can be taken on by a dedicated entity or collapsed with other roles, such as a Verifier.  The use of handles can compensate for a lack of clocks or other sources of time on entities taking on RATS roles.  The only entity that requires access to a source of time is the entity taking on the role of Handle Distributor. Handles are different from nonces as they can be used more than once and can be used by more than one entity at the same time.  Handles are different from timestamps as they do not have to convey information about a point in time, but their reception creates that information.  The reception of a handle is similar to the event that increments a relative tickcounter.  Receipt of a new handle invalidates a previously received handle. In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  The time that represents this event is named Handle received: time(HR).  Due to distribution over the network, there is some jitter with respect to time(HR) for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR') + offset - time(HR)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR) - time(EG) < validity-duration". From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the Evidence generation is younger than the duration of the distribution interval - "(time(HD')-time(HD)) - (time(HR)-time(EG)) < validity- duration". Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting granularity (time resolution) of Evidence freshness is typically lower than the resolution of clock-based tickcounters. The following example illustrates a hypothetical Background-Check Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. 15.4. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above.  <ins> 15.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any


built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations.  15.1. The following example illustrates a hypothetical Passport Model can directly compare it to its own clock and timestamps. The Verifier can check whether the Evidence is fresh when appraising <del> it at time(RG) by checking "time(RG) - time(EG) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  <del> If time(VG) is also included in the Evidence along with the claim </del>  value generated at that time, and the Verifier decides that it can <del> trust the time(VG) value, the Verifier can also determine whether the claim value is recent by checking "time(RG) - time(VG) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  The Relying Party can check whether the Attestation Result is fresh <del> when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to </del>  account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at <del> time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del>  15.2. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. <del> Thus we use a suffix (a for Attester, v for verifier, and r for </del>  Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at <del> roughly the same time.  The time that represents this event is named Handle received: time(HR).  Due to distribution over the network, there is some jitter with respect to time(HR) for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR') + offset - time(HR)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR) - time(EG) < validity-duration". </del>  From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the Evidence generation is younger than the duration of the distribution <del> interval - "(time(HD')-time(HD)) - (time(HR)-time(EG)) < validity- duration". </del>  Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting

This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label

built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. <ins> All times are relative to the local clocks, indicated by an "a" (Attester), "v" (Verifier), or "r" (Relying Party) suffix. How and if clocks are synchronized depends upon the model. </ins> 15.1. The following example illustrates a hypothetical Passport Model can directly compare it to its own clock and timestamps. The Verifier can check whether the Evidence is fresh when appraising  <ins> 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 maximum permitted clock skew between the Verifier and the Attester. </ins>  <ins> If time(VG_a) is also included in the Evidence along with the claim </ins> value generated at that time, and the Verifier decides that it can  <ins> trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh  <ins> when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) < Threshold", where the Relying Party's threshold is large enough to </ins> account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at  <ins> time(RA_r)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". </ins> 15.2. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  <ins> Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for </ins> Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at  <ins> roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity- duration: "time(HR_v) - time(EG_a) < validity-duration". </ins> From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the Evidence generation is younger than the duration of the distribution  <ins> interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < validity-duration". </ins> Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting


6. <del> An Attester consists of at least one Attesting Environment and Attested Environment.  In some implementations, the Attesting and Attested Environments might be combined.  Other implementations might have multiple Attesting and Attested Environments. </del>  7.

Incorporating text from draft-birkholz-rats-architecture and from my reading of the "bike shed" mailing list thread Signed-off-by: Dave Thaler

6.  <ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Target Environments are measured.  They provide the raw values and the information to be represented in claims and ultimately expressed as Evidence. Attesting Environments conduct the measuring.  They collect the claims, format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 7.


a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences.  A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a <del> 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 </del>  against values in other claims, or any other test. <del> Such reference values might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. </del>  <del> 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> 4.2. </del>  An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting capable of claims collection are referred to in this document as Attesting Environments. <del> 4.3. </del>  By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown in layered. <del> 4.4. </del>  A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal 7.5. <del> In some scenarios, the Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner- trust. </del>  8. 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 <del> a given manufacturer have information matching a set of known-good 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 Party's Appraisal Policy.  The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier.  A more complex policy might also <del> entail comparing information provided in the result against known- good reference values, or applying more complex logic on such information. </del>  Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical

Need Peter to confirm he agrees, but I believe these changes are consistent with the points that Peter and I were both making during the last call. Signed-off-by: Dave Thaler
To complete this, a sub section for Reference Value Provider should be added to section 7 on the Trust Model. All other such entities are described there now.
Here's some possible text. Endorser The primary function of an Endorser is to endorse an Attester so that a Verifier can know to trust that Attester. The Endorser does this by creating an Endorsement and conveying it securely to the Verifier. The primary basis for a Verifier trusting an Attester is the Endorsement. There is thus an existential relationship between Attesters and Endorsers. An Attester with no Endorsement is not worth very much since there is no good basis by which a Verifier can trust it so every Attester needs an Endorser. The Endorser’s primary function is to endorse Attesters so an Endorser doesn’t have anything to do without some Attesters to endorse. A Verify cannot do its job without Endorsements. It must have an Endorsement for each Attester from which it received Attestation Evidence. Without this, the Attester is not trusted and there is no basis for trusting the Evidence it produces. There is a trust triangle between the Endorser, Attester and Verifier. The Endorser tells the Verifier that an Attester is trustworthy. Endorsement Ultimately an Endorsement must be realized as some input bytes to a Verifier and they must be conveyed securely from the Endorser to the Verifier. RATS architecture does not impose any limit or restriction on the formats of these bytes or the conveyance mechanism. In practice they are expected to vary quite widely. In most cases the Endorsement will include the key material that is used to verify signatures on the Evidence. Since the Evidence will contain a nonce, this signature verification serves to authenticate the attester. The Endorsement may also contain information about the Attester such as its type, version, manufacturer and such. In one example, the Endorser and the Verifier are the same legal organization, so secure conveyance is entirely an internal issue for the organization. It may consist of one employee copying a set of public keys from computer in the company to another. In another example, the Endorsement may take the form of a PKI hierarchy. The Endorser conveys a root certificate to the Verifier. The Endorser also creates per-attester certificates under that root. Those per-attester certificates are programmed into Attesters. The Attester sends them to the Verifier attached to the Evidence. There may be several levels of certificates in the PKI hierarchy. The Verifier walks the certificate chain to determine trust. Note in the case the abstract notion of Endorsement comes to the Verifier in two parts, one in an out-of-band secure conveyance or a root certificate and the other as the signed (self-securing) certificates from the Attester. Unendorsed Attesters The use of unendorsed Attesters is discouraged because there is no good basis for establishing trust in them. An unendorsed Attester may still have a signing key and produce signed evidence. A Verifier may choose to have some trust in the Evidence they produce by assuming they are trusted on first use (TOFU), building up trust over time after seeing a lot of presumably good attestation evidence, or because it is fed into a machine learning algorithm that correlates to known fraud. Rats architecture include any facilities, details or designs for this mode of use and explicitly considers it insecure.
Two updated proposal options from URL 1) Expand the notion of an Endorsement quite a lot. Endorsements are not longer just static documents like X.509 certs and/or COSE/CMS signed blobs. They are anything that conveys the attestation key material into the Verifier or allows Verification of the attester. They must support confidentiality. 2) Replace the term “Endorsement” with something like “Verifier Input” or “Attester Trust Criteria” in the architecture document as the means by which key material goes into the Verifier. Endorsements still exist, but are just one type of Verifier Input or Attester Trust Criteria just like EAT is one kind of Attestation Evidence. Laurence proposes to follow one of theses options and highlights a slight preference for his 2nd option.
PR was related to that, is this now addressed or what gaps remain?
We acted on Laurence's preference in . I presented this slide below the IETF 108 RATS meeting today. I believe it is critical that the RATS architecture allow for all uses case in the slide. In particular RATS architecture must allow for symmetric keys. TPMs and public-key based crypto is too expensive for low-cost, large-scale IoT. There are real use cases supported my multiple companies using symmetric keys. Symmetric keys can be made secure at the verifier — we secure keys for TLS at servers all the time using HSMs and such. I do NOT want to put this taxonomy into the RATS architecture document. I don’t think that is necessary. I created the taxonomy as background information and as illustrative examples of real world designs. I think there are options for adjusting the architecture document to accommodate this. Option 1) Expand the notion of an Endorsement quite a lot. Endorsements are not longer just static documents like X.509 certs and/or COSE/CMS signed blobs. They are anything that conveys the attestation key material into the Verifier or allows Verification of the attester. They must support confidentiality. Option 2) Replace the term “Endorsement” with something like “Verifier Input” or “Attester Trust Criteria” in the architecture document as the means by which key material goes into the Verifier. Endorsements still exist, but are just one type of Verifier Input or Attester Trust Criteria just like EAT is one kind of Attestation Evidence. I have a slight preference for Option 2). I’m interested in opinions of which option to choose. This is issue , opened in GitHub four months ago. It is not a last-minute/new issue. I believe it is in scope with the RATS charter as the charter explicitly mentions attestation key material in the Program of Work. LL My main point of this taxonomy was to affect the RATS architecture document. There was discussion today of it being a separate document perhaps outside of RATS. I’m happy for that to happen, but I don’t want to write it because I have enough RATS/EAT work to do. I’m very happy if other folks want to pick it up and use in other documents :-).

a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. <ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise the authenticity of Evidence. A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference Values are sometimes referred to in other documents as known-good values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of comparison. </ins> A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a  <ins> 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 </ins> against values in other claims, or any other test.  <ins> 4.2. </ins>  <ins> Reference Values used in appraisal might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. The actual data format and semantics of any Reference Values are </ins> specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison.  <ins> 4.3. </ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting capable of claims collection are referred to in this document as Attesting Environments.  <ins> 4.4. </ins> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown in layered.  <ins> 4.5. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal 7.5.  <ins> In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </ins> 8. 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  <ins> 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 Party's Appraisal Policy.  The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier.  A more complex policy might also  <ins> entail comparing information provided in the result against Reference Values, or applying more complex logic on such information. </ins> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical


A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) <del> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability </del>  An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence

Suggested new text for Endorsements definition to make it slightly more broad, but constrained to the operations of an Attesting Environment (which is a subset of an Attester that also might contain Target Environments and other environments) which is focus for why a Verifier cares to get Endorsements.
This now aligns excellently with the overall terminology. Unfortunately, this now uses a term that is well-defined in section 4.2., but not included in the "upfront" terminology section. This is fine text! But it might now impliy the addition of Attesting Environment into this section.

A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519)  <ins> A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and Evidence signing </ins> An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence


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 solutions with weaker security, a Verifier might be configured to implicitly trust firmware or even software (e.g., a hypervisor). </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> hypervisor or firmware is true.  A stronger level of assurance of </del>  security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to <del> hardware tampering.  The component that is implicitly trusted is often referred to as a root of trust. </del>  A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the material and the Attesting Environment with equivalent strength protections.  7.5. In some scenarios, the Endorser, Reference Value Provider, and

attempt to bring the manufacturer/attester/verifier full circle without insisting that endorsements always occuring.

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.  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 some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material (rather than the Endorser's) in its trust anchor store. Such direct trust must first be established at the time of trust anchor store configuration either by checking with an Endorser at that time, or by conducting a security analysis of the specific device.  Having the Attester directly in the trust anchor store narrows the Verifier's trust to only specific devices rather than all devices the Endorser might vouch for, such as all devices manufactured by the same manufacturer in the case that the Endorser is a manufacturer. Such narrowing is often important since physical possession of a device can also be used to conduct a number of attacks, and so a device in a physically secure environment (such as one's own premises) may be considered trusted whereas devices owned by others would not be.  This often results in a desire to either have the owner run their own Endorser that would only Endorse devices one owns, or to use Attesters directly in the trust anchor store.  When there are many Attesters owned, the use of an Endorser becomes more scalable. </ins> 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  <ins> firmware or software is true.  A stronger level of assurance of </ins> security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to  <ins> hardware tampering.  In most cases, components that have to be vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust. The manufacturer of the Attester arranges for its Attesting Environment to be provisioned with key material.  The key material is typically in the form of an asymmetric key pair (e.g., an RSA or ECDSA private key and a manufacturer-signed IDevID certificate) secured in the Attester. The Verifier is provided with an appropriate trust anchor, or provided with a database of public keys (rather than certificates), or even carefully secured lists of symmetric keys.  The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation an Attestation system, but is not the subject of standardization within this architecture. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the material and the Attesting Environment with equivalent strength protections. <ins> See security-considerations for discussion on security strength. </ins> 7.5. In some scenarios, the Endorser, Reference Value Provider, and


or compromised devices from getting access to the network and potentially harming others. <del> Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for </del>  measurements.  The system components perform a series of measurements <del> that may be signed by the Root of Trust, considered as Evidence about </del>  the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is <del> the Root of Trust and the nested, staged, or chained attestation </del>  Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is <del> often referred to as a Root of Trust. </del>  A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the by the Attesting Environment that has the key material that protects the conveyance channel <del> The Root of Trust protects both the conveyance channel key </del>  material and the Attesting Environment with equivalent strength protections. architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it <del> is important to understand the strength of the Root of Trust, e.g., </del>  whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.

Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?

or compromised devices from getting access to the network and potentially harming others.  <ins> Typically, solutions start with a specific component (called a "root of trust") that provides device identity and protected storage for </ins> measurements.  The system components perform a series of measurements  <ins> that may be signed by the root of trust, considered as Evidence about </ins> the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is  <ins> the root of trust and the nested, staged, or chained attestation </ins> Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is  <ins> often referred to as a root of trust. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the by the Attesting Environment that has the key material that protects the conveyance channel  <ins> The root of trust protects both the conveyance channel key </ins> material and the Attesting Environment with equivalent strength protections. architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it  <ins> is important to understand the strength of the root of trust, e.g., </ins> whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.