control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del>  A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of

more details on encoding application group name, for
Reading the paragraph after "An application group can be named in many ways", I was left a bit confused: Why should it be encoded in the Uri-Query? That'd need coordination among all applications running on that host (for it is interfering with the query argument space that's usually left for the application to use). The common partitioning of applications inside a host is left-to-right in the URI, and that puts it in the very last spot. I think I do see what is meant by the discouragement of using the Uri-Host, but doubt that it'd be immediately obvious to general readers. How I understand Uri-Host to be impractical here is that while the request is sent to a well-defined and named URI, the response is a representation of the same URI with the individual server's IP replaced into the authority component, and if two application groups on the same CoAP group use the same path, then there may be clashes, not on the request-response layer (where the responses are bound to request for a particular host name) but in the client's cache of the responses. (And once one is at the point where application groups in the same CoAP group have a disjunct path set, one can do away with identification altogether and just address the unique path). I don't quite follow how this is not "as intended in RFC7252": It is an identifier for who is being addressed, and as such just part of the URI. (For example, if I define my lights group to be named URL and name the resource , then the host name is exactly the group name, and already needs to be put into the request unless there is known URI aliasing). See also URL on "send a Uri-Host" option, with the caveat that I'm a strong proponent of answer A2. Furthermore, the text seems to imply that virtual hosting is something a server would need to go out of its way to implement. It isn't: The Uri-Host option is critical, and a host needs to make the conscious decision to ignore that option; otherwise it's just as much part of finding the addressed resource as all the other Uri-* options are. The best practice is something I can get behind, although I suggest using no identifier on the wire (and just the disjunct set of resources) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded.
Thanks; we do need to improve the current text on these aspects. On Uri-Host and your example "URL" where authority component includes the application group: in this group communication example the sending client would normally DNS-resolve "URL" to a particular multicast IP address, then send the CoAP request to this multicast IP address destination, without including any Uri-Host Option. This works as long as you have a unique 1:1 association between application-group and CoAP-group. In case multiple application-groups map to a single CoAP-group, this doesn't work anymore : a client could be e.g. configured to always include the "Uri-Host" Option to indicate the hostname. Still not the preferred approach I would think. Btw I can't follow answer A2 on the CoAP-Faq, unfortunately: formulation is too complex. In some (common?) constrained use cases, the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to. Then, the application-group would need to be encoded in some way still, e.g. using the Uri-Path Option. Now what our original text tried to suggest is to "misuse" a Uri-Host Option for that. So instead of using an option like: Uri-Path = group123 You would instead use an option: Uri-Host = group123 So this is not a "real" URI hostname but rather a low-level hack to let the client's CoAP stack insert by force an additional option just before sending out the CoAP request. The receiver's CoAP stack would just parse it as the ID of the application-group and not really as a URI-host. Because this gets confusing and potentially messy (proven by the present discussion !) we don't recommend it. So, trying to reiterate if one has configured Group URIs of the form coap://[mcast-ip-address]/resource on the client then by default the Uri-Host Option would get elided. The above mentioned "hack" is to put it back to encode application-group. This has the issue that the application-group name isn't present in the Group URI. if one has configured Group URIs of the form URL on the client then normally by default the authority gets resolved to some IP multicast address before sending it out, and thus while sending it the Uri-Host Option is NOT included in the CoAP encoding but elided. So the receiving server doesn't see the application-group ID because it's not encoded in the request data. (We assume here that multiple application-groups use the same CoAP-group.) Maybe we should discuss this further; what's the effort here / who ensures it / unique between what and what?
Initial text proposed in above PR! We'll merge it in by tomorrow evening, as an improvement (hopefully). What is not included yet is a statement saying that we don't recommend using the non-Group-URI methods of encoding application group name. To do so we would need to clearly state why that is not recommended; still not clear at this moment what the disadvantages of these are.

control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different  <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of


6. <del> Encoding notifications for the HTTPS notifications is the same as the encoding notifications as defined in RFC8040 Section 6.4, with the following changes.  Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- restconf, it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example that would be sent over the HTTPS notif transport would appear as follows: </del>  7.

This adds an XML example. The only question is whether we need a prefix for ietf-https-notif in the example.

