]> Arm

paul.howard@arm.com

Linaro

Thomas.Fossati@linaro.org

Fraunhofer SIT

henk.birkholz@ietf.contact

Fujitsu

Shefali.Kamal@fujitsu.com

AMD

gmandyam@amd.com

Alibaba Cloud

xynnn@linux.alibaba.com

Security Remote ATtestation ProcedureS RATS attestation endorsement reference value In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Remote Attestation Procedures (RATS) enable Relying Parties to evaluate the trustworthiness of remote Attesters by appraising Evidence. This appraisal necessitates access to Endorsements and Reference Values, which are often distributed across multiple providers, including hardware manufacturers, firmware developers, and software vendors. The lack of standardized methods for querying and retrieving these artifacts poses challenges in achieving seamless interoperability. The Concise Selector for Endorsements and Reference Values (CoSERV) addresses this challenge by defining a query language and a corresponding result structure for the transaction of artifacts between a provider and a consumer. The query language format provides Verifiers with a standard way to specify a set of relevant artifacts, such that they can be obtained from Endorsers and Reference Value Providers. Queries can be based on characteristics of the Attester's environment. This includes composite Attesters, where those environments become the basis for obtaining topological information, such as composition or trust dependency details. Alternatively, queries can be based on the precise identifiers of one or more Reference Integrity Manifest (RIM) documents. In turn, the result format allows those Endorsers and Reference Value Providers to package the selected artifacts within a standard structure. This facilitates the efficient discovery and retrieval of relevant Endorsements and Reference Values from providers, maximising the re-use of common software tools and libraries within the transactions. The CoSERV query language is intended to form the input data type for tools and services that provide access to Endorsements and Reference Values. The CoSERV result set is intended to form the corresponding output data type from those tools and services. The environment characteristics of Endorsements and Reference Values are derived from the equivalent concepts in CoRIM . CoSERV therefore borrows heavily from CoRIM, and shares some data types for its fields. And, like CoRIM, the CoSERV schema is defined using CDDL . A CoSERV query can be serialized in CBOR format. In addition to the CBOR-based data formats for CoSERV queries and responses, this specification also defines API bindings and behaviours for the exchange of CoSERV queries and responses. This is to facilitate standard interactions between CoSERV producers and consumers. Standard API endpoints and behaviours will encourage the growth of interoperable software tools and modules, not only for parsing and emitting CoSERV-compliant data, but also for implementing the clients and services that need to exchange such data when acting in the capacity of the relevant RATS roles. This will be of greater benefit to the software ecosystem than the CoSERV data format alone. See for the API binding specifications.

Terminology and Requirements Language 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. This document uses terms and concepts defined by the RATS architecture. For a complete glossary, see . This document uses terms and concepts defined by the CoRIM specification. For a complete glossary, see . This document uses the terms "actual state" and "reference state" as defined in . The terminology from CBOR , CDDL and COSE applies; in particular, CBOR diagnostic notation is defined in and . Terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.

Aggregation and Trust Models The roles of Endorser or Reference Value Provider might sometimes be fulfilled by aggregators, which collect from multiple supply chain sources, or even from other aggregators, in order to project a holistic view of the endorsed system. The notion of such an aggregator is not explicit in the RATS architecture. In practice, however, supply chains are complex and multi-layered. Supply chain sources can include silicon manufacturers, device manufacturers, firmware houses, system integrators, service providers and more. In practical terms, an Attester is likely to be a complex entity, formed of components from across such supply chains. Evidence would be likewise structured, with contributions from different segments of the Attester's overall anatomy. A Verifier for such Evidence may find it convenient to contact an aggregator as a single source of truth for Endorsements and Reference Values. An aggregator would have intelligence about the Attester's complete anatomy and supply chain. It would have the ability to contact all contributing supply chain actors for their individual Endorsements and Reference Values, before collecting them into a cohesive set, and delivering them to the Verifier as a single, ergonomic package. The contributing supply chain actors might themselves be CoSERV-enabled, in which case the aggregator would send one or more separate CoSERV queries to those actors as part of the aggregation process. Alternatively, it might be necessary to use vendor-specific protocols to gather these artifacts and convert them into the aggregated CoSERV response. The choice between these approaches is deployment-dependent, and is considered to be an implementation detail of the aggregator. In pure RATS terms, an aggregator is still an Endorser or a Reference Value Provider - or, more likely, both. It is not a distinct role, and so there is no distinctly-modeled conveyance between an aggregator and a Verifier. However, when consuming from an aggregator, the Verifier may need visibility of the aggregation process, possibly to the extent of needing to audit the results by inspecting the individual inputs that came from the original supply chain actors. CoSERV addresses this need, catering equally for both aggregating and non-aggregating supply chain sources. To support deployments with aggregators, CoSERV allows for flexible trust models as follows.

• Shallow Trust: in this model, the consumer trusts the aggregator, solely and completely, to provide authentic descriptions of the endorsed system. The consumer does not need to audit the results of the aggregation process. The term "shallow" is used here to indicate the number of supply chain links that are traversed by the consumer. When trust in the aggregator is absolute, only one link needs to be traversed, from the consumer to the aggregator, because the aggregator is the sole authority.
• Deep Trust: in this model, the consumer has a trust relationship with the aggregator, but does not deem this to be sufficient. The consumer can still use the collected results from the aggregation process, where it is convenient to do so, but also needs to audit those results. The term "deep" is used to indicate that the consumer needs to traverse more supply chain links in order to gain an adequate level of trust, because trust in the aggregator is only partial. It means that the consumer has to reach more "deeply" into the supply chain sources, compared with the shallow model.

Any given CoSERV transaction can operate according to either model. The consumer decides which model to use when it forms a query. The CoSERV result payload can convey both the aggregated result and the audit trail as needed. The payload size may be smaller when the shallow model is used, but the choice between the two models is a question for implementations and deployments. Although CoSERV is designed to support aggregation, it is not a requirement. When aggregation is not used, CoSERV still fulfills the need for a standard conveyance mechanism between Verifiers and Endorsers or Reference Value Providers.

CoSERV Information Model

Overview CoSERV is designed to facilitate query-response transactions between a producer and a consumer. In the RATS model, the producer is either an Endorser or a Reference Value Provider, and the consumer is a Verifier. CoSERV defines a single top-level data type that can be used for both queries and result sets. Queries are authored by the consumer (Verifier), while result sets are authored by the producer (Endorser or Reference Value Provider) in response to the query. A CoSERV data object always contains a query. When CoSERV is used to express a result set, the query is retained alongside the result set that was yielded by that query. This allows consumers to verify a match between the query that was sent to the producer, and the query that was subsequently returned with the result set. Such verification is useful because it mitigates security threats arising from any untrusted infrastructure or intermediaries that might reside between the producer and the consumer. An example of this is caching in HTTP and CoAP . It might be expensive to compute the result set for a query, which would make caching desirable. However, if caching is managed by an untrusted intermediary, then there is a risk that such an untrusted intermediary might return incorrect results, either accidentally or maliciously. Pairing the original query with each result set provides an end-to-end contract between the consumer and producer, mitigating such risks. The transactional pattern between the producer and the consumer would be that the consumer begins the transaction by authoring a query and sending it to the producer as a CoSERV object. The producer receives the query, computes results, and returns a new CoSERV object formed from the results along with the original query. Notionally, the producer is "adding" the results to the query before sending it back to the consumer.

Artifacts Artifacts are what the consumer (Verifier) needs in order to verify and appraise Evidence from the Attester, and therefore they form the bulk of the response payload in a CoSERV transaction. The common CoSERV query language recognises the following four artifact types:

• Trust Anchor: A trust anchor is as defined in . An example of a trust anchor would be the public part of the asymmetric signing key that is used by the Attester to sign Evidence, such that the Verifier can verify the cryptographic signature. This is just one example. Other forms of trust anchor are possible. CoSERV does not place any additional requirements or constraints on the conveyance or use of trust anchors, beyond what is already described in and . sets out the applicable patterns for the endorsement of verification keys, all of which apply equally here.
• Endorsed Value: An endorsed value is as defined in . This represents a characteristic of the Attester that is not directly presented in the Evidence, such as certification data related to a hardware or firmware module.
• Reference Value: A reference value is as defined in . A reference value specifies an individual aspect of the Attester's desired state. Reference values are sometimes informally called "golden values". An example of a reference value would be the expected hash or checksum of a binary firmware or software image running in the Attester's environment. Evidence from the Attester would then include claims about the Attester's actual state, which the Verifier can then compare with the reference values at Evidence appraisal time.
• Domain: A domain is defined in as a hierarchical description of a Composite Attester in terms of its constituent environments and their compositional relationships. Domain artifacts in CoSERV are represented by CoMID Domain Membership Triples and Trust Dependency Triples (see ). These triples allow a Verifier to obtain authoritative information about the internal arrangement of the composite Attester and the trust dependencies between its constituent domains.

When artifacts are produced by an aggregator (see ), the following additional classifications apply:

• Collected Artifacts: these refer to artifacts that were derived by the aggregator by collecting and presenting data from original supply chain sources, or from other aggregators. Collected artifacts form a single holistic package, and provide the most ergonomic consumption experience for the Verifier.
• Source Artifacts: these refer to artifacts that were obtained directly from the original supply chain sources, and used as inputs into the aggregation process, allowing the aggregator to derive the collected artifacts.

In the shallow trust model of aggregation, only the collected artifacts are used by the consumer. In the deep trust model, both the collected artifacts and the source artifacts are used. The source artifacts allow the consumer to audit the collected artifacts and operate the trust-but-verify principle.

Environments Some CoSERV queries use environments as the basis for artifact selection. An environment defines the scope (or scopes) in which the endorsement artifacts are applicable. Given that the consumer of these artifacts is likely to be a Verifier in the RATS model, the typical interpretation of the environment would be that of an Attester that either has produced evidence, or is expected to produce evidence, that the Verifier needs to appraise. The Verifier consequently needs to query the Endorser or Reference Value Provider for artifacts that are applicable in that environment. For CoSERV queries that are based on environments, there are three mutually-exclusive methods for defining those environments. Exactly one of these three methods MUST be used for the query to be valid. All three methods correspond to environments that are also defined within CoRIM .

• Class: A class is an environment that is expected to be common to a group of similarly-constructed Attesters, who might therefore share the same set of endorsed characteristics. An example of this might be a fleet of computing devices of the same model and manufacturer.
• Instance: An instance is an environment that is unique to an individual and identifiable Attester, such as a single computing device or component.
• Group: A group is a collection of common Attester instances that are collected together based on some defined semantics. For example, Attesters may be put into groups for the purpose of anonymity.

Stateful Environments In addition to specifying the Attester environment by class, instance, or group, it is sometimes necessary to constrain the target environment further by specifying aspects of its state. This is because the applicability of Endorsements and Reference Values might vary, depending on these stateful properties. Consider, for example, an Attester instance who signs Evidence using a derived attestation key, where the derivation algorithm is dependent on one or more aspects of the Attester's current state, such as the version number of an upgradable firmware component. This example Attester would, at different points in its lifecycle, sign Evidence with different attestation keys, since the keys would change upon any firmware update. To provide the correct public key to use as the trust anchor for verification, the Endorser would need to know the configured state of the Attester at the time the Evidence was produced. Specifying such an Attester solely by its instance identifier is therefore insufficient for the Endorser to supply the correct artifact. The environment specification would need to include these critical stateful aspects as well. In CoRIM , stateful environments are modeled as an environment identifier plus a collection of measurements, and CoSERV takes the same approach. Therefore, any environment selector in a CoSERV query can optionally be enhanced with a collection of one or more measurements, which specify aspects of the target environment state that might materially impact the selection of artifacts.

Environment Uniqueness Because CoSERV is a query language, the CoSERV environment structure has been designed such that it is well suited to forming queries. It has been optimized such that the most common query styles are also the simplest to construct. For the case of environment-based queries, this design makes it very straightforward to query for artifacts by (multiples of) instance, group or class. It is not possible to query by combinations of these properties at the same time. For example, it is not possible to form a query that selects by instance or group, while simultaneously being constrained by the scope of a specific class. As a more precise example, it would not be possible to form a single query that selects artifacts for instance "0x010203040506", but only for devices of class "ACME SiliconPro 2000". This is a departure from CoRIM environments, which can optionally be modeled as combinations of instance, group or class. This design choice is a pragmatic one that is taken by CoSERV, but it does raise some deployment considerations in terms of environment uniqueness. In many deployments, it is expected that the identifiers used for instances and groups would be highly entropic and either universally unique, or at least unique within the scope of any given CoSERV provider/consumer pair, such that material ambiguities would not arise. Identifiers of type uuid or ueid, for example, are typical. However, some profiles might define their identifier types such that uniqueness is not guaranteed. Care is therefore needed when using CoSERV with such profiles. Where globally unique identifiers are not guaranteed, a CoSERV provider SHOULD be scoped such that any identifier used in a query remains unambiguous within that provider. For example, a provider might be scoped to a single product family (effectively constraining the class). This preserves the simplicity of the CoSERV environment model while avoiding ambiguity in practice.

Environments as Domains defines a domain identifier as being syntactically equivalent to an environment, even though a domain's semantics are richer than that of a simple Attester environment. Since the identifiers are syntactically the same, a CoSERV query structure that is based on environments can be used, nearly as-is, to identify a domain: by instance, group, or class of the domain identifier, subject to the same restrictions as any other environment-based query ().

Queries The purpose of a query is to allow the consumer (Verifier) to specify the artifacts that it needs. CoSERV offers a small but versatile query language. The following styles of query are available:

• Queries by Environment: This query style is used to select the artifacts that are applicable to the Attester's environment. For the case of composite Attesters, these artifacts can include domain composition and dependency information. See .
• Queries by RIM Identifier: This query style is used to select artifacts that are Reference Integrity Manifest (RIM) artifacts, and where the consumer already knows the precise identifiers of the specific RIMs that it needs.

Further details are given in the sections below.

Queries by Environment When a CoSERV query is specified using an environment, the following information is conveyed in the query:

