Concise Selector for Endorsements and Reference Values
draft-howard-rats-coserv-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Paul Howard , Thomas Fossati | ||
| Last updated | 2025-04-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | rats at interim-2025-rats-01 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-howard-rats-coserv-01
Remote ATtestation ProcedureS P. Howard
Internet-Draft Arm
Intended status: Informational T. Fossati
Expires: 10 October 2025 Linaro
8 April 2025
Concise Selector for Endorsements and Reference Values
draft-howard-rats-coserv-01
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://rats-
endorsements-distribution.github.io/draft-howard-rats-coserv/draft-
howard-rats-coserv.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-howard-rats-coserv/.
Discussion of this document takes place on the Remote ATtestation
ProcedureS Working Group mailing list (mailto:rats@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/rats/.
Subscribe at https://www.ietf.org/mailman/listinfo/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/rats-endorsements-distribution/draft-howard-rats-
coserv.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Howard & Fossati Expires 10 October 2025 [Page 1]
Internet-Draft CoSERV April 2025
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Requirements Language . . . . . . . . . . 4
2. CoSERV Information Model . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Result Sets . . . . . . . . . . . . . . . . . . . . . . . 5
3. CoSERV Data Model . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Common Data Types . . . . . . . . . . . . . . . . . . . . 6
3.2. Profile . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Query Structure . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Artifact Type . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Environment Selector . . . . . . . . . . . . . . . . 8
3.4. Result Set Structure . . . . . . . . . . . . . . . . . . 9
3.5. Encoding Requirements . . . . . . . . . . . . . . . . . . 9
3.6. Cryptographic Binding Between Query and Result Set . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
5.1. Veraison . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Forming Native Database Queries from CoSERV . . . . . . . 14
Howard & Fossati Expires 10 October 2025 [Page 2]
Internet-Draft CoSERV April 2025
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Media Types Registrations . . . . . . . . . . . . . . . . 14
8.1.1. application/coserv+cbor . . . . . . . . . . . . . . . 15
8.1.2. application/coserv+cose . . . . . . . . . . . . . . . 15
8.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Collated CoSERV CDDL . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. 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 the environment
characteristics of Attesters, such that the relevant artifacts can be
obtained from Endorsers and Reference Value Providers. In turn, the
result format allows those Endorsers and Reference Value Providers to
package the 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. This document does
not define the complete APIs or interaction models for such tools and
services. The scope of this document is limited to the definitions
of the query language and the result set only.
Howard & Fossati Expires 10 October 2025 [Page 3]
Internet-Draft CoSERV April 2025
Both the query language and the result set are designed for
extensibility. This addresses the need for a common baseline format
to optimise for interoperability and software reuse, while
maintaining the flexibility demanded by a dynamic and diverse
ecosystem.
The environment characteristics of Endorsements and Reference Values
are derived from the equivalent concepts in CoRIM
[I-D.ietf-rats-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 [RFC8610]. A CoSERV query can be
serialized in CBOR [STD94] format.
1.1. 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 [RFC2119] [RFC8174] 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 Section 4 of [RFC9334].
This document uses terms and concepts defined by the CoRIM
specification. For a complete glossary, see Section 1.1.1 of
[I-D.ietf-rats-corim].
This document uses the terms _"actual state"_ and _"reference state"_
as defined in Section 2 of [I-D.ietf-rats-endorsements].
The terminology from CBOR [STD94], CDDL [RFC8610] and COSE [STD96]
applies; in particular, CBOR diagnostic notation is defined in
Section 8 of [STD94] and Appendix G of [RFC8610]. Terms and concepts
are always referenced as proper nouns, i.e., with Capital Letters.
2. CoSERV Information Model
2.1. 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
Howard & Fossati Expires 10 October 2025 [Page 4]
Internet-Draft CoSERV April 2025
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 [STD98] and CoAP [RFC7252]. 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.
2.2. Queries
The purpose of a query is to allow the consumer (Verifier) to specify
the artifacts (Endorsements and Reference Values) that it needs.
Consequently, a query corresponds to the environmental
characteristics of one or more Attesters. Such environmental
characteristics are identical to those used in the information model
of CoRIM [I-D.ietf-rats-corim]. In summary, they can include the
following:
* An individual Attester instance.
* A group (identifiable collection) of Attester instances.
* A class of Attester, defined by characteristics such as the vendor
or model, of which there may be an arbitrary number of instances.
To facilitate efficient transactions, a single query can specify
either multiple instances, multiple groups or multiple classes.
2.3. Result Sets
The result set contains the Endorsements and Reference Values that
are needed by the Verifier in order to verify and appraise Evidence
from one or more Attesters.
Howard & Fossati Expires 10 October 2025 [Page 5]
Internet-Draft CoSERV April 2025
3. 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:
coserv = {
&(profile: 0) => profile
&(query: 1) => query
? result-set
}
profile = oid-type / ~uri
3.1. 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 Appendix A.
3.2. 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 Section 4.3.2 of
[I-D.ietf-rats-eat].
3.3. 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:
Howard & Fossati Expires 10 October 2025 [Page 6]
Internet-Draft CoSERV April 2025
query = {
&(artifact-type: 0) => artifact-type
&(environment-selector: 1) => environment-selector-map
}
artifact-type = &(endorsed-values: 0)
/ &(trust-anchors: 1)
/ &(reference-values: 2)
The meanings of these fields are detailed in the following
subsections.
3.3.1. Artifact Type
The artifact-type field is the foremost discriminator of the query.
It is a top-level category selector. Its three permissible values
are trust-anchors (codepoint 1), endorsed-values (codepoint 0) and
reference-values (codepoint 2). These correspond to the following
three categories of endorsement artifact that can be identified in
the RATS architecture:
* *Trust Anchor* (trust-anchors): A trust anchor is as defined in
[RFC6024]. 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 is able to verify the
cryptographic signature.
* *Endorsed Value* (endorsed-values): An endorsed value is as
defined in Section 1.1.1 of [I-D.ietf-rats-corim].
* *Reference Value* (reference-values): A reference value is as
defined in Section 1.1.1 of [I-D.ietf-rats-corim]. 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.
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.
Howard & Fossati Expires 10 October 2025 [Page 7]
Internet-Draft CoSERV April 2025
3.3.2. Environment Selector
The environment selector forms the main body of the query, and its
CDDL is given below:
environment-selector-map = { selector }
selector //= ( &(class: 0) => [ + class-map ] )
selector //= ( &(instance: 1) => [ + $instance-id-type-choice ] )
selector //= ( &(group: 2) => [ + $group-id-type-choice ] )
The 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. There are
three mutually-exclusive methods for defining the environment within
a CoSERV query. 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.
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 (such as a 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
Howard & Fossati Expires 10 October 2025 [Page 8]
Internet-Draft CoSERV April 2025
environment. For example, it would not be possible to query for both
class-level and instance-level artifacts in a single CoSERV
transaction.
3.4. Result Set Structure
The result set structure is given by the following CDDL:
result-set //= ? reference-values
result-set //= ? endorsed-values
result-set //= ? trust-anchors
result-set //= ? $$result-set-extensions
reference-values = (
&(rvt: 10) => [ * reference-triple-record ]
)
endorsed-values = (
&(evt: 20) => [ * endorsed-triple-record ]
&(cet: 21) => [ * conditional-endorsement-triple-record ]
)
trust-anchors = (
&(akt: 30) => [ * attest-key-triple-record ]
&(tas: 31) => [ * cots ]
)
;
; import CoTS
;
cots = "TODO COTS"
3.5. 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 Section 4.2 of [STD94].
Further, CoSERV queries MUST use CBOR definite-length encoding.
Howard & Fossati Expires 10 October 2025 [Page 9]
Internet-Draft CoSERV April 2025
3.6. 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 an end-to-end secure channel without any
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
[STD96]. A signed-coserv is a COSE_Sign1 with the following layout:
signed-coserv = [
protected: bytes .cbor signed-coserv-protected-hdr
unprotected: signed-coserv-unprotected-hdr
payload: bytes .cbor coserv
signature: bytes
]
The payload MUST be the CBOR-encoded CoSERV.
signed-coserv-protected-hdr = {
1 => int ; alg
2 => "application/coserv+cbor" / 10000 ; cty
* cose.label => cose.values
}
signed-coserv-unprotected-hdr = {
* cose.label => cose.values
}
cose.label = int / text
cose.values = any
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.
4. Examples
This section provides some illustrative examples of valid CoSERV
query objects.
Howard & Fossati Expires 10 October 2025 [Page 10]
Internet-Draft CoSERV April 2025
The following example shows a 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.
{
/ 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"
}
]
}
}
}
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.
{
/ 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'8999786556'), / tagged-bytes /
/ vendor / 1: "Example Vendor",
/ model / 2: "Example Model"
},
{
/ class-id / 0:
37(h'31FB5ABF023E4992AA4E95F9C1503BFA') / UUID /
}
]
}
}
}
Howard & Fossati Expires 10 October 2025 [Page 11]
Internet-Draft CoSERV April 2025
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.
{
/ profile / 0: "tag:example.com,2025:cc-platform#1.0.0",
/ query / 1: {
/ artifact-type / 0: 2, / reference-values /
/ environment-selector / 1: {
/ instance / 1: [
550(h'02DEADBEEFDEAD'), / UEID /
560(h'8999786556') / tagged-bytes /
]
}
}
}
5. Implementation Status
// RFC Editor: 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 [RFC7942].
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 [RFC7942], "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".
5.1. Veraison
Responsible Organisation: Veraison (open source project within the
Confidential Computing Consortium).
Howard & Fossati Expires 10 October 2025 [Page 12]
Internet-Draft CoSERV April 2025
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
6. Security Considerations
The CoSERV data type serves an auxiliary function in the RATS
architecture. It does not directly convey Evidence, Endorsements,
Reference Values, Policies or Attestation Results. CoSERV exists
only to facilitate the interactions between the Verifier and the
Endorser or Reference Value Provider roles. Consequently, there are
fewer security considerations for CoSERV, particularly when compared
with data objects such as EAT or CoRIM.
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.
Howard & Fossati Expires 10 October 2025 [Page 13]
Internet-Draft CoSERV April 2025
6.1. 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.
7. 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.
8. IANA Considerations
// RFC Editor: replace "RFCthis" with the RFC number assigned to this
document.
8.1. Media Types Registrations
IANA is requested to add the following media types to the "Media
Types" registry [IANA.media-types].
+=============+=========================+========================+
| Name | Template | Reference |
+=============+=========================+========================+
| coserv+cbor | application/coserv+cbor | Section 3 of RFCthis |
+-------------+-------------------------+------------------------+
| coserv+cose | application/coserv+cose | Section 3.6 of RFCthis |
+-------------+-------------------------+------------------------+
Table 1: CoSERV Media Types
Howard & Fossati Expires 10 October 2025 [Page 14]
Internet-Draft CoSERV April 2025
8.1.1. 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: Section 6 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
8.1.2. 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: Section 6 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
Howard & Fossati Expires 10 October 2025 [Page 15]
Internet-Draft CoSERV April 2025
8.2. 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
[IANA.core-parameters]:
+=========================+================+======+=============+
| Content-Type | Content Coding | ID | Reference |
+=========================+================+======+=============+
| application/coserv+cbor | - | TBD1 | Section 3 |
| | | | of RFCthis |
+-------------------------+----------------+------+-------------+
| application/coserv+cose | - | TBD2 | Section 3.6 |
| | | | of RFCthis |
+-------------------------+----------------+------+-------------+
Table 2: New CoAP Content Formats
If possible, TBD1 and TBD2 should be assigned in the 256..9999 range.
9. References
9.1. Normative References
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-07, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-07>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Howard & Fossati Expires 10 October 2025 [Page 16]
Internet-Draft CoSERV April 2025
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
9.2. Informative References
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[I-D.ietf-rats-endorsements]
Thaler, D., Birkholz, H., and T. Fossati, "RATS
Endorsements", Work in Progress, Internet-Draft, draft-
ietf-rats-endorsements-06, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
endorsements-06>.
Howard & Fossati Expires 10 October 2025 [Page 17]
Internet-Draft CoSERV April 2025
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/rfc/rfc6024>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[STD98] Internet Standard 98,
<https://www.rfc-editor.org/info/std98>.
At the time of writing, this STD comprises the following:
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
Appendix A. Collated CoSERV CDDL
coserv = {
&(profile: 0) => profile
&(query: 1) => query
? result-set
}
profile = oid-type / ~uri
environment-selector-map = { selector }
selector //= ( &(class: 0) => [ + class-map ] )
selector //= ( &(instance: 1) => [ + $instance-id-type-choice ] )
selector //= ( &(group: 2) => [ + $group-id-type-choice ] )
concise-mid-tag = {
? &(language: 0) => text
&(tag-identity: 1) => tag-identity-map
? &(entities: 2) => [ + comid-entity-map ]
? &(linked-tags: 3) => [ + linked-tag-map ]
&(triples: 4) => triples-map
* $$concise-mid-tag-extension
}
Howard & Fossati Expires 10 October 2025 [Page 18]
Internet-Draft CoSERV April 2025
attest-key-triple-record = [
environment: environment-map
key-list: [ + $crypto-key-type-choice ]
? conditions: non-empty< {
? &(mkey: 0) => $measured-element-type-choice,
? &(authorized-by: 1) => [ + $crypto-key-type-choice ]
}>
]
$class-id-type-choice /= tagged-oid-type
$class-id-type-choice /= tagged-uuid-type
$class-id-type-choice /= tagged-bytes
class-map = non-empty<{
? &(class-id: 0) => $class-id-type-choice
? &(vendor: 1) => tstr
? &(model: 2) => tstr
? &(layer: 3) => uint
? &(index: 4) => uint
}>
comid-entity-map =
entity-map<$comid-role-type-choice, $$comid-entity-map-extension>
$comid-role-type-choice /= &(tag-creator: 0)
$comid-role-type-choice /= &(creator: 1)
$comid-role-type-choice /= &(maintainer: 2)
conditional-endorsement-series-triple-record = [
condition: stateful-environment-record
series: [ + conditional-series-record ]
]
conditional-series-record = [
selection: [ + measurement-map]
addition: [ + measurement-map ]
]
COSE_KeySet = [ + COSE_Key ]
COSE_Key = {
1 => tstr / int
? 2 => bstr
? 3 => tstr / int
? 4 => [+ (tstr / int) ]
? 5 => bstr
* cose-label => cose-value
}
Howard & Fossati Expires 10 October 2025 [Page 19]
Internet-Draft CoSERV April 2025
cose-label = int / tstr
cose-value = any
coswid-triple-record = [
environment-map
[ + concise-swid-tag-id ]
]
concise-swid-tag-id = text / bstr .size 16
$crypto-key-type-choice /= tagged-pkix-base64-key-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-path-type
$crypto-key-type-choice /= tagged-cose-key-type
$crypto-key-type-choice /= tagged-thumbprint-type
$crypto-key-type-choice /= tagged-cert-thumbprint-type
$crypto-key-type-choice /= tagged-cert-path-thumbprint-type
$crypto-key-type-choice /= tagged-pkix-asn1der-cert-type
$crypto-key-type-choice /= tagged-bytes
tagged-pkix-base64-key-type = #6.554(tstr)
tagged-pkix-base64-cert-type = #6.555(tstr)
tagged-pkix-base64-cert-path-type = #6.556(tstr)
tagged-thumbprint-type = #6.557(digest)
tagged-cose-key-type = #6.558(COSE_KeySet / COSE_Key)
tagged-cert-thumbprint-type = #6.559(digest)
tagged-cert-path-thumbprint-type = #6.561(digest)
tagged-pkix-asn1der-cert-type = #6.562(bstr)
domain-dependency-triple-record = [
$domain-type-choice
[ + $domain-type-choice ]
]
domain-membership-triple-record = [
$domain-type-choice
[ + environment-map ]
]
conditional-endorsement-triple-record = [
conditions: [ + stateful-environment-record ]
endorsements: [ + endorsed-triple-record ]
]
$domain-type-choice /= uint
$domain-type-choice /= text
$domain-type-choice /= tagged-uuid-type
$domain-type-choice /= tagged-oid-type
Howard & Fossati Expires 10 October 2025 [Page 20]
Internet-Draft CoSERV April 2025
endorsed-triple-record = [
condition: environment-map
endorsement: [ + measurement-map ]
]
entity-map<role-type-choice, extension-socket> = {
&(entity-name: 0) => $entity-name-type-choice
? &(reg-id: 1) => uri
&(role: 2) => [ + role-type-choice ]
* extension-socket
}
$entity-name-type-choice /= text
environment-map = non-empty<{
? &(class: 0) => class-map
? &(instance: 1) => $instance-id-type-choice
? &(group: 2) => $group-id-type-choice
}>
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
}
$group-id-type-choice /= tagged-uuid-type
$group-id-type-choice /= tagged-bytes
identity-triple-record = [
environment: environment-map
key-list: [ + $crypto-key-type-choice ]
? conditions: non-empty<{
? &(mkey: 0) => $measured-element-type-choice,
? &(authorized-by: 1) => [ + $crypto-key-type-choice ]
}>
]
$instance-id-type-choice /= tagged-ueid-type
$instance-id-type-choice /= tagged-uuid-type
Howard & Fossati Expires 10 October 2025 [Page 21]
Internet-Draft CoSERV April 2025
$instance-id-type-choice /= $crypto-key-type-choice
$instance-id-type-choice /= tagged-bytes
ip-addr-type-choice = ip4-addr-type / ip6-addr-type
ip4-addr-type = bytes .size 4
ip6-addr-type = bytes .size 16
raw-int-type-choice = int / tagged-int-range
int-range = [min: int / negative-inf, max: int / positive-inf]
tagged-int-range = #6.564(int-range)
positive-inf = null
negative-inf = null
linked-tag-map = {
&(linked-tag-id: 0) => $tag-id-type-choice
&(tag-rel: 1) => $tag-rel-type-choice
}
mac-addr-type-choice = eui48-addr-type / eui64-addr-type
eui48-addr-type = bytes .size 6
eui64-addr-type = bytes .size 8
$measured-element-type-choice /= tagged-oid-type
$measured-element-type-choice /= tagged-uuid-type
$measured-element-type-choice /= uint
$measured-element-type-choice /= tstr
measurement-map = {
? &(mkey: 0) => $measured-element-type-choice
&(mval: 1) => measurement-values-map
? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
}
measurement-values-map = non-empty<{
? &(version: 0) => version-map
? &(svn: 1) => svn-type-choice
? &(digests: 2) => digests-type
? &(flags: 3) => flags-map
? (
&(raw-value: 4) => $raw-value-type-choice,
? &(raw-value-mask: 5) => raw-value-mask-type
)
? &(mac-addr: 6) => mac-addr-type-choice
? &(ip-addr: 7) => ip-addr-type-choice
? &(serial-number: 8) => text
? &(ueid: 9) => ueid-type
? &(uuid: 10) => uuid-type
? &(name: 11) => text
Howard & Fossati Expires 10 October 2025 [Page 22]
Internet-Draft CoSERV April 2025
? &(cryptokeys: 13) => [ + $crypto-key-type-choice ]
? &(integrity-registers: 14) => integrity-registers
? &(raw-int: 15) => raw-int-type-choice
* $$measurement-values-map-extension
}>
non-empty<M> = (M) .and ({ + any => any })
oid-type = bytes
tagged-oid-type = #6.111(oid-type)
$raw-value-type-choice /= tagged-bytes
$raw-value-type-choice /= tagged-masked-raw-value
raw-value-mask-type = bytes
tagged-masked-raw-value = #6.563([
value: bytes
mask : bytes
])
reference-triple-record = [
ref-env: environment-map
ref-claims: [ + measurement-map ]
]
stateful-environment-record = [
environment: environment-map,
claims-list: [ + measurement-map ]
]
svn-type = uint
svn = svn-type
min-svn = svn-type
tagged-svn = #6.552(svn)
tagged-min-svn = #6.553(min-svn)
svn-type-choice = svn / tagged-svn / tagged-min-svn
$tag-id-type-choice /= tstr
$tag-id-type-choice /= uuid-type
tag-identity-map = {
&(tag-id: 0) => $tag-id-type-choice
? &(tag-version: 1) => tag-version-type
}
$tag-rel-type-choice /= &(supplements: 0)
$tag-rel-type-choice /= &(replaces: 1)
Howard & Fossati Expires 10 October 2025 [Page 23]
Internet-Draft CoSERV April 2025
tag-version-type = uint .default 0
tagged-bytes = #6.560(bytes)
triples-map = non-empty<{
? &(reference-triples: 0) =>
[ + reference-triple-record ]
? &(endorsed-triples: 1) =>
[ + endorsed-triple-record ]
? &(identity-triples: 2) =>
[ + identity-triple-record ]
? &(attest-key-triples: 3) =>
[ + attest-key-triple-record ]
? &(dependency-triples: 4) =>
[ + domain-dependency-triple-record ]
? &(membership-triples: 5) =>
[ + domain-membership-triple-record ]
? &(coswid-triples: 6) =>
[ + coswid-triple-record ]
? &(conditional-endorsement-series-triples: 8) =>
[ + conditional-endorsement-series-triple-record ]
? &(conditional-endorsement-triples: 10) =>
[ + conditional-endorsement-triple-record ]
* $$triples-map-extension
}>
ueid-type = bytes .size (7..33)
tagged-ueid-type = #6.550(ueid-type)
uuid-type = bytes .size 16
tagged-uuid-type = #6.37(uuid-type)
version-map = {
&(version: 0) => text
? &(version-scheme: 1) => $version-scheme
}
digest = [
alg: (int / text),
val: bytes
]
digests-type = [ + digest ]
integrity-register-id-type-choice = uint / text
integrity-registers = {
+ integrity-register-id-type-choice => digests-type
Howard & Fossati Expires 10 October 2025 [Page 24]
Internet-Draft CoSERV April 2025
}
concise-swid-tag = {
tag-id => text / bstr .size 16,
tag-version => integer,
? corpus => bool,
? patch => bool,
? supplemental => bool,
software-name => text,
? software-version => text,
? version-scheme => $version-scheme,
? media => text,
? software-meta => one-or-more<software-meta-entry>,
entity => one-or-more<entity-entry>,
? link => one-or-more<link-entry>,
? payload-or-evidence,
* $$coswid-extension,
global-attributes,
}
payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )
any-uri = uri
label = text / int
$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= int / text
any-attribute = (
label => one-or-more<text> / one-or-more<int>
)
one-or-more<T> = T / [ 2* T ]
global-attributes = (
? lang => text,
* any-attribute,
)
hash-entry = [
hash-alg-id: int,
hash-value: bytes,
]
Howard & Fossati Expires 10 October 2025 [Page 25]
Internet-Draft CoSERV April 2025
entity-entry = {
entity-name => text,
? reg-id => any-uri,
role => one-or-more<$role>,
? thumbprint => hash-entry,
* $$entity-extension,
global-attributes,
}
$role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= maintainer
$role /= int / text
link-entry = {
? artifact => text,
href => any-uri,
? media => text,
? ownership => $ownership,
rel => $rel,
? media-type => text,
? use => $use,
* $$link-extension,
global-attributes,
}
$ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= int / text
$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= supplemental
$rel /= -256..64436 / text
$use /= optional
Howard & Fossati Expires 10 October 2025 [Page 26]
Internet-Draft CoSERV April 2025
$use /= required
$use /= recommended
$use /= int / text
software-meta-entry = {
? activation-status => text,
? channel-type => text,
? colloquial-version => text,
? description => text,
? edition => text,
? entitlement-data-required => bool,
? entitlement-key => text,
? generator => text / bstr .size 16,
? persistent-id => text,
? product => text,
? product-family => text,
? revision => text,
? summary => text,
? unspsc-code => text,
? unspsc-version => text,
* $$software-meta-extension,
global-attributes,
}
path-elements-group = ( ? directory => one-or-more<directory-entry>,
? file => one-or-more<file-entry>,
)
resource-collection = (
path-elements-group,
? process => one-or-more<process-entry>,
? resource => one-or-more<resource-entry>,
* $$resource-collection-extension,
)
file-entry = {
filesystem-item,
? size => uint,
? file-version => text,
? hash => hash-entry,
* $$file-extension,
global-attributes,
}
directory-entry = {
filesystem-item,
? path-elements => { path-elements-group },
* $$directory-extension,
Howard & Fossati Expires 10 October 2025 [Page 27]
Internet-Draft CoSERV April 2025
global-attributes,
}
process-entry = {
process-name => text,
? pid => integer,
* $$process-extension,
global-attributes,
}
resource-entry = {
type => text,
* $$resource-extension,
global-attributes,
}
filesystem-item = (
? key => bool,
? location => text,
fs-name => text,
? root => text,
)
payload-entry = {
resource-collection,
* $$payload-extension,
global-attributes,
}
evidence-entry = {
resource-collection,
? date => integer-time,
? device-id => text,
? location => text,
* $$evidence-extension,
global-attributes,
}
integer-time = #6.1(int)
tag-id = 0
software-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
hash = 7
Howard & Fossati Expires 10 October 2025 [Page 28]
Internet-Draft CoSERV April 2025
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14
lang = 15
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
entity-name = 31
reg-id = 32
role = 33
thumbprint = 34
date = 35
device-id = 36
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42
activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
Howard & Fossati Expires 10 October 2025 [Page 29]
Internet-Draft CoSERV April 2025
unspsc-version = 57
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
maintainer=6
abandon=1
private=2
shared=3
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
optional=1
required=2
recommended=3
Acknowledgments
TODO acknowledge.
Authors' Addresses
Paul Howard
Arm
Email: paul.howard@arm.com
Thomas Fossati
Linaro
Email: Thomas.Fossati@linaro.org
Howard & Fossati Expires 10 October 2025 [Page 30]