6.  <ins> Notifications are encoded as defined in RFC8040 Section 6.4.  The examples in that section apply for sending notifications over the "https-notif" based transport. An example of YANG-Push in JSON would look something like this: An example of YANG-Push in XML would look something like this: </ins> 7.


If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a <del> link pointing to relevant documentation.  Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </del>  If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of <del> RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. </del>  If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status <del> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. </del>  Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST

Issue
NAME NAME pl review re issue
Looks good
the examples of errors use a pattern of using a link in a header, and then (supposedly) using a human-readable error message. what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code?
I agree. coming up in the next draft.
NAME should we close this issue if it is resolved?
NAME closing this issue. Let me know if not addressed with my latest PR.

If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a  <ins> link pointing to relevant documentation.  Following examples shows an error response describing the problem using RFC7807. Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </ins> If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of  <ins> RFC4918. The server can also inform the client by using the HTTP header "Link" as shown below. </ins> If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status  <ins> code with body containing problem description. Or, alternately using the HTTP header "Link" pointing to the relevant documentation </ins> Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST


6. An entity in the RATS architecture includes at least one of the roles <del> 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.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del>  For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

URL 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

6. An entity in the RATS architecture includes at least one of the roles  <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.


role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. <del> In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this </del>  document. 7.

role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester.  <ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this </ins> document. 7.


12.  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 end-to-end

This is to partially
In section 4.2 there is a list of "places an attesting environment can exist" that is limited. The text should be softened to say the list is only examples and there is no formal limitation or requirement on the security of an Attester. There should probably be a detailed description of Attester security in the document, but it should be in Security Considerations. This seems like a glaring omission from Security Considerations.
The considerations weren't the extent of the issue. There is still text in 4.2 that I think needs changing.

12. <ins> 12.1. Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation Key Material.  When either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to high security where low security may be only application or process isolation by the device's operating system and high security involves specialized hardware to defend against physical attacks on a chip. 12.1.1. It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester.  For example the owner or user of a mobile phone or FIDO authenticator is not trusted.  The point of remote attestation is for the Relying Party to be able to trust the Attester even though they don't trust the user or owner. Some of the measures for low level security include process or application isolation by a high-level operating system, and perhaps restricting access to root or system privilege.  For extremely simple single-use devices that don't use a protected mode operating system, like a Bluetooth speaker, the isolation might only be the plastic housing for the device. At medium level security, a special restricted operating environment like a Trusted Execution Environment (TEE) might be used.  In this case, only security-oriented software has access to the Attester and key material. For high level security, specialized hardware will likely be used providing protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel attacks. 12.1.2. Attestation key provisioning is the process that occurs in the factory or elsewhere that establishes the signing key material on the device and the verification key material off the device.  Sometimes this is referred to as "personalization". One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the key is provisioned, is necessary.  This can be achieved in a number of ways. Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security use cases, this might be simply locking doors and limiting personnel that can enter the facility.  For high-security use cases, this might involve a special area of the facility accessible only to select security-trained personnel. Cryptography can also be used to support confidentiality, but keys that are used to then provision attestation keys must somehow have been provisioned securely beforehand (a recursive problem). In many cases both some physical security and some cryptography will be necessary and useful to establish confidentiality. Another way to provision the key material is to generate it on the device and export the verification key.  If public key cryptography is being used, then only integrity is necessary.  Confidentiality is not necessary. In all cases, the Attestation Key provisioning process must ensure that only attestation key material that is generated by a valid Endorser is established in Attesters and then configured correctly. For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. 12.2. </ins> 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 end-to-end


An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, <del> by applying an Evidence Appraisal Policy to assess the </del>  trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, or might be

Change "Evidence Appraisal Policy" -> "Appraisal Policy for Evidence" Fixes editorial nit reported to me by Tolga Acar Signed-off-by: Dave Thaler
looks good.

An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers,  <ins> by applying an Appraisal Policy for Evidence to assess the </ins> trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, or might be


by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might <del> be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. </del>  The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation <del> Results might, for example, be configured in the Relying Party by an administrator. </del>  4.1.

Also, my assumption is that all messages, configs and such go over one of the arrows in the figure. There are no back channels for things that are vital to or a major part of attestation. Seems like it would be a poor document if the major parts of attestation are not explicitly carried in the flows depicted.