• A specification of the required artifact type: Reference Value, Endorsed Value, Trust Anchor or Domain. See for definitions of artifact types. A single CoSERV query can only specify a single artifact type.
• A specification of the target environment. For Reference Value, Endorsed Value and Trust Anchor queries, this is the Attester environment. For Domain queries, this is the domain whose membership and dependency triples are being requested. Environments can be selected according to Attester instance, group or class. Additional properties of the environment state can be specified by adding one or more measurements to the selector. See for full definitions. To facilitate efficient transactions, a single query can specify either multiple instances, multiple groups or multiple classes. However, it is not possible to mix instance-based selectors, group-based selectors and class-based selectors in a single query.
• A switch to select the desired supply chain depth. A CoSERV query can request collected artifacts, source artifacts, or both. This switch is especially relevant when the CoSERV query is fulfilled by an aggregator. The collected artifacts are intended for convenient consumption (according to the shallow trust model), while the source artifacts are principally useful for auditing (according to the deep trust model). It is possible for a query to select for source artifacts only, without the collected artifacts. This might happen when the consumer needs to inspect or audit artifacts from across the deep supply chain, while not requiring the convenience of the aggregated view. It could also happen when the consumer is acting as an intermediate broker, gathering artifacts for delivery to another aggregator. See for details on aggregation, auditing and trust models.

Queries by RIM Identifier Reference Integrity Manifests (RIMs) are a common type of artifact format for representing Endorsements and Reference Values. RATS defines the CoRIM format for the encoding of RIMs (see ). CoSERV supports a query style that allows individual RIMs to be obtained based on their identifiers. This is a more direct style of query, compared with the query by environment. It is applicable in cases where the consumer is already aware of the precise set of RIMs that it needs. There is no environment matching performed in this case, nor is there any aggregation. The shallow and deep trust models are therefore not applicable for this style of query, and there is no distinction between source and collected artifacts. The producer is expected to do nothing more than look up the identified documents and return them directly in the result set. The query contains one or more identifiers for RIM documents, or for tags contained in RIM documents. RIM identifiers of the following types are permitted:

• CoRIM identifiers ()
• CoMID tag identifiers ()
• CoSWID tag identifiers ()

All three of these identifier types are required to be globally unique as per their corresponding specifications. A single query may contain identifiers of different types.

Avoidance of Volatile Data in Queries CoSERV queries do not contain timestamps or any similarly volatile or unpredictable fields. This is to ensure that any set of materially-identical queries will always yield the same encoded sequence of CBOR bytes, regardless of the time when they were issued, or of other volatile factors. Along with the other encoding rules set out in , it means that a query can be used as a stable and canonical identifier of artifacts. This property of queries is an important enabler of efficient CoSERV transactions. See, for example, the HTTP caching design described in .

Query Logging A CoSERV implementation MAY log the time at which a query was received and fulfilled. This might sometimes be desirable for transparency or audit purposes. Implementations are free to define their own transparency events, which can then include timestamps or other suitable information.

Query Combinations It is not always possible for a CoSERV consumer (such as a Verifier) to obtain all required artifacts from a single query. This is partly due to constraints of the query model itself. For example, in the case of environment-based queries, it is not possible to combine different artifact types in a single query, making it likely that a sequence of queries would be needed for different artifacts in realistic scenarios. Another related example is when using environments to query domains for their composition and dependency information. Domains are hierarchical, making traversal of the hierarchy a prerequisite step, before obtaining appraisal artifacts for their member environments. The expected interaction pattern is that the consumer would first issue a query for the domain artifacts (memberships and dependencies), and then follow this with one or more queries to obtain appraisal artifacts for specific environments within the domain hierarchy. For this interaction pattern to be efficient, CoSERV providers MUST return the entire trust dependency and domain membership subtree rooted in the queried environment, rather than just the immediate children, when domain artifacts are requested. This will reduce the burden on the client to traverse the hierarchy in multiple steps. Such server-side traversal of the hierarchy is necessarily limited to those compositional relationships of which the server is aware, based on what has been ingested into its available data stores at the time of the query.

Result Sets The result set contains the artifacts that the producer collected in response to the query. Result sets always include a timestamp indicating the expiry time of the entire result set. Consumers MUST NOT consider any part of the result set to be valid after this expiry time. The remaining information contained in the result set depends on the style of query that was used: either a query by environment, or a query by RIM identifier.

Results for Queries by Environment For queries by environment, the top-level structure of the result set contains the following two items in addition to the expiry timestamp:

• A collection of one or more result entries. This will be a collection of either reference values, endorsed values, trust anchors or domain definitions. See for definitions of artifact types. Artifact types are never mixed in any single CoSERV result set. The artifacts in the result collection therefore MUST match the single artifact type specified in the original CoSERV query.
• A collection of the original source materials from which the producer derived the correct artifacts to include in the result set. These source materials are optional, and their intended purpose is auditing. They are included only when requested by the original CoSERV query. Source materials would typically be requested in cases where the consumer is not willing to place sole trust in the producer, and therefore needs an audit trail to enable additional verifications.

Each individual result entry combines a CoMID triple with an authority delegation chain. CoMID triples are exactly as defined in . For Reference Value, Endorsed Value and Trust Anchor results, each CoMID triple demonstrates the association between an environment matching that of the CoSERV query and a single appraisal artifact. For Domain results, the result entries contain CoMID Domain Membership Triples and Trust Dependency Triples. The membership triples describe the member domains that compose the queried domain. The dependency triples describe trust dependencies between domains. The authority delegation chain is composed of one or more authority delegates. Each authority delegate is represented by a public key or key identifier, which the consumer can check against its own set of trusted authorities. The authority delegation chain serves to establish the provenance of the result entry, and enables the Verifier to evaluate the trustworthiness of the associated artifact. The purpose of the authority delegation chain is to allow CoSERV responses to support decentralized trust models, where Verifiers may apply their own policy to determine which authorities are acceptable for different classes of artifact. Because each result entry combines a CoMID triple with an authority delegation chain, the entries are consequently known as quadruples (or "quads" for short).

Results for Queries by RIM Identifier Queries by RIM identifier are significantly simpler than queries by environment, and the result set structure is likewise simpler. There are no authority delegation chains or "quads" in the result. The result does not contain any extracted or aggregated information. Instead, it is composed of entire RIM documents, obtained and passed through verbatim from their original supply chain sources. The result is a flat map structure, keyed by the RIM identifier. Each key in the map MUST correspond to one of the RIM identifiers in the original query. Each mapped value is the corresponding RIM data object, contained within a Conceptual Message Wrapper (CMW) as per . The permitted RIM content for each map entry depends upon the type of key used in the query. When the key is a CoRIM identifier, the RIM content MUST be the CoRIM data object whose identity matches the key. When the key is a CoMID tag identifier, the RIM content MUST be a CoRIM data object, which contains the CoMID tag whose identity matches the key. The CoRIM data object may also contain other CoMID (or CoSWID) tags with different identifiers, even if those identifiers were not included in the query. When the key is a CoSWID tag identifier, the RIM content MUST be one of the following:

• The CoSWID data object whose identity matches the key.
• A CoRIM data object, which contains the CoSWID tag whose identity matches the key. The CoRIM data object may also contain other CoSWID (or CoMID) tags with different identifiers, even if those identifiers were not included in the query.

The recipient of the query MAY return only a subset of the RIMs that were requested, if it is not able to satisfy the entire query. An empty set is also a valid result in the worst case. For CoMID and CoSWID tag identifiers, the producer may be in possession of multiple revisions of the RIM tag with that identity. In such cases, the producer MUST populate the result set with the newest available revision only. The "newest" revision is defined as the one with the highest integer version counter in the relevant tag's identity map. See and for additional details of tag versioning. It is possible for multiple keys in the result set to map to the same data object. For example, if a query selects for two CoMID identifiers, CoMID-A and CoMID-B, and the producer has a single CoRIM containing both of those CoMID tags, then the producer MAY populate the result set with entries for both CoMID-A and CoMID-B, where both entries map to identical copies of the single containing CoRIM. The producer SHOULD ensure that all RIMs in the result set are signed. In cases where the producer is returning copies of RIMs from upstream supply chain actors on a pass-through basis, the producer SHOULD preserve the original signatures from those supply chain actors, as opposed to re-constructing and re-signing the RIMs.

RIM Validity and Results Expiry Signed RIMs usually have an explicit validity period. For example, signed CoRIMs include validity information in the protected header map (see ). RIM validity information can take the form of CWT claims (nbf, not before time, and exp, expiration time) or use the CoRIM validity map. Whatever method is used to define the validity period:

1. The CoSERV query result MUST NOT expire after the end of the validity period but may expire before the end of the validity period.
2. The RIM MUST NOT be included in the CoSERV result if it is outside of its validity period.

CoSERV Data Model This section specifies the CBOR data model for CoSERV queries and result sets. CDDL is used to express rules and constraints of the data model for CBOR. These rules must be strictly followed when creating or validating CoSERV data objects. The top-level CoSERV data structure is given by the following CDDL: profile &(query: 1) => query ? &(results: 2) => results } profile = comid.oid-type / ~uri ]]>

Common Data Types CoSERV inherits the following types from the CoRIM data model class-map, $class-id-type-choice, $instance-id-type-choice and $group-id-type-choice. The collated CDDL is in .

Profile In common with EAT and CoRIM, CoSERV supports the notion of profiles. As with EAT and CoRIM, profiles are a way to extend or specialize the structure of a generic CoSERV query in order to cater for a specific use case or environment. In a CoSERV query, the profile can be identified by either a Uniform Resource Identifier (URI) or an Object Identifier (OID). This convention is identical to how EAT profiles are identified using the eat_profile claim as described in .

Query Structure The CoSERV query language enables Verifiers to specify the desired characteristics of Endorsements and Reference Values based on the environment in which they are applicable. The top-level structure of a CoSERV query is given by the following CDDL: artifact-type &(environment-selector: 1) => environment-selector-map &(result-type: 2) => result-type ) rim-query = ( &(rim-selector: 3) => [ + rim-selector-id ] ) rim-selector-id = [ &(comid: 0), comid.$tag-id-type-choice ] / [ &(coswid: 1), coswid.tag-id ] / [ &(corim: 2), corim.$corim-id-type-choice ] artifact-type = &(endorsed-values: 0) / &(trust-anchors: 1) / &(reference-values: 2) / &(domains: 3) result-type = &(collected-artifacts: 0) / &(source-artifacts: 1) / &(both: 2) ]]> At top level, the query is partitioned into mutually-exclusive variants for the different query styles: queries by environment, or queries by RIM identifier. See for details about the query styles and how they are used. The meanings of the query fields are detailed in the following subsections for each supported style.

Queries by Environment

Artifact Type For queries by environment, the artifact-type field is the foremost discriminator of the query. It is an artifact category selector. Its four permissible values are trust-anchors (codepoint 1), endorsed-values (codepoint 0), reference-values (codepoint 2), and domains (codepoint 3). See for full definitions of artifact types. It is expected that implementations might choose to store these different categories of artifacts in different top-level stores or database tables. Where this is the case, the artifact-type field serves to narrow the query down to the correct store or table. Even where this is not the case, the discriminator is useful as a filter for the consumer, resulting in an efficiency gain by avoiding the transfer of unwanted data items.

Environment Selector For queries by environment, the environment selector forms the main body of the query, and its CDDL is given below: [ + stateful-class ] ) stateful-instance = [ instance: comid.$instance-id-type-choice ? measurements: [ + comid.measurement-map ] ] selector //= ( &(instance: 1) => [ + stateful-instance ] ) stateful-group = [ group: comid.$group-id-type-choice ? measurements: [ + comid.measurement-map ] ] selector //= ( &(group: 2) => [ + stateful-group ] ) ]]> Environments can be specified according to instance, group or class. See for details. Although these three environment definitions are mutually-exclusive in a CoSERV query, all three support multiple entries. This is to gain efficiency by allowing the consumer (Verifier) to query for multiple artifacts in a single transaction. For example, where artifacts are being indexed by instance, it would be possible to specify an arbitrary number of instances in a single query, and therefore obtain the artifacts for all of them in a single transaction. Likewise for classes and groups. However, it would not be possible for a single query to specify more than one kind of environment. For example, it would not be possible to query for both class-level and instance-level artifacts in a single CoSERV transaction. All three environment selector types can optionally be enhanced with one or more measurement-map entries, which are used to express aspects of the environment state. See for a description of stateful environments.

Selector Semantics When multiple environment selectors are present in a single query, such as multiple instances or multiple groups, the recipient of the query MUST consider these to be alternatives, and hence use a logical OR operation when applying the query to its internal data stores. Below is an illustrative example of how a CoSERV query for endorsed values, selecting for multiple Attester instances, might be transformed into a semantically-equivalent SQL database query: The same applies for class-based selectors; however, since class selectors are themselves composed of multiple inner fields, the recipient of the query MUST use a logical AND operation in consideration of the inner fields for each class. Also, for class-based selectors, any unset fields in the class are assumed to be wildcard (*), and therefore match any value. Below is an illustrative example of how a CoSERV query for reference values, selecting for multiple Attester classes, might be transformed into a semantically-equivalent SQL database query:

Result Type For queries by environment, the result-type field selects for the desired type(s) of results: collected-artifacts (codepoint 0), source-artifacts (codepoint 1) or both (codepoint 2). See for definitions of source and collected artifacts.

Queries by RIM Identifier

RIM Selector The rim-selector (codepoint 3) is the only data field in this style of query. It contains a set of one or more RIM identifiers. RIMs can be selected by an arbitrary mixture of CoRIM, CoMID or CoSWID identifiers, as explained in .

