Restful Attested Resources arm
Adrian.Shaw@arm.com
arm
Hannes.Tschofenig@arm.com
arm
Sergei.Trofimov@arm.com
arm
Simon.Frost@arm.com
arm
Thomas.Fossati@arm.com
Security RATS Internet-Draft This memo describes a REST interface based on the RATS architecture that can be used to retrieve attested system state, for example the reading of a security critical sensor. The objective is to present a common vocabulary of data formats and basic protocol transactions that can be pieced together into a cohesive interface that is capable of serving different attestation workflows.
Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at . Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 December 2020.
Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
  • .  Introduction
    • .  Use Cases
    • .  Document Organisation
    • .  Conventions used in this document
  • .  Abstract Mechanism
    • .  Attester Interface
      • .  Resource Validation
    • .  Verifier Interface
      • .  Attestation Result Validation
    • .  Example Compositions
      • .  Background Check with Nonce-based Freshness
      • .  Background Check with Timestamp-based Freshness
      • .  Passport with Timestamp-based Freshness
      • .  Timestamp-based Uni-directional
  • .  REST Instantiation
    • .  Basic Data Formats
      • .  Resource
      • .  Nonce
      • .  Timestamp
      • .  Evidence
      • .  Attestation Result
    • .  Request and Response Payloads
      • .  Requesting an Attested Resource
      • .  Attested Resource
      • .  Request for Attestation Result
      • .  Verifier Response
    • .  Interaction Model
      • .  Channel Security Considerations
      • .  URLs
      • .  Methods
      • .  Multicast Support
      • .  Examples
  • .  Discovery
    • .  Resource Directory
      • .  Attested Resource Registration
      • .  Verifier Resource Registration
  • .  IANA Considerations
  • .  Privacy Considerations
  • .  Security Considerations
    • .  Model Architecture for the Origin
  • Acknowledgments
  • References
    • Normative References
    • Informative References
  • Authors' Addresses
Introduction This memo describes a REST interface based on the RATS architecture that can be used to retrieve attested system state, for example the reading of a security critical sensor. We present a simple vocabulary of data formats and basic protocol transactions that can be pieced together into a cohesive interface capable of serving different attestation workflows. At a minimum, we want to cater for the "background check" and "passport" topological models, and for freshness of attestation based on nonces as well as timestamps. The obvious advantage of sharing a uniform interface across different actors is it creates an ecosystem in which variability is minimised and so is the need to add complex and often fragile logics into the deployed components, e.g., data format and protocol translation. Besides, using the familiar REST toolbox provides additional benefits in terms of developer friendliness as well as code base and infrastructure reuse (e.g., web caching).
Use Cases The primary use case is that of a device that needs to provide application state to third parties with strong authenticity. This is a common situation in critical infrastructure systems where an actuator device needs some assurance that the sensing equipment is in pristine state before acting on its signals. Here, the sensor would expose its safety critical samples via an attested resource whose authenticity can be verified by the actuator. Another potential application is a fleet controller that needs to know the current state of its dependent devices to inform its next actions (e.g., scheduling a firmware update campaign). Here, the dependent devices uniformly expose the same resource (e.g., the list of currently installed software components) to the controller, which can decide, based on the information provided, which devices need a certain security patch. Many more use cases exist.
Document Organisation The remainder of this document describes:
  • An abstract protocol that allows a device to expose arbitrary attested system state, which can be consumed by third parties ();
  • An instantiation of said abstract protocol as a set of uniform data formats and interaction primitives based on the REST paradigm for both HTTP and CoAP ();
  • A way to advertise and discover said capability ().
Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Abstract Mechanism The protocol principals are the three RATS actors: the attester (A), the relying party (RP) and the verifier (V). It is assumed that A either directly owns a resource, r, or has a direct trust relationship with the resource owner. In the following, n and t are freshness indicators: n is an initiator provided nonce, t is a timestamp sourced by the responder. When using timestamp based freshness, producers' and consumers' clocks MUST be synchronised.
Attester Interface The interface to the Attester is illustrated in . X is any entity interacting with the Attester, typically a Relying Party, which wants to retrieve an attested resource. A function E(n_X, r, t_A) is used by A to compute an evidence report binding the device status to the resource (r) together with the freshness indicators n_X and t_A. Typically, only one of n_X or t_A will be present. E() outputs an EAT token , E, carrying a nonce claim that is used as described in the following. The binding between n_X, t_A and r is obtained by hashing their concatenation, H(n_X || r || t_A), and storing the result in the nonce claim which is then cryptographically signed by the Attester as part of the produced evidence, E. The presence of any freshness indicator (i.e., n_X or t_A) is optional. For the purpose of computing E, a nil freshness indicator is replaced by the zero-length string, "". If t_A != nil, then its value needs to be sent back to the requester as an additional explicit protocol entity. Optionally, an attestation result R computed on evidence E MAY be returned by an Attester that acts as a forwarder for a Verifier.
Attester Interface n l X X r n , n = n i r ( , , ( , A l = ) A _ l ) _ X i _ A E t _ E , t R n = i | | r, t_A=nil, E(n_X, r, t_A), R(E)=nil | |<--------------------------------------o | | ]]>
Resource Validation Given an Appraisal Policy for Evidence APE and an Appraisal Policy for Attestation Result APR, X accepts r if and only if:
  • E | APE => true
  • E.nonce == H(n_X || r || t_A)