by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might  <ins> be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation  <ins> Results is configured in the Relying Party by the Relying Party Owner, and/or is programmed into the Relying Party. </ins> 4.1.


12.  Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.

Merged from draft-thaler-rats-URL Signed-off-by: Dave Thaler
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 .

12. <ins> This document does not require any actions by IANA. 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.


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 <del> 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 </del>  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 <del> 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. </del>  In the Composite Attester, each Attester generates its own Evidence <del> by its Attesting Environments collecting the claims from its Target Environments.  The Lead Attester collects the Evidence of all other </del>  Attesters and then generates the Evidence of the whole Composite Attester. <del> 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. </del>  5.

This attempts to address the remaining feedback on PR on issues that were not fixed before it was merged. Signed-off-by: Dave Thaler
The simple word choice / grammar changes seem OK. I still don't understand the difference between a "claims collector" and a "verifier" (in the case where Attester B, C,... are signing evidence) and a "target environment" (in the case where Attester B, C, ... are not signing evidence). It seems this term isn't actually necessary. The case where Composite Attester is relying Evidence from "sub" attesters, the composite attester (aka claims collector) is relying Evidence not "collecting claims" in the sense that an attester "collects claims about a target environment". I think it is confusing to overload this terminology to also mean "rely Evidence".

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  <ins> be called Lead Attesters, that have the ability to communicate with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network </ins> 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  <ins> its boot process, after which it generates Evidence from the claims. 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 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 conceptual data flow for a Composite Attester. </ins> In the Composite Attester, each Attester generates its own Evidence  <ins> by its Attesting Environment(s) collecting the claims from its Target Environment(s).  The Lead Attester collects the Evidence of all other </ins> Attesters and then generates the Evidence of the whole Composite Attester.  <ins> The Lead Attester's Claims Collector may or may not include its own Verifier.  One situation is that the Claims Collector has no internal Verifier.  In this situation, the Claims Collecctor simply combines the various Evidences into the final Evidence that is sent off to the remote Verifier, which evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester's Claims Collector has an internal Verifier.  After collecting the Evidence of other Attesters, the Claims Collector verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), for evaluating these Attesters' trustworthiness.  Then the Claims Collector combines the Attestation Results into the final Evidence of the whole Composite Attester which is sent off to the remote Verifier, which might treat the claims obtained from the local Attestation Results as if they were Evidence. </ins> 5.


An Attester creates Evidence that is conveyed to a Verifier. <del> The Verifier uses the Evidence, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </del>  The Relying Party uses Attestation Results by applying its own appraisal policy to make application-specific decisions such as

adding the Reference Values to fix issue 185
` And the Verifier uses the Reference Values
I agree that Reference Values should be mentioned here.

An Attester creates Evidence that is conveyed to a Verifier.  <ins> The Verifier uses the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own appraisal policy to make application-specific decisions such as


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 <del> instance, it would provide Evidence to a network infrastructure device to gain access to the network, and to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del>  combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an

update the "Combinations" section to fix issue .
How does this show that both models are required in this example? I suggest changing this sentence in this way. Because I think the combinations have several possibilities and there is no need to detail all possibilities. Any other thoughts?

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  <ins> instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an


As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an <del> Attester role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. </del>  In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this

Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.

As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an  <ins> Attester role. </ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this


12.1. <del> Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. </del>  Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to

12.1.  <ins> Implementers need to pay close attention to the protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because an attacker can forge Evidence or manipulate the Attesting Environment.  For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from each other in some way. </ins> Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to


vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust. <del> 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 of an Attestation system, but is not the subject of standardization within this architecture. </del>  A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the

` 1) Is this a normative statement? 2) I think the next paragraph says that maybe it’s not an asymmetric key, and anyways, keys are out of scope for RATS Arch
In a layered device architecture the previous layer "provisions" the next layer. Hence, it isn't possible for the 'manufacturer' entity to do that. I don't know why a section on "Verifier" is going into so much detail about the Attester.

vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust.  <ins> The manufacturer having arranged for an Attesting Environment to be provisioned with key material with which to sign Evidence, the Verifier is then provided with some way of verifying the signature on the Evidence.  This may be in the form of an appropriate trust anchor, or the Verifier may be 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 of 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


boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> securely.  As such, if appraisal policies for a Relying Party or for a Verifier can be configured via a network protocol, the ability to create Evidence about the integrity of the entity providing the appraisal policy needs to be considered. </del>  The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding

` Does this mean to imply that bogus policy can’t be installed by sneakernet, e.g., on a usb thumb drive??
I don't think the 'via a network protocol' is necessary. The consideration is simply that policies have security considerations that are out of scope of the architecture.

boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained  <ins> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding


Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read- <del> only memory, (B) an updatable bootloader, and (C) an operating system kernel. </del>  Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There

` The loader environment only exists for a second or two, and has few resources… how it is supposed to report evidence to a verifier in that window?
Refers to figure 3, in section 3.4, on layered attestation.
It is rare that early layers generate or convey Evidence. In critical system with appropriate protected capabilities that actually happens. I can see that it is not a common case and would not argue strongly against removing 'B' from that conveyance arc.
Perhaps a better example for which the loader environment is not ephemeral would be where B is the OS and C is an application/workload process.

Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read-  <ins> only memory, (B) an operating system kernel, and (C) an application or workload. </ins> Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There


in read-only memory, (B) a bootloader, and (C) an operating system kernel. <del> The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target </del>  Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims

Changes "read-only BIOS" to "ROM" to align with the diagram
I think the text “the read-only BIOS in this example, has to ensure the integrity of the bootloader” is wrong since the example no longer has a “read-only BIOS” component. It should say “ROM” to be consistent. If ROM is determined to be ambiguous as a Root of Trust and we decide to changed it to "RoT" then this sentence would be updated accordingly.
NAME do you want to fix this still?
I'll add it to my list.