Result Set Structure The result set structure is given by the following CDDL: tdate ; RFC3339 date } environment-result = ( ; result-type: collected-artifacts result-set // ; result-type: source-artifacts &(source-artifacts: 11) => [ + cmw.cbor-record ] // ; result-type: both ( result-set &(source-artifacts: 11) => [ + cmw.cbor-record ] ) ) rim-result = ( &(rims: 5) => cmw.cbor-collection ) result-set //= reference-values result-set //= endorsed-values result-set //= trust-anchors result-set //= domains refval-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(rv-triple: 2) => comid.reference-triple-record } reference-values = ( &(rvq: 0) => [ * refval-quad ] ) endval-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(ev-triple: 2) => comid.endorsed-triple-record } cond-endval-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(ce-triple: 2) => comid.conditional-endorsement-triple-record } endorsed-values = ( &(evq: 1) => [ * endval-quad ] &(ceq: 2) => [ * cond-endval-quad ] ) ak-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(ak-triple: 2) => comid.attest-key-triple-record } cots-stmt = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(cots: 2) => cots } trust-anchors = ( &(akq: 3) => [ * ak-quad ] &(tas: 4) => [ * cots-stmt ] ) membership-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(membership-triple: 2) => comid.domain-membership-triple-record } dependency-quad = { &(authorities: 1) => [ + comid.$crypto-key-type-choice ] &(dependency-triple: 2) => comid.domain-dependency-triple-record } domains = ( &(membership: 5) => [ * membership-quad ] &(dependency: 6) => [ * dependency-quad ] ) ; ; import CoTS ; cots = "TODO COTS" ]]> Result sets are described in . As with the query data model, the result set is partitioned into mutually-exclusive variants for the different query styles: queries by environment, or queries by RIM identifier. The environment-result and rim-result types provide the separate data models for each style respectively. Only the expiry field (codepoint 10) is common to both styles.

Encoding Requirements Implementations may wish to use serialized CoSERV queries as canonical identifiers for artifact collections. For example, a Reference Value Provider service may wish the cache the results of a CoSERV query to gain efficiency when responding to a future identical query. For these use cases to be effective, it is essential that any given CoSERV query is always serialized to the same fixed sequence of CBOR bytes. Therefore, CoSERV queries MUST always use CBOR deterministic encoding as specified in . Further, CoSERV queries MUST use CBOR definite-length encoding.

Cryptographic Binding Between Query and Result Set CoSERV is designed to ensure that any result set passed from a producer to a consumer is precisely the result set that corresponds to the consumer's original query. This is the reason why the original query is always included along with the result set in the data model. However, this measure is only sufficient in cases where the conveyance protocol guarantees that CoSERV result sets are always transacted over a secure channel without any untrusted intermediaries. Wherever this is not the case, producers MUST create an additional cryptographic binding between the query and the result. This is achieved by transacting the result set within a cryptographic envelope, with a signature added by the producer, which is verified by the consumer. A CoSERV data object can be signed using COSE . A signed-coserv is a COSE_Sign1 with the following layout: The payload MUST be the CBOR-encoded CoSERV. The protected header MUST include the signature algorithm identifier. The protected header MUST include either the content type application/coserv+cbor or the CoAP Content-Format TBD1. Other header parameters MAY be added to the header buckets, for example a kid that identifies the signing key.

Examples

Query Data Examples This section provides some illustrative examples of valid CoSERV query objects. The following example shows an environment-based query for Reference Values scoped by a single class. The artifact-type is set to 2 (reference-values), indicating a query for Reference Values. The profile is given the example value of tag:example.com,2025:cc-platform#1.0.0. Finally, the environment-selector uses the key 0 to select for class, and the value contains a single entry with illustrative settings for the identifier, vendor and model. The next example is similar, but adds a second entry to the set of classes in the environment-map, showing how multiple classes can be queried at the same time. The following example shows a query for Reference Values scoped by instance. Again, the artifact-type is set to 2, and profile is given a demonstration value. The environment-selector now uses the key 1 to select for instances, and the value contains two entries with example instance identifiers. The next example shows a query for Domain information, scoped by class. The artifact-type in this case is set to 3, which indicates a query for domain membership and dependency information. The query structure is otherwise the same as for other environment-based query examples. This next example shows how a query can be based on one or more RIM identifiers, instead of environments. In this case, the query is requesting three specific CoRIMs.

Result Data Examples This section provides some illustrative examples of valid CoSERV queries with their corresponding result sets. In this next example, the query is a reference value query based on class. The top-level structure is a map with three entries: profile (codepoint 0), query (codepoint 1) and results (codepoint 2). The profile and query structures are the same as in the previous examples. The result structure is a map with two entries: expiry (codepoint 10) and rvq (codepoint 0). The rvq (reference value quad) entry comprises the asserting authority and the asserted triples. A single reference-value triple is shown in this example. Its environment-map, as expected, is the same as the environment-map that was supplied in the query. The rest of the structure is the measurement-map as defined in CoRIM . The following example is for a query that requested the results be provided in the "source artifacts" format. This means one or more original signed manifests containing information that satisfies the query criteria. Compared with the previous example, the rvq entry is empty, while the source-artifacts (codepoint 11) contain two CMW records , each of which contains a (made up) manifest with the type "application/vnd.example.refvals". The following example shows a result set for a Domain query. The query identifies a domain using an environment selector based on class. The result contains a membership collection and a dependency collection. The membership collection contains one Domain Membership Quad, which combines an authority delegation chain with a CoMID Domain Membership Triple. The dependency collection is present but empty, indicating that no matching Trust Dependency Triples are included in this result set. This next example shows how a query can be based on one or more RIM identifiers, instead of environments. In this case, the query is requesting three specific CoRIMs. The corresponding result set consequently has three entries. Each key in the result map corresponds to one of the RIM identifiers that was specified in the query. For brevity, the actual RIM content is represented here simply as an array of a single byte. In real-world situations, these arrays would contain complete CMW encodings as described in .

API Bindings This section sets out the ways in which CoSERV queries and responses can be exchanged between software components and services using APIs. The CoSERV data format itself is agnostic of any particular API model or transport. The API bindings provided here are intended to complement the data format. They will allow implementations to build the complete functionality of a CoSERV producer or consumer, in a way that is well-suited to any transport or interaction model that is needed. It is intended that these API definitions carry minimal additional semantics, since these are largely the preserve of the CoSERV query language itself. The API definitions are merely vehicles for the exchange of CoSERV queries and responses. Their purpose is to facilitate standard interactions that make the most effective use of available transports and protocols. The only API binding that is specified in this document is a request-response protocol that uses HTTP for transport. This is a simple pattern, and likely to be a commonly occurring one for a variety of use cases. Future specifications may define other API bindings. Such future bindings may introduce further HTTP-based protocols. Alternatively, they may define protocols for use with other transports, such as CoAP .

Request Response over HTTP This section defines and mandates the API endpoint behaviours for CoSERV request-response transactions over HTTP. Implementations MUST provide all parts of the API as specified in this section. The API is a simple protocol for the execution of CoSERV queries. It takes a single CoSERV query as input, and produces a corresponding single CoSERV result set as the output. It is a RESTful API because the CoSERV query serves as a unique and stable identifier of the target resource, where that resource is the set of artifacts being selected for by the query. The encoding rules for CoSERV are deterministic as set out in . This means that any given CoSERV query will always encode to the same sequence of bytes. The Base64Url encoding () of the byte sequence becomes the rightmost path segment of the URI used to identify the target resource. The GET method is then used with this URI to execute the query. Further details are provided in the subsections below. Authentication is out of scope for this document. Implementations MAY authenticate clients, for example for authorization or for preventing denial of service attacks.

Errors When returning error responses (4xx or 5xx status codes), CoSERV origin servers MUST set the Content-Type header field to application/concise-problem-details+cbor, and the content MUST be a Concise Problem Details object containing the following:

title:

A human-readable string that identifies the error that prevented the CoSERV Service from processing the request. This string should be short and suitable for inclusion in log messages.

detail:

A human-readable string that describes the error in more depth. This should ideally provide sufficient detail to enable the error to be rectified.

As specified by , the title and detail values use oltext, which is either an unadorned CBOR text string (text) or a language-tagged text string (tag38). When a language needs to be identified explicitly, tag38 carries a BCP 47 language tag as described in . If no explicit or implicit language context is available, unadorned text is interpreted with the language tag en. CoSERV's HTTP binding is not a CoAP API, but Constrained Problem Details objects provide a useful encoding for problem details and avoid the need to mix CBOR and JSON in resource or client implementations. Per the guidance in , the specific HTTP status codes shown in the examples throughout this document are illustrative. Status codes can be generated by generic HTTP components (caches, intermediaries, captive portals, gateways, etc.) that are not part of the CoSERV server, and the set of registered HTTP status codes can be extended over time. Clients MUST therefore be prepared to handle any HTTP status code by falling back to the generic class semantics (1xx, 2xx, 3xx, 4xx, or 5xx) of the response when a more specific code is not recognized, and MUST rely on the Concise Problem Details object (when present) rather than the status code alone to determine the application-level cause of an error. Clients handle 5xx responses as defined in and .

Discovery Clients discover CoSERV HTTP API endpoints by means of a well-known URI that is formed using the /.well-known/ path prefix as defined in . This URI supplies a single discovery document that clients can use to locate the URIs of other API endpoints, in addition to finding out other relevant information about the configuration and capabilities of the service. Implementations that provide CoSERV HTTP API endpoints MUST also provide the discovery endpoint at the path /.well-known/coserv-configuration. This endpoint MUST be accessible via GET with no additional query parameters. The response content can be formatted using either JSON or CBOR, governed by standard HTTP content negotiation (). The media types defined for this purpose are application/coserv-discovery+json (for JSON-formatted documents) or application/coserv-discovery+cbor (for CBOR-formatted documents). If the client presents one of the two valid media types, then the implementation MUST respond with the HTTP 200 (OK) status code, unless it is prevented from doing so by an error condition beyond the scope of this specification. When the 200 (OK) status code is returned, the response MUST contain exactly one discovery document in the requested format (JSON or CBOR). Server implementations MUST support both formats. In deployments where the discovery document might be stored in an HTTP cache, server implementations SHOULD add the Vary: Accept header to the HTTP response to ensure that the client does not receive a cached document in the wrong format. The contents of the discovery document MUST conform to the CDDL data model given below, which is common to both the JSON and CBOR encodings. version, capabilities-label => [ + capability ], api-endpoints-label => { + tstr => tstr }, ? result-verification-key-label => eat.JC } version-label = eat.JC<"version", 1> capabilities-label = eat.JC<"capabilities", 2> api-endpoints-label = eat.JC<"api-endpoints", 3> result-verification-key-label = eat.JC<"result-verification-key", 4> version = tstr capability = { media-type-label => cmw.media-type, artifact-support-label => artifact-support } media-type-label = eat.JC<"media-type", 1> artifact-support-label = eat.JC<"artifact-support", 2> non-empty-array = (M) .and ([ + any ]) artifact-support = non-empty-array<[ ? "source", ? "collected", ? "rims" ]> ]]>

Discovery Document Contents This section defines how to populate and interpret the data fields in the discovery document. The collated CDDL is in .

Version The version field is denoted by the label "version" in JSON documents and by the codepoint 1 in CBOR documents. It is a Semantic Versioning (semver) string, which denotes the version and patch level of the service that is providing the API endpoints described by the document. The semver string MUST conform to the ABNF defined in . Version numbers and patch levels are otherwise implementation-defined.

Capabilities The capabilities field is denoted by the label "capabilities" in JSON documents and by the codepoint 2 in CBOR documents. This field allows clients to discover the profiled variants of CoSERV for which the service implementation can satisfy queries and provide artifacts. This field is structured as an array, which allows for service implementations that support more than one profile. Each supported profile is indicated according to its parameterized media type, along with the categories of artifact that can be provided for the profile. The permitted artifact categories are "source", "collected" and "rims". The two categories "source" and "collected" refer specifically to the results of queries that are based on environments. The presence of either or both of these two categories in the array indicates that the service implementation supports environment-based queries, as described in . The difference between source and collected artifacts is explained in . The category "rims" refers to the results of queries that are based on RIM identifiers. The presence of this category indicates that the service implementation supports identifier-based queries, as described in . Each profile is paired with a non-empty set of artifact categories, allowing the service implementation to indicate the ways in which it can satisfy queries. This pairing caters for situations where the service implementation might support different combinations of artifact category for different profiles. The capability advertisement does not enumerate the individual artifact types that are available in response to environment-based queries. A service that advertises support for collected or source artifact results for a profile is indicating support for the environment-based query style for that profile. The availability of particular artifact types, such as Reference Values or Domains, can be determined only by executing a query, or by consulting profile-specific documentation.

API Endpoints The API endpoints field is denoted by the label "api-endpoints" in JSON documents and by the codepoint 3 in CBOR documents. This field allows clients to derive the correct URI for making HTTP API calls. The field is a map whose keys are the symbolic names of the APIs, and whose values are the URI path for the API endpoint. The symbolic name CoSERVRequestResponse is defined for services that offer the transactional API described in . Service implementations that offer this API MUST include a key with this name in the endpoints map field, and the corresponding endpoint URI path MUST end with /{query}. This allows the consumer to form a valid CoSERV query URI using variable expansion as per , replacing the {query} variable with the Base64Url-encoded CoSERV query object. There MUST NOT be any other variables that require substitution. The symbolic name CoSERVRequestResponseQUERY is defined for services that offer the transactional API using the QUERY method, as described in . The corresponding value is a plain URI path with no URI template: the query is carried in the request content, so there are no variables to substitute. Services that support the QUERY method MUST include a key with this name in the endpoints map field. Service implementations that include this key SHOULD also include CoSERVRequestResponse, since clients cannot always rely on QUERY being usable (see ). Responses from a CoSERVRequestResponseQUERY endpoint SHOULD include the Accept-Query header field () listing application/coserv+cbor. This allows a client to confirm that the endpoint, as reached through any infrastructure layers, accepts QUERY requests with that media type, independently of the discovery document.

Result Verification Key The result verification key is denoted by the label "result-verification-key" in JSON documents and by the codepoint 4 in CBOR documents. This field provides one or more public keys that can be used for the cryptographic verification of CoSERV query results that are returned by the service implementation. In JSON-formatted discovery documents, each key is a JSON Web Key (JWK) as defined in . In CBOR-formatted discovery documents, each key is a COSE Key as defined in . This field is optional. As described in , there are situations where it is permissible for CoSERV result sets to be unsigned, namely when they are transacted over an end-to-end secure channel without any untrusted intermediaries. CoSERV service implementations MAY publish discovery documents without result-verification keys in cases where they exclusively produce unsigned CoSERV result sets. Unsigned CoSERV result sets are characterized by use of the application/coserv+cbor media type (as opposed to the application/coserv+cose media type). The supported media types, along with their profile parameters, are published in the capabilities field of the discovery document. If all supported media types are variants of application/coserv+cbor, indicating unsigned results only, then there is no need for the verification key set to be included in the discovery document. If one or more of the supported media types are variants of application/coserv+cose, indicating signed results, then the verification key set MUST be included.

Discovery Document CBOR Encoding When the discovery document is encoded as CBOR, it is exempt from the encoding rules specified in . These encoding rules are designed to ensure that CoSERV queries can be used as canonical and stable identifiers. The discovery document is an independent structure, and not part of the CoSERV data model itself. Therefore, these encoding rules do not apply.