If R(E)!=nil, two further conditions MUST hold:
  • R(E) | APR => true
  • R.nonce == H("" || E || "")
Note that not all the appraisal operations are computed directly by X. For example, E | APE is typically delegated to a trusted Verifier.
Verifier Interface The interface to the Verifier is illustrated in . Y is any entity interacting with the Verifier, e.g., a Relying Party or an Attester, which supplies an evidence and receives an attestation result. The function R(n_Y, E, t_V) is used by V to compute the attestation result over E using an implicit Appraisal Policy for Evidence APE. The result is cryptographically signed by V and bound to any available freshness indicator. R() outputs an EAT token , R, carrying at a minimum:
  • a result claim carrying a boolean value that reflects the validity of the submitted evidence given the Appraisal Policy for Evidence used by the Verifier;
  • a nonce claim that is used as described in the following.
The token MAY contain further information associated with the evidence validation process. The binding between n_Y, t_V and E is obtained by hashing their concatenation, H(n_Y || E || t_V), and storing the result in the nonce claim which is then cryptographically signed by the Verifier as part of the produced attestation result, R. The presence of any freshness indicator (i.e., n_Y or t_V) is optional. For the purpose of computing R, a nil freshness indicator is replaced by the zero-length string, "".
Verifier Interface , , , = i , _ _ l _ V E Y n _ E l V ( n V Y n t = n ) R i Y t | | t_V=nil, R(n_Y, E, t_V) | |<-----------------------------o | | ]]>
Attestation Result Validation Given an Appraisal Policy for Attestation Result APR, Y accepts R if and only if:
  • R(E) | APR => true
  • R.nonce == H(n_Y || E || t_V)
Example Compositions
Background Check with Nonce-based Freshness
Background Check with Nonce-based Freshness P _ E , n ) i l r n , R E X , l ) n i X , ( n ( l V _ r i , A R n E | | | | E | | o----------------------------->| | | R(nil, E, nil) | | |<-----------------------------o | | | ]]>
RP accepts r if and only if:
  • E | APE => true
  • E.nonce == H(n_X || r || "")
  • R | APR => true, or equivalently R.result == true
  • R.nonce == H("" || E || "")
Background Check with Timestamp-based Freshness
Background Check with Timestamp-based Freshness , R i ( l , n l _ E ( i E i , i l n n , n ) , A ) A t R E A P , l r _ V r t | | | | E | | o----------------------------->| | | R(nil, E, nil) | | |<-----------------------------o | | | ]]>
RP accepts r if and only if:
  • R | APR => true, or equivalently R.result == true
  • R.nonce == H("" || E || "")
  • E | APE => true
  • E.nonce == H("" || r || t_A)
Passport with Timestamp-based Freshness The idea is that whenever the state of r changes, the Attester will "self-issue" an evidence for the changed resource using a locally sourced timestamp (t_A) as the freshness indicator.
Passport with Timestamp-based Freshness , r ( l ) i _ , E t R _ t E , n _ A A i r r n , P l A , , A i , R ( n n E i t E A V l ) i R ( i _ ( l , , n E l , n i ) t r , l l n , ) , o--. | | r, t_A, E(nil, r, t_A) |<-' | V | E | o------------------------------------------------------------>| | R(nil, E, nil) | |<------------------------------------------------------------o | | | RP | nil | |<-----------------------------o | r, t_A, E(nil, r, t_A), | | R(nil, E, nil) | o----------------------------->| ]]>
RP accepts r if and only if:
  • R | APR => true
  • R.nonce == H("" || E || "")
  • E.nonce == H("" || r || t_A)