in read-only memory, (B) a bootloader, and (C) an operating system kernel.  <ins> The first Attesting Environment, the ROM in this example, has to ensure the integrity of the bootloader (the first Target </ins> Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims


whether in the same conveyance protocol as part of the Evidence or not.  4. RFC4949 has defined a number of terms that are also used in this

attempt to provide forward reference as requested on Monday
This looks good to me, although I wonder whether the sentence would make more sense at the end of the "Implementation Considerations" section (a couple lines earlier in the document). I am ok either way.
Works for me. That would put that into section 1.
"artifacts are defined by which roles produce them or consume them" - This sentence structure seems awkward. Is "artifacts are defined by the roles that produce or consume them" better?LGTM

whether in the same conveyance protocol as part of the Evidence or not. <ins> As explained in overview, artifacts are defined by which roles produce them or consume them.  In some protocol instantiations, other roles may cache and forward artifacts as opaque data, to one or more entities implementing the consuming role. </ins> 4. RFC4949 has defined a number of terms that are also used in this


obtained via some other mechanism such as being configured in the Verifier by an administrator. <del> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </del> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy

Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler

obtained via some other mechanism such as being configured in the Verifier by an administrator.  The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy


4.1.  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

4.1. <ins> The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a reference value, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. 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. The actual data format and semantics of any reference values are specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. 4.2. </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


Environments are designed specifically with claims collection in mind. <del> 4.2. </del>  By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several

Environments are designed specifically with claims collection in mind.  <ins> 4.3. </ins> By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several


Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation. <del> 4.3. </del>  A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal

Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation.  <ins> 4.4. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal


Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del>  15.1.

only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences

Universal Time, or might be defined relative to some other timestamp or timeticks counter.  <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.


15.3. The following example illustrates a hypothetical Background-Check <del> 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.

15.3. The following example illustrates a hypothetical Background-Check  <ins> Model solution that uses centrally generated identifiers for explicit time-keeping (referred to as "handle" in this example).  Handles can be qualifying data, such as nonces or signed timestamps.  In this example, centrally generated signed timestamps and - and synchronized clocks between all entities - are distributed in periodic intervals as handles.  If the Attester lacks a source of time based on an absolute timescale, a relative source of time, such as a tick counter can be used, alternatively.  In this example, evidence generation is not triggered at value generation, but at events at which the Attesting Environment becomes of changes to the Target Environment. In comparison with example 1, the time considerations in this example go into more detail with respect to the life-cycle of Claims and Evidence.  While the goal is to create up-to-date and recent Evidence as soon as possible, typically there is a latency between value generation and Attester awareness. At time(AA) the Attesting Environment is able to trigger an event (e.g. based on an Event-Condition-Action model) to create attestation Evidence that is as recent as possible.  In essence, at time(AA) the Attesting Environment is aware of new values that where generated at time(VG) and corresponding Claim values are collected immediately. Consecutively, Evidence based on relevant "old" Claims and the just collected "new" Claims is generated at time(EG).  In essence, the Claims used to generate the Evidence are generated at various time(VG) before time(AA). In order to create attestation Evidence at at time(AA), the Attester requires a fresh (i.e. not expired) centrally generated handle that has been distributed to all involved entities. In general, The duration a handle remains fresh depends on the content-type of the handle.  If it is a (relative or absolute) timestamp, clocks synchronized with a shared and trustworthy source of time are required.  If another value type is used as a handle, the reception time of the handle time(HD) provides an epoch (relative time of zero) for measuring the duration of validity (similar to a heart-beat timeout).  From the point of view of a Verifier, validity of Evidence is only given if the handle used in Evidence satisfies delta(time(HD),time(EG))distribution-interval. In this usage scenario, time(VG), time(AA), and time(EG) are tightly coupled.  Also, the absolute point in time at which a handle is received by all three entities is assumed to be close to identical. </ins> 15.4.


attempted against.  An empty redemption is returned when the limit has been hit:  6. We present a number of security considerations that prevent malicious

cc NAME
There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions. This was raised in the previous WG meeting: URL This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem, and/or security considerations. There is also the option of declaring a separate document for addressing this.
A draft has been put forward for this by Mark McFadden: URL, and will be discussed at IETF 110. Will leave this open for now, until this draft (or some form of it) is accepted.

attempted against.  An empty redemption is returned when the limit has been hit: <ins> 5.4. A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the model used to control the Web's trust model. Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role of attestation in one or few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which attester implementations were chosen.  As a result, clients could have more opportunities to switch between attestation participants. </ins> 6. We present a number of security considerations that prevent malicious


that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin <del> authorization tokens that protect the client's anonymity during </del>  interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in

Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin  <ins> authorization tokens that protect the Clients' anonymity during </ins> interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in


properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA <del> challenges can be attested to have this capability for the purposes of being ruled out as a bot or otherwise automated Client. </del>  Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the <del> number of issuance protocol invocations, the client's geographic </del>  region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements. <del> Each of these attestation types have different security properties. </del>  For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.

properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA  <ins> challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client. </ins> Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the  <ins> number of issuance protocol invocations, the Client's geographic </ins> region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements.  <ins> Each of these attestation types has different security properties. </ins> For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.


on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In <del> Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow-lists. </del>  3.2.2.

on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In  <ins> Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2.


any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that <del> an Issuer uses to produce tokens corresponds to a number of different pieces of information. </del>  The issuance protocol in use; and

any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that  <ins> an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and


public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during <del> token issuance.  In normal circumstances, clients cannot determine if </del>  this value is correct or otherwise a tracking vector. <del> Private metadata is that which clients cannot observe as part of the </del>  token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21.

public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during  <ins> token issuance.  In normal circumstances, Clients cannot determine if </ins> this value is correct or otherwise a tracking vector.  <ins> Private metadata is that which Clients cannot observe as part of the </ins> token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21.


different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's <del> anonymity set shrinks to the total number of clients controlling </del>  tokens for the same keys. In the following, we consider the possible ways that Issuers can

different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's  <ins> anonymity set shrinks to the total number of Clients controlling </ins> tokens for the same keys. In the following, we consider the possible ways that Issuers can


Client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the Issuer.  When an Issuer rotates their key, any Client that invokes the issuance protocol in this key <del> cycle will be part of a group of possible clients owning valid tokens </del>  for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients.

Client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the Issuer.  When an Issuer rotates their key, any Client that invokes the issuance protocol in this key  <ins> cycle will be part of a group of possible Clients owning valid tokens </ins> for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients.


partition, the Client limits the number of different Issuers used to a small number to maintain the privacy properties the Client requires.  As long as each redemption partition maintains a strong <del> privacy boundary with each other, the verifier will only be able to learn a number of bits of information up to the limits within that "redemption partition". </del>  To support this strategy, the client keeps track of a "partition" which contains the set of Issuers that redemptions have been

partition, the Client limits the number of different Issuers used to a small number to maintain the privacy properties the Client requires.  As long as each redemption partition maintains a strong  <ins> privacy boundary with the others, the number of bits of information the verifier can learn is bounded by the number of "redemption partitions". </ins> To support this strategy, the client keeps track of a "partition" which contains the set of Issuers that redemptions have been


6. <del> We present a number of security considerations that prevent malicious Clients from abusing the protocol. 6.1. </del>  When a Client holds tokens for an Issuer, it is possible for any verifier to cause that client to redeem tokens for that Issuer.  This can lead to an attack where a malicious verifier can force a Client to spend all of their tokens from a given Issuer.  To prevent this from happening, tokens can be scoped to single Origins such that they <del> can only be redeemed within for a single Origin. </del>  If tokens are cross-Origin, Clients should use alternate methods to prevent many tokens from being redeemed at once.  For example, if the

6.  <ins> Beyond the aforementioned security gaols for the Issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to mitigate the risk of abuse by malicious Clients. </ins> When a Client holds tokens for an Issuer, it is possible for any verifier to cause that client to redeem tokens for that Issuer.  This can lead to an attack where a malicious verifier can force a Client to spend all of their tokens from a given Issuer.  To prevent this from happening, tokens can be scoped to single Origins such that they  <ins> can only be redeemed for a single Origin. </ins> If tokens are cross-Origin, Clients should use alternate methods to prevent many tokens from being redeemed at once.  For example, if the


directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance <del> protocol, in the original Privacy Pass protocol PPSRV, tokens were </del>  only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact.

[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL

directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance  <ins> protocol, in the original Privacy Pass protocol PPEXT, tokens were </ins> only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact.


valid token available, it presents the token to the origin (redemption).  2.1. Origins send a token challenge to clients in an "WWW-Authenticate"

it's not crystal-clear what the interaction model for this auth scheme is. In many auth schemes, the credential is repeated on each request, to keep the protocol stateless, and to prove the client's identity. However, that doesn't seem to be desireable here -- not only would it make all of those responses uncacheable, it would (AIUI) 'spend' a lot of private tokens. OTOH, the 'realm' parameter is explicitly supported (albiet without much detail), which implies the opposite. I think the preferred interaction model is that a token is only spent upon an explicit challenge from the server, but it was difficult to discern this from the documentation. Either way, it'd be good to clarify this.
Correct, the client shouldn't spend a token multiple times, and shouldn't keep including the credential on future requests. We could drop the realm text, but I think allowing it as a MAY does leave open use cases that might want to segment up different use cases of tokens.
Yeah, unless there's a reason to omitting it, I think keeping the MAY for the realm is fine. I tried to get a sense for how clients are intended to use other auth schemes from RFC 9110, but it wasn't clear to me. NAME do you know of other auth scheme specifications that make the interaction model more clear?

valid token available, it presents the token to the origin (redemption). <ins> Unlike many authentication schemes in which a client will present the same credentials across multiple requests, tokens used with the "PrivateToken" scheme are single-use credentials, and are not reused. Spending the same token value more than once allows the origin to link multiple transactions to the same client.  In deployment scenarios where origins send token challenges to request tokens, origins ought to expect at most one request containing a token from the client in reaction to a particular challenge. </ins> 2.1. Origins send a token challenge to clients in an "WWW-Authenticate"


The Privacy Pass protocol provides a privacy-preserving authorization mechanism.  In essence, the protocol allows clients to provide cryptographic tokens that prove nothing other than that they have <del> been created by a given server in the past I-D.ietf-privacypass- architecture. </del>  This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. <del> This document DOES NOT cover the architectural framework required for running and maintaining the Privacy Pass protocol in the Internet setting.  In addition, it DOES NOT cover the choices that are necessary for ensuring that client privacy leaks do not occur.  Both of these considerations are covered in I-D.ietf-privacypass- architecture. </del>  2.

There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)

The Privacy Pass protocol provides a privacy-preserving authorization mechanism.  In essence, the protocol allows clients to provide cryptographic tokens that prove nothing other than that they have  <ins> been created by a given server in the past ARCHITECTURE. </ins> This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA.  <ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks. This information is covered in ARCHITECTURE. </ins> 2.


blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document I-D.ietf-privacypass-architecture. </del>  Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This

blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the  <ins> Architecture document ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This


initially issued. At a high level, the Privacy Pass architecture consists of two <del> protocols: issuance and redemption.  The issuance protocol runs between an endpoint referred to as a Client and two functions in the Privacy Pass architecture: Attestation and Issuance.  These two network functions can be implemented by the same protocol participant, but can also be implemented separately.  The entity that implements Issuance, referred to as the Issuer, is responsible for issuing tokens in response to requests from Clients.  The entity that implements Attestation, referred to as the Attester, is responsible for attesting to properties about the Client for which tokens are issued.  The Issuer needs to be trusted by the server that later redeems the token.  Attestation can be performed by the Issuer or by an Attester that is trusted by the Issuer.  Clients might prefer to select different Attesters, separate from the Issuer, to be able to use preferred authentication methods or to improve privacy by not directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance protocol, in the original Privacy Pass protocol PPEXT, tokens were only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact. The redemption protocol runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </del>  authorization.  Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained <del> token or invokes the issuance protocol to acquire one for authorization. The issuance and redemption protocols operate in concert as shown in the figure below. </del>  This document describes requirements for both issuance and redemption <del> protocols.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. The privacypass working group is working on AUTHSCHEME as an instantiation of a redemption protocol and ISSUANCE as an instantiation of the issuance protocol. </del>  2.

In this image: ! It isn't very clear where messages originate and who gets to see them. In particular, it isn't clear where the TokenRequest originates (the Client) and whether the Attester gets to see it (¯(°_o)/¯).
That's a fair point. It should be clear that the TokenRequest comes from the Attester. I wonder if we also somehow need to illustrate that there's a trust relationship between the Attester and Issuer here. Something to at least imply that the Attester is either implicitly trusted to do attestation, or, perhaps in future versions of Privacy Pass, attestation proofs are sent directly to the Issuer.
Move diagram to section 3 (architecture). Also move much of the second intro paragraph down. Add more text about the actual steps to section 3, such as a numbered list
In here, introduce the basic privacy premise for how the redemption and issuance contexts are separated
The architecture references [AUTHSCHEME] for key concepts far more than I expected. For instance: Or: Can the architecture define the messages in their own right, then point to [AUTHSCHEME] for example implementations?
Is the suggestion here to describe -- conceptually -- what Token and TokenChallenges are in the architecture document? If so, that seems quite reasonable.
Yeah. An architecture is most useful if you don't have to dig into the details to understand it and those references are somewhat critical to comprehension.

initially issued. At a high level, the Privacy Pass architecture consists of two  <ins> protocols: issuance and redemption.  The redemption protocol AUTHSCHEME runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </ins> authorization.  Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained  <ins> token or invokes an issuance protocol, such as ISSUANCE, to acquire a token to present as authorization. </ins> This document describes requirements for both issuance and redemption  <ins> protocols and how they interact.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. </ins> 2.


Attester: An entity that attests to properties of Client for the purposes of token issuance.  3. The Privacy Pass architecture consists of four logical entities - <del> Client, Origin, Issuer, and Attester - that work in concert as shown in introduction for token issuance and redemption.  This section describes the purpose of token issuance and redemption and the requirements therein on the relevant participants. </del>  3.1.

Attester: An entity that attests to properties of Client for the purposes of token issuance. <ins> Redemption context: The interactions and set of information shared between the Client and Origin. Issuance context: The interactions and set of information shared between the Client, Attester, and Issuer. Attestation context: The interactions and set of information shared between the Client and Attester only, for the purposes of attesting the vailidity of the Client. </ins> 3. The Privacy Pass architecture consists of four logical entities -  <ins> Client, Origin, Issuer, and Attester - that work in concert as for token issuance and redemption.  This section describes the purpose of token issuance and redemption and the requirements on the relevant participants. The typical interaction flow for Privacy Pass tokens uses the following steps: A Client interacts with an Origin by sending an HTTP request.  The Origin sends an HTTP response that contains a token challenge that indicates a specific Issuer to use.  Note that the request might be made as part of accessing a resource normally, or with the specific intent of triggering a token challenge. If the Client already has a token available that satisfies the token challenge, it can skip to step 6 and redeem its token. Otherwise, it invokes the issuance protocol to request a token from the designated Issuer. The first step in the issuance protocol is attestation. Specifically, the Attester performs attestation checks on the Client.  These checks could be proof of solving a CAPTCHA, device trust, hardware attestation, etc (see attester). If attestation succeeds, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the details of Attestation, the Client can send the Token Request to the Attester alongside any attestation information.  If attestation fails, the Client receives an error and issuance aborts without a token. The Issuer generates a Token Response based on the Token Request, which is returned to the Client (generally via the Attester). Upon receiving the Token Response, the Client computes a token from the token challenge and Token Response.  This token can be validated by anyone with the per-Issuer key, but cannot be linked to the content of the Token Request or Token Response. If the Client has a token, it includes it in a subsequent HTTP request to the Origin, as authorization.  This token is sent only once.  The Origin validates that the token was generated by the expected Issuer and has not already been redeemed for the corresponding token challenge.  If the Client does not have a token, perhaps because issuance failed, the client does not reply to the Origin's challenge with a new request. </ins> 3.1.


identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See <del> attester-role for more details. </del>  3.2.1.

identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See  <ins> attester for more details. </ins> 3.2.1.


timestamp of the event, Client visible information (including the IP address), and the Origin name. <del> The challenge controls the type of token that the Origin will accept for the given resource.  As described in AUTHSCHEME, there are a number of ways in which the token may vary, including: </del>  Issuance protocol.  The token identifies the type of issuance protocol required for producing the token.  Different issuance

Is really true? A challenge is just a declaration from the Origin about what the Client should offer. It exerts no control. I would have thought that the arrangement is thus: The Origin determines what sorts of token are acceptable, including whether a token is necessary. This might incorporate any contextual information and so could change between different Clients or over time. A valid token includes information that an Origin can use to validate it against its policies. This includes all the stuff in the list that follows the quoted text (issuance protocol, issuer, redemption context, origin). Importantly, it does not carry information that directly identifies the Client to any entity other than the Origin; this being the primary privacy benefit to Clients. If the Origin determines that a token is necessary it can issue a challenge to the Client. This challenge might imply that a token that meets these constraints would be acceptable, but see the first point (i.e., the Origin can change its mind). There should be enough information in the challenge for the Client to obtain a token under reasonable assumptions (the Client understands the request and meets the requirements for token issuance). Clients can pre-emptively request token issuance. This might be based on a previous indication that this might work. (I see some caching in the trust tokens API.)
I'm probably missing the confusion that led to this issue. The arrangement you describe is true, and in that arrangement the only tokens that will be accepted for an Origin are those which verify with a valid challenge. That means the challenge determines how the client produces a valid token. For example, the challenge indicates the token type and therefore the issuance protocol required to produce a token. It also indicates a redemption context and therefore whether or not clients can preemptively request and cache tokens to amortize the cost of issuance. I don't think a challenge is just a declaration of what the Client should offer. To me, challenges fundamentally determine the set of possible tokens that clients can produce, and that implies some level of control. If "control" is somehow problematic or confusing, perhaps we just phrase this differently. That might be "The challenge determines the set of tokens the Origin will accept for the given resource. This is because tokens cryptographically bind the challenge to a client-chosen nonce."
As far as I can tell, yes, challenges do constrain what a client can produce in that in order to produce some tokens you need a challenge. However, the text here might be read to imply that it constrains the server in terms of what it might accept in the future. So yeah, using "control" is problematic as it too directly implies a link between the signal and the server actions that follow. I would have said that maybe "A challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept (in this context)."
That works for me! I'll send a PR.

timestamp of the event, Client visible information (including the IP address), and the Origin name.  <ins> The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept (in this context).  As described in AUTHSCHEME, there are a number of ways in which the token may vary, including: </ins> Issuance protocol.  The token identifies the type of issuance protocol required for producing the token.  Different issuance