Discovery Document Examples The contents of the responses in the following examples are for illustrative purposes only. Example HTTP request for retrieving the discovery document in JSON format: Corresponding HTTP response: Example HTTP request for retrieving the discovery document in CBOR format: Corresponding HTTP response:

Execute Query This endpoint executes a single CoSERV query and returns a CoSERV result set. The HTTP method is GET. The URI path is formed of the discovered coserv endpoint (as set out in ), where the {query} template variable is substituted with the CoSERV query to be executed, which is represented as a Base64Url encoding of the query's serialized CBOR byte sequence. There are no additional URI query parameters. The serialized query is carried in the URI, so its size is bounded by the URI length limits of the HTTP infrastructure in use, which are often not known in advance. recommends that senders and recipients support URIs of at least 8000 octets. Typical CoSERV queries are small: the serialized examples in this document are in the order of 100 to 200 octets, which Base64Url encoding expands by about one third. A query that is too large for some component on the path can cause that component to return a 414 (URI Too Long) status code, which clients need to be prepared to handle. As an optional alternative to GET, an implementation MAY also accept CoSERV queries using the QUERY method, as described in . Clients MUST set the Accept header field to one of the profiled application/coserv+cose or application/coserv+cbor media types that is supported by the server according to the discovery document (see ). Endpoint implementations MUST respond with an HTTP status code and content according to one of the subheadings below, except where the response is generated by infrastructure layers other than the origin server.

Responses

Successful Transaction (200) This response indicates that the CoSERV query was executed successfully. Example HTTP request: Example HTTP response: >, / unprotected / {}, / payload / << { / profile / 0: "tag:example.com,2025:cc-platform#1.0.0", / query / 1: { / artifact-type / 0: 2, / reference-values / / environment-selector / 1: { / class / 0: [ [ { / class-id / 0: 560(h'00112233'), / tagged-bytes / / vendor / 1: "Example Vendor", / model / 2: "Example Model" } ] ] }, / result-type / 2: 0 / collected-artifacts / }, / results / 2: { / rvq / 0: [ { / authorities / 1: [ 560(h'abcdef') ], / reference-triple / 2: [ / environment-map / { / class / 0: { / class-id / 0: 560(h'00112233'), / vendor / 1: "Example Vendor", / model / 2: "Example Model" } }, [ / measurement-map / { / mval / 1: { / digests / 2: [ [ 1, h'aa' ], [ 2, h'bb' ] ], / name / 11: "Component A" } }, / measurement-map / { / mval / 1: { / digests / 2: [ [ 1, h'cc' ], [ 2, h'dd' ] ], / name / 11: "Component B" } } ] ] } ], / expiry / 10: 0("2030-12-13T18:30:02Z") } } >>, / signature / h'face5190' ]) ]]>

Invalid Query (400) This response indicates that the supplied CoSERV query is badly formed, or is otherwise un-processable by the server. Conditions resulting in this error include the following:

• The request is badly formed. This could mean that the query is not valid CBOR, or does not conform to the CoSERV data model specified in .
• The request is well-formed, but cannot be executed by the server. This could happen when the query goes beyond the advertised capabilities of the server according to the server's discovery document (see ). An example would be a query that uses the RIM Identifier query style, where the server supports only the Environment query style, or vice versa.

The following example shows a badly-formed request with its response: The following example shows a well-formed but un-processable request, with response:

Failure to Negotiate Profile (406) This response indicates that the client has specified a CoSERV profile that is not understood or serviceable by the server. Conformant clients will not encounter this error, since this specification constrains clients to request only those CoSERV profiles that are listed in the discovery document. Clients can consult the discovery document () to determine the supported media types. Example HTTP request: Example HTTP response:

Too Many Requests (429) A server (or infrastructure layer) could apply rate limiting to requests received from clients. If a client exceeds its request quota, it might receive a 429 (Too Many Requests) response, which can carry a Retry-After header field () indicating how long to wait before retrying. Rate limiting is often implemented in infrastructure layers (such as gateways or load balancers), whose error responses are not governed by this specification. Example HTTP messages are not shown for this case.

Execute Query with the QUERY Method The QUERY method is a safe, idempotent method that carries the query in the request content instead of the URI. This avoids the URI size limits and keeps the query out of URIs, which are more likely to be logged. Support for this method is optional, and clients MUST NOT assume it is available unless the discovery document advertises it (see ). The request is sent to the URI path given by the CoSERVRequestResponseQUERY key of the discovery document. The Content-Type header field MUST be application/coserv+cbor, and the content MUST be a CoSERV object with the results field absent, which is the serialized CBOR CoSERV query encoded as per . The profile media type parameter is optional in this context, since the profile is carried in the query itself. The content is not Base64Url-encoded. The Accept header field is set as for GET (). Successful and unsuccessful transactions use the same status codes and response contents as for GET. In addition, a server that does not support the media type of the request content responds with 415 (Unsupported Media Type) () and SHOULD include the Accept-Query header field in that response. Example HTTP request: The response to a QUERY request is cacheable as described in . The cache key incorporates the request content, so the considerations in apply equally.

Caching In practical usage, the artifacts transacted via CoSERV queries (such as trust anchors and reference values) may change significantly less often than they are used. For example, a Verifier needs to use the artifacts whenever it needs to verify or appraise Evidence from an Attester. This might be a very frequent operation, for which a low latency is desirable. By contrast, the artifacts themselves would vary only as a consequence of impactful changes to the Attester's desired state or environment. One example of such an impactful change might be the roll-out of a firmware update, which would result in a new reference value for the impacted firmware component(s). Such changes would tend to be relatively infrequent. The caching of CoSERV artifacts is therefore beneficial for overall system performance. CoSERV is designed to facilitate both client-side and server-side caching by use of the standard HTTP caching mechanisms specified in . This includes use of the Cache-Control header field and its associated directives. It also includes the use of entity-tags (ETags). The following features of CoSERV and its HTTP binding are specifically designed to favor caching implementations:

• CoSERV queries form stable URI paths. As specified in , any given CoSERV query will always serialize to the same fixed sequence of bytes. This allows queries to be used as canonical and stable resource identifiers, which in turn allows them to function effectively as cache keys. If a service can return more than one representation for the same query URI, depending on the Accept header field of the request (see ), the origin server MUST include Vary: Accept in its responses, so that caches do not serve a representation in a different format or profile from the one the client requested.
• The result set is cryptographically bound to the query. As specified in , the origin server is required to return a signed response that combines the result set with the client's original query, in any deployment where untrusted intermediaries might exist. This means that the client can always verify the integrity of the result on an end-to-end basis, even in the presence of caching infrastructure.
• Only safe HTTP methods are used. CoSERV queries are executed as read-only operations using HTTP GET. The execution of a query does not modify any state on the server, which creates more opportunities for the re-use of cached results.
• Discovery documents are cacheable resources. Discovery documents (as described in ) are used by clients to locate suitable API endpoints for transacting CoSERV queries. These documents, like CoSERV responses themselves, can be cached to avoid round trips to the origin server during this bootstrapping phase.

Although reusing cached responses is generally desirable, clients that need to bypass the caching infrastructure can do so by specifying Cache-Control: no-cache in their requests. Note that this only prevents a stored response from being used to satisfy the request: the response to such a request can still be stored by caches. Preventing storage is a matter for the origin server's Cache-Control response directives, as discussed in . Implementations should be aware that there are specific privacy considerations related to caching. These are outlined in .

HTTP Caching and Result Set Expiry CoSERV's data model includes a mandatory expiration timestamp on every result set. This is an authoritative marker of the point in time at which the entire result set becomes invalid, and the query must be re-executed to obtain fresh results. This timestamp is established by the origin server. In the presence of HTTP caching infrastructure, the origin server MUST NOT set HTTP cache directives (e.g. Cache-Control: max-age, Expires) such that the freshness lifetime of the HTTP response exceeds the result set expiry timestamp contained within the CoSERV results. To avoid the risk of infrastructure layers providing default cache lifetimes that are unsuitable for the returned content, origin servers SHOULD set Cache-Control headers explicitly in all CoSERV responses.

Weak Validators for Signed Responses For CoSERV origin servers that return signed responses (of type application/coserv+cose), attention should be paid to the generation of suitable ETag headers for cache validation. Any non-determinism in the signing process could give rise to sets of results that are semantically identical, but not byte-for-byte identical due to differences in the signature. Populating cache infrastructure with such spuriously-differing results would be undesirable. This problem can be addressed by the use of a weak validator, which computes the ETag in such a way that the signature and the result set expiry timestamp are excluded. The expiry timestamp changes whenever a result set is recomputed, even if the artifacts it carries are unchanged. Excluding the signature and the expiry timestamp allows semantically-identical result sets to validate successfully, even when they differ in these respects. Precise details of ETag generation are beyond the scope of this document, but a suitable validator might be one that combines the unsigned payload (minus the expiry timestamp) with the public key (or key identity) as input to a strong hash function. Such a validator would still behave correctly if the signing key were to be rotated, in which case it would not be appropriate to validate any results that were signed with the previous key. A 304 (Not Modified) response does not update the stored content, so it does not refresh the expiry timestamp embedded in the result set. A client whose stored result set has passed its embedded expiry therefore needs a full response, even if the HTTP cache considers the entry fresh or revalidated. Origin servers using this approach MUST label the ETag as weak (W/ prefix), as in the examples below, and MUST evaluate If-None-Match using the weak comparison function (). For unsigned responses, strong validators are preferred.

Example HTTP Messages with Caching This section illustrates a caching scenario. In this example, the CoSERV HTTP API server endpoint is hosted by an HTTP origin (coserv.example), while a reverse proxy (cache.example) operates a public cache in front of the origin. Client A sends a request using a specific CoSERV query. As the reverse proxy has a "cache miss" for the resource, it forwards the request to the origin. The origin then constructs the response and returns it to the proxy. The response includes cache-control headers that are compatible with the time-to-live associated with the computed result set. For the purposes of this example, the HTTP response max-age has been set to 10 minutes and the s-maxage to 1 hour. This means that the origin allows intermediaries (e.g., its CDN) to cache this resource for longer than the client. The result is different caching behaviours between clients and intermediaries, which reduces the load on the origin by enabling CDNs to cache content for longer, while ensuring that clients receive fresher content. Before forwarding it to the client, the proxy stores the response in its cache using the request URI as the cache key alongside the entry's time-to-live value. The proxy also inserts an Age header, with a value of zero, to signal that the response has been freshly computed by the origin server. | lookup(ogB4I3RhZ..) | | +---. | | | | | | |<--' | | | MISS | | | | | | GET ogB4I3RhZ.. | | +--------------------->| | | +---. compute | | | | result | | |<--' set | | 200 OK | (expiry = now + 1h, ETag = "xyz") | | C-C: max-age=600, | | | s-maxage=3600 | | | ETag: W/"xyz" | | | #6.18([...]) | | |<---------------------+ | | | | | store(K=ogB4I3RhZ.., | | | ETag="xyz", | | +---. V=#6.18([...], | | | | TTL=3600) | | |<--' | | 200 OK | | | C-C: max-age=600, | | | s-maxage=3600 | | | ETag: W/"xyz" | | | Age: 0 | | | #6.18([...]) | | |<---------------------+ | | | | ]]> At a later point, after 2 minutes, a different client B makes the same request. This time, the request generates a "cache hit" event on the proxy. The response is therefore served from the public cache, bypassing the origin. This reduces the load on the origin, where computing the result set is generally costly, as well as reducing the overall latency of the transaction. Once again, the cache inserts an Age header into the response, now set to 120 to reflect the two minutes of elapsed time since the response was added to the cache. Client B additionally operates a local cache, where it stores a copy of the response. Client B's local cache entry has a time-to-live (TTL) value of 480, which is computed from the max-age of the publicly-cached entry (600), minus the value in the Age header (120). | lookup(ogB4I3RhZ..) | | +---. | | | | | | |<--' | | | HIT | | 200 OK | | | C-C: max-age=600, | | | s-maxage=3600 | | | ETag: W/"xyz" | | | Age: 120 | | | #6.18([...]) | | |<---------------------+ | | | | | store(K=ogB4I3RhZ.., | | | ETag="xyz", | | +---. V=#6.18([...], | | | | TTL=480) | | |<--' | | | | | ]]> After 9 more minutes, B is instructed to make the same request again. The request generates a "cache hit" event on the local cache. However, the cached resource has become stale and needs to be revalidated. Therefore, B sends a conditional request to the proxy. The request generates a "cache hit" event on the proxy where the resource is still fresh due to the differential caching behaviour dictated by the original response from the origin. The cached response includes an Age header set to 660, reflecting the total 11 minutes of elapsed time since the proxy cache was populated. The proxy returns a 304 (Not modified) status code, which instructs the client to reuse its local copy of the response. | | | +---. | | | | | | |<--' | | | HIT | | 304 Not modified | | | C-C: max-age=600, | | | s-maxage=3600 | | | ETag: W/"xyz" | | | Age: 660 | | |<---------------------+ | | | | ]]>

Implementation Status [^rfced] please remove this section prior to publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Veraison Responsible Organisation: Veraison (open source project within the Confidential Computing Consortium). Location: https://github.com/veraison Description: Veraison provides components that can be used to build a Verifier, and also exemplifies adjacent RATS roles such as the Relying Party. There is an active effort to extend Veraison so that it can act in the capacity of an Endorser or Reference Value Provider, showing how CoSERV can be used as a query language for such services. This includes library code to assist with the creation, parsing and manipulation of CoSERV queries. Level of Maturity: This is a proof-of-concept prototype implementation. License: Apache-2.0. Coverage: This implementation covers all aspects of the CoSERV query language. Contact: Thomas Fossati, Thomas.Fossati@linaro.org

Operational Considerations

Redirects Redirects are handled as for any other HTTP resource (). A redirect can change other parts of the URI, such as the authority or the path prefix of the endpoint, but is not expected to alter the final path segment, which carries the query. Since the result set is bound to the query it answers (), consumers can detect a response that does not correspond to their query. No CoSERV-specific handling of redirects is needed beyond this.