Timestamp-based Uni-directional If the transport allows it, timestamp-based uni-directional attestation protocols, e.g., TUDA , can also be constructed from the presented primitives. For example, using CoAP Observe the interaction pattern in , with an initial trigger and subsequent automatic updates on resource status change, can be naturally implemented.
Timestamp-based Uni-directional A ( n [ A i 1 ( n A ) l A . , n , ] n l r t _ . E _ A A E A [ _ , t r R r i ( _ , E i ] _ , t , , n i r P r _ ) , _ t t _ ) . . i _ 1 . t n l , i , . , _ _ , _ r l | | | | [...] | | | | r_i, t_A, E(nil, r_i, t_A) | o----------------------------->| | | | [...] | | | | r_n, t_A, E(nil, r_n, t_A) | o----------------------------->| ]]>
REST Instantiation Four new MIME types are defined for the requests and responses among the three actors that have been identified in the abstract mechanism. The MIME types are composed of the basic data types defined in .
Basic Data Formats
  • The resource to be attested;
  • A caller provided nonce;
  • A locally sourced timestamp;
  • The evidence produced by the Attester, and
  • The attestation result produced by the Verifier.
These basic types are described by the following CDDL rules, which reuse the eat-token definition from .
Resource An "ANY DEFINED BY"-like payload with type set to the original MIME type, either Content-Type (HTTP) or Content-Format (CoAP), of the resource representation.
Nonce
Timestamp
Evidence An EAT token signed by the attester bound to the relying party request and the attested resource state.
Attestation Result An EAT token signed by the verifier and bound to an evidence.
Request and Response Payloads
Requesting an Attested Resource MIME type application/rats-attested-resource-request CoAP Content-Format: TBD-rats-attested-resource-request-CT nonce-type, } ]]> This type is used in a POST request to an attested resource.
Attested Resource MIME type application/rats-attested-resource CoAP Content-Format: TBD-rats-attested-resource-CT resource-type, ? t-A-key => timestamp-type, evidence-key => evidence-type, ? attestation-result-key => attestation-result-type, } ]]> This type is used in a successful response to a request to an attested resource endpoint. Note that an attestation result is only present when the Passport model is used. Note also that the fact that the inner resource representation is embedded within the application/rats-attested-resource envelope suppresses the ability to do content negotiation on it, i.e., the inner representation format is unilaterally chosen by the origin.
Request for Attestation Result MIME type application/rats-attestation-result-request CoAP Content-Format: TBD-rats-attestation-result-request-CT nonce-type, evidence-key => evidence-type, } ]]> This type is used in a POST request to a verifier endpoint.
Verifier Response MIME type application/rats-attestation-result-response CoAP Content-Format: TBD-rats-attestation-result-response-CT timestamp-type, attestation-result-key => attestation-result-type, } ]]> This type is used in a successful response to a POST request to a verifier endpoint.
Interaction Model (For now) we only describe a synchronous, RPC-like transaction model, including the slight variant with a one-off trigger presented in . This might be not suited for devices that sit behind a NAT/firewall box, or those that have to go through extended sleep cycles in order to save energy. For this kind of devices, we assume in-network support in the form of store-and-forward nodes (e.g., LwM2M queue mode, specialised border routers, etc.).
Channel Security Considerations Unless the channel can be considered free from passive and active attackers at all times, all transactions are to be carried over a secure transport (i.e., HTTPS or COAPS).
URLs In the spirit of , no specific URL format is mandated. An application is free to specify the URL scheme of its liking for the exposed attested resources. When an origin exposes the same underlying state both as nonce- and timestamp-based resources, these are identified by two separate URIs. The verifier function is exposed via an URI that accepts evidence in form of application/rats-attestation-result-request typed requests and returns attestation results in form of application/rats-attestation-result-response typed responses.
Methods As per usual REST conventions, the guiding principles are:
  • POST is used for all requests involving a payload;
  • GET is used for requests without a payload.
The only example of the latter is when retrieving an "Attested Resource" using the timestamp-based freshness model. Any other request uses POST.
Response Codes and Caching The possible status codes are:
  • HTTP
    • 200 (OK) for successful GET. This response is cacheable; origins can use Cache-Control (max-age) and ETag headers in order to instruct on-path caches.
    • 201 (Created) for a successful POST. This response is not cacheable.
  • CoAP
    • 2.05 (Content) for successful GET. This response is cacheable; origins can use Max-Age and ETag Options to instruct on-path caches;
    • 2.01 (Created) for successful POST. This response is not cacheable.
Otherwise, a suitable error response (i.e., HTTP 4xx/5xx, CoAP 4.nn/5.nn) is returned.
Multicast Support TODO (This is a CoAP only feature.)
Examples A few examples are given to illustrate the different interaction models using both CoAP and HTTP transports.
Background Check with Nonce Based Freshness
  • RP - Attester (CoAP)
