# drafts

name: draft-lin-opsec-trustroute-problem-statement
rev: 04
title: Problem Statement and Use Cases of Trustworthiness-based Routing
time: 2024-07-26T07:05:07Z
group_uri: /api/v1/group/group/1027/
expires: 2024-07-27T06:07:09Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.253814+00:00
source: ietf
source_id: 102513
source_url: https://datatracker.ietf.org/doc/draft-lin-opsec-trustroute-problem-statement/
doc_status: active
abstract:
  Currently, network operators are trying to provide fine-granularity
     Service Level Agreement (SLA) guarantee to achieve better Quality of
     Experience (QoE) for end users and engage customers, such as ultra-
     low latency and high reliability service.  However, with increasing
     security threats, differentiated QoE services are insufficient, the
     demands for more differentiated security service are emerging.

     This document explores the requirements for differentiated security
     services and identifies the scenarios for network operators.  To
     provide differentiated security services, possible trustworthiness-
     based routing solution is discussed.

full_text:
  Network Working Group                                             T. Lin
  Internet-Draft                                                     H. Li
  Intended status: Informational                      New H3C Technologies
  Expires: 27 July 2024                                             X. Shi
                                                                    X. Yin
                                                       Tsinghua University
                                                                   W. Chen
                                                 Capital Normal University
                                                                   M. Chen
                                                      New H3C Technologies
                                                           24 January 2024


      Problem Statement and Use Cases of Trustworthiness-based Routing
              draft-lin-opsec-trustroute-problem-statement-04

  Abstract

     Currently, network operators are trying to provide fine-granularity
     Service Level Agreement (SLA) guarantee to achieve better Quality of
     Experience (QoE) for end users and engage customers, such as ultra-
     low latency and high reliability service.  However, with increasing
     security threats, differentiated QoE services are insufficient, the
     demands for more differentiated security service are emerging.

     This document explores the requirements for differentiated security
     services and identifies the scenarios for network operators.  To
     provide differentiated security services, possible trustworthiness-
     based routing solution is discussed.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 27 July 2024.





  Lin, et al.               Expires 27 July 2024                  [Page 1]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


  Copyright Notice

     Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Use Case 1: Customers Require Security Service  . . . . .   3
       3.2.  Use Case 2: Providers Require Secure defense  . . . . . .   4
     4.  Solution Discussions  . . . . . . . . . . . . . . . . . . . .   5
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     For the traditional best effort service provided by IP networks,
     routing is optimized for a single arbitrary metric, e.g.  IGP cost in
     OSPF and IS-IS.  To support differentiated services, additional
     routing metrics are used, such as bandwidth, jitter and delay.
     However, security metrics and methods of corresponding treatment are
     seldom taken into considerations.













  Lin, et al.               Expires 27 July 2024                  [Page 2]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


     Customers may request the network to transfer their traffic flows
     with different security guarantees.  Or the provider may classify
     traffic flows into different classes by security-related features.
     These traffic flows of different security service classes are
     expected to be transmitted by different sets of nodes, because the
     trustworthiness of different nodes is possibly not the same.  The
     traffic flows which have higher security requests are expected to be
     transmitted by the nodes with higher trustworthiness.
     Trustworthiness is used as a security metric to evaluate the
     qualification of network elements for differentiated security
     services.

     This document describes the requirements and use cases of
     trustworthiness-based routing.

  2.  Terminology

     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.

     Trustworthiness: The attribute of a network element used to evaluate
     its qualification for security services.

  3.  Problem Statement

     With more and more security incidents occur repeatedly, security
     continues to be an increasingly important common concern for network
     users and network operators.  Good connectivity is insufficient,
     higher and higher requirements for network security are emerging.
     From different perspectives of operators and end users, there will be
     different needs.  On the one hand, end users require network
     operators to ensure network security, on the other hand, network
     operators need to prevent the intrusion and attack from malicious
     users.  Two following use cases are described:

  3.1.  Use Case 1: Customers Require Security Service

     From the perspective of end users, different users may have different
     security level requirements.  Some users are sensitive to security
     and would like the network path given by the operator to have higher
     security.  The network path is composed by many network forwarding
     devices, and the trustworthiness of each device affects the
     trustworthiness of the whole path.  These network forwarding devices
     come from different vendors, have different security capabilities,
     and may have different security status at a certain time.  Therefore,



  Lin, et al.               Expires 27 July 2024                  [Page 3]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


     operators need to evaluate the trustworthiness of network forwarding
     devices, and choose different security level paths for users with
     different security requirements.

                     +--------+    ##########    +--------+
     Customer 1 --+--| node 1 |----# node 2 #----| node 3 |--- App Server
                  |  +--------+    ##########    +--------+
     Customer 2 --+       |             |             |
                          |             |             |
                     +--------+    +--------+    +--------+
                     | node 4 |----| node 5 |----| node 6 |
                     +--------+    +--------+    +--------+

     In the above network, node 1, node 3, node 4, node 5 and node 6 have
     advanced anti-hacker modules, but node 2 does not have such module.
     Two customers at node 1 both need to visit the application server at
     node 3.  Customer 1 requests normal service.  Customer 2 needs to
     transmit confidential information and requests the network to provide
     secure service.

     For the packets from Customer 1, the shortest path <node 1, node 2,
     node 3> is used.  For the packets from Customer 2, the path only
     contains the nodes with advanced anti-hacker modules, which can
     reduce the risk of manipulation or disclosure.  Therefore, node 2 is
     excluded and the best path is <node 1, node 4, node 5, node 6, node
     3>.

  3.2.  Use Case 2: Providers Require Secure defense

     For network operators, different users have different levels of
     trustworthiness.  Most users are normal and harmless, but there are
     also a small number of users suspected of threatening network
     security.  Therefore, for users with threats, operators may consider
     choosing paths with different security levels.

     Traffic Flow 1
     <Src A, Dest B>-+   +--------+    ##########    +--------+  +- Addr B
                     +-->| node 1 |----# node 2 #----| node 3 |--+
     Traffic Flow 2 -+   +--------+    ##########    +--------+  +- Addr D
     <Src C, Dest D>          |             |             |
                              |             |             |
                         +--------+    +--------+    +--------+
                         | node 4 |----| node 5 |----| node 6 |
                         +--------+    +--------+    +--------+

     In the above network, node 1, node 3, node 4, node 5 and node 6 have
     tracing modules which can record attacking packets, but node 2 does
     not have such module.  Two traffic flows enter the network at node 1



  Lin, et al.               Expires 27 July 2024                  [Page 4]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


     and need to be transmitted to node 3.  A and B are authenticated
     addresses, but C or D is not.  The traffic flow which comes from an
     authenticated address and goes to another authenticated address is
     classified by the provider as a credible flow.  Therefore, Traffic
     Flow 1 is classified as credible, and Traffic Flow 2 is classified as
     incredible.  For Traffic Flow 1, the shortest path <node 1, node 2,
     node 3> is used.  For Traffic Flow 2, the packets are transmitted by
     the nodes with tracing modules.  If there are attacking packets in
     Traffic Flow 2, these packets will be recorded and may be analyzed to
     trace the attacker.  Therefore, node 2 is excluded and the best path
     is <node 1, node 4, node 5, node 6, node 3>.

  4.  Solution Discussions

     To provide differentiated security services, specific traffic flows
     should be identified by the network.  For example, the IPv4 TOS
     field, the IPv6 Traffic Class field, or the 5-tuple in the IP and
     transport protocol header of a packet can be used to determine its
     security service class.

     For the traditional best effort service, routing is optimized for a
     single arbitrary metric, e.g.  IGP cost in OSPF and IS-IS.  To
     support differentiated services, additional routing metrics are used,
     such as bandwidth, jitter and delay.

     Trustworthiness is an attribute of a network element which is used as
     a security metric to evaluate its qualification for differentiated
     security services.  Trustworthiness attributes may be taken into
     consideration of device capability, administration authority,
     security protocol, etc.

     When computing paths for differentiated security services,
     trustworthiness attributes are added into the constraints.  Then
     particular traffic flows are steered into these paths.  There are
     several existing technologies that can steer traffic over a path that
     is computed using different constraints instead of the shortest IGP
     path.  They may be extended to implement trustworthiness-based
     routing.  For example, Segment Routing Policy, as defined in
     [RFC9256], enables the instantiation of an ordered list of segments
     on a node for implementing a source routing policy with a specific
     intent for traffic steering from that node.  For another example,
     Flexible Algorithm, as defined in [RFC9350], provides a mechanism for
     IGP to compute constraint-based paths under a combination of
     calculation-type, metric-type, and constraints.  Other technologies,
     such as multi-topology routing, may also be candidates.  Because of
     the flexibility of these technologies, they can adapt to different
     perspectives and needs from end users and network operators.




  Lin, et al.               Expires 27 July 2024                  [Page 5]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


  5.  Security Considerations

     TBD.

  6.  IANA Considerations

     No IANA action is required so far.

  7.  Contributors

     In addition to the authors listed on the front page, the following
     co-authors have also contributed to this document:

     Xiangqing Chang
     New H3C Technologies

     Email: chang.xiangqing@h3c.com

  8.  References

  8.1.  Normative References

     [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/info/rfc2119>.

     [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/info/rfc8174>.

  8.2.  Informative References

     [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
                A., and P. Mattes, "Segment Routing Policy Architecture",
                RFC 9256, DOI 10.17487/RFC9256, July 2022,
                <https://www.rfc-editor.org/info/rfc9256>.

     [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
                and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
                DOI 10.17487/RFC9350, February 2023,
                <https://www.rfc-editor.org/info/rfc9350>.

  Authors' Addresses

     Tao Lin
     New H3C Technologies
     Email: lintao@h3c.com



  Lin, et al.               Expires 27 July 2024                  [Page 6]


  Internet-Draft  Trustworthiness Routing Problem Statemen    January 2024


     Hao Li
     New H3C Technologies
     Email: lihao@h3c.com


     Xingang Shi
     Tsinghua University
     Email: shixg@cernet.edu.cn


     Xia Yin
     Tsinghua University
     Email: yxia@tsinghua.edu.cn


     Wenlong Chen
     Capital Normal University
     Email: chenwenlong@cnu.edu.cn


     Mengxiao Chen
     New H3C Technologies
     Email: chen.mengxiao@h3c.com




























  Lin, et al.               Expires 27 July 2024                  [Page 7]


name: draft-wiethuechter-drip-det-moc
rev: 02
title: Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness
time: 2025-07-07T23:45:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T23:45:10Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.258107+00:00
source: ietf
source_id: 140868
source_url: https://datatracker.ietf.org/doc/draft-wiethuechter-drip-det-moc/
doc_status: active
abstract:
  This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

full_text:
  drip Working Group                                       A. Wiethuechter
  Internet-Draft                                        AX Enterprize, LLC
  Intended status: Standards Track                             7 July 2025
  Expires: 8 January 2026


    Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain
                                 Awareness
                     draft-wiethuechter-drip-det-moc-02

  Abstract

     This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 8 January 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.










  Wiethuechter             Expires 8 January 2026                 [Page 1]


  Internet-Draft                   det-moc                       July 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Additional Definitions  . . . . . . . . . . . . . . . . .   4
     3.  Interactions & Responsibilities . . . . . . . . . . . . . . .   5
       3.1.  UAS Observers . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Registrants . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  UAS Manufacturers . . . . . . . . . . . . . . . . . . . .   6
       3.4.  HDA Operators . . . . . . . . . . . . . . . . . . . . . .   6
       3.5.  RAA Operators . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Requirements for DIME Operation . . . . . . . . . . . . . . .   8
       4.1.  Query . . . . . . . . . . . . . . . . . . . . . . . . . .   8
         4.1.1.  Public Information Registries . . . . . . . . . . . .   8
         4.1.2.  Private Information Registries  . . . . . . . . . . .   8
       4.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Compliance Testing  . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Registration Interface  . . . . . . . . . . . . . . . . .  10
       5.2.  Public Query Interface  . . . . . . . . . . . . . . . . .  10
       5.3.  Private Query Interface . . . . . . . . . . . . . . . . .  10
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.  Privacy & Transparency Considerations . . . . . . . . . . . .  11
       8.1.  DETs as Session ID and Authentication Key ID  . . . . . .  11
       8.2.  Selective Encryption  . . . . . . . . . . . . . . . . . .  12
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
     Appendix A.  HID Abbreviation . . . . . . . . . . . . . . . . . .  15
     Appendix B.  Compliance Submission Forms  . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction






  Wiethuechter             Expires 8 January 2026                 [Page 2]


  Internet-Draft                   det-moc                       July 2025


  1.1.  Purpose

     This document provides to stakeholders in a National Airspace System
     (NAS), such as a Civil Aviation Authority (CAA) and its consituients,
     a point of entry into a set of relevant standards.  These standards
     provide guidance to enable trustworthy Air Domain Awareness (ADA)
     primarily via cooperative techologies.  Such technologies can
     include, but are not limited to, Unmanned Aircraft Systems (UAS)
     Remote Identification (RID), UAS Traffic Management (UTM) and
     Advanced Air Mobility (AAM).  This document specifies an interopable
     manner of achieving the stated objectives in an international
     context.

     A CAA MAY override any technical specification in this document but
     MUST, if claiming compliance with this document, provide the reason
     and an alternative specification satisfying the same objective.

  1.2.  Background

     [RFC9153] provides comprehensive background on the UAS RID use-case
     and the UTM/AAM context.

     Trustworthiness revolves around identification and authentication.
     [RFC9374] defines the Drone Remote Identification Protocol (DRIP)
     Entity Tag (DET), a trustable identifier backed by asymmetic
     cryptography.  [RFC9575] standardizes authentication of DETs and
     associated information using strong cryptography suited for
     constrained mobile wireless links (typical of Broadcast RID).
     Broadcast and Network RID are defined by ASTM [F3411] which
     designates the International Civil Aviation Organization (ICAO) to
     maintain codepoints for Specific Session ID Types and Specific
     Authentication Methods (SAMs) [RID-NUMBER-REGISTRATION].  ICAO
     includes DETs as a Specific Session ID Type and lists the four DRIP
     SAMs.

     [DET-REGISTRATION] defines a method for a registrant (typically a UAS
     Operator or UAS) to propose their inclusion into the identifier
     heirarchy.  The registry system, made up of DRIP Identity Management
     Entities (DIMEs), ensures uniqueness within the heirarchy, endorses
     inclusion through X.509 certificates, and provides access to public
     and private information associated with a DET registration.  Public
     information is served using the Domain Name System (DNS) and is
     specified in [DET-DNS].  Private information is served using the
     Registration Data Access Protocol (RDAP, TODO: ref) and protected
     through policy based differentiated access [DET-DIFF-ACCESS].






  Wiethuechter             Expires 8 January 2026                 [Page 3]


  Internet-Draft                   det-moc                       July 2025


     This document specifies the fundamental registration processes and
     interactions surrounding the Private Information Registry function
     defined in the DRIP Architecture ([RFC9434]).

  1.3.  Scope

     This document assumes that participanting entities are in compliance
     with relevant existing UAS standards such as ASTM [F3411], [F3548]
     and TODO-REF: ICAO-TFP.

     This document governs use of a DET in the following cases:

     *  An entity that uses a Session ID (some participating entities,
        e.g. HDAs, may not need Session IDs), MUST use a DET for that
        Session ID.

     *  An entity that participates in DRIP protocol interactions (even if
        not needing a Session ID), MUST use a DET for the DRIP public key
        ID in those interactions.

     *  An entity that requires a strongly cryptographically verifiable IP
        compatible identifier, MAY use a DET for any other legal purpose.

     *  An entity SHOULD NOT use a DET as a locator in physical or logical
        space (e.g. as a globally routable IPv6 address outside of an
        overlay network), as deconflation is intended, see [RFC9063].

     The archetypal case is a UAS for which the DET serves as both the UAS
     ID (first case above) and the Authentication Key ID (second case).

  2.  Terminology

     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.

  2.1.  Additional Definitions

     This document makes use of terms (PII, USS, etc.) defined in
     [RFC9153], [RFC9434] and [RFC9374].  For convenience of the reader,
     some of the major definitions are restated here.

     DRIP Identity Management Entity (DIME):  Originally defined in
        [RFC9434] and expanded technically in [DET-DNS].  An entity
        providing registrar and registry services specifically for DETs.




  Wiethuechter             Expires 8 January 2026                 [Page 4]


  Internet-Draft                   det-moc                       July 2025


  3.  Interactions & Responsibilities

     This section outlines the various players in the ecosystem.  For
     each, it outlines relevant motivations for using DRIP, as well as the
     interactions and responsibilities they have in doing so.

  3.1.  UAS Observers

     An Observer has many motivations for detecting Broadcast RID.
     Regardless of their motivation the authenticity of the data presented
     is important for them to make decisions on their next actions.  This
     is accomplished by the use of Authentication of the Broadcast RID,
     something DRIP provides.  Observers also may need additional
     information, beyond what is sent over Broadcast RID.  While the use
     of a Session ID provides a level of privacy, the use of DRIP allows
     this privacy while also enabling authorized queries for additional
     data.

     An Observer device is expected to be able to process Broadcast RID
     messages per [F3411] in accordance with CAA regulations (such as
     [F3586]) as follows:

     In order to satisfy CAA regulatory requirements as per corresponding
     Means of Compliance (e.g. [F3586] for the US) something something
     MUST comply with applicable portions of [F3411] and process as per
     [RFC9575] the following messages:

     1.  The UAS ID SHOULD be displayed either in the style of an IPv6
         address per [RFC5952] or as described in Appendix A for the
         following ASTM [F3411] Message Types:

         *  Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific
            Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag).

     2.  Appendix A of [RFC9575] is RECOMMENDED for visualization of the
         trustworthiness assessment.  Observer devices MUST follow the
         requirements of Section 6.4.2 of [RFC9575] for the following ASTM
         [F3411] Message Types:

         *  Authentication Messages (Message Type 0x2), Authentication
            Type 0x5 (Specific Authentication Method (SAM)), SAM Types
            0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest)
            and optionally 0x04 (DRIP Frame).

  3.2.  Registrants

     Typically UAS Operators.




  Wiethuechter             Expires 8 January 2026                 [Page 5]


  Internet-Draft                   det-moc                       July 2025


     UAS Operators may want to protect the privacy of their details (such
     as Operator Location) and their reputation.  Reputation can be gained
     or lost with observation and reports of behavior backed by
     Authentication.  They MAY decide for which identification purposes
     they will use DETs.  This choice may be constrained by the
     jurisdiction's RID regulations.

        Author: move to Definitions: whether to use DRIP for an
        Authentication Key ID only, Single Use Session ID only, or both.
        The last of these is the natural approach providing the greatest
        benefits and thus the primary focus of this document.

  3.3.  UAS Manufacturers

     Manufacturers typically wish to maintain good reputation of their
     brands and are often driven by market forces.  Such forces include
     requirements and preferences of both UAS Observers and Operators.

     To satisfy CAA requirements, a UA MUST transmit whatever [F3411]
     messages are needed to carry at least the minimal elements of
     information required by the regulator.  In the US, under the current
     FAA RID rule, these are Basic ID, Location/Vector, and System as
     specified in [F3586].  If the content of these messages is to be
     trusted, the UA MUST also sign those messages, using the DRIP Wrapper
     and/or DRIP Manifest methods, as described in [RFC9575].

        Author: add reference to US RID rule

     The UAS MUST provide mechanisms and interfaces to enable DET support
     for UAS Operator selected purposes.  For DRIP this requires at
     minimum the UAS Operator to be able to select DRIP options and start
     the process of generating and registering a DET with a selected HDA.

  3.4.  HDA Operators

     A registry function including Hierarchical Host Identity Tag (HHIT)
     Domain Authority (HDA) is required to support Session IDs that can be
     used by CAAs and other lawfully authorized parties to look up
     essential safety and security information associated with UAS and
     their Operators.

     In the UTM context, it is expected that the HDA function will be
     provided by each UAS Service Supplier (USS).  This can be in-house or
     out-sourced to a service bureau more specialized in cryptographically
     verifiable identifiers usable to access data and systems on networks.
     Outside the UTM context, each Operator must still obtain this
     function from some provider.




  Wiethuechter             Expires 8 January 2026                 [Page 6]


  Internet-Draft                   det-moc                       July 2025


     The HDA function also can support other services related to Session
     IDs.  The DRIP Entity Tag (DET) can act as a Session ID and/or
     Authentication Key ID, thus HDA functionality in this document
     assumes both are being provided to registrants (see Section 8.1 for
     more details).  The use of Authentication is mandated in some (e.g.
     Japan) but not all regions.

     Each DET is tied to a longer term identifier by its HDA.  Typically
     this identifier is expected to be the UAS Serial Number, however a
     CAA MAY choose another long term identifier of significance to them.
     The binding between these two identifiers is typically considered
     private.

     An HDA Operator must fullfil the requirements of their jurisdiction.
     They must also satisfy the desires of UAS Operators.

     The HDA MUST provide, upon successful registration of a DET, the four
     Broadcast Endorsement objects for use in [RFC9575] as defined by
     [DKI].  These are:

     *  Broadcast Endorsement: RAA:A on RAA:A

     *  Broadcast Endorsement: RAA:A on HDA:A

     *  Broadcast Endorsement: HDA:A on HDA:I

     *  Broadcast Endorsement: HDA:I on Registrant

     The HDA must also place certain essential information into the
     Internet Domain Name System (DNS) and maintain that information as
     operations are activated, completed, etc.  All the information to be
     placed into the DNS is public as it is either needed to make the DET
     based systems work or because it is a high-availability replica of
     information transmitted in clear-text via Broadcast RID.  The DNS
     records also MUST point to the private registry in which additional
     information, required by the HDA/USS itself or the CAA, must be
     placed and maintained, for query by authorized parties only.

  3.5.  RAA Operators

     RAAs in this document are scoped to be operated by a State.  Each
     State is allocated four RAAs, and may decide on their usage.

     Each RAA MUST register HDAs within its scope.  Each RAA MUST provide
     both widely supported "long form" X.509 certificates and DRIP-
     specific "short form" endorsements of its HDAs.





  Wiethuechter             Expires 8 January 2026                 [Page 7]


  Internet-Draft                   det-moc                       July 2025


     The RAA MAY provide services to HDAs for verification of data
     pertaining to UAS Operators.  For example an HDA registering a UAS
     Session ID may query the RAA to verify a previously RAA-registered
     UAS Serial Number.

     The RAA Operator MUST obtain valid DNS delegation.  See Section 6 for
     more details.

  4.  Requirements for DIME Operation

     The requirements below apply to both RAA and HDA Operators with a
     focus on how HDA Operators provide registration and related services
     for their clients (i.e. UAS Operators and their UAS).

  4.1.  Query

     A DIME has two query interfaces it MUST support.  One interface is
     used for public information query and another (identified and using
     data found via public queries) is for private information.

  4.1.1.  Public Information Registries

     The information found in these registries has been designated as
     (explicitly or implicitly) public by cognizant authority and/or the
     information owner.  Such information includes public cryptographic
     keys needed for authentication in [RFC9575], static Broadcast RID
     data and trustworthy pointers to additional information.

     These registries are Authoritative Name Servers of DNS.  See
     [DET-DNS] for operational requirements, query mechanism and response
     models.

  4.1.2.  Private Information Registries

     The information found in these registries is considered Personally
     Identifiable Information (PII) and/or is stored for potential future
     audit of registration.

     Private information queries MUST follow [DET-DIFF-ACCESS].  This
     specifies the use of Registration Data Access Protocol (RDAP) data
     models and query formats as the primary query mechanisms.  The
     specific access control policies are to be defined by the CAA.  A CAA
     MAY require additional query mechanisms for their jurisdiction.

     The eXtensible Access Control Markup Language (XACML) MUST be used.
     The policies to be enforced by XACML MUST be provided by the CAA and
     are out of scope for this document.




  Wiethuechter             Expires 8 January 2026                 [Page 8]


  Internet-Draft                   det-moc                       July 2025


  4.2.  Registration

     There are several registration functions essential to achieving the
     purposes to which this document is directed.  Likewise there are
     several viable technical approaches to performing these functions.
     The only approaches fully specified in [DET-REGISTRATION] are the
     Constrained Application Protocol (CoAP) [RFC7252] and/or Concise
     Binary Object Representation (CBOR) Web Tokens (CWT) [RFC8392].

     DRIP does NOT provide protection against incorrect (e.g. fraudulent)
     data entered during registration or asserted subsequently.  DRIP does
     protect against alteration (intentional or unintentional) of data
     subsequent to its assertion by the cryptographic signer.  The signer
     might be the proximate sender (e.g. UA transmitting Broadcast RID) or
     might be an attestor far away and long ago (e.g. root Certificate
     Authority).  It is the duty of the operator of each DIME, or the
     party on whose behalf the DIME is being operated, to validate the
     registration data.  The RAA (e.g. CAA) SHOULD provide services to
     obtain this goal.  The APIs and access controls for such services are
     a matter of national policy and are out of scope for this document.

  5.  Compliance Testing

     It is the responsability of each node in the tree that a child node
     passes functional interop testing prior to issuing a certificate for
     the child node.

        Author: This section is a work in progress.

     All interfaces MUST be tested on valid and invalid data (such as
     being malformed).  When policy is required on an interface all
     defined permutations of the policy MUST be tested.  The policy engine
     MUST be evoked to validate proper decisions and actions are being
     made.  All data returned from an interface MUST be tested to check
     that it conforms with specifications.

     There is a range in the RAA space allocated for experimentation and
     testing purposes.  These can be delegated to parties, for a limited
     period of time at the behest of the RAA Designated Expert, to test
     DIME interoperability (e.g. HDA to RAA interactions) in any of the
     below subsections.  The IANA Considerations section of [DET-DNS]
     contains more information on how these delegations are to be handled.

     Appendix B provides a set of forms to be filled out and submitted as
     part of a CAA compliance process for using DRIP.






  Wiethuechter             Expires 8 January 2026                 [Page 9]


  Internet-Draft                   det-moc                       July 2025


     +-----+           +-----+
     |     |           |     |
     |     o----(1)--->o     |
     |  A  |           |  B  |
     |     o<---(2)----o     |
     |     |           |     |
     +-----+           +-----+

                    Figure 1: System Interface Test Diagram

  5.1.  Registration Interface

     A, B pairs: (registrant, HDA), (HDA, RAA)

     1: Ensure that CoAP endpoints on B can be accessed according to B's
     policy by A.  Ensure that the endpoints conform to the normative
     requirements of [DET-REGISTRATION] Test that B interface properly
     handles valid and malformed data.  Test that B securely generates
     proper artifacts and stores them.

     2: Ensure that the CoAP interactions for (1) properly returns data to
     A from B.  This data MUST include the Broadcast Endorsements, X.509s
     and any other data elements required.

  5.2.  Public Query Interface

     A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that B has a properly configured and publicly accessible
     Authoritative Name Server for its delegated ip6.arpa domain.

     2: Ensure that B returns the valid RRTypes defined in [DET-DNS] to A
     based on an ip6.arpa query via standard DNS methods (i.e. using UDP
     on port 53).  Ensure that the HHIT RRType contains the correct
     Certificate with an URI.

  5.3.  Private Query Interface

     A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that the provide URI from the public query interface points
     to a valid URI.  Ensure that the endpoint on B has proper AAA
     mechanisms as defined in this document and enforces the proper policy
     options.





  Wiethuechter             Expires 8 January 2026                [Page 10]


  Internet-Draft                   det-moc                       July 2025


     2: Ensure that the B endpoint securely returns the data expected
     according to policy (matrix of authorized, valid request,
     unauthorized and invalid request) to A.

  6.  IANA Considerations

     This document requires no new or modified actions by IANA.  It does
     depend on actions IANA has already undertaken to perform in support
     of DRIP [DET-DNS].  It also informs other parties of interactions
     they must have with IANA to achieve the intended purposes of this
     document; e.g. Nation states MUST request IANA delegation of the DNS
     zone under ip6.arpa. corresponding to their allocated RAA values.

  7.  Security Considerations

     The considerations discussed in [RFC9153], [RFC9434], [RFC9374],
     [RFC9575] and [DET-DNS] apply.

     DIMEs use and provide various methods to protect data as described
     below under seven categories: Attestation, Authentication,
     Authorization, Access Control, Attribution, Accounting and Audit.
     DRIP refers to these categories collectively as AAA.  All data,
     handled under DRIP, MUST be protected by AAA.  All private data MUST
     also be protected by strong encryption where permitted by law.  These
     requirements apply to data at rest and in transit in all phases of
     the process, i.e. registration and query.

     Attestation may be mandated by CAAs for devices (such as UA).  Remote
     ATtestation ProcedureS (RATS) [RFC9334] is recommended for DRIP.  The
     specific attestation mechanisms in a given jurisdiction are out of
     scope for this document.

  8.  Privacy & Transparency Considerations

     The considerations discussed in [RFC9153] apply.

  8.1.  DETs as Session ID and Authentication Key ID

     The properties of a DET allow it to be used as a Session ID and/or an
     Authentication Key ID.  There may be scenarios in which Session IDs
     are desired for privacy but Authentication is not; although this may
     reduce transparency and security, a DET MAY be used exclusively as a
     Session ID in such.  There are scenarios in which Authentication is
     desired but Session IDs are not (e.g. where a CAA does not allow
     Session IDs); a DET MAY be used exclusively as an Authentication Key
     ID in such.  In the scenario expected to be most common, both Session
     IDs and Authentication are desired; the same DET SHOULD be used as
     both the Session ID and Authentication Key ID in such.  Consequences



  Wiethuechter             Expires 8 January 2026                [Page 11]


  Internet-Draft                   det-moc                       July 2025


     and operational impact of using different DETs for the Session ID and
     Authentication Key ID are unknown and not covered in this document.

  8.2.  Selective Encryption

     Selective encryption may be allowed in some circumstances.  An HHIT
     may be used in a private lookup to access decryption key material or
     obtain decryption as a service.

     Selective encryption of UAS RID using DRIP is only allowed when the
     DET to be used as the Session ID is issued by an HDA associated with
     a USS and that DET is associated with the corresponding Operational
     Intent in UTM.  This enables the encryption of selected data elements
     in Broadcast RID to provide a layer of privacy for operators (e.g.
     their position) without compromising transparency to entities (e.g.
     public safety / law enforcement personnel) that need to know.

     Selective encryption typically requires network connectivity of the
     Observer to perform the private query to obtain the decryption
     service or key material.  CAAs should consider the expected Observer
     environment and prohibit encryption wherever and whenever Observers
     cannot reasonably be expected to have connectivity.  For example
     selective encryption, per CAA regulations, MAY be allowed in dense
     wireless IP connectivity areas (e.g. urban) but prohibited in poor
     wirelessly covered areas (e.g. rural).

     The issue of Observer network connectivity MAY be mitigated with the
     use of a shared decryption key used by multiple Session IDs under a
     given USS/HDA over a period of time, that is preloaded onto the
     Observer device before connectivity is lost.  For example Observers
     MAY query USS/HDAs for flight volumes in which they are interested to
     preload their decryption key(s) for the Operational Intents/Session
     IDs that day.

  9.  References

  9.1.  Normative References

     [DET-DIFF-ACCESS]
                Wiethuechter, A., "DRIP Entity Tag (DET) Differentiated
                Access using RDAP", Work in Progress, Internet-Draft,
                draft-wiethuechter-drip-det-diff-access-rdap-00, 27
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-wiethuechter-drip-det-diff-access-rdap-00>.







  Wiethuechter             Expires 8 January 2026                [Page 12]


  Internet-Draft                   det-moc                       July 2025


     [DET-DNS]  Wiethuechter, A. and J. Reid, "DRIP Entity Tags in the
                Domain Name System", Work in Progress, Internet-Draft,
                draft-ietf-drip-registries-31, 27 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                registries-31>.

     [DET-REGISTRATION]
                Wiethuechter, A., "DRIP Entity Tag (DET) Registration
                using CoAP & CWTs", Work in Progress, Internet-Draft,
                draft-wiethuechter-drip-det-registration-coap-cwt-00, 27
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-wiethuechter-drip-det-registration-coap-cwt-00>.

     [DKI]      Moskowitz, R. and S. W. Card, "The DRIP DET public Key
                Infrastructure", Work in Progress, Internet-Draft, draft-
                ietf-drip-dki-08, 22 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                dki-08>.

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

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

     [RFC9153]  Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
                Gurtov, "Drone Remote Identification Protocol (DRIP)
                Requirements and Terminology", RFC 9153,
                DOI 10.17487/RFC9153, February 2022,
                <https://www.rfc-editor.org/rfc/rfc9153>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/rfc/rfc9374>.

     [RFC9434]  Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
                and A. Gurtov, "Drone Remote Identification Protocol
                (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
                2023, <https://www.rfc-editor.org/rfc/rfc9434>.








  Wiethuechter             Expires 8 January 2026                [Page 13]


  Internet-Draft                   det-moc                       July 2025


     [RFC9575]  Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
                Entity Tag (DET) Authentication Formats and Protocols for
                Broadcast Remote Identification (RID)", RFC 9575,
                DOI 10.17487/RFC9575, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9575>.

  9.2.  Informative References

     [F3411]    ASTM International, "Standard Specification for Remote ID
                and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
                2022, <https://www.astm.org/f3411-22a.html>.

     [F3548]    ASTM International, "Standard Specification for UAS
                Traffic Management (UTM) UAS Service Supplier (USS)
                Interoperability", ASTM F3548-21, July 2025,
                <https://www.astm.org/f3548-21.html>.

     [F3586]    ASTM International, "Standard Practice for Remote ID Means
                of Compliance to Federal Aviation Administration
                Regulation 14 CFR Part 89", ASTM F3586-22,
                DOI 10.1520/F3586-22, July 2022,
                <https://www.astm.org/f3411-22a.html>.

     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
                Address Text Representation", RFC 5952,
                DOI 10.17487/RFC5952, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5952>.

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

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC9063]  Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
                Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
                <https://www.rfc-editor.org/rfc/rfc9063>.

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






  Wiethuechter             Expires 8 January 2026                [Page 14]


  Internet-Draft                   det-moc                       July 2025


     [RID-NUMBER-REGISTRATION]
                International Civil Aviation Organization, "ICAO Remote ID
                Number Registry", July 2025,
                <https://www.icao.int/airnavigation/IATF/Pages/ASTM-
                Remote-ID.aspx>.

  Appendix A.  HID Abbreviation

     The DET MAY be abbreviated.  This is useful for display application
     with limited screen real-estate as the display of the entire 128-bit
     (32-character in hexadecimal) IPv6 address can be costly.
     Abbreviations SHOULD follow the following format rules.

     Hierarchy Level:  Each hierarchy level (RAA/HDA) is represented by a
        maximum of four alphanumeric characters.  This abbreviation SHOULD
        NOT be a single character in length, for obvious reasons of not
        being very useful.  The decimal representation does fit into the 4
        character restriction but is NOT RECOMMENDED.  The RECOMMENDED
        abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
        code for nations.  This abbreviation MAY be found in DNS under a
        HHIT RRType of the entity or its parents.  If there is no
        abbreviation hint display devices SHOULD use a fixed size four
        character hexadecimal representation of the value.  It is
        RECOMMENDED that display applications specify a default RAA value,
        and only display the RAA abbreviation explicitly when it does not
        match the default.

     Entity Hash:  The entity is represented by a fixed size four
        character hexadecimal string using the last four characters of the
        DET.  If a collision (within the same HID space) on display
        occurs, the four characters SHOULD shift to the left by one
        hexadecimal character until the collision is resolved.  This
        window MUST stay within the last sixteen hexadecimal characters of
        the DET.  The : character found in an IPv6 address string is
        ignored.

     Delimiter:  Each section is delimited by a single character.  This
        can be any whitespace character (except newline and tab) or any
        non-alphanumeric character (period, comma, semicolon, etc.).  It
        is RECOMMENDED that the delimiter is consistent between
        components.  The RECOMMENDED delimiter is the space character.

     For example a DET with the values of RAA 16383 and HDA 1 without any
     abbreviation hint from DNS is represented by the string 3FFF 0001
     xxxx with xxxx representing a entity hash.  If an abbreviation for
     the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
     the DET can be represented with the string of DRIP01 TEST xxxx.




  Wiethuechter             Expires 8 January 2026                [Page 15]


  Internet-Draft                   det-moc                       July 2025


     For an example of the entity hash, let's assume there are two DETs
     with the following hashes in the same HID: 0000:1111:2222:3333 and
     0000:2222:1111:3333.  At first both DETs are represented with the
     same abbreviation: RAA HDA 3333.  One of these DETs is selected by
     the display application to shift the display hash one character to
     avoid the collision resulting in the following two abbreviations: RAA
     HDA 3333 and RAA HDA 1333.

  Appendix B.  Compliance Submission Forms

     TODO

  Author's Address

     Adam Wiethuechter
     AX Enterprize, LLC
     4947 Commercial Drive
     Yorkville, NY 13495
     United States of America
     Email: adam.wiethuechter@axenterprize.com































  Wiethuechter             Expires 8 January 2026                [Page 16]


name: draft-smith-rats-evidence-trans
rev: 01
title: Evidence Transformations
time: 2025-04-04T21:57:22Z
group_uri: /api/v1/group/group/2231/
expires: 2025-09-01T22:51:46Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.263511+00:00
source: ietf
source_id: 143010
source_url: https://datatracker.ietf.org/doc/draft-smith-rats-evidence-trans/
doc_status: active
abstract:
  Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester to decide if continued
     interaction is warrented.  Evidence structures can vary making
     appraisals challenging for Verifiers.  Verifiers need to understand
     Evidence encoding formats and some of the Evidence semantics to
     appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods
     for DiceTcbInfo, concise evidence, and SPDM measurements block
     structures.  These Evidence structures are converted to the CoRIM
     internal representation and follow CoRIM defined appraisal
     procedures.

full_text:
  Remote ATtestation ProcedureS                                 F. D'Amato
  Internet-Draft                                                       AMD
  Intended status: Standards Track                               A. Draper
  Expires: 1 September 2025                                         Altera
                                                                  N. Smith
                                                                     Intel
                                                          28 February 2025


                          Evidence Transformations
                     draft-smith-rats-evidence-trans-01

  Abstract

     Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester to decide if continued
     interaction is warrented.  Evidence structures can vary making
     appraisals challenging for Verifiers.  Verifiers need to understand
     Evidence encoding formats and some of the Evidence semantics to
     appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods
     for DiceTcbInfo, concise evidence, and SPDM measurements block
     structures.  These Evidence structures are converted to the CoRIM
     internal representation and follow CoRIM defined appraisal
     procedures.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 1 September 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  D'Amato, et al.         Expires 1 September 2025                [Page 1]


  Internet-Draft          Evidence Transformations           February 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Verifier Reconciliation . . . . . . . . . . . . . . . . . . .   3
     3.  Transforming DICE Certificate Extension Evidence  . . . . . .   4
       3.1.  DiceTcbInfo Transformation  . . . . . . . . . . . . . . .   4
       3.2.  DiceUeid Transformation . . . . . . . . . . . . . . . . .   7
       3.3.  DiceConceptualMessageWrapper Transformation . . . . . . .   7
       3.4.  Authority field in DICE/SPDM ECTs . . . . . . . . . . . .   8
     4.  Transforming TCG Concise Evidence . . . . . . . . . . . . . .   8
       4.1.  Transforming the ce.evidence-triples  . . . . . . . . . .   9
       4.2.  Transforming the ce.identity-triples  . . . . . . . . . .  10
       4.3.  Transforming the ce.attest-key-triples  . . . . . . . . .  11
     5.  DMTF SPDM Structure Definitons  . . . . . . . . . . . . . . .  11
     6.  Transforming SPDM Measurement Block Digest  . . . . . . . . .  14
     7.  Transforming SPDM Measurement Block Raw Value . . . . . . . .  14
     8.  Transforming SPDM RATS EAT CWT  . . . . . . . . . . . . . . .  14
     9.  Transforming SPDM Evidence  . . . . . . . . . . . . . . . . .  15
     10. Implementation Status . . . . . . . . . . . . . . . . . . . .  16
     11. Security and Privacy Considerations . . . . . . . . . . . . .  16
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       13.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     Remote Attestation Procedures (RATS) [RFC9334] enable Relying Parties
     to assess the trustworthiness of a remote Attester to decide if
     continued interaction is warrented.  Evidence structures can vary
     making appraisals challenging for Verifiers.  Verifiers need to
     understand Evidence encoding formats and some of the Evidence
     semantics to appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods



  D'Amato, et al.         Expires 1 September 2025                [Page 2]


  Internet-Draft          Evidence Transformations           February 2025


     for DiceTcbInfo [DICE.Attest], concise evidence [TCG.CE], and SPDM
     measurements block [SPDM] structures.  These Evidence structures are
     converted to the CoRIM internal representation (Section 2.1
     [I-D.ietf-rats-corim]) and follow CoRIM defined appraisal procedures
     (Section 8 [I-D.ietf-rats-corim]).

  1.1.  Terminology

     This document uses terms and concepts defined by the RATS
     architecture.  For a complete glossary.  See Section 4 of [RFC9334].
     Addintional RATS architecture and terminology is found in
     [I-D.ietf-rats-endorsements].  RATS architecture terms and concepts
     are always referenced as proper nouns, i.e., with Capital Letters.
     Additional terminology from CoRIM [I-D.ietf-rats-corim],
     [DICE.CoRIM], CBOR [STD94], CDDL [RFC8610] and COSE [STD96] may also
     apply.

     In this document, Evidence structures are expressed in their
     respective "external representations".  There are many possible
     Evidence structures including those mentioned above.

     The CoRIM specification defines an "internal representation" for
     Evidence (Section 8.2.1.3 [I-D.ietf-rats-corim]).  This document
     defines mapping operations that convert from an external
     representation to an internal representation.  The conversion steps
     are also known as "transformation".

     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.

  2.  Verifier Reconciliation

     This document assumes the reader is familiar with Verifier
     reconciliation as described in Section 2 of [I-D.ietf-rats-corim].
     It describes how a Verifier should process the CoRIM to enable CoRIM
     authors to convey their intended meaning and how a Verifier
     reconciles its various inputs.  Evidence is one of its inputs.  The
     Verifier is expected to create an internal representation from an
     external representation.  By using an internal representation, the
     Verifier processes Evidence inputs such that they can be appraised
     consistently.

     This document defines format transformations for Evidence in DICE
     [DICE.Attest], SPDM [SPDM], and concise evidence [TCG.CE] formats
     that are transformed into a Verifier's internal representation.  This



  D'Amato, et al.         Expires 1 September 2025                [Page 3]


  Internet-Draft          Evidence Transformations           February 2025


     document uses the CoMID internal representation (Section 8.2.1 of
     [I-D.ietf-rats-corim]) as the transformation target.  Other internal
     representations are possible but out of scope for this document.

  3.  Transforming DICE Certificate Extension Evidence

     This section defines how Evidence from an X.509 certificate [RFC5280]
     containing a DICE certificate extension [DICE.Attest] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the DICE certificate Evidence extensions SHOULD
     implement this transformation.

  3.1.  DiceTcbInfo Transformation

     This section defines transformation methods for DICE certificate
     extensions DiceTcbInfo, DiceMultiTcbInfo, and DiceMultiTcbInfoComp.

     These extensions are identified by the following object identifiers:

     *  tcg-dice-TcbInfo - "2.23.133.5.4.1"

     *  tcg-dice-MultiTcbInfo - "2.23.133.5.4.5"

     *  tcg-dice-MultiTcbInfoComp - "2.23.133.5.4.8"

     Each DiceTcbInfo entry in a MultiTcbInfo is converted to a CoRIM ECT
     (see Section 8.2.1 of [I-D.ietf-rats-corim]) using the transformation
     steps in this section.  Each DiceMultiTcbInfo entry is independent of
     the others such that each is transformed to a separate ECT entry.  A
     list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using
     CoRIM attestation evidence internal representation (see
     Section 8.2.1.1 of [I-D.ietf-rats-corim]).  Each DiceMultiTcbInfoComp
     entry is converted to a DiceMultiTcbInfo entry then processed as a
     DiceMultiTcbInfo.

     For each DiceTcbInfo (DTI) entry in a DiceMultiTcbInfo allocate an
     ECT structure.

     Step 1.  An ae entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The DiceTcbInfo (DTI) entry populates the ae ECT.

     i  The DTI entry populates the ae ECT environment-map





  D'Amato, et al.         Expires 1 September 2025                [Page 4]


  Internet-Draft          Evidence Transformations           February 2025


        *copy*(DTI.type, ECT.environment.environment-map.class-
           map.class-id).  The binary representation of DTI.type MUST be
           equivalent to the binary representation of class-id without the
           CBOR tag.

        *copy*(DTI.vendor, ECT.environment.environment-map.class-
           map.vendor).

        *copy*(DTI.model, ECT.environment.environment-map.class-
           map.model).

        *copy*(DTI.layer, ECT.environment.environment-map.class-
           map.layer).

        *copy*(DTI.index, ECT.environment.environment-map.class-
           map.index).

     ii The DTI entry populates the ae ECT elemenet-list.

        *copy*(DTI.version, ECT.element-list.element-map.measurement-
           values-map.version-map.version).

        *copy*(DTI.svn, ECT.element-list.element-map.measurement-
           values-map.svn).

        *copy*(DTI.vendorInfo, ECT.element-list.element-
           map.measurement-values-map.raw-value).

        Foreach FWID in FWIDLIST: *copy*(DTI.FWID.digest, ECT.element-
           list.element-map.measurement-values-map.digests.digest.val).

        Foreach FWID in FWIDLIST: *copy*(DTI.FWID.hashAlg, ECT.element-
           list.element-map.measurement-values-map.digests.digest.alg).

     iiiThe DTI entry populates the ae ECT elemenet-list.flags.  Foreach
        _f_ in DTI.OperationalFlags and each _m_ in
        DTI.OperationalFlagsMask:

        If _m_.notConfigured = 1 AND _f_.notConfigured = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-configured = FALSE).

        If _m_.notConfigured = 1 AND _f_.notConfigured = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-configured = TRUE).






  D'Amato, et al.         Expires 1 September 2025                [Page 5]


  Internet-Draft          Evidence Transformations           February 2025


        If _m_.notSecure = 1 AND _f_.notSecure = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-secure =
           FALSE).

        If _m_.notSecure = 1 AND _f_.notSecure = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-secure =
           TRUE).

        If _m_.recovery = 1 AND _f_.recovery = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-recovery =
           FALSE).

        If _m_.recovery = 1 AND _f_.recovery = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-recovery =
           TRUE).

        If _m_.debug = 1 AND _f_.debug = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-debug =
           FALSE).

        If _m_.debug = 1 AND _f_.debug = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-debug = TRUE).

        If _m_.notReplayProtected = 1 AND _f_.notReplayProtected = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-replay-protected = FALSE).

        If _m_.notReplayProtected = 1 AND _f_.notReplayProtected = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-replay-protected = TRUE).

        If _m_.notIntegrityProtected = 1 AND _f_.notIntegrityProtected
           = 1; *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-integrity-proteccted = FALSE).

        If _m_.notIntegrityProtected = 1 AND _f_.notIntegrityProtected
           = 0; *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-integrity-proteccted = TRUE).

        If _m_.notRuntimeMeasured = 1 AND _f_.notRuntimeMeasured = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-runtime-meas = FALSE).

        If _m_.notRuntimeMeasured = 1 AND _f_.notRuntimeMeasured = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-runtime-meas = TRUE).





  D'Amato, et al.         Expires 1 September 2025                [Page 6]


  Internet-Draft          Evidence Transformations           February 2025


        If _m_.notImmutable = 1 AND _f_.notImmutable = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-immutable = FALSE).

        If _m_.notImmutable = 1 AND _f_.notImmutable = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-immutable = TRUE).

        If _m_.notTcb = 1 AND _f_.notTcb = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-tcb = FALSE).

        If _m_.notTcb = 1 AND _f_.notTcb = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-tcb = TRUE).

     Step 4.  The ECT.authority field is set up based on the signer of the
              certificate containing DTI as described in Section 3.4.

     The completed ECT is added to the ae list.

  3.2.  DiceUeid Transformation

     This section defines the transformation method for the DiceUeid
     certificate extension.  This extension is identified by the following
     object identifier:

     *  tcg-dice-Ueid - "2.23.133.5.4.4"

     Step 1.  An ae entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The DiceUeid entry populates the ae ECT environment-
              map.instance-id.tagged-ueid-type.  The CBOR tag #6.550 is
              prepended to the DiceUeid OCTET STRING then copied to
              ae.environment-map.instance-id.

     Step 4.  The ECT.authority field is set up based on the signer of the
              certificate containing DiceUeid as described in Section 3.4.

     The completed ECT is added to the ae list.

  3.3.  DiceConceptualMessageWrapper Transformation

     This section defines the transformation method for the
     DiceConceptualMessageWrapper certificate extension.  This extension
     is identified by the following object identifier:

     *  tcg-dice-Ueid - "2.23.133.5.4.9"



  D'Amato, et al.         Expires 1 September 2025                [Page 7]


  Internet-Draft          Evidence Transformations           February 2025


     The DiceConceptualMessageWrapper entry OCTET STRING may contain a
     CBOR array, JSON array, or CBOR tagged value.  If the entry contains
     a CBOR tag value of #6.571 or #6.1668557429, or a Content ID of
     10571, or a Media Type of "application/ce+cbor", the contents are
     transformed according to Section 4.

  3.4.  Authority field in DICE/SPDM ECTs

     The ECT authority field is an array of $crypto-keys-type-choice
     values.

     When adding Evidence to the ACS, the Verifier SHALL add the public
     key representing the signer of that Evidence (for example the DICE
     certificate or SPDM MEASUREMENTS response) to the ECT authority
     field.  The Verifier SHALL add the authority of the signers of each
     certificate in the certificate path of the end-entity signing key to
     the ECT authority list.  Having each authority in a certificate path
     in the ECT authority field lets conditional endorsement conditions
     match multiple authorities or match an authority that is scoped more
     broadly than the immediate signer of the Evidence artifact.

     Each signer authority value MUST be represented using tagged-cose-
     key-type.

  4.  Transforming TCG Concise Evidence

     This section defines how Evidence from TCG [TCG.CE] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the TCG Concise Evidence format SHOULD implement
     this transformation.

     Concise evidence may be recognized by any of the following registered
     types:

         +==========+========+===============+=======================+
         | CBOR tag | C-F ID | TN Tag        | Media Type            |
         +==========+========+===============+=======================+
         | #6.571   | 10571  | #6.1668557429 | "application/ce+cbor" |
         +----------+--------+---------------+-----------------------+

                                    Table 1

     A Concise Evidence entry is converted to a CoRIM ECT (see
     Section 8.2.1 of [I-D.ietf-rats-corim]) using the transformation
     steps in this section.  A list of Evidence ECTs (i.e., ae = [ + ECT])
     is constructed using CoRIM attestation evidence internal
     representation (see Section 8.2.1.1 of [I-D.ietf-rats-corim]).  The



  D'Amato, et al.         Expires 1 September 2025                [Page 8]


  Internet-Draft          Evidence Transformations           February 2025


     Concise Evidence scheme uses CoRIM CDDL definitions to define several
     Evidence representations called _triples_. Cases where Concise
     Evidence CDDL is identical to CoRIM CDDL the transformation logic
     uses the structure names in common.

  4.1.  Transforming the ce.evidence-triples

     The ce.evidence-triples structure is a list of evidence-triple-
     record.  An evidence-triple-record consists of an environment-map and
     a list of measurement-map.  For each evidence-triple-record an ae ECT
     is constructed.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.evidence-triple-record.environment-map,
           ECT.environment.environment-map).

     i  For each ce in CE.[ + measurement-map]; and each ect in ECT.[ +
        element-list]:

        *copy*(ce.mkey, ect.element-map.element-id)

        *copy*(ce.mval, ect.element-map.element-claims`)

     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field as described in Section 3.4.  For
              example, a CE may be wrapped by an EAT token
              [I-D.ietf-rats-eat] or DICE certificate [DICE.Attest].  The
              signer identity MUST be expressed using $crypto-key-type-
              choice.  A profile or other arrangement is used to
              coordinate which $crypto-key-type-choice is used for both
              Evidence and Reference Values.

     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.









  D'Amato, et al.         Expires 1 September 2025                [Page 9]


  Internet-Draft          Evidence Transformations           February 2025


  4.2.  Transforming the ce.identity-triples

     The ce.identity-triples structure is a list of ev-identity-triple-
     record.  An ev-identity-triple-record consists of an environment-map
     and a list of $crypto-key-type-choice.  For each ev-identity-triple-
     record an ae ECT is constructed where the $crypto-key-type-choice
     values are copied as ECT Evidence measurement values.  The ECT
     internal representation accommodates keys as a type of measurement.
     In order for the $crypto-key-type-choice keys to be verified a CoRIM
     identity-triples claim MUST be asserted.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.ce-identity-triple-record.environment-map,
           ECT.environment.environment-map).

        *copy*(_null_, ECT.element-list.element-map.element-id).

     i  For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in
        ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-
        crypto-key ]:

        *copy*(cek, ect.key)

        *set*( &(identity-key: 1), ect.key-type)

     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field.  For example, a CE may be wrapped by an
              EAT token [I-D.ietf-rats-eat] or DICE certificate
              [DICE.Attest].  The signer identity MUST be expressed using
              $crypto-key-type-choice.  A profile or other arrangement is
              used to coordinate which $crypto-key-type-choice is used for
              both Evidence and Reference Values.

     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.








  D'Amato, et al.         Expires 1 September 2025               [Page 10]


  Internet-Draft          Evidence Transformations           February 2025


  4.3.  Transforming the ce.attest-key-triples

     The ce.attest-key-triples structure is a list of ev-attest-key-
     triple-record.  An ev-attest-key-triple-record consists of an
     environment-map and a list of $crypto-key-type-choice.  For each ev-
     attest-key-triple-record an ae ECT is constructed where the $crypto-
     key-type-choice values are copied as ECT Evidence measurement values.
     The ECT internal representation accommodates keys as a type of
     measurement.  In order for the $crypto-key-type-choice keys to be
     verified a CoRIM attest-key-triples claim MUST be asserted.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.ce-attest-key-triple-record.environment-map,
           ECT.environment.environment-map).

        *copy*(_null_, ECT.element-list.element-map.element-id).

     i  For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in
        ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-
        crypto-key ]:

        *copy*(cek, ect.key)

        *set*( &(attest-key: 0), ect.key-type)

     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field.  For example, a CE may be wrapped by an
              EAT token [I-D.ietf-rats-eat] or DICE certificate
              [DICE.Attest].  The signer identity MUST be expressed using
              $crypto-key-type-choice.  A profile or other arrangement is
              used to coordinate which $crypto-key-type-choice is used for
              both Evidence and Reference Values.

     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.

  5.  DMTF SPDM Structure Definitons

     This section defines how a Verifier shall parse a DMTF Measurement
     Block.



  D'Amato, et al.         Expires 1 September 2025               [Page 11]


  Internet-Draft          Evidence Transformations           February 2025


     DMTF Measurement Block Definition:

     *  Byte Offset 0: DMTFSpecMeasurementValueType

        -  Bit 7 = 0b Digest / 1b Raw bit stream

        -  Bit [6:0] = Indicate what is measured

           o  0x0 Immutable Rom

           o  0x1 Mutable FW

           o  0x2 HW Config

           o  0x3 FW config

           o  0x4 Freeform Manifest

           o  0x5 Structured Representation of debug and device mode

           o  0x6 Mutable FW Version Number

           o  0x7 Mutable FW Secure Version Number

           o  0x8 Hash-Extend Measurement (new in SPDM 1.3)

           o  0x9 Informational (new in SPDM 1.3)

           o  0xA Structured Measurement Manifest (new in SPDM 1.3)

     *  Byte Offset 1: DMTFSpecMeasurementValueSize

     *  Byte Offset 3: DMTFSpecMeasurementValue

     Structured Manifest Block Definition (only for >=SPDM 1.3):

     *  Byte Offset 0: Standard Body or Vendor Defined Header (SVH)

     *  Byte Offset 2 + VendorIdLen: Manifest

     Standard Body or Vendor Defined Header (SVH) Definition (only for
     >=SPDM 1.3):

     *  Byte Offset 0: ID

     *  Byte Offset 1: VendorIdLen

     *  Byte Offset 2: VendorId



  D'Amato, et al.         Expires 1 September 2025               [Page 12]


  Internet-Draft          Evidence Transformations           February 2025


     DMTF Header for Concise Evidence Manifest Block:

     If SPDM Version 1.2:

     *  DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)

     *  DMTFSpecMeasurementValueSize = Size of tagged-spdm-toc CBOR Tag

     *  DMTFSpecMeasurementValue = tagged-spdm-toc CBOR Tag

     if SPDM >=Version 1.3:

     *  DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured
        Manifest)

     *  DMTFSpecMeasurementValueSize = Size of Structured Manifest

     *  DMTFSpecMeasurementValue = Structured Manifest

     SVH for Concise Evidence Manifest Block:

     *  ID = 0xA (IANA CBOR)

     *  VendorIdLen = 2

     *  VendorId = 0x570 #6.570(spdm-toc-map)

     Structured Manifest Block Definition for Concise Evidence:

     *  SVH = SVH for Concise Evidence Manifest Block

     *  Manifest = tagged-spdm-toc CBOR Tag Payload

     DMTF Header for CBor Web Token (CWT):

     If SPDM Version 1.2:

     *  DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)

     *  DMTFSpecMeasurementValueSize = Size of CWT

     *  DMTFSpecMeasurementValue = CWT # COSE_Sign1

     if SPDM = Version 1.3:

     *  DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured
        Manifest)




  D'Amato, et al.         Expires 1 September 2025               [Page 13]


  Internet-Draft          Evidence Transformations           February 2025


     *  DMTFSpecMeasurementValueSize = Size of Structured Manifest

     *  DMTFSpecMeasurementValue = Structured Manifest

     SVH for CBor Web Token (CWT):

     *  ID = 0xA (IANA CBOR)

     *  VendorIdLen = 2

     *  VendorId = 0x18 #6.18

     Structured Manifest Block Definition for CBor Web Token (CWT):

     *  SVH = SVH for CBor Web Token (CWT)

     *  Manifest = COSE_Sign1 Payload

  6.  Transforming SPDM Measurement Block Digest

     Step 1.  if DMTFSpecMeasurementValueType is in range [0x80 - 0x83]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.digests).

     Step 2.  if DMTFSpecMeasurementValueType is in range [0x88]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.integrity-
                 registers).

  7.  Transforming SPDM Measurement Block Raw Value

     Step 1.  if DMTFSpecMeasurementValueType is in range [0x7]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.svn).

  8.  Transforming SPDM RATS EAT CWT

     The RATS EAT CWT shall be reported in any of the assigned Measurement
     Blocks range [0xF0 - 0xFC] The Concise Evidence CBOR Tag is
     serialized inside eat-measurements (273) claim ($measurements-body-
     cbor /= bytes .cbor concise-evidence-map) Subsequently the
     transformation steps defined in Section 4.






  D'Amato, et al.         Expires 1 September 2025               [Page 14]


  Internet-Draft          Evidence Transformations           February 2025


  9.  Transforming SPDM Evidence

     This section defines how Evidence from SPDM [SPDM] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the SPDM Evidence format SHOULD implement this
     transformation.  SPDM Responders SHALL support a minimum version of
     1.2

     Theory of Operations:

     *  The SPDM Requestor SHALL retrieve the measurement Manifest at
        Block 0xFD (Manifest Block) and send its payload to the Verifier

        -  The Verifier SHALL decode the payload as a tagged-spdm-toc CBOR
           tag.

        -  The Verifier SHALL extract the tagged-concise-evidence CBOR TAG
           from the tagged-spdm-toc CBOR tag

     Theconcise-evidence has a format that is similar to CoRIM triples-map
     (their semantics follows the matching rules described above).

     *  For every spdm-indirect measurement the Verifier shall ask the
        SPDM Requestor to retrieve the measurement block indicated by the
        index

        -  if the index is in range [0x1 - 0xEF] (refer to #Transforming
           SPDM Measurement Block Digest)

        -  if the index is in range [0xF0 - 0xFC] (refer to #Transforming
           SPDM RATS EAT CWT] )

     The TCG DICE Concise Evidence Binding for SPDM specification [TCG.CE]
     describes a process for converting the SPDM Measurement Block to
     Concise Evidence.  Subsequently the transformation steps defined in
     Section 4.

     The keys provided in the ECT.authority field SHOULD include the key
     which signed the SPDM MEASUREMENTS response carrying the Evidence and
     keys which authorized that key as described in Section 3.4.```










  D'Amato, et al.         Expires 1 September 2025               [Page 15]


  Internet-Draft          Evidence Transformations           February 2025


  10.  Implementation Status

     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 catalogue 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".

  11.  Security and Privacy Considerations

     Evidence appraisal is at the core of any RATS protocol flow,
     mediating all interactions between Attesters and their Relying
     Parties.  The Verifier is effectively part of the Attesters' and
     Relying Parties' trusted computing base (TCB).  Any mistake in the
     appraisal process could have security implications.  For instance, it
     could lead to the subversion of an access control function, which
     creates a chance for privilege escalation.

     Therefore, the Verifier’s code and configuration, especially those of
     the CoRIM processor, are primary security assets that must be built
     and maintained as securely as possible.

     The protection of both the Attester and Verifier systems should be
     considered throughout their entire lifecycle, from design to
     operation.  This includes the following aspects:

     *  Minimizing implementation complexity (see also Section 6.1 of
        [I-D.ietf-rats-endorsements]);

     *  Using memory-safe programming languages;

     *  Using secure defaults;





  D'Amato, et al.         Expires 1 September 2025               [Page 16]


  Internet-Draft          Evidence Transformations           February 2025


     *  Minimizing the attack surface by avoiding unnecessary features
        that could be exploited by attackers;

     *  Applying the principle of least privilege to the system's users;

     *  Minimizing the potential impact of security breaches by
        implementing separation of duties in both the software and
        operational architecture;

     *  Conducting regular, automated audits and reviews of the system,
        such as ensuring that users' privileges are correctly configured
        and that any new code has been audited and approved by independent
        parties;

     *  Failing securely in the event of errors to avoid compromising the
        security of the system.

     The appraisal process should be auditable and reproducible.  The
     integrity of the code and data during execution should be made an
     explicit objective, for example ensuring that the appraisal functions
     are computed in an attestable trusted execution environment (TEE).

     The integrity of public and private key material and the secrecy of
     private key material must be ensured at all times.  This includes key
     material carried in attestation key triples and key material used to
     assert or verify the authority of triples (such as public keys that
     identify trusted supply chain actors).  For more detailed information
     on protecting Trust Anchors, refer to Section 12.4 of [RFC9334].

     The Verifier should use cryptographically protected, mutually
     authenticated secure channels to all its trusted input sources (i.e.,
     Attesters, Endorsers, RVPs, Verifier Owners).  The Attester should
     use cryptographically protected, mutually authenticated secure
     channels to all its trusted input sources (i.e., Verifiers, Relying
     Parties).  These links must reach as deep as possible - possibly
     terminating within the Attesting Environment of an Attester or within
     the appraisal session context of a Verifier - to avoid man-in-the-
     middle attacks.  Also consider minimizing the use of intermediaries:
     each intermediary becomes another party that needs to be trusted and
     therefore factored in the Attesters and Relying Parties' TCBs.  Refer
     to Section 12.2 of [RFC9334] for information on Conceptual Messages
     protection.

  12.  IANA Considerations

     There are no IANA considerations.

  13.  References



  D'Amato, et al.         Expires 1 September 2025               [Page 17]


  Internet-Draft          Evidence Transformations           February 2025


  13.1.  Normative References

     [DICE.Attest]
                Trusted Computing Group (TCG), "DICE Attestation
                Architecture", Version 1.2, Revision 1 , January 2025,
                <https://trustedcomputinggroup.org/wp-content/uploads/
                DICE-Attestation-Architecture-Version-1.2-rc-
                1_9January25.pdf>.

     [DICE.CoRIM]
                Trusted Computing Group (TCG), "DICE Endorsement
                Architecture for Devices", Version 1.0, Revision 0.38 ,
                November 2022, <https://trustedcomputinggroup.org/wp-
                content/uploads/TCG-Endorsement-Architecture-for-Devices-
                V1-R38_pub.pdf>.

     [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-06, 18
                October 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-corim-06>.

     [I-D.ietf-rats-endorsements]
                Thaler, D., Birkholz, H., and T. Fossati, "RATS
                Endorsements", Work in Progress, Internet-Draft, draft-
                ietf-rats-endorsements-05, 8 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                endorsements-05>.

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

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

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

     [SPDM]     Distributed Management Task Force, "Security Protocol and
                Data Model (SPDM)", Version 1.3.0 , May 2023,
                <https://www.dmtf.org/sites/default/files/standards/
                documents/DSP0274_1.3.0.pdf>.



  D'Amato, et al.         Expires 1 September 2025               [Page 18]


  Internet-Draft          Evidence Transformations           February 2025


     [TCG.CE]   Trusted Computing Group, "TCG DICE Concise Evidence
                Binding for SPDM", Version 1.00, Revision 0.54 , January
                2024, <https://trustedcomputinggroup.org/wp-
                content/uploads/TCG-DICE-Concise-Evidence-Binding-for-
                SPDM-Version-1.0-Revision-54_pub.pdf>.

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

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

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

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

  Contributors

     The authors would like to thank the following people for their
     valuable contributions to the specification.

     Henk Birkholz



  D'Amato, et al.         Expires 1 September 2025               [Page 19]


  Internet-Draft          Evidence Transformations           February 2025


     Email: henk.birkholz@ietf.contact

     Yogesh Deshpande

     Email: yogesh.deshpande@arm.com

     Thomas Fossati

     Email: Thomas.Fossati@linaro.org

     Dionna Glaze

     Email: dionnaglaze@google.com

  Acknowledgments

     The authors would like to thank James D.  Beaney, Francisco J.
     Chinchilla, Vincent R.  Scarlata, and Piotr Zmijewski for review
     feedback.

  Authors' Addresses

     Fabrizio D'Amato
     AMD
     Email: fabrizio.damato@amd.com


     Andrew Draper
     Altera
     Email: andrew.draper@altera.com


     Ned Smith
     Intel
     Email: ned.smith@intel.com
















  D'Amato, et al.         Expires 1 September 2025               [Page 20]


name: draft-deshpande-rats-multi-verifier
rev: 04
title: Remote Attestation with Multiple Verifiers
time: 2026-02-07T10:26:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-11T10:26:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.268986+00:00
source: ietf
source_id: 143453
source_url: https://datatracker.ietf.org/doc/draft-deshpande-rats-multi-verifier/
doc_status: active
abstract:
  IETF RATS Architecture, defines the key role of a Verifier.  In a
     complex system, this role needs to be performed by multiple Verfiers
     coordinating together to assess the full trustworthiness of an
     Attester.  This document focuses on various topological patterns for
     a multiple Verifier system.  It only covers the architectural aspects
     introduced by the Multi Verifier concept, which is neutral with
     regard to specific wire formats, encoding, transport mechanisms, or
     processing details.

full_text:
  RATS                                                        Y. Deshpande
  Internet-Draft                                                   Arm Ltd
  Intended status: Informational                                  J. Zhang
  Expires: 11 August 2026                                        H. Labiod
                                       Huawei Technologies France S.A.S.U.
                                                              H. Birkholtz
                                                            Fraunhofer SIT
                                                           7 February 2026


                 Remote Attestation with Multiple Verifiers
                   draft-deshpande-rats-multi-verifier-04

  Abstract

     IETF RATS Architecture, defines the key role of a Verifier.  In a
     complex system, this role needs to be performed by multiple Verfiers
     coordinating together to assess the full trustworthiness of an
     Attester.  This document focuses on various topological patterns for
     a multiple Verifier system.  It only covers the architectural aspects
     introduced by the Multi Verifier concept, which is neutral with
     regard to specific wire formats, encoding, transport mechanisms, or
     processing details.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-rats/draft-deshpande-multi-verifier.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 11 August 2026.




  Deshpande, et al.        Expires 11 August 2026                 [Page 1]


  Internet-Draft             RATS Many-Verifiers             February 2026


  Copyright Notice

     Copyright (c) 2026 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
     2.  Need for Multiple Verifiers . . . . . . . . . . . . . . . . .   3
     3.  Reference Use Cases . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Verification of Devices containing heterogenous
             components  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Verification of Workloads operating in Confidential
             Computing environment . . . . . . . . . . . . . . . . . .   5
     4.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
       4.1.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Multi Verifier topological patterns . . . . . . . . . . . . .   7
       5.1.  Hierarchical Pattern  . . . . . . . . . . . . . . . . . .   7
         5.1.1.  Lead Verifier . . . . . . . . . . . . . . . . . . . .   7
         5.1.2.  Component Verifier  . . . . . . . . . . . . . . . . .   8
         5.1.3.  Trust Relationships . . . . . . . . . . . . . . . . .   9
       5.2.  Cascaded Pattern  . . . . . . . . . . . . . . . . . . . .   9
         5.2.1.  Trust Relationships . . . . . . . . . . . . . . . . .  10
         5.2.2.  Verifiers . . . . . . . . . . . . . . . . . . . . . .  10
         5.2.3.  Relying Party and Verifiers . . . . . . . . . . . . .  11
       5.3.  Hybrid Pattern  . . . . . . . . . . . . . . . . . . . . .  11
     6.  Freshness . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
       7.1.  Adversarial Model . . . . . . . . . . . . . . . . . . . .  12
       7.2.  General Considerations  . . . . . . . . . . . . . . . . .  12
       7.3.  Security for Topological Patterns . . . . . . . . . . . .  12
         7.3.1.  Hierarchical Pattern  . . . . . . . . . . . . . . . .  12
         7.3.2.  Cascaded Pattern  . . . . . . . . . . . . . . . . . .  14
         7.3.3.  Security of the Hybrid Pattern  . . . . . . . . . . .  15
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
       Normative References  . . . . . . . . . . . . . . . . . . . . .  16



  Deshpande, et al.        Expires 11 August 2026                 [Page 2]


  Internet-Draft             RATS Many-Verifiers             February 2026


       Informative References  . . . . . . . . . . . . . . . . . . . .  16
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     A Verifier plays a central role in any Remote Attestation System.  A
     Verifier appraises the Attester and produces Attestation Results,
     which are essentially a verdict of attestation.  The results are
     consumed by the Relying Party to conclude the trustworthiness of the
     Attester, before making any critical decisions about the Attester,
     such as admitting it to the network or releasing confidential
     resources to it.  Attesters can come in wide varieties of shape and
     form.  For example Attesters can be endpoints (edge or IoT devices)
     or complex machines in the cloud.  Composite Attester Section 4.1,
     generate Evidence that consists of multiple parts.  For example, in
     data center servers, it is not uncommon for separate attesting
     environments (AE) to serve a subsection of the entire machine.  One
     AE might measure and attest to what was booted on the main CPU, while
     another AE might measure and attest to what was booted machine's GPU.
     Throughout this document we use the term Component Attester
     Section 4.1 to address the sub-entity or an individual layer which
     produces its own Evidence in a Composite Attester system.

     In a Composite Attester system, it may not be possible for a single
     Verifier to possess all the capabilities or information required to
     conduct a complete appraisal of the Attester.  Please refer to
     Section 2 for motivation of this document.  Multiple Verifiers need
     to collaborate to reach a conclusion on the appraisal and produce the
     Attestation Results.

     This document describes various topological patterns of multiple
     Verifiers that work in a coordinated manner to conduct appraisal of a
     Composite Attester to produce an Attestation Results.

  2.  Need for Multiple Verifiers

     To conduct the task of Evidence appraisal, a Verifier requires:

     1.  Reference Values from trusted supply chain actors producing,
         aggregating, or administering Attesters (Reference Value
         Providers)

     2.  Endorsements from trusted supply chain actors producing,
         certifying, or compliance checking Attesters (Endorsers)

     3.  Appraisal Policy for Evidence, which is under the control of the
         Verifier Owner



  Deshpande, et al.        Expires 11 August 2026                 [Page 3]


  Internet-Draft             RATS Many-Verifiers             February 2026


     The Verifier inputs listed above are linked to the shape of the
     Attesters.  Typically, Composite Attesters come with a varying degree
     of heterogeneity of Evidence formats, depending on the type of
     Attesting Environments that come with each Component Attester, for
     example, CPU variants or GPU/FPGA variants.  When conducting Evidence
     appraisal for a Composite Attester, the following challenges remain:

     1.  An Attester's composition can change over time based on market
         requirements and availability (e.g., a set of racks in a data
         center gets thousands of new FPGAs).  It is highly unlikely that
         there is always one appropriate Verifier that satisfies all the
         requirements that a complex and changing Composite Attesters
         imposes.  It may not be economically viable to build and maintain
         such a degree of complexity in a single Verifier.

     2.  A Verifier Owner may have an Appraisal Policy for Evidence of a
         Component Attester that is internal to them and which they may
         choose not to reveal to a “monolithic" Verifier.

     3.  A Reference Values Provider may not wish to reveal its Reference
         Values or their lifecycle to a monolithic Verifier.

     4.  There may not be a single actor in the ecosystem that can stand
         up and take ownership of verifying every Component Attester due
         to a lack of knowledge, complexity, regulations or associated
         cost.

     5.  The mix today is a combination of Verifier services provided by
         component manufacturers, Verifiers provided by integrators, and
         Verifiers under local authority (i.e., close to the attester).
         Rarely is it just one of these.

  3.  Reference Use Cases

     This section covers generic use cases that demonstrate the
     applicability of Multi Verifier, regardless of specific solutions.
     Its purpose is to motivate various aspects of the architecture
     presented in this document.  There are many other use cases; this
     document does not contain a complete list.

  3.1.  Verification of Devices containing heterogenous components

     A device may contain a central processing unit (CPU), as well as
     heterogeneous acceleration components (such as GPUs, NPUs and TPUs)
     from different suppliers.






  Deshpande, et al.        Expires 11 August 2026                 [Page 4]


  Internet-Draft             RATS Many-Verifiers             February 2026


     These components can be used to speed up processing or assist with AI
     inference.  Trustworthiness assessment of the device requires trust
     in all of these components.  However, due to business concerns such
     as scalability, complexity and cost of infrastructure, the Verifier
     for each type of component may be deployed separately by each vendor.

     When these Verifiers operate together, they must interact with each
     other, understand the topology and interoperate using standardised
     protocols.  For instance, they may need to exchange partial Evidence
     relating to the relevant component or partial Attestation Results for
     it.

     Attester: A Device having multiple components

     Relying Party: An entity which is making trust decisions for such an
     Attester

  3.2.  Verification of Workloads operating in Confidential Computing
        environment

     As organisations move more workloads into untrusted or shared
     environments, Confidential Computing is becoming increasingly
     important.  In such a system, an application or workload (which could
     be an AI model, database process or financial service, for example)
     is executed inside a TEE-protected virtual machine (VM).  When the
     workload starts, the TEE can generate a cryptographic attestation
     report providing:

     1.  The workload is running on a platform with a known state.

     2.  The workload is running the correct application.

     The platform is often built by an independent TEE vendor, while the
     workloads are deployed by workload owners from different parts of the
     supply chain.

     Verification of Attestation for such a system requires independent,
     yet mutually coordinated, verification of: Platform claims appraised
     by a Platform Verifier and Workload claims appraised by a Workload
     Verifier.

     Attester: A layered Attester containing a platform and a workload
     running in a CC environment

     Relying Party: An entity which is making trust decisions, such as a
     key release to a workload





  Deshpande, et al.        Expires 11 August 2026                 [Page 5]


  Internet-Draft             RATS Many-Verifiers             February 2026


  4.  Conventions and Definitions

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

     Specifically this document heavily uses the terms Layered Attester
     Section 3.2 of [RFC9334] and Composite Device Section 3.3 of
     [RFC9334]

  4.1.  Glossary

     This document uses the following terms:

     Composite Attester:  A Composite Attester is either a Composite
        Device or a Layered Attester or any composition involving a
        combination of one or more Composite Devices or Layered Attesters.

     Component Attester:  A Component Attester is a single Attester of a
        Composite Attester.  For this document, a Component Attester is an
        entity which produces a single Evidence which can be appraised by
        a Component Verifier.

     Composite Evidence:  Evidence produced by a Composite Attester.  Also
        referred to as CE in the document.

     Partial Evidence:  It is an extract from a Composite Evidence.  It
        consists of at least one or more Component Evidence.  Also
        referred to as PE in the document.

     Lead Verifier:  A Verifier which acts as a main Verifier to receive
        Composite Evidence from a Composite Attester in a Hierarchical
        pattern Section 5.1.  Also referred to as LV in the document.

     Component Verifier:  A Verifier which is responsible for the
        Verification of one single component or a layer.  Also referred to
        as CV in the document.

     Partial Attestation Results:  Attestation Results produced by a
        Component Verifier, which contains partial results from atleast
        one or more Component Attesters.

     Aggregated Attestation Results:  An Aggregated Attestation Results



  Deshpande, et al.        Expires 11 August 2026                 [Page 6]


  Internet-Draft             RATS Many-Verifiers             February 2026


        (AAR) refers to a collection of Attestation Results produced upon
        completion of appraisal of a Composite Attester.

  5.  Multi Verifier topological patterns

     A Composite Attester has multiple Component Attesters.  Each Attester
     requires a different set of Verifiers.  Hence multiple Verifiers
     collaborate to appraise a Composite Attester.

  5.1.  Hierarchical Pattern

     Figure below shows the block diagram of a Hierarchical Pattern.

                                      PE_1               .------------.
                                    .------------------->|            |
                                    |                    | Verifier 1 |
                                    |      .-------------+            |
                                    |      |       PAR_1 '------------'
                                    |      v                  ...
     .---------------. CE      .----+----------. PE_i    .------------.
     |               +-------->|               +-------->|            |
     | Attester / RP |         | Lead Verifier |         | Verifier i |
     |               |<--------+               |<--------+            |
     '---------------'     AAR '----+----------'   PAR_i '------------'
                                    |      ^                  ...
                                    |      |       PAR_n .------------.
                                    |      '-------------+            |
                                    |                    | Verifier n |
                                    '------------------->|            |
                                      PE_n               '------------'
     Legend:
     - CE: Composite Evidence
     - AAR: Aggregated Attestation Results
     - PE_i: Partial Evidence of i-th Component Attester
     - PAR: Partial Attestation Results

                         Figure 1: Hierarchical Pattern

     The following sub-sections describe the various roles that exist in
     this pattern.

  5.1.1.  Lead Verifier

     In this topological pattern, there is an Entity known as Lead
     Verifier.






  Deshpande, et al.        Expires 11 August 2026                 [Page 7]


  Internet-Draft             RATS Many-Verifiers             February 2026


     Lead Verifier is the central entity in communication with the
     Attester (directly in passport model or indirectly via the Relying
     Party in background-check model).  It receives Attestation Evidence
     from a Composite Attester.  If the Composite Attestation Evidence is
     signed, then it validates the integrity of the Evidence by validating
     the signature.  If signature verification fails, the Verification is
     terminated.  Otherwise it performs the following steps.

     *  Lead Verifier has the required knowledge to break down the
        Composite Evidence into Partial Evidence.  It decodes the
        Composite Evidence to extract the Component Attesters Evidence.
        This may lead to "N" Partial Evidence, one for each Component
        Attester.

     *  Lead Verifier delegates each Partial Evidence to its own Component
        Verifier (CV) and receives Component Attester Attestation Results
        also known as Partial Attestation Results after successful
        Appraisal of Evidence.  There are many protocols to determine how
        a Lead Verifier can select the Component Verifiers.  This document
        does not mandate any specific protocol for determining the
        Component Verifiers

     *  Once the Lead Verifier receives Partial Attestation Results from
        all the Verifiers, it combines the results from each Verifier to
        construct an Aggregated Attestation Results (AAR).  The Lead
        verifier may apply its own policies and also add extra claims as
        part of its appraisal.

     *  Lead Verifier conveys the AAR to the Attester (in Passport model)
        or to the Relying Party (in background check model).

     The overall verdict may be dependent on the Appraisal Policy of the
     Lead Verifier.

     In certain topologies, it is possible that only the Composite
     Evidence is signed to provide the overall integrity, while the
     Partial Evidence (example PE_1) is not protected.  In such cases, the
     Lead Verifer upon processing of Composite Evidence may wrap the
     Partial Evidence (example PE_1) in a signed Conceptual Message
     Wrapper (CMW), and send it to each Verifier (example Verifier 1).

  5.1.2.  Component Verifier

     The role of a Component Verifier is to receive Partial Evidence from
     the Lead Verifier and produce Partial Attestation Results to the Lead
     Verifier.





  Deshpande, et al.        Expires 11 August 2026                 [Page 8]


  Internet-Draft             RATS Many-Verifiers             February 2026


  5.1.3.  Trust Relationships

     In this topology the Lead Verifier is fully trusted by Component
     Verifiers (example Verifier 1).  Each Component Verifiers are
     provisioned with the Trust Anchors (see [RFC6024]) for the Lead
     Verifier.

     Also, each of the Component Verifier is fully trusted by the Lead
     Verifier.  Lead Verifier is provisioned with the Trust Anchors (see
     [RFC6024]) for Verifier 1..N.

  5.2.  Cascaded Pattern

     Figure below shows the block diagram of a Cascaded Pattern.

                          .-----.            .-----.               .-----.
                          |  V  |            |  V  |               |  V  |
                          |  e  |            |  e  |               |  e  |
  .---------------. CE    |  r  | CE, PAR_1  |  r  | CE, PAR_1..2  |  f  |
  |               +------>|  i  +----------->|  i  +----- ... ---->|  i  |
  | Attester / RP |       |  f  |            |  f  |               |  f  |
  |               |<------+  i  |<-----------+  i  |<---- ... -----+  i  |
  '---------------'   AAR |  e  |        AAR |  e  |  AAR=PAR_1..n |  e  |
                          |  r  |            |  r  |               |  r  |
                          |     |            |     |               |     |
                          |  1  |            |  2  |               |  n  |
                          '-----'            '-----'               '-----'

  Legend:
  - CE: Composite Evidence
  - AAR: Aggregated Attestation Results
  - PAR: Partial Attestation Results

                        Figure 2: Cascaded Pattern

     In this topological pattern, the Attestation Verification happens in
     sequence.  Verifiers are cascaded to perform the Attestation
     Appraisal.  Each Verifier in the chain has the knowledge to derive or
     extract the Partial Evidence, which it can appraise, from the
     Composite Evidence.











  Deshpande, et al.        Expires 11 August 2026                 [Page 9]


  Internet-Draft             RATS Many-Verifiers             February 2026


     Attester may send the Composite Evidence(CE) to any of the Verifier
     (directly in the passport model, or indirectly via the Relying Party
     in the background-check model).  The Verifier which processes the
     Composite Evidence, Verifies the signature on the Evidence, if
     present.  It extracts the Partial Evidence from the Composite
     Evidence, performs Appraisal of the Component Attester whose
     Reference Values and Endorsements are in its database.  Once the
     appraisal is complete, it forwards the Composite Evidence and Partial
     Attestation Results to the subsequent Verifier.

     The process is repeated, until the entire appraisal is complete.  The
     last Verifier, i.e. Verifier-N, completes its Appraisal of the
     Partial Evidence, that it can appraise.  It has now all the Partial
     Attestation Results and creates the Aggregated Attestation
     Results(AAR).  It returns the AAR to the N-1 Verifier (from where it
     received the Composite Evidence and Partial AR).  The process is
     repeated, i.e. AAR is returned in the chain until the Verifier, which
     recieved the initial Composite Evidence is reached.  At this point in
     time the Aggregated Attestation Results are signed and the AAR is
     sent to the Attester (in Passport Model) or Relying Party (in
     background check model).

     As shown in the picture, the Partial Attestation Results and
     Composite Evidence is transmitted to a chain of Verifier, till the
     Appraisal is complete.  Upon completion, the last Verifier in the
     chain combines the incoming Partial Attestation Results, combines the
     results from it own Evidence Appraisal and passes the Aggregated
     Attestation Results to the Verifier from which it receives Composite
     Evidence.

     There are many protocols to determine how a Verifier can select the
     next Verifier to route the CE and PAR.  This document does not
     mandate any specific protocol for determining the Verifiers in
     cascade.

  5.2.1.  Trust Relationships

  5.2.2.  Verifiers

     In the cascaded pattern, the communicating Verifiers fully trust each
     other.  Each Verifier has the trust anchor for the Verifier it is
     communicating to (i.e. either sending information or receiving
     information).  This prevents man in the middle attack for the Partial
     Attestation Results received by a Verifier or a Aggregated
     Attestation Results (AAR) which it receives in the return path.






  Deshpande, et al.        Expires 11 August 2026                [Page 10]


  Internet-Draft             RATS Many-Verifiers             February 2026


  5.2.3.  Relying Party and Verifiers

     In the cascaded pattern, the RP may communicate with any Verifier and
     thus receive its Attestation Results.  Hence RP fully trusts all the
     Verifiers.

  5.3.  Hybrid Pattern

     In a particular deployment, there is a possibility that the two
     models presented above can be combined to produce a hybrid pattern.
     For example Verifier 2 in the Cascaded Pattern becomes the Lead
     Verifier for the remaining Verifers from 3, to N.

  6.  Freshness

     The Verifier needs to ensure that the claims included in the Evidence
     reflect the latest state of the Attester.  As per RATS Architecture,
     the recommended freshness is ascertained using either Synchronised
     Clocks, Epoch IDs, or nonce, embedded in the Evidence.  In the case
     of Hierarchical Pattern, the Verification of Freshness should be
     checked by the Lead Verifier.

     In the Cascaded Pattern, the freshness is always checked by the first
     Verifier in communication with either the Attester (Passport Model)
     or Relying Party (Background Check Model).

  7.  Security Considerations

     The Verifier is not part of the Attester’s Trusted Computing Base
     (TCB), but acts as a critical component in the Relying Party’s trust
     decision chain.  Therefore, its security directly affects the
     reliability of the entire remote attestation process.  When multiple
     Verifiers coordinate to conduct an appraisal, this may increase the
     attack surface, depending on the system architecture and trust
     assumptions.

     Any mistake in the appraisal procedure conducted by one or more
     Verifiers could lead to severe security implications, such as
     incorrect Attestation Result of a component or a composition to the
     Relying party.  This section details the security threats and
     mitigation strategies specific to the multi-verifier topologies
     described in this document.  In addition to the considerations
     herein, Verifiers MUST follow the guidance detailed in the Security
     and Privacy considerations of a RATS Verifier as detailed in
     Section 11 of [I-D.draft-ietf-rats-corim] and the RATS Architecture
     Section 11 and Section 12 of [RFC9334].





  Deshpande, et al.        Expires 11 August 2026                [Page 11]


  Internet-Draft             RATS Many-Verifiers             February 2026


  7.1.  Adversarial Model

     The security analysis in this section assumes that attackers may:

     1.  Eavesdrop on any communication channel between Verifiers.

     2.  Inject, modify, replay, or delay messages traversing the network.

     3.  Compromise one or more Verifiers in the ecosystem, attempting to
         leak sensitive information (e.g., Evidence, Reference Values) or
         manipulate Attestation Results.

     4.  Perform Man-in-the-Middle (MitM) attacks between any two
         communicating entities.

     The system is designed to be resilient under the assumption that the
     cryptographic keys used for signing Evidence and Attestation Results
     (by authentic entities) are not compromised.

  7.2.  General Considerations

     All communications between entities (Attester-Verifier, Verifier-
     Verifier, Verifier-RP) MUST be secured using mutually authenticated,
     confidential, and integrity-protected channels (e.g., TLS).

     It is recommended that any two verifiers establishing a communication
     channel perform mutual attestation before exchanging any attestation
     messages.

  7.3.  Security for Topological Patterns

  7.3.1.  Hierarchical Pattern

     The hierarchical pattern introduces a central trust entity, the Lead
     Verifier (LV).  The security of the entire system relies on the
     integrity and correct operation of the LV.

  7.3.1.1.  Threats and Mitigations

  7.3.1.1.1.  LV Compromise

     *Threat:* A compromised LV can orchestrate attacks, such as approving
     malicious attestations, wrongly aggregating attestation results or
     leaking sensitive evidence.  This is a single point of failure from a
     trust perspective.






  Deshpande, et al.        Expires 11 August 2026                [Page 12]


  Internet-Draft             RATS Many-Verifiers             February 2026


     *Mitigation:* The LV MUST be hardened and operate and store its Keys
     in a secure environment.  Its operation SHOULD be auditable.
     Component Verifiers should be made available suitable trust anchors
     so that they can establish required trust in the authority of the LV.

  7.3.1.1.2.  Communication Security (LV <-> CV)

     *Threat:* Eavesdropping or manipulation of evidence/results in
     transit.

     *Mitigation:* All communications between the LV and CVs MUST be
     mutually authenticated and confidential (e.g., using TLS with client
     authentication).  This ensures integrity, confidentiality, and
     authenticity of the messages exchanged between the Verifiers.

  7.3.1.1.3.  Evidence Integrity and Origin Authentication (LV -> CV)

     *Threat:* The LV could forward manipulated evidence to a CV, or an
     attacker could inject fake evidence.

     *Mitigation:* The conceptual message containing the Partial Evidence
     MUST be integrity-protected and authenticated.  If the Partial
     Evidence is natively signed by the Component Attester at origin, the
     CV can verify it directly.  If the Partial Evidence lacks inherent
     signatures (e.g., in UCCS), the LV MUST sign the Partial Evidence
     using a key that the CV trusts.  This prevents any on-path attacker
     from altering the Partial Evidence.

  7.3.1.1.4.  Results Integrity and Origin Authentication (CV -> LV)

     *Threat:* Partial Attestation Results could be manipulated in transit
     or forged by a malicious CV.

     *Mitigation:* Each Partial Attestation Result MUST be digitally
     signed by the CV.  LV should maintain a list of trust anchors for the
     CV's it communicates with.  The LV MUST validate the signature using
     the required trust anchor for the CV, before adding the Partial
     Attestation Results to the Aggregated Attestation Results.

  7.3.1.1.5.  Replay Attacks

     *Threat:* An adversary Component Verifier replays old Evidence or
     Attestation Results.

     *Mitigation:* The LV is responsible for enforcing freshness (via
     nonces, epochs, or timestamps).  This freshness value MUST be
     propagated to CVs and back to the LV, to ensure final AR can be
     validated against the original challenge.



  Deshpande, et al.        Expires 11 August 2026                [Page 13]


  Internet-Draft             RATS Many-Verifiers             February 2026


  7.3.2.  Cascaded Pattern

     The cascaded pattern distributes trust but requires each Verifier in
     the chain to be trusted to correctly handle and forward Attestation
     messages.  The chain's security is only as strong as its weakest
     link.

  7.3.2.1.  Threats and Mitigations

  7.3.2.1.1.  Verifier Compromise

     *Threat:* Any compromised Verifier in the chain can block, delay, or
     manipulate the attestation process.  It can inject false partial
     results, drop evidence, or leak sensitive information.

     *Mitigation:* Relying Parties and Verifiers MUST be configured with
     strict trust policies defining the allowed paths and trusted
     Verifiers.  Operations should be logged for auditability.

  7.3.2.1.2.  Communication Security

     *Threat:* Eavesdropping or manipulation of evidence and results
     between Verifiers.

     *Mitigation:* Each hop between Verifiers MUST be secured with
     mutually authenticated and confidential channels (e.g., TLS with
     client authentication).

  7.3.2.1.3.  Evidence and Results Protection

     *Threat:* Lack of end-to-end security allows intermediate Verifiers
     to manipulate evidence or results that are not intended for them to
     appraise.

     *Mitigation:* End-to-end integrity protection is RECOMMENDED.  The
     Composite Evidence should be signed by the Attester.  Partial and
     Aggregated Attestation Results SHOULD be signed by the Verifier that
     generated them.  This allows subsequent Verifiers and the Relying
     Party to verify that results have not been tampered with by
     intermediate nodes.

  7.3.2.1.4.  Replay Attacks

     *Threat:* An adversary replays old Evidence or Attestation Results.

     *Mitigation:* The first Verifier in the chain (the one receiving
     evidence from the Attester/RP) is responsible for enforcing freshness
     (via nonces, epochs, or timestamps) for the entire cascade.  This



  Deshpande, et al.        Expires 11 August 2026                [Page 14]


  Internet-Draft             RATS Many-Verifiers             February 2026


     freshness value MUST be propagated with the Evidence and Results
     through the chain so the final AR can be validated against the
     original challenge.

  7.3.3.  Security of the Hybrid Pattern

     As the hybrid pattern is the composition of hierarchical pattern and
     cascade pattern, all the threats and mitigations that are applicable
     for these two patterns are also applicable for the general hybrid
     pattern.

  8.  Privacy Considerations

     The appraisal of a Composite Attester requires exchange of
     attestation related messages, for example, Partial Evidence and
     Partial Attestation Results, among multiple Verifiers.  This can
     potentially leak sensitive information about the Attester's
     configuration, identities and the nature of composition.

     However, when carefully designed, a multi-verifier architecture can
     actually mitigate these privacy concerns.  By distributing appraisal
     responsibilities and ensuring that no single Verifier has access to
     the full set of Evidence, the risk of comprehensive device profiling
     or tracking is reduced.

     Nonetheless, such benefits depend on strong implementation practices.

     *  Minimization: Attesters should only generate Evidence that is
        strictly necessary for the appraisal policy.  Verifiers should
        only request necessary claims.

     *  Confidentiality: Evidence containing sensitive information should
        be encrypted so that it can only be accessed by the intended
        Verifier and not by any unauthorised parties (including other
        Verifiers in the hierarchy, cascade or hybrid pattern).  This is
        crucial in multi-tenant environments.

     *  Policy Handling: Verifiers should be careful not to leak their
        internal appraisal policies (e.g., through error messages or
        timing side channels) when communicating with other Verifiers or
        Attesters, as this information could be exploited by an attacker
        to manipulate appraisal.

  9.  IANA Considerations







  Deshpande, et al.        Expires 11 August 2026                [Page 15]


  Internet-Draft             RATS Many-Verifiers             February 2026


  Acknowledgments

     The authors would like to thank Simon Frost and Usama Sardar for
     their reviews and suggestions.

  References

  Normative References

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

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

  Informative References

     [I-D.draft-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-09, 20
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-corim-09>.

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

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

  Contributors

     Thomas Fossati
     Linaro
     Email: Thomas.Fossati@linaro.org


     Thanassis Giannetsos
     UBITECH Ltd.
     Email: agiannetsos@ubitech.eu





  Deshpande, et al.        Expires 11 August 2026                [Page 16]


  Internet-Draft             RATS Many-Verifiers             February 2026


     Steven Bellock
     NVIDIA
     Email: sbellock@nvidia.com


     Ghada Arfaoui
     ORANGE
     Email: ghada.arfaoui@orange.com


  Authors' Addresses

     Yogesh Deshpande
     Arm Ltd
     Email: yogesh.deshpande@arm.com


     Jun Zhang
     Huawei Technologies France S.A.S.U.
     Email: junzhang1@huawei.com


     Houda Labiod
     Huawei Technologies France S.A.S.U.
     Email: houda.labiod@huawei.com


     Henk Birkholtz
     Fraunhofer SIT
     Email: henk.birkholz@sit.fraunhofer.de





















  Deshpande, et al.        Expires 11 August 2026                [Page 17]


name: draft-fv-rats-ear
rev: 05
title: EAT Attestation Results
time: 2025-04-04T19:41:50Z
group_uri: /api/v1/group/group/2231/
expires: 2025-08-10T15:23:44Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.274502+00:00
source: ietf
source_id: 114423
source_url: https://datatracker.ietf.org/doc/draft-fv-rats-ear/
doc_status: active
abstract:
  This document defines the EAT Attestation Result (EAR) message
     format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" to present a normalized view of the evaluation results, thus
     easing the task of defining and computing authorization policies by
     relying parties.  Alongside the trustworthiness vector, EAR provides
     contextual information bound to the appraisal process.  This allows a
     relying party (or an auditor) to reconstruct the frame of reference
     in which the trustworthiness vector was originally computed.  EAR
     supports simple devices with one attester as well as composite
     devices that are made of multiple attesters, allowing the state of
     each attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT or JWT.

full_text:
  Remote ATtestation ProcedureS                                 T. Fossati
  Internet-Draft                                                    Linaro
  Intended status: Standards Track                                 E. Voit
  Expires: 10 August 2025                                            Cisco
                                                               S. Trofimov
                                                               Arm Limited
                                                               H. Birkholz
                                                            Fraunhofer SIT
                                                           6 February 2025


                          EAT Attestation Results
                            draft-fv-rats-ear-05

  Abstract

     This document defines the EAT Attestation Result (EAR) message
     format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" to present a normalized view of the evaluation results, thus
     easing the task of defining and computing authorization policies by
     relying parties.  Alongside the trustworthiness vector, EAR provides
     contextual information bound to the appraisal process.  This allows a
     relying party (or an auditor) to reconstruct the frame of reference
     in which the trustworthiness vector was originally computed.  EAR
     supports simple devices with one attester as well as composite
     devices that are made of multiple attesters, allowing the state of
     each attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT or JWT.

  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://thomas-
     fossati.github.io/draft-ear/draft-fv-rats-ear.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-fv-rats-ear/.

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





  Fossati, et al.          Expires 10 August 2025                 [Page 1]


  Internet-Draft                     EAR                     February 2025


     Source for this draft and an issue tracker can be found at
     https://github.com/thomas-fossati/draft-ear.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 August 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
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  EAT Attestation Result  . . . . . . . . . . . . . . . . . . .   4
       3.1.  EAR Appraisal Claims  . . . . . . . . . . . . . . . . . .   5
       3.2.  JSON Serialisation  . . . . . . . . . . . . . . . . . . .   6
         3.2.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  CBOR Serialisation  . . . . . . . . . . . . . . . . . . .   9
         3.3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   9
     4.  EAR Extensions  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Unregistered claims . . . . . . . . . . . . . . . . . . .  10
       4.2.  Registered claims . . . . . . . . . . . . . . . . . . . .  10
       4.3.  Choosing between registered and unregistered claims . . .  10



  Fossati, et al.          Expires 10 August 2025                 [Page 2]


  Internet-Draft                     EAR                     February 2025


       4.4.  TEEP Extension  . . . . . . . . . . . . . . . . . . . . .  11
         4.4.1.  JSON Serialization Example  . . . . . . . . . . . . .  11
         4.4.2.  CBOR Serialization Example  . . . . . . . . . . . . .  12
       4.5.  Project Veraison Extensions . . . . . . . . . . . . . . .  13
         4.5.1.  JSON Serialization Examples . . . . . . . . . . . . .  14
         4.5.2.  CBOR Serialization Example  . . . . . . . . . . . . .  16
     5.  Media Types . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  18
       6.1.  Project Veraison  . . . . . . . . . . . . . . . . . . . .  18
         6.1.1.  github.com/veraison/ear . . . . . . . . . . . . . . .  18
         6.1.2.  github.com/veraison/c-ear . . . . . . . . . . . . . .  19
         6.1.3.  github.com/veraison/rust-ear  . . . . . . . . . . . .  19
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       9.1.  New EAT Claims  . . . . . . . . . . . . . . . . . . . . .  20
         9.1.1.  EAR Status  . . . . . . . . . . . . . . . . . . . . .  20
         9.1.2.  Trustworthiness Vector  . . . . . . . . . . . . . . .  20
         9.1.3.  EAR Raw Evidence  . . . . . . . . . . . . . . . . . .  21
         9.1.4.  EAR Appraisal Policy Identifier . . . . . . . . . . .  21
         9.1.5.  Verifier Software Identifier  . . . . . . . . . . . .  21
         9.1.6.  EAR TEEP Claims . . . . . . . . . . . . . . . . . . .  22
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
       10.2.  Informative References . . . . . . . . . . . . . . . . .  23
     Appendix A.  Common CDDL Types  . . . . . . . . . . . . . . . . .  24
     Appendix B.  Open Policy Agent Example  . . . . . . . . . . . . .  24
     Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  26
     Appendix D.  Document History . . . . . . . . . . . . . . . . . .  26
       D.1.  draft-fv-rats-ear-00  . . . . . . . . . . . . . . . . . .  26
       D.2.  draft-fv-rats-ear-01  . . . . . . . . . . . . . . . . . .  27
       D.3.  draft-fv-rats-ear-02  . . . . . . . . . . . . . . . . . .  27
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

     This document defines the EAT [I-D.ietf-rats-eat] Attestation Result
     (EAR) message format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" [I-D.ietf-rats-ar4si] to present a normalized view of the
     evaluation results, thus easing the task of defining and computing
     authorization policies by relying parties.  Alongside the
     trustworthiness vector, EAR provides contextual information bound to
     the appraisal process.  This allows a relying party (or an auditor)
     to reconstruct the frame of reference in which the trustworthiness



  Fossati, et al.          Expires 10 August 2025                 [Page 3]


  Internet-Draft                     EAR                     February 2025


     vector was originally computed.  EAR supports simple devices with one
     attester as well as composite devices that are made of multiple
     attesters (see Section 3.3 of [RFC9334]) allowing the state of each
     attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT [RFC8392] or JWT [RFC7519].

  2.  Conventions and Definitions

     This document uses terms and concepts defined by the RATS
     architecture.  For a complete glossary see Section 4 of [RFC9334].

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

     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.

  3.  EAT Attestation Result

     EAR is an EAT token which can be serialized as JWT [RFC7519] or CWT
     [RFC8392].

     The EAR claims-set is as follows:

     ;# import rfc9711 as eat
     ;# import ar4si as ar4si

     EAR = {
       eat.profile-label => "tag:github.com,2023:veraison/ear"
       eat.iat-claim-label => int
       verifier-id-label => ar4si.verifier-id
       ? raw-evidence-label => eat.binary-data
       eat.submods-label => { + text => EAR-appraisal }
       ? eat.nonce-label => eat.nonce-type
       * $$ear-extension
     }

     ; EAR-specific claims
     raw-evidence-label = eat.JC<"ear.raw-evidence", 1002>
     verifier-id-label = eat.JC<"ear.verifier-id", 1004>

                        Figure 1: EAR (CDDL Definition)




  Fossati, et al.          Expires 10 August 2025                 [Page 4]


  Internet-Draft                     EAR                     February 2025


     Where:

     eat_profile (mandatory)  The EAT profile (Section 6 of
        [I-D.ietf-rats-eat]) associated with the EAR claims-set and
        encodings defined by this document.  It MUST be the following tag
        URI ([RFC4151]) tag:github.com,2023:veraison/ear.

     iat (mandatory)  "Issued At" claim -- the time at which the EAR is
        issued.  See Section 4.1.6 of [RFC7519] and Section 4.3.1 of
        [I-D.ietf-rats-eat] for the EAT-specific encoding restrictions
        (i.e., disallowing the floating point representation).

     ear.verifier-id (mandatory)  Identifying information about the
        appraising verifier.  See Section 3.3 of [I-D.ietf-rats-ar4si] for
        further details on its structure and serialization.

     ear.raw-evidence (optional)  The unabridged evidence submitted for
        appraisal, including any signed container/envelope.  This field
        may be consumed by other Verifiers in multi-stage verification
        scenarios or by auditors.  There are privacy considerations
        associated with this claim.  See Section 8.

     submods (mandatory)  A submodule map (Section 4.2.18 of
        [I-D.ietf-rats-eat]) holding one EAR-appraisal for each separately
        appraised attester.  The map MUST contain at least one entry.  For
        each appraised attester the verifier chooses a unique label.  For
        example, when evidence is in EAT format, the label could be
        constructed from the associated EAT profile.  A verifier SHOULD
        publicly and permanently document its labelling scheme for each
        supported evidence type, unless EAR payloads are produced and
        consumed entirely within a private deployment.  See Section 3.1
        for the details about the contents of an EAR-appraisal.

     eat_nonce (optional)  A user supplied nonce that is echoed by the
        verifier to provide freshness.  The nonce is a sequence of bytes
        between 8 and 64 bytes long.  When serialized as JWT, the nonce
        MUST be base64 encoded, resulting in a string between 12 and 88
        bytes long.  See Section 4.1 of [I-D.ietf-rats-eat].

     $$ear-extension (optional)  Any registered or unregistered extension.
        An EAR extension MUST be a map.  See Section 4 for further
        details.

  3.1.  EAR Appraisal Claims







  Fossati, et al.          Expires 10 August 2025                 [Page 5]


  Internet-Draft                     EAR                     February 2025


     ;# import ar4si as ar4si

     EAR-appraisal = {
       status-label => ar4si.trustworthiness-tier
       ? trustworthiness-vector-label => ar4si.trustworthiness-vector
       ? appraisal-policy-id-label => text
       * $$ear-appraisal-extension
     }

     status-label = eat.JC<"ear.status", 1000>
     trustworthiness-vector-label = eat.JC<"ear.trustworthiness-vector", 1001>
     appraisal-policy-id-label = eat.JC<"ear.appraisal-policy-id", 1003>

                Figure 2: EAR Appraisal Claims (CDDL Definition)

     ear.status (mandatory)
        The overall appraisal status for this attester represented as one
        of the four trustworthiness tiers (Section 3.2 of
        [I-D.ietf-rats-ar4si]).  The value of this claim MUST be set to a
        tier of no higher trust than the tier corresponding to the worst
        trustworthiness claim across the entire trustworthiness vector.

     ear.trustworthiness-vector (optional)
        The AR4SI trustworthiness vector providing the breakdown of the
        appraisal for this attester.  See Section 3.1 of
        [I-D.ietf-rats-ar4si] for the details.  This claim MUST be present
        unless the party requesting Evidence appraisal explicitly asks for
        it to be dropped, e.g., via an API parameter or similar
        arrangement.  Such consumer would therefore rely entirely on the
        semantics of the ear.status claim.  This behaviour is NOT
        RECOMMENDED because of the resulting loss of quality of the
        appraisal result.

     ear.appraisal-policy-id (optional)
        An unique identifier of the appraisal policy used to evaluate the
        attestation result.

     $$ear-appraisal-extension (optional)
        Any registered or unregistered extension.  An EAR appraisal
        extension MUST be a map.  See Section 4 for further details.

  3.2.  JSON Serialisation









  Fossati, et al.          Expires 10 August 2025                 [Page 6]


  Internet-Draft                     EAR                     February 2025


  3.2.1.  Examples

     The example in Figure 3 shows an EAR claims-set corresponding to a
     "contraindicated" appraisal, meaning the verifier has found some
     problems with the attester's state reported in the submitted
     evidence.  Specifically, the identified issue is related to
     unauthorized code or configuration loaded in runtime memory (i.e.,
     value 96 in the executables category).  The appraisal is for a device
     with one attester labelled "PSA".  Note that in case there is only
     one attester, the labelling can be freely chosen because there is no
     ambiguity.

     {
       "eat_profile": "tag:github.com,2023:veraison/ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         }
       }
     }

              Figure 3: JSON claims-set: contraindicated appraisal

     The breakdown of the trustworthiness vector is as follows:

     *  Instance Identity (affirming): recognized and not compromised

     *  Configuration (warning): known vulnerabilities

     *  Executables (contraindicated): contraindicated run-time

     *  File System (none): no claim being made

     *  Hardware (affirming): genuine




  Fossati, et al.          Expires 10 August 2025                 [Page 7]


  Internet-Draft                     EAR                     February 2025


     *  Runtime Opaque (none): no claim being made

     *  Storage Opaque (none): no claim being made

     *  Sourced Data (none): no claim being made

     The example in Figure 4 contains the appraisal for a composite device
     with two attesters named "CCA Platform" and "CCA Realm" respectively.
     Both attesters have either "affirming" or (implicit) "none" values in
     their associated trustworthiness vectors.  Note that the "none"
     values can refer to either an AR4SI category that is unapplicable for
     the specific attester (ideally, the applicability should be specified
     by the evidence format itself), or to the genuine lack of information
     at the attester site regarding the specific category.  For example,
     the reference values for the "CCA Realm" executables (i.e., the
     confidential computing workload) may not be known to the CCA platform
     verifier.  In such cases, it is up to the downstream entity
     (typically, the relying party) to complete the partial appraisal.

     {
       "eat_profile": "tag:github.com,2023:veraison/ear",
       "iat": 1666529300,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQKNzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "CCA Platform": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 2,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         },
         "CCA Realm": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         }
       }
     }



  Fossati, et al.          Expires 10 August 2025                 [Page 8]


  Internet-Draft                     EAR                     February 2025


             Figure 4: JSON claims-set: simple affirming appraisal

  3.3.  CBOR Serialisation

  3.3.1.  Examples

     The example in Figure 5 is semantically equivalent to that in
     Figure 3.  It shows the same "contraindicated" appraisal using the
     more compact CBOR serialization of the EAR claims-set.

     {
       265: "tag:github.com,2023:veraison/ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA": {
           1000: 96,
           1001: {
             0: 2,
             2: 96,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d"
         }
       }
     }

              Figure 5: CBOR claims-set: contraindicated appraisal

  4.  EAR Extensions

     EAR provides core semantics for describing the result of appraising
     attestation evidence.  However, a given application may offer extra
     functionality to its relying parties, or tailor the attestation
     result to the needs of the application (e.g., TEEP
     [I-D.ietf-teep-protocol]).  To accommodate such cases, both EAR and
     EAR-appraisal claims-sets can be extended by plugging new claims into
     the $$ear-extension (or $$ear-appraisal-extension, respectively) CDDL
     socket.

     The rules that govern extensibility of EAR are those defined in
     [RFC8392] and [RFC7519] for CWTs and JWTs respectively.





  Fossati, et al.          Expires 10 August 2025                 [Page 9]


  Internet-Draft                     EAR                     February 2025


     An extension MUST NOT change the semantics of the EAR and EAR-
     appraisal claims-sets.

     A receiver MUST ignore any unknown claim.

  4.1.  Unregistered claims

     An application-specific extension will normally mint its claim from
     the "private space" - using integer values less than -65536 for CWT,
     and Public or Private Claim Names as defined in Sections 4.2 and 4.3
     of [RFC7519] when serializing to JWT.

     It is RECOMMENDED that JWT EARs use Collision-Resistant Public Claim
     Names (Section 2 of [RFC7519]) rather than Private Claim Names.

  4.2.  Registered claims

     If an extension will be used across multiple applications, or is
     intended to be used across multiple environments, the associated
     extension claims SHOULD be registered in one, or both, the CWT and
     JWT claim registries.

     In general, if the registration policy requires an accompanying
     specification document (as it is the case for "specification
     required" and "standards action"), such document SHOULD explicitly
     say that the extension is expected to be used in EAR claims-sets
     identified by this profile.

     An up-to-date view of the registered claims can be obtained via the
     [IANA.cwt] and [IANA.jwt] registries.

  4.3.  Choosing between registered and unregistered claims

     If an extension supports functionality of a specific application
     (e.g. Project Veraison Services), its claims MAY be registered.

     If an extension supports a protocol that may be applicable across
     multiple applications or environments (e.g., TEEP), its claims SHOULD
     be registered.

     Since, in general, there is no guarantee that an application will be
     confined within an environment, it is RECOMMENDED that extension
     claims that have meaning outside the application's context are always
     registered.







  Fossati, et al.          Expires 10 August 2025                [Page 10]


  Internet-Draft                     EAR                     February 2025


     It is also possible that claims that start out as application-
     specific acquire a more stable meaning over time.  In such cases, it
     is RECOMMENDED that new equivalent claims are created in the "public
     space" and are registered as described in Section 4.2.  The original
     "private space" claims SHOULD then be deprecated by the application.

  4.4.  TEEP Extension

     The TEEP protocol [I-D.ietf-teep-protocol] specifies the required
     claims that an attestation result must carry for a TAM (Trusted
     Application Manager) to make decisions on how to remediate a TEE
     (Trusted Execution Environment) that is out of compliance, or update
     a TEE that is requesting an authorized change.

     The list is provided in Section 4.3.1 of [I-D.ietf-teep-protocol].

     EAR defines a TEEP application extension for the purpose of conveying
     such claims.

     ;# import rfc9711 as eat
     ;# import rfc9393

     $$ear-appraisal-extension //= (
       ear.teep-claims-label => ear-teep-claims
     )

     ear-teep-claims = non-empty<{
       ? eat.nonce-label => eat.nonce-type
       ? eat.ueid-label => eat.ueid-type
       ? eat.oemid-label => eat.oemid-pen / eat.oemid-ieee / eat.oemid-random
       ? eat.hardware-model-label => eat.hardware-model-type
       ? eat.hardware-version-label => eat.hardware-version-type
       ? eat.manifests-label => eat.manifests-type
     }>

     ear.teep-claims-label = eat.JC<"ear.teep-claims", 65000>

                   Figure 6: TEEP Extension (CDDL Definition)

  4.4.1.  JSON Serialization Example











  Fossati, et al.          Expires 10 August 2025                [Page 11]


  Internet-Draft                     EAR                     February 2025


     {
       "eat_profile": "tag:github.com,2023:veraison/ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.teep-claims": {
             "eat_nonce": "80FH7byS7VjfARIq0_KLqu6B9j-F79QtV6p",
             "ueid": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "oemid": "Av8B",
             "hwmodel": "fJYq",
             "hwversion": ["1.2.5", 16384]
           }
         }
       }
     }

  4.4.2.  CBOR Serialization Example





















  Fossati, et al.          Expires 10 August 2025                [Page 12]


  Internet-Draft                     EAR                     February 2025


     {
       265: "tag:github.com,2023:veraison/ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA": {
           1000: 0,
           1001: {
             0: 2,
             1: 2,
             2: 2,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d",
           65000: {
             10: h'948f8860d13a463e',
             256: h'0198f50a4ff6c05861c8860d13a638ea',
             258: 64242,
             259: h'ee80f5a66c1fb9742999a8fdab930893',
             260: ["1.2.5", 16384]
           }
         }
       }
     }

  4.5.  Project Veraison Extensions

     The Project Veraison verifier defines three private, application-
     specific extensions:

     ear.veraison.annotated-evidence
        JSON representation of the evidence claims-set, including any
        annotations provided by the Project Veraison verifier.  There are
        privacy considerations associated with this claim.  See Section 8.

     ear.veraison.policy-claims
        any extra claims added by the policy engine in the Project
        Veraison verifier.

     ear.veraison.key-attestation
        contains the public key part of a successfully verified attested
        key.  The key is a DER encoded ASN.1 SubjectPublicKeyInfo
        structure (Section 4.1.2.7 of [RFC5280]).




  Fossati, et al.          Expires 10 August 2025                [Page 13]


  Internet-Draft                     EAR                     February 2025


     ;# import rfc9711 as eat

     $$ear-appraisal-extension //= (
       ear.veraison.annotated-evidence-label => ear-veraison-annotated-evidence
     )

     ear-veraison-annotated-evidence = {
       + text => any
     }

     $$ear-appraisal-extension //= (
       ear.veraison.policy-claims-label => ear-veraison-policy-claims
     )

     ear-veraison-policy-claims = {
       + text => any
     }

     $$ear-appraisal-extension //= (
       ear.veraison.key-attestation-label => ear-veraison-key-attestation
     )

     ear-veraison-key-attestation = {
       "akpub" => eat.binary-data
     }

     ear.veraison.annotated-evidence-label = eat.JC<"ear.veraison.annotated-evidence", -70000>
     ear.veraison.policy-claims-label = eat.JC<"ear.veraison.policy-claims", -70001>
     ear.veraison.key-attestation-label = eat.JC<"ear.veraison.key-attestation", -70002>

            Figure 7: Project Veraison Extensions (CDDL Definition)

  4.5.1.  JSON Serialization Examples

     {
       "eat_profile": "tag:github.com,2023:veraison/ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA_IOT": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,



  Fossati, et al.          Expires 10 August 2025                [Page 14]


  Internet-Draft                     EAR                     February 2025


             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.veraison.annotated-evidence": {
             "eat-profile": "http://arm.com/psa/2.0.0",
             "psa-client-id": 1,
             "psa-security-lifecycle": 12288,
             "psa-implementation-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-software-components": [
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               },
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               }
             ],
             "psa-nonce":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-instance-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "psa-certification-reference": "1234567890123-12345"
           },
           "ear.veraison.policy-claims": {
             "psa-certified": {
               "certificate-number": "1234567890123-12345",
               "date-of-issue": "23/06/2022",
               "test-lab": "Riscure",
               "certification-holder": "ACME Inc.",
               "certified-product": "RoadRunner",
               "hardware-version": "Gizmo v1.0.2",
               "software-version": "TrustedFirmware-M v1.0.6",
               "certification-type": "PSA Certified Level 1 v2.1",
               "developer-type": "PSA Certified – Device"
             }
           }
         }
       }
     }





  Fossati, et al.          Expires 10 August 2025                [Page 15]


  Internet-Draft                     EAR                     February 2025


     {
       "eat_profile": "tag:github.com,2023:veraison/ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PARSEC_TPM": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 2,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.veraison.key-attestation": {
             "akpub":
               "MFkwEwYHKoZIzj0CAQYIKoZIz___"
           }
         }
       }
     }

  4.5.2.  CBOR Serialization Example

     {
       265: "tag:github.com,2023:veraison/ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA_IOT": {
           1000: 0,
           1001: {
             0: 2,
             1: 2,
             2: 2,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d",
           -70000: {
             "eat-profile": "http://arm.com/psa/2.0.0",



  Fossati, et al.          Expires 10 August 2025                [Page 16]


  Internet-Draft                     EAR                     February 2025


             "psa-client-id": 1,
             "psa-security-lifecycle": 12288,
             "psa-implementation-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-software-components": [
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               },
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               }
             ],
             "psa-nonce":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-instance-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "psa-certification-reference": "1234567890123-12345"
           },
           -70001: {
             "psa-certified": {
               "certificate-number": "1234567890123-12345",
               "date-of-issue": "23/06/2022",
               "test-lab": "Riscure",
               "certification-holder": "ACME Inc.",
               "certified-product": "RoadRunner",
               "hardware-version": "Gizmo v1.0.2",
               "software-version": "TrustedFirmware-M v1.0.6",
               "certification-type": "PSA Certified Level 1 v2.1",
               "developer-type": "PSA Certified – Device"
             }
           }
         }
       }
     }

  5.  Media Types

     Media types for EAR are automatically derived from the base EAT media
     type [I-D.ietf-rats-eat-media-type] using the profile string defined
     in Section 3.

     For example, a JWT serialization would use:



  Fossati, et al.          Expires 10 August 2025                [Page 17]


  Internet-Draft                     EAR                     February 2025


     application/eat-jwt; eat_profile="tag:github.com,2023:veraison/ear"

     A CWT serialization would instead use:

     application/eat-cwt; eat_profile="tag:github.com,2023:veraison/ear"

  6.  Implementation Status

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

  6.1.  Project Veraison

     The organization responsible for this implementation is Project
     Veraison, a Linux Foundation project hosted at the Confidential
     Computing Consortium.

     The organization currently provides two separate implementations: one
     in Golang another in C17.

     The developers can be contacted on the Zulip channel:
     https://veraison.zulipchat.com/#narrow/stream/357929-EAR/.

  6.1.1.  github.com/veraison/ear

     The software, hosted at https://github.com/veraison/ear, provides a
     Golang package that allows encoding, decoding, signing and
     verification of EAR payloads together with a CLI (arc) to create,
     verify and visualize EARs on the command line.  The maturity level is
     currently alpha, and only the JWT serialization is implemented.  The
     license is Apache 2.0.  The package is used by the Project Veraison



  Fossati, et al.          Expires 10 August 2025                [Page 18]


  Internet-Draft                     EAR                     February 2025


     verifier to produce attestation results.

  6.1.2.  github.com/veraison/c-ear

     The software, hosted at https://github.com/veraison/c-ear, provides a
     C17 library that allows verification and partial decoding of EAR
     payloads.  The maturity level is currently pre-alpha, and only the
     JWT serialization is implemented.  The license is Apache 2.0.  The
     library targets relying party applications that need to verify
     attestation results.

  6.1.3.  github.com/veraison/rust-ear

     The software, hosted at https://github.com/veraison/rust-ear,
     provides a Rust (2021 edition) library that allows verification and
     partial decoding of EAR payloads.  The maturity level is currently
     pre-alpha, with limitted algorithm support.  Both JWT and COSE
     serializations are implemented.  The license is Apache 2.0.  The
     library targets verifiers that need to produce attestation results as
     well as relying party applications that need to verify and consume
     attestation results.

  7.  Security Considerations

     TODO Security

  8.  Privacy Considerations

     EAR is designed to expose as little identifying information as
     possible about the attester.  However, certain EAR claims have direct
     privacy implications.  Implementations should therefore allow
     applying privacy-preserving techniques to those claims, for example
     allowing their redaction, anonymisation or outright removal.
     Specifically:

     *  It SHOULD be possible to disable inclusion of the optional
        ear.raw-evidence claim

     *  It SHOULD be possible to disable inclusion of the optional
        ear.veraison.annotated-evidence claim

     *  It SHOULD be possible to allow redaction, anonymisation or removal
        of specific claims from the ear.veraison.annotated-evidence object

     EAR is an EAT, therefore the privacy considerations in Section 8 of
     [I-D.ietf-rats-eat] apply.





  Fossati, et al.          Expires 10 August 2025                [Page 19]


  Internet-Draft                     EAR                     February 2025


  9.  IANA Considerations

  9.1.  New EAT Claims

     This specification adds the following values to the "JSON Web Token
     Claims" registry [IANA.jwt] and the "CBOR Web Token Claims" registry
     [IANA.cwt].

     Each entry below is an addition to both registries.

     The "Claim Description", "Change Controller" and "Specification
     Documents" are common and equivalent for the JWT and CWT registries.
     The "Claim Key" and "Claim Value Types(s)" are for the CWT registry
     only.  The "Claim Name" is as defined for the CWT registry, not the
     JWT registry.  The "JWT Claim Name" is equivalent to the "Claim Name"
     in the JWT registry.

  9.1.1.  EAR Status

     *  Claim Name: ear.status

     *  Claim Description: EAR Status

     *  JWT Claim Name: ear.status

     *  Claim Key: 1000

     *  Claim Value Type(s): unsigned integer (0, 2, 32, 96)

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis

  9.1.2.  Trustworthiness Vector

     *  Claim Name: ear.trustworthiness-vector

     *  Claim Description: EAR Trustworthiness Vector

     *  JWT Claim Name: ear.trustworthiness-vector

     *  Claim Key: 1001

     *  Claim Value Type(s): map

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis



  Fossati, et al.          Expires 10 August 2025                [Page 20]


  Internet-Draft                     EAR                     February 2025


  9.1.3.  EAR Raw Evidence

     *  Claim Name: ear.raw-evidence

     *  Claim Description: EAR Raw Evidence

     *  JWT Claim Name: ear.raw-evidence

     *  Claim Key: 1002

     *  Claim Value Type(s): bytes

     *  Change Controller: IESG

     *  Specification Document(s): Section 3 of RFCthis

  9.1.4.  EAR Appraisal Policy Identifier

     *  Claim Name: ear.appraisal-policy-id

     *  Claim Description: EAR Appraisal Policy Identifier

     *  JWT Claim Name: ear.appraisal-policy-id

     *  Claim Key: 1003

     *  Claim Value Type(s): text

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis

  9.1.5.  Verifier Software Identifier

     *  Claim Name: ear.verifier-id

     *  Claim Description: AR4SI Verifier Software Identifier

     *  JWT Claim Name: ear.verifier-id

     *  Claim Key: 1004

     *  Claim Value Type(s): map

     *  Change Controller: IESG

     *  Specification Document(s): Section 3 of RFCthis




  Fossati, et al.          Expires 10 August 2025                [Page 21]


  Internet-Draft                     EAR                     February 2025


  9.1.6.  EAR TEEP Claims

     TODO

  10.  References

  10.1.  Normative References

     [I-D.ietf-rats-ar4si]
                Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
                Scarlata, "Attestation Results for Secure Interactions",
                Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
                08, 6 February 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                ar4si-08>.

     [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-eat-media-type]
                Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
                Types", Work in Progress, Internet-Draft, draft-ietf-rats-
                eat-media-type-12, 3 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                eat-media-type-12>.

     [I-D.ietf-teep-protocol]
                Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and
                A. Tsukamoto, "Trusted Execution Environment Provisioning
                (TEEP) Protocol", Work in Progress, Internet-Draft, draft-
                ietf-teep-protocol-20, 5 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-teep-
                protocol-20>.

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.



  Fossati, et al.          Expires 10 August 2025                [Page 22]


  Internet-Draft                     EAR                     February 2025


     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

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

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

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

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

  10.2.  Informative References

     [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
                <https://www.iana.org/assignments/cwt>.

     [IANA.jwt] IANA, "JSON Web Token (JWT)",
                <https://www.iana.org/assignments/jwt>.

     [RFC4151]  Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
                RFC 4151, DOI 10.17487/RFC4151, October 2005,
                <https://www.rfc-editor.org/rfc/rfc4151>.

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







  Fossati, et al.          Expires 10 August 2025                [Page 23]


  Internet-Draft                     EAR                     February 2025


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

  Appendix A.  Common CDDL Types

     non-empty
        A CDDL generic that can be used to ensure the presence of at least
        one item in an object with only optional fields.

     non-empty<M> = (M) .within ({ + any => any })

  Appendix B.  Open Policy Agent Example

     Open Policy Agent OPA (https://www.openpolicyagent.org) is a popular
     and flexible policy engine that is used in a variety of contexts,
     from cloud to IoT.  OPA policies are written using a purpose-built,
     declarative programming language called Rego
     (https://www.openpolicyagent.org/docs/latest/policy-language/).  Rego
     has been designed to handle JSON claim-sets and their JWT envelopes
     as first class objects, which makes it an excellent fit for dealing
     with JWT EARs.

     The following example illustrates an OPA policy that a Relying Party
     would use to make decisions based on a JWT EAR received from a
     trusted verifier.
























  Fossati, et al.          Expires 10 August 2025                [Page 24]


  Internet-Draft                     EAR                     February 2025


     package ear

     ear_appraisal = {
         "verified": signature_verified,
         "appraisal-status": status,
         "trustworthiness-vector": trust_vector,
     } {
         # verify EAR signature is correct and from one of the known and
         # trusted verifiers
         signature_verified := io.jwt.verify_es256(
             input.ear_token,
             json.marshal(input.trusted_verifiers)
         )

         # extract the EAR claims-set
         [_, payload, _] := io.jwt.decode(input.ear_token)

         # access the attester-specific appraisal record
         app_rec := payload.submods.PARSEC_TPM
         status := app_rec["ear.status"] == "affirming"

         # extract the trustworhiness vector for further inspection
         trust_vector := app_rec["ear.trustworthiness-vector"]
     }

     # add further conditions on the trust_vector here
     # ...

     The result of the policy appraisal is the following JSON object:

     {
         "ear_appraisal": {
             "appraisal-status": true,
             "trustworthiness-vector": {
                 "executables": 2,
                 "hardware": 2,
                 "instance-identity": 2
             },
             "verified": true
         }
     }

     For completeness, the trusted verifier public key and the EAR JWT
     used in the example are provided below.







  Fossati, et al.          Expires 10 August 2025                [Page 25]


  Internet-Draft                     EAR                     February 2025


     =============== NOTE: '\' line wrapping per RFC 8792 ================
     {
         "ear_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXIucmF3L\
     WV2aWRlbmNlIjoiTnpRM01qWTVOek0yTlRZek56UUsiLCJlYXIudmVyaWZpZXItaWQiO\
     nsiYnVpbGQiOiJ2dHMgMC4wLjEiLCJkZXZlbG9wZXIiOiJodHRwczovL3ZlcmFpc29uL\
     XByb2plY3Qub3JnIn0sImVhdF9wcm9maWxlIjoidGFnOmdpdGh1Yi5jb20sMjAyMzp2Z\
     XJhaXNvbi9lYXIiLCJpYXQiOjEuNjY2NTI5MTg0ZSswOSwianRpIjoiNTViOGIzZmFkO\
     GRkMWQ4ZWFjNGU0OGYxMTdmZTUwOGIxMWY4NDRkOWYwMTg5YmZlZDliODc1MTVhNjc1N\
     DI2NCIsIm5iZiI6MTY3NzI0Nzg3OSwic3VibW9kcyI6eyJQQVJTRUNfVFBNIjp7ImVhc\
     i5hcHByYWlzYWwtcG9saWN5LWlkIjoiaHR0cHM6Ly92ZXJhaXNvbi5leGFtcGxlL3Bvb\
     GljeS8xLzYwYTAwNjhkIiwiZWFyLnN0YXR1cyI6ImFmZmlybWluZyIsImVhci50cnVzd\
     HdvcnRoaW5lc3MtdmVjdG9yIjp7ImV4ZWN1dGFibGVzIjoyLCJoYXJkd2FyZSI6Miwia\
     W5zdGFuY2UtaWRlbnRpdHkiOjJ9LCJlYXIudmVyYWlzb24ua2V5LWF0dGVzdGF0aW9uI\
     jp7ImFrcHViIjoiTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFY2pTc\
     DhfTVdNM2d5OFR1Z1dPMVRwUVNqX3ZJa3NMcEMtZzhsNVMzbHBHYjdQV1dHb0NBakVQO\
     F9BNTlWWndMWGd3b1p6TjBXeHVCUGpwYVdpV3NmQ1EifX19fQ.3Ym-f1LEgamxePUM7h\
     6Y2RJDGh9eeL0xKor0n1wE9jdAnLNwm3rTKFV2S2LbqVFoDtK9QGalT2t5RnUdfwZNmg\
     ",
         "trusted_verifiers": {
             "keys": [
                 {
                     "alg": "ES256",
                     "crv": "P-256",
                     "kty": "EC",
                     "x": "usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8",
                     "y": "IBOL-C3BttVivg-lSreASjpkttcsz-1rb7btKLv8EX4"
                 }
             ]
         }
     }

  Appendix C.  Open Issues


     // Note to RFC Editor: please remove before publication.

     The list of currently open issues for this documents can be found at
     https://github.com/thomas-fossati/draft-ear/issues.

  Appendix D.  Document History


     // Note to RFC Editor: please remove before publication.

  D.1.  draft-fv-rats-ear-00

     Initial release.




  Fossati, et al.          Expires 10 August 2025                [Page 26]


  Internet-Draft                     EAR                     February 2025


  D.2.  draft-fv-rats-ear-01

     *  privacy considerations

     *  OPA policy example

     *  add rust-ear crate to the implementation status section

  D.3.  draft-fv-rats-ear-02

     *  align JWT and CWT representations of eat_nonce

  Acknowledgments

     Many thanks to Dave Thaler, Greg Kostal, Simon Frost, Yogesh
     Deshpande for helpful comments and discussions that have shaped this
     document.

  Authors' Addresses

     Thomas Fossati
     Linaro
     Email: thomas.fossati@linaro.org


     Eric Voit
     Cisco
     Email: evoit@cisco.com


     Sergei Trofimov
     Arm Limited
     Email: sergei.trofimov@arm.com


     Henk Birkholz
     Fraunhofer SIT
     Rheinstrasse 75
     64295 Darmstadt
     Germany
     Email: henk.birkholz@ietf.contact










  Fossati, et al.          Expires 10 August 2025                [Page 27]


name: draft-howard-rats-coserv
rev: 04
title: Concise Selector for Endorsements and Reference Values
time: 2025-08-12T13:06:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-21T11:35:52Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.301157+00:00
source: ietf
source_id: 145213
source_url: https://datatracker.ietf.org/doc/draft-howard-rats-coserv/
doc_status: active
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.

full_text:
  Remote ATtestation ProcedureS                                  P. Howard
  Internet-Draft                                                       Arm
  Intended status: Informational                                T. Fossati
  Expires: 21 January 2026                                          Linaro
                                                               H. Birkholz
                                                            Fraunhofer SIT
                                                                  S. Kamal
                                                                   Fujitsu
                                                              20 July 2025


           Concise Selector for Endorsements and Reference Values
                        draft-howard-rats-coserv-04

  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, et al.           Expires 21 January 2026                [Page 1]


  Internet-Draft                   CoSERV                        July 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 21 January 2026.

  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.  Aggregation and Trust Models  . . . . . . . . . . . . . . . .   5
     3.  CoSERV Information Model  . . . . . . . . . . . . . . . . . .   6
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Artifacts . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  Environments  . . . . . . . . . . . . . . . . . . . . . .   8
         3.3.1.  Stateful Environments . . . . . . . . . . . . . . . .   8
       3.4.  Queries . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.5.  Result Sets . . . . . . . . . . . . . . . . . . . . . . .  10
     4.  CoSERV Data Model . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  Common Data Types . . . . . . . . . . . . . . . . . . . .  11
       4.2.  Profile . . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.3.  Query Structure . . . . . . . . . . . . . . . . . . . . .  12
         4.3.1.  Artifact Type . . . . . . . . . . . . . . . . . . . .  12
         4.3.2.  Environment Selector  . . . . . . . . . . . . . . . .  12
         4.3.3.  Timestamp . . . . . . . . . . . . . . . . . . . . . .  14
         4.3.4.  Result Type . . . . . . . . . . . . . . . . . . . . .  15
       4.4.  Result Set Structure  . . . . . . . . . . . . . . . . . .  15
       4.5.  Encoding Requirements . . . . . . . . . . . . . . . . . .  16



  Howard, et al.           Expires 21 January 2026                [Page 2]


  Internet-Draft                   CoSERV                        July 2025


       4.6.  Cryptographic Binding Between Query and Result Set  . . .  16
     5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       5.1.  Query Data Examples . . . . . . . . . . . . . . . . . . .  17
       5.2.  Result Data Examples  . . . . . . . . . . . . . . . . . .  19
     6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  21
       6.1.  Veraison  . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
       7.1.  Forming Native Database Queries from CoSERV . . . . . . .  23
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
       9.1.  Media Types Registrations . . . . . . . . . . . . . . . .  23
         9.1.1.  application/coserv+cbor . . . . . . . . . . . . . . .  24
         9.1.2.  application/coserv+cose . . . . . . . . . . . . . . .  24
       9.2.  CoAP Content-Formats  . . . . . . . . . . . . . . . . . .  25
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       10.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Collated CoSERV CDDL . . . . . . . . . . . . . . . .  27
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

  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



  Howard, et al.           Expires 21 January 2026                [Page 3]


  Internet-Draft                   CoSERV                        July 2025


     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.

     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.











  Howard, et al.           Expires 21 January 2026                [Page 4]


  Internet-Draft                   CoSERV                        July 2025


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

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

     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



  Howard, et al.           Expires 21 January 2026                [Page 5]


  Internet-Draft                   CoSERV                        July 2025


     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.

  3.  CoSERV Information Model

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









  Howard, et al.           Expires 21 January 2026                [Page 6]


  Internet-Draft                   CoSERV                        July 2025


  3.2.  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 three artifact types.  These
     correspond to the three categories of endorsement artifact that can
     be identified natively in the RATS architecture:

     *  *Trust Anchor*: 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 can verify the cryptographic
        signature.

     *  *Endorsed Value*: An endorsed value is as defined in Section 1.1.1
        of [I-D.ietf-rats-corim].  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
        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.

     When artifacts are produced by an aggregator (see Section 2), 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 Arfifacts*: 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.







  Howard, et al.           Expires 21 January 2026                [Page 7]


  Internet-Draft                   CoSERV                        July 2025


     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.

  3.3.  Environments

     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 [I-D.ietf-rats-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.

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



  Howard, et al.           Expires 21 January 2026                [Page 8]


  Internet-Draft                   CoSERV                        July 2025


     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 [I-D.ietf-rats-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.

  3.4.  Queries

     The purpose of a query is to allow the consumer (Verifier) to specify
     the artifacts that it needs.  The information that is conveyed in a
     CoSERV query includes the following:

     *  A specification of the required artifact type: Reference Value,
        Endorsed Value or Trust Anchor.  See Section 3.2 for definitions
        of artifact types.  A single CoSERV query can only specify a
        single artifact type.

     *  A specification of the Attester's environment.  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 Section 3.3
        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 timestamp, denoting the time at which the CoSERV query was sent.

     *  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



  Howard, et al.           Expires 21 January 2026                [Page 9]


  Internet-Draft                   CoSERV                        July 2025


        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
        Section 2 for details on aggregation, auditing and trust models.

  3.5.  Result Sets

     The result set contains the artifacts that the producer collected in
     response to the query.  The top-level structure of the result set
     consists of the following three items:

     *  A collection of one or more result entries.  This will be a
        collection of either reference values, endorsed values or trust
        anchors.  See Section 3.2 for definitions of artifact types.  In
        the future, it may be possible to support additional artifact
        types via an extension mechanism.  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 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.

     *  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
     Section 5.1.4 of [I-D.ietf-rats-corim].  Each CoMID triple will
     demonstrate the association between an environment matching that of
     the CoSERV query, and a single artifact such as a reference value,
     trust anchor or endorsed value.  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.



  Howard, et al.           Expires 21 January 2026               [Page 10]


  Internet-Draft                   CoSERV                        July 2025


     Because each result entry combines a CoMID triple with an authority
     delegation chain, the entries are consequently known as quadruples
     (or "quads" for short).

  4.  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:

     ;# import comid-autogen

     coserv = {
       &(profile: 0) => profile
       &(query: 1) => query
       ? &(results: 2) => results
     }

     profile = comid.oid-type / ~uri

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

  4.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].






  Howard, et al.           Expires 21 January 2026               [Page 11]


  Internet-Draft                   CoSERV                        July 2025


  4.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:

     query = {
       &(artifact-type: 0) => artifact-type
       &(environment-selector: 1) => environment-selector-map
       &(timestamp: 2) => tdate ; RFC3339 date
       &(result-type: 3) => result-type
     }

     artifact-type = &(endorsed-values: 0)
                     / &(trust-anchors: 1)
                     / &(reference-values: 2)

     result-type = &(collected-artifacts: 0)
                   / &(source-artifacts: 1)
                   / &(both: 2)

     The meanings of these fields are detailed in the following
     subsections.

  4.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).

     See Section 3.2 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.

  4.3.2.  Environment Selector

     The environment selector forms the main body of the query, and its
     CDDL is given below:



  Howard, et al.           Expires 21 January 2026               [Page 12]


  Internet-Draft                   CoSERV                        July 2025


     ;# import comid-autogen

     environment-selector-map = { selector }

     stateful-class = [
       class: comid.class-map
       ? measurements: [ + comid.measurement-map ]
     ]

     selector //= ( &(class: 0) => [
       + 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 Section 3.3 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.





  Howard, et al.           Expires 21 January 2026               [Page 13]


  Internet-Draft                   CoSERV                        July 2025


     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 Section 3.3.1 for a
     description of stateful environments.

  4.3.2.1.  Selector Semantics

     When multiple environment selectors are present in a single query,
     such as multiple instances or multiple groups, the implementation of
     the artifact producer 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:

     SELECT *
       FROM endorsed_values
      WHERE ( instance-id = "At6tvu/erQ==" ) OR
            ( instance-id = "iZl4ZVY=" )`

     The same applies for class-based selectors; however, since class
     selectors are themselves composed of multiple inner fields, the
     implementation of the artifact producer 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:

     SELECT *
       FROM reference_values
      WHERE ( class-id = "iZl4ZVY=" AND class-vendor = "ACME Inc." ) OR
            ( class-id = "31fb5abf-023e-4992-aa4e-95f9c1503bfa" )

  4.3.3.  Timestamp

     The timestamp field records the date and time at which the query was
     made, formatted according to Section 3.4.1 of [STD94].
     Implementations SHOULD populate this field with the current date and
     time when forming a CoSERV query.






  Howard, et al.           Expires 21 January 2026               [Page 14]


  Internet-Draft                   CoSERV                        July 2025


  4.3.4.  Result Type

     The result-type field selects for either collected-artifacts
     (codepoint 0), source-artifacts (codepoint 1) or both (codepoint 2).
     See Section 2 for definitions of source and collected artifacts.

  4.4.  Result Set Structure

     The result set structure is given by the following CDDL:

     ;# import cmw-autogen
     ;# import comid-autogen

     results = {
       result-set
       &(expiry: 10) => tdate ; RFC3339 date
       ? &(source-artifacts: 11) => [ + cmw.cbor-record ]
     }

     result-set //= reference-values
     result-set //= endorsed-values
     result-set //= trust-anchors
     result-set //= $$result-set-extensions

     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 ]
     )




  Howard, et al.           Expires 21 January 2026               [Page 15]


  Internet-Draft                   CoSERV                        July 2025


     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 ]
     )

     ;
     ; import CoTS
     ;
     cots = "TODO COTS"

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

  4.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 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
     [STD96].  A signed-coserv is a COSE_Sign1 with the following layout:




  Howard, et al.           Expires 21 January 2026               [Page 16]


  Internet-Draft                   CoSERV                        July 2025


     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.

  5.  Examples

  5.1.  Query Data Examples

     This section provides some illustrative examples of valid CoSERV
     query objects.

     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.









  Howard, et al.           Expires 21 January 2026               [Page 17]


  Internet-Draft                   CoSERV                        July 2025


     {
       / 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"
             }
           ] ]
         },
         / timestamp /   2: 0("2030-12-01T18:30:01Z"),
         / result-type / 3: 1 / source-material /
       }
     }

     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 /
             } ]
           ]
         },
         / timestamp /   2: 0("2030-12-01T18:30:01Z"),
         / result-type / 3: 2 / both collected and source material /
       }
     }








  Howard, et al.           Expires 21 January 2026               [Page 18]


  Internet-Draft                   CoSERV                        July 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 /
           ]
         },
         / timestamp /   2: 0("2030-12-01T18:30:01Z"),
         / result-type / 3: 0 / collected material /
       }
     }

  5.2.  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 [I-D.ietf-rats-corim].











  Howard, et al.           Expires 21 January 2026               [Page 19]


  Internet-Draft                   CoSERV                        July 2025


     {
       / profile / 0: "tag:example.com,2025:cc-platform#1.0.0",
       / query / 1: {
         0: 2,
         1: {
           0: [ [
             {
               0: 560(h'8999786556')
             }
           ] ]
         },
         2: 0("2030-12-01T18:30:01Z"),
         3: 0
       },
       / results / 2: {
         0: [
           {
             1: [ 560(h'abcdef') ],
             2: [
               {
                 0: {
                   0: 560(h'8999786556')
                 }
               },
               [
                 {
                   0: 37(h'31FB5ABF023E4992AA4E95F9C1503BFA'),
                   1: {
                     / version / 0: {
                       0: "1.2.3",
                       1: 16384
                     },
                     / svn / 1: 553(2)
                   }
                 }
               ]
             ]
           }
         ],
         10: 0("2030-12-13T18:30:02Z")
       }
     }

     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.




  Howard, et al.           Expires 21 January 2026               [Page 20]


  Internet-Draft                   CoSERV                        July 2025


     Compared with the previous example, the rvq entry is empty, while the
     source-artifacts (codepoint 11) contain two CMW records
     [I-D.ietf-rats-msg-wrap], each of which contains a (made up) manifest
     with the type "application/vnd.example.refvals".

     {
       / 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"
             }
           ] ]
         },
         / timestamp /   2: 0("2030-12-01T18:30:01Z"),
         / result-type / 3: 1 / source-artifacts /
       },
       / results / 2: {
         / rvq / 0: [ ],
         / expiry / 10: 0("2030-12-13T18:30:02Z"),
         / source artifacts / 11: [
           [ "application/vnd.example.refvals", h'afaeadac' ],
           [ "application/vnd.example.refvals", h'adacabaa' ]
         ]
       }
     }

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



  Howard, et al.           Expires 21 January 2026               [Page 21]


  Internet-Draft                   CoSERV                        July 2025


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

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

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



  Howard, et al.           Expires 21 January 2026               [Page 22]


  Internet-Draft                   CoSERV                        July 2025


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

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

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

  9.  IANA Considerations


     // RFC Editor: replace "RFCthis" with the RFC number assigned to this
     document.

  9.1.  Media Types Registrations

     IANA is requested to add the following media types to the "Media
     Types" registry [IANA.media-types].




  Howard, et al.           Expires 21 January 2026               [Page 23]


  Internet-Draft                   CoSERV                        July 2025


      +=============+=========================+========================+
      | Name        | Template                | Reference              |
      +=============+=========================+========================+
      | coserv+cbor | application/coserv+cbor | Section 4 of RFCthis   |
      +-------------+-------------------------+------------------------+
      | coserv+cose | application/coserv+cose | Section 4.6 of RFCthis |
      +-------------+-------------------------+------------------------+

                         Table 1: CoSERV Media Types

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

  9.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 7 of RFCthis
     Interoperability considerations:  n/a
     Published specification:  RFCthis



  Howard, et al.           Expires 21 January 2026               [Page 24]


  Internet-Draft                   CoSERV                        July 2025


     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

  9.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 4   |
     |                         |                |      | of RFCthis  |
     +-------------------------+----------------+------+-------------+
     | application/coserv+cose | -              | TBD2 | Section 4.6 |
     |                         |                |      | of RFCthis  |
     +-------------------------+----------------+------+-------------+

                     Table 2: New CoAP Content Formats

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

  10.  References

  10.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-08, 7 July
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                rats-corim-08>.

     [I-D.ietf-rats-msg-wrap]
                Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
                D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
                in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-16,
                3 July 2025, <https://datatracker.ietf.org/doc/html/draft-
                ietf-rats-msg-wrap-16>.



  Howard, et al.           Expires 21 January 2026               [Page 25]


  Internet-Draft                   CoSERV                        July 2025


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

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

  10.2.  Informative References






  Howard, et al.           Expires 21 January 2026               [Page 26]


  Internet-Draft                   CoSERV                        July 2025


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

     [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

     ;# import comid-autogen

     coserv = {
       &(profile: 0) => profile
       &(query: 1) => query
       ? &(results: 2) => results
     }

     profile = comid.oid-type / ~uri



  Howard, et al.           Expires 21 January 2026               [Page 27]


  Internet-Draft                   CoSERV                        July 2025


     ;# import comid-autogen

     environment-selector-map = { selector }

     stateful-class = [
       class: comid.class-map
       ? measurements: [ + comid.measurement-map ]
     ]

     selector //= ( &(class: 0) => [
       + 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
     ] )

     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
     }

     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 ]
       }>
     ]



  Howard, et al.           Expires 21 January 2026               [Page 28]


  Internet-Draft                   CoSERV                        July 2025


     $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
     }

     cose-label = int / tstr
     cose-value = any

     coswid-triple-record = [
       environment-map
       [ + concise-swid-tag-id ]
     ]




  Howard, et al.           Expires 21 January 2026               [Page 29]


  Internet-Draft                   CoSERV                        July 2025


     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

     endorsed-triple-record = [
       condition: environment-map
       endorsement: [ + measurement-map ]
     ]

     entity-map<role-type-choice, extension-socket> = {
       &(entity-name: 0) => $entity-name-type-choice



  Howard, et al.           Expires 21 January 2026               [Page 30]


  Internet-Draft                   CoSERV                        July 2025


       ? &(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
     $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




  Howard, et al.           Expires 21 January 2026               [Page 31]


  Internet-Draft                   CoSERV                        July 2025


     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
       ? &(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 })



  Howard, et al.           Expires 21 January 2026               [Page 32]


  Internet-Draft                   CoSERV                        July 2025


     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)

     tag-version-type = uint .default 0

     tagged-bytes = #6.560(bytes)

     triples-map = non-empty<{
       ? &(reference-triples: 0) =>
         [ + reference-triple-record ]



  Howard, et al.           Expires 21 January 2026               [Page 33]


  Internet-Draft                   CoSERV                        July 2025


       ? &(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
     }

     concise-swid-tag = {
       tag-id => text / bstr .size 16,
       tag-version => integer,
       ? corpus => bool,
       ? patch => bool,



  Howard, et al.           Expires 21 January 2026               [Page 34]


  Internet-Draft                   CoSERV                        July 2025


       ? 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,
     ]

     entity-entry = {
       entity-name => text,
       ? reg-id => any-uri,
       role => one-or-more<$role>,
       ? thumbprint => hash-entry,
       * $$entity-extension,



  Howard, et al.           Expires 21 January 2026               [Page 35]


  Internet-Draft                   CoSERV                        July 2025


       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
     $use /= required
     $use /= recommended
     $use /= int / text

     software-meta-entry = {
       ? activation-status => text,



  Howard, et al.           Expires 21 January 2026               [Page 36]


  Internet-Draft                   CoSERV                        July 2025


       ? 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,
       global-attributes,
     }

     process-entry = {
       process-name => text,
       ? pid => integer,



  Howard, et al.           Expires 21 January 2026               [Page 37]


  Internet-Draft                   CoSERV                        July 2025


       * $$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
     corpus = 8
     patch = 9
     media = 10
     supplemental = 11
     tag-version = 12
     software-version = 13



  Howard, et al.           Expires 21 January 2026               [Page 38]


  Internet-Draft                   CoSERV                        July 2025


     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
     unspsc-version = 57

     multipartnumeric = 1
     multipartnumeric-suffix = 2
     alphanumeric = 3
     decimal = 4



  Howard, et al.           Expires 21 January 2026               [Page 39]


  Internet-Draft                   CoSERV                        July 2025


     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


     Henk Birkholz
     Fraunhofer SIT
     Email: henk.birkholz@ietf.contact




  Howard, et al.           Expires 21 January 2026               [Page 40]


  Internet-Draft                   CoSERV                        July 2025


     Shefali Kamal
     Fujitsu
     Email: Shefali.Kamal@fujitsu.com
















































  Howard, et al.           Expires 21 January 2026               [Page 41]


name: draft-zzn-dvs
rev: 00
title: Domain-Verified Skills (DVS) Protocol
time: 2026-03-02T22:59:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T22:59:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.307351+00:00
source: ietf
source_id: 154034
source_url: https://datatracker.ietf.org/doc/draft-zzn-dvs/
doc_status: active
abstract:
  This document defines the Domain-Verified Skills (DVS) protocol, a
     lightweight mechanism for AI Agents to discover, verify, and execute
     skill definitions served over HTTPS.  A skill is a directory
     containing a SKILL.md entry point and optional bundled resources that
     instructs an AI Agent to perform a specific task or adopt a specific
     behavior.

     The central design principle of DVS is that a skill's identity and
     trustworthiness are derived entirely from the HTTPS URL at which it
     is served -- no centralized registry or third-party certification is
     required.  The operator of the URL's origin is the authoritative
     endorser of the skill.

     This trust is formalized through the concept of a Trust Root: an
     HTTPS URL prefix declared by the skill publisher that scopes the
     trust boundary for their skills.  A skill is considered verified if
     and only if its URL begins with the declared Trust Root.  For brands
     with first-party domains, the Trust Root is the domain origin.  For
     brands publishing on user-generated content platforms where the
     platform operator does not vouch for individual publishers, the Trust
     Root MUST be path-scoped to content the brand controls, ensuring that
     trust does not extend to the entire platform.

     The protocol leverages the existing trust infrastructure of the
     Domain Name System (DNS) and Transport Layer Security (TLS) and is
     backward compatible with skills already served over HTTPS, including
     those hosted on GitHub or other platforms.

full_text:
  Network Working Group                                         Z. V. Zhou
  Internet-Draft                                                    Namefi
  Intended status: Informational                              2 March 2026
  Expires: 3 September 2026


                   Domain-Verified Skills (DVS) Protocol
                              draft-zzn-dvs-00

  Abstract

     This document defines the Domain-Verified Skills (DVS) protocol, a
     lightweight mechanism for AI Agents to discover, verify, and execute
     skill definitions served over HTTPS.  A skill is a directory
     containing a SKILL.md entry point and optional bundled resources that
     instructs an AI Agent to perform a specific task or adopt a specific
     behavior.

     The central design principle of DVS is that a skill's identity and
     trustworthiness are derived entirely from the HTTPS URL at which it
     is served -- no centralized registry or third-party certification is
     required.  The operator of the URL's origin is the authoritative
     endorser of the skill.

     This trust is formalized through the concept of a Trust Root: an
     HTTPS URL prefix declared by the skill publisher that scopes the
     trust boundary for their skills.  A skill is considered verified if
     and only if its URL begins with the declared Trust Root.  For brands
     with first-party domains, the Trust Root is the domain origin.  For
     brands publishing on user-generated content platforms where the
     platform operator does not vouch for individual publishers, the Trust
     Root MUST be path-scoped to content the brand controls, ensuring that
     trust does not extend to the entire platform.

     The protocol leverages the existing trust infrastructure of the
     Domain Name System (DNS) and Transport Layer Security (TLS) and is
     backward compatible with skills already served over HTTPS, including
     those hosted on GitHub or other platforms.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Zhou                    Expires 3 September 2026                [Page 1]


  Internet-Draft                     DVS                        March 2026


     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 3 September 2026.

  Copyright Notice

     Copyright (c) 2026 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Core Protocol . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Identity and Trust  . . . . . . . . . . . . . . . . . . .   4
       3.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Skill Specification . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Directory Structure . . . . . . . . . . . . . . . . . . .   6
       4.2.  SKILL.md Entry Point  . . . . . . . . . . . . . . . . . .   6
       4.3.  Metadata (Frontmatter)  . . . . . . . . . . . . . . . . .   6
       4.4.  Instructions (Body) . . . . . . . . . . . . . . . . . . .   7
       4.5.  Bundled Resources . . . . . . . . . . . . . . . . . . . .   7
         4.5.1.  Additional Instructions . . . . . . . . . . . . . . .   7
         4.5.2.  Executable Scripts  . . . . . . . . . . . . . . . . .   7
         4.5.3.  Data and Reference Materials  . . . . . . . . . . . .   8
       4.6.  Progressive Loading . . . . . . . . . . . . . . . . . . .   8
     5.  Security and Permissions  . . . . . . . . . . . . . . . . . .   8
       5.1.  Same-Origin Isolation . . . . . . . . . . . . . . . . . .   9
       5.2.  Explicit Consent  . . . . . . . . . . . . . . . . . . . .   9
       5.3.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  Composition . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12




  Zhou                    Expires 3 September 2026                [Page 2]


  Internet-Draft                     DVS                        March 2026


  1.  Introduction

     Current AI Agent skills (such as those in the Claude Agent Skills
     protocol [CLAUDE-SKILLS]) are primarily distributed via centralized
     code repositories or platform-specific upload mechanisms.  This
     creates several friction points:

     *  Identity Ambiguity: Users cannot easily verify if a skill hosted
        on a third-party platform genuinely belongs to a brand.

     *  Hosting Friction: Brands must manage external accounts and
        synchronization instead of using their existing web
        infrastructure.

     *  Security Risks: Malicious skills can spoof brand names on open
        platforms to exfiltrate data.

     The Domain-Verified Skills (DVS) protocol returns to the fundamental
     logic of the Web: the URL is the Identity.  By serving skills
     directly from a brand-controlled URL prefix, we leverage the existing
     global trust of the DNS and HTTPS infrastructure.

     For brands with first-party domains, the Trust Root is the domain
     itself (e.g., https://microsoft.com/).  For brands that publish on
     user-generated content platforms such as GitHub or Hugging Face, the
     Trust Root is scoped to the brand's path on that platform (e.g.,
     https://github.com/microsoft/).  This allows DVS to provide brand-
     verified skill identity across all hosting configurations, without
     requiring brands to self-host infrastructure.

     This protocol is designed to be compatible with existing skill
     formats and distributions.  A skill already hosted on GitHub (e.g.,
     https://github.com/microsoft/repo/blob/main/.../SKILL.md) is
     immediately usable under DVS by registering https://github.com/
     microsoft/ as the Trust Root, with no changes to the skill files
     themselves.  In particular, a skill directory conforming to DVS can
     be directly consumed by any agent that understands the SKILL.md
     convention, while also gaining the identity and trust properties
     conferred by domain-verified hosting.

  2.  Conventions and Definitions

     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.




  Zhou                    Expires 3 September 2026                [Page 3]


  Internet-Draft                     DVS                        March 2026


     The following terms are used in this document:

     Skill:  A directory containing a SKILL.md entry point and optional
        bundled resources (scripts, templates, data files, additional
        instructions) that directs an AI Agent to perform a specific task
        or adopt a specific behavior.

     SKILL.md:  The mandatory Markdown entry-point file within a skill
        directory.  It contains YAML frontmatter metadata and human-
        readable instructions for the Agent.

     Agent:  An AI system capable of fetching, interpreting, and executing
        Skill instructions.

     Skill URL:  The HTTPS URL of the skill directory (or its SKILL.md
        entry point).  This URL serves as the globally unique identifier
        of the Skill.

     Trust Root:  An HTTPS URL prefix that defines the trust boundary for
        a skill or set of skills.  A skill is considered verified under a
        Trust Root if and only if its Skill URL begins with the Trust Root
        prefix.  For first-party brand domains, the Trust Root is
        typically the domain origin (e.g., https://microsoft.com/).  For
        user-generated content platforms, the Trust Root MUST be scoped to
        a path controlled by the brand (e.g., https://github.com/
        microsoft/).

     Hosting Domain:  The domain component of the Trust Root URL,
        considered the network-level endorser of the Skill via DNS and
        TLS.

     Bundled Resource:  Any file within the skill directory other than
        SKILL.md, including additional instruction files, executable
        scripts, templates, schemas, and data files.

  3.  Core Protocol

     The identity of a skill is defined strictly by its HTTPS URL.

  3.1.  Identity and Trust

     Skills MUST be served via HTTPS [RFC9110].  Agents MUST NOT fetch or
     execute skills served over plain HTTP.

     The identity and trust of a skill is defined by its Trust Root.  A
     skill's URL MUST begin with its declared Trust Root prefix for the
     skill to be considered verified under that root.




  Zhou                    Expires 3 September 2026                [Page 4]


  Internet-Draft                     DVS                        March 2026


     For first-party brand hosting, the Trust Root is the domain origin:

     Trust Root: https://example.com/
     Skill URL:  https://example.com/.well-known/
                 skills/support/SKILL.md

     For user-generated content platforms, the Trust Root MUST be scoped
     to a path controlled by the brand.  Agents MUST NOT accept a bare UGC
     platform domain (e.g., https://github.com/) as a Trust Root, as this
     would confer trust to all content on the platform:

     Trust Root: https://github.com/example-org/
     Skill URL:  https://github.com/example-org/
                 repo/blob/main/skills/SKILL.md

     A skill URL that does not begin with its declared Trust Root prefix
     MUST be rejected by the Agent.

  3.2.  Discovery

     Skills MAY be hosted at any valid URL path on a domain (e.g.,
     https://example.com/skills/my-assistant/SKILL.md).

     Official brand skills SHOULD be served from the well-known path
     prefix:

     /.well-known/skills/{skill-name}/SKILL.md

     This follows the conventions established by [RFC8615] for well-known
     URIs.

     Skills MAY be indexed in the domain's sitemap.xml [SITEMAP] to enable
     automated agent discovery.  Agents supporting discovery SHOULD check
     for skill entries in the sitemap when exploring a domain's available
     skills.

     A domain MAY serve a skill index document at:

     /.well-known/skills/index.json

     The index document, if present, SHOULD contain an array of objects,
     each with name, description, and path fields pointing to available
     skills on the domain.

  4.  Skill Specification






  Zhou                    Expires 3 September 2026                [Page 5]


  Internet-Draft                     DVS                        March 2026


  4.1.  Directory Structure

     A Domain-Verified Skill is a directory containing at minimum a
     SKILL.md file.  The directory MAY contain additional files organized
     by purpose:

     my-skill/
     +-- SKILL.md              (entry point - REQUIRED)
     +-- ADVANCED.md           (additional instructions - OPTIONAL)
     +-- REFERENCE.md          (detailed reference docs - OPTIONAL)
     +-- scripts/
     |   +-- process.py        (executable script - OPTIONAL)
     |   +-- validate.sh       (executable script - OPTIONAL)
     +-- templates/
     |   +-- report.html       (template file - OPTIONAL)
     +-- data/
         +-- schema.json       (data/reference file - OPTIONAL)

     When served over HTTPS, the directory structure is represented by URL
     paths relative to the skill's base URL.  For example, a skill at
     https://example.com/.well-known/skills/my-skill/ would have its entry
     point at:

     https://example.com/.well-known/skills/my-skill/SKILL.md

     And a bundled script at:

     https://example.com/.well-known/skills/my-skill/scripts/process.py

  4.2.  SKILL.md Entry Point

     Every skill directory MUST contain a file named SKILL.md.  This file
     MUST be encoded in UTF-8 and served with the media type text/markdown
     [RFC7763].

     The file consists of two parts:

     1.  YAML frontmatter (metadata) - REQUIRED

     2.  Markdown body (instructions) - REQUIRED

  4.3.  Metadata (Frontmatter)

     SKILL.md files MUST begin with a YAML frontmatter block delimited by
     --- lines.  The frontmatter MUST contain the following fields:

     name:  A short, human-readable name for the skill.  MUST NOT exceed




  Zhou                    Expires 3 September 2026                [Page 6]


  Internet-Draft                     DVS                        March 2026


        64 characters.  MUST contain only lowercase letters, numbers, and
        hyphens.

     description:  A brief description of the skill's purpose and
        capabilities, including guidance on when an Agent should trigger
        the skill.  MUST NOT be empty.  MUST NOT exceed 1024 characters.

     Example:

     name: customer-support
     description: Handles common customer support inquiries for
       Acme Corp products. Use when the user asks about product
       returns, warranty claims, or order status.

  4.4.  Instructions (Body)

     The body of SKILL.md, following the frontmatter, MUST contain human-
     readable instructions for the Agent.  These instructions define the
     behavior, constraints, and capabilities of the skill.

     Instructions SHOULD be written as clear, step-by-step procedural
     guidance.  They MAY reference bundled resources using relative URLs
     (e.g., [see advanced guide](ADVANCED.md) or run the script at
     scripts/process.py).

  4.5.  Bundled Resources

     Skills MAY include additional files alongside SKILL.md.  These
     bundled resources fall into three categories:

  4.5.1.  Additional Instructions

     Additional Markdown files (e.g., ADVANCED.md, REFERENCE.md, FORMS.md)
     provide specialized guidance, detailed API references, or extended
     workflows.  These files:

     *  SHOULD use the .md extension and text/markdown media type.

     *  Are loaded by the Agent only when referenced from SKILL.md or when
        the task context requires them.

  4.5.2.  Executable Scripts

     Scripts (e.g., Python, Shell, JavaScript) provide deterministic
     operations that the Agent can execute.  These files:

     *  MUST reside within the same skill directory (same-origin).




  Zhou                    Expires 3 September 2026                [Page 7]


  Internet-Draft                     DVS                        March 2026


     *  Are executed by the Agent via its runtime environment; only the
        script's output enters the Agent's context, not the script source
        code itself.

     *  MUST be subject to the Explicit Consent requirement defined in
        Section 5.2 before execution.

  4.5.3.  Data and Reference Materials

     Data files (e.g., JSON schemas, CSV datasets, configuration
     templates, API documentation) provide factual lookup material.  These
     files:

     *  MUST reside within the same skill directory (same-origin).

     *  Are read by the Agent on demand when the task requires specific
        reference information.

     *  Impose no context cost until actually accessed.

  4.6.  Progressive Loading

     Agents implementing DVS SHOULD employ a progressive loading strategy
     to manage context efficiently:

     Level 1 - Metadata (always loaded):  The YAML frontmatter (name and
        description) is loaded at agent startup or skill registration
        time.  This enables skill discovery with minimal token cost
        (approximately 100 tokens per skill).

     Level 2 - Instructions (loaded on trigger):  The body of SKILL.md is
        fetched and loaded into the agent's context only when the skill is
        triggered by a matching user request.

     Level 3 - Resources (loaded as needed):  Bundled resources
        (additional markdown files, scripts, data files) are accessed only
        when referenced during execution.  Scripts are executed and only
        their output is loaded into context.

     This three-level approach ensures that a domain can publish many
     skills without imposing context overhead on agents, as only the
     metadata of registered skills is persistently loaded.

  5.  Security and Permissions







  Zhou                    Expires 3 September 2026                [Page 8]


  Internet-Draft                     DVS                        March 2026


  5.1.  Same-Origin Isolation

     Agents MUST restrict a skill's automated access to resources within
     its Trust Root prefix.  A skill with Trust Root https://github.com/
     example-org/ MUST NOT be permitted to automatically access resources
     outside that prefix (including other GitHub users or repos) without
     explicit user consent.

     Bundled resources (scripts, data files, templates) referenced by a
     skill MUST reside within the same Trust Root prefix as the SKILL.md
     file.  Agents MUST reject references to resources outside the skill's
     Trust Root unless the user explicitly approves the access.

     This prevents a compromised or malicious skill from leveraging its
     trusted context to exfiltrate data from, or perform actions on,
     unrelated origins or paths.

  5.2.  Explicit Consent

     Agents MUST display the source domain to the user and request
     explicit confirmation before executing any non-textual instructions
     contained in a skill (e.g., shell commands, API calls, file system
     operations, running bundled scripts).

     The consent prompt SHOULD clearly indicate:

     *  The Trust Root of the skill.

     *  A description of the action to be performed.

     *  Any resources that will be accessed or modified.

     Textual instructions (Markdown content) MAY be loaded without
     additional consent beyond the initial skill activation.  Executable
     content (scripts, commands) MUST always require explicit consent.

  5.3.  DNSSEC

     Domain operators SHOULD deploy DNSSEC [RFC4033] to prevent DNS
     spoofing attacks that could redirect agents to malicious skill files
     hosted on attacker-controlled infrastructure.

  6.  Composition

     A skill MAY reference other skills via their full HTTPS URLs.  When
     an Agent encounters a referenced skill URL during execution, it
     SHOULD dynamically fetch and load the referenced skill if the current
     context requires the extended capabilities it provides.



  Zhou                    Expires 3 September 2026                [Page 9]


  Internet-Draft                     DVS                        March 2026


     Each referenced skill is subject to its own Trust Root's trust and
     security policies.  Agents MUST apply the Same-Origin Isolation
     policy (Section 5.1) independently to each loaded skill based on its
     own Trust Root.

     When composing skills across domains, agents SHOULD clearly
     communicate to the user that the trust context is being extended to
     additional domains.

  7.  Security Considerations

     The primary security property of this protocol is that trust is
     anchored to domain ownership.  This inherits both the strengths and
     weaknesses of the existing Web PKI and DNS infrastructure.

     Skill spoofing is mitigated by the HTTPS requirement, which ensures
     that only the legitimate operator of a domain can serve skills from
     that domain.  DNSSEC (Section 5.3) provides an additional layer of
     protection against DNS-level attacks.

     Agents implementing this protocol should be aware of the following
     risks:

     *  Domain compromise: If a domain is compromised, all skills served
        from it should be considered compromised.

     *  Subdomain delegation: Skills on subdomains should be treated as
        distinct trust contexts from the parent domain.

     *  UGC platform Trust Roots: On user-generated content platforms,
        agents MUST enforce path-scoped Trust Roots.  Accepting a bare
        platform domain (e.g., https://github.com/) as a Trust Root would
        allow any user on that platform to publish skills that appear
        equally trusted as a legitimate brand's skills.

     *  Transitive trust in composition: When skills reference other
        skills (Section 6), the trust chain extends across domains.
        Agents should clearly communicate this to users.

     *  Script execution: Bundled scripts execute with the permissions of
        the agent's runtime environment.  Malicious scripts could perform
        unauthorized file access, network calls, or data exfiltration.
        The Explicit Consent requirement (Section 5.2) mitigates this
        risk, but agents SHOULD also sandbox script execution where
        possible.






  Zhou                    Expires 3 September 2026               [Page 10]


  Internet-Draft                     DVS                        March 2026


     *  External resource fetching: Skills that instruct agents to fetch
        data from external URLs pose particular risk, as fetched content
        may contain malicious instructions.  Agents SHOULD treat
        externally-fetched content as untrusted.

  8.  IANA Considerations

     This document requests registration of the well-known URI suffix
     skills in the "Well-Known URIs" registry established by [RFC8615].

     URI suffix:  skills

     Change controller:  Namefi

     Specification document:  This document (Section 3.2)

  9.  References

  9.1.  Normative References

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

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC7763]  Leonard, S., "The text/markdown Media Type", RFC 7763,
                DOI 10.17487/RFC7763, March 2016,
                <https://www.rfc-editor.org/rfc/rfc7763>.

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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

  9.2.  Informative References



  Zhou                    Expires 3 September 2026               [Page 11]


  Internet-Draft                     DVS                        March 2026


     [CLAUDE-SKILLS]
                Anthropic, "Agent Skills Overview", n.d.,
                <https://platform.claude.com/docs/en/agents-and-tools/
                agent-skills/overview>.

     [SITEMAP]  sitemaps.org contributors, "Sitemaps XML Format", n.d.,
                <https://www.sitemaps.org/protocol.html>.

  Acknowledgments

     The authors would like to thank the broader AI agent community for
     discussions that informed this protocol design.

  Author's Address

     Zainan Victor Zhou
     Namefi
     Email: zzn@namefi.io

































  Zhou                    Expires 3 September 2026               [Page 12]


name: draft-ietf-rats-ar4si
rev: 09
title: Attestation Results for Secure Interactions
time: 2026-02-17T07:09:01Z
group_uri: /api/v1/group/group/2231/
expires: 2026-02-16T14:20:06Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.311927+00:00
source: ietf
source_id: 105892
source_url: https://datatracker.ietf.org/doc/draft-ietf-rats-ar4si/
doc_status: active
abstract:
  This document defines reusable Attestation Result information
     elements.  When these elements are offered to Relying Parties as
     Evidence, different aspects of Attester trustworthiness can be
     evaluated.  Additionally, where the Relying Party is interfacing with
     a heterogeneous mix of Attesting Environment and Verifier types,
     consistent policies can be applied to subsequent information exchange
     between each Attester and the Relying Party.

     This document also defines two serialisations of the proposed
     information model, utilising CBOR and JSON.

full_text:
  RATS Working Group                                               E. Voit
  Internet-Draft                                                     Cisco
  Intended status: Standards Track                             H. Birkholz
  Expires: 16 February 2026                                 Fraunhofer SIT
                                                               T. Hardjono
                                                                       MIT
                                                                T. Fossati
                                                                    Linaro
                                                               V. Scarlata
                                                                     Intel
                                                            15 August 2025


                Attestation Results for Secure Interactions
                          draft-ietf-rats-ar4si-09

  Abstract

     This document defines reusable Attestation Result information
     elements.  When these elements are offered to Relying Parties as
     Evidence, different aspects of Attester trustworthiness can be
     evaluated.  Additionally, where the Relying Party is interfacing with
     a heterogeneous mix of Attesting Environment and Verifier types,
     consistent policies can be applied to subsequent information exchange
     between each Attester and the Relying Party.

     This document also defines two serialisations of the proposed
     information model, utilising CBOR and JSON.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-rats-wg/draft-ietf-rats-ar4si.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.






  Voit, et al.            Expires 16 February 2026                [Page 1]


  Internet-Draft             Attestation Results               August 2025


     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 16 February 2026.

  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.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Attestation Results for Secure Interactions . . . . . . . . .   6
       2.1.  Information driving a Relying Party Action  . . . . . . .   6
       2.2.  Non-repudiable Identity . . . . . . . . . . . . . . . . .   7
         2.2.1.  Attester and Attesting Environment  . . . . . . . . .   8
         2.2.2.  Verifier  . . . . . . . . . . . . . . . . . . . . . .  10
         2.2.3.  Communicating Identity  . . . . . . . . . . . . . . .  10
       2.3.  Trustworthiness Claims  . . . . . . . . . . . . . . . . .  11
         2.3.1.  Design Principles . . . . . . . . . . . . . . . . . .  11
         2.3.2.  Enumeration Encoding  . . . . . . . . . . . . . . . .  12
         2.3.3.  Assigning a Trustworthiness Claim value . . . . . . .  14
         2.3.4.  Specific Claims . . . . . . . . . . . . . . . . . . .  14
         2.3.5.  Trustworthiness Vector  . . . . . . . . . . . . . . .  19
         2.3.6.  Trustworthiness Vector for a type of Attesting
                 Environment . . . . . . . . . . . . . . . . . . . . .  19
       2.4.  Freshness . . . . . . . . . . . . . . . . . . . . . . . .  20
     3.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       3.1.  Trustworthiness Vector  . . . . . . . . . . . . . . . . .  20
       3.2.  Trustworthiness Tiers . . . . . . . . . . . . . . . . . .  21
       3.3.  Verifier ID . . . . . . . . . . . . . . . . . . . . . . .  22
       3.4.  Consolitated CDDL . . . . . . . . . . . . . . . . . . . .  22
     4.  Secure Interactions Models  . . . . . . . . . . . . . . . . .  23
       4.1.  Background-Check  . . . . . . . . . . . . . . . . . . . .  24



  Voit, et al.            Expires 16 February 2026                [Page 2]


  Internet-Draft             Attestation Results               August 2025


         4.1.1.  Verifier Retrieval  . . . . . . . . . . . . . . . . .  24
         4.1.2.  Co-resident Verifier  . . . . . . . . . . . . . . . .  24
       4.2.  Below Zero Trust  . . . . . . . . . . . . . . . . . . . .  25
       4.3.  Mutual Attestation  . . . . . . . . . . . . . . . . . . .  29
       4.4.  Transport Protocol Integration  . . . . . . . . . . . . .  29
     5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  30
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  30
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  31
     Appendix A.  Implementation Guidance  . . . . . . . . . . . . . .  32
       A.1.  Supplementing Trustworthiness Claims  . . . . . . . . . .  32
     Appendix B.  Supportable Trustworthiness Claims . . . . . . . . .  32
       B.1.  Supportable Trustworthiness Claims for HSM-based CC . . .  33
       B.2.  Supportable Trustworthiness Claims for process-based
             CC  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
       B.3.  Supportable Trustworthiness Claims for VM-based CC  . . .  37
     Appendix C.  Some issues being worked . . . . . . . . . . . . . .  38
     Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  38
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

  1.  Introduction

     The first paragraph of the May 2021 US Presidential Executive Order
     on Improving the Nation's Cybersecurity [US-Executive-Order] ends
     with the statement "the trust we place in our digital infrastructure
     should be proportional to how trustworthy and transparent that
     infrastructure is."  Later this order explores aspects of
     trustworthiness such as an auditable trust relationship, which it
     defines as an "agreed-upon relationship between two or more system
     elements that is governed by criteria for secure interaction,
     behavior, and outcomes."

     The Remote ATtestation procedureS (RATS) architecture [RFC9334]
     provides a useful context for programmatically establishing and
     maintaining such auditable trust relationships.  Specifically, the
     architecture defines conceptual messages conveyed between
     architectural subsystems to support trustworthiness appraisal.  The
     RATS conceptual message used to convey evidence of trustworthiness is
     the Attestation Results.  The Attestation Results includes Verifier
     generated appraisals of an Attester including such information as the
     identity of the Attester, the security mechanisms employed on this
     Attester, and the Attester's current state of trustworthiness.

     Generated Attestation Results are ultimately conveyed to one or more
     Relying Parties.  Reception of an Attestation Result enables a
     Relying Party to determine what action to take with regards to an



  Voit, et al.            Expires 16 February 2026                [Page 3]


  Internet-Draft             Attestation Results               August 2025


     Attester.  Frequently, this action will be to choose whether to allow
     the Attester to securely interact with the Relying Party over some
     connection between the two.

     When determining whether to allow secure interactions with an
     Attester, a Relying Party is challenged with a number of difficult
     problems which it must be able to handle successfully.  These
     problems include:

     *  What Attestation Results (AR) might a Relying Party be willing to
        trust from a specific Verifier?

     *  What information does a Relying Party need before allowing
        interactions or choosing policies to apply to a connection?

     *  What are the operating/environmental realities of the Attesting
        Environment where a Relying Party should only be able to associate
        a certain confidence regarding Attestation Results out of the
        Verifier?  (In other words, different types of Trusted Execution
        Environments (TEE) need not be treated as equivalent.)

     *  How to make direct comparisons where there is a heterogeneous mix
        of Attesting Environments and Verifier types.

     To address these problems, it is important that specific Attestation
     Result information elements are framed independently of Attesting
     Environment specific constraints.  If they are not, a Relying Party
     would be forced to adapt to the syntax and semantics of many vendor
     specific environments.  This is not a reasonable ask as there can be
     many types of Attesters interacting with or connecting to a Relying
     Party.

     The business need therefore is for common Attestation Result
     information element definitions.  With these definitions, consistent
     interaction or connectivity decisions can be made by a Relying Party
     where there is a heterogenous mix of Attesting Environment types and
     Verifier types.

     This document defines information elements for Attestation Results in
     a way which normalizes the trustworthiness assertions that can be
     made from a diverse set of Attesters.










  Voit, et al.            Expires 16 February 2026                [Page 4]


  Internet-Draft             Attestation Results               August 2025


  1.1.  Requirements Notation

     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.

  1.2.  Terminology

     The following terms are imported from [RFC9334]: Appraisal Policy for
     Attestation Results, Attester, Attesting Environment, Claims,
     Evidence, Relying Party, Target Environment and Verifier.

     [RFC9334] also describes topological patterns that illustrate the
     need for interoperable conceptual messages.  The two patterns called
     "background-check model" and "passport model" are imported from the
     RATS architecture and used in this document as a reference to the
     architectural concepts: Background-Check Model and Passport Model.

     Newly defined terms for this document:

     AR-augmented Evidence:  a bundle of Evidence which includes at least
        the following:

        1.  Verifier signed Attestation Results.  These Attestation
            Results must include Identity Evidence for the Attester, a
            Trustworthiness Vector describing a Verifier's most recent
            appraisal of an Attester, and some Verifier Proof-of-Freshness
            (PoF).

        2.  A Relying Party PoF which is bound to the Attestation Results
            of (1) by the Attester's Attesting Environment signature.

        3.  Sufficient information to determine the elapsed interval
            between the Verifier PoF and Relying Party PoF.

     Identity Evidence:  Evidence which unambiguously identifies an
        identity.  Identity Evidence could take different forms, such as a
        certificate, or a signature which can be appraised to have only
        been generated by a specific private/public key pair.

     Trustworthiness Claim:  a specific quanta of trustworthiness which
        can be assigned by a Verifier based on its appraisal policy.

     Trustworthiness Tier:  a categorization of the levels of





  Voit, et al.            Expires 16 February 2026                [Page 5]


  Internet-Draft             Attestation Results               August 2025


        trustworthiness which may be assigned by a Verifier to a specific
        Trustworthiness Claim.  These enumerated categories are:
        Affirming, Warning, Contraindicated, and None.

     Trustworthiness Vector:  a set of zero to many Trustworthiness Claims
        assigned during a single appraisal procedure by a Verifier using
        Evidence generated by an Attester.  The vector is included within
        Attestation Results.

  2.  Attestation Results for Secure Interactions

     A Verifier generates the Attestation Results used by a Relying Party.
     When a Relying Party needs to determine whether to permit
     communications with an Attester, these Attestation Results must
     contain a specific set of information elements.  This section defines
     those information elements, and in some cases encodings for
     information elements.

  2.1.  Information driving a Relying Party Action

     When the action is a communication establishment attempt with an
     Attester, there is only a limited set of actions which a Relying
     Party might take.  These actions include:

     *  Allow or deny information exchange with the Attester.  When there
        is a deny, reasons should be returned to the Attester.

     *  Establish a transport connection between an Attester and a
        specific context within a Relying Party (e.g., a TEE, or Virtual
        Routing Function (VRF).)

     *  Apply policies on this connection (e.g., rate limits).

     There are three categories of information which must be conveyed to
     the Relying Party (which also is integrated with a Verifier) before
     it determines which of these actions to take.

     1.  Non-repudiable Identity Evidence – Evidence which undoubtably
         identifies one or more entities involved with a communication.

     2.  Trustworthiness Claims – Specifics a Verifier asserts with
         regards to its trustworthiness findings about an Attester.

     3.  Claim Freshness – Establishes the time of last update (or
         refresh) of Trustworthiness Claims.

     The following sections detail requirements for these three
     categories.



  Voit, et al.            Expires 16 February 2026                [Page 6]


  Internet-Draft             Attestation Results               August 2025


  2.2.  Non-repudiable Identity

     Identity Evidence must be conveyed during the establishment of any
     trust-based relationship.  Specific use cases will define the minimum
     types of identities required by a particular Relying Party as it
     evaluates Attestation Results, and perhaps additional associated
     Evidence.  At a bare minimum, a Relying Party MUST start with the
     ability to verify the identity of a Verifier it chooses to trust.
     Attester identities may then be acquired through signed or encrypted
     communications with the Verifier identity and/or the pre-provisioning
     Attester public keys in the Attester.

     During the Remote Attestation process, the Verifier's identity must
     be established with a Relying Party, often via a Verifier signature
     across recent Attestation Results.  This Verifier identity could only
     have come from a key pair maintained by a trusted developer or
     operator of the Verifier.

     Additionally, each set of Attestation Results must be provably and
     non-reputably bound to the identity of the original Attesting
     Environment which was evaluated by the Verifier.  This is
     accomplished via satisfying two requirements.  First the Verifier
     signed Attestation Results MUST include sufficient Identity Evidence
     to ensure that this Attesting Environment signature refers to the
     same Attesting Environment appraised by the Verifier.  Second, where
     the passport model is used as a subsystem, an Attesting Environment
     signature which spans the Verifier signature MUST also be included.
     As the Verifier signature already spans the Attester Identity as well
     as the Attestation Results, this restricts the viability of spoofing
     attacks.

     In a subset of use cases, these two pieces of Identity Evidence may
     be sufficient for a Relying Party to successfully meet the criteria
     for its Appraisal Policy for Attestation Results.  If the use case is
     a connection request, a Relying Party may simply then establish a
     transport session with an Attester after a successful appraisal.
     However an Appraisal Policy for Attestation Results will often be
     more nuanced, and the Relying Party may need additional information.
     Some Identity Evidence related policy questions which the Relying
     Party may consider include:

     *  Does the Relying Party only trust this Verifier to make
        Trustworthiness Claims on behalf a specific type of Attesting
        Environment?  Might a mix of Verifiers be necessary to cover all
        mandatory Trustworthiness Claims?

     *  Does the Relying Party only accept connections from a verified-
        authentic software build from a specific software developer?



  Voit, et al.            Expires 16 February 2026                [Page 7]


  Internet-Draft             Attestation Results               August 2025


     *  Does the Relying Party only accept connections from specific
        preconfigured list of Attesters?

     For any of these more nuanced appraisals, additional Identity
     Evidence or other policy related information must be conveyed or pre-
     provisioned during the formation of a trust context between the
     Relying Party, the Attester, the Attester's Attesting Environment,
     and the Verifier.

  2.2.1.  Attester and Attesting Environment

     Per [RFC9334] Figure 2, an Attester and a corresponding Attesting
     Environment might not share common code or even hardware boundaries.
     Consequently, an Attester implementation needs to ensure that any
     Evidence which originates from outside the Attesting Environment MUST
     have been collected and delivered securely before any Attesting
     Environment signing may occur.  After the Verifier performs its
     appraisal, it will include sufficient information in the Attestation
     Results to enable a Relying Party to have confidence that the
     Attester's trustworthiness is represented via Trustworthiness Claims
     signed by the appropriate Attesting Environment.

     This document recognizes three general categories of Attesters.

     1.  HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
         which hashes one or more streams of security measurements from an
         Attester within the Attesting Environment.  Maintenance of this
         hash enables detection of an Attester which is not reporting the
         exact set of security measurements (such as log entries) taken
         within the Attesting Environment.  An example of a HSM is a
         TPM2.0 [TPM2.0].

     2.  Process-based: An individual process which has its runtime memory
         encrypted by an Attesting Environment in a way that no other
         processes can read and decrypt that memory (e.g., [SGX] or
         [RFC9783].)

     3.  VM-based: An entire Guest VM (or a set of containers within a
         host) have been encrypted as a walled-garden unit by an Attesting
         Environment.  The result is that the host operating system cannot
         read and decrypt what is executing within that VM (e.g.,
         [SEV-SNP], [TDX] or [ARM-CCA].)

     Each of these categories of Attesters above will be capable of
     generating Evidence which is protected using private keys /
     certificates which are not accessible outside of the corresponding
     Attesting Environment.  The owner of these secrets is the owner of
     the identity which is bound within the Attesting Environment.



  Voit, et al.            Expires 16 February 2026                [Page 8]


  Internet-Draft             Attestation Results               August 2025


     Effectively this means that for any Attester identity, there will
     exist a chain of trust ultimately bound to a hardware-based root of
     trust in the Attesting Environment.  It is upon this root of trust
     that unique, non-repudiable Attester identities may be founded.

     There are several types of Attester identities defined in this
     document.  This list is extensible:

     *  chip-vendor: the vendor of the hardware chip used for the
        Attesting Environment (e.g., a primary Endorsement Key from a TPM)

     *  chip-hardware: specific hardware with specific firmware from an
        'chip-vendor'

     *  target-environment: a unique instance of a software build running
        in an Attester (e.g., MRENCLAVE [SGX], an Identity Block
        [SEV-SNP], a Realm Initial Measurement (RIM) [ARM-CCA], or a hash
        which represents a set of software loaded since boot (e.g., TPM
        based integrity verification.))

     *  target-developer: the organizational unit responsible for a
        particular 'target-environment' (e.g., MRSIGNER [SGX])

     *  instance: a unique instantiated instance of an Attesting
        Environment running on 'chip-hardware' (e.g., an LDevID
        [IEEE802.1AR], an Instance ID [RFC9783] [ARM-CCA])

     Based on the category of the Attesting Environment, different types
     of identities might be exposed by an Attester.

      +========================+===============+===========+===========+
      | Attester Identity type | Process-based | VM-based  | HSM-based |
      +========================+===============+===========+===========+
      | chip-vendor            | Mandatory     | Mandatory | Mandatory |
      +------------------------+---------------+-----------+-----------+
      | chip-hardware          | Mandatory     | Mandatory | Mandatory |
      +------------------------+---------------+-----------+-----------+
      | target-environment     | Mandatory     | Mandatory | Optional  |
      +------------------------+---------------+-----------+-----------+
      | target-developer       | Mandatory     | Optional  | Optional  |
      +------------------------+---------------+-----------+-----------+
      | instance               | Optional      | Optional  | Optional  |
      +------------------------+---------------+-----------+-----------+

                                   Table 1






  Voit, et al.            Expires 16 February 2026                [Page 9]


  Internet-Draft             Attestation Results               August 2025


     It is expected that drafts subsequent to this specification will
     provide the definitions and value domains for specific identities,
     each of which falling within the Attester identity types listed
     above.  In some cases the actual unique identities might be encoded
     as complex structures.  An example complex structure might be a
     'target-environment' encoded as a Software Bill of Materials (SBOM).

     With the identity definitions and value domains, a Relying Party will
     have sufficient information to ensure that the Attester identities
     and Trustworthiness Claims asserted are actually capable of being
     supported by the underlying type of Attesting Environment.
     Consequently, the Relying Party SHOULD require Identity Evidence
     which indicates of the type of Attesting Environment when it
     considers its Appraisal Policy for Attestation Results.

  2.2.2.  Verifier

     For the Verifier identity, it is critical for a Relying Party to
     review the certificate and chain of trust for that Verifier.
     Additionally, the Relying Party must have confidence that the
     Trustworthiness Claims being relied upon from the Verifier considered
     the chain of trust for the Attesting Environment.

     There are two categorizations of Verifier identities defined in this
     document:

     *  verifier build: a unique instance of a software build running as a
        Verifier.

     *  verifier developer: the organizational unit responsible for a
        particular 'verifier build'.

     Within each category, communicating the identity can be accomplished
     via a variety of objects and encodings.

  2.2.3.  Communicating Identity

     Any of the above identities used by the Appraisal Policy for
     Attestation Results needed to be pre-established by the Relying Party
     before, or provided during, the exchange of Attestation Results.
     When provided during this exchange, the identity may be communicated
     either implicitly or explicitly.

     An example of explicit communication would be to include the
     following Identity Evidence directly within the Attestation Results:
     a unique identifier for an Attesting Environment, the name of a key
     which can be provably associated with that unique identifier, and the
     set of Attestation Results which are signed using that key.  As these



  Voit, et al.            Expires 16 February 2026               [Page 10]


  Internet-Draft             Attestation Results               August 2025


     Attestation Results are signed by the Verifier, it is the Verifier
     which is explicitly asserting the credentials it believes are
     trustworthy.

     An example of implicit communication would be to include Identity
     Evidence in the form of a signature which has been placed over the
     Attestation Results asserted by a Verifier.  It would be then up to
     the Relying Party's Appraisal Policy for Attestation Results to
     extract this signature and confirm that it only could have been
     generated by an Attesting Environment having access to a specific
     private key.  This implicit identity communication is only viable if
     the Attesting Environment's public key is already known by the
     Relying Party.

     One final step in communicating identity is proving the freshness of
     the Attestation Results to the degree needed by the Relying Party.  A
     typical way to accomplish this is to include an element of freshness
     be embedded within a signed portion of the Attestation Results.  This
     element of freshness reduces the identity spoofing risks from a
     replay attack.  For more on this, see Section 2.4.

  2.3.  Trustworthiness Claims

  2.3.1.  Design Principles

     Trust is not absolute.  Trust is a belief in some aspect about an
     entity (in this case an Attester), and that this aspect is something
     which can be depended upon (in this case by a Relying Party.)  Within
     the context of Remote Attestation, believability of this aspect is
     facilitated by a Verifier.  This facilitation depends on the
     Verifier's ability to parse detailed Evidence from an Attester and
     then to assert conclusions about this aspect in a way interpretable
     by a Relying Party.

     Specific aspects for which a Verifier will assert trustworthiness are
     defined in this section.  These are known as Trustworthiness Claims.
     These claims have been designed to enable a common understanding
     between a broad array of Attesters, Verifiers, and Relying Parties.
     The following set of design principles have been applied in the
     Trustworthiness Claim definitions:

     1.  Expose a small number of Trustworthiness Claims.









  Voit, et al.            Expires 16 February 2026               [Page 11]


  Internet-Draft             Attestation Results               August 2025


         Reason: a plethora of similar Trustworthiness Claims will result
         in divergent choices made on which to support between different
         Verifiers.  This would place a lot of complexity in the Relying
         Party as it would be up to the Relying Party (and its policy
         language) to enable normalization across rich but incompatible
         Verifier object definitions.

     2.  Each Trustworthiness Claim enumerates only the specific states
         that could viably result in a different outcome after the Policy
         for Attestation Results has been applied.

         Reason: by explicitly disallowing the standardization of
         enumerated states which cannot easily be connected to a use case,
         we avoid forcing implementers from making incompatible guesses on
         what these states might mean.

     3.  Verifier and RP developers need explicit definitions of each
         state in order to accomplish the goals of (1) and (2).

         Reason: without such guidance, the Verifier will append plenty of
         raw supporting info.  This relieves the Verifier of making the
         hard decisions.  Of course, this raw info will be mostly non-
         interpretable and therefore non-actionable by the Relying Party.

     4.  Support standards and non-standard extensibility for (1) and (2).

         Reason: standard types of Verifier generated Trustworthiness
         Claims should be vetted by the full RATS working group, rather
         than being maintained in a repository which doesn't follow the
         RFC process.  This will keep a tight lid on extensions which must
         be considered by the Relying Party's policy language.  Because
         this process takes time, non-standard extensions will be needed
         for implementation speed and flexibility.

     These design principles are important to keep the number of Verifier
     generated claims low, and to retain the complexity in the Verifier
     rather than the Relying Party.

  2.3.2.  Enumeration Encoding

     Per design principle (2), each Trustworthiness Claim will only expose
     specific encoded values.  To simplify the processing of these
     enumerations by the Relying Party, the enumeration will be encoded as
     a single signed 8 bit integer.  These value assignments for this
     integer will be in four Trustworthiness Tiers which follow these
     guidelines:





  Voit, et al.            Expires 16 February 2026               [Page 12]


  Internet-Draft             Attestation Results               August 2025


     None: The Verifier makes no assertions regarding this aspect of
     trustworthiness.

     *  Value 0: The Evidence received is insufficient to make a
        conclusion.  Note: this should always be always treated
        equivalently by the Relying Party as no claim being made.  I.e.,
        the RP's Appraisal Policy for Attestation Results SHOULD NOT make
        any distinction between a Trustworthiness Claim with enumeration
        '0', and no Trustworthiness Claim being provided.

     *  Value 1: The Evidence received contains unknown elements which the
        Verifier is unable to evaluate.  An example might be that the
        wrong type of Evidence has been delivered.  Another case is that
        of Evidence coming from a composite Attester: a Verifier may
        understand only part of it and leave as "unknown" the
        Trustworthiness claims related to features it can't appraise.

     *  Value -1: A verifier malfunction occurred during the Verifier's
        appraisal processing.

     Affirming: The Verifier affirms the Attester support for this aspect
     of trustworthiness.

     *  Values 2 to 31: A standards enumerated reason for affirming.

     *  Values -2 to -32: A non-standard reason for affirming.

     Warning: The Verifier warns about this aspect of trustworthiness.

     *  Values 32 to 95: A standards enumerated reason for the warning.

     *  Values -33 to -96: A non-standard reason for the warning.

     Contraindicated: The Verifier asserts the Attester is explicitly
     untrustworthy in regard to this aspect.

     *  Values 96 to 127: A standards enumerated reason for the
        contraindication.

     *  Values -97 to -128: A non-standard reason for the
        contraindication.

     This enumerated encoding listed above will simplify the Appraisal
     Policy for Attestation Results.  Such a policies may be as simple as
     saying that a specific Verifier has recently asserted Trustworthiness
     Claims, all of which are Affirming.





  Voit, et al.            Expires 16 February 2026               [Page 13]


  Internet-Draft             Attestation Results               August 2025


  2.3.3.  Assigning a Trustworthiness Claim value

     In order to simplify design, only a single encoded value is asserted
     by a Verifier for any Trustworthiness Claim within a using the
     following process.

     1.  If applicable, a Verifier MUST assign a standardized value from
         the Contraindicated tier.

     2.  Else if applicable, a Verifier MUST assign a non-standardized
         value from the Contraindicated tier.

     3.  Else if applicable, a Verifier MUST assign a standardized value
         from the Warning tier.

     4.  Else if applicable, a Verifier MUST assign a non-standardized
         value from the Warning tier.

     5.  Else if applicable, a Verifier MUST assign a standardized value
         from the Affirming tier.

     6.  Else if applicable, a Verifier MUST assign a non-standardized
         value from the Affirming tier.

     7.  Else a Verifier MAY assign a 0 or -1.

  2.3.4.  Specific Claims

     Following are the Trustworthiness Claims and their supported
     enumerations which may be asserted by a Verifier:

     configuration:  A Verifier has appraised an Attester's configuration,
        and is able to make conclusions regarding the exposure of known
        vulnerabilities

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  The configuration is a known and approved config.

        3:  The configuration includes or exposes no known
           vulnerabilities.

        32:  The configuration includes or exposes known vulnerabilities.



  Voit, et al.            Expires 16 February 2026               [Page 14]


  Internet-Draft             Attestation Results               August 2025


        36:  Elements of the configuration relevant to security are
           unavailable to the Verifier.

        96:  The configuration is unsupportable as it exposes unacceptable
           security vulnerabilities.

        99:  Cryptographic validation of the Evidence has failed.

     executables:  A Verifier has appraised and evaluated relevant runtime
        files, scripts, and/or other objects which have been loaded into
        the Target environment's memory.

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  Only a recognized genuine set of approved executables,
           scripts, files, and/or objects have been loaded during and
           after the boot process.

        3:  Only a recognized genuine set of approved executables have
           been loaded during the boot process.

        32:  Only a recognized genuine set of executables, scripts, files,
           and/or objects have been loaded.  However the Verifier cannot
           vouch for a subset of these due to known bugs or other known
           vulnerabilities.

        33:  Runtime memory includes executables, scripts, files, and/or
           objects which are not recognized.

        96:  Runtime memory includes executables, scripts, files, and/or
           object which are contraindicated.

        99:  Cryptographic validation of the Evidence has failed.

     file-system:  A Verifier has evaluated a specific set of directories
        within the Attester's file system.  (Note: the Verifier may or may
        not indicate what these directory and expected files are via an
        unspecified management interface.)

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.



  Voit, et al.            Expires 16 February 2026               [Page 15]


  Internet-Draft             Attestation Results               August 2025


        -1:  Verifier malfunction

        2:  Only a recognized set of approved files are found.

        32:  The file system includes unrecognized executables, scripts,
           or files.

        96:  The file system includes contraindicated executables,
           scripts, or files.

        99:  Cryptographic validation of the Evidence has failed.

     hardware:  A Verifier has appraised any Attester hardware and
        firmware which are able to expose fingerprints of their identity
        and running code.

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  An Attester has passed its hardware and/or firmware
           verifications needed to demonstrate that these are genuine/
           supported.

        32: An Attester contains only genuine/supported hardware and/or
        firmware, but there are known security vulnerabilities.

        96:  Attester hardware and/or firmware is recognized, but its
           trustworthiness is contraindicated.

        97:  A Verifier does not recognize an Attester's hardware or
           firmware, but it should be recognized.

        99:  Cryptographic validation of the Evidence has failed.

     instance-identity:  A Verifier has appraised an Attesting
        Environment's unique identity based upon private key signed
        Evidence which can be correlated to a unique instantiated instance
        of the Attester.  (Note: this Trustworthiness Claim should only be
        generated if the Verifier actually expects to recognize the unique
        identity of the Attester.)

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer



  Voit, et al.            Expires 16 February 2026               [Page 16]


  Internet-Draft             Attestation Results               August 2025


           evaluation.

        -1:  Verifier malfunction

        2:  The Attesting Environment is recognized, and the associated
           instance of the Attester is not known to be compromised.

        96:  The Attesting Environment is recognized, and but its unique
           private key indicates a device which is not trustworthy.

        97:  The Attesting Environment is not recognized; however the
           Verifier believes it should be.

        99:  Cryptographic validation of the Evidence has failed.

     runtime-opaque:  A Verifier has appraised the visibility of Attester
        objects in memory from perspectives outside the Attester.

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  the Attester's executing Target Environment and Attesting
           Environments are encrypted and within Trusted Execution
           Environment(s) opaque to the operating system, virtual machine
           manager, and peer applications.  (Note: This value corresponds
           to the protections asserted by O.RUNTIME_CONFIDENTIALITY from
           [GP-TEE-PP])

        32:  the Attester's executing Target Environment and Attesting
           Environments inaccessible from any other parallel application
           or Guest VM running on the Attester's physical device.  (Note
           that unlike "1" these environments are not encrypted in a way
           which restricts the Attester's root operator visibility.  See
           O.TA_ISOLATION from [GP-TEE-PP].)

        96:  The Verifier has concluded that in memory objects are
           unacceptably visible within the physical host that supports the
           Attester.

        99:  Cryptographic validation of the Evidence has failed.

     sourced-data:  A Verifier has evaluated of the integrity of data
        objects from external systems used by the Attester.




  Voit, et al.            Expires 16 February 2026               [Page 17]


  Internet-Draft             Attestation Results               August 2025


        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  All essential Attester source data objects have been provided
           by other Attester(s) whose most recent appraisal(s) had both no
           Trustworthiness Claims of "0" where the current Trustworthiness
           Claim is "Affirming", as well as no "Warning" or
           "Contraindicated" Trustworthiness Claims.

        32:  Attester source data objects come from unattested sources, or
           attested sources with "Warning" type Trustworthiness Claims.

        96:  Attester source data objects come from contraindicated
           sources.

        99:  Cryptographic validation of the Evidence has failed.

     storage-opaque:  A Verifier has appraised that an Attester is capable
        of encrypting persistent storage.  (Note: Protections must meet
        the capabilities of [OMTP-ATE] Section 5, but need not be hardware
        tamper resistant.)

        0:  No assertion

        1:  Evidence contains unknown elements which inhibit Verifer
           evaluation.

        -1:  Verifier malfunction

        2:  the Attester encrypts all secrets in persistent storage via
           using keys which are never visible outside an HSM or the
           Trusted Execution Environment hardware.

        32:  the Attester encrypts all persistently stored secrets, but
           without using hardware backed keys

        96:  There are persistent secrets which are stored unencrypted in
           an Attester.

        99:  Cryptographic validation of the Evidence has failed.

     It is possible for additonal Trustworthiness Claims and enumerated
     values to be defined in subsequent documents.  At the same time, the
     standardized Trustworthiness Claim values listed above have been



  Voit, et al.            Expires 16 February 2026               [Page 18]


  Internet-Draft             Attestation Results               August 2025


     designed so there is no overlap within a Trustworthiness Tier.  As a
     result, it is possible to imagine a future where overlapping
     Trustworthiness Claims within a single Trustworthiness Tier may be
     defined.  Wherever possible, the Verifier SHOULD assign the best
     fitting standardized value.

     Where a Relying Party doesn't know how to handle a particular
     Trustworthiness Claim, it MAY choose an appropriate action based on
     the Trustworthiness Tier under which the enumerated value fits.

     It is up to the Verifier to publish the types of evaluations it
     performs when determining how Trustworthiness Claims are derived for
     a type of any particular type of Attester.  It is out of the scope of
     this document for the Verifier to provide proof or specific logic on
     how a particular Trustworthiness Claim which it is asserting was
     derived.

  2.3.5.  Trustworthiness Vector

     Multiple Trustworthiness Claims may be asserted about an Attesting
     Environment at single point in time.  The set of Trustworthiness
     Claims inserted into an instance of Attestation Results by a Verifier
     is known as a Trustworthiness Vector.  The order of Claims in the
     vector is NOT meaningful.  A Trustworthiness Vector with no
     Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a
     valid construct.  In this case, the Verifier is making no
     Trustworthiness Claims but is confirming that an appraisal has been
     made.

  2.3.6.  Trustworthiness Vector for a type of Attesting Environment

     Some Trustworthiness Claims are implicit based on the underlying type
     of Attesting Environment.  For example, a validated MRSIGNER identity
     can be present where the underlying [SGX] hardware is authentic.
     Where such implicit Trustworthiness Claims exist, they do not have to
     be explicitly included in the Trustworthiness Vector.  However, these
     implicit Trustworthiness Claims SHOULD be considered as being present
     by the Relying Party.  Another way of saying this is if a
     Trustworthiness Claim is automatically supported as a result of
     coming from a specific type of TEE, that claim need not be
     redundantly articulated.  Such implicit Trustworthiness Claims can be
     seen in the tables within Appendix B.2 and Appendix B.3.









  Voit, et al.            Expires 16 February 2026               [Page 19]


  Internet-Draft             Attestation Results               August 2025


     Additionally, there are some Trustworthiness Claims which cannot be
     adequately supported by an Attesting Environment.  For example, it
     would be difficult for an Attester that includes only a TPM (and no
     other TEE) from ever having a Verifier appraise support for 'runtime-
     opaque'.  As such, a Relying Party would be acting properly if it
     rejects any non-supportable Trustworthiness Claims asserted from a
     Verifier.

     As a result, the need for the ability to carry a specific
     Trustworthiness Claim will vary by the type of Attesting Environment.
     Example mappings can be seen in Appendix B.

  2.4.  Freshness

     A Relying Party will care about the recentness of the Attestation
     Results, and the specific Trustworthiness Claims which are embedded.
     All freshness mechanisms of [RFC9334], Section 10 are supportable by
     this specification.

     Additionally, a Relying Party may track when a Verifier expires its
     confidence for the Trustworthiness Claims or the Trustworthiness
     Vector as a whole.  Mechanisms for such expiry are not defined within
     this document.

     There is a subset of secure interactions where the freshness of
     Trustworthiness Claims may need to be revisited asynchronously.  This
     subset is when trustworthiness depends on the continuous availability
     of a transport session between the Attester and Relying Party.  With
     such connectivity dependent Attestation Results, if there is a reboot
     which resets transport connectivity, all established Trustworthiness
     Claims should be cleared.  Subsequent connection re-establishment
     will allow fresh new Trustworthiness Claims to be delivered.

  3.  Data Model

     The following CDDL [RFC8610] defines the necessary AR4SI types for
     use in CBOR and JSON serializations.

     Other serializations are possible but must be defined in subsequent
     documents.

  3.1.  Trustworthiness Vector

     The trustworthiness-vector is defined as follows:







  Voit, et al.            Expires 16 February 2026               [Page 20]


  Internet-Draft             Attestation Results               August 2025


     trustworthiness-vector = non-empty<{
       ? instance-identity-label => trustworthiness-claim
       ? configuration-label => trustworthiness-claim
       ? executables-label => trustworthiness-claim
       ? file-system-label => trustworthiness-claim
       ? hardware-label => trustworthiness-claim
       ? runtime-opaque-label => trustworthiness-claim
       ? storage-opaque-label => trustworthiness-claim
       ? sourced-data-label => trustworthiness-claim
     }>

     instance-identity-label = JC<"instance-identity", 0>
     configuration-label = JC<"configuration", 1>
     executables-label = JC<"executables", 2>
     file-system-label = JC<"file-system", 3>
     hardware-label = JC<"hardware", 4>
     runtime-opaque-label = JC<"runtime-opaque", 5>
     storage-opaque-label = JC<"storage-opaque", 6>
     sourced-data-label = JC<"sourced-data", 7>

     trustworthiness-claim = -128..127

                        Figure 1: Trustworthiness Vector

     This type contains an entry for each one of the eight AR4SI
     appraisals that have been conducted on the submitted evidence
     (Section 2.3.4).

     The value of each entry is chosen in the -128..127 range according to
     the rules described in Section 2.3.3 and Section 2.3.4.

     All categories are optional.

     A missing entry means that the verifier makes no claim about this
     specific appraisal facet because the category is not applicable to
     the submitted evidence.

     As required by the non-empty macro, at least one entry MUST be
     present in the vector.

  3.2.  Trustworthiness Tiers

     The trustworthiness-tier type represents one of the equivalency
     classes in which the trustworthiness-claim space is partitioned.

     See Section 2.3.2 for the details.

     The allowed values for the type are as follows:



  Voit, et al.            Expires 16 February 2026               [Page 21]


  Internet-Draft             Attestation Results               August 2025


     trustworthiness-tier-none-label = JC<"none", 0>
     trustworthiness-tier-affirming-label = JC<"affirming", 2>
     trustworthiness-tier-warning-label = JC<"warning", 32>
     trustworthiness-tier-contraindicated-label = JC<"contraindicated", 96>

     trustworthiness-tier /= trustworthiness-tier-none-label
     trustworthiness-tier /= trustworthiness-tier-affirming-label
     trustworthiness-tier /= trustworthiness-tier-warning-label
     trustworthiness-tier /= trustworthiness-tier-contraindicated-label

                        Figure 2: Trustworthiness Tiers

  3.3.  Verifier ID

     The verifier-id type identifies the software that runs the verifier
     according to the information model defined in Section 2.2.2.

     verifier-id = {
       developer-label => text
       build-label => text
     }

     developer-label = JC<"developer", 0>
     build-label = JC<"build", 1>

                             Figure 3: Verifier ID

     The fields are:

     build (mandatory)  A text string that uniquely identifies the
        software build running the verifier.

     developer (mandatory)  A text string that uniquely identifies the
        organizational unit responsible for this build.

  3.4.  Consolitated CDDL

     Figure 4 contains the CDDL of the entire AR4SI type system.













  Voit, et al.            Expires 16 February 2026               [Page 22]


  Internet-Draft             Attestation Results               August 2025


     =============== NOTE: '\' line wrapping per RFC 8792 ================

     $.start.$ = trustworthiness-vector / trustworthiness-tier / verifier\
                                               -id / trustworthiness-claim
     trustworthiness-vector = non-empty<{
         ? instance-identity-label => trustworthiness-claim,
         ? configuration-label => trustworthiness-claim,
         ? executables-label => trustworthiness-claim,
         ? file-system-label => trustworthiness-claim,
         ? hardware-label => trustworthiness-claim,
         ? runtime-opaque-label => trustworthiness-claim,
         ? storage-opaque-label => trustworthiness-claim,
         ? sourced-data-label => trustworthiness-claim,
     }>
     instance-identity-label = JC<"instance-identity", 0>
     configuration-label = JC<"configuration", 1>
     executables-label = JC<"executables", 2>
     file-system-label = JC<"file-system", 3>
     hardware-label = JC<"hardware", 4>
     runtime-opaque-label = JC<"runtime-opaque", 5>
     storage-opaque-label = JC<"storage-opaque", 6>
     sourced-data-label = JC<"sourced-data", 7>
     trustworthiness-claim = -128 .. 127
     trustworthiness-tier-none-label = JC<"none", 0>
     trustworthiness-tier-affirming-label = JC<"affirming", 2>
     trustworthiness-tier-warning-label = JC<"warning", 32>
     trustworthiness-tier-contraindicated-label = JC<"contraindicated", \
                                                                       96>
     trustworthiness-tier /= trustworthiness-tier-none-label / \
     trustworthiness-tier-affirming-label / trustworthiness-tier-warning-\
                        label / trustworthiness-tier-contraindicated-label
     verifier-id = {
       developer-label => text,
       build-label => text,
     }
     developer-label = JC<"developer", 0>
     build-label = JC<"build", 1>
     non-empty<M> = M .within ({+ any => any})
     JSON-ONLY<J> = J .feature "json"
     CBOR-ONLY<C> = C .feature "cbor"
     JC<J, C> = JSON-ONLY<J> / CBOR-ONLY<C>

                              Figure 4: AR4SI CDDL

  4.  Secure Interactions Models

     There are multiple ways of providing a Trustworthiness Vector to a
     Relying Party.  This section describes two alternatives.



  Voit, et al.            Expires 16 February 2026               [Page 23]


  Internet-Draft             Attestation Results               August 2025


  4.1.  Background-Check

  4.1.1.  Verifier Retrieval

     It is possible to for a Relying Party to follow the Background-Check
     Model defined in Section 5.2 of [RFC9334].  In this case, a Relying
     Party will receive Attestation Results containing the Trustworthiness
     Vector directly from a Verifier.  These Attestation Results can then
     be used by the Relying Party in determining the appropriate treatment
     for interactions with the Attester.

     While applicable in some cases, the utilization of the Background-
     Check Model without modification has potential drawbacks in other
     cases.  These include:

     *  Verifier scale: if the Attester has many Relying Parties, a
        Verifier appraising that Attester could be frequently be queried
        based on the same Evidence.

     *  Information leak: Evidence which the Attester might consider
        private can be visible to the Relying Party.  Hiding that Evidence
        could devalue any resulting appraisal.

     *  Latency: a Relying Party will need to wait for the Verifier to
        return Attestation Results before proceeding with secure
        interactions with the Attester.

     An implementer should examine these potential drawbacks before
     selecting this alternative.

  4.1.2.  Co-resident Verifier

     A simplified Background-Check Model may exist in a very specific
     case.  This is where the Relying Party and Verifier functions are co-
     resident.  This model is appropriate when:

     *  Some hardware-based private key is used by an Attester while
        proving its identity as part of a mutually authenticated secure
        channel establishment with the Relying Party, and

     *  this Attester identity is accepted as sufficient proof of Attester
        integrity.

     Effectively this means that detailed forensic capabilities of a
     robust Verifier are unnecessary because it is accepted that the code
     and operational behavior of the Attester cannot be manipulated after
     TEE initialization.




  Voit, et al.            Expires 16 February 2026               [Page 24]


  Internet-Draft             Attestation Results               August 2025


     An example of such a scenario may be when an SGX's MRENCLAVE and
     MRSIGNER values have been associated with a known QUOTE value.  And
     the code running within the TEE is not modifiable after launch.

  4.2.  Below Zero Trust

     Zero Trust Architectures are referenced in [US-Executive-Order]
     eleven times.  However despite this high profile, there is an
     architectural gap with Zero Trust.  The credentials used for
     authentication and admission control can be manipulated on the
     endpoint.  Attestation can fill this gap through the generation of a
     compound credential called AR-augmented Evidence.  This compound
     credential is rooted in the hardware based Attesting Environment of
     an endpoint, plus the trustworthiness of a Verifier.  The overall
     solution is known as "Below Zero Trust" as the compound credential
     cannot be manipulated or spoofed by an administrator of an endpoint
     with root access.  This solution is not adversely impacted by the
     potential drawbacks with pure background-check described above.

     To kick-off the "Below Zero Trust" compound credential creation
     sequence, a Verifier evaluates an Attester and returns signed
     Attestation Results back to this original Attester no less frequently
     than a well-known interval.  This interval may also be asynchronous,
     based on the changing of certain Evidence as described in
     [I-D.ietf-rats-network-device-subscription].

     When a Relying Party is to receive information about the Attester's
     trustworthiness, the Attesting Environment assembles the minimal set
     of Evidence which can be used to confirm or refute whether the
     Attester remains in the state of trustworthiness represented by the
     AR.  To this Evidence, the Attesting Environment appends the
     signature from the most recent AR as well as a Relying Party Proof-
     of-Freshness.  The Attesting Environment then signs the combination.

     The Attester then assembles AR Augmented Evidence by taking the
     signed combination and appending the full AR.  The assembly now
     consists of two independent but semantically bound sets of signed
     Evidence.

     The AR Augmented Evidence is then sent to the Relying Party.  The
     Relying Party then can appraise these semantically bound sets of
     signed Evidence by applying an Appraisal Policy for Attestation
     Results as described below.  This policy will consider both the AR as
     well as additional information about the Attester within the AR
     Augmented Evidence when determining what action to take.






  Voit, et al.            Expires 16 February 2026               [Page 25]


  Internet-Draft             Attestation Results               August 2025


     This alternative combines the [RFC9334] Sections 5.1 Passport Model
     and Section 5.2 Background-Check Model.  Figure 5 describes this flow
     of information.  The flows within this combined model are mapped to
     [RFC9334] in the following way.  "Verifier A" below corresponds to
     the "Verifier" Figure 5 within [RFC9334].  And "Relying Party/
     Verifier B" below corresponds to the union of the "Relying Party" and
     "Verifier" boxes within Figure 6 of [RFC9334].  This union is
     possible because Verifier B can be implemented as a simple, self-
     contained process.  The resulting combined process can appraise the
     AR-augmented Evidence to determine whether an Attester qualifies for
     secure interactions with the Relying Party.  The specific steps of
     this process are defined later in this section.

       .----------------.
       | Attester       |
       | .-------------.|
       | | Attesting   ||             .----------.    .---------------.
       | | Environment ||             | Verifier |    | Relying Party |
       | '-------------'|             |     A    |    |  / Verifier B |
       '----------------'             '----------'    '---------------'
             time(VG)                       |                 |
               |<------Verifier PoF-------time(NS)            |
               |                            |                 |
      time(EG)(1)------Evidence------------>|                 |
               |                          time(RG)            |
               |<------Attestation Results-(2)                |
               ~                            ~                 ~
             time(VG')?                     |                 |
               ~                            ~                 ~
               |<------Relying Party PoF-----------------(3)time(NS')
               |                            |                 |
     time(EG')(4)------AR-augmented Evidence----------------->|
               |                            |   time(RG',RA')(5)
                                                             (6)
                                                              ~
                                                           time(RX')

                           Figure 5: Below Zero Trust

     The interaction model depicted above includes specific time related
     events from Appendix A of [RFC9334].  With the identification of
     these time related events, time duration/interval tracking becomes
     possible.  Such duration/interval tracking can become important if
     the Relying Party cares if too much time has elapsed between the
     Verifier PoF and Relying Party PoF.  If too much time has elapsed,
     perhaps the Attestation Results themselves are no longer trustworthy.





  Voit, et al.            Expires 16 February 2026               [Page 26]


  Internet-Draft             Attestation Results               August 2025


     Note that while time intervals will often be relevant, there is a
     simplified case that does not require a Relying Party's PoF in step
     (3).  In this simplified case, the Relying Party trusts that the
     Attester cannot be meaningfully changed from the outside during any
     reportable interval.  Based on that assumption, and when this is the
     case then the step of the Relying Party PoF can be safely omitted.

     In all cases, appraisal policies define the conditions and
     prerequisites for when an Attester does qualify for secure
     interactions.  To qualify, an Attester has to be able to provide all
     of the mandatory affirming Trustworthiness Claims and identities
     needed by a Relying Party's Appraisal Policy for Attestation Results,
     and none of the disqualifying detracting Trustworthiness Claims.

     More details on each interaction step of Below Zero Trust are as
     follows.  The numbers used in this sequence match to the numbered
     steps in Figure 5:

     1.  An Attester sends Evidence which is provably fresh to Verifier A
         at time(EG).  Freshness from the perspective of Verifier A MAY be
         established with Verifier PoF such as a nonce.

     2.  Verifier A appraises (1), then sends the following items back to
         that Attester within Attestation Results:

         1.  the verified identity of the Attesting Environment,

         2.  the Verifier A appraised Trustworthiness Vector of an
             Attester,

         3.  a freshness proof associated with the Attestation Results,

         4.  a Verifier signature across (2.1) though (2.3).

     3.  At time(EG') a Relying Party PoF (such as a nonce) known to the
         Relying Party is sent to the Attester.

     4.  The Attester generates and sends AR-augmented Evidence to the
         Relying Party/Verifier B.  This AR-augmented Evidence includes:

         1.  The Attestation Results from (2)

         2.  Any (optionally) new incremental Evidence from the Attesting
             Environment







  Voit, et al.            Expires 16 February 2026               [Page 27]


  Internet-Draft             Attestation Results               August 2025


         3.  Attestation Environment signature which spans a hash of the
             Attestation Results (such as the signature of (2.4)), the
             proof-of-freshness from (3), and (4.2).  Note: this construct
             allows the delta of time between (2.3) and (3) to be
             definitively calculated by the Relying Party.

     5.  On receipt of (4), the Relying Party applies its Appraisal Policy
         for Attestation Results.  At minimum, this appraisal policy
         process must include the following:

         1.  Verify that (4.3) includes the nonce from (3).

         2.  Use a local certificate to validate the signature (4.1).

         3.  Verify that the hash from (4.3) matches (4.1)

         4.  Use the identity of (2.1) to validate the signature of (4.3).

         5.  Failure of any steps (5.1) through (5.4) means the link does
             not meet minimum validation criteria, therefore appraise the
             link as having a null Verifier B Trustworthiness Vector.
             Jump to step (6.1).

         6.  When there is large or uncertain time gap between time(EG)
             and time(EG'), the link should be assigned a null Verifier B
             Trustworthiness Vector.  Jump to step (6.1).

         7.  Assemble the Verifier B Trustworthiness Vector

             1.  Copy Verifier A Trustworthiness Vector to Verifier B
                 Trustworthiness Vector

             2.  Add implicit Trustworthiness Claims inherent to the type
                 of TEE.

             3.  Prune any Trustworthiness Claims unsupportable by the
                 Attesting Environment.

             4.  Prune any Trustworthiness Claims the Relying Party
                 doesn't accept from this Verifier.

     6.  The Relying Party takes action based on Verifier B's appraised
         Trustworthiness Vector, and applies the Appraisal Policy for
         Attestation Results.  Following is a reasonable process for such
         evaluation:






  Voit, et al.            Expires 16 February 2026               [Page 28]


  Internet-Draft             Attestation Results               August 2025


         1.  Prune any Trustworthiness Claims from the Trustworthiness
             Vector not used in the Appraisal Policy for Attestation
             Results.

         2.  Allow the information exchange from the Attester into a
             Relying Party context in the Appraisal Policy for Attestation
             Results where the Verifier B appraised Trustworthiness Vector
             includes all the mandatory Trustworthiness Claims are in the
             "Affirming" value range, and none of the disqualifying
             Trustworthiness Claims are in the "Contraindicated" value
             range.

         3.  Disallow any information exchange into a Relying Party
             context for which that Verifier B appraised Trustworthiness
             Vector is not qualified.

     As link layer protocols re-authenticate, steps (1) to (2) and steps
     (3) to (6) will independently refresh.  This allows the
     Trustworthiness of Attester to be continuously re-appraised.  There
     are only specific event triggers which will drive the refresh of
     Evidence generation (1), Attestation Result generation (2), or AR-
     augmented Evidence generation (4):

     *  life-cycle events, e.g. a change to an Authentication Secret of
        the Attester or an update of a software component.

     *  uptime-cycle events, e.g. a hard reset or a re-initialization of
        an Attester.

     *  authentication-cycle events, e.g. a link-layer interface reset
        could result in a new (4).

  4.3.  Mutual Attestation

     In the interaction models described above, each device on either side
     of a secure interaction may require remote attestation of its peer.
     This process is known as mutual-attestation.  To support mutual-
     attestation, the interaction models listed above may be run
     independently on either side of the connection.

  4.4.  Transport Protocol Integration

     Either unidirectional attestation or mutual attestation may be
     supported within the protocol interactions needed for the
     establishment of a single transport session.  While this document
     does not mandate specific transport protocols, messages containing
     the Attestation Results and AR Augmented Evidence can be passed
     within an authentication framework such the EAP protocol [RFC5247]



  Voit, et al.            Expires 16 February 2026               [Page 29]


  Internet-Draft             Attestation Results               August 2025


     over TLS [RFC8446].

  5.  Privacy Considerations

     Privacy Considerations Text

  6.  Security Considerations

     Security Considerations Text

  7.  IANA Considerations

     See Body.

  8.  References

  8.1.  Normative References

     [GP-TEE-PP]
                "Global Platform TEE Protection Profile v1.3", September
                2020, <https://globalplatform.org/specs-library/tee-
                protection-profile-v1-3/>.

     [OMTP-ATE] "Open Mobile Terminal Platform - Advanced Trusted
                Environment", May 2009, <https://www.gsma.com/newsroom/wp-
                content/uploads/2012/03/
                omtpadvancedtrustedenvironmentomtptr1v11.pdf>.

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

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

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




  Voit, et al.            Expires 16 February 2026               [Page 30]


  Internet-Draft             Attestation Results               August 2025


  8.2.  Informative References

     [ARM-CCA]  Frost, S., Fossati, T., and G. Mandyam, "Arm's
                Confidential Compute Architecture Reference Attestation
                Token", Work in Progress, Internet-Draft, draft-ffm-rats-
                cca-token-01, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ffm-rats-cca-
                token-01>.

     [I-D.ietf-rats-network-device-subscription]
                Birkholz, H., Voit, E., and W. Pan, "Attestation Event
                Stream Subscription", Work in Progress, Internet-Draft,
                draft-ietf-rats-network-device-subscription-07, 21 July
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                rats-network-device-subscription-07>.

     [IEEE802.1AR]
                "802.1AR: Secure Device Identity", 2 August 2018,
                <https://ieeexplore.ieee.org/document/8423794>.

     [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
                Authentication Protocol (EAP) Key Management Framework",
                RFC 5247, DOI 10.17487/RFC5247, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5247>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC9783]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
                Fossati, "Arm's Platform Security Architecture (PSA)
                Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June
                2025, <https://www.rfc-editor.org/rfc/rfc9783>.

     [SEV-SNP]  "AMD SEV-SNP: Stregthening VM Isolation with Integrity
                Protection and More", 2020,
                <https://www.amd.com/system/files/TechDocs/SEV-SNP-
                strengthening-vm-isolation-with-integrity-protection-and-
                more.pdf>.

     [SGX]      "Supporting Third Party Attestation for Intel SGX with
                Intel Data Center Attestation Primitives", 2017, <https://
                software.intel.com/content/dam/develop/external/us/en/
                documents/intel-sgx-support-for-third-party-attestation-
                801017.pdf>.






  Voit, et al.            Expires 16 February 2026               [Page 31]


  Internet-Draft             Attestation Results               August 2025


     [TDX]      "Intel Trust Domain Extensions", 2020, <https://software.i
                ntel.com/content/dam/develop/external/us/en/documents/tdx-
                whitepaper-final9-17.pdf>.

     [TPM-ID]   "TPM Keys for Platform Identity for TPM 1.2", August 2015,
                <https://www.trustedcomputinggroup.org/wp-content/uploads/
                TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf>.

     [TPM2.0]   "Trusted Platform Module Library - Part 1: Architecture",
                n.d., <https://trustedcomputinggroup.org/wp-
                content/uploads/TPM-Rev-2.0-Part-1-Architecture-
                01.07-2014-03-13.pdf>.

     [US-Executive-Order]
                "Executive Order on Improving the Nation's Cybersecurity",
                12 May 2021, <https://bidenwhitehouse.archives.gov/
                briefing-room/presidential-actions/2021/05/12/executive-
                order-on-improving-the-nations-cybersecurity/>.

  Appendix A.  Implementation Guidance

  A.1.  Supplementing Trustworthiness Claims

     What has been encoded into each Trustworthiness Claim is the domain
     of integer values which is likely to drive a different programmatic
     decision in the Relying Party's Appraisal Policy for Attestation
     Results.  This will not be the only thing a Relying Party's
     Operations team might care to track for measurement or debugging
     purposes.

     There is also the opportunity for the Verifier to include
     supplementary Evidence beyond a set of asserted Trustworthiness
     Claims.  It is recommended that if supplementary Evidence is provided
     by the Verifier within the Attestation Results, that this
     supplementary Evidence includes a reference to a specific
     Trustworthiness Claim.  This will allow a deeper understanding of
     some of the reasoning behind the integer value assigned.

  Appendix B.  Supportable Trustworthiness Claims

     The following is a table which shows what Claims are supportable by
     different Attesting Environment types.  Note that claims MAY BE
     implicit to an Attesting Environment type, and therefore do not have
     to be included in the Trustworthiness Vector to be considered as set
     by the Relying Party.






  Voit, et al.            Expires 16 February 2026               [Page 32]


  Internet-Draft             Attestation Results               August 2025


  B.1.  Supportable Trustworthiness Claims for HSM-based CC

     Following are Trustworthiness Claims which MAY be set for a HSM-based
     Confidential Computing Attester.  (Such as a TPM [TPM-ID].)















































  Voit, et al.            Expires 16 February 2026               [Page 33]


  Internet-Draft             Attestation Results               August 2025


     +===================+===========+==================================+
     | Trustworthiness   | Required? | Appraisal Method                 |
     | Claim             |           |                                  |
     +===================+===========+==================================+
     | configuration     | Optional  | Verifier evaluation of Attester  |
     |                   |           | reveals no configuration lines   |
     |                   |           | which expose the Attester to     |
     |                   |           | known security vulnerabilities.  |
     |                   |           | This may be done with or without |
     |                   |           | the involvement of a TPM PCR.    |
     +-------------------+-----------+----------------------------------+
     | executables       | Yes       | Checks the TPM PCRs for the      |
     |                   |           | static operating system, and for |
     |                   |           | any tracked files subsequently   |
     |                   |           | loaded                           |
     +-------------------+-----------+----------------------------------+
     | file-system       | No        | Can be supported, but TPM        |
     |                   |           | tracking is unlikely             |
     +-------------------+-----------+----------------------------------+
     | hardware          | Yes       | If TPM PCR check ok from BIOS    |
     |                   |           | checks, through Master Boot      |
     |                   |           | Record configuration             |
     +-------------------+-----------+----------------------------------+
     | instance-identity | Optional  | Check IDevID                     |
     +-------------------+-----------+----------------------------------+
     | runtime-opaque    | n/a       | TPMs are not recommended to      |
     |                   |           | provide a sufficient technology  |
     |                   |           | base for this Trustworthiness    |
     |                   |           | Claim.                           |
     +-------------------+-----------+----------------------------------+
     | sourced-data      | n/a       | TPMs are not recommended to      |
     |                   |           | provide a sufficient technology  |
     |                   |           | base for this Trustworthiness    |
     |                   |           | Claim.                           |
     +-------------------+-----------+----------------------------------+
     | storage-opaque    | Minimal   | With a TPM, secure storage space |
     |                   |           | exists and is writeable by       |
     |                   |           | external applications.  But the  |
     |                   |           | space is so limited that it      |
     |                   |           | often is used just be used to    |
     |                   |           | store keys.                      |
     +-------------------+-----------+----------------------------------+

                                   Table 2

     Setting the Trustworthiness Claims may follow the following logic at
     the Verifier A within (2) of Figure 5:




  Voit, et al.            Expires 16 February 2026               [Page 34]


  Internet-Draft             Attestation Results               August 2025


     Start: Evidence received starts the generation of a new
     Trustworthiness Vector.  (e.g.,  TPM Quote Received, log received,
     or appraisal timer expired)

     Step 0: set Trustworthiness Vector = Null

     Step 1: Is there sufficient fresh signed evidence to appraise?
       (yes) - No Action
       (no) -  Goto Step 6

     Step 2: Appraise Hardware Integrity PCRs
        if (hardware NOT "0") - push onto vector
        if (hardware NOT affirming or warning), go to Step 6

     Step 3: Appraise Attesting Environment identity
        if (instance-identity <> "0") - push onto vector

     Step 4: Appraise executable loaded and filesystem integrity
        if (executables NOT "0") - push onto vector
        if (executables NOT affirming or warning), go to Step 6

     Step 5: Appraise all remaining Trustworthiness Claims
             Independently and set as appropriate.

     Step 6: Assemble Attestation Results, and push to Attester

     End

  B.2.  Supportable Trustworthiness Claims for process-based CC

     Following are Trustworthiness Claims which MAY be set for a process-
     based Confidential Computing based Attester.  (Such as a SGX Enclaves
     and TrustZone.)


















  Voit, et al.            Expires 16 February 2026               [Page 35]


  Internet-Draft             Attestation Results               August 2025


     +===================+===========+==================================+
     | Trustworthiness   | Required? | Appraisal Method                 |
     | Claim             |           |                                  |
     +===================+===========+==================================+
     | instance-identity | Optional  | Internally available in TEE.     |
     |                   |           | But keys might not be known/     |
     |                   |           | exposed to the Relying Party by  |
     |                   |           | the Attesting Environment.       |
     +-------------------+-----------+----------------------------------+
     | configuration     | Optional  | If done, this is at the          |
     |                   |           | Application Layer.  Plus each    |
     |                   |           | process needs it own protection  |
     |                   |           | mechanism as the protection is   |
     |                   |           | limited to the process itself.   |
     +-------------------+-----------+----------------------------------+
     | executables       | Optional  | Internally available in TEE.     |
     |                   |           | But keys might not be known/     |
     |                   |           | exposed to the Relying Party by  |
     |                   |           | the Attesting Environment.       |
     +-------------------+-----------+----------------------------------+
     | file-system       | Optional  | Can be supported by application, |
     |                   |           | but process-based CC is not a    |
     |                   |           | sufficient technology base for   |
     |                   |           | this Trustworthiness Claim.      |
     +-------------------+-----------+----------------------------------+
     | hardware          | Implicit  | At least the TEE is protected    |
     |                   | in        | here.  Other elements of the     |
     |                   | signature | system outside of the TEE might  |
     |                   |           | need additional protections is   |
     |                   |           | used by the application process. |
     +-------------------+-----------+----------------------------------+
     | runtime-opaque    | Implicit  | From the TEE                     |
     |                   | in        |                                  |
     |                   | signature |                                  |
     +-------------------+-----------+----------------------------------+
     | storage-opaque    | Implicit  | Although the application must    |
     |                   | in        | assert that this function is     |
     |                   | signature | used by the code itself.         |
     +-------------------+-----------+----------------------------------+
     | sourced-data      | Optional  | Will need to be supported by     |
     |                   |           | application code                 |
     +-------------------+-----------+----------------------------------+

                                   Table 3







  Voit, et al.            Expires 16 February 2026               [Page 36]


  Internet-Draft             Attestation Results               August 2025


  B.3.  Supportable Trustworthiness Claims for VM-based CC

     Following are Trustworthiness Claims which MAY be set for a VM-based
     Confidential Computing based Attester.  (Such as SEV, TDX, ACCA, SEV-
     SNP.)

     +===================+===========+===================================+
     | Trustworthiness   | Required? | Appraisal Method                  |
     | Claim             |           |                                   |
     +===================+===========+===================================+
     | instance-identity | Optional  | Internally available in TEE.      |
     |                   |           | But keys might not be known/      |
     |                   |           | exposed to the Relying Party by   |
     |                   |           | the Attesting Environment.        |
     +-------------------+-----------+-----------------------------------+
     | configuration     | Optional  | Requires application              |
     |                   |           | integration.  Easier than with    |
     |                   |           | process-based solution, as the    |
     |                   |           | whole protected machine can be    |
     |                   |           | evaluated.                        |
     +-------------------+-----------+-----------------------------------+
     | executables       | Optional  | Internally available in TEE.      |
     |                   |           | But keys might not be known/      |
     |                   |           | exposed to the Relying Party by   |
     |                   |           | the Attesting Environment.        |
     +-------------------+-----------+-----------------------------------+
     | file-system       | Optional  | Can be supported by application   |
     +-------------------+-----------+-----------------------------------+
     | hardware          | Chip      | At least the TEE is protected     |
     |                   | dependent | here.  Other elements of the      |
     |                   |           | system outside of the TEE might   |
     |                   |           | need additional protections is    |
     |                   |           | used by the application process.  |
     +-------------------+-----------+-----------------------------------+
     | runtime-opaque    | Implicit  | From the TEE                      |
     |                   | in        |                                   |
     |                   | signature |                                   |
     +-------------------+-----------+-----------------------------------+
     | storage-opaque    | Chip      | Although the application must     |
     |                   | dependent | assert that this function is      |
     |                   |           | used by the code itself.          |
     +-------------------+-----------+-----------------------------------+
     | sourced-data      | Optional  | Will need to be supported by      |
     |                   |           | application code                  |
     +-------------------+-----------+-----------------------------------+

                                    Table 4




  Voit, et al.            Expires 16 February 2026               [Page 37]


  Internet-Draft             Attestation Results               August 2025


  Appendix C.  Some issues being worked

     It is possible for a cluster/hierarchy of Verifiers to have aggregate
     AR which are perhaps signed/endorsed by a lead Verifier.  What should
     be the Proof-of-Freshness or Verifier associated with any of the
     aggregate set of Trustworthiness Claims?

     There will need to be a subsequent document which documents how these
     objects which will be translated into a protocol on a wire (e.g. EAP
     on TLS).  Some breakpoint between what is in this draft, and what is
     in specific drafts for wire encoding will need to be determined.
     Questions like architecting the cluster/hierarchy of Verifiers fall
     into this breakdown.

     For some Trustworthiness Claims, there could be value in identifying
     a specific Appraisal Policy for Attestation Results applied within
     the Attester.  One way this could be done would be a URI which
     identifies the policy used at Verifier A, and this URI would
     reference a specific Trustworthiness Claim.  As the URI also could
     encode the version of the software, it might also act as a mechanism
     to signal the Relying Party to refresh/re-evaluate its view of
     Verifier A.  Do we need this type of structure to be included here?
     Should it be in subsequent documents?

     Expand the variant of Figure 5 which requires no Relying Party PoF
     into its own picture.

     In what document (if any) do we attempt normalization of the identity
     claims between different types of TEE.  E.g., does MRSIGNER plus
     extra loaded software = the sum of TrustZone Signer IDs for loaded
     components?

  Appendix D.  Contributors

     Guy Fedorkow

     Email: gfedorkow@juniper.net

     Dave Thaler

     Email: dthaler@microsoft.com

     Ned Smith

     Email: ned.smith@intel.com

     Lawrence Lundblade




  Voit, et al.            Expires 16 February 2026               [Page 38]


  Internet-Draft             Attestation Results               August 2025


     Email: lgl@island-resort.com

  Authors' Addresses

     Eric Voit
     Cisco Systems
     Email: evoit@cisco.com


     Henk Birkholz
     Fraunhofer SIT
     Rheinstrasse 75
     64295 Darmstadt
     Germany
     Email: henk.birkholz@sit.fraunhofer.de


     Thomas Hardjono
     MIT
     Email: hardjono@mit.edu


     Thomas Fossati
     Linaro
     Email: Thomas.Fossati@linaro.org


     Vincent Scarlata
     Intel
     Email: vincent.r.scarlata@intel.com





















  Voit, et al.            Expires 16 February 2026               [Page 39]


name: draft-ietf-rats-coserv
rev: 05
title: Concise Selector for Endorsements and Reference Values
time: 2026-03-02T14:30:53Z
group_uri: /api/v1/group/group/2231/
expires: 2026-09-03T14:30:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.318429+00:00
source: ietf
source_id: 149772
source_url: https://datatracker.ietf.org/doc/draft-ietf-rats-coserv/
doc_status: active
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.

full_text:
  Remote ATtestation ProcedureS                                  P. Howard
  Internet-Draft                                                       Arm
  Intended status: Informational                                T. Fossati
  Expires: 3 September 2026                                         Linaro
                                                               H. Birkholz
                                                            Fraunhofer SIT
                                                                  S. Kamal
                                                                   Fujitsu
                                                                G. Mandyam
                                                                       AMD
                                                                     D. Ma
                                                             Alibaba Cloud
                                                              2 March 2026


           Concise Selector for Endorsements and Reference Values
                         draft-ietf-rats-coserv-05

  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://ietf-rats-
     wg.github.io/draft-ietf-rats-coserv/draft-ietf-rats-coserv.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-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/ietf-rats-wg/draft-ietf-rats-coserv.





  Howard, et al.          Expires 3 September 2026                [Page 1]


  Internet-Draft                   CoSERV                       March 2026


  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at 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 3 September 2026.

  Copyright Notice

     Copyright (c) 2026 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.  Aggregation and Trust Models  . . . . . . . . . . . . . . . .   5
     3.  CoSERV Information Model  . . . . . . . . . . . . . . . . . .   6
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Artifacts . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  Environments  . . . . . . . . . . . . . . . . . . . . . .   8
         3.3.1.  Stateful Environments . . . . . . . . . . . . . . . .   9
       3.4.  Queries . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.5.  Result Sets . . . . . . . . . . . . . . . . . . . . . . .  10
     4.  CoSERV Data Model . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  Common Data Types . . . . . . . . . . . . . . . . . . . .  12
       4.2.  Profile . . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.3.  Query Structure . . . . . . . . . . . . . . . . . . . . .  12
         4.3.1.  Artifact Type . . . . . . . . . . . . . . . . . . . .  13



  Howard, et al.          Expires 3 September 2026                [Page 2]


  Internet-Draft                   CoSERV                       March 2026


         4.3.2.  Environment Selector  . . . . . . . . . . . . . . . .  13
         4.3.3.  Result Type . . . . . . . . . . . . . . . . . . . . .  15
       4.4.  Result Set Structure  . . . . . . . . . . . . . . . . . .  16
       4.5.  Encoding Requirements . . . . . . . . . . . . . . . . . .  17
       4.6.  Cryptographic Binding Between Query and Result Set  . . .  17
     5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.1.  Query Data Examples . . . . . . . . . . . . . . . . . . .  18
       5.2.  Result Data Examples  . . . . . . . . . . . . . . . . . .  19
     6.  API Bindings  . . . . . . . . . . . . . . . . . . . . . . . .  22
       6.1.  Request Response over HTTP  . . . . . . . . . . . . . . .  23
         6.1.1.  Discovery . . . . . . . . . . . . . . . . . . . . . .  23
         6.1.2.  Execute Query . . . . . . . . . . . . . . . . . . . .  28
         6.1.3.  Caching . . . . . . . . . . . . . . . . . . . . . . .  32
     7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  37
       7.1.  Veraison  . . . . . . . . . . . . . . . . . . . . . . . .  38
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  38
       8.1.  In Relation to CoRIM  . . . . . . . . . . . . . . . . . .  39
       8.2.  Forming Native Database Queries from CoSERV . . . . . . .  39
       8.3.  Aggregators . . . . . . . . . . . . . . . . . . . . . . .  39
     9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  41
       9.1.  Aggregators . . . . . . . . . . . . . . . . . . . . . . .  42
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  42
       10.1.  Media Types Registrations  . . . . . . . . . . . . . . .  42
         10.1.1.  application/coserv+cbor  . . . . . . . . . . . . . .  42
         10.1.2.  application/coserv+cose  . . . . . . . . . . . . . .  43
         10.1.3.  application/coserv-discovery+cbor  . . . . . . . . .  43
         10.1.4.  application/coserv-discovery+json  . . . . . . . . .  44
       10.2.  CoAP Content-Formats . . . . . . . . . . . . . . . . . .  44
       10.3.  Well-Known URI for CoSERV Configuration  . . . . . . . .  45
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  45
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  45
       11.2.  Informative References . . . . . . . . . . . . . . . . .  47
     Appendix A.  Collated CDDL  . . . . . . . . . . . . . . . . . . .  48
       A.1.  CoSERV Data Model . . . . . . . . . . . . . . . . . . . .  48
       A.2.  API Discovery Data Model  . . . . . . . . . . . . . . . .  61
     Appendix B.  OpenAPI Schema . . . . . . . . . . . . . . . . . . .  64
     Appendix C.  Locating CoSERV Services . . . . . . . . . . . . . .  66
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  67
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  68

  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



  Howard, et al.          Expires 3 September 2026                [Page 3]


  Internet-Draft                   CoSERV                       March 2026


     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.

     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.

     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 Section 6 for the API binding specifications.

  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.




  Howard, et al.          Expires 3 September 2026                [Page 4]


  Internet-Draft                   CoSERV                       March 2026


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



  Howard, et al.          Expires 3 September 2026                [Page 5]


  Internet-Draft                   CoSERV                       March 2026


     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.

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

     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.

  3.  CoSERV Information Model

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



  Howard, et al.          Expires 3 September 2026                [Page 6]


  Internet-Draft                   CoSERV                       March 2026


     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.

  3.2.  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 three artifact types.  These
     correspond to the three categories of endorsement artifact that can
     be identified natively in the RATS architecture:

     *  *Trust Anchor*: 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 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 [RFC9334] and
        [I-D.ietf-rats-endorsements].  Section 4 of
        [I-D.ietf-rats-endorsements] 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 Section 1.1.1
        of [I-D.ietf-rats-corim].  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
        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".



  Howard, et al.          Expires 3 September 2026                [Page 7]


  Internet-Draft                   CoSERV                       March 2026


        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.

     When artifacts are produced by an aggregator (see Section 2), 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 Arfifacts*: 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.

  3.3.  Environments

     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 [I-D.ietf-rats-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.




  Howard, et al.          Expires 3 September 2026                [Page 8]


  Internet-Draft                   CoSERV                       March 2026


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

  3.3.1.  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 [I-D.ietf-rats-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.

  3.4.  Queries

     The purpose of a query is to allow the consumer (Verifier) to specify
     the artifacts that it needs.  The information that is conveyed in a
     CoSERV query includes the following:

     *  A specification of the required artifact type: Reference Value,
        Endorsed Value or Trust Anchor.  See Section 3.2 for definitions
        of artifact types.  A single CoSERV query can only specify a
        single artifact type.





  Howard, et al.          Expires 3 September 2026                [Page 9]


  Internet-Draft                   CoSERV                       March 2026


     *  A specification of the Attester's environment.  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 Section 3.3
        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
        Section 2 for details on aggregation, auditing and trust models.

     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
     Section 4.5, 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 Section 6.1.3.

     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.

  3.5.  Result Sets

     The result set contains the artifacts that the producer collected in
     response to the query.  The top-level structure of the result set
     consists of the following three items:





  Howard, et al.          Expires 3 September 2026               [Page 10]


  Internet-Draft                   CoSERV                       March 2026


     *  A collection of one or more result entries.  This will be a
        collection of either reference values, endorsed values or trust
        anchors.  See Section 3.2 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 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.

     *  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
     Section 5.1.4 of [I-D.ietf-rats-corim].  Each CoMID triple will
     demonstrate the association between an environment matching that of
     the CoSERV query, and a single artifact such as a reference value,
     trust anchor or endorsed value.  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).

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



  Howard, et al.          Expires 3 September 2026               [Page 11]


  Internet-Draft                   CoSERV                       March 2026


     The top-level CoSERV data structure is given by the following CDDL:

     ;# import comid-autogen

     coserv = {
       &(profile: 0) => profile
       &(query: 1) => query
       ? &(results: 2) => results
     }

     profile = comid.oid-type / ~uri

  4.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.1.

  4.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 [RFC9711].

  4.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, et al.          Expires 3 September 2026               [Page 12]


  Internet-Draft                   CoSERV                       March 2026


     query = {
       &(artifact-type: 0) => artifact-type
       &(environment-selector: 1) => environment-selector-map
       &(result-type: 2) => result-type
     }

     artifact-type = &(endorsed-values: 0)
                     / &(trust-anchors: 1)
                     / &(reference-values: 2)

     result-type = &(collected-artifacts: 0)
                   / &(source-artifacts: 1)
                   / &(both: 2)

     The meanings of these fields are detailed in the following
     subsections.

  4.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).

     See Section 3.2 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.

  4.3.2.  Environment Selector

     The environment selector forms the main body of the query, and its
     CDDL is given below:













  Howard, et al.          Expires 3 September 2026               [Page 13]


  Internet-Draft                   CoSERV                       March 2026


     ;# import comid-autogen

     environment-selector-map = { selector }

     stateful-class = [
       class: comid.class-map
       ? measurements: [ + comid.measurement-map ]
     ]

     selector //= ( &(class: 0) => [
       + 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 Section 3.3 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.





  Howard, et al.          Expires 3 September 2026               [Page 14]


  Internet-Draft                   CoSERV                       March 2026


     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 Section 3.3.1 for a
     description of stateful environments.

  4.3.2.1.  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:

     SELECT *
       FROM endorsed_values
      WHERE ( instance-id = "At6tvu/erQ==" ) OR
            ( instance-id = "iZl4ZVY=" )`

     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:

     SELECT *
       FROM reference_values
      WHERE ( class-id = "iZl4ZVY=" AND class-vendor = "ACME Inc." ) OR
            ( class-id = "31fb5abf-023e-4992-aa4e-95f9c1503bfa" )

  4.3.3.  Result Type

     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 Section 2 for definitions of source and
     collected artifacts.







  Howard, et al.          Expires 3 September 2026               [Page 15]


  Internet-Draft                   CoSERV                       March 2026


  4.4.  Result Set Structure

     The result set structure is given by the following CDDL:

     ;# import cmw-autogen
     ;# import comid-autogen

     results = {
       result-set
       &(expiry: 10) => tdate ; RFC3339 date
       ? &(source-artifacts: 11) => [ + cmw.cbor-record ]
     }

     result-set //= reference-values
     result-set //= endorsed-values
     result-set //= trust-anchors

     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 ]



  Howard, et al.          Expires 3 September 2026               [Page 16]


  Internet-Draft                   CoSERV                       March 2026


       &(cots: 2) => cots
     }

     trust-anchors = (
       &(akq: 3) => [ * ak-quad ]
       &(tas: 4) => [ * cots-stmt ]
     )

     ;
     ; import CoTS
     ;
     cots = "TODO COTS"

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

  4.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 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
     [STD96].  A signed-coserv is a COSE_Sign1 with the following layout:

     signed-coserv = #6.18([
       protected: bytes .cbor signed-coserv-protected-hdr
       unprotected: signed-coserv-unprotected-hdr
       payload: bytes .cbor coserv
       signature: bytes
     ])




  Howard, et al.          Expires 3 September 2026               [Page 17]


  Internet-Draft                   CoSERV                       March 2026


     The payload MUST be the CBOR-encoded CoSERV.

     (Artwork only available as CDDL: see
     https://www.ietf.org/archive/id/draft-ietf-rats-coserv-05.html)

     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.

  5.  Examples

  5.1.  Query Data Examples

     This section provides some illustrative examples of valid CoSERV
     query objects.

     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"
             }
           ] ]
         },
         / result-type / 2: 1 / source-artifacts /
       }
     }

     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.





  Howard, et al.          Expires 3 September 2026               [Page 18]


  Internet-Draft                   CoSERV                       March 2026


     {
       / 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 /
             } ]
           ]
         },
         / result-type / 2: 2 / both collected and source artifacts /
       }
     }

     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 /
           ]
         },
         / result-type / 2: 0 / collected artifacts /
       }
     }

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



  Howard, et al.          Expires 3 September 2026               [Page 19]


  Internet-Draft                   CoSERV                       March 2026


     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 [I-D.ietf-rats-corim].








































  Howard, et al.          Expires 3 September 2026               [Page 20]


  Internet-Draft                   CoSERV                       March 2026


     {
       / profile / 0: "tag:example.com,2025:cc-platform#1.0.0",
       / query / 1: {
         0: 2,
         1: {
           0: [ [
             {
               0: 560(h'8999786556')
             }
           ] ]
         },
         2: 0
       },
       / results / 2: {
         0: [
           {
             1: [ 560(h'abcdef') ],
             2: [
               {
                 0: {
                   0: 560(h'8999786556')
                 }
               },
               [
                 {
                   0: 37(h'31FB5ABF023E4992AA4E95F9C1503BFA'),
                   1: {
                     / version / 0: {
                       0: "1.2.3",
                       1: 16384
                     },
                     / svn / 1: 553(2)
                   }
                 }
               ]
             ]
           }
         ],
         10: 0("2030-12-13T18:30:02Z")
       }
     }

     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.





  Howard, et al.          Expires 3 September 2026               [Page 21]


  Internet-Draft                   CoSERV                       March 2026


     Compared with the previous example, the rvq entry is empty, while the
     source-artifacts (codepoint 11) contain two CMW records
     [I-D.ietf-rats-msg-wrap], each of which contains a (made up) manifest
     with the type "application/vnd.example.refvals".

     {
       / 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: 1 / source-artifacts /
       },
       / results / 2: {
         / rvq / 0: [ ],
         / expiry / 10: 0("2030-12-13T18:30:02Z"),
         / source artifacts / 11: [
           [ "application/vnd.example.refvals", h'afaeadac' ],
           [ "application/vnd.example.refvals", h'adacabaa' ]
         ]
       }
     }

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




  Howard, et al.          Expires 3 September 2026               [Page 22]


  Internet-Draft                   CoSERV                       March 2026


     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 [RFC7252].

  6.1.  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 Section 4.5.  This means that any given CoSERV query will
     always encode to the same sequence of bytes.  The Base64Url encoding
     (Section 2 of [RFC7515]) of the byte sequence becomes the rightmost
     path segment of the URI used to identify the target resource.  The
     HTTP GET verb 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.

  6.1.1.  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
     [RFC8615].  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 available via an HTTP GET
     method with no additional query parameters.

     The response body can be formatted using either JSON or CBOR,
     governed by standard HTTP content-type negotiation.  The media types
     defined for this purpose are application/coserv-discovery+json (for
     JSON-formatted documents) or application/coserv-discovery+cbor (for



  Howard, et al.          Expires 3 September 2026               [Page 23]


  Internet-Draft                   CoSERV                       March 2026


     CBOR-formatted documents).  If the client presents any media type
     other than these two options in its HTTP Accept header, the
     implementation SHOULD respond with an HTTP 406 (Not Acceptable)
     status code.  If the client presents one of the two valid media
     types, then the implementation MUST respond with an 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 body MUST contain exactly one
     discovery document in the requested format (JSON or CBOR).  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.

     ;# import rfc9711 as eat
     ;# import cmw-autogen as cmw
     ;# import rfc9052 as cose
     ;# import jwk-autogen as jwk

     coserv-well-known-info = {
       version-label => version,
       capabilities-label => [ + capability ],
       api-endpoints-label => { + tstr => tstr },
       ? result-verification-key-label => eat.JC<jwk.JWK_Set, cose.COSE_KeySet>
     }

     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> = (M) .and ([ + any ])
     artifact-support = non-empty-array<[ ? "source", ? "collected" ]>

  6.1.1.1.  Discovery Document Contents

     This section defines how to populate and interpret the data fields in
     the discovery document.




  Howard, et al.          Expires 3 September 2026               [Page 24]


  Internet-Draft                   CoSERV                       March 2026


     The collated CDDL is in Appendix A.2.

  6.1.1.1.1.  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
     [SEMVER].  Version numbers and patch levels are otherwise
     implementation-defined.

  6.1.1.1.2.  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 artifact categories are source and collected, as described in
     Section 3.2.  Each profile is paired with a non-empty set of artifact
     categories, allowing the service implementation to indicate whether
     it supports the retrieval of source artifacts, collected artifacts,
     or both.  This pairing caters for situations where the service
     implementation might support different combinations of artifact
     category for different profiles.

  6.1.1.1.3.  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 URL for making HTTP API calls.
     The field is a map whose keys are the symbolic names of the APIs, and
     whose values are the URL path for the API endpoint.

     The symbolic name CoSERVRequestResponse is defined for services that
     offer the transactional API described in Section 6.1.2.  Service
     implementations that offer this API MUST include a key with this name
     in the endpoints map field, and the corresponding endpoint URL path
     MUST end with /{query}. This allows the consumer to form a valid
     CoSERV query URI using variable expansion as per [RFC6570], replacing
     the {query} variable with the Base64Url-encoded CoSERV query object.
     There MUST NOT be any other variables that require substitution.





  Howard, et al.          Expires 3 September 2026               [Page 25]


  Internet-Draft                   CoSERV                       March 2026


  6.1.1.1.4.  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
     [RFC7517].  In CBOR-formatted discovery documents, each key is a COSE
     Key as defined in [STD96].

     This field is optional.  As described in Section 4.6, 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.

  6.1.1.2.  Discovery Document CBOR Encoding

     When the discovery document is encoded as CBOR, it is exempt from the
     encoding rules specified in Section 4.5.  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.

  6.1.1.3.  Discovery Document Examples

     In the following examples, the contents of bodies are informative
     examples only.

     Example HTTP request for retrieving the discovery document in JSON
     format:






  Howard, et al.          Expires 3 September 2026               [Page 26]


  Internet-Draft                   CoSERV                       March 2026


     GET /.well-known/coserv-configuration HTTP/1.1
     Host: endorsements-distributor.example
     Accept: application/coserv-discovery+json

     Corresponding HTTP response:

     HTTP/1.1 200 OK
     Content-Type: application/coserv-discovery+json

     Body (JSON)

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
       "version": "1.2.3-beta",
       "capabilities": [
         {
           "media-type": "application/coserv+cose; profile=\"tag:vendor.\
                                            com,2025:cc_platform#1.0.0\"",
           "artifact-support": [
             "source",
             "collected"
           ]
         }
       ],
       "api-endpoints": {
         "CoSERVRequestResponse": "/endorsement-distribution/v1/coserv/{\
                                                                   query}"
       },
       "result-verification-key": [
         {
           "alg": "ES256",
           "crv": "P-256",
           "kty": "EC",
           "x": "usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8",
           "y": "IBOL-C3BttVivg-lSreASjpkttcsz-1rb7btKLv8EX4",
           "kid": "key1"
         }
       ]
     }

     Example HTTP request for retrieving the discovery document in CBOR
     format:

     GET /.well-known/coserv-configuration HTTP/1.1
     Host: endorsements-distributor.example
     Accept: application/coserv-discovery+cbor




  Howard, et al.          Expires 3 September 2026               [Page 27]


  Internet-Draft                   CoSERV                       March 2026


     Corresponding HTTP response:

     HTTP/1.1 200 OK
     Content-Type: application/coserv-discovery+cbor

     Body (in CBOR Extended Diagnostic Notation (EDN))

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
       / version / 1: "1.2.3-beta",
       / capabilities / 2: [
         {
           / media-type / 1: "application/coserv+cose; profile=\"tag:\
                                     vendor.com,2025:cc_platform#1.0.0\"",
           / artifact-support / 2: [
             "source",
             "collected"
           ]
         }
       ],
       / api-endpoints / 3: {
         "CoSERVRequestResponse": "/endorsement-distribution/v1/coserv/{\
                                                                   query}"
       },
       / result-verification-key / 4: [
         {
           / kty / 1: 2,
           / alg / 3: -7,
           / crv / -1: 1,
           / x / -2: h'1A2B3C4D',
           / y / -3: h'5E6F7A8B',
           / kid / 2: h'ABCDEF1234'
         }
       ]
     }

  6.1.2.  Execute Query

     This endpoint executes a single CoSERV query and returns a CoSERV
     result set.

     The HTTP method is GET.

     The URL path is formed of the discovered coserv endpoint (as set out
     in Section 6.1.1), 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.



  Howard, et al.          Expires 3 September 2026               [Page 28]


  Internet-Draft                   CoSERV                       March 2026


     There are no additional URL query parameters.

     Clients MUST set the HTTP Accept header to a suitably-profiled
     application/coserv+cose or application/coserv+cbor media type.

     Endpoint implementations MUST respond with an HTTP status code and
     response body according to one of the subheadings below.

  6.1.2.1.  Responses

  6.1.2.1.1.  Successful Transaction (200)

     This response indicates that the CoSERV query was executed
     successfully.

     Example HTTP request:

     # NOTE: '\' line wrapping per RFC 8792

     GET /coserv/ogB4I3R... HTTP/1.1
     Host: endorsements-distributor.example
     Accept: application/coserv+cose; \
             profile="tag:vendor.com,2025:cc_platform#1.0.0"

     Example HTTP response:

     # NOTE: '\' line wrapping per RFC 8792

     HTTP/1.1 200 OK
     Content-Type: application/coserv+cose; \
                   profile="tag:vendor.com,2025:cc_platform#1.0.0"

     Body (in CBOR Extended Diagnostic Notation (EDN))

     / signed-coserv / 18([
       / protected / << {
         / alg / 1: -7 / ECDSA 256 /,
         / cty / 2 : "application/coserv+cbor"
       } >>,
       / 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: [ [
             {



  Howard, et al.          Expires 3 September 2026               [Page 29]


  Internet-Draft                   CoSERV                       March 2026


               / 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'



  Howard, et al.          Expires 3 September 2026               [Page 30]


  Internet-Draft                   CoSERV                       March 2026


     ])

  6.1.2.1.2.  Failure to Validate Query (400)

     This response indicates that the supplied query is badly formed.

     Example HTTP request:

     # NOTE: '\' line wrapping per RFC 8792

     GET /coserv/badquery... HTTP/1.1
     Host: endorsements-distributor.example
     Accept: application/coserv+cose; \
             profile="tag:vendor.com,2025:cc_platform#1.0.0"

     Example HTTP response:

     # NOTE: '\' line wrapping per RFC 8792

     HTTP/1.1 400 Bad Request
     Content-Type: application/concise-problem-details+cbor

     Body (in CBOR Extended Diagnostic Notation (EDN))

     {
       / title /  -1: "Query validation failed",
       / detail / -2: "The query payload is not in CBOR format"
     }

  6.1.2.1.3.  Failure to Negotiate Profile (406)

     This response indicates that the client has specified a CoSERV
     profile that is not understood or serviceable by the receiving
     endpoint implementation.

     Example HTTP request:

     # NOTE: '\' line wrapping per RFC 8792

     GET /coserv/ogB4I3R... HTTP/1.1
     Host: endorsements-distributor.example
     Accept: application/coserv+cose; \
             profile="tag:vendor.com,2025:cc_platform#2.0.0"

     Example HTTP response:






  Howard, et al.          Expires 3 September 2026               [Page 31]


  Internet-Draft                   CoSERV                       March 2026


     # NOTE: '\' line wrapping per RFC 8792

     HTTP/1.1 406 Not Acceptable
     Content-Type: application/concise-problem-details+cbor

     Body (in CBOR Extended Diagnostic Notation (EDN))

     {
       / title /  -1: "Unsupported profile",
       / detail / -2: "Profile tag:vendor.com,2025:cc_platform#2.0.0 \
                       not supported",
     }

  6.1.3.  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
     [STD98].  This includes use of the HTTP Cache-Control header 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 URL paths.  As specified in
        Section 4.5, 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.










  Howard, et al.          Expires 3 September 2026               [Page 32]


  Internet-Draft                   CoSERV                       March 2026


     *  The result set is cryptographically bound to the query.  As
        specified in Section 4.6, 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.

     *  The use of safe HTTP methods.  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.

  6.1.3.1.  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
     result set payload.

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

















  Howard, et al.          Expires 3 September 2026               [Page 33]


  Internet-Draft                   CoSERV                       March 2026


     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.

        |  This "differential caching" strategy could be useful if the
        |  origin and its CDN have control plane APIs that the origin
        |  owner can use to instruct the CDN operator to purge certain
        |  cached entries [RFC8007].  For instance, in CoSERV, this
        |  feature could be used in case of an unexpected revocation.






























  Howard, et al.          Expires 3 September 2026               [Page 34]


  Internet-Draft                   CoSERV                       March 2026


   client A             cache.example          coserv.example
                            .---.                   .-.
       o                   |     |                 |   |
       |                   |'---'|                  '+'
       |                   |     |                   |
       |                    '-+-'                    |
       |   GET ogB4I3RhZ..    |                      |
       +--------------------->| lookup(obB4I3RhZ..)  |
       |                      +---.                  |
       |                      |    |                 |
       |                      |<--'                  |
       |                      | MISS                 |
       |                      |                      |
       |                      |   GET ogB4I3RhZ..    |
       |                      +--------------------->|
       |                      |                      +---.  compute
       |                      |                      |    | result
       |                      |                      |<--'  set
       |                      |  200 OK              | (expiry = now + 1h)
       |                      |  C-C: max-age=600,   |
       |                      |       s-maxage=3600  |
       |                      |  #6.18([...])        |
       |                      |<---------------------+
       |                      |                      |
       |                      | store(K=obB4I3RhZ.., |
       |                      +---.   V=#6.18([...], |
       |                      |    |  TTL=3600)      |
       |                      |<--'                  |
       |  200 OK              |                      |
       |  C-C: max-age=600,   |                      |
       |       s-maxage=3600  |                      |
       |  #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.  Client B operates a
     local cache, where it stores a copy of the response.









  Howard, et al.          Expires 3 September 2026               [Page 35]


  Internet-Draft                   CoSERV                       March 2026


     client B             cache.example          coserv.example
                              .---.                   .-.
        .-.                  |     |                 |   |
       |   |                 |'---'|                  '+'
       |'-'|                 |     |                   |
        '+'                   '-+-'                    |
         |   GET ogB4I3RhZ..    |                      |
         +--------------------->| lookup(obB4I3RhZ..)  |
         |                      +---.                  |
         |                      |    |                 |
         |                      |<--'                  |
         |                      | HIT                  |
         |  200 OK              |                      |
         |  C-C: max-age=480,   |                      |
         |       s-maxage=3480  |                      |
         |  Etag: "xyz"         |                      |
         |  #6.18([...])        |                      |
         |<---------------------+                      |
         |                      |                      |
         | store(K=obB4I3RhZ.., |                      |
         +---.   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 is 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 proxy returns
     a 304 (Not modified) status code, which instructs the client to reuse
     its local copy of the response.

















  Howard, et al.          Expires 3 September 2026               [Page 36]


  Internet-Draft                   CoSERV                       March 2026


     client B              cache.example          coserv.example
                              .---.                   .-.
        .-.                  |     |                 |   |
       |   |                 |'---'|                  '+'
       |'-'|                 |     |                   |
        '+'                   '-+-'                    |
         | lookup(obB4I3RhZ..)  |                      |
         +---.                  |                      |
         |    |                 |                      |
         |<--'                  |                      |
         | HIT (stale)          |                      |
         |                      |                      |
         | GET ogB4I3RhZ..      |                      |
         | If-None-Match:"xyz"  |                      |
         +--------------------->|                      |
         |                      +---.                  |
         |                      |    |                 |
         |                      |<--'                  |
         |                      | HIT                  |
         |  304 Not modified    |                      |
         |  C-C: max-age=0,     |                      |
         |       s-maxage=3060  |                      |
         |<---------------------+                      |
         |                      |                      |

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









  Howard, et al.          Expires 3 September 2026               [Page 37]


  Internet-Draft                   CoSERV                       March 2026


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

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

  8.  Security Considerations

     CoSERV implements a conveyance protocol for specific categories of
     Conceptual Message in [RFC9334], 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:



  Howard, et al.          Expires 3 September 2026               [Page 38]


  Internet-Draft                   CoSERV                       March 2026


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

  8.1.  In Relation to CoRIM

     CoSERV's data model inherits heavily from that of
     [I-D.ietf-rats-corim].  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 Section 11 of [I-D.ietf-rats-corim]
     therefore apply equally to CoSERV.

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

  8.3.  Aggregators

     Aggregation (see Section 2) 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.














  Howard, et al.          Expires 3 September 2026               [Page 39]


  Internet-Draft                   CoSERV                       March 2026


     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 an independent trust anchor.

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











  Howard, et al.          Expires 3 September 2026               [Page 40]


  Internet-Draft                   CoSERV                       March 2026


     *  *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 Section 4.6).

     *  *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 Section 2, with a greater reliance on collected
        artifacts rather than source artifacts.

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




  Howard, et al.          Expires 3 September 2026               [Page 41]


  Internet-Draft                   CoSERV                       March 2026


  9.1.  Aggregators

     Aggregators (as described in Section 2) 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.

  10.  IANA Considerations


     // RFC Editor: replace "RFCthis" with the RFC number assigned to this
     document.

  10.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 4 of  |
      |                       |                         | RFCthis       |
      +-----------------------+-------------------------+---------------+
      | coserv+cose           | application/coserv+cose | Section 4.6   |
      |                       |                         | of RFCthis    |
      +-----------------------+-------------------------+---------------+
      | coserv-discovery+cbor | application/coserv-     | Section 6.1.1 |
      |                       | discovery+cbor          | of RFCthis    |
      +-----------------------+-------------------------+---------------+
      | coserv-discovery+json | application/coserv-     | Section 6.1.1 |
      |                       | discovery+json          | of RFCthis    |
      +-----------------------+-------------------------+---------------+

                          Table 1: CoSERV Media Types

  10.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.)



  Howard, et al.          Expires 3 September 2026               [Page 42]


  Internet-Draft                   CoSERV                       March 2026


     Encoding considerations:  binary (CBOR)
     Security considerations:  Section 8 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

  10.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 8 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

  10.1.3.  application/coserv-discovery+cbor

     Type name:  application
     Subtype name:  coserv-discovery+cbor
     Required parameters:  n/a
     Optional parameters:  n/a
     Encoding considerations:  binary (CBOR)



  Howard, et al.          Expires 3 September 2026               [Page 43]


  Internet-Draft                   CoSERV                       March 2026


     Security considerations:  Section 8 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

  10.1.4.  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:  Section 8 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

  10.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]:






  Howard, et al.          Expires 3 September 2026               [Page 44]


  Internet-Draft                   CoSERV                       March 2026


     +=========================+================+======+=============+
     | Content-Type            | Content Coding | ID   | Reference   |
     +=========================+================+======+=============+
     | application/coserv+cbor | -              | TBD1 | Section 4   |
     |                         |                |      | of RFCthis  |
     +-------------------------+----------------+------+-------------+
     | application/coserv+cose | -              | TBD2 | Section 4.6 |
     |                         |                |      | of RFCthis  |
     +-------------------------+----------------+------+-------------+

                     Table 2: New CoAP Content Formats

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

  10.3.  Well-Known URI for CoSERV Configuration

     IANA is requested to register the following in the "Well-Known URIs"
     registry [IANA.well-known-uris]:

     URI suffix: coserv-configuration

     Change controller: IETF

     Specification document: RFCthis

     Related information: N/A

  11.  References

  11.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-09, 20
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-corim-09>.

     [I-D.ietf-rats-msg-wrap]
                Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
                D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
                in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
                11 December 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-msg-wrap-23>.







  Howard, et al.          Expires 3 September 2026               [Page 45]


  Internet-Draft                   CoSERV                       March 2026


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

     [IANA.well-known-uris]
                IANA, "Well-Known URIs",
                <https://www.iana.org/assignments/well-known-uris>.

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

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4648>.

     [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
                and D. Orchard, "URI Template", RFC 6570,
                DOI 10.17487/RFC6570, March 2012,
                <https://www.rfc-editor.org/rfc/rfc6570>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/rfc/rfc7515>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7517>.

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








  Howard, et al.          Expires 3 September 2026               [Page 46]


  Internet-Draft                   CoSERV                       March 2026


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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

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

     [SEMVER]   "Semantic Versioning 2.0.0", 2013,
                <https://semver.org/spec/v2.0.0.html>.

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

  11.2.  Informative References

     [I-D.ietf-iotops-mud-rats]
                Birkholz, H., Richardson, M., and P. C. Liu, "MUD-Based
                RATS Resources Discovery", Work in Progress, Internet-
                Draft, draft-ietf-iotops-mud-rats-02, 28 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-iotops-
                mud-rats-02>.

     [I-D.ietf-rats-endorsements]
                Thaler, D., Birkholz, H., and T. Fossati, "RATS
                Endorsements", Work in Progress, Internet-Draft, draft-
                ietf-rats-endorsements-09, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                endorsements-09>.

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




  Howard, et al.          Expires 3 September 2026               [Page 47]


  Internet-Draft                   CoSERV                       March 2026


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

     [RFC8007]  Murray, R. and B. Niven-Jenkins, "Content Delivery Network
                Interconnection (CDNI) Control Interface / Triggers",
                RFC 8007, DOI 10.17487/RFC8007, December 2016,
                <https://www.rfc-editor.org/rfc/rfc8007>.

     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
                DOI 10.17487/RFC9711, April 2025,
                <https://www.rfc-editor.org/rfc/rfc9711>.

     [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 CDDL

  A.1.  CoSERV Data Model

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     signed-coserv = #6.18([
         protected: bytes .cbor signed-coserv-protected-hdr,
         unprotected: signed-coserv-unprotected-hdr,
         payload: bytes .cbor coserv,
         signature: bytes,
     ])
     signed-coserv-protected-hdr = {
       1 => int,
       2 => "application/coserv+cbor" / 10000,
       * cose.label => cose.values,
     }
     signed-coserv-unprotected-hdr = {* cose.label => cose.values}
     cose.label = int / text



  Howard, et al.          Expires 3 September 2026               [Page 48]


  Internet-Draft                   CoSERV                       March 2026


     cose.values = any
     coserv = {
       &(profile: 0) => profile,
       &(query: 1) => query,
       ? &(results: 2) => results,
     }
     profile = comid.oid-type / ~uri
     query = {
       &(artifact-type: 0) => artifact-type,
       &(environment-selector: 1) => environment-selector-map,
       &(result-type: 2) => result-type,
     }
     artifact-type = &(endorsed-values: 0) / &(trust-anchors: 1) / &(\
                                                      reference-values: 2)
     result-type = &(collected-artifacts: 0) / &(source-artifacts: 1) / &\
                                                                 (both: 2)
     results = {
       result-set,
       &(expiry: 10) => tdate,
       ? &(source-artifacts: 11) => [+ cmw.cbor-record],
     }
     result-set //= (reference-values // endorsed-values // trust-anchors)
     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 = (



  Howard, et al.          Expires 3 September 2026               [Page 49]


  Internet-Draft                   CoSERV                       March 2026


       &(akq: 3) => [* ak-quad],
       &(tas: 4) => [* cots-stmt],
       )
     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<tn, fmt> = #6.<tn>(bytes .cbor fmt)
     cmw.tag-cm-data<tn> = #6.<tn>(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]*))*"



  Howard, et al.          Expires 3 September 2026               [Page 50]


  Internet-Draft                   CoSERV                       March 2026


     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],



  Howard, et al.          Expires 3 September 2026               [Page 51]


  Internet-Draft                   CoSERV                       March 2026


       &(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, $$comid-entity-map-extension>
     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



  Howard, et al.          Expires 3 September 2026               [Page 52]


  Internet-Draft                   CoSERV                       March 2026


     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<role-type-choice, extension-socket> = {
         &(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,



  Howard, et al.          Expires 3 September 2026               [Page 53]


  Internet-Draft                   CoSERV                       March 2026


       ? &(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,



  Howard, et al.          Expires 3 September 2026               [Page 54]


  Internet-Draft                   CoSERV                       March 2026


       ? &(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> = 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



  Howard, et al.          Expires 3 September 2026               [Page 55]


  Internet-Draft                   CoSERV                       March 2026


     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,



  Howard, et al.          Expires 3 September 2026               [Page 56]


  Internet-Draft                   CoSERV                       March 2026


       ? comid.version-scheme => comid.$version-scheme,
       ? comid.media => text,
       ? comid.software-meta => comid.one-or-more<comid.software-meta-\
                                                                   entry>,
       comid.entity => comid.one-or-more<comid.entity-entry>,
       ? comid.link => comid.one-or-more<comid.link-entry>,
       ? 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<text> / \
                                                   comid.one-or-more<int>)
     comid.one-or-more<T> = 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.$role>,
       ? 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,



  Howard, et al.          Expires 3 September 2026               [Page 57]


  Internet-Draft                   CoSERV                       March 2026


       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.directory-entry>,
       ? comid.file => comid.one-or-more<comid.file-entry>,
       )
     comid.resource-collection = (
       comid.path-elements-group,
       ? comid.process => comid.one-or-more<comid.process-entry>,
       ? comid.resource => comid.one-or-more<comid.resource-entry>,
       * $$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 = {



  Howard, et al.          Expires 3 September 2026               [Page 58]


  Internet-Draft                   CoSERV                       March 2026


       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



  Howard, et al.          Expires 3 September 2026               [Page 59]


  Internet-Draft                   CoSERV                       March 2026


     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



  Howard, et al.          Expires 3 September 2026               [Page 60]


  Internet-Draft                   CoSERV                       March 2026


     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

  A.2.  API Discovery Data Model

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     coserv-well-known-info = {
       version-label => version,
       capabilities-label => [+ capability],
       api-endpoints-label => {+ tstr => tstr},
       ? result-verification-key-label => eat.JC<jwk.JWK_Set, cose.\
                                                             COSE_KeySet>,
     }
     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> = M .and ([+ any])



  Howard, et al.          Expires 3 September 2026               [Page 61]


  Internet-Draft                   CoSERV                       March 2026


     artifact-support = non-empty-array<[
         ? "source",
         ? "collected",
     ]>
     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<tn, fmt> = #6.<tn>(bytes .cbor fmt)
     cmw.tag-cm-data<tn> = #6.<tn>(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          = "!" / "#" / "$" / "%" / "&" / "\'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"



  Howard, et al.          Expires 3 September 2026               [Page 62]


  Internet-Draft                   CoSERV                       March 2026


                    / 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,



  Howard, et al.          Expires 3 September 2026               [Page 63]


  Internet-Draft                   CoSERV                       March 2026


       ? "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<J, C> = eat.JSON-ONLY<J> / eat.CBOR-ONLY<C>
     eat.JSON-ONLY<J> = J .feature "json"
     eat.CBOR-ONLY<C> = 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

  Appendix B.  OpenAPI Schema

     The OpenAPI schema for the request/response HTTP API described in
     Section 6.1 is provided below.

  openapi: '3.0.0'

  info:
    title: CoSERV HTTP API Binding
    description: CoSERV HTTP API Binding, including request-response and discovery
    version: '1.0.0alpha'
  paths:
    /coserv/{query}:
      get:
        summary: Query the CoSERV endpoint.
        parameters:
          - in: path
            name: query
            schema:
              type: string



  Howard, et al.          Expires 3 September 2026               [Page 64]


  Internet-Draft                   CoSERV                       March 2026


              format: base64url
            required: true
            description: base64url-encoded CoSERV query
        responses:
          '200':
            description: >
              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:



  Howard, et al.          Expires 3 September 2026               [Page 65]


  Internet-Draft                   CoSERV                       March 2026


                  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.

  Appendix C.  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 Section 2), 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 URL of a suitable service is known, CoSERV provides in-
     protocol discovery mechanisms, such as the one described in
     Section 6.1.1, 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 URL 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 [I-D.ietf-iotops-mud-rats].






  Howard, et al.          Expires 3 September 2026               [Page 66]


  Internet-Draft                   CoSERV                       March 2026


  Acknowledgments

     The participants in the "Staircase meeting" at FOSDEM '25:

   @@@@#=+++==+=+++++==+++++++++=========-========================-=======
   @@@@@@@@#+*++++=+++****#########+====================================-=
   *+@@@@@@%@%@%=***#*########%#####*++===============================-===
   %%%%%@@%#@*@@@%%%%##%%%####%%###%#%++++=+=+================--==========
   %%%%%%@@@%#%@%@@%###%#%#%%%#%%%#%%####===%%%+==================-=======
   %%%%%%%@%%##%%%%%####%++=+=++++*%*=#+*++++++%#=== Mathias Brossard ====
   %%%@%%%%%%%%%%%@%%####*##**#***+%%#**=*==*==*%================-========
   %%%%%%@%%%%%%%%%#@###**+==%**%###%#+*+++=*+=*%=========================
   %%%%%%%%%%%#%%%#*%###%###@#**%##%@#*%#++=+*#*=======================-==
   @@@@@@@@%@@@#%#%%####%##%%%**###**%#+++++++++++======================--
   %%@@@@@@@@%%#%%#%#==+%##%+%+=**##*%#%@@%%%***+==============-===-===-=:
   %-*@%@%%%%#%%%##%==--#**##+*@@%%#*#@@@%%%%%%@%##%%==----======----=---:
   %%%@@%#**%%%%%##%---#%@@%%%##**@@@%%%%%%%%@@#***%%=...-== Thomas ==-::+
   =###%@@%%%%%%#*+===%#%%##%*#@@@@%%%%%%%%@@%%*+*+#=..:==== Fossati =-:**
   +**+#%@@@@@@@@@@@@####*+++*@@@@@%%%@%%%%%#@%=+=--.:====================
   +++**+%%@@@@@@%%%%%%%@@+#++#@@%@%%%@%%%%%@#+=-:.:==++++++++++++++++++++
   +=++*#%#%@@%%%%%%#%**@+#+-+-%#%*%%%###%%%%#%%++++********++++++++++++++
   ++++**###=*@%%%%%%%++%*%+*==%##*#%+###@@@@%%%#===++++* Yogesh ++ ++++++
   ++=+++#**+=@*@@@@%#++#==+=+-%##**#*=+@@@@@%%#*----===+ Deshpande =+=+==
   ==+**+###++%++**@%*++#====+*##*****@%@#%%##%%*-==========+++++===+=++++
   *+++++###++%=++*%#**+%===*++##***++@@%#%@%%%@%###-:::===++=---=-----:==
   %++=-=%###+#====****=#===+=*=##*+%*@@%%%%%%@@%*=++#--===*==+=-+==+=-+++
   %==----###=%===++*++=%*=+=***@#+***@%%*@%%%##%*##*%%@+=+==+++++++++++++
   #*++----##=@*=+=**+*=*++#+=%%#*##%#*+@%@@%%%%%**%@%@@+#+**#*#####***#*+
   +*+++@**+#%=%=+++++*=#++#%#+*****##*+@+++%%%%%#@@@@@@=-====-----+**++++
   +*+*=%%#**#%=%@%=#++=%+***++*********%%%@%%#-==*+===++===++++++++++++++
   #+**++%@%**#%@@%+#+*+%++=+=+*##*****%%%##%==-==**-+====-----:---::::--=
   %%***+#%@%**%%=#*#+++%=====+*****#*+*@@+====-==%#*+-.-..-==:==.-.:::...
   ##**++=@%%#*#%%++#**=%-====+%%+###+++%#=====-+=%%##**+------===::=---::
   #***++=+%%%#*%%==#+-+---==+*%%#@@%%++##=====-==%%%%=*++== Paul =:---===
   ##***+===%%@##@#%#*#=----===+++=+##*+##=====-==%%%%=*=-.. Howard .:-===
   ##***++==%%%%+**#%%#++-#%====+++%*++==#=====-==%%%%%%+--.:.-::--+=--+=+
   ##***+=+=%@%%##%##+######=++*=%=---*=+*=====--+%%%%%%+#--:.:--+**#*####
   ****+++==+%%@@%%%#%*########-%%=-====+*=-===-=+%%%%%%+++++++++*********
   *+****++=##%%@@@%%#%+###%###%#@#+=+++==--===-=+%%%%%#+=+++--..====----=
   ++**+=#++#%%@+#@@@#%%####*#*##@*##%#*++=======+------++=++=--.-----=---
   *%++*=+*+%#@#*@*%%#%%*###%#####+##%%=--+======+==:---+=--- Thore -===--
   *++##**%=:==-#*+%#%=-=%%#%#%#%%##%*-=====-=--====--*-+-=== Sommer --=-=
   -++*=%%*=%++-:#+=:*:####%#%%#%%**++=-==+---*-=*==--**+-===============+
   -%#=%%%%%%@%%*%%##*%%%%%%%%%*@#%#++==---------=*+###++========+++++++++
   -%@=*%%@%#%%@#@%%%%%%#@++++++@%%@#%%%%%%%---=====++++++++++++++++++++++
   -%@=++*#@%#%*@++*#%%%*%*#*##@%+:%##+@@%%#%%#==========+++++++++++++++++
   =%%=*==+%###+@%@%%@@%%%%####****+%#%%%%@%*###=:-========++++++++=++++++
   ==@==-+*##**+#%%%%#%##**###******++*%#%%##%*%#--===========++++++++++++



  Howard, et al.          Expires 3 September 2026               [Page 67]


  Internet-Draft                   CoSERV                       March 2026


   =-%=+*+-%#**-%@%%%@##**#*******+***%%%%##*%%%%-==++##===== Hannes +++++
   +=@+*++++%**=%*+++%##+=@%%@%@@%*@%%%%%%+###+*==+=---%#==== Tschofenig +
   +=@=++++*%**+%@+*=%###=-=-=-###%%@%%%#%*%#%%+==--+==%#====+=+++++++++++
   *=%%==*+*#**=%@+#@@#==+=%*-----=%%#%%%%##%#%%%@=-+*%*++++++++++++++++++
   #*@#+*+++#**=*=++-=+=+*#%%%%%%=-+%%%@@@%##%%%@#=+=+++++++++++++++++++++
   ****:::::-:::.=*++.=+**#######%%####%####*%%#%%%+++++++++++++++++++++++
   *****:-::---==%+++=###+%********%%####%####@%##%%+++++++++++***********
   #***##+++%#*++%++=+##*=%++#@@@@@%%%#%#####*%%##%%@*+++++++*************
   #####+++*@%#+*@++*+%##+%++===+++++++++==========-=***+*****************
   %%%#+***++@%@*@++*%%%%*#+===========================%%+================
   %===++*++#***#@**%%%#%#+==========================%%%==================
   ######*****###*##*##===========================%%%#====================
   #######****##*#*##**=====+++=++-----=======++%%#+======================
   #########**#***##*#*#=+=======-:::::--====@%##-========================
   ######*=####**=#####*++++++++=-------+++@%##--=============------------
   %%######@@@@@@@%++++=%====%+==----=++%%%#==---=========================
   %%%%#%%###@@=**=++=------==#----+++%%%#+====-======================+===
   ======+##=%@++**=#-:--::---+-+++%%%#===== Ionut Mihalcea ==============
   ---------=+=*++%#*+=-=::---*++%%%#==================================+==
   ------------==%==-:::=*=*##%%%%#======*================================
   ===========-=##------+%%@%%%#+====================== =  /` _____ `\;,
   ###############*+*****@%%%#+========================   /__(^===^)__\';,
   *############++++++#%%%#++==========++==============     /  :::  \   ,;
   +++****##*#++=+++@%%%#+==== The Staircase ==========    |   :::   | ,;'
   ++++++++======++@#%#================================    '._______.'`
   ++++++++====++@#%#===================================  Dionna Glaze ===

     Henk Birkholz and Jag Raman are puppeteering in the shadows.

     The authors would like to thank Carl Wallace for their reviews and
     suggestions.

  Authors' Addresses

     Paul Howard
     Arm
     Email: paul.howard@arm.com


     Thomas Fossati
     Linaro
     Email: Thomas.Fossati@linaro.org


     Henk Birkholz
     Fraunhofer SIT
     Email: henk.birkholz@ietf.contact




  Howard, et al.          Expires 3 September 2026               [Page 68]


  Internet-Draft                   CoSERV                       March 2026


     Shefali Kamal
     Fujitsu
     Email: Shefali.Kamal@fujitsu.com


     Giridhar Mandyam
     AMD
     Email: gmandyam@amd.com


     Ding Ma
     Alibaba Cloud
     Email: xynnn@linux.alibaba.com






































  Howard, et al.          Expires 3 September 2026               [Page 69]