Deployment of the QUERY Method The QUERY method is new, and support for it is still being rolled out. Servers, proxies, gateways, CDNs, and client libraries that predate it, or that have not enabled it, can reject QUERY requests (for example with 405 (Method Not Allowed), 501 (Not Implemented) or 400 (Bad Request)), drop them, or fail to cache the responses. A CoSERV origin server that supports QUERY is therefore not sufficient: every infrastructure layer between client and origin has to support it too. Clients thus need to establish that QUERY works on the path to the service before relying on it. Advertisement by the CoSERVRequestResponseQUERY entry of the discovery document () only reflects the origin server's capabilities. A client can additionally look for the Accept-Query header field in responses from the endpoint, and can fall back to GET () if the QUERY request fails in a way that indicates lack of support. A fallback to GET is not possible for a query that exceeds URI length limits, so services that expect large queries need to ensure that their infrastructure supports QUERY. Services that offer QUERY SHOULD continue to offer GET, so that clients unable to use QUERY can still interoperate.

Security Considerations CoSERV implements a conveyance protocol for specific categories of Conceptual Message in , namely Endorsements and Reference Values. Consequently, it is used only between the Endorser and Verifier roles, or between the Reference Value Provider and Verifier roles of the RATS architecture. The relevant security considerations are therefore the ones associated with those roles and their interactions. Certain security characteristics are desirable for interactions between the Verifier and the Endorser or Reference Value Provider. However, these characteristics would be the province of the specific implementations of these roles, and of the transport protocols in between them. They would not be the province of the CoSERV data object itself. Examples of such desirable characteristics might be:

• The Endorser or Reference Value Provider is available to the Verifier when needed.
• The Verifier is authorised to query data from the Endorser or Reference Value Provider.
• Queries cannot be intercepted or undetectably modified by an entity that is interposed between the Verifier and the Endorser or Reference Value Provider.

In Relation to CoRIM CoSERV's data model inherits heavily from that of . CoSERV responses can contain one or more complete CoRIM artifacts. They can also contain aggregated views that are composed of multiple CoRIM fragments. The security and privacy considerations set out in therefore apply equally to CoSERV.

Forming Native Database Queries from CoSERV Implementations should take care when transforming CoSERV queries into native query types that are compatible with their underlying storage technology (such as SQL queries). There is a risk of injection attacks arising from poorly-formed or maliciously-formed CoSERV queries. Implementations must ensure that suitable sanitization procedures are in place when performing such translations.

Aggregators Aggregation (see ) is the process of combining artifacts from multiple Endorser or Reference Value Provider sources, which is a necessary step in some supply chains. CoSERV supports aggregation explicitly at the protocol level, but is agnostic with regards to how (or whether) such support is used. However, there are specific security considerations for deployments that make use of aggregators. When used, aggregators feed Endorsements and Reference Values to the Verifier (possibly via further aggregators). This means that they act in the Endorser and/or Reference Value Provider roles of RATS, both of which are trusted roles. Aggregators are therefore trusted components. Further, since the purpose of an aggregator is to provide a consolidated point of consumption for the Verifier, there is a risk of its becoming a single point of failure or vulnerability. An aggregator that is unavailable, malfunctioning, or malicious, has the potential to impact the security of the overall deployment. For example, a malicious aggregator might attempt to impersonate or otherwise subvert the authority of other actors in the supply chain, such as hardware or firmware vendors. The intent of CoSERV is for aggregators to provide an optional convenience layer for the Verifier, rather than to be a subversive authority. The design features of CoSERV can be used alongside judicious deployment practices to mitigate the risks. An informative and non-exhaustive list of mitigations follows:

• Use independent chains of trust. It is established above that aggregators are trusted components. This does not mean that they necessarily become a sole or replacement trust authority. CoSERV's aggregation model allows for deference to other authorities that exist in the supply chain. This is true even when an aggregator is acting in the Endorser role. A hardware Endorsement, for example, might be delivered to the Verifier via an aggregator (along with multiple other artifacts, such as Reference Values). But the authority of that Endorsement can still be chained back to the hardware provider, and this authority can be checked by the Verifier using a trust anchor associated with that hardware provider.
• Inspect the authority delegation chains. The "quads" feature of the CoSERV data model provides explicit tracking of supply chain sources. Each inner CoMID triple of an aggregated CoSERV response is annotated with an authority delegation chain. This is a sequence of delegated trust authorities, each of which might be either a further upstream aggregator or a primary supply chain actor. This information allows the consumer (Verifier) to inspect the provenance of each aggregated result, which can be checked against its own independent record of trustworthy sources.
• Use source artifacts. CoSERV's aggregation model supports the pass-through of artifacts from upstream supply-chain actors, known as "source artifacts" in the data model. Source artifacts are passed verbatim in CoSERV, meaning that they retain any original signatures. This provides another means of checking the provenance and integrity of such artifacts, independently of any signature that is applied to the CoSERV result by the aggregator (see ).
• Mutual trust between aggregators and primary supply chain actors. The default assumption of CoSERV is that trust flows in one direction only: CoSERV consumers trust CoSERV producers, but not the reverse. When a Verifier sends a CoSERV query to an aggregator, the Verifier is trusting that aggregator, but not the reverse. Likewise, when an aggregator calls a primary supply chain source (whether using CoSERV or some proprietary mechanism), then the aggregator is trusting that primary supply chain source, but not the reverse. Indeed, a primary supply chain source might not even be aware of the existence of any aggregator that is consuming artifacts from it, let alone place any trust in such an aggregator. However, it is perfectly valid for a deployment to deviate from this baseline, provided that the suitable technical and contractual enablers are put in place. There could exist an aggregator that is trusted - and vouched for - by the primary supply chain actor(s) from which it consumes. Supply chain actors might even actively provision their artifacts into the aggregator for onward distribution. The clients of such an aggregator might then be able to make more use of the "shallow trust" model described in , with a greater reliance on collected artifacts rather than source artifacts.

Privacy Considerations A CoSERV query can potentially contain privacy-sensitive information. Specifically, the environment-selector field of the query may reference identifiable Attester instances in some cases. This concern naturally also extends to the data objects that might be returned to the consumer in response to the query, although the specifications of such data objects are beyond the scope of this document. Implementations should ensure that appropriate attention is paid to this. Suitable mitigations include the following:

• The use of authenticated secure channels between the producers and the consumers of CoSERV queries and returned artifacts.
• Collating Attester instances into anonymity groups, and referencing the groups rather than the individual instances.

Aggregators Aggregators (as described in ) can pose a specific privacy risk. This is because they necessarily correlate inputs from multiple supply-chain actors, and can observe repeated CoSERV queries over time. In doing so, an aggregator might be able to infer details about the composition of an Attester's hardware, firmware or software components. Such details would not be accessible to individual supply-chain actors implementing the Endorser or Reference Value Provider roles. There is consequently a risk that such inferred details could be misused to create a covert channel.

Domains Domain queries and domain result sets can reveal the topology of a Composite Attester, including the relationship between parent and child environments and the trust dependencies between domains. This information can be sensitive even when the environment identifiers themselves are not individually identifying. Implementations should apply the same access-control, confidentiality, and minimization considerations to Domain artifacts as to other privacy-sensitive CoSERV query and result data.

Query URIs In the HTTP binding, the serialized query is carried in the request URI. URIs are more likely than request content to be logged by clients, servers and intermediaries. Where a query identifies individual Attester instances or other small anonymity groups, such logging can disclose them. Deployments should treat logs containing CoSERV query URIs as sensitive, and can use the QUERY method () where it is available.

Caching Caching is an important characteristic of CoSERV in general, and of the CoSERV HTTP bindings in particular. CoSERV transactions are expected to benefit from the use of HTTP caching infrastructure as explained in . CoSERV's deterministic encoding rules allow for encoded queries to be used as cache keys. Where queries contain privacy-sensitive information, such as references to individual Attester instances or other small anonymity groups, there is a risk of HTTP caches themselves becoming an oracle. For instance, the time taken to generate a response could indicate whether a client has already queried the same information previously. An attacker could use these timings to gain intelligence about the use of those instances or groups. Safe methods can be replayed, including in TLS 0-RTT early data, so the cost of executing queries is a consideration for origin servers independently of caching. Implementations should be intentional about their use of caching, and avoid relying on default behaviours that could lead to side channels. For example, the Cache-Control: no-store or Cache-Control: private directives can be used selectively in situations where very fine-grained information is being queried, while still allowing broader queries to benefit from caching.

IANA Considerations [^rfced] replace "RFCthis" with the RFC number assigned to this document.

Media Types Registrations IANA is requested to add the following media types to the "Media Types" registry . CoSERV Media Types

Name	Template	Reference
coserv+cbor	application/coserv+cbor	of RFCthis
coserv+cose	application/coserv+cose	of RFCthis
coserv-discovery+cbor	application/coserv-discovery+cbor	of RFCthis
coserv-discovery+json	application/coserv-discovery+json	of RFCthis

application/coserv+cbor

Type name:

application

Subtype name:

coserv+cbor

Required parameters:

n/a

Optional parameters:

"profile" (CoSERV profile in string format. OIDs must use the dotted-decimal notation.)

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Verifiers, Endorsers, Reference Value Providers

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/coserv+cose

Type name:

application

Subtype name:

coserv+cose

Required parameters:

n/a (cose-type is explicitly not supported, as it is understood to be "cose-sign1")

Optional parameters:

"profile" CoSERV profile in string format. OIDs must use the dotted-decimal notation. Note that the cose-type parameter is explicitly not supported, as it is understood to be "cose-sign1".

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Verifiers, Endorsers, Reference Value Providers

Fragment identifier considerations:

n/a

Person and email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration?

no

application/coserv-discovery+cbor

Type name:

application

Subtype name:

coserv-discovery+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Verifiers, Endorsers, Reference Value Providers

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/coserv-discovery+json

Type name:

application

Subtype name:

coserv-discovery+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Verifiers, Endorsers, Reference Value Providers

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

CoAP Content-Formats IANA is requested to register the following Content-Format IDs in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group : New CoAP Content Formats

Content-Type	Content Coding	ID	Reference
application/coserv+cbor	-	TBD1	of RFCthis
application/coserv+cose	-	TBD2	of RFCthis

If possible, TBD1 and TBD2 should be assigned in the 256..9999 range.

Well-Known URI for CoSERV Configuration IANA is requested to register the following in the "Well-Known URIs" registry : URI suffix: coserv-configuration Change controller: IETF Specification document: RFCthis Related information: N/A

References Normative References A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. 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. 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. IANA IANA IANA Informative References A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. 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. This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests, but QUERY requests can be automatically repeated or restarted without concern for partial state changes. Armidale Consulting Fraunhofer SIT NVIDIA In the IETF Remote Attestation Procedures (RATS) architecture (RFC 9334), a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it updates RFC 9334 by refining the description of Endorsements and Reference Values. Specifically, this document classifies the RATS conceptual messages as actual state, reference state, or appraisal policy, and adds considerations on conditionally endorsed values, endorsing verification keys, timeliness, and multiple Endorsements. Fraunhofer SIT Sandelman Software Works Huawei Technologies Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services.

Collated CDDL