> Request: POST coap://device.example/my-attested-resource Content-Format: TBD-application/rats-attested-resource-request-CT Accept: application/rats-attested-resource Payload: { "n_X": "bm9uY2Uh" } << Response: 2.01 Created ETag: "xyzzy" Content-format: TBD-application/rats-attested-resource-CT Payload: { "r" : { "typ": "text/plain", "val": "foobar" }, "E": "eyJhbGciO...RfrKmTWk" } ]]>
  • RP - Verifier (HTTP)
> Request: POST /my-verify Host: verifier.example Content-Type: application/rats-attestation-result-request Accept: application/rats-attestation-result-response { "E": "eyJhbGciO...RfrKmTWk" } << Response: HTTP/1.1 201 Created ETag: "abccb" Content-format: application/rats-attestation-result-response Payload: { "R": "eyJhbGciO...8j5EDGYc" } ]]>
Background Check with Timestamp Based Freshness
  • RP - Attester (CoAP) with POST
> Request: POST coap://device.example/my-attested-resource Content-Format: TBD-application/rats-attested-resource-request-CT Accept: TBD-application/rats-attested-resource-CT Payload: { } << Response: 2.01 Created ETag: "xyzzy" Content-format: TBD-application/rats-attested-resource-CT Payload: { "r" : { "typ": "text/plain", "val": "foobar" }, "t_A": "2020-04-01T21:02:31Z", "E": "eyJhbGciO...z0ikw9Aa" } ]]>
  • RP - Attester (CoAP) with GET
> Request: GET coap://device.example/my-attested-resource Accept: TBD-application/rats-attested-resource-CT << Response: 2.05 Content ETag: "xyzzy" Max-Age: 3600 Content-format: TBD-application/rats-attested-resource-CT Payload: { "r" : { "typ": "text/plain", "val": "foobar" }, "t_A": "2020-04-01T21:02:31Z", "E": "eyJhbGciO...z0ikw9Aa" } ]]>
  • RP - Verifier (HTTP) is the same as .
Passport Model
  • Attester - Verifier (CoAP)
> Request: POST coap://verifier.example/my-verify Content-Format: application/rats-attestation-result-request Accept: application/rats-attestation-result-response Payload: { "E": "eyJhbGciO...RfrKmTWk" } << Response: 2.01 Created ETag: "jkllk" Content-format: application/rats-attestation-result-response Payload: { "R": "eyJhbGciO...Z0IKW9aA" } ]]>
  • Relying Party - Attester (CoAP) with POST
> Request: POST coap://device.example/my-attested-resource Content-Format: TBD-application/rats-attested-resource-request-CT Accept: TBD-application/rats-attested-resource-CT Payload: { } << Response: 2.01 Created ETag: "qwerty" Content-format: TBD-application/rats-attested-resource-CT Payload: { "r": { "type": "text/plain", "val": "foobar" }, "t_A": "2020-04-01T21:02:31Z", "E": "eyJhbGciO...RfrKmTWk", "R": "eyJhbGciO...Z0IKW9aA" } ]]>
  • Relying Party - Attester (CoAP) with GET
> Request: GET coap://device.example/my-attested-resource Accept: TBD-application/rats-attested-resource-CT << Response: 2.05 Content ETag: "qwerty" Max-Age: 3600 Content-format: TBD-application/rats-attested-resource-CT Payload: { "r": { "type": "text/plain", "val": "foobar" }, "t_A": "2020-04-01T21:02:31Z", "E": "eyJhbGciO...RfrKmTWk", "R": "eyJhbGciO...Z0IKW9aA" } ]]>
Discovery
Resource Directory The following describes the new link format attribute values needed for registering attested resources as well as verification endpoints to a Resource Directory . The same attribute values can be used by RD clients to discover attestation related resources.
Attested Resource Registration An attested resource is registered with:
  • an interface description (if=) with value rats.if.timestamp or rats.if.nonce depending on the supported freshness model, which determines the access method (i.e., POST+nonce vs GET);
  • a content format (ct=) with value "TBD-application/rats-attested-resource-CT";
  • an inner content format (ict=) that reflects the type field of the returned resource;
  • a resource type (rt=) that reflects the nature of the inner resource.