CoSERV Data Model int, 3 => "application/coserv+cbor" / 10000, * cose.label => cose.values, } signed-coserv-unprotected-hdr = {* cose.label => cose.values} cose.label = int / text cose.values = any coserv = { &(profile: 0) => profile, &(query: 1) => query, ? &(results: 2) => results, } profile = comid.oid-type / ~uri query = {environment-query // rim-query} environment-query = ( &(artifact-type: 0) => artifact-type, &(environment-selector: 1) => environment-selector-map, &(result-type: 2) => result-type, ) rim-query = (&(rim-selector: 3) => [+ rim-selector-id]) rim-selector-id = [ &(comid: 0), comid.$tag-id-type-choice, ] / [ &(coswid: 1), coswid.tag-id, ] / [ &(corim: 2), corim.$corim-id-type-choice, ] artifact-type = &(endorsed-values: 0) / &(trust-anchors: 1) / &(\ reference-values: 2) / &(domains: 3) result-type = &(collected-artifacts: 0) / &(source-artifacts: 1) / &\ (both: 2) results = { (environment-result // rim-result), &(expiry: 10) => tdate, } environment-result = (result-set // &(source-artifacts: 11) => [+ \ cmw.cbor-record] // ( result-set, &(source-artifacts: 11) => [+ cmw.cbor-record], )) rim-result = (&(rims: 5) => cmw.cbor-collection) result-set //= (reference-values // endorsed-values // trust-\ anchors // domains) refval-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(rv-triple: 2) => comid.reference-triple-record, } reference-values = (&(rvq: 0) => [* refval-quad]) endval-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(ev-triple: 2) => comid.endorsed-triple-record, } cond-endval-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(ce-triple: 2) => comid.conditional-endorsement-triple-record, } endorsed-values = ( &(evq: 1) => [* endval-quad], &(ceq: 2) => [* cond-endval-quad], ) ak-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(ak-triple: 2) => comid.attest-key-triple-record, } cots-stmt = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(cots: 2) => cots, } trust-anchors = ( &(akq: 3) => [* ak-quad], &(tas: 4) => [* cots-stmt], ) membership-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(membership-triple: 2) => comid.domain-membership-triple-record, } dependency-quad = { &(authorities: 1) => [+ comid.$crypto-key-type-choice], &(dependency-triple: 2) => comid.domain-dependency-triple-record, } domains = ( &(membership: 5) => [* membership-quad], &(dependency: 6) => [* dependency-quad], ) cots = "TODO COTS" environment-selector-map = {selector} stateful-class = [ class: comid.class-map, ? measurements: [+ comid.measurement-map], ] selector //= (&(class: 0) => [+ stateful-class] // &(instance: 1) =\ > [+ stateful-instance] // &(group: 2) => [+ stateful-group]) stateful-instance = [ instance: comid.$instance-id-type-choice, ? measurements: [+ comid.measurement-map], ] stateful-group = [ group: comid.$group-id-type-choice, ? measurements: [+ comid.measurement-map], ] cmw.start = cmw.cmw cmw.cmw = cmw.json-cmw / cmw.cbor-cmw cmw.json-cmw = cmw.json-record / cmw.json-collection cmw.cbor-cmw = cmw.cbor-record / cmw.cbor-collection / cmw.$cbor-tag cmw.json-record = [ type: cmw.media-type, value: cmw.base64url-string, ? ind: uint .bits cmw.cm-type, ] cmw.cbor-record = [ type: cmw.coap-content-format-type / cmw.media-type, value: bytes, ? ind: uint .bits cmw.cm-type, ] cmw.tag-cm-cbor = #6.(bytes .cbor fmt) cmw.tag-cm-data = #6.(bytes) cmw.json-collection = { ? __cmwc_t: ~uri / cmw.oid, + &(label: text) => cmw.json-cmw, } cmw.cbor-collection = { ? __cmwc_t: ~uri / cmw.oid, + &(label: int / text) => cmw.cbor-cmw, } cmw.media-type = text .abnf ("Content-Type" .cat cmw.Content-Type-\ ABNF) cmw.base64url-string = text .regexp "[A-Za-z0-9_-]+" cmw.coap-content-format-type = uint .size 2 cmw.oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" cmw.cm-type = &( reference-values: 0, endorsements: 1, evidence: 2, attestation-results: 3, appraisal-policy: 4, ) cmw.Content-Type-ABNF = ' Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\\" ( SP / VCHAR ) Media-Type-Name = type-name "/" subtype-name type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix DIGIT = %x30-39 ; 0 - 9 POS-DIGIT = %x31-39 ; 1 - 9 ALPHA = %x41-5A / %x61-7A ; A - Z / a - z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ' cmw.$cbor-tag /= cmw.tag-cm-data<1668612070> / cmw.tag-cm-cbor<\ 1668612069, cmw.my-evidence> cmw.my-evidence = {&(eat_nonce: 10) => bytes .size (8 .. 64)} comid.concise-mid-tag = { ? &(language: 0) => text, &(tag-identity: 1) => comid.tag-identity-map, ? &(entities: 2) => [+ comid.comid-entity-map], ? &(linked-tags: 3) => [+ comid.linked-tag-map], &(triples: 4) => comid.triples-map, * $$concise-mid-tag-extension, } comid.attest-key-triple-record = [ environment: comid.environment-map, key-list: [+ comid.$crypto-key-type-choice], ? conditions: comid.non-empty<{ ? &(mkey: 0) => comid.$measured-element-type-choice, ? &(authorized-by: 1) => [+ comid.$crypto-key-type-\ choice], }>, ] comid.$class-id-type-choice /= comid.tagged-oid-type / comid.tagged-\ uuid-type / comid.tagged-bytes comid.class-map = comid.non-empty<{ ? &(class-id: 0) => comid.$class-id-type-choice, ? &(vendor: 1) => tstr, ? &(model: 2) => tstr, ? &(layer: 3) => uint, ? &(index: 4) => uint, }> comid.comid-entity-map = comid.entity-map comid.$comid-role-type-choice /= &(tag-creator: 0) / &(creator: 1) \ / &(maintainer: 2) comid.conditional-endorsement-series-triple-record = [ condition: comid.stateful-environment-record, series: [+ comid.conditional-series-record], ] comid.conditional-series-record = [ selection: [+ comid.measurement-map], addition: [+ comid.measurement-map], ] comid.COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * comid.cose-label => comid.cose-value, } comid.cose-label = int / tstr comid.cose-value = any comid.coswid-triple-record = [ comid.environment-map, [+ comid.concise-swid-tag-id], ] comid.concise-swid-tag-id = text / bstr .size 16 comid.$crypto-key-type-choice /= comid.tagged-pkix-base64-key-type \ / comid.tagged-pkix-base64-cert-type / comid.tagged-pkix-base64-cert\ -path-type / comid.tagged-cose-key-type / comid.tagged-pkix-asn1der-\ cert-type / comid.tagged-key-thumbprint-type / comid.tagged-cert-\ thumbprint-type / comid.tagged-cert-path-thumbprint-type / comid.\ tagged-bytes comid.tagged-pkix-base64-key-type = #6.554(tstr) comid.tagged-pkix-base64-cert-type = #6.555(tstr) comid.tagged-pkix-base64-cert-path-type = #6.556(tstr) comid.tagged-key-thumbprint-type = #6.557(comid.digest) comid.tagged-cose-key-type = #6.558(comid.COSE_Key) comid.tagged-cert-thumbprint-type = #6.559(comid.digest) comid.tagged-cert-path-thumbprint-type = #6.561(comid.digest) comid.tagged-pkix-asn1der-cert-type = #6.562(bstr) comid.domain-dependency-triple-record = [ comid.domain-type, [+ comid.domain-type], ] comid.domain-membership-triple-record = [ domain-id: comid.domain-type, members: [+ comid.domain-type], ] comid.conditional-endorsement-triple-record = [ conditions: [+ comid.stateful-environment-record], endorsements: [+ comid.endorsed-triple-record], ] comid.domain-type = comid.environment-map comid.endorsed-triple-record = [ condition: comid.environment-map, endorsement: [+ comid.measurement-map], ] comid.entity-map = { &(entity-name: 0) => comid.$entity-name-type-choice, ? &(reg-id: 1) => uri, &(role: 2) => [+ role-type-choice], * extension-socket, } comid.$entity-name-type-choice /= text comid.environment-map = comid.non-empty<{ ? &(class: 0) => comid.class-map, ? &(instance: 1) => comid.$instance-id-type-choice, ? &(group: 2) => comid.$group-id-type-choice, }> comid.flags-map = { ? &(is-configured: 0) => bool, ? &(is-secure: 1) => bool, ? &(is-recovery: 2) => bool, ? &(is-debug: 3) => bool, ? &(is-replay-protected: 4) => bool, ? &(is-integrity-protected: 5) => bool, ? &(is-runtime-meas: 6) => bool, ? &(is-immutable: 7) => bool, ? &(is-tcb: 8) => bool, ? &(is-confidentiality-protected: 9) => bool, * $$flags-map-extension, } comid.$group-id-type-choice /= comid.tagged-uuid-type / comid.tagged\ -bytes comid.identity-triple-record = [ environment: comid.environment-map, key-list: [+ comid.$crypto-key-type-choice], ? conditions: comid.non-empty<{ ? &(mkey: 0) => comid.$measured-element-type-choice, ? &(authorized-by: 1) => [+ comid.$crypto-key-type-\ choice], }>, ] comid.$instance-id-type-choice /= comid.tagged-ueid-type / comid.\ tagged-uuid-type / comid.tagged-bytes / comid.tagged-pkix-base64-key\ -type / comid.tagged-pkix-base64-cert-type / comid.tagged-cose-key-\ type / comid.tagged-key-thumbprint-type / comid.tagged-cert-\ thumbprint-type / comid.tagged-pkix-asn1der-cert-type comid.ip-addr-type-choice = comid.ip4-addr-type / comid.ip6-addr-type comid.ip4-addr-type = bytes .size 4 comid.ip6-addr-type = bytes .size 16 comid.int-range-type-choice = int / comid.tagged-int-range comid.int-range = [ min: int / comid.negative-inf, max: int / comid.positive-inf, ] comid.tagged-int-range = #6.564(comid.int-range) comid.positive-inf = null comid.negative-inf = null comid.linked-tag-map = { &(linked-tag-id: 0) => comid.$tag-id-type-choice, &(tag-rel: 1) => comid.$tag-rel-type-choice, } comid.mac-addr-type-choice = comid.eui48-addr-type / comid.eui64-\ addr-type comid.eui48-addr-type = bytes .size 6 comid.eui64-addr-type = bytes .size 8 comid.$measured-element-type-choice /= comid.tagged-oid-type / comid\ .tagged-uuid-type / uint / tstr comid.measurement-map = { ? &(mkey: 0) => comid.$measured-element-type-choice, &(mval: 1) => comid.measurement-values-map, ? &(authorized-by: 2) => [+ comid.$crypto-key-type-choice], } comid.measurement-values-map = comid.non-empty<{ ? &(version: 0) => comid.version-map, ? &(svn: 1) => comid.svn-type-choice, ? &(digests: 2) => comid.digests-type, ? &(flags: 3) => comid.flags-map, ? ( &(raw-value: 4) => comid.$raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => comid.raw-\ value-mask-type, ), ? &(mac-addr: 6) => comid.mac-addr-type-choice, ? &(ip-addr: 7) => comid.ip-addr-type-choice, ? &(serial-number: 8) => text, ? &(ueid: 9) => comid.ueid-type, ? &(uuid: 10) => comid.uuid-type, ? &(name: 11) => text, ? &(cryptokeys: 13) => [+ comid.$crypto-key-type-choice], ? &(integrity-registers: 14) => comid.integrity-registers, ? &(int-range: 15) => comid.int-range-type-choice, * $$measurement-values-map-extension, }> comid.non-empty = M .and ({+ any => any}) comid.oid-type = bytes comid.tagged-oid-type = #6.111(comid.oid-type) comid.$raw-value-type-choice /= comid.tagged-bytes / comid.tagged-\ masked-raw-value comid.raw-value-mask-type = bytes comid.tagged-masked-raw-value = #6.563([ value: bytes, mask: bytes, ]) comid.reference-triple-record = [ ref-env: comid.environment-map, ref-claims: [+ comid.measurement-map], ] comid.stateful-environment-record = [ environment: comid.environment-map, claims-list: [+ comid.measurement-map], ] comid.svn-type = uint comid.svn = comid.svn-type comid.min-svn = comid.svn-type comid.tagged-svn = #6.552(comid.svn) comid.tagged-min-svn = #6.553(comid.min-svn) comid.svn-type-choice = comid.svn / comid.tagged-svn / comid.tagged-\ min-svn comid.$tag-id-type-choice /= tstr / comid.uuid-type comid.tag-identity-map = { &(tag-id: 0) => comid.$tag-id-type-choice, ? &(tag-version: 1) => comid.tag-version-type, } comid.$tag-rel-type-choice /= &(supplements: 0) / &(replaces: 1) comid.tag-version-type = uint .default 0 comid.tagged-bytes = #6.560(bytes) comid.triples-map = comid.non-empty<{ ? &(reference-triples: 0) => [+ comid.reference-triple-record], ? &(endorsed-triples: 1) => [+ comid.endorsed-triple-record], ? &(identity-triples: 2) => [+ comid.identity-triple-record], ? &(attest-key-triples: 3) => [+ comid.attest-key-triple-record], ? &(dependency-triples: 4) => [+ comid.domain-dependency-triple-\ record], ? &(membership-triples: 5) => [+ comid.domain-membership-triple-\ record], ? &(coswid-triples: 6) => [+ comid.coswid-triple-record], ? &(conditional-endorsement-series-triples: 8) => [+ comid.\ conditional-endorsement-series-triple-record], ? &(conditional-endorsement-triples: 10) => [+ comid.conditional\ -endorsement-triple-record], * $$triples-map-extension, }> comid.ueid-type = bytes .size (7 .. 33) comid.tagged-ueid-type = #6.550(comid.ueid-type) comid.uuid-type = bytes .size 16 comid.tagged-uuid-type = #6.37(comid.uuid-type) comid.version-map = { &(version: 0) => text, ? &(version-scheme: 1) => comid.$version-scheme, } comid.digest = [ alg: int / text, val: bytes, ] comid.digests-type = [+ comid.digest] comid.integrity-register-id-type-choice = uint / text comid.integrity-registers = {+ comid.integrity-register-id-type-\ choice => comid.digests-type} comid.concise-swid-tag = { comid.tag-id => text / bstr .size 16, comid.tag-version => integer, ? comid.corpus => bool, ? comid.patch => bool, ? comid.supplemental => bool, comid.software-name => text, ? comid.software-version => text, ? comid.version-scheme => comid.$version-scheme, ? comid.media => text, ? comid.software-meta => comid.one-or-more, comid.entity => comid.one-or-more, ? comid.link => comid.one-or-more, ? comid.payload-or-evidence, * $$coswid-extension, comid.global-attributes, } comid.payload-or-evidence //= (comid.payload => comid.payload-entry \ // comid.evidence => comid.evidence-entry) comid.any-uri = uri comid.label = text / int comid.$version-scheme /= comid.multipartnumeric / comid.\ multipartnumeric-suffix / comid.alphanumeric / comid.decimal / comid\ .semver / int / text comid.any-attribute = (comid.label => comid.one-or-more / \ comid.one-or-more) comid.one-or-more = T / [2*T] comid.global-attributes = ( ? comid.lang => text, * comid.any-attribute, ) comid.hash-entry = [ hash-alg-id: int, hash-value: bytes, ] comid.entity-entry = { comid.entity-name => text, ? comid.reg-id => comid.any-uri, comid.role => comid.one-or-more, ? comid.thumbprint => comid.hash-entry, * $$entity-extension, comid.global-attributes, } comid.$role /= comid.tag-creator / comid.software-creator / comid.\ aggregator / comid.distributor / comid.licensor / comid.maintainer \ / int / text comid.link-entry = { ? comid.artifact => text, comid.href => comid.any-uri, ? comid.media => text, ? comid.ownership => comid.$ownership, comid.rel => comid.$rel, ? comid.media-type => text, ? comid.use => comid.$use, * $$link-extension, comid.global-attributes, } comid.$ownership /= comid.shared / comid.private / comid.abandon / \ int / text comid.$rel /= comid.ancestor / comid.component / comid.feature / \ comid.installationmedia / comid.packageinstaller / comid.parent / \ comid.patches / comid.requires / comid.see-also / comid.supersedes \ / comid.supplemental / -256 .. 64436 / text comid.$use /= comid.optional / comid.required / comid.recommended / \ int / text comid.software-meta-entry = { ? comid.activation-status => text, ? comid.channel-type => text, ? comid.colloquial-version => text, ? comid.description => text, ? comid.edition => text, ? comid.entitlement-data-required => bool, ? comid.entitlement-key => text, ? comid.generator => text / bstr .size 16, ? comid.persistent-id => text, ? comid.product => text, ? comid.product-family => text, ? comid.revision => text, ? comid.summary => text, ? comid.unspsc-code => text, ? comid.unspsc-version => text, * $$software-meta-extension, comid.global-attributes, } comid.path-elements-group = ( ? comid.directory => comid.one-or-more, ? comid.file => comid.one-or-more, ) comid.resource-collection = ( comid.path-elements-group, ? comid.process => comid.one-or-more, ? comid.resource => comid.one-or-more, * $$resource-collection-extension, ) comid.file-entry = { comid.filesystem-item, ? comid.size => uint, ? comid.file-version => text, ? comid.hash => comid.hash-entry, * $$file-extension, comid.global-attributes, } comid.directory-entry = { comid.filesystem-item, ? comid.path-elements => {comid.path-elements-group}, * $$directory-extension, comid.global-attributes, } comid.process-entry = { comid.process-name => text, ? comid.pid => integer, * $$process-extension, comid.global-attributes, } comid.resource-entry = { comid.type => text, * $$resource-extension, comid.global-attributes, } comid.filesystem-item = ( ? comid.key => bool, ? comid.location => text, comid.fs-name => text, ? comid.root => text, ) comid.payload-entry = { comid.resource-collection, * $$payload-extension, comid.global-attributes, } comid.evidence-entry = { comid.resource-collection, ? comid.date => comid.integer-time, ? comid.device-id => text, ? comid.location => text, * $$evidence-extension, comid.global-attributes, } comid.integer-time = #6.1(int) comid.tag-id = 0 comid.software-name = 1 comid.entity = 2 comid.evidence = 3 comid.link = 4 comid.software-meta = 5 comid.payload = 6 comid.hash = 7 comid.corpus = 8 comid.patch = 9 comid.media = 10 comid.supplemental = 11 comid.tag-version = 12 comid.software-version = 13 comid.version-scheme = 14 comid.lang = 15 comid.directory = 16 comid.file = 17 comid.process = 18 comid.resource = 19 comid.size = 20 comid.file-version = 21 comid.key = 22 comid.location = 23 comid.fs-name = 24 comid.root = 25 comid.path-elements = 26 comid.process-name = 27 comid.pid = 28 comid.type = 29 comid.entity-name = 31 comid.reg-id = 32 comid.role = 33 comid.thumbprint = 34 comid.date = 35 comid.device-id = 36 comid.artifact = 37 comid.href = 38 comid.ownership = 39 comid.rel = 40 comid.media-type = 41 comid.use = 42 comid.activation-status = 43 comid.channel-type = 44 comid.colloquial-version = 45 comid.description = 46 comid.edition = 47 comid.entitlement-data-required = 48 comid.entitlement-key = 49 comid.generator = 50 comid.persistent-id = 51 comid.product = 52 comid.product-family = 53 comid.revision = 54 comid.summary = 55 comid.unspsc-code = 56 comid.unspsc-version = 57 comid.multipartnumeric = 1 comid.multipartnumeric-suffix = 2 comid.alphanumeric = 3 comid.decimal = 4 comid.semver = 16384 comid.tag-creator = 1 comid.software-creator = 2 comid.aggregator = 3 comid.distributor = 4 comid.licensor = 5 comid.maintainer = 6 comid.abandon = 1 comid.private = 2 comid.shared = 3 comid.ancestor = 1 comid.component = 2 comid.feature = 3 comid.installationmedia = 4 comid.packageinstaller = 5 comid.parent = 6 comid.patches = 7 comid.requires = 8 comid.see-also = 9 comid.supersedes = 10 comid.optional = 1 comid.required = 2 comid.recommended = 3 corim.corim = corim.concise-rim-type-choice corim.concise-rim-type-choice /= corim.tagged-unsigned-corim-map / \ corim.signed-corim corim.concise-tl-tag = { &(tag-identity: 0) => corim.tag-identity-map, &(tags-list: 1) => [+ corim.tag-identity-map], &(tl-validity: 2) => corim.validity-map, } corim.$concise-tag-type-choice /= corim.tagged-concise-swid-tag / \ corim.tagged-concise-mid-tag / corim.tagged-concise-tl-tag corim.corim-entity-map = corim.entity-map corim.$corim-id-type-choice /= tstr / corim.uuid-type corim.corim-locator-map = { &(href: 0) => uri / [+ uri], ? &(thumbprint: 1) => corim.digest / [corim.digest], } corim.corim-map = { &(id: 0) => corim.$corim-id-type-choice, &(tags: 1) => [+ corim.$concise-tag-type-choice], ? &(dependent-rims: 2) => [+ corim.corim-locator-map], ? &(profile: 3) => corim.$profile-type-choice, ? &(rim-validity: 4) => corim.validity-map, ? &(entities: 5) => [+ corim.corim-entity-map], * $$corim-map-extension, } corim.unsigned-corim-map = corim.corim-map corim.corim-meta-map = { &(signer: 0) => corim.corim-signer-map, ? &(signature-validity: 1) => corim.validity-map, } corim.$corim-role-type-choice /= &(manifest-creator: 1) / &(manifest\ -signer: 2) corim.corim-signer-map = { &(signer-name: 0) => corim.$entity-name-type-choice, ? &(signer-uri: 1) => uri, * $$corim-signer-map-extension, } corim.COSE-Sign1-corim = [ protected: bstr .cbor corim.protected-corim-header-map, unprotected: corim.unprotected-corim-header-map, payload: bstr .cbor corim.tagged-unsigned-corim-map, signature: bstr, ] corim.$profile-type-choice /= uri / corim.tagged-oid-type corim.cwt-claims = { &(iss: 1) => tstr, ? &(sub: 2) => tstr, ? &(exp: 4) => int / float, ? &(nbf: 5) => int / float, * int => any, } corim.protected-corim-header-map = { &(alg: 1) => int, &(content-type: 3) => "application/rim+cbor", corim.meta-group, * corim.cose-label => corim.cose-value, } corim.meta-group = (( corim.corim-meta-identity, ? corim.cwt-claims-identity, ) // corim.cwt-claims-identity) corim.corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim.\ corim-meta-map) corim.cwt-claims-identity = (&(CWT-Claims: 15) => corim.cwt-claims) corim.signed-corim = #6.18(corim.COSE-Sign1-corim) corim.tagged-concise-swid-tag = #6.505(bytes .cbor corim.concise-\ swid-tag) corim.tagged-concise-mid-tag = #6.506(bytes .cbor corim.concise-mid-\ tag) corim.tagged-concise-tl-tag = #6.508(bytes .cbor corim.concise-tl-\ tag) corim.tagged-unsigned-corim-map = #6.501(corim.unsigned-corim-map) corim.unprotected-corim-header-map = {* corim.cose-label => corim.\ cose-value} corim.validity-map = { ? &(not-before: 0) => time, &(not-after: 1) => time, } corim.concise-mid-tag = { ? &(language: 0) => text, &(tag-identity: 1) => corim.tag-identity-map, ? &(entities: 2) => [+ corim.comid-entity-map], ? &(linked-tags: 3) => [+ corim.linked-tag-map], &(triples: 4) => corim.triples-map, * $$concise-mid-tag-extension, } corim.attest-key-triple-record = [ environment: corim.environment-map, key-list: [+ corim.$crypto-key-type-choice], ? conditions: corim.non-empty<{ ? &(mkey: 0) => corim.$measured-element-type-choice, ? &(authorized-by: 1) => [+ corim.$crypto-key-type-\ choice], }>, ] corim.$class-id-type-choice /= corim.tagged-oid-type / corim.tagged-\ uuid-type / corim.tagged-bytes corim.class-map = corim.non-empty<{ ? &(class-id: 0) => corim.$class-id-type-choice, ? &(vendor: 1) => tstr, ? &(model: 2) => tstr, ? &(layer: 3) => uint, ? &(index: 4) => uint, }> corim.comid-entity-map = corim.entity-map corim.$comid-role-type-choice /= &(tag-creator: 0) / &(creator: 1) \ / &(maintainer: 2) corim.conditional-endorsement-series-triple-record = [ condition: corim.stateful-environment-record, series: [+ corim.conditional-series-record], ] corim.conditional-series-record = [ selection: [+ corim.measurement-map], addition: [+ corim.measurement-map], ] corim.COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * corim.cose-label => corim.cose-value, } corim.cose-label = int / tstr corim.cose-value = any corim.coswid-triple-record = [ corim.environment-map, [+ corim.concise-swid-tag-id], ] corim.concise-swid-tag-id = text / bstr .size 16 corim.$crypto-key-type-choice /= corim.tagged-pkix-base64-key-type \ / corim.tagged-pkix-base64-cert-type / corim.tagged-pkix-base64-cert\ -path-type / corim.tagged-cose-key-type / corim.tagged-pkix-asn1der-\ cert-type / corim.tagged-key-thumbprint-type / corim.tagged-cert-\ thumbprint-type / corim.tagged-cert-path-thumbprint-type / corim.\ tagged-bytes corim.tagged-pkix-base64-key-type = #6.554(tstr) corim.tagged-pkix-base64-cert-type = #6.555(tstr) corim.tagged-pkix-base64-cert-path-type = #6.556(tstr) corim.tagged-key-thumbprint-type = #6.557(corim.digest) corim.tagged-cose-key-type = #6.558(corim.COSE_Key) corim.tagged-cert-thumbprint-type = #6.559(corim.digest) corim.tagged-cert-path-thumbprint-type = #6.561(corim.digest) corim.tagged-pkix-asn1der-cert-type = #6.562(bstr) corim.domain-dependency-triple-record = [ corim.domain-type, [+ corim.domain-type], ] corim.domain-membership-triple-record = [ domain-id: corim.domain-type, members: [+ corim.domain-type], ] corim.conditional-endorsement-triple-record = [ conditions: [+ corim.stateful-environment-record], endorsements: [+ corim.endorsed-triple-record], ] corim.domain-type = corim.environment-map corim.endorsed-triple-record = [ condition: corim.environment-map, endorsement: [+ corim.measurement-map], ] corim.entity-map = { &(entity-name: 0) => corim.$entity-name-type-choice, ? &(reg-id: 1) => uri, &(role: 2) => [+ role-type-choice], * extension-socket, } corim.$entity-name-type-choice /= text corim.environment-map = corim.non-empty<{ ? &(class: 0) => corim.class-map, ? &(instance: 1) => corim.$instance-id-type-choice, ? &(group: 2) => corim.$group-id-type-choice, }> corim.flags-map = { ? &(is-configured: 0) => bool, ? &(is-secure: 1) => bool, ? &(is-recovery: 2) => bool, ? &(is-debug: 3) => bool, ? &(is-replay-protected: 4) => bool, ? &(is-integrity-protected: 5) => bool, ? &(is-runtime-meas: 6) => bool, ? &(is-immutable: 7) => bool, ? &(is-tcb: 8) => bool, ? &(is-confidentiality-protected: 9) => bool, * $$flags-map-extension, } corim.$group-id-type-choice /= corim.tagged-uuid-type / corim.tagged\ -bytes corim.identity-triple-record = [ environment: corim.environment-map, key-list: [+ corim.$crypto-key-type-choice], ? conditions: corim.non-empty<{ ? &(mkey: 0) => corim.$measured-element-type-choice, ? &(authorized-by: 1) => [+ corim.$crypto-key-type-\ choice], }>, ] corim.$instance-id-type-choice /= corim.tagged-ueid-type / corim.\ tagged-uuid-type / corim.tagged-bytes / corim.tagged-pkix-base64-key\ -type / corim.tagged-pkix-base64-cert-type / corim.tagged-cose-key-\ type / corim.tagged-key-thumbprint-type / corim.tagged-cert-\ thumbprint-type / corim.tagged-pkix-asn1der-cert-type corim.ip-addr-type-choice = corim.ip4-addr-type / corim.ip6-addr-type corim.ip4-addr-type = bytes .size 4 corim.ip6-addr-type = bytes .size 16 corim.int-range-type-choice = int / corim.tagged-int-range corim.int-range = [ min: int / corim.negative-inf, max: int / corim.positive-inf, ] corim.tagged-int-range = #6.564(corim.int-range) corim.positive-inf = null corim.negative-inf = null corim.linked-tag-map = { &(linked-tag-id: 0) => corim.$tag-id-type-choice, &(tag-rel: 1) => corim.$tag-rel-type-choice, } corim.mac-addr-type-choice = corim.eui48-addr-type / corim.eui64-\ addr-type corim.eui48-addr-type = bytes .size 6 corim.eui64-addr-type = bytes .size 8 corim.$measured-element-type-choice /= corim.tagged-oid-type / corim\ .tagged-uuid-type / uint / tstr corim.measurement-map = { ? &(mkey: 0) => corim.$measured-element-type-choice, &(mval: 1) => corim.measurement-values-map, ? &(authorized-by: 2) => [+ corim.$crypto-key-type-choice], } corim.measurement-values-map = corim.non-empty<{ ? &(version: 0) => corim.version-map, ? &(svn: 1) => corim.svn-type-choice, ? &(digests: 2) => corim.digests-type, ? &(flags: 3) => corim.flags-map, ? ( &(raw-value: 4) => corim.$raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => corim.raw-\ value-mask-type, ), ? &(mac-addr: 6) => corim.mac-addr-type-choice, ? &(ip-addr: 7) => corim.ip-addr-type-choice, ? &(serial-number: 8) => text, ? &(ueid: 9) => corim.ueid-type, ? &(uuid: 10) => corim.uuid-type, ? &(name: 11) => text, ? &(cryptokeys: 13) => [+ corim.$crypto-key-type-choice], ? &(integrity-registers: 14) => corim.integrity-registers, ? &(int-range: 15) => corim.int-range-type-choice, * $$measurement-values-map-extension, }> corim.non-empty = M .and ({+ any => any}) corim.oid-type = bytes corim.tagged-oid-type = #6.111(corim.oid-type) corim.$raw-value-type-choice /= corim.tagged-bytes / corim.tagged-\ masked-raw-value corim.raw-value-mask-type = bytes corim.tagged-masked-raw-value = #6.563([ value: bytes, mask: bytes, ]) corim.reference-triple-record = [ ref-env: corim.environment-map, ref-claims: [+ corim.measurement-map], ] corim.stateful-environment-record = [ environment: corim.environment-map, claims-list: [+ corim.measurement-map], ] corim.svn-type = uint corim.svn = corim.svn-type corim.min-svn = corim.svn-type corim.tagged-svn = #6.552(corim.svn) corim.tagged-min-svn = #6.553(corim.min-svn) corim.svn-type-choice = corim.svn / corim.tagged-svn / corim.tagged-\ min-svn corim.$tag-id-type-choice /= tstr / corim.uuid-type corim.tag-identity-map = { &(tag-id: 0) => corim.$tag-id-type-choice, ? &(tag-version: 1) => corim.tag-version-type, } corim.$tag-rel-type-choice /= &(supplements: 0) / &(replaces: 1) corim.tag-version-type = uint .default 0 corim.tagged-bytes = #6.560(bytes) corim.triples-map = corim.non-empty<{ ? &(reference-triples: 0) => [+ corim.reference-triple-record], ? &(endorsed-triples: 1) => [+ corim.endorsed-triple-record], ? &(identity-triples: 2) => [+ corim.identity-triple-record], ? &(attest-key-triples: 3) => [+ corim.attest-key-triple-record], ? &(dependency-triples: 4) => [+ corim.domain-dependency-triple-\ record], ? &(membership-triples: 5) => [+ corim.domain-membership-triple-\ record], ? &(coswid-triples: 6) => [+ corim.coswid-triple-record], ? &(conditional-endorsement-series-triples: 8) => [+ corim.\ conditional-endorsement-series-triple-record], ? &(conditional-endorsement-triples: 10) => [+ corim.conditional\ -endorsement-triple-record], * $$triples-map-extension, }> corim.ueid-type = bytes .size (7 .. 33) corim.tagged-ueid-type = #6.550(corim.ueid-type) corim.uuid-type = bytes .size 16 corim.tagged-uuid-type = #6.37(corim.uuid-type) corim.version-map = { &(version: 0) => text, ? &(version-scheme: 1) => corim.$version-scheme, } corim.digest = [ alg: int / text, val: bytes, ] corim.digests-type = [+ corim.digest] corim.integrity-register-id-type-choice = uint / text corim.integrity-registers = {+ corim.integrity-register-id-type-\ choice => corim.digests-type} corim.concise-swid-tag = { corim.tag-id => text / bstr .size 16, corim.tag-version => integer, ? corim.corpus => bool, ? corim.patch => bool, ? corim.supplemental => bool, corim.software-name => text, ? corim.software-version => text, ? corim.version-scheme => corim.$version-scheme, ? corim.media => text, ? corim.software-meta => corim.one-or-more, corim.entity => corim.one-or-more, ? corim.link => corim.one-or-more, ? corim.payload-or-evidence, * $$coswid-extension, corim.global-attributes, } corim.payload-or-evidence //= (corim.payload => corim.payload-entry \ // corim.evidence => corim.evidence-entry) corim.any-uri = uri corim.label = text / int corim.$version-scheme /= corim.multipartnumeric / corim.\ multipartnumeric-suffix / corim.alphanumeric / corim.decimal / corim\ .semver / int / text corim.any-attribute = (corim.label => corim.one-or-more / \ corim.one-or-more) corim.one-or-more = T / [2*T] corim.global-attributes = ( ? corim.lang => text, * corim.any-attribute, ) corim.hash-entry = [ hash-alg-id: int, hash-value: bytes, ] corim.entity-entry = { corim.entity-name => text, ? corim.reg-id => corim.any-uri, corim.role => corim.one-or-more, ? corim.thumbprint => corim.hash-entry, * $$entity-extension, corim.global-attributes, } corim.$role /= corim.tag-creator / corim.software-creator / corim.\ aggregator / corim.distributor / corim.licensor / corim.maintainer \ / int / text corim.link-entry = { ? corim.artifact => text, corim.href => corim.any-uri, ? corim.media => text, ? corim.ownership => corim.$ownership, corim.rel => corim.$rel, ? corim.media-type => text, ? corim.use => corim.$use, * $$link-extension, corim.global-attributes, } corim.$ownership /= corim.shared / corim.private / corim.abandon / \ int / text corim.$rel /= corim.ancestor / corim.component / corim.feature / \ corim.installationmedia / corim.packageinstaller / corim.parent / \ corim.patches / corim.requires / corim.see-also / corim.supersedes \ / corim.supplemental / -256 .. 64436 / text corim.$use /= corim.optional / corim.required / corim.recommended / \ int / text corim.software-meta-entry = { ? corim.activation-status => text, ? corim.channel-type => text, ? corim.colloquial-version => text, ? corim.description => text, ? corim.edition => text, ? corim.entitlement-data-required => bool, ? corim.entitlement-key => text, ? corim.generator => text / bstr .size 16, ? corim.persistent-id => text, ? corim.product => text, ? corim.product-family => text, ? corim.revision => text, ? corim.summary => text, ? corim.unspsc-code => text, ? corim.unspsc-version => text, * $$software-meta-extension, corim.global-attributes, } corim.path-elements-group = ( ? corim.directory => corim.one-or-more, ? corim.file => corim.one-or-more, ) corim.resource-collection = ( corim.path-elements-group, ? corim.process => corim.one-or-more, ? corim.resource => corim.one-or-more, * $$resource-collection-extension, ) corim.file-entry = { corim.filesystem-item, ? corim.size => uint, ? corim.file-version => text, ? corim.hash => corim.hash-entry, * $$file-extension, corim.global-attributes, } corim.directory-entry = { corim.filesystem-item, ? corim.path-elements => {corim.path-elements-group}, * $$directory-extension, corim.global-attributes, } corim.process-entry = { corim.process-name => text, ? corim.pid => integer, * $$process-extension, corim.global-attributes, } corim.resource-entry = { corim.type => text, * $$resource-extension, corim.global-attributes, } corim.filesystem-item = ( ? corim.key => bool, ? corim.location => text, corim.fs-name => text, ? corim.root => text, ) corim.payload-entry = { corim.resource-collection, * $$payload-extension, corim.global-attributes, } corim.evidence-entry = { corim.resource-collection, ? corim.date => corim.integer-time, ? corim.device-id => text, ? corim.location => text, * $$evidence-extension, corim.global-attributes, } corim.integer-time = #6.1(int) corim.tag-id = 0 corim.software-name = 1 corim.entity = 2 corim.evidence = 3 corim.link = 4 corim.software-meta = 5 corim.payload = 6 corim.hash = 7 corim.corpus = 8 corim.patch = 9 corim.media = 10 corim.supplemental = 11 corim.tag-version = 12 corim.software-version = 13 corim.version-scheme = 14 corim.lang = 15 corim.directory = 16 corim.file = 17 corim.process = 18 corim.resource = 19 corim.size = 20 corim.file-version = 21 corim.key = 22 corim.location = 23 corim.fs-name = 24 corim.root = 25 corim.path-elements = 26 corim.process-name = 27 corim.pid = 28 corim.type = 29 corim.entity-name = 31 corim.reg-id = 32 corim.role = 33 corim.thumbprint = 34 corim.date = 35 corim.device-id = 36 corim.artifact = 37 corim.href = 38 corim.ownership = 39 corim.rel = 40 corim.media-type = 41 corim.use = 42 corim.activation-status = 43 corim.channel-type = 44 corim.colloquial-version = 45 corim.description = 46 corim.edition = 47 corim.entitlement-data-required = 48 corim.entitlement-key = 49 corim.generator = 50 corim.persistent-id = 51 corim.product = 52 corim.product-family = 53 corim.revision = 54 corim.summary = 55 corim.unspsc-code = 56 corim.unspsc-version = 57 corim.multipartnumeric = 1 corim.multipartnumeric-suffix = 2 corim.alphanumeric = 3 corim.decimal = 4 corim.semver = 16384 corim.tag-creator = 1 corim.software-creator = 2 corim.aggregator = 3 corim.distributor = 4 corim.licensor = 5 corim.maintainer = 6 corim.abandon = 1 corim.private = 2 corim.shared = 3 corim.ancestor = 1 corim.component = 2 corim.feature = 3 corim.installationmedia = 4 corim.packageinstaller = 5 corim.parent = 6 corim.patches = 7 corim.requires = 8 corim.see-also = 9 corim.supersedes = 10 corim.optional = 1 corim.required = 2 corim.recommended = 3 coswid.tag-id = 0 ]]>

API Discovery Data Model version, capabilities-label => [+ capability], api-endpoints-label => {+ tstr => tstr}, ? result-verification-key-label => eat.JC, } version-label = eat.JC<"version", 1> capabilities-label = eat.JC<"capabilities", 2> api-endpoints-label = eat.JC<"api-endpoints", 3> result-verification-key-label = eat.JC<"result-verification-key", 4> version = tstr capability = { media-type-label => cmw.media-type, artifact-support-label => artifact-support, } media-type-label = eat.JC<"media-type", 1> artifact-support-label = eat.JC<"artifact-support", 2> non-empty-array = M .and ([+ any]) artifact-support = non-empty-array<[ ? "source", ? "collected", ? "rims", ]> cmw.start = cmw.cmw cmw.cmw = cmw.json-cmw / cmw.cbor-cmw cmw.json-cmw = cmw.json-record / cmw.json-collection cmw.cbor-cmw = cmw.cbor-record / cmw.cbor-collection / cmw.$cbor-tag cmw.json-record = [ type: cmw.media-type, value: cmw.base64url-string, ? ind: uint .bits cmw.cm-type, ] cmw.cbor-record = [ type: cmw.coap-content-format-type / cmw.media-type, value: bytes, ? ind: uint .bits cmw.cm-type, ] cmw.tag-cm-cbor = #6.(bytes .cbor fmt) cmw.tag-cm-data = #6.(bytes) cmw.json-collection = { ? __cmwc_t: ~uri / cmw.oid, + &(label: text) => cmw.json-cmw, } cmw.cbor-collection = { ? __cmwc_t: ~uri / cmw.oid, + &(label: int / text) => cmw.cbor-cmw, } cmw.media-type = text .abnf ("Content-Type" .cat cmw.Content-Type-\ ABNF) cmw.base64url-string = text .regexp "[A-Za-z0-9_-]+" cmw.coap-content-format-type = uint .size 2 cmw.oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" cmw.cm-type = &( reference-values: 0, endorsements: 1, evidence: 2, attestation-results: 3, appraisal-policy: 4, ) cmw.Content-Type-ABNF = ' Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\\" ( SP / VCHAR ) Media-Type-Name = type-name "/" subtype-name type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix DIGIT = %x30-39 ; 0 - 9 POS-DIGIT = %x31-39 ; 1 - 9 ALPHA = %x41-5A / %x61-7A ; A - Z / a - z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ' cmw.$cbor-tag /= cmw.tag-cm-data<1668612070> / cmw.tag-cm-cbor<\ 1668612069, cmw.my-evidence> cmw.my-evidence = {&(eat_nonce: 10) => bytes .size (8 .. 64)} jwk.JWK = { "kty" => tstr, ? "use" => tstr, ? "key_ops" => [* tstr], ? "alg" => tstr, ? "kid" => tstr, ? "x5u" => tstr, ? "x5c" => [* jwk.bytes-b64u], ? "x5t" => jwk.bytes-b64u, ? "x5t#S256" => jwk.bytes-b64u, ? jwk.RSA-Key-Fields, ? jwk.EC-Key-Fields, ? jwk.Symmetric-Key-Fields, } jwk.JWK_Set = [+ jwk.JWK] jwk.RSA-Key-Fields = ( "n" => jwk.bytes-b64u, "e" => jwk.bytes-b64u, ? "d" => jwk.bytes-b64u, ? "p" => jwk.bytes-b64u, ? "q" => jwk.bytes-b64u, ? "dp" => jwk.bytes-b64u, ? "dq" => jwk.bytes-b64u, ? "qi" => jwk.bytes-b64u, ) jwk.EC-Key-Fields = ( "crv" => tstr, "x" => jwk.bytes-b64u, "y" => jwk.bytes-b64u, ? "d" => jwk.bytes-b64u, ) jwk.Symmetric-Key-Fields = ("k" => jwk.bytes-b64u) jwk.bytes-b64u = tstr .b64u bytes eat.JC = eat.JSON-ONLY / eat.CBOR-ONLY eat.JSON-ONLY = J .feature "json" eat.CBOR-ONLY = C .feature "cbor" cose.COSE_KeySet = [+ cose.COSE_Key] cose.COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * cose.label => cose.values, } cose.label = int / tstr cose.values = any ]]>