If a resource has both a "plain" and an "attested" variant, then the link value corresponding to the "attested" resource can be associated to its "plain" twin by means of the link relationship attested-variant. TBD: Should we have rats.if.timestamp variants for GET and POST? Alternative includes: 1) let the client probe and server return 405/4.05 if the requested variant is not supported; 2) add another attribute that explicitly states which request methods are supported.
Examples The following example shows a registrant endpoint with the name "node1" registering an attested heart rate sensor resource to an RD. The location /rd is an example RD location discovered in a previous .well-known/core query. > Request: POST /rd?ep=node1 HTTP/1.1 Host: rd.example Content-Type: application/link-format ; if="rats.if.timestamp"; rt="heart-rate-zoladz"; ct=TBD-application/rats-attested-resource-CT; ict=0 << Response: HTTP/1.1 201 Created Location: /rd/4520 ]]> The following example shows a registrant endpoint with the name "node1" registering a temperature sensor resource along with its attested twin to an RD. The attested-variant link relation establishes the semantics of the link between /sensors/temp and /sensors/attested-temp: the latter being an attested version of the former. Note, in particular, that the resource type (rt=) of the linked resource is inherited by the attested twin. Missing an explicit inner content format (ict=) the content type of the inner resource representation can be assumed to be that of the linked resource. The interface description (if=) rats.if.nonce says that the access to the attested resource happens by supplying a nonce through a POST. > Request: POST /rd?ep=node1 HTTP/1.1 Host: rd.example Content-Type: application/link-format ; ct=41; rt="temperature-c"; if="sensor", ; anchor="/sensors/temp"; rel="attested-variant"; if="rats.if.nonce"; ct=TBD-application/rats-attested-resource-CT; ict=41 << Response: HTTP/1.1 201 Created Location: /rd/4521 ]]>
Verifier Resource Registration A Verifier resource is registered with:
  • An rt with value rats.verifier;
  • A ct with value TBD-application/rats-attestation-result-response-CT
Examples > Request: POST /rd?ep=node1 HTTP/1.1 Host: rd.example Content-Type: application/link-format ; ct=application/rats-attestation-result-response; rt="rats.verifier" << Response: HTTP/1.1 201 Created Location: /rd/4522 ]]>
IANA Considerations TODO
Privacy Considerations TODO
Security Considerations
Model Architecture for the Origin The model architecture for the origin of the attested resource is illustrated in . The REST client (an user agent of a relying party or verifier) interfaces directly with a REST front-end (a CoAP or HTTP server stack) running in the Rich Execution Environment (REE), for example a Linux operating system. The REST front-end is paired with a back-end Trusted Application (TA) running in the Trusted Execution Environment (TEE). The TA has exclusive control over some "resource" (e.g., a sensor that feeds back into some kind of critical infrastructure control system) and can talk to the attestation service hosted inside the TEE to request EAT tokens. In this model, it is critical that the attestation service can only be used by the intended TA or, failing that, that the identity of the calling TA can be securely proved to the relying party or verifier. An example of the latter is the Client ID claim used in PSA attestation .
Model Security Architecture e i r - n n E T r c E T e s c o R E b n E v o a k e l e E T c f T a E S n o A t s S c r d - t a R e n i t i t e t R d e s r u t e | REST |<--->| back-end +->|resource| | | client | | | front-end | | | TA | '------' | '--------' | '-----------' | '-----+----' | | | | | | | v | | | .-------------. | | | | attestation | | | | | service | | | | '-------------' | '-----------------'---------------------------' ]]>
Acknowledgments TBD
References Normative References CoRE Resource Directory In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. Work in Progress Remote Attestation Procedures Architecture In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence. The evidence is typically a set of claims about its software and hardware platform. This document describes an architecture for such remote attestation procedures (RATS). Work in Progress The Entity Attestation Token (EAT) An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device. These claims are used by a relying party to determine how much it wishes to trust the entity. An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT. Contributing TBD Work in Progress Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. URI Design and Ownership Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. Observing Resources in the Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Architectural Styles and the Design of Network-based Software Architectures University of California, Irvine Time-Based Uni-Directional Attestation This documents defines the method and bindings used to conduct Time- based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) Principals over the Internet. TUDA does not require a challenge-response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester. As a prerequisite for TUDA, every RATS Principal requires access to a trusted and synchronized time-source. Per default, in TUDA this is a Time Stamp Authority (TSA) issuing signed Time Stamp Tokens (TST). Work in Progress Arm's Platform Security Architecture (PSA) Attestation Token The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. At its core, the CWT (COSE Web Token) format is used and populated with a set of claims in a way similar to EAT (Entity Attestation Token). This specification describes what claims are used by PSA compliant systems. Work in Progress
Authors' Addresses arm
Adrian.Shaw@arm.com
arm
Hannes.Tschofenig@arm.com
arm
Sergei.Trofimov@arm.com
arm
Simon.Frost@arm.com
arm
Thomas.Fossati@arm.com