OpenAPI Schema The OpenAPI schema for the request/response HTTP API described in is provided below. A CoSERV result set has been successfully computed. content: application/coserv+cose: schema: type: string format: binary description: > A CoSERV result set enveloped in a COSE Sign1 object. '400': description: > The request was malformed; e.g., the query was not valid base64url, or the CoSERV data item could not be successfully parsed. content: application/concise-problem-details+cbor: schema: type: string format: binary description: > A CBOR-encoded problem details data item. '406': description: > The server cannot produce a response matching the list of acceptable values defined in the request's 'Accept' header field. In particular, the client may have specified a CoSERV profile that is not understood or serviceable by the server. content: application/concise-problem-details+cbor: schema: type: string format: binary description: > A CBOR-encoded problem details data item. /.well-known/coserv-configuration: get: summary: Retrieve the CoSERV configuration document. responses: '200': description: > The CoSERV configuration document has been successfully retrieved. content: application/coserv-discovery+json: schema: type: string format: binary description: > A JSON-encoded CoSERV configuration document. application/coserv-discovery+cbor: schema: type: string format: binary description: > A CBOR-encoded CoSERV configuration document. ]]>

Locating CoSERV Services CoSERV facilitates the conveyance of Endorsements and Reference Values to the Verifier. The question of how the Verifier locates the CoSERV-enabled service(s) that it needs is beyond the scope of this specification. But it is an important consideration for successful deployments. When aggregators are used (see ), those might also need to locate upstream CoSERV-enabled services. This non-normative appendix sets out some illustrative examples of how services might be located. This list is neither exhaustive nor prescriptive. Deployments are free to use whatever logistics are sensible. Note that the goal here is solely one of bootstrapping. Once the base URI of a suitable service is known, CoSERV provides in-protocol discovery mechanisms, such as the one described in , which cater for the discovery of more specific API endpoints and capabilities.

• Some CoSERV-enabled services might exist in locations that are documented publicly by supply chain actors. A hardware vendor, for example, might document the base URI for the service that endorses their products. In such a case, the location would be prior knowledge within the Verifier or aggregator that needs to consume the service. It could be hard-coded, or made available via a configuration file.
• The locations of suitable services might be carried within the Evidence produced by an Attester. An example would be a specific claim within an attestation report that is reserved and documented for this purpose. As part of the verification process, the Verifier would process this claim and use it to locate the required service(s).
• Services could be located via Manufacturer Usage Description (MUD) files as per .

Acknowledgments The participants in the "Staircase meeting" at FOSDEM '25: Henk Birkholz and Jag Raman are puppeteering in the shadows. The authors would like to thank Carl Wallace, Lucas Pardue, Mark Nottingham for their reviews and suggestions. [^rfced]: RFC Editor:

Contributors Red Hound Software, Inc.

carl@redhoundsoftware.com

Carl contributed in-depth reviews, resulting in many improvements and clarifications across the document.