# drafts

name: draft-ietf-drip-auth
rev: 49
title: DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID
time: 2024-06-26T18:53:10Z
group_uri: /api/v1/group/group/2266/
expires: 2024-08-24T22:38:49Z
ad: /api/v1/person/person/105099/
shepherd: /api/v1/person/email/mohamed.boucadair@orange.com/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.226496+00:00
source: ietf
source_id: 100101
source_url: https://datatracker.ietf.org/doc/draft-ietf-drip-auth/
doc_status: active
abstract:
  The Drone Remote Identification Protocol (DRIP), plus trust policies
     and periodic access to registries, augments Unmanned Aircraft System
     (UAS) Remote Identification (RID), enabling local real time
     assessment of trustworthiness of received RID messages and observed
     UAS, even by Observers lacking Internet access.  This document
     defines DRIP message types and formats to be sent in Broadcast RID
     Authentication Messages to verify that attached and recent detached
     messages were signed by the registered owner of the DRIP Entity Tag
     (DET) claimed.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  DRIP Working Group                                  A. Wiethuechter, Ed.
  Internet-Draft                                                   S. Card
  Intended status: Standards Track                      AX Enterprize, LLC
  Expires: 24 August 2024                                     R. Moskowitz
                                                            HTT Consulting
                                                          21 February 2024


  DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote
                                     ID
                          draft-ietf-drip-auth-49

  Abstract

     The Drone Remote Identification Protocol (DRIP), plus trust policies
     and periodic access to registries, augments Unmanned Aircraft System
     (UAS) Remote Identification (RID), enabling local real time
     assessment of trustworthiness of received RID messages and observed
     UAS, even by Observers lacking Internet access.  This document
     defines DRIP message types and formats to be sent in Broadcast RID
     Authentication Messages to verify that attached and recent detached
     messages were signed by the registered owner of the DRIP Entity Tag
     (DET) claimed.

  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 24 August 2024.

  Copyright Notice

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






  Wiethuechter, et al.     Expires 24 August 2024                 [Page 1]


  Internet-Draft              DRIP Auth Formats              February 2024


     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.  DRIP Entity Tag (DET) Authentication Goals for Broadcast
             RID . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Required Terminology  . . . . . . . . . . . . . . . . . .   5
       2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  UAS RID Authentication Background & Procedures  . . . . . . .   5
       3.1.  DRIP Authentication Protocol Description  . . . . . . . .   6
         3.1.1.  Usage of DNS  . . . . . . . . . . . . . . . . . . . .   6
         3.1.2.  Providing UAS RID Trust . . . . . . . . . . . . . . .   7
       3.2.  ASTM Authentication Message Framing . . . . . . . . . . .   8
         3.2.1.  Authentication Page . . . . . . . . . . . . . . . . .   8
         3.2.2.  Authentication Payload Field  . . . . . . . . . . . .   9
         3.2.3.  Specific Authentication Method (SAM)  . . . . . . . .  10
         3.2.4.  ASTM Broadcast RID Constraints  . . . . . . . . . . .  11
     4.  DRIP Authentication Formats . . . . . . . . . . . . . . . . .  13
       4.1.  UA Signed Evidence Structure  . . . . . . . . . . . . . .  13
       4.2.  DRIP Link . . . . . . . . . . . . . . . . . . . . . . . .  15
       4.3.  DRIP Wrapper  . . . . . . . . . . . . . . . . . . . . . .  17
         4.3.1.  Wrapped Count & Format Validation . . . . . . . . . .  18
         4.3.2.  Wrapper over Extended Transports  . . . . . . . . . .  18
         4.3.3.  Wrapper Limitations . . . . . . . . . . . . . . . . .  20
       4.4.  DRIP Manifest . . . . . . . . . . . . . . . . . . . . . .  20
         4.4.1.  Hash Count & Format Validation  . . . . . . . . . . .  21
         4.4.2.  Manifest Ledger Hashes  . . . . . . . . . . . . . . .  22
         4.4.3.  Hash Algorithms and Operation . . . . . . . . . . . .  22
       4.5.  DRIP Frame  . . . . . . . . . . . . . . . . . . . . . . .  23
     5.  Forward Error Correction  . . . . . . . . . . . . . . . . . .  24
       5.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  25
       5.2.  Decoding  . . . . . . . . . . . . . . . . . . . . . . . .  26
       5.3.  FEC Limitations . . . . . . . . . . . . . . . . . . . . .  29
     6.  Requirements & Recommendations  . . . . . . . . . . . . . . .  29
       6.1.  Legacy Transports . . . . . . . . . . . . . . . . . . . .  29
       6.2.  Extended Transports . . . . . . . . . . . . . . . . . . .  29
       6.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .  29
       6.4.  Operational . . . . . . . . . . . . . . . . . . . . . . .  30
         6.4.1.  DRIP Wrapper  . . . . . . . . . . . . . . . . . . . .  31



  Wiethuechter, et al.     Expires 24 August 2024                 [Page 2]


  Internet-Draft              DRIP Auth Formats              February 2024


         6.4.2.  UAS RID Trust Assessment  . . . . . . . . . . . . . .  31
     7.  Summary of Addressed DRIP Requirements  . . . . . . . . . . .  31
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
       8.1.  IANA DRIP Registry  . . . . . . . . . . . . . . . . . . .  32
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
       9.1.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  33
       9.2.  Wrapper vs Manifest . . . . . . . . . . . . . . . . . . .  34
       9.3.  VNA Timestamp Offsets for DRIP Authentication Formats . .  35
       9.4.  DNS Security in DRIP  . . . . . . . . . . . . . . . . . .  36
     10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  36
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  37
       11.2.  Informative References . . . . . . . . . . . . . . . . .  38
     Appendix A.  Authentication States  . . . . . . . . . . . . . . .  38
       A.1.  None: Black . . . . . . . . . . . . . . . . . . . . . . .  40
       A.2.  Partial: Gray . . . . . . . . . . . . . . . . . . . . . .  40
       A.3.  Unsupported: Brown  . . . . . . . . . . . . . . . . . . .  41
       A.4.  Unverifiable: Yellow  . . . . . . . . . . . . . . . . . .  41
       A.5.  Verified: Green . . . . . . . . . . . . . . . . . . . . .  41
       A.6.  Trusted: Blue . . . . . . . . . . . . . . . . . . . . . .  41
       A.7.  Questionable: Orange  . . . . . . . . . . . . . . . . . .  41
       A.8.  Unverified: Red . . . . . . . . . . . . . . . . . . . . .  42
       A.9.  Conflicting: Purple . . . . . . . . . . . . . . . . . . .  42
     Appendix B.  Operational Recommendation Analysis  . . . . . . . .  42
       B.1.  Page Counts vs Frame Counts . . . . . . . . . . . . . . .  42
         B.1.1.  Special Cases . . . . . . . . . . . . . . . . . . . .  44
       B.2.  Full Authentication Example . . . . . . . . . . . . . . .  44
         B.2.1.  Raw Example . . . . . . . . . . . . . . . . . . . . .  46
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

  1.  Introduction

     The initial regulations (e.g., [FAA-14CFR]) and standards (e.g.,
     [F3411]) for Unmanned Aircraft (UA) Systems (UAS) Remote
     Identification and tracking (RID) do not address trust.  However,
     this is a requirement that needs to be addressed for various
     different parties that have a stake in the safe operation of National
     Airspace Systems (NAS).  Drone Remote ID Protocol's (DRIP's) goal is
     to specify how RID can be made trustworthy and available in both
     Internet and local-only connected scenarios, especially in emergency
     situations.










  Wiethuechter, et al.     Expires 24 August 2024                 [Page 3]


  Internet-Draft              DRIP Auth Formats              February 2024


     UAS often operate in a volatile environment.  Small UA offer little
     capacity for computation and communication.  UAS RID must also be
     accessible with ubiquitous and inexpensive devices without
     modification.  This limits options.  Most current small UAS are IoT
     devices even if not typically thought of as such.  Thus many IoT
     considerations apply here.  Some DRIP work, currently strongly scoped
     to UAS RID, is likely to be applicable to some other IoT use-cases.

     Generally, two communication schemes for UAS RID are considered:
     Broadcast and Network.  This document focuses on adding trust to
     Broadcast RID (Section 3.2 of [RFC9153] and Section 1.2.2 of
     [RFC9434]).  As defined in [F3411] and outlined in [RFC9153] and
     [RFC9434], Broadcast RID is a one-way RF transmission of MAC layer
     messages over Bluetooth or Wi-Fi.

     Senders can make any claims the RID message formats allow.  Observers
     have no standardized means to assess the trustworthiness of message
     content, nor verify whether the messages were sent by the UA
     identified therein, nor confirm that the UA identified therein is the
     one they are visually observing.  Indeed, Observers have no way to
     detect whether the messages were sent by a UA, or spoofed by some
     other transmitter (e.g., a laptop or smartphone) anywhere in direct
     wireless broadcast range.  Authentication is the primary strategy for
     mitigating this issue.

  1.1.  DRIP Entity Tag (DET) Authentication Goals for Broadcast RID

     ASTM [F3411] Authentication Messages (Message Type 0x2), when used
     with DRIP Entity Tag (DET) [RFC9374] based formats, enable a high
     level of trust that the content of other ASTM Messages was generated
     by their claimed registered source.  These messages are designed to
     provide the Observers with trustworthy and immediately actionable
     information.  Appendix A provides a high-level overview of the
     various states of trustworthiness that may be used along with these
     formats.

     This authentication approach also provides some error correction
     (Section 5) as mandated by the United States (US) Federal Aviation
     Administration (FAA) [FAA-14CFR], which is missing from [F3411] over
     Legacy Transports (Bluetooth 4.x).

     These DRIP enhancements to ASTM's [F3411] further support the
     important use case of Observers who may be offline at the time of
     observation.

     A summary of DRIP requirements [RFC9153] addressed herein is provided
     in Section 7.




  Wiethuechter, et al.     Expires 24 August 2024                 [Page 4]


  Internet-Draft              DRIP Auth Formats              February 2024


        Note: The Endorsement (used in Section 4.2) that proves that a DET
        is registered MUST come from its immediate parent in the
        registration hierarchy, e.g., a DRIP Identity Management Entity
        (DIME) [drip-registries].  In the definitive hierarchy, the parent
        of the UA is its HHIT Domain Authority (HDA), the parent of an HDA
        is its Registered Assigning Authority (RAA), etc.  It is also
        assumed that all DRIP-aware entities use a DET as their identifier
        during interactions with other DRIP-aware entities.

  2.  Terminology

  2.1.  Required 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.2.  Definitions

     This document makes use of the terms (CAA, Observer, USS, UTM, etc.)
     defined in [RFC9153].  Other terms (such as DIME) are from [RFC9434],
     while others (HI, DET, RAA, HDA, etc.) are from [RFC9374].

     In addition, the following terms are defined for this document:

     Extended Transports:

        Use of extended advertisements (Bluetooth 5.x), service info (Wi-
        Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons
        with vendor specific information element as specified in [F3411].
        Must use ASTM Message Pack (Message Type 0xF).

     Legacy Transports:

        Use of broadcast frames (Bluetooth 4.x) as specified in [F3411].

     Manifest:

        an immutable list of items being transported (in this specific
        case over wireless communication).

  3.  UAS RID Authentication Background & Procedures







  Wiethuechter, et al.     Expires 24 August 2024                 [Page 5]


  Internet-Draft              DRIP Auth Formats              February 2024


  3.1.  DRIP Authentication Protocol Description

     [F3411] defines Authentication Message framing only.  It does not
     define authentication formats or methods.  It explicitly anticipates
     several signature options but does not fully define those.  Annex A1
     of [F3411] defines a Broadcast Authentication Verifier Service, which
     has a heavy reliance on Observer real-time connectivity to the
     Internet.  Fortunately, [F3411] also allows third party standard
     Authentication Types using Type 5 Specific Authentication Method
     (SAM), several of which DRIP defines herein.

     The standardization of specific formats to support the DRIP
     requirements in UAS RID for trustworthy communications over Broadcast
     RID is an important part of the chain of trust for a UAS ID.  Per
     Section 5 of [RFC9434], Authentication formats are needed to relay
     information for Observers to determine trust.  No existing formats
     (defined in [F3411] or other organizations leveraging this feature)
     provide the functionality to satisfy this goal resulting in the work
     reflected in this document.

  3.1.1.  Usage of DNS

     Like most aviation matters, the overall objectives here are security
     and ultimately safety oriented.  Since DRIP depends on DNS for some
     of its functions, DRIP usage of DNS needs to be protected as per best
     security practices.  Many participating nodes will have limited local
     processing power and/or poor, low bandwidth QoS paths.  Appropriate
     and feasible security techniques will be highly UAS and Observer
     situation dependent.  Therefore specification of particular DNS
     security options, transports, etc. is outside the scope of this
     document (see also Section 9.4).

     In DRIP Observers MUST validate all signatures received.  This
     requires the Host Identity (HI) corresponding to a DET [RFC9374].
     HI's MAY be retrieved from a local cache, if present.  The local
     cache is pre-configured with well knowns HIs (such as those of CAA
     DIMEs) and further populated by received Broadcast Endorsements (BEs)
     (Section 3.1.2.1) and DNS lookups (when available).

     The Observer MUST perform a DNS query, when connectivity allows, to
     obtain an HI not previously known.  If a query can not be performed,
     the message SHOULD be cached by the Observer to be validated once the
     HI is obtained.

     A more comprehensive specification of DRIP's use of DNS is out of
     scope for this document and can be found in [drip-registries].





  Wiethuechter, et al.     Expires 24 August 2024                 [Page 6]


  Internet-Draft              DRIP Auth Formats              February 2024


  3.1.2.  Providing UAS RID Trust

     For DRIP, two actions together provide a mechanism for an Observer to
     trust in UAS RID using Authentication Messages.

     First is the transmission of an entire trust chain via Broadcast
     Endorsements (Section 3.1.2.1).  This provides a hierarchy of DIMEs
     down to and including an individual UA's registration of a claimed
     DET and corresponding HI (public key).  This alone cannot be trusted
     as having any relevance to the observed UA because replay attacks are
     trivial.

     After an Observer has gathered such a complete key trust chain (from
     pre-configured cache entries, Broadcast Endorsements received over
     the air and/or DNS lookups) and verified all of its links, that
     device can trust that claimed DET and corresponding public key are
     properly registered, but the UA has not yet been proven to possess
     the corresponding private key.

     It is necessary for the UA to prove possession by dynamically signing
     data that is unique and unpredictable but easily verified by the
     Observer (Section 3.1.2.2).  Verification of this signed data MUST be
     performed by the Observer as part of the received UAS RID information
     trust assessment (Section 6.4.2).

  3.1.2.1.  DIME Endorsements of Subordinate DETs

     Observers receive DRIP Link Authentication Messages (Section 4.2)
     containing Broadcast Endorsements by DIMEs of child DET
     registrations.  A series of these Endorsements confirms a path
     through the hierarchy, defined in [drip-registries], from the DET
     Prefix Owner all the way to an individual UA DET registration.

        Note: For the remainder of this document Broadcast Endorsement:
        Parent, Child will be abbreviated to BE: Parent, Child.  For
        example Broadcast Endorsement: RAA, HDA will be abbreviated to BE:
        RAA, HDA.

  3.1.2.2.  UA Signed Evidence

     To prove possession of the private key associated to the DET, the UA
     MUST send data that is unique and unpredictable but easily validated
     by the Observer, that is signed over.  The data can be an ASTM
     Message that fulfills the requirements to be unpredictable but easily
     validated.  An Observer receives this UA-signed Evidence from DRIP-
     based Authentication Messages (Section 4.3 or Section 4.4).





  Wiethuechter, et al.     Expires 24 August 2024                 [Page 7]


  Internet-Draft              DRIP Auth Formats              February 2024


     Whether the content is true is a separate question which DRIP cannot
     address, but validation performed using observable and/or out of band
     data (Section 6) are possible and encouraged.

  3.2.  ASTM Authentication Message Framing

     The Authentication Message (Message Type 0x2) is unique in the ASTM
     [F3411] Broadcast standard as it is the only message that can be
     larger than the Legacy Transport size.  To address this limitation
     around transport size, it is defined as a set of "pages", each of
     which fits into a single Legacy Transport frame.  For Extended
     Transports, pages are still used but all are in a single frame.

        Informational Note: Message Pack (Message Type 0xF) is also larger
        than the Legacy Transport size but is limited for use only on
        Extended Transports where is can be supported.

     The following sub-sections are a brief overview of the Authentication
     Message format defined in [F3411] for better context on how DRIP
     Authentication fills and uses various fields already defined by ASTM
     [F3411].

  3.2.1.  Authentication Page

     This document leverages Authentication Type 0x5, Specific
     Authentication Method (SAM), as the principal authentication
     container, defining a set of SAM Types in Section 4.  Authentication
     Type is encoded in every Authentication Page in the Page Header.  The
     SAM Type is defined as a field in the Authentication Payload (see
     Section 3.2.3.1).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |  Page Header  |                                               |
       +---------------+                                               |
       |                                                               |
       |                                                               |
       |                     Authentication Payload                    |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+

              Figure 1: Standard ASTM Authentication Message Page

     Page Header: (1 octet)

        Authentication Type (4 bits) and Page Number (4 bits)



  Wiethuechter, et al.     Expires 24 August 2024                 [Page 8]


  Internet-Draft              DRIP Auth Formats              February 2024


     Authentication Payload: (23 octets per page)

        Authentication Payload, including headers.  Null padded.  See
        Section 3.2.2.

     The Authentication Message is structured as a set of pages per
     Figure 1.  There is a technical maximum of 16 pages (indexed 0 to 15)
     that can be sent for a single Authentication Message, with each page
     carrying a maximum 23 octet Authentication Payload.  See
     Section 3.2.4 for more details.  Over Legacy Transports, these
     messages are "fragmented", with each page sent in a separate Legacy
     Transport frame.

     Either as a single Authentication Message or a set of fragmented
     Authentication Message Pages, the structure is further wrapped by
     outer ASTM framing and the specific link framing.

  3.2.2.  Authentication Payload Field

     Figure 2 is the source data view of the data fields found in the
     Authentication Message as defined by [F3411].  This data is placed
     into Figure 1's Authentication Payload, spanning multiple
     Authentication Pages.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |                     Authentication Headers                    |
       |                               +---------------+---------------+
       |                               |                               |
       +---------------+---------------+                               |
       .                                                               .
       .                Authentication Data / Signature                .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |      ADL      |                                               |
       +---------------+                                               |
       .                                                               .
       .                       Additional Data                         .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+

                  Figure 2: ASTM Authentication Message Fields

     Authentication Headers: (6 octets)




  Wiethuechter, et al.     Expires 24 August 2024                 [Page 9]


  Internet-Draft              DRIP Auth Formats              February 2024


        As defined in [F3411].

     Authentication Data / Signature: (0 to 255 octets)

        Opaque authentication data.  The length of this payload is known
        through a field in the Authentication Headers (defined in
        [F3411]).

     Additional Data Length (ADL): (1 octet - unsigned)

        Length in octets of Additional Data.  The value of ADL is
        calculated as the minimum of 361 - Authentication Data / Signature
        Length and 255.  Only present with Additional Data.

     Additional Data: (ADL octets)

        Data that follows the Authentication Data / Signature but is not
        considered part of the Authentication Data thus is not covered by
        a signature.  For DRIP, this field is used to carry Forward Error
        Correction (FEC) generated by transmitters and parsed by receivers
        as defined in Section 5.

  3.2.3.  Specific Authentication Method (SAM)

  3.2.3.1.  SAM Data Format

     Figure 3 is the general format to hold authentication data when using
     SAM and is placed inside the Authentication Data/Signature field in
     Figure 2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |   SAM Type    |                                               |
       +---------------+                                               |
       .                                                               .
       .                     SAM Authentication Data                   .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+

                           Figure 3: SAM Data Format

     SAM Type: (1 octet)

        The following SAM Types are allocated to DRIP:





  Wiethuechter, et al.     Expires 24 August 2024                [Page 10]


  Internet-Draft              DRIP Auth Formats              February 2024


                  +==========+=============================+
                  | SAM Type | Description                 |
                  +==========+=============================+
                  | 0x01     | DRIP Link (Section 4.2)     |
                  +----------+-----------------------------+
                  | 0x02     | DRIP Wrapper (Section 4.3)  |
                  +----------+-----------------------------+
                  | 0x03     | DRIP Manifest (Section 4.4) |
                  +----------+-----------------------------+
                  | 0x04     | DRIP Frame (Section 4.5)    |
                  +----------+-----------------------------+

                           Table 1: DRIP SAM Types

        Note: ASTM International is the owner of these code points as they
        are defined in [F3411].  In accordance with Annex 5 of the ASTM's
        [F3411], the International Civil Aviation Organization (ICAO) has
        been selected by ASTM as the registrar to manage allocations of
        these code points.  The list of which can be found at
        [ASTM-Remote-ID].

     SAM Authentication Data: (0 to 200 octets)

        Contains opaque authentication data formatted as defined by the
        preceding SAM Type.

  3.2.4.  ASTM Broadcast RID Constraints

  3.2.4.1.  Wireless Frame Constraints

     A UA has the option of broadcasting using Bluetooth (4.x and 5.x),
     Wi-Fi NAN, or IEEE 802.11 Beacon, see Section 6.  With Bluetooth, FAA
     and other Civil Aviation Authorities (CAA) mandate transmitting
     simultaneously over both 4.x and 5.x.  The same application layer
     information defined in [F3411] MUST be transmitted over all the
     physical layer interfaces performing the function of RID.  This is
     because Observer transports may be limited.  If an Observer can
     support multiple transports it should be assumed to use the latest
     data regardless of the transport received over.

     Bluetooth 4.x presents a payload size challenge in that it can only
     transmit 25 octets of payload per frame while other transports can
     support larger payloads per frame.  However, the [F3411] messaging
     framing dictated by Bluetooth 4.x constraints is inherited by [F3411]
     over other media.






  Wiethuechter, et al.     Expires 24 August 2024                [Page 11]


  Internet-Draft              DRIP Auth Formats              February 2024


     It should be noted that Extended Transports by definition have Error
     Correction built in, unlike Legacy Transports.  For Authentication
     Messages this means that over Legacy Transport pages could be not
     received by Observers resulting in incomplete messages during
     operation, although the use of DRIP FEC (Section 5) reduces the
     likelihood of this.  Authentication Messages sent using Extended
     Transports do not suffer this issue as the full message (all pages)
     are sent using a single Message Pack.  Furthermore the use of one-way
     RF broadcasts prohibits the use of any congestion control or loss
     recovery schemes that require ACKs or NACKs.

  3.2.4.2.  Paged Authentication Message Constraints

     To keep consistent formatting across the different transports (Legacy
     and Extended) and their independent restrictions, the authentication
     data being sent is REQUIRED to fit within the page limit that the
     most constrained existing transport can support.  Under Broadcast
     RID, the Extended Transport that can hold the least amount of
     authentication data is Bluetooth 5.x at 9 pages.

     As such DRIP transmitters are REQUIRED to adhere to the following
     when using the Authentication Message:

     1.  Authentication Data / Signature data MUST fit in the first 9
         pages (Page Numbers 0 through 8).

     2.  The Length field in the Authentication Headers (which encodes the
         length in octets of Authentication Data / Signature only) MUST
         NOT exceed the value of 201.  This includes the SAM Type but
         excludes Additional Data.

  3.2.4.3.  Timestamps

     In ASTM [F3411] timestamps are a Unix-style timestamp with an epoch
     of 2019-01-01 00:00:00 UTC.  For DRIP this format is adopted for
     Authentication to keep a common time format in Broadcast payloads.

     Under DRIP there are two timestamps defined Valid Not Before (VNB)
     and Valid Not After (VNA).

     Valid Not Before (VNB) Timestamp: (4 octets)

        Timestamp denoting recommended time to start trusting data in.
        MUST follow the format defined in [F3411] as described above.
        MUST be set no earlier than the time the signature (across a given
        structure) is generated.

     Valid Not After (VNA) Timestamp: (4 octets)



  Wiethuechter, et al.     Expires 24 August 2024                [Page 12]


  Internet-Draft              DRIP Auth Formats              February 2024


        Timestamp denoting recommended time to stop trusting data.  MUST
        follow the format defined in [F3411] as described above.  Has an
        additional offset to push a short time into the future (relative
        to VNB) to avoid replay attacks.  The exact offset is not defined
        in this document.  Best practice identifying an acceptable offset
        should be used taking into consideration the UA environment, and
        propagation characteristics of the messages being sent, and clock
        differences between the UA and Observers.  A reasonable time would
        be to set VNA 2 minutes after VNB.

  4.  DRIP Authentication Formats

     All formats defined in this section are the content of the
     Authentication Data / Signature field in Figure 2 and use the
     Specific Authentication Method (SAM, Authentication Type 0x5).  The
     first octet of the Authentication Data / Signature of Figure 2 is
     used to multiplex among these various formats.

     When sending data over a medium that does not have underlying FEC,
     for example Legacy Transports, then Section 5 MUST be used.

     Examples of Link, Wrapper and Manifest are shown as part of an
     operational schedule in Appendix B.2.1.

  4.1.  UA Signed Evidence Structure

     The UA Signed Evidence Structure (Figure 4) is used by the UA during
     flight to sign over information elements using the private key
     associated with the current UA DET.  It is encapsulated by the SAM
     Authentication Data field of Figure 3.

     This structure is used by the DRIP Wrapper (Section 4.3), Manifest
     Section 4.4, and Frame (Section 4.5).  DRIP Link (Section 4.2) MUST
     NOT use it as it will not fit in the ASTM Authentication Message with
     its intended content (i.e., a Broadcast Endorsement).
















  Wiethuechter, et al.     Expires 24 August 2024                [Page 13]


  Internet-Draft              DRIP Auth Formats              February 2024


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |                      VNB Timestamp by UA                      |
       +---------------+---------------+---------------+---------------+
       |                      VNA Timestamp by UA                      |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       .                                                               .
       .                            Evidence                           .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                              UA                               |
       |                        DRIP Entity Tag                        |
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                          UA Signature                         |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+

             Figure 4: Endorsement Structure for UA Signed Evidence

     Valid Not Before (VNB) Timestamp by UA: (4 octets)

        See Section 3.2.4.3.  Set by the UA.

     Valid Not After (VNA) Timestamp by UA: (4 octets)

        See Section 3.2.4.3.  Set by the UA.

     Evidence: (0 to 112 octets)




  Wiethuechter, et al.     Expires 24 August 2024                [Page 14]


  Internet-Draft              DRIP Auth Formats              February 2024


        The evidence section MUST be filled in with data in the form of an
        opaque object specified in the DRIP Wrapper (Section 4.3),
        Manifest (Section 4.4), or Frame (Section 4.5).

     UA DRIP Entity Tag: (16 octets)

        This is the current DET [RFC9374] being used by the UA assumed to
        be a Specific Session ID (a type of UAS ID).

     UA Signature: (64 octets)

        Signature over concatenation of preceding fields (VNB, VNA,
        Evidence, and UA DET) using the keypair of the UA DET.  The
        signature algorithm is specified by the HHIT Suite ID of the DET.

     When using this structure, the UA is minimally self-endorsing its
     DET.  The HI of the UA DET can be looked up by mechanisms described
     in [drip-registries] or by extracting it from a Broadcast Endorsement
     (see Section 4.2 and Section 6.3).

  4.2.  DRIP Link

     This SAM Type is used to transmit Broadcast Endorsements.  For
     example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link
     message.

     DRIP Link is important as its contents are used to provide trust in
     the DET/HI pair that the UA is currently broadcasting.  This message
     does not require Internet connectivity to perform signature
     verification of the contents when the DIME DET/HI is in the
     Observer's cache.  It also provides the UA HI, when it is filled with
     a BE: HDA, UA, so that connectivity is not required when performing
     signature verification of other DRIP Authentication Messages.

     Various Broadcast Endorsements are sent during operation to ensure
     that the full Broadcast Endorsement chain is available offline.  See
     Section 6.3 for further details.














  Wiethuechter, et al.     Expires 24 August 2024                [Page 15]


  Internet-Draft              DRIP Auth Formats              February 2024


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |                    VNB Timestamp by Parent                    |
       +---------------+---------------+---------------+---------------+
       |                    VNA Timestamp by Parent                    |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                              DET                              |
       |                            of Child                           |
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                                                               |
       |                                                               |
       |                           HI of Child                         |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                              DET                              |
       |                           of Parent                           |
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                     Signature by Parent                       |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+

                  Figure 5: Broadcast Endorsement / DRIP Link

     VNB Timestamp by Parent: (4 octets)




  Wiethuechter, et al.     Expires 24 August 2024                [Page 16]


  Internet-Draft              DRIP Auth Formats              February 2024


        See Section 3.2.4.3.  Set by Parent Entity.

     VNA Timestamp by Parent: (4 octets)

        See Section 3.2.4.3.  Set by Parent Entity.

     DET of Child: (16 octets)

        DRIP Entity Tag of Child Entity.

     HI of Child: (32 octets)

        Host Identity of Child Entity.

     DET of Parent: (16 octets)

        DRIP Entity Tag of Parent Entity in DIME Hierarchy.

     Signature by Parent: (64 octets)

        Signature over concatenation of preceding fields (VNB, VNA, DET of
        Child, HI of Child, and DET of Parent) using the keypair of the
        Parent DET.

     This DRIP Authentication Message is used in conjunction with other
     DRIP SAM Types (such as the Manifest or the Wrapper) that contain
     data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that
     is guaranteed to be unique, unpredictable, and easily cross-checked
     by the receiving device.

     A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
     chain MUST be included in each DRIP Manifest Section 4.4.

  4.3.  DRIP Wrapper

     This SAM Type is used to wrap and sign over a list of other [F3411]
     Broadcast RID messages.

     The evidence section of the UA Signed Evidence Structure
     (Section 4.1) is populated with up to four ASTM [F3411] Messages in a
     contiguous octet sequence.  Only ASTM Message Types 0x0, 0x1, 0x3,
     0x4, and 0x5 are allowed and must be in Message Type order as defined
     by [F3411].  These messages MUST include the Message Type and
     Protocol Version octet and MUST NOT include the Message Counter octet
     (thus are fixed at 25 octets in length).






  Wiethuechter, et al.     Expires 24 August 2024                [Page 17]


  Internet-Draft              DRIP Auth Formats              February 2024


  4.3.1.  Wrapped Count & Format Validation

     When decoding a DRIP Wrapper on a receiver, a calculation of the
     number of messages wrapped and a validation MUST be performed by
     using the number of octets (defined as wrapperLength) between the VNA
     Timestamp by UA and the UA DET as shown in Figure 6.

     <CODE BEGINS>
     if (wrapperLength MOD 25) != 0 {
       return DECODE_FAILURE;
     }
     wrappedCount = wrapperLength / 25;
     if (wrappedCount == 0) {
       // DECODE_SUCCESS; treat as DRIP Wrapper over extended transport
     }
     else if (wrappedCount > 4) {
       return DECODE_FAILURE;
     } else {
       // DECODE_SUCCESS; treat as standard DRIP Wrapper
     }
     <CODE ENDS>

           Figure 6: Pseudo-code for Wrapper validation and number of
                              messages calculation

  4.3.2.  Wrapper over Extended Transports

     When using Extended Transports an optimization can be made to DRIP
     Wrapper to sign over co-located data in an ASTM Message Pack (Message
     Type 0xF).

     To perform this optimization the UA Signed Evidence Structure is
     filled with the ASTM Messages to be in the ASTM Message Pack, the
     signature is generated, then the evidence field is cleared leaving
     the encoded form shown in Figure 7.
















  Wiethuechter, et al.     Expires 24 August 2024                [Page 18]


  Internet-Draft              DRIP Auth Formats              February 2024


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |                      VNB Timestamp by UA                      |
       +---------------+---------------+---------------+---------------+
       |                      VNA Timestamp by UA                      |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                              UA                               |
       |                        DRIP Entity Tag                        |
       |                                                               |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                          UA Signature                         |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+

                Figure 7: DRIP Wrapper over Extended Transports

     To verify the signature, the receiver MUST concatenate all the
     messages in the Message Pack (excluding Authentication Message found
     in the same Message Pack) in ASTM Message Type order and set the
     evidence section of the UA Signed Evidence Structure before
     performing signature verification.

     The functionality of a Wrapper in this form is equivalent to Message
     Set Signature (Authentication Type 0x3) when running over Extended
     Transports.  What the Wrapper provides is the same format but over
     both Extended and Legacy Transports allowing the transports to be
     similar.  Message Set Signature also implies using the ASTM validator
     system architecture which depends on Internet connectivity for
     verification which the receiver may not have at the time of receipt
     of an Authentication Message.  This is something the Wrapper, and all
     DRIP Authentication Formats, avoid when the UA key is obtained via a
     DRIP Link Authentication Message.



  Wiethuechter, et al.     Expires 24 August 2024                [Page 19]


  Internet-Draft              DRIP Auth Formats              February 2024


  4.3.3.  Wrapper Limitations

     The primary limitation of the Wrapper is the bounding of up to 4 ASTM
     Messages that can be sent within it.  Another limitation is that the
     format cannot be used as a surrogate for messages it is wrapping due
     to the potential that an Observer on the ground does not support
     DRIP.  Thus, when a Wrapper is being used, the wrapped data must
     effectively be sent twice, once as a single framed message (as
     specified in [F3411]) and then again within the Wrapper.

  4.4.  DRIP Manifest

     This SAM Type is used to create message manifests that contain hashes
     of previously sent ASTM Messages.

     By hashing previously sent messages and signing them, we gain trust
     in a UA's previous reports without re-transmitting them.  This is a
     way to evade the limitation of a maximum of 4 messages in the Wrapper
     (Section 4.3.3) and greatly reduce overhead.

     Observers MUST hash all received ASTM Messages and cross-check them
     against hashes in received Manifests.

     Judicious use of a Manifest enables an entire Broadcast RID message
     stream to be strongly authenticated with less than 100% overhead
     relative to a completely unauthenticated message stream (see
     Section 6.3 and Appendix B).

     The evidence section of the UA Signed Evidence Structure
     (Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast
     RID messages (up to 11) and three special hashes (Section 4.4.2).
     All these hashes MUST be concatenated to form a contiguous octet
     sequence in the evidence section.  It is RECOMMENDED the max number
     of ASTM Message Hashes be used is 10 (see Appendix B.1.1.2).

     The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE:
     HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen
     in Figure 8.

     An Observer MUST use the Manifest to verify each ASTM Message hashed
     therein that it has previously received.  It can do this without
     having received them all.  A Manifest SHOULD typically encompass a
     single transmission cycle of messages being sent, see Section 6.4 and
     Appendix B.







  Wiethuechter, et al.     Expires 24 August 2024                [Page 20]


  Internet-Draft              DRIP Auth Formats              February 2024


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |                       Previous Manifest                       |
       |                              Hash                             |
       +---------------+---------------+---------------+---------------+
       |                       Current Manifest                        |
       |                              Hash                             |
       +---------------+---------------+---------------+---------------+
       |                      DRIP Link (BE: HDA, UA)                  |
       |                              Hash                             |
       +---------------+---------------+---------------+---------------+
       |                                                               |
       .                                                               .
       .                      ASTM Message Hashes                      .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+

                   Figure 8: DRIP Manifest Evidence Structure

     Previous Manifest Hash: (8 octets)

        Hash of the previously sent Manifest Message.

     Current Manifest Hash: (8 octets)

        Hash of the current Manifest Message.

     DRIP Link (BE: HDA, UA): (8 octets)

        Hash of the DRIP Link Authentication Message carrying BE: HDA, UA
        (see Section 4.2).

     ASTM Message Hash: (8 octets)

        Hash of a single full ASTM Message using hash operations described
        in Section 4.4.3.

  4.4.1.  Hash Count & Format Validation

     When decoding a DRIP Manifest on a receiver, a calculation of the
     number of hashes and a validation can be performed by using the
     number of octets (defined as manifestLength) between the UA DET and
     the VNB Timestamp by UA such as shown in Figure 9.






  Wiethuechter, et al.     Expires 24 August 2024                [Page 21]


  Internet-Draft              DRIP Auth Formats              February 2024


     <CODE BEGINS>
     if (manifestLength MOD 8) != 0 {
       return DECODE_FAILURE
     }
     hashCount = (manifestLength / 8) - 3;
     <CODE ENDS>

      Figure 9: Pseudo-code for Manifest Sanity Check and Number of Hashes
                                  Calculation

  4.4.2.  Manifest Ledger Hashes

     Three special hashes are included in all Manifests.  The Previous
     Manifest Hash, links to the previous Manifest, and the Current
     Manifest Hash is of the Manifest in which it appears.  These two
     hashes act as a ledger of provenance to the Manifest that could be
     traced back if the Observer was present for extended periods of time.

     The DRIP Link (BE: HDA, UA) is included so there is a direct
     signature by the UA over the Broadcast Endorsement (see Section 4.2).
     Typical operation would expect that the list of ASTM Message Hash's
     contain nonce-link data.  To enforce a binding between the BE: HDA,
     UA and avoid trivial replay attack vectors (see Section 9.1) at least
     1 ASTM Message Hash MUST be from an [F3411] message that satisfies
     the 4th requirement in Section 6.3.

  4.4.3.  Hash Algorithms and Operation

     The hash algorithm used for the Manifest is the same hash algorithm
     used in creation of the DET [RFC9374] that is signing the Manifest.
     This is encoded as part of the DET using the HHIT Suite ID.

     DET's using cSHAKE128 [NIST.SP.800-185] compute the hash as follows:

     cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")

     For OGAs other than "5" [RFC9374], use the construct appropriate for
     the associated hash.  For example, for "2" which is ECDSA/SHA-384:

     Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )











  Wiethuechter, et al.     Expires 24 August 2024                [Page 22]


  Internet-Draft              DRIP Auth Formats              February 2024


     When building the list of hashes, the Previous Manifest Hash is known
     from the previous Manifest.  For the first built Manifest this value
     is filled with a random nonce.  The Current Manifest Hash is null
     filled while ASTM Messages are hashed and fill the ASTM Messages
     Hashes section.  When all messages are hashed, the Current Manifest
     Hash is computed over the Previous Manifest Hash, Current Manifest
     Hash (null filled) and ASTM Messages Hashes.  This hash value
     replaces the null filled Current Manifest Hash and becomes the
     Previous Manifest Hash for the next Manifest.

  4.4.3.1.  Legacy Transport Hashing

     Under this transport DRIP hashes the full ASTM Message being sent
     over the Bluetooth Advertising frame.  This is the 25-octet object
     start with the Message Type and Protocol Version octet along with the
     24 octets of message data.  The hash MUST NOT included the Message
     Counter octet.

     For paged ASTM Messages (currently only Authentication Messages) all
     the pages are concatenated together in Page Number order and hashed
     as one object.

  4.4.3.2.  Extended Transport Hashing

     Under this transport DRIP hashes the full ASTM Message Pack (Message
     Type 0xF) regardless of its content.  The hash MUST NOT included the
     Message Counter octet.

  4.5.  DRIP Frame

     This SAM Type is defined to enable the use of Section 4.1 in the
     future beyond the previously defined formats (Wrapper and Manifest)
     by the inclusion of a single octet to signal the format of evidence
     data (up to 111 octets).

     The content format of Frame Evidence Data is not defined in this
     document.  Other specifications MUST define the contents and register
     for a Frame Type.  At the time of publication there are no defined
     Frame Types other than an Experimental range.

     Observers MUST check the signature of the structure (Section 4.1) per
     Section 3.1.2.2 and MAY, if the specification of Frame Type is known,
     parse the content in Frame Evidence Data.








  Wiethuechter, et al.     Expires 24 August 2024                [Page 23]


  Internet-Draft              DRIP Auth Formats              February 2024


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |  Frame Type   |                                               |
       +---------------+                                               .
       .                      Frame Evidence Data                      .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+

                             Figure 10: DRIP Frame

     Frame Type: (1 octet)

        Byte to sub-type for future different DRIP Frame formats.  It
        takes the first octet in Figure 10, leaving 111 octets available
        for Frame Evidence Data.  See Section 8.1 for Frame Type
        allocations.

  5.  Forward Error Correction

     For Broadcast RID, FEC is provided by the lower layers in Extended
     Transports.  The Bluetooth 4.x Legacy Transport does not have
     supporting FEC, so with DRIP Authentication the following application
     level scheme is used to add some FEC.  When sending data over a
     medium that does not have underlying FEC, for example Bluetooth 4.x,
     then this section MUST be used.

     The Bluetooth 4.x lower layers have error detection but not
     correction.  Any frame in which Bluetooth detects an error is dropped
     and not delivered to higher layers (in our case, DRIP).  Thus it can
     be treated as an erasure.

     DRIP standardizes a single page FEC scheme using XOR parity across
     all page data of an Authentication Message.  This allows the
     correction of single erased page in an Authentication Message.  If
     more than a single page is missing then handling of an incomplete
     Authentication Message is determined by higher layers.

     Other FEC schemes, to protect more than a single page of an
     Authentication Message or multiple [F3411] Messages, is left for
     future standardization if operational experience proves it necessary
     and/or practical.

     The data added during FEC is not included in the Authentication Data
     / Signature, but instead in the Additional Data field of Figure 2.
     This may cause the Authentication Message to exceed 9-pages, up to a
     maximum of 16-pages.



  Wiethuechter, et al.     Expires 24 August 2024                [Page 24]


  Internet-Draft              DRIP Auth Formats              February 2024


  5.1.  Encoding

     When encoding two things are REQUIRED:

     1.  The FEC data MUST start on a new Authentication Page.  To do
         this, the results of parity encoding MUST be placed in the
         Additional Data field of Figure 2 with null padding before it to
         line up with the next page.  The Additional Data Length field
         MUST be set to number of padding octets + number of parity
         octets.

     2.  The Last Page Index field (in Page 0) MUST be incremented from
         what it would have been without FEC by the number of pages
         required for the Additional Data Length field, null padding and
         FEC.

     To generate the parity, a simple XOR operation using the previous
     parity page and current page is used.  Only the 23-octet
     Authentication Payload field of Figure 1 is used in the XOR
     operations.  For Page 0, a 23-octet null pad is used for the previous
     parity page.

     Figure 11 shows an example of the last two pages (out of N) of an
     Authentication Message using DRIP Single Page FEC.  The Additional
     Data Length is set to 33 as there are always 23 octets of FEC data
     and in this example 10 octets of padding to line it up into Page N.

























  Wiethuechter, et al.     Expires 24 August 2024                [Page 25]


  Internet-Draft              DRIP Auth Formats              February 2024


       Page N-1:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |  Page Header  |                                               |
       +---------------+                                               |
       |                Authentication Data / Signature                |
       |                                                               |
       |               +---------------+---------------+---------------+
       |               |    ADL=33     |                               |
       +---------------+---------------+                               |
       |                          Null Padding                         |
       |                                                               |
       +---------------+---------------+---------------+---------------+

       Page N:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |  Page Header  |                                               |
       +---------------+                                               |
       |                                                               |
       |                     Forward Error Correction                  |
       |                                                               |
       |                                                               |
       |                                                               |
       +---------------+---------------+---------------+---------------+

                  Figure 11: Example Single Page FEC Encoding

  5.2.  Decoding

     Frame decoding is independent of the transmit media.  However the
     decoding process can determine from the first Authentication page
     that there may be a Bluetooth 4.x FEC page at the end.  The decoding
     process MUST test for the presence of FEC and apply it as follows.

     To determine if FEC has been used, a check of the Last Page Index is
     performed.  In general if the Last Page Index field is one greater
     than that necessary to hold Length octets of Authentication Data then
     FEC has been used.  Note that if Length octets are exhausted exactly
     at the end of an Authentication Page, the Additional Data Length
     field will occupy the first octet of the following page.  The
     remainder of this page will be null padded under DRIP to align the
     FEC to its own page.  In this case the Last Page Index will have been
     incremented once for initializing the Additional Data Length field
     and once for FEC page, for a total of two additional pages, as in the
     last row of Table 5.



  Wiethuechter, et al.     Expires 24 August 2024                [Page 26]


  Internet-Draft              DRIP Auth Formats              February 2024


     To decode FEC in DRIP, a rolling XOR is used on each Authentication
     Page received in the current Authentication Message.  A Message
     Counter, outside of the ASTM Message but specified in [F3411], is
     used to signal a different Authentication Message and to correlate
     pages to messages.  This Message Counter is only single octet in
     length, so it will roll over (to 0x00) after reaching its maximum
     value (0xFF).  If only a single page is missing in the Authentication
     Message the resulting parity octets should be the data of the erased
     page.

     Authentication Page 0 contains various important fields, only located
     on that page, that help decode the full ASTM Authentication Message.
     If Page 0 has been reconstructed, the Last Page Index and Length
     fields MUST be validated by DRIP.  The pseudo-code in Figure 12 can
     be used for both checks.




































  Wiethuechter, et al.     Expires 24 August 2024                [Page 27]


  Internet-Draft              DRIP Auth Formats              February 2024


     <CODE BEGINS>
     function decode_check(auth_pages[], decoded_lpi, decoded_length) {
       // check decoded_lpi does not exceed maximum value
       if (decoded_lpi >= 16) {
         return DECODE_FAILURE
       }

       // check that decoded length does not exceed DRIP maximum value
       if (decoded_length > 201) {
         return DECODE_FAILURE
       }

       // grab the page at index where length ends and extract its data
       auth_data = auth_pages[(decoded_length - 17) / 23].data
       // find the index of last auth byte
       last_auth_byte = (17 + (23 * last_auth_page)) - decoded_length

       // look for non-nulls after the last auth byte
       if (auth_data[(last_auth_byte + 2):] has non-nulls) {
         return DECODE_FAILURE
       }

       // check that byte directly after last auth byte is null
       if (auth_data[last_auth_byte + 1] equals null) {
         return DECODE_FAILURE
       }

       // we set our presumed Additional Data Length (ADL)
       presumed_adl = auth_data[last_auth_byte + 1]
       // use the presumed ADL to calculate a presumed LPI
       presumed_lpi = (presumed_adl + decoded_length - 17) / 23

       // check that presumed LPI and decoded LPI match
       if (presumed_lpi not equal decoded_lpi) {
         return DECODE_FAILURE
       }
       return DECODE_SUCCESS
     }
     <CODE ENDS>

                    Figure 12: Pseudo-code for Decode Checks










  Wiethuechter, et al.     Expires 24 August 2024                [Page 28]


  Internet-Draft              DRIP Auth Formats              February 2024


  5.3.  FEC Limitations

     The worst-case scenario is when the Authentication Data / Signature
     ends perfectly on a page boundary (Page N-1).  This means the
     Additional Data Length would start the next page (Page N) and have 22
     octets worth of null padding to align the FEC to begin at the start
     of the next page (Page N+1).  In this scenario, an entire page (Page
     N) is being wasted just to carry the Additional Data Length.

  6.  Requirements & Recommendations

  6.1.  Legacy Transports

     Under DRIP, the goal is to attempt to bring reliable receipt of the
     paged Authentication Message using Legacy Transports.  FEC
     (Section 5) MUST be used, per mandated RID rules (for example the US
     FAA RID Rule [FAA-14CFR]), when using Legacy Transports (such as
     Bluetooth 4.x).

     Under [F3411], Authentication Messages are transmitted at the static
     rate (at least every 3 seconds).  Any DRIP Authentication Messages
     containing dynamic data (such as the DRIP Wrapper) MAY be sent at the
     dynamic rate (at least every 1 second).

  6.2.  Extended Transports

     Under the ASTM specification, Extended Transports of RID must use the
     Message Pack (Message Type 0xF) format for all transmissions.  Under
     Message Pack, ASTM Messages are sent together (in Message Type order)
     in a single frame (up to 9 single frame equivalent messages under
     Legacy Transports).  Message Packs are required by [F3411] to be sent
     at a rate of 1 per second (like dynamic messages).

     Message Packs are sent only over Extended Transports that provide
     FEC.  Thus, the DRIP decoders will never be presented with a Message
     Pack from which a constituent Authentication Page has been dropped;
     DRIP FEC could never provide a benefit to a Message Pack, only
     consume its precious payload space.  Therefore, DRIP FEC (Section 5)
     MUST NOT be used in Message Packs.

  6.3.  Authentication

     To fulfill the requirements in [RFC9153], a UA:

     1.  MUST: send DRIP Link (Section 4.2) using the BE: Apex, RAA
         (partially satisfying GEN-3); at least once per 5 minutes.  Apex
         in this context is the DET prefix owner




  Wiethuechter, et al.     Expires 24 August 2024                [Page 29]


  Internet-Draft              DRIP Auth Formats              February 2024


     2.  MUST: send DRIP Link (Section 4.2) using the BE: RAA, HDA
         (partially satisfying GEN-3); at least once per 5 minutes

     3.  MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA
         (satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least
         once per minute

     4.  MUST: send any other DRIP Authentication Format (non-DRIP Link)
         where the UA is dynamically signing data that is guaranteed to be
         unique, unpredictable and easily cross checked by the receiving
         device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5
         seconds

     These four transmission requirements collectively satisfy GEN-3.

  6.4.  Operational

     UAS operation may impact the frequency of sending DRIP Authentication
     messages.  When a UA dwells at an approximate location, and the
     channel is heavily used by other devices, less frequent message
     authentication may be effective (to minimize RF packet collisions)
     for an Observer.  Contrast this with a UA transiting an area, where
     authenticated messages SHOULD be sufficiently frequent for an
     Observer to have a high probability of receiving an adequate number
     for validation during the transit.

     A RECOMMENDED operational configuration (in alignment with
     Section 6.3) with reasoning can be found in Appendix B.  It consists
     of the following recommendations for every second:

     *  Under Legacy Transport:

        -  Two sets of those ASTM Messages required by a CAA in its
           jurisdiction (example: Basic ID, Location and System) and one
           set of other ASTM Messages (example: Self ID, Operator ID)

        -  An FEC protected DRIP Manifest enabling authentication of those
           ASTM Messages sent

        -  A single page of an FEC protected DRIP Link

     *  Under Extended Transport:

        -  A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper
           (per Section 4.3.2)

        -  A Message Pack of a DRIP Link




  Wiethuechter, et al.     Expires 24 August 2024                [Page 30]


  Internet-Draft              DRIP Auth Formats              February 2024


  6.4.1.  DRIP Wrapper

     If DRIP Wrappers are sent, they MUST be sent in addition to any
     required ASTM Messages in a given jurisdiction.  An implementation
     MUST NOT send DRIP Wrappers in place of any required ASTM Messages it
     may encapsulate.  Thus, messages within a Wrapper are sent twice:
     once in the clear and once authenticated within the Wrapper.

     The DRIP Wrapper has a specific use case for DRIP aware Observers.
     For an Observer plotting Location Messages (Message Type 0x2) on a
     map, display an embedded Location Message in a DRIP Wrapper can be
     marked differently (e.g., via color) to signify trust in the Location
     data.

  6.4.2.  UAS RID Trust Assessment

     As described in Section 3.1.2, the Observer MUST perform validation
     of the data being received in Broadcast RID.  This is because trust
     in a key is different from trust that an observed UA possesses that
     key.

     A chain of DRIP Links provides trust in a key.  A message containing
     rapidly changing, not predictable far in advance (relative to typical
     operational flight times) that can be validated by Observers, signed
     by that key, provides trust that some agent with access to that data
     also possesses that key.  If the validation involves correlating
     physical world observations of the UA with claims in that data, then
     the probability is high that the observed UA is (or is collaborating
     with or observed in real time by) the agent with the key.

     After signature verification of any DRIP Authentication Message
     containing UAS RID information elements (e.g., DRIP Wrapper
     Section 4.3) the Observer MUST use other sources of information to
     correlate against and perform validation.  An example of another
     source of information is a visual confirmation of the UA position.

     When correlation of these different data streams does not match in
     acceptable thresholds, the data MUST be rejected as if the signature
     failed to validate.  Acceptable thresholds limits and what happens
     after such a rejection are out of scope for this document.

  7.  Summary of Addressed DRIP Requirements

     The following [RFC9153] requirements are addressed in this document:

     ID-5: Non-spoofability





  Wiethuechter, et al.     Expires 24 August 2024                [Page 31]


  Internet-Draft              DRIP Auth Formats              February 2024


        Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest
        (Section 4.4) or DRIP Frame (Section 4.5).

     GEN-1: Provable Ownership

        Addressed using the DRIP Link (Section 4.2) and DRIP Wrapper
        (Section 4.3), DRIP Manifest (Section 4.4) or DRIP Frame
        (Section 4.5).

     GEN-2: Provable Binding

        Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest
        (Section 4.4) or DRIP Frame (Section 4.5).

     GEN-3: Provable Registration

        Addressed using the DRIP Link (Section 4.2).

  8.  IANA Considerations

  8.1.  IANA DRIP Registry

     This document requests two new registries, for DRIP SAM Type and DRIP
     Frame Type, under the DRIP registry group
     (https://www.iana.org/assignments/drip/drip.xhtml).

     DRIP SAM Type:  This registry is a mirror for SAM Types containing
        the subset of allocations used by DRIP Authentication Messages.
        Future additions MUST be done through ASTM's designated registrar
        which at the time of publication of this RFC is ICAO
        [ASTM-Remote-ID].  Additions for DRIP will be coordinated by IANA
        and the ASTM designated registrar before final publication as
        Standards Track RFCs.  The following values have been allocated to
        the IETF and are defined here:

     +==========+===============+=======================================+
     | SAM Type | Name          | Description                           |
     +==========+===============+=======================================+
     | 0x01     | DRIP Link     | Format to hold Broadcast Endorsements |
     +----------+---------------+---------------------------------------+
     | 0x02     | DRIP Wrapper  | Authenticate full ASTM Messages       |
     +----------+---------------+---------------------------------------+
     | 0x03     | DRIP Manifest | Authenticate hashes of ASTM Messages  |
     +----------+---------------+---------------------------------------+
     | 0x04     | DRIP Frame    | Format for future DRIP authentication |
     +----------+---------------+---------------------------------------+

                           Table 2: DRIP SAM Types



  Wiethuechter, et al.     Expires 24 August 2024                [Page 32]


  Internet-Draft              DRIP Auth Formats              February 2024


     DRIP Frame Type:  This 8-bit valued registry is for Frame Types in
        DRIP Frame Authentication Messages.  Future additions to this
        registry are to be made through Expert Review (Section 4.5 of
        [RFC8126]) for the values of 0x01 to 0x9F and First Come, First
        Served (Section 4.4 of [RFC8126]) for values 0xA0 to 0xEF.  The
        following values are defined:

      +=============+==============+====================================+
      | Frame Type  | Name         | Description                        |
      +=============+==============+====================================+
      | 0x00        | Reserved     | Reserved                           |
      +-------------+--------------+------------------------------------+
      | 0x01 - 0x9F | Reserved     | Reserved: Expert Review            |
      +-------------+--------------+------------------------------------+
      | 0xA0 - 0xEF | Reserved     | Reserved: First Come, First Served |
      +-------------+--------------+------------------------------------+
      | 0xF0 - 0xFF | Experimental | Experimental Use                   |
      +-------------+--------------+------------------------------------+

                           Table 3: DRIP Frame Types

     Criteria that should be applied by the designated experts includes
     determining whether the proposed registration duplicates existing
     functionality and whether the registration description is clear and
     fits the purpose of this registry.

     Registration requests MUST be sent to drip-reg-review@ietf.org
     (mailto:drip-reg-review@ietf.org) and be evaluated within a three-
     week review period on the advice of one or more designated experts.
     Within that review period, the designated experts will either approve
     or deny the registration request, and communicate their decision to
     the review list and IANA.  Denials should include an explanation and,
     if applicable, suggestions to successfully register the DRIP Frame
     Type.

     Registration requests that are undetermined for a period longer than
     28 days can be brought to the IESG's attention for resolution.

  9.  Security Considerations

  9.1.  Replay Attacks

     [F3411] (regardless of transport) lacks replay protection, as it more
     fundamentally lacks fully specified authentication.  An attacker can
     spoof the UA sender MAC address and UAS ID, replaying (with or
     without modification) previous genuine messages, and/or crafting
     entirely new messages.  Using DRIP in [F3411] Authentication message
     framing enables verification that messages were signed with



  Wiethuechter, et al.     Expires 24 August 2024                [Page 33]


  Internet-Draft              DRIP Auth Formats              February 2024


     registered keys, but when naively used may be vulnerable to replay
     attacks.  Technologies such as Single Emitter Identification can
     detect such attacks, but are not readily available and can be
     prohibitively expensive, especially for typical Observer devices such
     as smartphones.

     Replay attack detection using DRIP requires Observer devices to
     combine information from multiple messages and sources other than
     Broadcast RID.  A complete chain of Link messages (Section 4.2), from
     an Endorsement root of trust to the claimed sender, must be collected
     and verified by the Observer device to provide trust in a key.
     Successful signature verification, using that key, of a Wrapper
     (Section 4.3) or Manifest (Section 4.4) message, authenticating
     content that is nonce-like, provides trust that the sender actually
     possesses that key.

     By "nonce-like" is meant data that is unique, not accurately
     predictable long in advance, and readily validated by the Observer.
     This is described in Section 6.3 (requirement 4) and Section 3.1.2.2.
     The [F3411] Location message reporting precise UA position and
     velocity at a precise very recent time, to be checked by the Observer
     against visual observations of the UA within RF and thus typically
     visual Line Of Sight is the recommended form of this data.  For
     specification of the foregoing, see Section 3.1.2 and Section 6.4.2.

     Messages that pass signature verification with trusted keys could
     still be replays if they contain only static information (e.g.,
     Broadcast Endorsements (Section 4.2), [F3411] Basic ID or [F3411]
     Operator ID) or information that cannot be readily validated (e.g.,
     [F3411] Self-ID).  Replay of Link messages is harmless (unless sent
     so frequently as to cause RF data link congestion) and indeed can
     increase the likelihood of an Observer device collecting an entire
     trust chain in a short time window.  Replay of other messages
     ([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a
     vulnerability, unless they are combined with messages containing
     nonce-like data ([F3411] Location or [F3411] System) in a Wrapper or
     Manifest.  For specification of this last requirement, see
     Section 4.4.2.

  9.2.  Wrapper vs Manifest

     Implementations have a choice on using Wrapper (Section 4.3),
     Manifest (Section 4.4), or a combination to satisfy the 4th
     requirement in Section 6.3.







  Wiethuechter, et al.     Expires 24 August 2024                [Page 34]


  Internet-Draft              DRIP Auth Formats              February 2024


     Wrapper is an attached signature of the full content of one or more
     [F3411] messages, providing strong authentication.  However, the size
     limitation means it can not support such signatures over other
     Authentication Messages, thus it can not provide a direct binding to
     any part of the trust chain (Section 3.1.2 and Section 6.4.2).

     Manifest explicitly provides the binding of the last link in the
     trust chain (with the inclusion of the hash of the Link containing
     BE: HDA, UA).  The use of hashes and their length also allows for a
     larger (11 vs 4) number of any [F3411] messages to be authenticated,
     making it more efficient compared to the Wrapper.  However, the
     detached signature requires additional Observer overhead in storing
     and comparing hashes of received messages (some that may not be
     received) of those in a Manifest.

     Appendix B contains a breakdown of frame counts and an example of a
     schedule using both Manifest and Wrapper.  Typical operation may see
     (as an example) 2x Basic ID, 2x Location, 2x System, 1x Operator ID
     and 1x Self ID broadcast per second to comply with jurisdiction
     mandates.  Each of these messages are a single frame in size.  A Link
     message is 8 frames long (including FEC).  This is a base frame count
     of *16 frames*.

     When Wrapper is used, up to 4 of the previous messages (except the
     Link) can be authenticated.  For this comparison, we will sign all
     the messages we can in two Wrappers.  This results in _20 frames_
     (with FEC).  Due to not being able to fit, the Link message is left
     unauthenticated.  The total frame count using Wrappers is *36 frames*
     (wrapper frame count + base frame count).

     When Manifest is used, up to 10 previous messages can be
     authenticated.  For this example all messages (8) are hashed
     (including the Link) resulting in a single Manifest that is _9
     frames_ (with FEC).  The total frame count using Manifest is *25
     frames* (manifest frame count + base frame count).

  9.3.  VNA Timestamp Offsets for DRIP Authentication Formats

     Note the discussion of VNA Timestamp offsets here is in the context
     of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and
     DRIP Frame (Section 4.5).  For DRIP Link (Section 4.2) these offsets
     are set by the DIME and have their own set of considerations in
     [drip-registries].

     The offset of the VNA Timestamp by UA is one that needs careful
     consideration for any implementation.  The offset should be shorter
     than any given flight duration (typically less than an hour) but be
     long enough to be received and processed by Observers (larger than a



  Wiethuechter, et al.     Expires 24 August 2024                [Page 35]


  Internet-Draft              DRIP Auth Formats              February 2024


     few seconds).  It is recommended that 3-5 minutes should be
     sufficient to serve this purpose in any scenario, but is not limited
     by design.

  9.4.  DNS Security in DRIP

     As stated in Section 3.1 specification of particular DNS security
     options, transports, etc. is outside the scope of this document.
     [drip-registries] is the main specification for DNS operations in
     DRIP and as such will specify DRIP usage of best common practices for
     security (such as [RFC9364]).

  10.  Acknowledgments

     *  Ryan Quigley, James Mussi and Joseph Stanton of AX Enterprize, LLC
        for early prototyping to find holes in the draft specifications

     *  Carsten Bormann for the simple approach of using bit-column-wise
        parity for erasure (dropped frame) FEC

     *  Soren Friis for pointing out that Wi-Fi implementations would not
        always give access to the MAC Address, originally used in
        calculation of the hashes for DRIP Manifest.  Also, for confirming
        that Message Packs (0xF) can only carry up to 9 ASTM frames worth
        of data (9 Authentication pages)

     *  Gabriel Cox (chair of the working group that produced [F3411]) in
        reviewing the specification for the SAM Type request as the ASTM
        Designated Expert

     *  Mohamed Boucadair (Document Shepherd) for his many patches and
        comments

     *  Eric Vyncke (DRIP AD) for his guidance through the documents path
        to publication

     *  Thanks to the following reviewers:

        -  Rick Salz (secdir)

        -  Matt Joras (genart)

        -  Di Ma (dnsdir)

        -  Gorry Fairhurst (tsvart)

        -  Carlos Bernardos (intdir)




  Wiethuechter, et al.     Expires 24 August 2024                [Page 36]


  Internet-Draft              DRIP Auth Formats              February 2024


        -  Behcet Sarikaya (iotdir)

        -  Martin Duke (IESG)

        -  Roman Danyliw (IESG)

        -  Murray Kucherawy (IESG)

        -  Erik Kline (IESG)

        -  Warren Kumari (IESG)

        -  Paul Wouters (IESG)

  11.  References

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

     [NIST.SP.800-185]
                Kelsey, J., Change, S., Perlner, R., and NIST, "SHA-3
                derived functions: cSHAKE, KMAC, TupleHash and
                ParallelHash", NIST Special Publications
                (General) 800-185, DOI 10.6028/NIST.SP.800-185, December
                2016,
                <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
                NIST.SP.800-185.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/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>.

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






  Wiethuechter, et al.     Expires 24 August 2024                [Page 37]


  Internet-Draft              DRIP Auth Formats              February 2024


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

  11.2.  Informative References

     [ASTM-Remote-ID]
                "ICAO Remote ID Number Registration", December 2023,
                <https://www.icao.int/airnavigation/IATF/Pages/ASTM-
                Remote-ID.aspx>.

     [drip-registries]
                Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET)
                Identity Management Architecture", Work in Progress,
                Internet-Draft, draft-ietf-drip-registries-14, 4 December
                2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
                drip-registries-14>.

     [FAA-14CFR]
                "Remote Identification of Unmanned Aircraft", January
                2021, <https://www.govinfo.gov/content/pkg/FR-2021-01-15/
                pdf/2020-28948.pdf>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

     [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
                RFC 9364, DOI 10.17487/RFC9364, February 2023,
                <https://www.rfc-editor.org/info/rfc9364>.

  Appendix A.  Authentication States

     ASTM Authentication has only three states: None, Invalid, and Valid.
     This is because, under ASTM, the authentication is done by an
     external service hosted somewhere on the Internet so it is assumed an
     authoritative response will always be returned.  This classification
     becomes more complex in DRIP with the support of "offline" scenarios
     where a Observer does not have Internet connectivity.  With the use
     of asymmetric cryptography this means that the public key (PK) must
     somehow be obtained. [drip-registries] gets more into detail how



  Wiethuechter, et al.     Expires 24 August 2024                [Page 38]


  Internet-Draft              DRIP Auth Formats              February 2024


     these keys are stored on DNS and one use of DRIP Authentication
     messages is to send PK's over Broadcast RID.

     There are a few keys of interest: the PK of the UA and the PK's of
     relevant DIMEs.  This document describes how to send the PK of the UA
     over the Broadcast RID messages.  The key of DIMEs are sent over
     Broadcast RID using the same mechanisms (see Section 4.2 and
     Section 6.3) but MAY be sent at a far lower rate due to potential
     operational constraints (such as saturation of limited bandwidth).
     As such, there are scenarios where part of the key-chain may be
     unavailable at the moment a full Authentication Message is received
     and processed.

     The intent of this informative appendix is to give a recommended way
     to classify these various states and convey it to the user through
     colors and state names/text.  These states can apply to either a
     single authentication message, a DET (and its associated public key),
     and/or a sender.

     The table below lays out the recommended colors to associate with
     state and a brief description of each.






























  Wiethuechter, et al.     Expires 24 August 2024                [Page 39]


  Internet-Draft              DRIP Auth Formats              February 2024


          +==============+========+=================================+
          | State        | Color  | Details                         |
          +==============+========+=================================+
          | None         | Black  | No Authentication being         |
          |              |        | received (as yet)               |
          +--------------+--------+---------------------------------+
          | Partial      | Gray   | Authentication being received   |
          |              |        | but missing pages               |
          +--------------+--------+---------------------------------+
          | Unsupported  | Brown  | Authentication Type/SAM Type of |
          |              |        | received message not supported  |
          +--------------+--------+---------------------------------+
          | Unverifiable | Yellow | Data needed for signature       |
          |              |        | verification is missing         |
          +--------------+--------+---------------------------------+
          | Verified     | Green  | Valid signature verification    |
          |              |        | and content validation          |
          +--------------+--------+---------------------------------+
          | Trusted      | Blue   | evidence of Verified and DIME   |
          |              |        | is marked as only registering   |
          |              |        | DETs for trusted entities       |
          +--------------+--------+---------------------------------+
          | Unverified   | Red    | Invalid signature verification  |
          |              |        | or content validation           |
          +--------------+--------+---------------------------------+
          | Questionable | Orange | evidence of both Verified &     |
          |              |        | Unverified for the same claimed |
          |              |        | sender                          |
          +--------------+--------+---------------------------------+
          | Conflicting  | Purple | evidence of both Trusted &      |
          |              |        | Unverified for the same claimed |
          |              |        | sender                          |
          +--------------+--------+---------------------------------+

           Table 4: Authentication State Names, Colors & Descriptions

  A.1.  None: Black

     The default state where no authentication information has yet to be
     received.

  A.2.  Partial: Gray

     A pending state where authentication pages are being received but a
     full authentication message has yet to be compiled.






  Wiethuechter, et al.     Expires 24 August 2024                [Page 40]


  Internet-Draft              DRIP Auth Formats              February 2024


  A.3.  Unsupported: Brown

     A state wherein authentication data is being or has been received,
     but cannot be used, as the Authentication Type or SAM Type is not
     supported by the Observer.

  A.4.  Unverifiable: Yellow

     A pending state where a full authentication message has been received
     but other information, such as public keys to verify signatures, is
     missing.

  A.5.  Verified: Green

     A state where all authentication messages that have been received, up
     to that point from that claimed sender, pass signature verification
     and the requirement of Section 6.4.2 has been met.

  A.6.  Trusted: Blue

     A state where all authentication messages that have been received, up
     to that point, from that claimed sender, have passed signature
     verification, the requirement of Section 6.4.2 has been met, and the
     public key of the sending UA is marked as trusted.

     The sending UA key will have been marked as trusted if the relevant
     DIMEs only register DETs (of subordinate DIMEs, UAS operators, and
     UA) that have been vetted as per their published registration
     policies, and those DIMEs have been marked, by the owner (individual
     or organizational) of the Observer, as per that owner's policy, as
     trusted to register DETs only for trusted parties.

  A.7.  Questionable: Orange

     A state where there is a mix of authentication messages received that
     are Verified (Appendix A.5) and Unverified (Appendix A.8).

     Transition to this state is from Verified if a subsequent message
     fails verification so would have otherwise been marked Unverified, or
     from Unverified if a subsequent message passes verification or
     validation so would otherwise have been marked Verified, or from
     either of those state upon mixed results on the requirement of
     Section 6.4.2.








  Wiethuechter, et al.     Expires 24 August 2024                [Page 41]


  Internet-Draft              DRIP Auth Formats              February 2024


  A.8.  Unverified: Red

     A state where all authentication messages that have been received, up
     to that point, from that claimed sender, failed signature
     verification or the requirement of Section 6.4.2.

  A.9.  Conflicting: Purple

     A state where there is a mix of authentication messages received that
     are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the
     public key of the aircraft is marked as trusted.

     Transition to this state is from Trusted if a subsequent message
     fails verification so would have otherwise been marked Unverified, or
     from Unverified if a subsequent message passes verification or
     validation and policy checks so would otherwise have been marked
     Trusted, or from either of those state upon mixed results on the
     requirement of Section 6.4.2.

  Appendix B.  Operational Recommendation Analysis

     The recommendations found in Section 6.4 may seem heavy handed and
     specific.  This informative appendix lays out the math and
     assumptions made to come to the recommendations listed there as well
     as an example.

     In many jurisdictions, the required ASTM Messages to be transmitted
     every second are: Basic ID (0x1), Location (0x2), and System (0x4).
     Typical implementations will most likely send at a higher rate (2x
     sets per cycle) resulting in 6 frames sent per cycle.  Transmitting
     this set of message more than once a second is not discouraged but
     awareness is needed to avoid congesting the RF spectrum, causing
     further issues.

        Informational Note: In Europe, the Operator ID Message (0x5) is
        also required.  In Japan, two Basic ID (0x0), Location (0x1), and
        Authentication (0x2) are required.  Self ID (0x3) is optional but
        can carry Emergency Status information.

  B.1.  Page Counts vs Frame Counts

     There are two formulas to determine the number of Authentication
     Pages required, one for Wrapper:

     <CODE BEGINS>
     wrapper_struct_size = 89 + (25 * num_astm_messages)
     wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1
     <CODE ENDS>



  Wiethuechter, et al.     Expires 24 August 2024                [Page 42]


  Internet-Draft              DRIP Auth Formats              February 2024


     and one for Manifest:

     <CODE BEGINS>
     manifest_struct_size = 89 + (8 * (num_astm_hashes + 3))
     manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1
     <CODE ENDS>

     A similar formula can be applied to Link as they are of fixed size:

     <CODE BEGINS>
     link_page_count = ceiling((137 - 17) / 23) + 1 = 7
     <CODE ENDS>

     Comparing Wrapper and Manifest Authentication Message page counts
     against total frame counts we have the following:

      +==========+=========+==========+=================+===============+
      | ASTM     | Wrapper | Manifest | ASTM Messages + | ASTM Messages |
      | Messages | (w/FEC) | (w/FEC)  | Wrapper (w/FEC) | + Manifest    |
      |          |         |          |                 | (w/FEC)       |
      +==========+=========+==========+=================+===============+
      | 0        | 5 (6)   | 6 (7)    | 5 (6)           | 6 (7)         |
      +----------+---------+----------+-----------------+---------------+
      | 1        | 6 (7)   | 6 (7)    | 7 (8)           | 7 (8)         |
      +----------+---------+----------+-----------------+---------------+
      | 2        | 7 (8)   | 6 (7)    | 9 (10)          | 8 (9)         |
      +----------+---------+----------+-----------------+---------------+
      | 3        | 8 (9)   | 7 (8)    | 11 (12)         | 10 (11)       |
      +----------+---------+----------+-----------------+---------------+
      | 4        | 9 (10)  | 7 (8)    | 13 (14)         | 11 (12)       |
      +----------+---------+----------+-----------------+---------------+
      | 5        | N/A     | 7 (8)    | N/A             | 12 (13)       |
      +----------+---------+----------+-----------------+---------------+
      | 6        | N/A     | 8 (9)    | N/A             | 14 (15)       |
      +----------+---------+----------+-----------------+---------------+
      | 7        | N/A     | 8 (9)    | N/A             | 15 (16)       |
      +----------+---------+----------+-----------------+---------------+
      | 8        | N/A     | 8 (9)    | N/A             | 16 (17)       |
      +----------+---------+----------+-----------------+---------------+
      | 9        | N/A     | 9 (10)   | N/A             | 18 (19)       |
      +----------+---------+----------+-----------------+---------------+
      | 10       | N/A     | 9 (10)   | N/A             | 19 (20)       |
      +----------+---------+----------+-----------------+---------------+
      | 11       | N/A     | 9 (11)   | N/A             | 20 (22)       |
      +----------+---------+----------+-----------------+---------------+

                          Table 5: Page & Frame Counts




  Wiethuechter, et al.     Expires 24 August 2024                [Page 43]


  Internet-Draft              DRIP Auth Formats              February 2024


     Link shares the same page counts as Manifest with 5 ASTM Messages.

  B.1.1.  Special Cases

  B.1.1.1.  Zero ASTM Messages

     Zero ASTM Messages in Table 5 is where Extended Wrapper
     (Section 4.3.2) without FEC is used in Message Packs.  With a max of
     9 "message slots" in a Message Pack an Extended Wrapper fills 5
     slots, thus can authenticate up to 4 ASTM Messages co-located in the
     same Message Pack.

  B.1.1.2.  Eleven ASTM Messages

     Eleven ASTM Messages in Table 5 is where a Manifest with FEC invokes
     the situation mentioned in Section 5.3.

     Eleven is the max number of ASTM Messages Hashes that can be
     supported resulting in 14 total hashes.  This completely fills the
     evidence section of the structure making its total size 200 octets.
     This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8) so
     when the ADL is added it is placed on the next page (Page 10).  Per
     rule 1 in Section 5.1 this means that all of Page 10 is null padded
     (expect the ADL octet) and FEC data fills Page 11, resulting in a
     plus two page count when FEC is applied.

     This drives the recommendation is Section 4.4 to only use up to 10
     ASTM Message Hashes and not 11.

  B.2.  Full Authentication Example

     This example is focused on showing that 100% of ASTM Messages can be
     authenticated over Legacy Transports with up to 125% overhead in
     Authentication Pages.  Extended Transports is not shown as
     Authentication with DRIP in that case is covered using Extended
     Wrapper (Section 4.3.2).  Two ASTM Message Packs are sent in a given
     cycle: one containing up to 4 ASTM Messages and an Extended Wrapper
     (authenticating the pack) and one containing a Link message with a
     Broadcast Endorsement and up to two other ASTM Messages.

     This example transmit scheme covers and meets every known regulatory
     case enabling manufacturers to use the same firmware worldwide.









  Wiethuechter, et al.     Expires 24 August 2024                [Page 44]


  Internet-Draft              DRIP Auth Formats              February 2024


           +------------------------------------------------------+
           |                      Frame Slots                     |
           | 00 - 04           | 05 - 07       | 08 - 16 | 17     |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[0] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[1] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[2] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[3] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[4] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[5] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[6] |
           +-------------------+---------------+---------+--------+
           | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[7] |
           +-------------------+---------------+---------+--------+

           A = Basic ID Message (0x0) ID Type 1
           B = Basic ID Message (0x0) ID Type 2
           C = Basic ID Message (0x0) ID Type 3
           D = Basic ID Message (0x0) ID Type 4
           V = Location/Vector Message (0x1)
           I = Self ID Message (0x3)
           S = System Message (0x4)
           O = Operator ID Message (0x5)

           L[y,z] = DRIP Link Authentication Message (0x2)
           W[y,z] = DRIP Wrapper Authentication Message (0x2)
           M[y,z] = DRIP Manifest Authentication Message (0x2)
             y = Start Page
             z = End Page

           # = Empty Frame Slot
           * = Message in DRIP Manifest Authentication Message

        Figure 13: Full Authenticated Legacy Transport Transmit Schedule
                                    Example

     Every common required message (Basic ID, Location and System) is sent
     twice plus Operator ID and Self ID in a single second.  The Manifest
     is over all messages (8) in slots 00 - 04 and 05 - 07.

     In two seconds either a Link or Wrapper are sent.  The content and
     order of Links and Wrappers runs as follows:



  Wiethuechter, et al.     Expires 24 August 2024                [Page 45]


  Internet-Draft              DRIP Auth Formats              February 2024


     Link: HDA on UA
     Link: RAA on HDA
     Link: HDA on UA
     Link: Apex on RAA
     Link: HDA on UA
     Link: RAA on HDA
     Link: HDA on UA
     Wrapper: Location (0x1), System (0x4)
     Link: HDA on UA
     Link: RAA on HDA
     Link: HDA on UA
     Link: Apex on RAA
     Link: HDA on UA
     Link: RAA on HDA
     Link: HDA on UA
     Wrapper: Location (0x1), System (0x4)
     Link: IANA on UAS RID Apex

     With perfect receipt of all messages, in 8 seconds all messages (up
     to that point then all in future) are authenticated using the
     Manifest.  Within 136 seconds the entire Broadcast Endorsement chain
     is received and can be validated; interspersed with 4 messages
     directly signed over via Wrapper.

  B.2.1.  Raw Example

     Assuming the following DET and HI:

     2001:3f:fe00:105:a29b:3ff4:2226:c04e
     b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813

     The following ASTM Messages to be sent in a single second:

     0240012001003ffe000105a29b3ff42226c04e000000000000
     12000000000000000000000000000000000000000060220000
     32004578616d706c652053656c662049440000000000000000
     420000000000000000000100000000000000000010ea510900
     52004578616d706c65204f70657261746f7220494400000000
     0240012001003ffe000105a29b3ff42226c04e000000000000
     12000000000000000000000000000000000000000060220000
     420000000000000000000100000000000000000010ea510900

     This is Link with FEC that would be spread out over 8 seconds:








  Wiethuechter, et al.     Expires 24 August 2024                [Page 46]


  Internet-Draft              DRIP Auth Formats              February 2024


     2250078910ea510904314b8564b17e66662001003ffe000105
     2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7
     2252f5ed0ac08a81975034297bea2b000418132001003ffe00
     22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222
     2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46
     2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94
     2256d9ad97940d280000000000000000000000000000000000
     2257a03b0f7a6feb0d198167045058cfc49f73129917024d22

     This is a Wrapper with FEC that would be spread out over 8 seconds:

     2250078b10ea510902e0dd7c6560115e671200000000000000
     22510000000000000000000000000060220000420000000000
     2252000000000100000000000000000010ea5109002001003f
     2253fe000105a29b3ff42226c04ef0ecad581a030ca790152a
     22542f08df5762a463e24a742d1c530ec977bbe0d113697e2b
     2255b909d6c7557bdaf1227ce86154b030daadda4a6b8474de
     22569a62f6c375020826000000000000000000000000000000
     2257f5e8eebcb04f8c2197526053e66c010d5d7297ff7c1fe0

     This is the Manifest with FEC sent in the same second as the original
     messages:

     225008b110ea510903e0dd7c6560115e670000000000000000
     2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01
     22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928
     22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3
     2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
     22552226c04efb729846e7d110903797066fd96f49a77c5a48
     2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
     22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
     2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83

  Authors' Addresses

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


     Stuart Card
     AX Enterprize, LLC
     4947 Commercial Drive
     Yorkville, NY 13495
     United States of America



  Wiethuechter, et al.     Expires 24 August 2024                [Page 47]


  Internet-Draft              DRIP Auth Formats              February 2024


     Email: stu.card@axenterprize.com


     Robert Moskowitz
     HTT Consulting
     Oak Park, MI 48237
     United States of America
     Email: rgm@labs.htt-consult.com











































  Wiethuechter, et al.     Expires 24 August 2024                [Page 48]


name: draft-ietf-rats-corim
rev: 10
title: Concise Reference Integrity Manifest
time: 2026-03-02T17:26:59Z
group_uri: /api/v1/group/group/2231/
expires: 2026-09-03T17:26:59Z
shepherd: /api/v1/person/email/mcr+ietf@sandelman.ca/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/41/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.234296+00:00
source: ietf
source_id: 110359
source_url: https://datatracker.ietf.org/doc/draft-ietf-rats-corim/
doc_status: active
abstract:
  Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester and therefore to decide
     whether or not to engage in secure interactions with it.  Evidence
     about trustworthiness can be rather complex and it is deemed
     unrealistic that every Relying Party is capable of the appraisal of
     Evidence.  Therefore that burden is typically offloaded to a
     Verifier.  In order to conduct Evidence appraisal, a Verifier
     requires not only fresh Evidence from an Attester, but also trusted
     Endorsements and Reference Values from Endorsers and Reference Value
     Providers, such as manufacturers, distributors, or device owners.
     This document specifies the information elements for representing
     Endorsements and Reference Values in CBOR format.

full_text:
  Remote ATtestation ProcedureS                                H. Birkholz
  Internet-Draft                                            Fraunhofer SIT
  Intended status: Standards Track                              T. Fossati
  Expires: 3 September 2026                                         Linaro
                                                              Y. Deshpande
                                                                       arm
                                                                  N. Smith
                                                               Independent
                                                                    W. Pan
                                                       Huawei Technologies
                                                              2 March 2026


                    Concise Reference Integrity Manifest
                          draft-ietf-rats-corim-10

  Abstract

     Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester and therefore to decide
     whether or not to engage in secure interactions with it.  Evidence
     about trustworthiness can be rather complex and it is deemed
     unrealistic that every Relying Party is capable of the appraisal of
     Evidence.  Therefore that burden is typically offloaded to a
     Verifier.  In order to conduct Evidence appraisal, a Verifier
     requires not only fresh Evidence from an Attester, but also trusted
     Endorsements and Reference Values from Endorsers and Reference Value
     Providers, such as manufacturers, distributors, or device owners.
     This document specifies the information elements for representing
     Endorsements and Reference Values in CBOR format.

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

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




  Birkholz, et al.        Expires 3 September 2026                [Page 1]


  Internet-Draft                    CoRIM                       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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Terminology and Requirements Language . . . . . . . . . .   5
         1.1.1.  Glossary  . . . . . . . . . . . . . . . . . . . . . .   6
     2.  Verifier Reconciliation . . . . . . . . . . . . . . . . . . .   8
       2.1.  Internal Representation . . . . . . . . . . . . . . . . .   9
       2.2.  Interacting with an ACS . . . . . . . . . . . . . . . . .   9
     3.  Typographical Conventions for CDDL  . . . . . . . . . . . . .  10
     4.  Concise Reference Integrity Manifest (CoRIM)  . . . . . . . .  11
       4.1.  CoRIM Map . . . . . . . . . . . . . . . . . . . . . . . .  12
         4.1.1.  CoRIM Identifier  . . . . . . . . . . . . . . . . . .  14
         4.1.2.  Tags  . . . . . . . . . . . . . . . . . . . . . . . .  14
         4.1.3.  Locator Map . . . . . . . . . . . . . . . . . . . . .  14
         4.1.4.  Profile Types . . . . . . . . . . . . . . . . . . . .  14
         4.1.5.  Entities  . . . . . . . . . . . . . . . . . . . . . .  15
       4.2.  Signed CoRIM  . . . . . . . . . . . . . . . . . . . . . .  16
         4.2.1.  Protected Header Map  . . . . . . . . . . . . . . . .  17
         4.2.2.  CWT Claims  . . . . . . . . . . . . . . . . . . . . .  18
         4.2.3.  Meta Map  . . . . . . . . . . . . . . . . . . . . . .  19
         4.2.4.  Unprotected CoRIM Header Map  . . . . . . . . . . . .  19
       4.3.  Signer authority of securely conveyed unsigned CoRIM  . .  20
         4.3.1.  CoRIM collections . . . . . . . . . . . . . . . . . .  20
     5.  Concise Module Identifier (CoMID) . . . . . . . . . . . . . .  23
       5.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  24
         5.1.1.  Tag Identity  . . . . . . . . . . . . . . . . . . . .  25
         5.1.2.  Entities  . . . . . . . . . . . . . . . . . . . . . .  26



  Birkholz, et al.        Expires 3 September 2026                [Page 2]


  Internet-Draft                    CoRIM                       March 2026


         5.1.3.  Linked Tag  . . . . . . . . . . . . . . . . . . . . .  27
         5.1.4.  Triples . . . . . . . . . . . . . . . . . . . . . . .  27
         5.1.5.  Reference Values Triple . . . . . . . . . . . . . . .  41
         5.1.6.  Endorsed Values Triple  . . . . . . . . . . . . . . .  42
         5.1.7.  Conditional Endorsement Triple  . . . . . . . . . . .  43
         5.1.8.  Conditional Endorsement Series Triple . . . . . . . .  44
         5.1.9.  Device Identity Triple  . . . . . . . . . . . . . . .  46
         5.1.10. Attest Key Triple . . . . . . . . . . . . . . . . . .  47
         5.1.11. Triples for domain definitions  . . . . . . . . . . .  48
         5.1.12. CoMID-CoSWID Linking Triple . . . . . . . . . . . . .  50
       5.2.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  51
         5.2.1.  Map Extensions  . . . . . . . . . . . . . . . . . . .  51
         5.2.2.  Data Type Extensions  . . . . . . . . . . . . . . . .  51
     6.  CoTL  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  51
       6.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  52
     7.  Common Types  . . . . . . . . . . . . . . . . . . . . . . . .  53
       7.1.  Non-Empty . . . . . . . . . . . . . . . . . . . . . . . .  53
       7.2.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .  53
       7.3.  Validity  . . . . . . . . . . . . . . . . . . . . . . . .  54
       7.4.  UUID  . . . . . . . . . . . . . . . . . . . . . . . . . .  54
       7.5.  UEID  . . . . . . . . . . . . . . . . . . . . . . . . . .  54
       7.6.  OID . . . . . . . . . . . . . . . . . . . . . . . . . . .  55
       7.7.  Digest  . . . . . . . . . . . . . . . . . . . . . . . . .  55
       7.8.  Tagged Bytes Type . . . . . . . . . . . . . . . . . . . .  55
     8.  Appraisal of CoRIM-based Inputs . . . . . . . . . . . . . . .  55
       8.1.  Appraisal Procedure . . . . . . . . . . . . . . . . . . .  56
     9.  Reference Verifier Sequence . . . . . . . . . . . . . . . . .  57
       9.1.  Processing of Conceptual Messages . . . . . . . . . . . .  59
         9.1.1.  Internal structure of ECT . . . . . . . . . . . . . .  59
         9.1.2.  Common Conventions for Input Transformation . . . . .  60
         9.1.3.  Processing of Evidence  . . . . . . . . . . . . . . .  61
         9.1.4.  Processing of Reference Value Triples . . . . . . . .  62
         9.1.5.  Processing of Endorsed Value Triple, Conditional
                 Endorsement Triple & Conditional Endorsement Series
                 Triples . . . . . . . . . . . . . . . . . . . . . . .  64
         9.1.6.  Processing of Attest Key and Device Identity Key
                 Triples . . . . . . . . . . . . . . . . . . . . . . .  68
         9.1.7.  Processing of Domain Membership Triples . . . . . . .  69
         9.1.8.  Processing of Domain Dependency Triples . . . . . . .  71
       9.2.  Input Validation and Transformation (Phase 1) . . . . . .  73
         9.2.1.  Input Validation  . . . . . . . . . . . . . . . . . .  73
         9.2.2.  Evidence Collection . . . . . . . . . . . . . . . . .  75
         9.2.3.  Input Transformation  . . . . . . . . . . . . . . . .  76
         9.2.4.  Internal Representation of Appraisal Claims Set
                 (ACS) . . . . . . . . . . . . . . . . . . . . . . . .  76
       9.3.  ACS Augmentation - Phases 2, 3, and 4 . . . . . . . . . .  77
         9.3.1.  ACS Requirements  . . . . . . . . . . . . . . . . . .  77
         9.3.2.  Evidence Augmentation (Phase 2) . . . . . . . . . . .  79



  Birkholz, et al.        Expires 3 September 2026                [Page 3]


  Internet-Draft                    CoRIM                       March 2026


         9.3.3.  Reference Values Corroboration and Augmentation (Phase
                 3)  . . . . . . . . . . . . . . . . . . . . . . . . .  80
         9.3.4.  Endorsed Values Augmentation (Phase 4)  . . . . . . .  80
       9.4.  Comparing a condition ECT against the ACS . . . . . . . .  85
         9.4.1.  Comparing a condition ECT against a single ACS
                 entry . . . . . . . . . . . . . . . . . . . . . . . .  85
         9.4.2.  Environment Comparison  . . . . . . . . . . . . . . .  85
         9.4.3.  Authority comparison  . . . . . . . . . . . . . . . .  86
         9.4.4.  Element list comparison . . . . . . . . . . . . . . .  86
         9.4.5.  Element map comparison  . . . . . . . . . . . . . . .  87
         9.4.6.  Measurement values map map Comparison . . . . . . . .  87
         9.4.7.  Profile-directed Comparison . . . . . . . . . . . . .  92
     10. Implementation Status . . . . . . . . . . . . . . . . . . . .  92
       10.1.  Veraison . . . . . . . . . . . . . . . . . . . . . . . .  93
     11. Security and Privacy Considerations . . . . . . . . . . . . .  94
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  95
       12.1.  New COSE Header Parameters . . . . . . . . . . . . . . .  95
       12.2.  New CBOR Tags  . . . . . . . . . . . . . . . . . . . . .  95
       12.3.  CoRIM Map Registry . . . . . . . . . . . . . . . . . . .  97
       12.4.  CoRIM Entity Map Registry  . . . . . . . . . . . . . . .  98
       12.5.  CoRIM Signer Map Registry  . . . . . . . . . . . . . . .  99
       12.6.  CoMID Map Registry . . . . . . . . . . . . . . . . . . . 100
       12.7.  CoMID Entity Map Registry  . . . . . . . . . . . . . . . 101
       12.8.  CoMID Triples Map Registry . . . . . . . . . . . . . . . 102
       12.9.  CoMID Measurement Values Map Registry  . . . . . . . . . 103
       12.10. CoMID Flags Map Registry . . . . . . . . . . . . . . . . 105
       12.11. CoTL Map Registry  . . . . . . . . . . . . . . . . . . . 107
       12.12. New Media Types  . . . . . . . . . . . . . . . . . . . . 107
         12.12.1.  rim+cbor  . . . . . . . . . . . . . . . . . . . . . 108
         12.12.2.  rim+cose  . . . . . . . . . . . . . . . . . . . . . 108
       12.13. CoAP Content-Formats Registration  . . . . . . . . . . . 109
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . . 109
       13.1.  Normative References . . . . . . . . . . . . . . . . . . 109
       13.2.  Informative References . . . . . . . . . . . . . . . . . 112
     Appendix A.  Base CoRIM CDDL  . . . . . . . . . . . . . . . . . . 114
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 126
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 126
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 127

  1.  Introduction

     The RATS Architecture Section 4 of [RFC9334] specifies several roles,
     including Endorsers and Reference Value Providers.  These two roles
     are typically fulfilled by supply chain actors, such as
     manufacturers, distributors, or device owners.  Endorsers and
     Reference Value Providers supply Endorsements (e.g., test results or
     certification data) and Reference Values (e.g., digest ) relating to
     an Attester.  This information is used by a Verifier to appraise



  Birkholz, et al.        Expires 3 September 2026                [Page 4]


  Internet-Draft                    CoRIM                       March 2026


     Evidence received from an Attester which describes Attester
     operational state.

     In a complex supply chain, multiple actors will likely produce these
     values over several points in time.  As such, one supply chain actor
     might only supply a portion of the Reference Values or Endorsements
     that otherwise fully characterizes an Attester.  Ideally, only the
     supply chain actor who is the most knowledgable entity regarding a
     particular component will supply Reference Values or Endorsements for
     that component.

     Attesters vary across vendors and even across products from a single
     vendor.  Not only Attesters can evolve and therefore new measurement
     types need to be expressed, but an Endorser may also want to provide
     new security relevant attributes about an Attester at a future point
     in time.

     In order to promote inter-operability, consistency and accuracy in
     the representation of Endorsements and Reference Values this document
     specifies a data model for Endorsements and Reference Values known as
     Concise Reference Integrity Manifests (CoRIM).  The CoRIM data model
     is expressed in CDDL which is used to realize a CBOR [STD94] encoding
     suitable for cryptographic operations (e.g., hashing, signing,
     encryption) and transmission over computer networks.  Additionally,
     this document describes multiple phases of a Verifier Appraisal and
     provides an example of a possible use of CoRIM messages from multiple
     supply chain actors to represent a homogeneous representation of
     Attester state.  CoRIM is extensible to accommodate supply chain
     diversity while supporting a common representation for Endorsement
     and Reference Value inputs to Verifiers.  See Section 2.

  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.  Specifically the terms Attester, Reference Value
     Provider, Endorser, Verifier Owner, and Relying Party are taken from
     Section 4 of [RFC9334].

     For a complete glossary, see Section 4 of [RFC9334].

     This document uses the terms _"actual state"_ and _"reference state"_
     as defined in Section 2 of [I-D.ietf-rats-endorsements].



  Birkholz, et al.        Expires 3 September 2026                [Page 5]


  Internet-Draft                    CoRIM                       March 2026


     In this document, the term CoRIM message and CoRIM documents are used
     as synonyms.  A CoRIM data structure can be at rest (e.g., residing
     in a file system as a document) or can be in flight (e.g., conveyed
     as a message in a protocol exchange).  The bytes composing the CoRIM
     data structure are the same either way.

     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.

  1.1.1.  Glossary

     This document uses the following terms:

     Appraisal Claims Set (ACS):
        A structure that holds Environment-Claim Tuples that have been
        appraised.  The ACS contains Attester state that has been
        authorized by Verifier processing and Appraisal Policy.

     Appraisal Policy:
        A description of the conditions that, if met, allow appraisal of
        Claims.  Typically, the entity asserting a Claim should have
        knowledge, expertise, or context that gives credibility to the
        assertion.  Appraisal Policy resolves which entities are credible
        and under what conditions.  See also "Appraisal Policy for
        Evidence" in [RFC9334].

     Attestation Results Set (ARS):
        A structure that holds results of appraisal and Environment-Claim
        Tuples that are used to construct an Attestation Results message
        that is conveyed to a Relying Party.

     Authority:
        The entity asserting that a Claim is true.  Typically, a Claim is
        asserted using a cryptographic key to digitally sign the Claim.  A
        cryptographic key can be a proxy for a human or organizational
        entity.

     Claim:
        A piece of information, in the form of a key-value pair.  See also
        Section 4.2 of [RFC9334] and Section 2 of [RFC7519].

     Class ID:
        An identifier for an Environment that is shared among similar
        Environment instances, such as those with the same hardware
        assembly.  See also Section 4.2.4 of [RFC9711].




  Birkholz, et al.        Expires 3 September 2026                [Page 6]


  Internet-Draft                    CoRIM                       March 2026


     Composite Attester:
        A Composite Attester is either a Composite Device (Section 3.3 of
        [RFC9334]) or a Layered Attester (Section 3.2 of [RFC9334]) or any
        composition involving a combination of one or more Composite
        Devices or Layered Attesters.

     Domain:
        A domain is a hierarchical description of a Composite Attester in
        terms of its constituent Environments and their compositional
        relationships.

     Endorsed values:
        A set of characteristics of an Attester that do not appear in
        Evidence.  For example, Endorsed Values may include testing or
        certification data related to a hardware or firmware module.
        Endorsed Values are said to be "conditional" when they apply if
        Attester's actual state matches Verifier's accepted Claims.  See
        also Section 3 of [I-D.ietf-rats-endorsements].

     Environment:
        A logical partition within an Attester.  The term "Target
        Environment" refers to the group of system security metrics that
        are reported through Evidence.  The term "Attesting Environment"
        refers to the entity that collects and cryptographically signs
        such security metrics.  See also Section 3.1 of [RFC9334].

     Environment-Claim Tuple (ECT):
        A structure containing a set of values that describe a Target
        Environment plus a set of Measurement / Claim values that describe
        properties of the Target Environment.  The ECT also contains
        Authority which identifies the entity that authored the ECT.

     Instance ID:
        An identifier of an Environment that is unique to that Environment
        instance, such as the serial number of a hardware module.  See
        also Section 4.2.1 of [RFC9711].

     Measurement:
        A value associated with specific security characteristics of an
        Attester that influences the trustworthiness of that Attester.
        The object of a Measurement could be the invariant part of a
        firmware component loaded into memory during startup, a run-time
        integrity check (RTIC), a file system object, or a CPU register.
        A measured object is part of the Attester's Target Environment.
        Expected, or "golden," Measurements are compiled as Reference
        Values, which are used by the Verifier to assess the trust state
        of the Attester.  See also [TNC.Arch], and Section 9.5.5 of
        [TPM2.Part1].



  Birkholz, et al.        Expires 3 September 2026                [Page 7]


  Internet-Draft                    CoRIM                       March 2026


     Reference Values:
        A set of values that represent the desired or undesired state of
        an Attester.  Reference Values are compared against Evidence to
        determine whether Attester state is corroborated by a Reference
        Value Provider.  Reference Values with matching Evidence produce
        "acceptable Claims."  See also Section 4.2 of [RFC9334],
        Section 8.3 of [RFC9334], and Section 2 of
        [I-D.ietf-rats-endorsements].

     Triple:
        A term derived from the Resource Description Framework (RDF) to
        mean a statement expressing a relationship between a subject and
        an object resource.  The nature of the relationship between
        subject and object is expressed via a predicate.  In CoRIM, unlike
        RDF, the predicate of the triple is implicit and is encoded in the
        triple's name/codepoint.  CoRIM triples typically represent
        assertions made by the CoRIM author regarding Attesting or Target
        Environments and their security features, such as Measurements and
        cryptographic key material.  See also Section 3.1 of
        [W3C.rdf11-primer].

  2.  Verifier Reconciliation

     This specification describes the CoRIM format and documents how a
     Verifier must process the CoRIM.  This ensures that the behaviour of
     the CoRIM-based appraisal is predictable and consistent, in a word
     deterministic.

     A Verifier needs to reconcile its various inputs, with CoRIM being
     one of them.  In addition to the external CoRIM documents, the
     Verifier is expected to create an internal representation for each
     input and map each external representation to an internal one.  By
     using the internal representation, the Verifier processes inputs as
     if they are part of a conversation, keeping track of who said what.
     The origin of the inputs is tracked as _authority_. The authority for
     the Claims in a CoRIM is the CoRIM issuer.  To this effect, this
     specification defines one possible internal representation of the
     attester's actual state for use during the appraisal procedure, known
     as Appraisal Claims Set (ACS).

     Effectively, Attesters, Reference Value Providers, Endorsers,
     Verifier Owners, Relying Parties, and even the Verifier potentially
     all contribute to the conversation.  Each producer of corresponding
     RATS Conceptual Messages can assert Claims about an Attester's actual
     or allowed state.  The Verifier's objective is to produce a list of
     Claims that describe the Attester's presumed actual state.  Producers
     of RATS Conceptual Messages can assert contradictory assertions.  For
     example, a compromised Attester may produce false claims that



  Birkholz, et al.        Expires 3 September 2026                [Page 8]


  Internet-Draft                    CoRIM                       March 2026


     conflict with the Reference Values provided by a Reference Value
     Provider (RVP).  In essence, if Evidence is not corroborated by an
     RVP's Claims, then the RVP's Claims are not included in the ACS.
     Please see Figure 1.

     A Verifier relies on input from appraisal policy to identify relevant
     assertions included in the ACS.  For example, if a policy requires
     corroborated assertions issued by a particular RVP, then those
     assertions may be conveyed as Attestation Results.  The Verifier may
     produce new assertions as a result of an applied appraisal policy.
     For example, if an appraisal procedure finds all of the components of
     a subsystem are configured correctly, the policy may direct the
     Verifier to produce new assertions, "Subsystem=X" has the Claim
     "TRUSTED=TRUE".  Consequently, the internal ACS structure is a
     reconciled conversation between several producers of RATS Conceptual
     Messages that has mapped each message into a consistent internal
     representation, has associated the identity of the corresponding RATS
     role with each assertion (the authority), and has applied Conceptual
     Message constraints to the assertion.

     The CoRIM data model specified in this document covers the RATS
     Conceptual Message types, "Reference Values" and "Endorsements".
     Reference values and Endorsements are required for Verifier
     reconciliation, and Evidence is required for corresponding internal
     ACS creation as illustrated in Section 2.2.

  2.1.  Internal Representation

     In this document CDDL is used to specify both the CoRIM structure and
     to specify an internal representation for use in the appraisal
     procedure.  The actual internal representation of a Verifier is
     implementation-specific and out-of-scope of this document.
     Requirements for an internal representation of Conceptual Messages
     are defined in Table 1, where each Conceptual Message type has a
     structure as depicted by the _Structure_ column.  The internal
     representations used by this document are defined in Section 9.1.

  2.2.  Interacting with an ACS

     Conceptual Messages interact with an ACS by specifying criteria that
     should be met by the ACS and by presenting the assertions that should
     be added to the ACS if the criteria are satisfied.  The processing
     sequence of Conceptual Message interaction with ACS is guided by
     Section 8.1.

     The internal representations of Conceptual Messages and ACS SHOULD
     satisfy the requirements in Table 1 for Verifier reconciliation and
     appraisal processing:



  Birkholz, et al.        Expires 3 September 2026                [Page 9]


  Internet-Draft                    CoRIM                       March 2026


     +==============+====================+==============================+
     | CM Type      | Structure          | Description                  |
     +==============+====================+==============================+
     | Evidence     | List of Evidence   | If the Attester is           |
     |              | claims             | authenticated, add Evidence  |
     |              |                    | claims to the ACS with       |
     |              |                    | Attester authority           |
     +--------------+--------------------+------------------------------+
     | Reference    | List of Reference  | If a reference value in a    |
     | Values       | Values claims      | CoRIM matches claims in the  |
     |              |                    | ACS, then the authority of   |
     |              |                    | the CoRIM issuer is added to |
     |              |                    | those claims.                |
     +--------------+--------------------+------------------------------+
     | Endorsements | List of expected   | If the list of expected      |
     |              | actual state       | claims are in the ACS, then  |
     |              | claims, List of    | add the list of Endorsed     |
     |              | Endorsed Values    | Values claims to the ACS     |
     |              | claims             | with Endorser authority      |
     +--------------+--------------------+------------------------------+
     | Series       | List of expected   | If the expected claims are   |
     | Endorsements | actual state       | in the ACS, and if the       |
     |              | claims and a       | series selection condition   |
     |              | series of          | is satisfied, then add the   |
     |              | selection-addition | additional claims to the ACS |
     |              | tuples             | with Endorser authority.     |
     |              |                    | See Section 9.1.5.1          |
     +--------------+--------------------+------------------------------+

           Table 1: Conceptual Message Representation Requirements

  3.  Typographical Conventions for CDDL

     The CDDL definitions in this document follows the naming conventions
     illustrated in Table 2.
















  Birkholz, et al.        Expires 3 September 2026               [Page 10]


  Internet-Draft                    CoRIM                       March 2026


     +========================+===============+==========================+
     | Type trait             | Example       | Typographical convention |
     +========================+===============+==========================+
     | extensible             | int / text /  | $NAME-type-choice        |
     | type choice            | ...           |                          |
     +------------------------+---------------+--------------------------+
     | closed type            | int / text    | NAME-type-choice         |
     | choice                 |               |                          |
     +------------------------+---------------+--------------------------+
     | group                  | ( 1 => int // | $$NAME-group-choice      |
     | choice                 | 2 => text )   |                          |
     +------------------------+---------------+--------------------------+
     | group                  | ( 1 => int, 2 | NAME-group               |
     |                        | => text )     |                          |
     +------------------------+---------------+--------------------------+
     | type                   | int           | NAME-type                |
     +------------------------+---------------+--------------------------+
     | tagged type            | #6.123(int)   | tagged-NAME-type         |
     +------------------------+---------------+--------------------------+
     | map                    | { 1 => int, 2 | NAME-map                 |
     |                        | => text }     |                          |
     +------------------------+---------------+--------------------------+
     | flags                  | &( a: 1, b: 2 | NAME-flags               |
     |                        | )             |                          |
     +------------------------+---------------+--------------------------+

               Table 2: Type Traits and Typographical Conventions

  4.  Concise Reference Integrity Manifest (CoRIM)

     A CoRIM is a collection of tags and related metadata in a concise
     CBOR [STD94] encoding.  A CoRIM can be digitally signed with a COSE
     [STD96] signature.  A tag is a structured, machine-readable data
     format used to uniquely identify, describe, and manage modules or
     components of a system.

     Tags can be of different types:

     *  Concise Module ID (CoMID) tags (Section 5) contain metadata and
        claims about the hardware and firmware modules.

     *  Concise Software ID (CoSWID) tags ([RFC9393]) are used to
        identify, describe and manage software components.

     *  Concise Tag List (CoTL) tags (Section 6) contain the list of CoMID
        and CoSWID tags that the Verifier should consider as "active" at a
        certain point in time.




  Birkholz, et al.        Expires 3 September 2026               [Page 11]


  Internet-Draft                    CoRIM                       March 2026


     CoRIM allows for new types of tags to be added in future
     specifications.  For example, Concise Trust Anchor Stores (CoTS)
     ([I-D.ietf-rats-concise-ta-stores]) is currently being defined as a
     standard CoRIM extension.

     Each CoRIM contains a unique identifier to distinguish a CoRIM from
     other CoRIMs.

     CoRIM can also carry the following optional metadata:

     *  A locator, which allows discovery of possibly related RIMs.

     *  A profile identifier, which is used to interpret the information
        contained in the enclosed tags.  A profile allows the base CoRIM
        CDDL definition to be customized to fit a specific Attester by
        augmenting the base CDDL data definition via the specified
        extension points or by constraining types defined.  A profile MUST
        NOT change the base CoRIM CDDL definition's semantics, which
        includes not changing or overloading names and numbers registered
        at IANA registries used by this document.  For more detail, see
        Section 4.1.4.

     *  A validity period, which indicates the time period for which the
        CoRIM contents are valid.

     *  Information about the supply chain entities responsible for the
        contents of the CoRIM and their associated roles.

     A CoRIM can be signed (Section 4.2) using COSE Sign1 to provide end-
     to-end security to the CoRIM contents.  When CoRIM is signed, the
     protected header carries further identifying information about the
     CoRIM signer.  Alternatively, CoRIM can be encoded as a #6.501 CBOR-
     tagged payload (Section 4.1) and transported over a secure channel.

     The following CDDL describes the top-level CoRIM.

     corim = concise-rim-type-choice

     concise-rim-type-choice /= tagged-unsigned-corim-map
     concise-rim-type-choice /= signed-corim

  4.1.  CoRIM Map

     The CDDL specification for the corim-map is as follows and this rule
     and its constraints MUST be followed when creating or validating a
     CoRIM map.





  Birkholz, et al.        Expires 3 September 2026               [Page 12]


  Internet-Draft                    CoRIM                       March 2026


     corim-map = {
       &(id: 0) => $corim-id-type-choice
       &(tags: 1) => [ + $concise-tag-type-choice ]
       ? &(dependent-rims: 2) => [ + corim-locator-map ]
       ? &(profile: 3) => $profile-type-choice
       ? &(rim-validity: 4) => validity-map
       ? &(entities: 5) => [ + corim-entity-map ]
       * $$corim-map-extension
     }
     unsigned-corim-map = corim-map

     The following describes each child item of this map.

     *  id (index 0): A globally unique identifier to identify a CoRIM.
        Described in Section 4.1.1.

     *  tags (index 1): An array of one or more CoMID, CoSWID or CoTL
        tags.  Described in Section 4.1.2.

     *  dependent-rims (index 2): One or more services supplying
        additional, possibly dependent, manifests or related files.
        Described in Section 4.1.3.

     *  profile (index 3): An optional profile identifier for the tags
        contained in this CoRIM.  The profile MUST be understood by the
        CoRIM processor.  Failure to recognize the profile identifier MUST
        result in the rejection of the entire CoRIM.  See Section 4.1.4

     *  rim-validity (index 4): Specifies the validity period of the
        CoRIM.  Described in Section 7.3.

     *  entities (index 5): A list of entities involved in a CoRIM life-
        cycle.  Described in Section 4.1.5.

     *  $$corim-map-extension: This CDDL socket is used to add new
        information structures to the corim-map.  Described in
        Section 12.3.

     A corim-map is unsigned, and its tagged form is an entrypoint for
     parsing a CoRIM, so it is named tagged-unsigned-corim-map. ~~~ cddl
     tagged-unsigned-corim-map = #6.501(unsigned-corim-map) ~~~










  Birkholz, et al.        Expires 3 September 2026               [Page 13]


  Internet-Draft                    CoRIM                       March 2026


  4.1.1.  CoRIM Identifier

     A CoRIM Identifier uniquely identifies a CoRIM instance within the
     context of a CoRIM issuer.  In other words the CoRIM identifier is
     not guaranteed to be globally unique, but can be used to distinguish
     CoRIMs that come from the same issuer.  The base CDDL definition
     allows UUID and text identifiers.  Other types of identifiers could
     be defined as needed.

     $corim-id-type-choice /= tstr
     $corim-id-type-choice /= uuid-type

  4.1.2.  Tags

     A $concise-tag-type-choice is a tagged CBOR payload that carries
     either a CoMID (Section 5), a CoSWID ([RFC9393]), or a CoTL
     (Section 6).

     $concise-tag-type-choice /= tagged-concise-swid-tag
     $concise-tag-type-choice /= tagged-concise-mid-tag
     $concise-tag-type-choice /= tagged-concise-tl-tag

  4.1.3.  Locator Map

     The locator map contains pointers to repositories where dependent
     manifests, certificates, or other relevant information can be
     retrieved by the Verifier.

     ;# import measured-component as eatmc

     corim-locator-map = {
       &(href: 0) => uri / [ + uri ]
       ? &(thumbprint: 1) => eatmc.digest / [ eatmc.digest ]
     }

     The following describes each child element of this type.

     *  href (index 0): a URI or array of alternative URIs identifying
        locations where the additional resource can be fetched.

     *  thumbprint (index 1): expected digest or an array of digests
        referenced by href or an array of hrefs.  See sec-common-hash-
        entry}}.

  4.1.4.  Profile Types

     Profiling is the mechanism that allows the base CoRIM CDDL definition
     to be customized to fit a specific Attester.



  Birkholz, et al.        Expires 3 September 2026               [Page 14]


  Internet-Draft                    CoRIM                       March 2026


     A profile defines which of the optional parts of a CoRIM are
     required, which are prohibited and which extension points are
     exercised and how.  A profile MUST NOT alter the syntax or semantics
     of CoRIM types defined in this document.

     A profile MAY constrain the values of a given CoRIM type to a subset
     of the values.  A profile MAY extend the set of a given CoRIM type
     using the defined extension points (Section 5.2).  Exercised
     extension points SHOULD preserve the intent of the original
     semantics.

     CoRIM profiles SHOULD be specified in a publicly available document.

     A CoRIM profile can use one of the base CoRIM media type defined in
     Section 12.12.1 with the profile parameter set to the appropriate
     value.  Alternatively, it MAY define and register its own media type.

     A profile identifier is either an OID [RFC9090] or a URL [STD66].

     The profile identifier uniquely identifies a documented profile.  Any
     changes to the profile, even the slightest deviation, is considered a
     different profile that MUST have a different identifier.

     The CoRIM profile must describe at a minimum the following: (a) how
     cryptographic verification key material is represented (e.g., using
     Attestation Keys triples, or CoTS tags), and (b) how key material is
     associated with the Attesting Environment.  The CoRIM profile should
     also specify whether CBOR deterministic encoding is required.

     $profile-type-choice /= uri
     $profile-type-choice /= tagged-oid-type

     For an example profile definition, see
     [I-D.fdb-rats-psa-endorsements].

  4.1.5.  Entities

     The CoRIM Entity is an instantiation of the Entity generic
     (Section 7.2) using a $corim-role-type-choice.

     The only role defined in this specification for a CoRIM Entity is
     manifest-creator.

     The $$corim-entity-map-extension extension socket is empty in this
     specification.






  Birkholz, et al.        Expires 3 September 2026               [Page 15]


  Internet-Draft                    CoRIM                       March 2026


     corim-entity-map =
       entity-map<$corim-role-type-choice, $$corim-entity-map-extension>

     $corim-role-type-choice /= &(manifest-creator: 1)
     $corim-role-type-choice /= &(manifest-signer: 2)

     The corim-entity-map MUST NOT contain two entities with the manifest-
     signer role.

  4.2.  Signed CoRIM

     signed-corim = #6.18(COSE-Sign1-corim)

     Signing a CoRIM follows the procedures defined in CBOR Object Signing
     and Encryption [STD96].  A CoRIM tag MUST be wrapped in a COSE_Sign1
     structure.  The CoRIM MUST be signed by the CoRIM creator.

     The following CDDL specification defines a restrictive subset of COSE
     header parameters that MUST be used in the protected header alongside
     additional information about the CoRIM encoded in a corim-meta-map
     (Section 4.2.3) or alternatively in a CWT-Claims ([RFC9597]).

     COSE-Sign1-corim = [
       protected: bstr .cbor protected-corim-header-map
       unprotected: unprotected-corim-header-map
       payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-digest / nil
       signature: bstr
     ]

     hash-envelope-digest = bstr

     The following describes each child element of this type.

     *  protected: A CBOR Encoded protected header which is protected by
        the COSE signature.  Contains information as given by Protected
        Header Map below.

     *  unprotected: A COSE header that is not protected by COSE
        signature.

     *  payload: When the payload is signed directly, either a CBOR-
        encoded tagged CoRIM, or nil if it is detached.  When the payload
        is signed indirectly, the digest of a CBOR-encoded tagged CoRIM.

     *  signature: A COSE signature block, as defined in Section 4 of
        [STD96].





  Birkholz, et al.        Expires 3 September 2026               [Page 16]


  Internet-Draft                    CoRIM                       March 2026


  4.2.1.  Protected Header Map

     ; protected corim header map needs to contain at least one of corim-meta (8) or CWT-Claims (15)
     protected-corim-header-map = protected-corim-header-map-inline / protected-corim-header-map-hash-envelope

     protected-corim-header-map-inline =
       {
         &(alg: 1) => int,
         &(content-type: 3) => "application/rim+cbor",
         meta-group,
         * cose-label => cose-value
       }

     protected-corim-header-map-hash-envelope =
       {
         &(alg: 1) => int,
         &(payload_hash_alg: 258) => int
         &(payload_preimage_content_type: 259) => "application/rim+cbor",
         ? &(payload_location: 260) => tstr
         meta-group,
         * cose-label => cose-value
       }

     meta-group = ((
             corim-meta-identity,
             ? cwt-claims-identity,
           ) // cwt-claims-identity)

     corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim-meta-map)
     cwt-claims-identity = (&(CWT-Claims: 15) => cwt-claims)

     The CoRIM protected header map uses some common COSE header
     parameters plus additional metadata.  Additional metadata can either
     be carried in a CWT_Claims (index: 15) parameter as defined by
     [RFC9597], or in a corim-meta map as a legacy alternative, described
     in Section 4.2.3.

     The following describes each child item of this map.

     *  alg (index 1): An integer that identifies a signature algorithm.

     Either, when the payload is signed directly:

     *  content-type (index 3): A string that represents the "MIME Content
        type" carried in the CoRIM payload.

     Or, when the payload is signed indirectly using a Hash Envelope
     ([I-D.ietf-cose-hash-envelope]):



  Birkholz, et al.        Expires 3 September 2026               [Page 17]


  Internet-Draft                    CoRIM                       March 2026


     *  payload_hash_alg (index 258): The hash algorithm used to produce
        the payload.

     *  payload_preimage_content_type (index 259): A string that
        represents the "MIME Content type" of the CoRIM document used as
        the pre-image of the payload.

     *  payload_location (index 260): An optional identifier enabling
        retrieval of the original resource (preimage) identified by the
        payload.

     At least one of:

     *  CWT-Claims (index 15): A map that contains metadata associated
        with a signed CoRIM.  Described in [RFC9597].

     *  corim-meta (index 8): A map that contains metadata associated with
        a signed CoRIM.  Described in Section 4.2.3.

     Documents MAY include both CWT-Claims and corim-meta, in which case
     the signer MUST ensure that their contents are semantically
     identical: the CWT-Claims issuer (iss) MUST have the same value as
     signer-name in corim-meta, and the nbf and exp values in the CWT-
     Claims MUST match the signature-validity in corim-meta.

     Additional data can be included in the COSE header map as per
     (Section 3 of [STD96]).

  4.2.2.  CWT Claims

     The CWT Claims ([RFC9597]) map identifies the entity that created and
     signed the CoRIM.  This ensures the consumer is able to identify
     credentials used to authenticate its signer.  To avoid any possible
     ambiguity with the contents of the CoRIM tags, the CWT Claims map
     MUST NOT contain claims that have semantic overlap with the
     information contained in CoRIM tags.

     The following describes each child item of this group.

     *  iss (index 1): Issuer or signer for the CoRIM, formerly signer-
        name or signer-uri in Section 4.2.3.1.

     *  sub (index 2): Optional - identifies the CoRIM document,
        equivalent to a string representation of $corim-id-type-choice

     Additional data can be included in the CWT Claims, as per [RFC8392],
     such as:




  Birkholz, et al.        Expires 3 September 2026               [Page 18]


  Internet-Draft                    CoRIM                       March 2026


     *  exp (index 4): Expiration time, formerly signature-validity in
        Section 7.3.

     *  nbf (index 5): Not before time, formerly signature-validity in
        Section 7.3.

  4.2.3.  Meta Map

     The CoRIM meta map identifies the entity or entities that create and
     sign the CoRIM.  This ensures the consumer is able to identify
     credentials used to authenticate its signer.

     corim-meta-map = {
       &(signer: 0) => corim-signer-map
       ? &(signature-validity: 1) => validity-map
     }

     The following describes each child item of this group.

     *  signer (index 0): Information about the entity that signs the
        CoRIM.  Described in Section 4.2.3.1.

     *  signature-validity (index 1): Validity period for the CoRIM.
        Described in Section 7.3.

  4.2.3.1.  Signer Map

     corim-signer-map = {
       &(signer-name: 0) => $entity-name-type-choice
       ? &(signer-uri: 1) => uri
       * $$corim-signer-map-extension
     }

     *  signer-name (index 0): Name of the organization that performs the
        signer role

     *  signer-uri (index 1): A URI identifying the same organization

     *  $$corim-signer-map-extension: Extension point for future expansion
        of the Signer map.

  4.2.4.  Unprotected CoRIM Header Map

     unprotected-corim-header-map = {
       * cose-label => cose-value
     }





  Birkholz, et al.        Expires 3 September 2026               [Page 19]


  Internet-Draft                    CoRIM                       March 2026


  4.3.  Signer authority of securely conveyed unsigned CoRIM

     An unsigned (#6.501-tagged) CoRIM may be a payload in an enveloping
     signed document, or it may be conveyed unsigned within the protection
     scope of a secure channel.  The CoRIM signer authority is taken from
     the authenticated credential (e.g., OAUTH token) of the entity that
     originates the CoRIM.  For example, this entity could be the sending
     peer in a secure channel.  A CoRIM role entry expressing the origin
     of the unsigned CoRIM (i.e., the enveloping signed document or the
     origin endpoint of the secure channel) via the manifest-signer role
     MUST be added to corim-entity-map.  If the authority cannot be
     expressed directly via the existing authority types, the receiver
     SHOULD establish a local authority in one of the supported authority
     formats (e.g., if an unsigned CoRIM is received over a secure channel
     where authentication is token- or password-based).  If it is
     impossible to assert the authority of the origin, the Verifier's
     appraisal policy MAY assert the Verifier’s authority as the CoRIM
     origin.

     It is out of scope of this document to specify a method of delegating
     the signer role in the case that an unsigned CoRIM is conveyed
     through multiple secured links with different notions of authenticity
     without end-to-end integrity protection.

  4.3.1.  CoRIM collections

     Several CoRIMs may share the same signer (e.g., as collection payload
     in a different signed message) and use locally-resolvable references
     to each other, for example using a RATS Conceptual Message Wrapper
     (CMW) [I-D.ietf-rats-msg-wrap].  The Collection CMW type is similar
     to a profile in its way of restricting the shape of the CMW
     collection.  The Collection CMW type for a CoRIM collection SHALL be
     tag:{{&SELF}}:corim.

     A COSE_Sign1-signed CoRIM Collection CMW has a similar requirement to
     a signed CoRIM.  The signing operation MUST include either a CWT-
     Claims or a corim-meta and MAY contain both, in the COSE_Sign1
     protected-header parameter.  These metadata containers ensure that
     each CoRIM in the collection has an identified signer.  The COSE
     protected header can include a Collection CMW type name by using the
     cmwc_t content type parameter for the &(content-type: 3) COSE header,
     or &(payload_preimage_content_type: 259) in the case of hash
     envelopes.

     If using other signing envelope formats, the CoRIM signing authority
     MUST be specified.  For example, this can be accomplished by adding
     the manifest-signer role to every CoRIM, or by using a protected
     header analogous to corim-meta.



  Birkholz, et al.        Expires 3 September 2026               [Page 20]


  Internet-Draft                    CoRIM                       March 2026


     corim-cbor-collection = {
       "__cmwc_t" => "tag:{{&SELF}}:corim",
       + cmw-label => [TBD1, bytes .cbor tagged-corim-map]
     }
     cmw-label = text / int

     The Collection CMW MAY use any label for its CoRIMs.  If there is a
     hierarchical structure to the CoRIM Collection CMW, the base entry
     point SHOULD be labeled 0 in CBOR or "base" in JSON.  It is
     RECOMMENDED to label a CoRIM with its tag-id in string format, where
     uuid-type string format is specified by [RFC9562].  CoRIMs
     distributed in a CoRIM Collection CMW MAY declare their
     interdependence dependent-rims with local resource indicators.  It is
     RECOMMENDED that a CoRIM with a uuid-type tag-id be referenced with
     URI urn:uuid:_tag-id-uuid-string_. It is RECOMMENDED that a CoRIM
     with a tstr tag-id be referenced with tag:{{&SELF}}:local,_tag-id-
     tstr_. It is RECOMMENDED for a corim-locator-map containing local
     URIs to afterwards list a nonzero number of reachable URLs as remote
     references.

     The following example demonstrates these recommendations for bundling
     CoRIMs with a common signer but have different profiles.





























  Birkholz, et al.        Expires 3 September 2026               [Page 21]


  Internet-Draft                    CoRIM                       March 2026


     =============== NOTE: '\' line wrapping per RFC 8792 ================

     / cbor-collection / {
       "__cmwc_t": "tag:{{&SELF}}:corim",
       "adee8cd4-4e47-461f-b341-2aba3ae4cbda":
         / cbor-cmw / [TBD1, << / tagged-corim-map / 501({
           / id / 0: h'adee8cd44e47461fb3412aba3ae4cbda',
           / tags / 1: [/ tagged-concise-mid-tag / 506(<<{
             / tag-identity / 1: {
               / tag-id / 0: h'315cfc0208d548ee9c89906df96e7fb8'
             },
             / triples / 4: {
               / reference-triples / 0: [[
                 / ref-env / {/ class / 0: {/ class-id / 0: 560(h'c0de')}\
                                                                        },
                 / ref-claims / {
                   / mval / 1: {
                     / profile-foo / -404:
                       h'\
                       6094685f8bb9b67daaf35707bd2c391f536a1df2ce5152c3cc'
                   }}]],
               / coswid-triples / 6: [[
                 {/ class / 0: {/ class-id / 0: 560(h'c0de')}},
                 [h'369a6688451240b9b74905b1dd5fae9f']]]}}>>)],
           / profile / 3: "tag:example.com,2025/example-profile",
           / dependent-rims / 2: [{
             / href / 0: [
               "urn:uuid:51a5f633-71c0-45f5-855e-43e8254c1806",
               "https://example.com/369a6688451240b9b74905b1dd5fae9f.\
                                                                    corim"
             ]}]}) >>],
       "51a5f633-71c0-45f5-855e-43e8254c1806":
         / cbor-cmw / [TBD1, << / tagged-corim-map / 501({
           / id: / 0: h'51a5f63371c045f5855e43e8254c1806',
           / tags / 1: [/ tagged-concise-swid-tag / 505(<<{
               / tag-id / 0: h'369a6688451240b9b74905b1dd5fae9f',
               / tag-version / 12: 2,
               / software-name / 1: "Gadget Firmware",
               / entity / 2: {
                 / entity-name / 31: "ACME Firmware",
                 / role / 33: / software-creator / 2
               },
               / profile-bar / 4294967295: {
                / profile-baz / 0: 5,
                / profile-qux / 1: h'f76e41f3462a62e8'}}>>)],
           / profile / 3: "tag:example.com,2025/software-profile"})>>]
     }




  Birkholz, et al.        Expires 3 September 2026               [Page 22]


  Internet-Draft                    CoRIM                       March 2026


  5.  Concise Module Identifier (CoMID)

     A CoMID tag contains information about hardware, firmware, or module
     composition.

     Each CoMID has a unique ID that is used to unambiguously identify
     CoMID instances when cross referencing CoMID tags, for example in
     typed link relations, or in a CoTL tag.

     A CoMID defines several types of Claims, using "triples" semantics.

     At a high level, a triple is a statement that links a subject to an
     object via a predicate.  CoMID triples typically encode assertions
     made by the CoRIM author about Attesting or Target Environments and
     their security features, for example measurements, cryptographic key
     material, etc.

     This specification defines two classes of triples, the Mandatory To
     Implement (MTI) and the Optional To Implement (OTI).  The MTI triples
     are essential to basic appraisal processing as illustrated in
     [RFC9334] and [I-D.ietf-rats-endorsements].  Every CoRIM Verifier
     MUST implement the MTI triples.  The OTI class of triples are
     generally useful across profiles.  A CoRIM Verifier SHOULD implement
     OTI triples.  Verifiers may be constrained in various ways that may
     make implementation of the OTI class infeasible or unnecessary.  For
     example, deployment environments may have constrained resources,
     limited code size, or limited scope Attesters.

     MTI Triples:

     *  Reference Values triples: containing Reference Values that are
        expected to match Evidence for a given Target Environment
        (Section 5.1.5).

     *  Endorsed Values triples: containing "Endorsed Values", i.e.,
        features about an Environment that do not appear in Evidence.
        Specific examples include testing or certification data pertaining
        to a module (Section 5.1.6).

     *  Conditional Endorsement triples: describing one or more conditions
        that, once matched, result in augmenting the Attester's actual
        state with the supplied Endorsed Values (Section 5.1.7).

     OTI Triples:

     *  Conditional Endorsement Series triples: describing conditional
        endorsements that are evaluated using a special matching algorithm
        (Section 5.1.7).



  Birkholz, et al.        Expires 3 September 2026               [Page 23]


  Internet-Draft                    CoRIM                       March 2026


     *  Device Identity triples: containing cryptographic credentials -
        for example, an IDevID - uniquely identifying a device
        (Section 5.1.9).

     *  Attestation Key triples: containing cryptographic keys that are
        used to verify the integrity protection on the Evidence received
        from the Attester (Section 5.1.10).

     *  Domain dependency triples: describing trust relationships between
        domains, i.e., collection of related environments and their
        measurements (Section 5.1.11.2).

     *  Domain membership triples: describing topological relationships
        between (sub-)modules.  For example, in a composite Attester
        comprising multiple sub-Attesters (sub-modules), this triple can
        be used to define the topological relationship between lead- and
        sub- Attester environments (Section 5.1.11.1).

     *  CoMID-CoSWID linking triples: associating a Target Environment
        with existing CoSWID Payload tags (Section 5.1.12).

     CoMID triples are extensible (Section 5.1.4).  Triples added via the
     extensibility feature MUST be OTI class triples.  This document
     specifies profiles (see Section 5.2).  OTI triples MAY be
     reclassified as MTI using a profile.  Conversely, profiles can choose
     not to _use_ certain MTI triples.  Profiles MUST NOT reclassify MTI
     triples as OTI.

  5.1.  Structure

     The CDDL specification for the concise-mid-tag map is as follows and
     this rule and its constraints MUST be followed when creating or
     validating a CoMID tag:

     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
     }

     The following describes each member of the concise-mid-tag map.

     *  lang (index 0): A textual language tag that conforms with IANA
        "Language Subtag Registry" [IANA.language-subtag-registry].  The
        context of the specified language applies to all sibling and



  Birkholz, et al.        Expires 3 September 2026               [Page 24]


  Internet-Draft                    CoRIM                       March 2026


        descendant textual values, unless a descendant object has defined
        a different language tag.  Thus, a new context is established when
        a descendant object redefines a new language tag.  All textual
        values within a given context MUST be considered expressed in the
        specified language.

     *  tag-identity (index 1): A tag-identity-map containing unique
        identification information for the CoMID.  Described in
        Section 5.1.1.

     *  entities (index 2): Provides information about one or more
        organizations responsible for producing the CoMID tag.  Described
        in Section 5.1.2.

     *  linked-tags (index 3): A list of one or more linked-tag-map
        providing typed relationships between this and other CoMIDs.
        Described in Section 5.1.3).

     *  triples (index 4): One or more triples providing information
        specific to the described module, e.g.: reference or endorsed
        values, cryptographic material, or structural relationship between
        the described module and other modules.  Described in
        Section 5.1.4.

  5.1.1.  Tag Identity

     tag-identity-map = {
       &(tag-id: 0) => $tag-id-type-choice
       ? &(tag-version: 1) => tag-version-type
     }

     The following describes each member of the tag-identity-map.

     *  tag-id (index 0): A universally unique identifier for the CoMID.
        Described in Section 5.1.1.1.

     *  tag-version (index 1): Optional versioning information for the
        tag-id.  Described in Section 5.1.1.2.

  5.1.1.1.  Tag ID

     $tag-id-type-choice /= tstr
     $tag-id-type-choice /= uuid-type

     A Tag ID is either a 16-byte binary string, or a textual identifier,
     uniquely referencing the CoMID.  The tag identifier MUST be globally
     unique.  Failure to ensure global uniqueness can create ambiguity in
     tag use since the tag-id serves as the global key for matching,



  Birkholz, et al.        Expires 3 September 2026               [Page 25]


  Internet-Draft                    CoRIM                       March 2026


     lookups and linking.  If represented as a 16-byte binary string, the
     identifier MUST be a valid universally unique identifier as defined
     by [RFC9562].  There are no strict guidelines on how the identifier
     is structured, but examples include a 16-byte GUID (e.g., class 4
     UUID) [RFC9562], or a URI [STD66].

  5.1.1.2.  Tag Version

     tag-version-type = uint .default 0

     Tag Version is an integer value that indicates the specific release
     revision of the tag.  Typically, the initial value of this field is
     set to 0 and the value is increased for subsequent tags produced for
     the same module release.  This value allows a CoMID tag producer to
     correct an incorrect tag previously released without indicating a
     change to the underlying module the tag represents.  For example, the
     tag version could be changed to add new metadata, to correct a broken
     link, to add a missing reference value, etc.  When producing a
     revised tag, the new tag-version value MUST be greater than the old
     tag-version value.

  5.1.2.  Entities

     comid-entity-map =
       entity-map<$comid-role-type-choice, $$comid-entity-map-extension>

     The CoMID Entity is an instantiation of entity-map (Section 7.2)
     using a $comid-role-type-choice.

     The $$comid-entity-map-extension extension socket is empty in this
     specification.

     $comid-role-type-choice /= &(tag-creator: 0)
     $comid-role-type-choice /= &(creator: 1)
     $comid-role-type-choice /= &(maintainer: 2)

     The roles defined for a CoMID entity are:

     *  tag-creator (value 0): creator of the CoMID tag.

     *  creator (value 1): original maker of the module described by the
        CoMID tag.

     *  maintainer (value 2): an entity making changes to the module
        described by the CoMID tag.






  Birkholz, et al.        Expires 3 September 2026               [Page 26]


  Internet-Draft                    CoRIM                       March 2026


  5.1.3.  Linked Tag

     The linked tag map represents a typed relationship between the
     embedding CoMID tag (the source) and another CoMID tag (the target).

     linked-tag-map = {
       &(linked-tag-id: 0) => $tag-id-type-choice
       &(tag-rel: 1) => $tag-rel-type-choice
     }

     The following describes each member of the tag-identity-map.

     *  linked-tag-id (index 0): Unique identifier for the target tag.
        See Section 5.1.1.1.

     *  tag-rel (index 1): the kind of relation linking the source tag to
        the target identified by linked-tag-id.

     $tag-rel-type-choice /= &(supplements: 0)
     $tag-rel-type-choice /= &(replaces: 1)

     The relations defined in this specification are:

     *  supplements (value 0): the source tag provides additional
        information about the module described in the target tag.

     *  replaces (value 1): the source tag corrects erroneous information
        contained in the target tag.  The information in the target MUST
        be disregarded.

  5.1.4.  Triples

     The triples-map contains all the CoMID triples broken down per
     category.  Not all category need to be present but at least one
     category MUST be present and contain at least one entry.

     In most cases, the supply chain entity that is responsible for
     providing a triple (i.e., Reference Values or Endorsed Values) is by
     default the CoRIM signer.  The signer of a triple is said to be its
     _authority_. However, multiple authorities may be involved in signing
     triples.  See [STD96].  Consequently, authority may differ for search
     criteria.  See Section 5.1.4.5.









  Birkholz, et al.        Expires 3 September 2026               [Page 27]


  Internet-Draft                    CoRIM                       March 2026


     triples-map = non-empty<{
       ? &(reference-triples: 0) =>
         [ + reference-triple-record ]
       ? &(endorsed-triples: 1) =>
         [ + endorsed-triple-record ]
       ? &(identity-triples: 2) =>
         [ + identity-triple-record ]
       ? &(attest-key-triples: 3) =>
         [ + attest-key-triple-record ]
       ? &(dependency-triples: 4) =>
         [ + domain-dependency-triple-record ]
       ? &(membership-triples: 5) =>
         [ + domain-membership-triple-record ]
       ? &(coswid-triples: 6) =>
         [ + coswid-triple-record ]
       ? &(conditional-endorsement-series-triples: 8) =>
         [ + conditional-endorsement-series-triple-record ]
       ? &(conditional-endorsement-triples: 10) =>
         [ + conditional-endorsement-triple-record ]
       * $$triples-map-extension
     }>

     The following describes each member of the triples-map:

     *  reference-triples (index 0): Triples containing reference values.
        Described in Section 5.1.5.

     *  endorsed-triples (index 1): Triples containing endorsed values.
        Described in Section 5.1.6.

     *  identity-triples (index 2): Triples containing identity
        credentials.  Described in Section 5.1.9.

     *  attest-key-triples (index 3): Triples containing verification keys
        associated with attesting environments.  Described in
        Section 5.1.10.

     *  dependency-triples (index 4): Triples describing trust
        relationships between domains.  Described in Section 5.1.11.2.

     *  membership-triples (index 5): Triples describing topological
        relationships between (sub-)modules.  Described in
        Section 5.1.11.1.

     *  coswid-triples (index 6): Triples associating modules with
        existing CoSWID tags.  Described in Section 5.1.12.





  Birkholz, et al.        Expires 3 September 2026               [Page 28]


  Internet-Draft                    CoRIM                       March 2026


     *  conditional-endorsement-series-triples (index 8): Triples
        describing a series of Endorsements that are applicable based on
        the acceptance of a condition.  Described in Section 5.1.8.

     *  conditional-endorsement-triples (index 10): Triples describing a
        series of conditional Endorsements based on the acceptance of a
        stateful environment.  Described in Section 5.1.7.

  5.1.4.1.  Environments

     An environment-map may be used to represent a whole Attester, an
     Attesting Environment, or a Target Environment.  The exact semantic
     depends on the context (triple) in which the environment is used.

     An environment is named after a class, instance or group identifier
     (or a combination thereof).

     An environment MUST be globally unique.  The combination of values
     within class-map MUST combine to form a globally unique identifier.

     environment-map = non-empty<{
       ? &(class: 0) => class-map
       ? &(instance: 1) => $instance-id-type-choice
       ? &(group: 2) => $group-id-type-choice
     }>

     The following describes each member of the environment-map:

     *  class (index 0): Contains "class" attributes associated with the
        module.  Described in Section 5.1.4.2.

     *  instance (index 1): Contains a unique identifier of a module's
        instance.  Described in Section 5.1.4.3.

     *  group (index 2): identifier for a group of instances, e.g., if an
        anonymization scheme is used.  Described in Section 5.1.4.4.

  5.1.4.2.  Environment Class

     The Class name consists of class attributes that distinguish the
     class of environment from other classes.  The class attributes
     include class-id, vendor, model, layer, and index.  The CoMID author
     determines which attributes are needed.








  Birkholz, et al.        Expires 3 September 2026               [Page 29]


  Internet-Draft                    CoRIM                       March 2026


     class-map = non-empty<{
       ? &(class-id: 0) => $class-id-type-choice
       ? &(vendor: 1) => tstr
       ? &(model: 2) => tstr
       ? &(layer: 3) => uint
       ? &(index: 4) => uint
     }>

     $class-id-type-choice /= tagged-oid-type
     $class-id-type-choice /= tagged-uuid-type
     $class-id-type-choice /= tagged-bytes

     The following describes each member of the class-map:

     *  class-id (index 0): Identifies the environment via a well-known
        identifier.  Typically, class-id is an object identifier (OID)
        variable-length opaque byte string (Section 7.8) or universally
        unique identifier (UUID).  Use of this attribute is preferred.

     *  vendor (index 1): Identifies the entity responsible for choosing
        values for the other class attributes that do not already have
        naming authority.

     *  model (index 2): Describes a product, generation, and family.  If
        populated, vendor MUST also be populated.

     *  layer (index 3): Is used to capture where in a sequence the
        environment exists.  For example, the order in which bootstrap
        code is executed may have security relevance.

     *  index (index 4): Is used when there are clones (i.e., multiple
        instances) of the same class of environment.  Each clone is given
        a different index value to disambiguate it from the other clones.
        For example, given a chassis with several network interface
        controllers (NIC), each NIC can be given a different index value.

  5.1.4.3.  Environment Instance

     An instance-id is a unique value that identifies a Target Environment
     instance.  The identifier is reliably bound to the Target
     Environment.  For example, if an X.509 certificate's subject public
     key is unique for each instance of a target environment, the
     instance-id might be created from that subject public key.  See
     Section 4.1 of [RFC5280].  Alternatively, if the certificate's
     subject public key is large, the instance-id might be a key
     identifier that is a digest of that public key.  See Section 4.2.1.2
     of [RFC5280].  The key identifier is reliably bound to the subject
     public key because the identifier is a digest of the key.



  Birkholz, et al.        Expires 3 September 2026               [Page 30]


  Internet-Draft                    CoRIM                       March 2026


     The types defined for an instance identifier are CBOR tagged
     expressions of UEID, UUID, variable-length opaque byte string
     (Section 7.8), cryptographic keys, or cryptographic key identifiers.

     $instance-id-type-choice /= tagged-ueid-type
     $instance-id-type-choice /= tagged-uuid-type
     $instance-id-type-choice /= tagged-bytes
     $instance-id-type-choice /= tagged-pkix-base64-key-type
     $instance-id-type-choice /= tagged-pkix-base64-cert-type
     $instance-id-type-choice /= tagged-cose-key-type
     $instance-id-type-choice /= tagged-key-thumbprint-type
     $instance-id-type-choice /= tagged-cert-thumbprint-type
     $instance-id-type-choice /= tagged-pkix-asn1der-cert-type

  5.1.4.4.   Environment Group

     A group carries a unique identifier that is reliably bound to a group
     of Attesters, for example when a number of Attester are hidden in the
     same anonymity set.

     The types defined for a group identified are UUID and variable-length
     opaque byte string (Section 7.8).

     $group-id-type-choice /= tagged-uuid-type
     $group-id-type-choice /= tagged-bytes

  5.1.4.5.  Measurements

     Measurements can be of a variety of things including software,
     firmware, configuration files, read-only memory, fuses, IO ring
     configuration, partial reconfiguration regions, etc.  Measurements
     comprise raw values, digests, or status information.

     An environment has one or more measurable elements.  Each element can
     have a dedicated measurement or multiple elements could be combined
     into a single measurement.  Measurements can have class, instance or
     group scope.  This is typically determined by the triple's
     environment.

     Class measurements apply generally to all the Attesters in a given
     class.

     Instance measurements apply to a specific Attester instance.
     Environments identified by a class identifier have measurements that
     are common to the class.  Environments identified by an instance
     identifier have measurements that are specific to that instance.





  Birkholz, et al.        Expires 3 September 2026               [Page 31]


  Internet-Draft                    CoRIM                       March 2026


     An environment may have multiple measured elements.  Measured
     elements are distinguished from each other by measurement keys.
     Measurement keys may be used to disambiguate measurements of the same
     type originating from different elements.

     Triples that have search conditions may specify authority as matching
     criteria by populating authorized-by.

     measurement-map = {
       ? &(mkey: 0) => $measured-element-type-choice
       &(mval: 1) => measurement-values-map
       ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
     }

     The following describes each member of the measurement-map:

     *  mkey (index 0): An optional measurement key.  Described in
        Section 5.1.4.5.1.  A measurement-map without an mkey is said to
        be anonymous.

     *  mval (index 1): The measurements associated with the environment.
        Described in Section 5.1.4.5.2.

     *  authorized-by (index 2): The cryptographic identity of the entity
        (individual or organization) that is the designated authority for
        measurement Claims.  For example, the signer of a CoMID triple.
        See Section 5.1.4.6.  An entity is authoritative when it makes
        Claims that are inside its area of competence.

  5.1.4.5.1.  Measurement Keys

     Measurement keys SHALL be unique within the scope of the environment-
     map they are associated with.  The initial types defined are OID,
     UUID, uint, and tstr. mkey may be necessary to disambiguate multiple
     measurements of the same type or to distinguish multiple measured
     elements within the same environment.  A single anonymous
     measurement-map is allowed within the same environment.  Two or more
     measurement-map entries within the same environment MUST populate
     mkey.

     $measured-element-type-choice /= tagged-oid-type
     $measured-element-type-choice /= tagged-uuid-type
     $measured-element-type-choice /= uint
     $measured-element-type-choice /= tstr







  Birkholz, et al.        Expires 3 September 2026               [Page 32]


  Internet-Draft                    CoRIM                       March 2026


  5.1.4.5.2.  Measurement Values

     A measurement-values-map contains measurements associated with a
     certain environment.  Depending on the context (triple) in which they
     are found, elements in a measurement-values-map can represent class
     or instance measurements.  Note that some of the elements have
     instance scope only.

     Measurement values may support use cases beyond Verifier appraisal.
     Typically, a Relying Party determines if additional processing is
     desirable and whether the processing is applied by the Verifier or
     the Relying Party.

     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-DEPRECATED: 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
       ? &(int-range: 15) => int-range-type-choice
       * $$measurement-values-map-extension
     }>

     The following describes each member of the measurement-values-map.

     *  version (index 0): Typically changes whenever the measured
        environment is updated.  Described in Section 5.1.4.5.3.

     *  svn (index 1): The security version number typically changes only
        when a security relevant change is made to the measured
        environment.  Described in Section 5.1.4.5.4.

     *  digests (index 2): Contains the digest(s) of the measured
        environment together with the respective hash algorithm used in
        the process.  It uses the digests-type.  Described in Section 7.7.





  Birkholz, et al.        Expires 3 September 2026               [Page 33]


  Internet-Draft                    CoRIM                       March 2026


     *  flags (index 3): Describes security relevant operational modes.
        For example, whether the environment is in a debug mode, recovery
        mode, not fully configured, not secure, not replay protected or
        not integrity protected.  The flags field indicates which
        operational modes are currently associated with measured
        environment.  Described in Section 5.1.4.5.5.

     *  raw-value (index 4): Contains the actual (not hashed) value of the
        element.  The vendor determines the encoding of raw-value.  When
        used for comparison, the tagged-masked-raw-value variant includes
        a mask indicating which bits in the value to compare.  Described
        in Section 5.1.4.5.6

     *  raw-value-mask-DEPRECATED (index 5): Is an obsolete method of
        indicating which bits in a raw value to compare.  New CoMID files
        should use the tagged-masked-raw-value on index 4 instead of using
        index 5.

     *  mac-addr (index 6): An EUI-48 (Extended Unique Identifier 48) or
        EUI-64 MAC address [IEEE-802.OandA] associated with the measured
        environment.  Described in Section 5.1.4.5.7.

     *  ip-addr (index 7): An IPv4 or IPv6 address associated with the
        measured environment.  Described in Section 5.1.4.5.7.

     *  serial-number (index 8): A text string representing the product
        serial number.

     *  ueid (index 9): UEID associated with the measured environment.
        Described in Section 7.5.

     *  uuid (index 10): UUID associated with the measured environment.
        Described in Section 7.4.

     *  name (index 11): a name associated with the measured environment.

     *  cryptokeys (index 13): identifies cryptographic keys that are
        protected by the Target Environment See Section 5.1.4.6 for the
        supported formats.  An Attesting Environment determines that keys
        are protected as part of Claims collection.  Appraisal verifies
        that, for each value in cryptokeys, there is a matching Reference
        Value entry.  Matching is described in Section 9.4.6.1.5.

     *  integrity-registers (index 14): A group of one or more named
        measurements associated with the environment.  Described in
        Section 5.1.4.7.





  Birkholz, et al.        Expires 3 September 2026               [Page 34]


  Internet-Draft                    CoRIM                       March 2026


  5.1.4.5.3.  Version

     A version-map contains details about the versioning of a measured
     environment.

     ;# import rfc9393 as coswid

     version-map = {
       &(version: 0) => text
       ? &(version-scheme: 1) => coswid.$version-scheme
     }

     The following describes each member of the version-map:

     *  version (index 0): the version string

     *  version-scheme (index 1): an optional indicator of the versioning
        convention used in the version attribute.  Defined in Section 4.1
        of [RFC9393].  The CDDL is copied below for convenience.

     $version-scheme /= &(multipartnumeric: 1)
     $version-scheme /= &(multipartnumeric-suffix: 2)
     $version-scheme /= &(alphanumeric: 3)
     $version-scheme /= &(decimal: 4)
     $version-scheme /= &(semver: 16384)
     $version-scheme /= int / text

  5.1.4.5.4.  Security Version Number

     The following details the security version number (svn) and the
     minimum security version number (min-svn) statements.  A security
     version number is used to track changes to an object (e.g., a secure
     enclave, a boot loader executable, a configuration file, etc.) that
     are security relevant.  Rollback of a security relevant change is
     considered to be an attack vector; as such, security version numbers
     cannot be decremented.  If a security relevant flaw is discovered in
     the Target Environment and is subsequently fixed, the svn value is
     typically incremented.

     There may be several revisions to a Target Environment that are in
     use at the same time.  If there are multiple revisions with different
     svn values, the revision with a lower svn value may or may not be in
     a security critical condition.  The Endorser may provide a minimum
     security version number using min-svn to specify the lowest svn value
     that is acceptable. svn values that are equal to or greater than min-
     svn do not signal a security critical condition. svn values that are
     below min-svn are in a security critical condition that is unsafe for
     normal use.



  Birkholz, et al.        Expires 3 September 2026               [Page 35]


  Internet-Draft                    CoRIM                       March 2026


     The svn-type-choice measurement consists of a tagged-svn or tagged-
     min-svn value.  The tagged-svn and tagged-min-svn tags are CBOR tags
     with the values #6.552 and #6.553 respectively.

     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

  5.1.4.5.5.  Flags

     The flags-map measurement describes a number of boolean operational
     modes.  If a flags-map value is not specified, then the operational
     mode is unknown.  Note that, while the fields may not be completely
     independent of one another, this specification imposes no
     restrictions on combinations of the flags-map booleans.  However, a
     profile may restrict the possible flags-map booleans and their valid
     combinations.

     flags-map = non-empty<{
       ? &(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
     }>

     The following describes each member of the flags-map:

     *  is-configured (index 0): If the flag is true, the measured
        environment is fully configured for normal operation.

     *  is-secure (index 1): If the flag is true, the measured
        environment's configurable security settings are fully enabled.

     *  is-recovery (index 2): If the flag is true, the measured
        environment is in recovery mode.

     *  is-debug (index 3): If the flag is true, the measured environment
        is in a debug enabled mode.



  Birkholz, et al.        Expires 3 September 2026               [Page 36]


  Internet-Draft                    CoRIM                       March 2026


     *  is-replay-protected (index 4): If the flag is true, the measured
        environment is protected from rollback to previous software
        images.

     *  is-integrity-protected (index 5): If the flag is true, the
        measured environment is protected from unauthorized update.

     *  is-runtime-meas (index 6): If the flag is true, the measured
        environment is measured after being loaded into memory.

     *  is-immutable (index 7): If the flag is true, the measured
        environment is immutable.

     *  is-tcb (index 8): If the flag is true, the measured environment is
        a trusted computing base.

     *  is-confidentiality-protected (index 9): If the flag is true, the
        measured environment is confidentiality protected.  For example,
        if the measured environment consists of memory, the sensitive
        values in memory are encrypted.

  5.1.4.5.6.  Raw Values Types

     Raw value measurements are typically vendor defined values that are
     checked by Verifiers for consistency only, since the security
     relevance is opaque to Verifiers.  A profile may choose to define
     more specific semantic meaning to a raw value.

     A raw-value measurement, or an Endorsement, is a tagged value of type
     bytes.  This specification defines tag #6.560.  The default raw value
     measurement is of type tagged-bytes (Section 7.8).

     Additional value types can be added to $raw-value-type-choice.  These
     additional values MUST be CBOR tagged bstrs.  Constraining all raw
     value types to be bstr lets Verifiers compare raw values without
     understanding their contents.

     A raw value intended for comparison can include a mask value, which
     selects the bits to compare during appraisal.  The mask is applied by
     the Verifier as part of appraisal.  Only the raw value bits with
     corresponding TRUE mask bits are compared during appraisal.

     The raw-value-mask-DEPRECATED in measurement-values-map is
     deprecated, but retained for backwards compatibility.  This code
     point may be removed in a future revision of this specification.






  Birkholz, et al.        Expires 3 September 2026               [Page 37]


  Internet-Draft                    CoRIM                       March 2026


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

  5.1.4.5.7.  Address Types

     This specification defines types for 48-bit and 64-bit MAC
     identifiers.  For IP addresses, it reuses the "Address Format" types
     defined in [RFC9164] with the CBOR tag removed.

     All the types represent a single address.

     mac-addr-type-choice = eui48-addr-type / eui64-addr-type
     eui48-addr-type = bytes .size 6
     eui64-addr-type = bytes .size 8

     ;# import rfc9164 as cbor-ip

     ip-addr-type-choice /= cbor-ip.ipv4-address
     ip-addr-type-choice /= cbor-ip.ipv6-address

  5.1.4.6.  Crypto Keys

     A cryptographic key can be one of the following formats:

     *  tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo.
        Defined in Section 13 of [RFC7468].

     *  tagged-pkix-base64-cert-type: PEM encoded X.509 public key
        certificate.  Defined in Section 5 of [RFC7468].

     *  tagged-pkix-base64-cert-path-type: X.509 certificate chain created
        by the concatenation of as many PEM encoded X.509 certificates as
        needed.  The certificates MUST be concatenated in order so that
        each directly certifies the one preceding.

     *  tagged-cose-key-type: CBOR encoded COSE_Key or COSE_KeySet.
        Defined in Section 7 of [STD96].

     *  tagged-pkix-asn1der-cert-type: a bstr of ASN.1 DER encoded X.509
        public key certificate.  Defined in Section 4 of [RFC5280].

     A cryptographic key digest can be one of the following formats:



  Birkholz, et al.        Expires 3 September 2026               [Page 38]


  Internet-Draft                    CoRIM                       March 2026


     *  tagged-key-thumbprint-type: a digest (e.g., the SHA-2 hash) of a
        raw public key.  For example, the digest value can be used to
        locate a public key contained in a lookup table.  Ultimately, the
        discovered keys have to be successfully byte-by-byte compared with
        the corresponding keys.

     *  tagged-cert-thumbprint-type: a digest of a certificate.  The
        digest value may be used to find the certificate if contained in a
        lookup table.

     *  tagged-cert-path-thumbprint-type: a digest of a certification
        path.  The digest value may be used to find the certificate path
        if contained in a lookup table.

     *  tagged-bytes: a key identifier with no prescribed construction
        method.

     ;# import measured-component as eatmc

     $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-pkix-asn1der-cert-type
     $crypto-key-type-choice /= tagged-key-thumbprint-type
     $crypto-key-type-choice /= tagged-cert-thumbprint-type
     $crypto-key-type-choice /= tagged-cert-path-thumbprint-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-key-thumbprint-type = #6.557(eatmc.digest)
     tagged-cose-key-type = #6.558(COSE_Key)
     tagged-cert-thumbprint-type = #6.559(eatmc.digest)
     tagged-cert-path-thumbprint-type = #6.561(eatmc.digest)
     tagged-pkix-asn1der-cert-type = #6.562(bstr)

  5.1.4.7.  Integrity Registers

     An Integrity Registers map groups together one or more measured
     "objects".  Each measured object has a unique identifier and one or
     more associated digests.  Identifiers are either unsigned integers or
     text strings and their type matters, e.g., unsigned integer 5 is
     distinct from the text string "5".  The digests use digests-type
     semantics (Section 7.7).






  Birkholz, et al.        Expires 3 September 2026               [Page 39]


  Internet-Draft                    CoRIM                       March 2026


     integrity-register-id-type-choice = uint / text

     integrity-registers = {
       + integrity-register-id-type-choice => digests-type
     }

     All the measured objects in an Integrity Registers map are explicitly
     named and the order in which they appear in the map is irrelevant.
     Any digests associated with a measured object represent an acceptable
     state for the object.  Therefore, if multiple digests are provided,
     the acceptable state is their cross-product.  For example, given the
     following Integrity Registers:

     {
       0: [ [ 0, h'00' ] ],
       1: [ [ 0, h'11' ], [ 1, h'12' ] ]
     }

     then both

     {
       0: [ 0, h'00' ],
       1: [ 0, h'11' ]
     }

     and

     {
       0: [ 0, h'00' ],
       1: [ 1, h'12' ]
     }

     are acceptable states.

     Integrity Registers can be used to model the PCRs in a TPM or vTPM,
     in which case the identifier is the register index, or other kinds of
     vendor-specific measured objects.

  5.1.4.8.  Int Range

     An int range describes an integer value that can be compared with
     linear order in the target environment.  An int range is represented
     with either major type 0 or major type 1 ints.








  Birkholz, et al.        Expires 3 September 2026               [Page 40]


  Internet-Draft                    CoRIM                       March 2026


     int-range-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

     The signed integer range representation is an inclusive range unless
     either min or max are infinite as represented by null, in which case,
     each infinity is necessarily exclusive.

  5.1.5.  Reference Values Triple

     Reference Values Triples describe the possible intended states of an
     Attester.  At any given point in time, an Attester is expected to
     match only one of these states.

     A Reference Values Triple provides reference values pertaining to a
     Target Environment.  In a Reference Value triple, the subject
     identifies a Target Environment, the object contains reference
     measurements associated with one or more measured elements of the
     Environment, and the predicate asserts that these represent the
     expected state of the Target Environment.

     The Reference Values Triple has the following structure:

     reference-triple-record = [
       ref-env: environment-map
       ref-claims: [ + measurement-map ]
     ]

     The reference-triple-record has the following parameters:

     *  ref-env: Identifies the Target Environment

     *  ref-claims: Contains one or more reference measurements for the
        Target Environment

     CoMID triples (Section 5.1.4) may contain multiple reference-triple-
     record entries, each of which describes one or more possible states
     for a particular Target Environment.

     The ref-claims in a reference-triple-record can contain one or more
     entries.  This multiplicity can have different meanings:

     1.  Each ref-claims entry can represent a different possible state of
         the Environment.





  Birkholz, et al.        Expires 3 September 2026               [Page 41]


  Internet-Draft                    CoRIM                       March 2026


     2.  Each ref-claims entry can represent a possible state of a
         different measured element (identified by its mkey) within the
         Environment.

     Note that the same semantics can be expressed using multiple
     Reference Value Triples.

     Note also that a measurement key-value pair could be defined to have
     multiple values or use "wild carding" to describe a range of
     acceptable values, for example when using int-range and min-svn.

     Any of these multiplicities could be used in the context of Reference
     Values Triples.

     To process a reference-triple-record, the ref-env and ref-claims
     criteria are compared with Evidence entries.  First, ref-env is used
     as search criteria to locate matching Evidence environments.  Then,
     the ref-claims from this triple are used to match against the
     Evidence measurements for a matched environment.  If the search
     criteria are satisfied, the matching entry is added to the body of
     Attester state, except these Claims are asserted with the Reference
     Value Provider's authority.  By re-asserting Evidence matched with
     Reference Values using the RVP's authority, the Verifier avoids
     confusing Reference Values (reference / possible state) with Evidence
     (actual state).  See [I-D.ietf-rats-endorsements].  Evidence Claims
     that are re-asserted using RVP authority are said to be "corroborated
     Evidence" because the actual state in Evidence was found within the
     corpus of the RVP's possible state.

  5.1.6.  Endorsed Values Triple

     An Endorsed Values triple provides additional Endorsements - i.e.,
     claims reflecting the actual state - for an existing Target
     Environment.  For Endorsed Values Claims, the subject is a Target
     Environment, the object contains Endorsement Claims for the
     Environment, and the predicate defines semantics for how the object
     relates to the subject.

     The Endorsed Values Triple has the following structure:

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

     The endorsed-triple-record has the following parameters:





  Birkholz, et al.        Expires 3 September 2026               [Page 42]


  Internet-Draft                    CoRIM                       March 2026


     *  condition: Search criterion that locates an Evidence, corroborated
        Evidence, or Endorsements environment.

     *  endorsement: Additional Endorsement Claims.

     To process a endorsed-triple-record the condition is compared with
     existing Evidence, corroborated Evidence, and Endorsements.  If the
     search criterion is satisfied, the endorsement Claims are combined
     with the condition environment-map to form a new (actual state)
     entry.  The new entry is added to the existing set of entries using
     the Endorser's authority.

  5.1.7.  Conditional Endorsement Triple

     A Conditional Endorsement Triple declares one or more conditions
     that, once matched, results in augmenting the Attester's actual state
     with the Endorsement Claims.  The conditions are expressed via
     stateful-environment-records, which match Target Environments from
     Evidence in certain reference state.

     The Conditional Endorsement Triple has the following structure:

     conditional-endorsement-triple-record = [
       conditions: [ + stateful-environment-record ]
       endorsements: [ + endorsed-triple-record ]
     ]

     stateful-environment-record = [
       environment: environment-map,
       claims-list: [ + measurement-map ]
     ]

     The conditional-endorsement-triple-record has the following
     parameters:

     *  conditions: Search criteria that locates Evidence, corroborated
        Evidence, or Endorsements.

     *  endorsements: Additional Endorsements.

     To process a conditional-endorsement-triple-record the conditions are
     compared with existing Evidence, corroborated Evidence, and
     Endorsements.  If the search criteria are satisfied, the endorsements
     entries are asserted with the Endorser's authority as new
     Endorsements.






  Birkholz, et al.        Expires 3 September 2026               [Page 43]


  Internet-Draft                    CoRIM                       March 2026


  5.1.8.  Conditional Endorsement Series Triple

     The Conditional Endorsement Series Triple employs a 2-stage matching
     convention to assert endorsed values based on an initial condition
     match followed by a series selection match.  If both the condition
     and selection criteria are satisfied, a set of endorsed values are
     added to the matching triple records.  The condition match identifies
     the set of Claims to which the selection criteria are applied.  The
     selection specifies a pattern of measurements that, if present,
     controls when a focused set of endorsed values are to be asserted.
     The 2-stage approach enables Endorsement authors the ability to craft
     powerful search criteria while avoiding probelmatic repetition of
     search criteria.

     The Conditional Endorsement Series Triple has the following
     structure:

     conditional-endorsement-series-triple-record = [
       condition: [
         environment: environment-map
         claims-list: [ * measurement-map ]
         ? authorized-by: [ + $crypto-key-type-choice ]
       ]
       series: [ + conditional-series-record ]
     ]

     conditional-series-record = [
       selection: [ + measurement-map]
       addition: [ + measurement-map ]
     ]

     The conditional-endorsement-series-triple-record has the following
     parameters:

     *  condition: Initial selection criteria that locates Evidence,
        corroborated Evidence, or Endorsements from the current set of
        accepted Claims.  The condition consists of an environment-map, a
        (possibly empty) claims-list, and an optional authorized-by.

     *  series: A sequence of selection-addition tuples.

     The conditional-series-record has the following parameters:

     *  selection: Secondary selection criteria that locates Evidence,
        corroborated Evidence, or Endorsements from the initial selection
        criteria's condition result.





  Birkholz, et al.        Expires 3 September 2026               [Page 44]


  Internet-Draft                    CoRIM                       March 2026


     *  addition: Endorsements that are added if the selection criteria
        are satisfied.

  5.1.8.1.  Condition Matching

     The condition matching criteria is applied to the set of Claims the
     Verifier has previously accepted.  The criteria is expressed in terms
     of environments (i.e., environment-map) and optionally measurements
     (i.e., claims-list) or authority (i.e., authorized-by).  Condition
     matching is intended to powerfully enable broad or narrow searches
     that serve as staging for subsequent selection matching.

     Note that measurement-map can also specify authority criteria.  To
     avoid conflicting criteria, the authorized-by in condition takes
     precedence over the authorized-by in measurement-map.

  5.1.8.1.1.  Selection Matching

     Every conditional-series-record selection MUST select the same mkeys
     where every selected mkey's corresponding set of code points
     represented as mval.key MUST be the same across each conditional-
     series-record.  For example, if a selection matches on 3 measurement-
     map statements; mkey is the same for all 3 statements and mval
     contains only A= variable-X, B= variable-Y, and C= variable-Z
     (exactly the set of code points A, B, and C) respectively for every
     conditional-series-record in the series.

     These restrictions ensure that evaluation order does not change the
     meaning of the triple during the appraisal process.  Series entries
     are ordered such that the most precise match is evaluated first and
     least precise match is evaluated last.  The first series condition
     that matches terminates series matching and the endorsement values
     are added to the Attester's actual state.

  5.1.8.1.2.  Processing the Addition

     To process a conditional-endorsement-series-record the selection
     criteria in condition entries are matched with existing Evidence,
     corroborated Evidence, and Endorsements.  If the selection criteria
     are satisfied, the series tuples are processed.

     The series array contains an ordered list of conditional-series-
     record entries.  Evaluation order begins at list position 0.








  Birkholz, et al.        Expires 3 September 2026               [Page 45]


  Internet-Draft                    CoRIM                       March 2026


     For each series entry, if the selection criteria matches an entry
     found in the condition result, the series addition is combined with
     the environment-map from the condition result to form a new
     Endorsement entry.  The new entry is added to the existing set of
     Endorsements.

     The first series entry that successfully matches the selection
     criteria terminates series processing.

  5.1.9.  Device Identity Triple

     Device Identity triples (see identity-triples in Section 5.1.4)
     endorse that the keys were securely provisioned to the named Target
     Environment.  A single Target Environment (as identified by
     environment and mkey) may contain one or more cryptographic keys.
     The existence of these keys is asserted in Evidence, Reference
     Values, or Endorsements.

     The device identity keys may have been used to authenticate the
     Attester device or may be held in reserve for later use.

     Device Identity triples instruct a Verifier to perform key validation
     checks, such as revocation, certificate path construction &
     verification, or proof of possession.  The Verifier SHOULD verify
     keys contained in Device Identity triples.

     Additional details about how a key was provisioned or is protected
     may be asserted using Endorsements such as endorsed-triples.

     Depending on key formatting, as defined by $crypto-key-type-choice,
     the Verifier may take different steps to locate and verify the key.

     If a key has usage restrictions that limit its use to device identity
     challenges, the Verifier SHOULD enforce key use restrictions.

     Each successful verification of a key in key-list SHALL produce
     Endorsement Claims that are added to the Attester's Claim set.
     Claims are asserted with the joint authority of the Endorser (CoRIM
     signer) and the Verifier.  The Verifier MAY report key verification
     results as part of an error reporting function.











  Birkholz, et al.        Expires 3 September 2026               [Page 46]


  Internet-Draft                    CoRIM                       March 2026


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

     *  environment: An environment-map condition used to identify the
        target Evidence or Reference Value.  See Section 5.1.4.1.

     *  key-list: A list of $crypto-key-type-choice keys that identifies
        which keys are to be verified.  See Section 5.1.4.6.

     *  mkey: An optional $measured-element-type-choice condition used to
        identify the element within the target Evidence or Reference
        Value.  See Section 5.1.4.5.1.

     *  authorized-by: An optional list of $crypto-key-type-choice keys
        that identifies the authorities that asserted the key-list in the
        target Evidence or Reference Values.

  5.1.10.  Attest Key Triple

     Attest Key triples (see attest-key-triples in Section 5.1.4) endorse
     that the keys were securely provisioned to the named Attesting
     Environment.  An Attesting Environment (as identified by environment
     and mkey) may contain one or more cryptographic keys.  The existence
     of these keys is asserted in Evidence, Reference Values, or
     Endorsements.

     The attestation keys may have been used to sign Evidence or may be
     held in reserve for later use.

     Attest Key triples instruct a Verifier to perform key validation
     checks, such as revocation, certification path construction and
     validation, or proof of possession.  The Verifier SHOULD verify keys
     contained in Attest Key triples.

     Additional details about how a key was provisioned or is protected
     may be asserted using Endorsements such as endorsed-triples.

     Depending on key formatting, as defined by $crypto-key-type-choice,
     the Verifier may take different steps to locate and verify the key.
     If a key has usage restrictions that limits its use to Evidence
     signing (e.g., see Section 5.1.5.3 in [DICE.cert]).  The Verifier
     SHOULD enforce key use restrictions.



  Birkholz, et al.        Expires 3 September 2026               [Page 47]


  Internet-Draft                    CoRIM                       March 2026


     Each successful verification of a key in key-list SHALL produce
     Endorsement Claims that are added to the Attester's Claim set.
     Claims are asserted with the joint authority of the Endorser (CoRIM
     signer) and the Verifier.  The Verifier MAY report key verification
     results as part of an error reporting function.

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

     See Section 5.1.9 for additional details.

  5.1.11.  Triples for domain definitions

     A domain is a hierarchical description of a Composite Attester in
     terms of its constituent Environments and their compositional
     relationships.

     The following CDDL describes domain type.

     domain-type = environment-map

     Domain structure is defined with the following types of triples.

  5.1.11.1.  Domain Membership Triple

     A Domain Membership Triple (DMT) links a domain identifier to its
     member Environments.  The triple's subject is the domain identifier
     while the triple’s object lists all the member Environments within
     the domain.

     The Domain Membership Triple allows an Endorser (for example, an
     Integrator) to issue an authoritative statement about the composition
     of an Attester as a collection of Environments.  This allows a
     topological description of an Attester to be expressed by linking a
     parent Environment (e.g., a lead Attester) to its child Environments
     (e.g., one or more sub-Attesters).

     If the Verifier Appraisal policy requires Domain Membership, the
     Domain Membership Triple is used to match an Attester's reference
     composition with the actual composition represented in Evidence.





  Birkholz, et al.        Expires 3 September 2026               [Page 48]


  Internet-Draft                    CoRIM                       March 2026


     Representing members of a DMT as domains enables the recursive
     construction of an entity's topology, such as a Composite Device (see
     Section 3.3 of [RFC9334]), where multiple lower-level domains can be
     aggregated into a higher-level domain.

     domain-membership-triple-record = [
       domain-id: domain-type
       members: [ +  domain-type ]
     ]

  5.1.11.2.  Domain Dependency Triple

     A Domain Dependency Triple (DDT) links a domain to a set of _trustee_
     domains.  A domain dependency triple is used by an Endorser to assert
     that a trust dependency exists between various components.  A DDT
     specifies which component (identified by domain-id) depends on which
     other components (identified by trustees) for proper operation.  A
     series of DDTs can be used to describe the trust dependencies of a
     system of components as a graph.  CoRIM uses environment-map to
     identify components and groupings of components (i.e., domains).

     Trust dependency means that an environment can only be fully trusted
     if one or more trustee environments have been appraised and found to
     be trustworthy.  A candidate environment can only be trusted if the
     trustee environments it depends on exist, have been appraised and are
     found to be trustworthy.

     The first four phases of appraisal (see Section 8.1) might not
     determine whether a component is trustworthy.  Subsequent Verifier
     stages or Relying Party processing might be needed to finalize
     trustworthiness.  Therefore, the trustworthiness of trustee domains
     MUST be appraised before the trustworthiness of the subject domain
     can be finalized.  Consequently, trust dependency semantics may need
     to be represented in Attestation Results if Relying Parties play a
     role in finalizing which components are trustworthy.

     There are a variety of use cases where trust dependency might exist.
     For example, trust in an operating system (OS) might depend on
     trustworthy loading of the OS loader image.  Consequently, the OS
     loader is a trustee domain of the OS.  Alternatively, trust in a
     peripheral device might depend on trustworthy operation of a
     perpheral device's bus controller.  The bus controller is therefore a
     trustee domain of the peripheral device.

     DDTs cannot create domains.  Instead, DDT processing first checks
     that a domain-id has already been accepted into the ACS before adding
     trust dependencies.




  Birkholz, et al.        Expires 3 September 2026               [Page 49]


  Internet-Draft                    CoRIM                       March 2026


     The domain dependency triple subject (domain-id) identifies the
     member domain (see Section 5.1.11.1) that has trustees.  The triple
     object trustees lists the domains that are trustees of the subject
     domain.  The triple predicate asserts that a trust appraisal of
     domain-id is not complete without appraisal of the trustees.

     domain-dependency-triple-record = [
       domain-id: domain-type
       trustees: [ + domain-type ]
     ]

     All of the DDT subjects (domain-id) and objects (trustees) MUST also
     be domain members for the DDT expression to be processed.

     Trust dependency graphs are acyclic, meaning a domain-id MUST NOT
     appear in the trustees list or within a trustee's subtree.

     A terminating "leaf" trustee is a "root of trust" for that subtree.
     Leaf trustees SHOULD have a corresponding Endorsement triple.
     Verifiers MAY use DDTs with appraisal policies to assess the veracity
     of domain-to-trustee linkages.

     Trust dependency typically exists if any of the following are true:

     *  A trustee performs any Attesting Environment functions relating to
        a Target Environment (TE), such as Claims collection, Claims
        signing, loading or initialization of the TE, provisioning TE
        secrets - including cryptographic keys or other security-relevant
        material.

     *  A trustee executes security-relevant code in response to an
        execution thread that originates from the domain-id environment.

     *  A trustee is a component embedded within another component
        identified by domain-id.

     Trust dependency processing is described in Section 9.1.8.

  5.1.12.  CoMID-CoSWID Linking Triple

     A CoSWID triple relates reference measurements contained in one or
     more CoSWIDs to a Target Environment.  The subject identifies a
     Target Environment, the object one or more unique tag identifiers of
     existing CoSWIDs, and the predicate asserts that these contain the
     expected (i.e., reference) measurements for the Target Environment.






  Birkholz, et al.        Expires 3 September 2026               [Page 50]


  Internet-Draft                    CoRIM                       March 2026


     ;# import rfc9393 as coswid

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

  5.2.  Extensibility

     The base CoRIM document definition is described using CDDL [RFC8610]
     that can be extended only at specific allowed points known as
     "extension points".

     The following types of extensions are supported in CoRIM.

  5.2.1.  Map Extensions

     Map extensions provide extensibility support to CoRIM map structures.
     CDDL map extensibility enables a CoRIM profile to extend the base
     CoRIM CDDL definition.  CDDL map extension points have the form
     ($$NAME-extension) where "NAME" is the name of the map and '$$'
     signifies map extensibility.  Typically, map extension requires a
     convention for code point naming that avoids code-point reuse.  Well-
     known code points may be in a registry, such as CoSWID [IANA.coswid].
     Non-negative integers are reserved for IANA to assign meaning
     globally.

  5.2.2.  Data Type Extensions

     Data type extensibility has the form ($NAME-type-choice) where "NAME"
     is the type name and '$' signifies type extensibility.

     New data type extensions SHOULD be documented to facilitate
     interoperability.  CoRIM profiles are best used to document vendor or
     industry defined extensions.

  6.  CoTL

     A Concise Tag List (CoTL) object represents the signal for the
     Verifier to activate the listed tags.  Verifier policy determines
     whether CoTLs are required.

     When CoTLs are required, each tag MUST be activated by a CoTL before
     being processed.  All the tags listed in the CoTL MUST be activated
     atomically.  If any tag activated by a CoTL is not available to the
     Verifier, the entire CoTL is rejected.





  Birkholz, et al.        Expires 3 September 2026               [Page 51]


  Internet-Draft                    CoRIM                       March 2026


     The number of CoTLs required in a given supply chain ecosystem is
     dependent on Verifier Owner's Appraisal Policy for Evidence.
     Corresponding policies are often driven by the complexity and nature
     of the use case.

     If a Verifier Owner has a policy that does not require CoTL, tags
     within a CoRIM received by a Verifier are activated immediately and
     treated valid for appraisal.

     There may be cases when Verifier receives CoRIMs from multiple
     Reference Value providers and Endorsers.  In such cases, a supplier
     (or other authorities, such as integrators) may be designated to
     issue a single CoTL to activate all the tags submitted to the
     Verifier in these CoRIMs.

     In a more complex case, there may be multiple authorities that issue
     CoTLs at different points in time.  An Appraisal Policy for Evidence
     may dictate how multiple CoTLs are to be processed within the
     Verifier.

  6.1.  Structure

     The CDDL specification for the concise-tl-tag map and additional
     grammatical requirements specified in the text of this Section MUST
     be followed when creating or validating a CoTL tag are given below:

     concise-tl-tag = {
       &(tag-identity: 0) => tag-identity-map
       &(tags-list: 1) => [ + tag-identity-map ],
       &(tl-validity: 2) => validity-map
     }

     The following describes each member of the concise-tl-tag map.

     *  tag-identity (index 0): A tag-identity-map containing unique
        identification information for the CoTL.  Described in
        Section 5.1.1.

     *  tags-list (index 1): One or more tag-identity-maps identifying the
        CoMID and CoSWID tags that constitute the list, i.e., a complete
        set of verification-related information.  The tags-list behaves
        like a signaling mechanism from the supply chain (e.g., a product
        vendor) to a Verifier that activates the tags in tags-list for use
        in the Evidence appraisal process, and the activation is atomic.
        All tags listed in tags-list MUST be activated or no tags are
        activated.





  Birkholz, et al.        Expires 3 September 2026               [Page 52]


  Internet-Draft                    CoRIM                       March 2026


     *  tl-validity (index 2): Specifies the validity period of the CoTL.
        Described in Section 7.3.

  7.  Common Types

     The following CDDL types may be shared by CoRIM, CoMID, and CoTL.

  7.1.  Non-Empty

     The non-empty generic type is used to express that a map with only
     optional members MUST at least include one of the members.

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

  7.2.  Entity

     The entity-map is a generic type describing an organization
     responsible for the contents of a manifest.  It is instantiated by
     supplying two parameters:

     *  A role-type-choice, i.e., a selection of roles that entities of
        the instantiated type can claim

     *  An extension-socket, i.e., a CDDL socket that can be used to
        extend the attributes associated with entities of the instantiated
        type

     entity-map<role-type-choice, extension-socket> = {
       &(entity-name: 0) => $entity-name-type-choice
       ? &(reg-id: 1) => uri
       &(role: 2) => [ + role-type-choice ]
       * extension-socket
     }

     $entity-name-type-choice /= text

     The following describes each member of the entity-map.

     *  entity-name (index 0): The name of entity which is responsible for
        the action(s) as defined by the role. $entity-name-type-choice can
        only be text.  Other specifications can extend the $entity-name-
        type-choice.  See Section 12.6.

     *  reg-id (index 1): A URI associated with the organization that owns
        the entity name.






  Birkholz, et al.        Expires 3 September 2026               [Page 53]


  Internet-Draft                    CoRIM                       March 2026


     *  role (index 2): A type choice defining the roles that the entity
        is claiming.  The role is supplied as a parameter at the time the
        entity-map generic is instantiated.

     *  extension-socket: A CDDL socket used to add new information
        structures to the entity-map.

     Examples of how the entity-map generic is instantiated can be found
     in (Section 4.1.5) and (Section 5.1.2).

  7.3.  Validity

     A validity-map represents the time interval during which the signer
     warrants that it will maintain information about the status of the
     signed object (e.g., a manifest).

     In a validity-map, both ends of the interval are encoded as epoch-
     based date/time as per Section 3.4.2 of [STD94].

     validity-map = {
       ? &(not-before: 0) => time
       &(not-after: 1) => time
     }

     *  not-before (index 0): the date on which the signed manifest
        validity period begins

     *  not-after (index 1): the date on which the signed manifest
        validity period ends

  7.4.  UUID

     Used to tag a byte string as a binary UUID.  Defined in Section 4 of
     [RFC9562].

     uuid-type = bytes .size 16
     tagged-uuid-type = #6.37(uuid-type)

  7.5.  UEID

     Used to tag a byte string as Universal Entity ID Claim (UEID).
     Defined in Section 4.2.1 of [RFC9711].

     ueid-type = bytes .size (7..33)
     tagged-ueid-type = #6.550(ueid-type)






  Birkholz, et al.        Expires 3 September 2026               [Page 54]


  Internet-Draft                    CoRIM                       March 2026


  7.6.  OID

     Used to tag a byte string as the BER encoding [X.690] of an absolute
     object identifier [RFC9090].

     oid-type = bytes
     tagged-oid-type = #6.111(oid-type)

  7.7.  Digest

     A digest represents the value of a hashing operation together with
     the hash algorithm used.  This specification reuses the digest type
     defined in Section 4.2 of [I-D.ietf-rats-eat-measured-component].
     Only the CBOR serialization is used.

     ;# import measured-component as eatmc

     digests-type = [ + eatmc.digest ]

     A measurement can be obtained using different hash algorithms.  A
     digests-type can be used to collect multiple digest values obtained
     by applying different hash algorithms on the same input.  Each entry
     in the digests-type MUST have a unique alg value.

  7.8.  Tagged Bytes Type

     An opaque, variable-length byte string.  It can be used in different
     contexts: as an instance, class or group identifier in an
     environment-map; as a raw value measurement in a measurement-values-
     map.  Its semantics are defined by the context in which it is found,
     and by the overarching CoRIM profile.  When used as an identifier the
     responsible allocator entity SHOULD ensure uniqueness within the
     context that it is used.

     tagged-bytes = #6.560(bytes)

  8.  Appraisal of CoRIM-based Inputs

     Inputs to a Verifier are mapped from their external representation to
     an internal representation.  CoRIM defines CBOR structures and
     content media types for Conceptual Messages that include Endorsements
     and Reference Values.  CoRIM data structures may also be used by
     Evidence and Attestation Results that wish to describe overlapping
     structure.  CoRIM-based data structures define an external
     representation of Conceptual Messages that are mapped to an internal
     representation.  Appraisal processing describes both mapping
     transformations and Verifier reconciliation (Section 2).  Non-CoRIM-
     based data structures require mapping transformation, but these are



  Birkholz, et al.        Expires 3 September 2026               [Page 55]


  Internet-Draft                    CoRIM                       March 2026


     out of scope for this document.

     If a CoRIM profile is specified, there are a few well-defined points
     in the procedure where Verifier behaviour depends on the profile.
     The CoRIM profile MUST provide a description of the expected Verifier
     behavior for each of those well-defined points.

     Verifier implementations MUST provide the specified information model
     of the Appraisal Context at the end of phase 4 as described in this
     specification.  They are not required to use the same internal
     representation or evaluation order described by this specification.

  8.1.  Appraisal Procedure

     The appraisal procedure is divided into several logical phases for
     clarity.

     *  *Phase 1*: Input Validation and Transformation

     During Phase 1, all available Conceptual Messages are processed for
     validation.  This involves checking digital signatures to verify
     their integrity and authenticity, ensuring they are not outdated, and
     confirming their relevance to the current appraisal.  If validation
     fails, the input Conceptual Message is discarded.  If validation
     succeeds, the input Conceptual Message is transformed from its
     external representation into an internal one.  These internal
     representations are then collected in an implementation-specific
     "staging area", which acts as a database for subsequent appraisal
     processing.

     *  *Phase 2*: Evidence Augmentation

     During Phase 2, Evidence inputs are added to a list that describes
     the Attester's actual state.  These inputs are added with the
     Attester's authority.

     *  *Phase 3*: Reference Values Corroboration and Augmentation

     During Phase 3, Reference Values inputs are compared with Evidence
     inputs.  Reference Values inputs describe possible states of
     Attesters.  If the actual state of the Attester is described by the
     possible Attester states, then the overlapping (corroborated) actual
     states are added to the Attester's actual state.  These inputs are
     added with the Reference Value Provider's authority.

     *  *Phase 4*: Endorsed Values Augmentation





  Birkholz, et al.        Expires 3 September 2026               [Page 56]


  Internet-Draft                    CoRIM                       March 2026


     During Phase 4, Endorsed Values inputs containing conditions that
     describe expected Attester state are processed.  If the comparison is
     satisfied, then additional Claims about the Attester are added to the
     ACS.  These inputs are added with the Endorser's authority.

     *  *Subsequent Phases*: Before producing an Attestation Result, a
        Verifier may go through subsequent phases of the appraisal
        procedure.

     For example, the Verifier may perform consistency, integrity, or
     additional validity checks.  These checks may result in additional
     Claims about the Attester that are added to the ACS.  These Claims
     are added with the Verifier's authority.

     Typically, a Verifier applies Appraisal Policy for Evidence on the
     ACS that describes desirable or undesirable Attester states.  If
     these conditions exist, the policy may add additional Claims about
     the Attester, to the ACS.  These Claims are added with the policy
     author's authority.

     Finally, the outcome of Appraisal and the set of Attester Claims of
     interest to a Relying Party are copied from the Attester state to an
     output staging area.  The Claims in the output staging area and other
     Verifier-related metadata are transformed into an external
     representation, suitable for consumption by a Relying Party.  This
     external representation is the Attestation Result message Section 8.4
     of [RFC9334].

     Please note, a detail description of Subsequent Phases is out of
     scope of this document.  They are mentioned here to provide an
     overall context to the Appraisal procedure.

  9.  Reference Verifier Sequence

     This document presumes that Verifier implementations will differ.  To
     facilitate the description of normative Verifier behavior, this
     document describes the internal representation for a reference
     Verifier and demonstrates how the data is used in the appraisal
     phases outlined in Section 8.1.  If the Verifier operates on CoRIM
     documents, it is RECOMMENDED that it follows this algorithm.

     The terms Claim, Environment-Claim Tuple (ECT), Authority, Appraisal
     Claims Set (ACS), Appraisal Policy, and Attestation Results Set (ARS)
     are used with the meaning defined in Section 1.1.1.







  Birkholz, et al.        Expires 3 September 2026               [Page 57]


  Internet-Draft                    CoRIM                       March 2026


                                                  .-------------------.
                                                .-+-----------------. |
                                              .-+-----------------. +-'
                                              |   CoRIM file(s)   +-'
                                              '---------+---------'
                                                        |
                                .-----------------------+------------.
                               | CoRIM Processor        v             |
                               |                .--------------.      |
                               |               | Validation &   |     |
                               |               | Internal Repr. |     |
                               |               | Transformation |     |
                               |                '-------+------'      |
         .----------------.    |                        |             |
         |    Evidence    |    |                        v             |
         '-------+--------'    |             .---------------------.  |
                 |             |             |    Staging Area     |  |
                 v             |             | .-----.     .-----. |  |
          .--------------.     |             | | ECT | ... | ECT | |  |
         | Validation &   |    |             | '-----'     '-----' |  |
         | Internal Repr. |    |             '----------+----------'  |
         | Transformation |    |                        |             |
          '------+-------'     |  .---------.           v             |
                 |             |  | .-----. |      .---------.        |
                  '------------+->| | ECT | +---->|           |       |
                               |  | '-----' |     | ACS       |       |
                               |  |   ...   |     | Condition |       |
                               |  | .-----. |     | Matching  |       |
                               |  | | ECT | |<----+           |       |
                               |  | '-----' |      '---------'        |
                               |  |   ACS   |                         |
                               |  '----+----'                         |
                               |       |                              |
                                '------+-----------------------------'
                                       v
                              .-----------------.       .-------------.
                             | Subsequent Phases +----->| Attestation |
                              '-----------------'       | Results     |
                                                        '-------------'


          Legend:                                  .-------.   .------.
            ACS = Appraisal Claims Set            | Process |  | Data |
            ECT = Environment-Claims Tuple         '-------'   '------'

                        Figure 1: CoRIM Processing Flow





  Birkholz, et al.        Expires 3 September 2026               [Page 58]


  Internet-Draft                    CoRIM                       March 2026


  9.1.  Processing of Conceptual Messages

     Conceptual Messages are Verifier input and output values such as
     Evidence, Reference Values, Endorsed Values, Appraisal Policy, and
     Attestation Results.

     All the Conceptual Messages once fully processed are transformed into
     a common internal representation known as Environment Claims
     Tuple(ECT).  This section describes the internal structure of ECT and
     explains the process of transformation of external conceptual
     messages into ECTs.

  9.1.1.  Internal structure of ECT

     Environment-Claims Tuples (ECT) have six attributes:

     1.  Environment : Identifies the Target Environment.  Environments
         are identified using instance, class, or group identifiers.
         Environments may be composed of elements, each having an element
         identifier (mkey).  If the Conceptual Message Type is domain-
         member, this field contains the domain identifier (domain-id) of
         the domain triple.

     2.  Elements : Identifies the set of elements contained within a
         Target Environment and their trustworthiness Claims.

     3.  Authority : Identifies the entity that issued the tuple.  A
         certain type of key material by which the authority (and
         corresponding provenance) of the tuple can be determined, such as
         the public key of an asymmetric key pair that is associated with
         an authority's PKIX certificate.

     4.  Members : Identifies the set of Environments that act as members
         when a Domain Membership is expressed in an ECT

     5.  Conceptual Message Type : Identifies the type of Conceptual
         Message that originated the tuple.

     6.  Profile : The profile that defines this tuple.  If no profile is
         used, this attribute is omitted.

     The following CDDL describes the ECT structure in more detail.









  Birkholz, et al.        Expires 3 September 2026               [Page 59]


  Internet-Draft                    CoRIM                       March 2026


     ECT = {
       ? environment: environment-map
       ? element-list: [ + element-map ]
       ? authority: [ + $crypto-key-type-choice ]
       ? members: [ + environment-map ]
       ? trustees: [ + environment-map ]
       ? cmtype: cm-type
       ? profile: $profile-type-choice
     }

     element-map = {
       ? element-id: $measured-element-type-choice
       element-claims: measurement-values-map
     }

     cm-type =  &(
       reference-values: 0
       endorsements: 1
       evidence: 2
       attestation-results: 3
       verifier: 4
       policy: 5
       domain-member: 6
       trustee: 7
     )

     The Conceptual Message type (cmtype) determines which attributes are
     mandatory.

  9.1.2.  Common Conventions for Input Transformation

     The following mapping conventions apply to all forms of input
     transformation:

        -  The environment field is populated with a Target Environment
           identifier.

        -  The element-list field is populated with the measurements
           collected by an Attesting Environment.

        -  The authority field is populated with the identity of the
           entity that asserted (e.g., signed) the Conceptual Message.

        -  The cmtype field is set based on the type of Conceptual Message
           inputted or to be output.

        -  The profile field is set based on the corim-map profile value.




  Birkholz, et al.        Expires 3 September 2026               [Page 60]


  Internet-Draft                    CoRIM                       March 2026


  9.1.3.  Processing of Evidence

  9.1.3.1.  Internal Representation of Evidence

     An internal representation of Attestation Evidence uses the ae
     relation. ae implies Attestation Evidence and refers to a collection
     of evidence ECTs.

     ae = [
       addition: [ + ECT ]
     ]

     The addition is a list of ECTs with Evidence to be appraised.

     A Verifier may maintain multiple simultaneous sessions to different
     Attesters.  Each Attester has a different ACS.  The Verifier ensures
     the Evidence inputs are associated with the correct ACS.  The
     addition is added to the ACS for a specific Attester.

     Table 3 contains the requirements for the ECT fields of the Evidence
     tuple:

                   +==========+==============+=============+
                   | ECT type | ECT Field    | Requirement |
                   +==========+==============+=============+
                   | addition | environment  | Mandatory   |
                   +----------+--------------+-------------+
                   |          | element-list | Mandatory   |
                   +----------+--------------+-------------+
                   |          | authority    | Mandatory   |
                   +----------+--------------+-------------+
                   |          | cmtype       | Mandatory   |
                   +----------+--------------+-------------+
                   |          | profile      | Optional    |
                   +----------+--------------+-------------+
                   |          | members      | n/a         |
                   +----------+--------------+-------------+
                   |          | trustees     | n/a         |
                   +----------+--------------+-------------+

                      Table 3: Evidence tuple requirements










  Birkholz, et al.        Expires 3 September 2026               [Page 61]


  Internet-Draft                    CoRIM                       March 2026


  9.1.3.2.  Evidence Transformation

     Evidence is transformed from an external representation to an
     internal representation as specified in Section 9.1.3.1.  The
     Evidence is mapped into one or more addition ECTs.  If the Evidence
     does not have a value for the mandatory ae fields, the Verifier MUST
     NOT process the Evidence.

     Evidence transformation algorithms may be well-known, defined by a
     CoRIM profile (Section 4.1.4), or supplied dynamically.  The handling
     of Evidence transformation algorithms is out of scope for this
     document.

  9.1.4.  Processing of Reference Value Triples

     Upon processing of CoRIMs containing Reference Value Triples, the RV
     Triples are transformed to an internal representation.

  9.1.4.1.  Internal Representation of Reference Values

     An internal representation of Reference Values uses the rv relation,
     which is a list of ECTs that contains possible states and a list of
     ECTs that contain actual states asserted with RVP authority.

     rv = [ + {
       condition: ECT
       addition: ECT
     } ]

     The rv relation is a list of condition-addition pairings where each
     pairing is evaluated together.  If the condition containing reference
     ECTs matches Evidence ECTs then the Evidence ECTs are re-asserted,
     but with RVP authority as contained in the addition and cmtype set to
     reference-values.

     The reference ECTs define the matching conditions that are applied to
     Evidence ECTs.  If the matching condition is satisfied, then the re-
     asserted ECTs are added to the ACS.  Refer to Section 9.3.3 for how
     the rv entries are processed.

     Table 4 contains the requirements for the ECT fields of the Reference
     Values tuple:









  Birkholz, et al.        Expires 3 September 2026               [Page 62]


  Internet-Draft                    CoRIM                       March 2026


                  +===========+==============+=============+
                  | ECT type  | ECT Field    | Requirement |
                  +===========+==============+=============+
                  | condition | environment  | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | element-list | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | authority    | Optional    |
                  +-----------+--------------+-------------+
                  |           | cmtype       | n/a         |
                  +-----------+--------------+-------------+
                  |           | profile      | n/a         |
                  +-----------+--------------+-------------+
                  |           | members      | n/a         |
                  +-----------+--------------+-------------+
                  |           | trustees     | n/a         |
                  +-----------+--------------+-------------+
                  | addition  | environment  | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | element-list | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | authority    | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | cmtype       | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | profile      | Optional    |
                  +-----------+--------------+-------------+
                  |           | members      | n/a         |
                  +-----------+--------------+-------------+
                  |           | trustees     | n/a         |
                  +-----------+--------------+-------------+

                       Table 4: Reference Values tuple
                                 requirements

  9.1.4.2.  Reference Triples Transformation

     Step 1.  An rv list entry (Section 9.1.4.1) is allocated.

     Step 2.  The cmtype of the addition ECT in the rv entry is set to
              reference-values.

     Step 3.  The Reference Values Triple (RVT) (Section 5.1.5) populates
              the rv ECTs.

     i  RVT.ref-env





  Birkholz, et al.        Expires 3 September 2026               [Page 63]


  Internet-Draft                    CoRIM                       March 2026


        *copy*(environment-map, rv.condition.environment.environment-
           map)

        *copy*(environment-map, rv.addition.environment.environment-
           map)

     ii For each e in RVT.ref-claims:

        *copy*(e.measurement-map, rv.condition.element-list.element-
           map)

     Step 4.  The signer of the Reference Values conceptual message is
              copied to the rv.addition.authority field.

     Step 5.  If the Reference Values conceptual message has a profile,
              the profile identifier is copied to the rv.addition.profile
              field.

  9.1.5.  Processing of Endorsed Value Triple, Conditional Endorsement
          Triple & Conditional Endorsement Series Triples

  9.1.5.1.  Internal Representation of Endorsed Values

     An internal representation of Endorsed Values uses the ev and evs
     relations, which are lists of ECTs that describe matching conditions
     and the additions that are added if the conditions are satisfied.
     The ev relation is applicable to Endorsed Values (EV) and Conditional
     Endorsement (CE) Triple.  The evs relation is applicable to the
     Conditional Endorsement Series Triples.

     ev = [
       condition: [ + ECT ]
       addition: [ + ECT ]
     ]

     evs = [
       condition: [ + ECT ]
       series: [ + {
         selection: [ + ECT ]
         addition: [ + ECT ]
       } ]
     ]

     The ev relation compares the condition ECTs to the ACS and if all of
     the ECTs are found in the ACS then the addition ECTs are added to the
     ACS.  Note, when ev relation is for EV Triple, then the element-list
     inside condition is Optional while it is Mandatory for CE Triple.




  Birkholz, et al.        Expires 3 September 2026               [Page 64]


  Internet-Draft                    CoRIM                       March 2026


     The evs relation compares the condition ECTs to the ACS and if all of
     the ECTs are found in the ACS then each entry in the series list is
     evaluated.  The selection ECTs are compared with the ACS and if the
     selection criteria is satisfied, then the addition ECTs are added to
     the ACS and evaluation of the series ends.  If the selection criteria
     is not satisfied, then evaluation procedes to the next series list
     entry.

     Table 5 contains the requirements for the ECT fields of the Endorsed
     Values and Endorsed Values Series tuples:

                  +===========+==============+=============+
                  | ECT type  | ECT Field    | Requirement |
                  +===========+==============+=============+
                  | condition | environment  | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | element-list | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | authority    | Optional    |
                  +-----------+--------------+-------------+
                  |           | cmtype       | n/a         |
                  +-----------+--------------+-------------+
                  |           | profile      | n/a         |
                  +-----------+--------------+-------------+
                  |           | members      | n/a         |
                  +-----------+--------------+-------------+
                  |           | trustees     | n/a         |
                  +-----------+--------------+-------------+
                  | selection | environment  | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | element-list | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | authority    | Optional    |
                  +-----------+--------------+-------------+
                  |           | cmtype       | n/a         |
                  +-----------+--------------+-------------+
                  |           | profile      | n/a         |
                  +-----------+--------------+-------------+
                  |           | members      | n/a         |
                  +-----------+--------------+-------------+
                  |           | trustees     | n/a         |
                  +-----------+--------------+-------------+
                  | addition  | environment  | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | element-list | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | authority    | Mandatory   |
                  +-----------+--------------+-------------+



  Birkholz, et al.        Expires 3 September 2026               [Page 65]


  Internet-Draft                    CoRIM                       March 2026


                  |           | cmtype       | Mandatory   |
                  +-----------+--------------+-------------+
                  |           | profile      | Optional    |
                  +-----------+--------------+-------------+
                  |           | members      | n/a         |
                  +-----------+--------------+-------------+
                  |           | trustees     | n/a         |
                  +-----------+--------------+-------------+

                    Table 5: Endorsed Values and Endorsed
                      Values Series tuples requirements

  9.1.5.2.  Endorsement Triples Transformations

  9.1.5.2.1.  Endorsed Values Triple Transformation

     Step 1.  An ev entry (Section 9.1.5.1) is allocated.

     Step 2.  The cmtype of the ev entry's addition ECT is set to
              endorsements.

     Step 3.  The Endorsed Values Triple (EVT) (Section 5.1.6) populates
              the ev ECTs.

     i  EVT.condition

        *copy*(environment-map, ev.condition.environment.environment-
           map)

        *copy*(environment-map, ev.addition.environment.environment-
           map)

     ii For each e in EVT.endorsement:

        *copy*(e.endorsement.measurement-map, ev.addition.element-
           list.element-map)

     Step 4.  The signer of the Endorsement conceptual message is copied
              to the ev.addition.authority field.

     Step 5.  If the Endorsement conceptual message has a profile, the
              profile is copied to the ev.addition.profile field.

  9.1.5.2.2.  Conditional Endorsement Triple Transformation

     Step 1.  An ev entry (Section 9.1.5.1) is allocated.





  Birkholz, et al.        Expires 3 September 2026               [Page 66]


  Internet-Draft                    CoRIM                       March 2026


     Step 2.  The cmtype of the ev entry's addition ECT is set to
              endorsements.

     Step 3.  Entries in the Conditional Endorsement Triple (CET)
              (Section 5.1.7) conditions list are copied to a suitable ECT
              in the internal representation.

     i  For each e in CET.conditions:

        *copy*(e.stateful-environment-record.environment.environment-
           map, ev.condition.environment.environment-map)

        *copy*(e.stateful-environment-record.claims-list.measurement-
           map, ev.condition.element-list.element-map)

     ii For each e in CET.endorsements:

        *copy*(e.endorsed-triple-record.condition.environment-map,
           ev.addition.environment.environment-map)

        *copy*(e.endorsed-triple-record.endorsement.measurement-map,
           ev.addition.element-list.element-map)

     Step 4.  The signer of the Conditional Endorsement conceptual message
              is copied to the ev.addition.authority field.

     Step 5.  If the Conditional Endorsement conceptual message has a
              profile, the profile is copied to the ev.addition.profile
              field.

  9.1.5.2.3.  Conditional Endorsement Series Triple Transformation

     Step 1.  An evs entry (Section 9.1.5.1) is allocated.

     Step 2.  The cmtype of the evs entry's addition ECT is set to
              endorsements.

     Step 3.  Populate the evs ECTs using the Conditional Endorsement
              Series Triple (CEST) (Section 5.1.8).

     i.  For c in CEST.condition:

        *copy*(c.environment, evs.condition.environment)

        If the c.claims-list is not empty then *copy*(c.claims-list,
           evs.condition.element-list)





  Birkholz, et al.        Expires 3 September 2026               [Page 67]


  Internet-Draft                    CoRIM                       March 2026


        If c.authorized-by is present then *copy*(c.authorized-by,
           evs.condition.authority)

     ii. For each s in CEST.series:

        *copy*(evs.condition.environment,
           evs.series[s].selection.environment)

        *copy*(s.selection, evs.series[s].selection.element-list)

        *copy*(evs.condition.environment,
           evs.series[s].addition.environment)

        *copy*(s.addition, evs.series[s].addition.element-list)

     Step 4.  The signer of the Conditional Endorsement Series conceptual
              message is copied to the evs.series.addition.authority field
              for each addition.

     Step 5.  If the Conditional Endorsement Series conceptual message has
              a profile, the profile is copied to the
              evs.series.addition.profile field for each addition.

  9.1.6.  Processing of Attest Key and Device Identity Key Triples

  9.1.6.1.  Internal Representation of Cryptographic Keys

     The internal representation for keys use the extension slot within
     measurement-values-map with the intrep-keys claim that consists of a
     list of typed-crypto-key. typed-crypto-key consists of a key and an
     optional key-type.  There are two types of keys attest-key and
     identity-key.

     $$measurement-values-map-extension //= (
       &(intrep-keys: 65534) => [ + typed-crypto-key ]
     )

     typed-crypto-key = {
       key: $crypto-key-type-choice
       ? key-type: uint .bits key-type
     }

     key-type = &(
       attest-key: 0
       identity-key: 1
     )





  Birkholz, et al.        Expires 3 September 2026               [Page 68]


  Internet-Draft                    CoRIM                       March 2026


  9.1.6.2.  Key Verification Triples Transformation

     The following transformation steps are applied for both the identity-
     triples and attest-key-triples with noted exceptions:

     Step 1.  An ev entry (Section 9.1.5.1) is allocated.

     Step 2.  The cmtype of the ev entry's addition ECT is set to
              endorsements.

     Step 3.  Populate the ev condition ECT using either the identity-
              triple-record or attest-key-triple-record (Section 5.1.9) as
              follows:

     i.    *copy*(environment-map, ev.condition.environment.environment-
           map).

     ii.   Foreach _key_ in keylist.$crypto-key-type-choice, *copy*(_key_,
           ev.condition.element-list.element-map.element-
           claims.measurement-values-map.intrep-keys.key).

     iii.  If key-list originated from attest-key-triples,
           *set*(ev.condition.element-list.element-map.element-
           claims.measurement-values-map.intrep-keys.key-type = attest-
           key).

     iv.   Else if key-list originated from identity-triples,
           *set*(ev.condition.element-list.element-map.element-
           claims.measurement-values-map.intrep-keys.key-type = identity-
           key).

     v.    If populated, *copy*(mkey, ev.condition.element-list.element-
           map.element-id).

     vi.   If populated, *copy*(authorized-by, ev.condition.authority).

     Step 4.  The signer of the Identity or Attest Key Endorsement
              conceptual message is copied to the ev.addition.authority
              field.

     Step 5.  If the Endorsement conceptual message has a profile, the
              profile is copied to the ev.addition.profile field.

  9.1.7.  Processing of Domain Membership Triples







  Birkholz, et al.        Expires 3 September 2026               [Page 69]


  Internet-Draft                    CoRIM                       March 2026


  9.1.7.1.  Internal Representation of Domain Membership

     An internal representation of Domain Membership is expressed in a
     single ECT, where the domain identifier is set in the environment
     field of the ECT, and the domain members are expressed in the members
     field.  The cmtype is set to domain-member.

     dm = [ + ( domain: ECT ) ]

     Table 6 contains the requirements for the ECT fields of the Domain
     Membership tuple:

                   +==========+==============+=============+
                   | ECT type | ECT Field    | Requirement |
                   +==========+==============+=============+
                   | domain   | environment  | Mandatory   |
                   +----------+--------------+-------------+
                   |          | element-list | Optional    |
                   +----------+--------------+-------------+
                   |          | authority    | Mandatory   |
                   +----------+--------------+-------------+
                   |          | cmtype       | Mandatory   |
                   +----------+--------------+-------------+
                   |          | profile      | Optional    |
                   +----------+--------------+-------------+
                   |          | members      | Mandatory   |
                   +----------+--------------+-------------+
                   |          | trustees     | Optional    |
                   +----------+--------------+-------------+

                        Table 6: Domain Membership tuple
                                  requirements

  9.1.7.2.  Domain Membership Triples Transformation

     This section describes how the external representation of a Domain
     Membership Triple (DMT) (Section 5.1.11.1) is transformed into its
     CoRIM internal representation dm (see Section 9.1.7.1).

     Step 1.  Allocate a domain ECT entry.

     Step 2.  Set the conceptual message type for the domain ECT to 6
              (domain-member).

     i  *copy*(domain-member, domain.cmtype)

     Step 3.  Set the authority for the domain ECT to the DMT signer
              (Section 4.2.3.1).



  Birkholz, et al.        Expires 3 September 2026               [Page 70]


  Internet-Draft                    CoRIM                       March 2026


     i  *copy*(DMT.signer, domain.authority)

     Step 4.  Use the DMT to populate the dm internal representation.

     i  *copy*(DMT.domain-id, domain.environment)

     ii For each environment *e* in DMT.members:

        *copy*(DMT.members[_e_].environment,
           domain.members[_e_].environment)

     Step 5.  If the conceptual message containing the DMT has a profile,
              it is used to populate the profile for the domain ECT.

     i  *copy*(DMT.profile, domain.profile)

  9.1.8.  Processing of Domain Dependency Triples

  9.1.8.1.  Internal Representation of Domain Dependency

     An internal representation of trust dependency is a directed acyclic
     graph where each node in the graph identifies a member domain and
     contains edges to dependent, or "trustee" domains.  An ECT structure
     environment field contains the domain identifier, and the ECT
     trustees list are the edges.  The cmtype is inclusive of trustee to
     indicate the ECT is being used to model a trust dependency graph.

     ddg = [ + ( dde: ECT ) ]

     Table 7 contains the requirements for the ECT fields of the Domain
     Dependency tuple:




















  Birkholz, et al.        Expires 3 September 2026               [Page 71]


  Internet-Draft                    CoRIM                       March 2026


                   +==========+==============+=============+
                   | ECT type | ECT Field    | Requirement |
                   +==========+==============+=============+
                   | domain   | environment  | Mandatory   |
                   +----------+--------------+-------------+
                   |          | element-list | Optional    |
                   +----------+--------------+-------------+
                   |          | authority    | Mandatory   |
                   +----------+--------------+-------------+
                   |          | cmtype       | Mandatory   |
                   +----------+--------------+-------------+
                   |          | profile      | Optional    |
                   +----------+--------------+-------------+
                   |          | members      | Mandatory   |
                   +----------+--------------+-------------+
                   |          | trustees     | Mandatory   |
                   +----------+--------------+-------------+

                        Table 7: Domain Dependency tuple
                                  requirements

  9.1.8.2.  Domain Dependency Triples Transformation

     This section describes how the external representation of a Domain
     Dependency Triple (DDT) (Section 5.1.11.2) is transformed into its
     CoRIM internal representation of a domain dependency graph (ddg) (see
     Section 9.1.8.1).

     For each domain-dependency-triple-record (ddtr) in the DDT list,
     perform the following steps:

     Step 1.  Allocate a domain dependency edge dde ECT entry.

     Step 2.  Set the conceptual message type cmtype for the dde ECT to
              trustee.

     i  *assign*(trustee, dde.cmtype)

     Step 3.  Set the authority for the trust domain ECT to the ddt signer
              (Section 4.2.3.1).

     i  *copy*(ddtr.signer, dde.authority)

     Step 4.  Populate the ECT environment using the domain identifier.

     i  *copy*(ddtr.domain-id, dde.environment)

     Step 5.  Populate the ECT trustees.



  Birkholz, et al.        Expires 3 September 2026               [Page 72]


  Internet-Draft                    CoRIM                       March 2026


     i  For each environment _e_ in ddtr.trustees:

        *copy*([_e_].environment, dde.trustees[_e_].environment)

     Step 6.  If the conceptual message containing the DDT has a profile,
              it is used to populate the profile for the dde ECT.

     i  *copy*(ddtr.profile, dde.profile)

     Append the domain dependency edge (dde) to the domain dependency
     graph (ddg).

     Process each domain dependency triple record (ddtr) in the DDT list
     until every entry has been transformed to the internal representation
     and is contained in the domain dependency graph.

     The domain dependency graph becomes input to domain dependency
     processing steps in Section 9.3.4.6.

  9.2.  Input Validation and Transformation (Phase 1)

     During the initialization phase, the CoRIM Appraisal Context is
     loaded with various conceptual message inputs such as CoMID tags
     (Section 5), CoSWID tags [RFC9393], CoTL tags, and cryptographic
     validation key material (including raw public keys, root
     certificates, intermediate CA certificate chains), and Concise Trust
     Anchor Stores (CoTS) [I-D.ietf-rats-concise-ta-stores].  These
     objects will be utilized in the Evidence Appraisal phase that
     follows.  The primary goal of this phase is to ensure that all
     necessary information is available for subsequent processing.

     After context initialization, additional inputs are held back until
     appraisal processing has completed.

  9.2.1.  Input Validation

  9.2.1.1.  CoRIM Selection

     All available CoRIMs are collected.

     CoRIM tags MUST be discarded if they are expired, or if they are not
     associated with an authenticated and authorized source, or if they
     have been revoked by an authorized source.

     Any CoRIM that has been secured by a cryptographic mechanism that
     fails validation MUST be discarded.  An example of such a mechanism
     is a digital signature.




  Birkholz, et al.        Expires 3 September 2026               [Page 73]


  Internet-Draft                    CoRIM                       March 2026


     Other selection criteria MAY be applied.  For example, if the
     Evidence format is known in advance, CoRIMs using a profile that is
     not understood by a Verifier can be readily discarded.

     Later stages will further select the CoRIMs appropriate to the
     Evidence Appraisal stage.

  9.2.1.2.  CoRIM Trust Anchors

     If CoRIM tags are signed, the signatures MUST be validated using the
     appropriate trust anchors (certification paths) available to the
     Verifier.  The Verifier is expected to have a trust anchor store.
     The way in which these trust anchors (i.e., root certificates) are
     provisioned in the Verifier is beyond the scope of this
     specification.  If signed, the CoRIM itself should include at least
     one certificate (e.g., as part of the x5chain in the COSE header),
     which corresponds to the key pair used for signing.  This certificate
     (the "leaf certificate") must be linked to one of the Verifier trust
     anchors.

  9.2.1.3.  Tags Extraction and Validation

     The Verifier chooses tags from the selected CoRIMs - including CoMID,
     CoSWID, CoTL, and CoTS.

     The Verifier MUST discard all tags which are not syntactically and
     semantically valid.  Cross-referenced triples MUST be successfully
     resolved.  An example of a cross-referenced triple is a CoMID-CoSWID
     linking triple.

  9.2.1.4.  CoTL Extraction

     This section is not applicable if the Verifier appraisal policy does
     not require CoTLs.

     CoTLs which are not within their validity period MUST be discarded.

     The Verifier processes all CoTLs that are valid at the point in time
     of Evidence Appraisal and activates all tags referenced therein.












  Birkholz, et al.        Expires 3 September 2026               [Page 74]


  Internet-Draft                    CoRIM                       March 2026


     The Verifier MAY decide to discard some of the available and valid
     CoTLs depending on any locally configured authorization policies.
     Such policies model the trust relationships between the Verifier
     Owner and the relevant suppliers, and are out of the scope of the
     present document.  For example, a composite device (Section 3.3 of
     [RFC9334]) is likely to be fully described by multiple CoRIMs, each
     signed by a different supplier.  In such a case, the Verifier Owner
     may instruct the Verifier to discard tags activated by supplier CoTLs
     that are not also activated by the trusted integrator.

     After the Verifier has processed all CoTLs it MUST discard any tags
     which have not been activated by a CoTL.

  9.2.2.  Evidence Collection

     During the Evidence collection phase, the Verifier communicates with
     Attesters to gather Evidence.  Discovery of Evidence sources is
     untrusted.  Verifiers may rely on conveyance protocol specific
     context to identify an Evidence source, which is the Evidence input
     oracle for appraisal.

     The collected Evidence is then transformed to an internal
     representation, making it suitable for appraisal processing.

     The exact protocol used to collect Evidence is out of scope of this
     specification.

  9.2.2.1.  Cryptographic Validation of Evidence

     If Evidence is cryptographically signed, its validation is applied
     before transforming Evidence to an internal representation.

     If Evidence is not cryptographically signed, the underlying
     conveyance protocol that collected it, should provide the required
     security.  In such cases, the cryptographic validation of Evidence is
     determined by the security offered by the conveyance protocol.

     The way cryptographic signature validation works depends on the
     specific Evidence collection method used.  For example, in DICE, a
     proof of liveness is carried out on the final key in the certificate
     chain (a.k.a., the alias certificate).  If this is successful, a
     suitable certification path is looked up in the Appraisal Context,
     based on linking information obtained from the DeviceID certificate.
     See Section 9.2.1 of [DICE.Layer].  If a trusted root certificate is
     found, X.509 certificate validation is performed.






  Birkholz, et al.        Expires 3 September 2026               [Page 75]


  Internet-Draft                    CoRIM                       March 2026


     As a second example, in PSA [RFC9783] the verification public key is
     looked up in the appraisal context using the ueid claim found in the
     PSA claims-set.  If found, COSE Sign1 verification is performed
     accordingly.

     Regardless of the specific integrity protection method used, the
     Verifier MUST NOT process Evidence which is not successfully
     validated.

     Once Evidence is validated it is transformed into an internal
     representation as given in Section 9.1.3.

  9.2.3.  Input Transformation

     Input Conceptual Messages, whether Evidence, Reference Values,
     Endorsements, or Policies, are transformed to an internal
     representation that is based on ECTs (Section 9.1).

  9.2.3.1.  Appraisal Context Construction

     All of the extracted and validated tags are loaded into an _appraisal
     context_. The Appraisal Context contains an internal representation
     of the inputted Conceptual Messages.  The selected tags are mapped to
     an internal representation, making them suitable for appraisal
     processing.  As the Conceptual Messages are processed during
     Appraisal, the _appraisal context_ starts to get populated using a
     data structure as given below.  See Section 9.2.4

  9.2.4.  Internal Representation of Appraisal Claims Set (ACS)

     An ACS is a list of ECTs that describe an Attester's actual state.

     For ECTs present in the ACS, the cmtype field is mandatory.
     Table Table 8 shows the minimum required mandatory fields applicable
     to all ECTs in an ACS.

                   +==========+=============+=============+
                   | ECT type | ECT Field   | Requirement |
                   +==========+=============+=============+
                   | n/a      | environment | Mandatory   |
                   +----------+-------------+-------------+
                   |          | authority   | Mandatory   |
                   +----------+-------------+-------------+
                   |          | cmtype      | Mandatory   |
                   +----------+-------------+-------------+

                   Table 8: ACS tuple minimum requirements




  Birkholz, et al.        Expires 3 September 2026               [Page 76]


  Internet-Draft                    CoRIM                       March 2026


     ACS = [ + ECT ]

  9.3.  ACS Augmentation - Phases 2, 3, and 4

     In the ACS augmentation phase, a CoRIM Appraisal Context and an
     Evidence Appraisal Policy are used by the Verifier to find CoMID
     triples which match the ACS.  Triples that specify an ACS matching
     condition will augment the ACS with Endorsements if the condition is
     met.

     Each triple is processed independently of other triples.  However,
     the ACS state may change as a result of processing a triple.  If a
     triple condition does not match, then the Verifier continues to
     process other triples.

  9.3.1.  ACS Requirements

     At the end of the Evidence collection process, the Evidence has been
     converted into an internal representation suitable for appraisal.
     See Section 9.1.

     Verifiers are not required to use this as their internal
     representation.  For the purposes of this document, appraisal is
     described in terms of the above cited internal representation.

  9.3.1.1.  ACS Processing Requirements

     The ACS contains the actual state of Attester's Target Environments
     (TEs).  The ACS contains Evidence ECTs (from Attesters) and
     Endorsement ECTs (e.g. from endorsed-triple-record).

     CoMID Reference Values will be matched against the ACS following the
     comparison rules in Section 9.4.

     Each Endorsement ECT contains the environment and internal
     representation of measurement-maps as extracted from an endorsed-
     triple-record.  When an endorsed-triple-record is transformed to
     Endorsements ECTs it indicates that the authority named by
     measurement-map.authorized-by asserts that the actual state of one or
     more Claims within the Target Environment, as identified by
     environment-map, have the measurement values in measurement-map.mval.

     ECT authority is represented by cryptographic keys.  Authority is
     asserted by digitally signing a Claim using the key.  Hence, Claims
     are added to the ACS under the authority of a cryptographic key.






  Birkholz, et al.        Expires 3 September 2026               [Page 77]


  Internet-Draft                    CoRIM                       March 2026


     Each Claim is encoded as an ECT.  The environment-map, the mkey or
     element-id, and a key within measurement-values-map encode the name
     of the Claim.  The value matching that key within measurement-values-
     map is the actual state of the Claim.

     This specification does not assign special meanings to any Claim
     name, it only specifies rules for determining when two Claim names
     are the same.

     If two Claims have the same environment-map encoding then this does
     not trigger special encoding in the Verifier.  The Verifier follows
     instructions in the CoRIM file which tell it how claims are related.

     If Evidence or Endorsements from different sources has the same
     environment-map and authorized-by then the measurement-values-maps
     are merged.

     The ACS MUST maintain the authority information for each ECT.  There
     can be multiple entries in state-triples which have the same
     environment-map and a different authority.  See Section 9.3.2.2.

     If the merged measurement-values-map contains duplicate codepoints
     and the measurement values are equivalent, then duplicate claims
     SHOULD be omitted.  Equivalence typically means values MUST be binary
     identical.

     If the merged measurement-values-map contains duplicate codepoints
     and the measurement values are not equivalent, then the Verifier
     SHALL report an error and stop validation processing.

  9.3.1.1.1.  Ordering of triple processing

     Triples interface with the ACS by either adding new ACS entries or by
     matching existing ACS entries before updating the ACS.  Most triples
     use an environment-map field to select the ACS entries to match or
     modify.  This field may be contained in an explicit matching
     condition, such as stateful-environment-record.

     The order of triples processing is important.  Processing a triple
     may result in ACS modifications that affect matching behavior of
     other triples.

     The Verifier MUST ensure that a triple including a matching condition
     is processed after any other triple that modifies or adds an ACS
     entry with an environment-map that is in the matching condition.






  Birkholz, et al.        Expires 3 September 2026               [Page 78]


  Internet-Draft                    CoRIM                       March 2026


     This can be acheived by sorting the triples before processing, by
     repeating processing of some triples after ACS modifications or by
     other algorithms.

  9.3.1.2.  ACS Augmentation Requirements

     The ordering of ECTs in the ACS is not significant.  Logically, the
     ACS represents the conjunction of all claims, so adding an ECT entry
     to the existing ACS at the end is equivalent to inserting it anywhere
     else.  Implementations may optimize ECT order to achieve better
     performance.  Additions to the ACS MUST be atomic.

  9.3.2.  Evidence Augmentation (Phase 2)

  9.3.2.1.  Appraisal Claims Set Initialization

     The ACS is initialized by copying the internal representation of
     Evidence claims to the ACS.  See Section 9.3.

  9.3.2.2.  The authority field in the ACS

     The authority field in an ACS ECT indicates the entity whose
     authority backs the Claims.

     The Verifier keeps track of authority so that it can satisfy
     appraisal policy that specifies authority.

     When adding an Evidence entry to the ACS, the Verifier SHALL set the
     authority field using a $crypto-keys-type-choice representation of
     the entity that signed the Evidence.

     If multiple authorities approve the same Claim, for example if
     multiple key chains are available, then the authority field SHALL be
     set to include the $crypto-keys-type-choice representation for each
     key chain.

     When adding Endorsement or Reference Values Claims to the ACS that
     resulted from CoRIM processing, the Verifier SHALL set the authority
     field using a $crypto-keys-type-choice representation of the entity
     that signed the CoRIM.

     When searching the ACS for an entry which matches a triple condition
     containing an authorized-by field, the Verifier SHALL ignore ACS
     entries if none of the entries present in the condition authorized-by
     field are present in the ACS authority field.  The Verifier SHALL
     match ACS entries if all of the entries present in the condition
     authorized-by field are present in the ACS authority field.




  Birkholz, et al.        Expires 3 September 2026               [Page 79]


  Internet-Draft                    CoRIM                       March 2026


  9.3.2.3.  ACS augmentation using CoMID triples

     In the ACS augmentation phase, a CoRIM Appraisal Context and an
     Evidence Appraisal Policy are used by the Verifier to find CoMID
     triples which match the ACS.  Triples that specify an ACS matching
     condition will augment the ACS with Endorsements if the condition is
     met.

     Each triple is processed independently of other triples.  However,
     the ACS state may change as a result of processing a triple.  If a
     triple condition does not match, then the Verifier continues to
     process other triples.

  9.3.3.  Reference Values Corroboration and Augmentation (Phase 3)

     Reference Value Providers (RVP) publish Reference Values using the
     Reference Values Triple (Section 5.1.5) which are transformed
     (Section 9.1.4.2) into an internal representation (Section 9.1.4.1).
     Each Reference Value Triple describes a single possible Attester
     state.

     Corroboration is the process of determining whether actual Attester
     state (as contained in the ACS) can be satisfied by Reference Values.

     Reference Values are matched with ACS entries by iterating through
     the rv list.  For each rv entry, the condition ECT is compared with
     an ACS ECT, where the ACS ECT cmtype contains evidence.

     If satisfied, for the rv entry, the following three steps are
     performed:

     1.  The addition ECT is moved to the ACS, with cmtype set to
         reference-values

     2.  The claims, i.e., the element-list from the ACS ECT with cmtype
         set to evidence is copied to the element-list of the addition ECT

     3.  The authority field of the addition ECT has been confirmed as
         being set correctly to the RVP authority

  9.3.4.  Endorsed Values Augmentation (Phase 4)

     Endorsers publish Endorsements using endorsement triples (see
     Section 5.1.6), Section 5.1.7, and Section 5.1.8) which are
     transformed (Section 9.1.5.2) into an internal representation
     (Section 9.1.5.1).  Endorsements describe actual Attester state.
     Endorsements are added to the ACS if the Endorsement condition is
     satisifed by the ACS.



  Birkholz, et al.        Expires 3 September 2026               [Page 80]


  Internet-Draft                    CoRIM                       March 2026


  9.3.4.1.  Processing Endorsements

     Endorsed Values Triple and Conditional Endorsement Triple share the
     same internal representation.

     After transformation into an ev entry, the processing steps of both
     triples are the same, as described below.  Each ev entry is processed
     independently of other evs.

     Endorsements are matched with ACS entries by iterating through the ev
     list.  For each ev entry, the condition ECT is compared with an ACS
     ECT, where the ACS ECT cmtype contains either evidence, reference-
     values, or endorsements.  If the ECTs match (Section 9.4), the ev
     addition ECT is added to the ACS.

     Some condition values can match against multiple ACS-ECTs, or sets of
     ACS-ECTs.  If there are multiple matches, then each match is
     processed independently from the others.

  9.3.4.2.  Processing Conditional Endorsements

     Conditional Endorsement Triples are transformed into an internal
     representation based on ev.  Conditional endorsements have the same
     processing steps as shown in (Section 9.3.4.1).

  9.3.4.3.  Processing Conditional Endorsement Series

     Conditional Endorsement Series Triples are transformed into an
     internal representation based on evs.  Conditional series
     endorsements are matched with ACS entries first by iterating through
     the evs list, where for each evs entry, the condition ECT is compared
     with an ACS ECT, where the ACS ECT cmtype contains either evidence,
     reference-values, or endorsements.  If the ECTs match (Section 9.4),
     the evs series array is iterated, where for each series entry, if the
     selection ECT matches an ACS ECT, the addition ECT is added to the
     ACS.  Series iteration terminates after the first matching series
     entry is processed or when no series entries match.

  9.3.4.4.  Processing Key Verifications

     To process key verification triples, the internal representation of
     ECTs containing intrep-keys is used to identify ACS entries
     containing $crypto-key-type-choice values that require additional key
     verification steps.  If the key-type field is set, the Verifier will
     apply the verification steps defined below.  If the key verification
     check succeeds, the key is re-asserted by the Verifier as an
     Endorsement by constructing an ECT that contains the verified key
     using the authority of the Verifier.  Note that, in this case, the



  Birkholz, et al.        Expires 3 September 2026               [Page 81]


  Internet-Draft                    CoRIM                       March 2026


     Verifier is acting in the role of an Endorser.

     For each ECT from endorsed value (ev) or attestation evidence (ae)
     entries, the candidate ECT (C-ECT) is compared with an ACS ECT (ACS-
     ECT), where the ACS-ECT cmtype contains either evidence or
     endorsements.  If the C-ECT and ACS-ECT match (Section 9.4), then for
     each _key_ in the C-ECT.element-claims.measurement-values-map.intrep-
     keys, do the following steps:

     Step 1.  Verify the certificate signatures for each certificate in
              the certification path.

     Step 2.  Verify certificate revocation status for each certificate in
              the certification path.

     Step 3.  Verify key usage restrictions appropriate for the type of
              key in key-type.

     Step 4.  If key verification succeeds for any _key_, allocate an
              addition ECT (ADDITION).

     Step 5.  For each verified _key_ in C-ECT:

     i  *append*(_key_, ADDITION.element-list.element-map.element-
        claims.measurement-values-map.intrep-keys).

     Step 6.  *copy*(ACS-ECT.environment, ADDITION.environment`).

     Step 7.  *copy*(ACS-ECT.element-list.element-map.element-id,
              ADDITION.element-list.element-map.element-id).

     Step 8.  Set ADDITION.cmtype to endorsements.

     Step 9.  Add the Verifier authority $crypto-key-type-choice to the
              ADDITION.authority field.

     Step 10. Add the ADDITION to the ACS.

     Otherwise, do not add the ADDITION to the ACS.

     It is possible that a candidate key has been verified during Phase 1
     processing (Section 9.2) or is replicated across Evidence or
     Endorsement ECTs.  Implementations might optimize processing of key
     verifications by checking whether a key has already been verified by
     the Verifier.






  Birkholz, et al.        Expires 3 September 2026               [Page 82]


  Internet-Draft                    CoRIM                       March 2026


  9.3.4.5.  Processing Domain Membership

     This section assumes that each Domain Membership Triple (see
     Section 5.1.11.1) has been transformed into an internal
     representation following the steps described in Section 9.1.7.2,
     resulting in the representation specified in Section 9.1.7.1.

     Domain Membership ECTs (i.e., cmtype equals domain-member) in the dm
     staging area are matched with ACS entries where cmtype is set to
     evidence, reference-values i.e. corroborated evidence, or domain-
     member using the following algorithm:

     For each domain in the dm staging area, which has not been processed
     (outer loop):

     For each member m in domain.members (inner loop):

     *  Check that there is a corresponding ACS entry environment that
        matches m.environment.

     *  Check that the ACS entry cmtype is one of evidence, reference-
        values, or domain-member.

     Outer loop resumes:

     *  If all domain.members matched a corresponding ACS entry, add the
        domain ECT to the ACS.

     *  If none of the domain.members matched, proceed to next dm entry.

     *  If some, but not all of the domain.members matched, proceed to the
        next dm entry.  If the previous execution of the outer loop added
        any domain entry to the ACS, then run the outer loop again Else
        STOP processing dm entries.

     The processing terminates, when all the Domain Membership ECTs which
     are appropriate to the Evidence have been added to the ACS.

     If any of the expected Domain Membership ECTs have not been added to
     the ACS, then this may affect outcomes in subsequent phases.

  9.3.4.6.  Processing Domain Dependency

     This section assumes that each Domain Dependency Triple (see
     Section 5.1.11.2) has been transformed into domain dependency graph
     (see Section 9.1.8.1) following the steps described in
     Section 9.1.8.2.




  Birkholz, et al.        Expires 3 September 2026               [Page 83]


  Internet-Draft                    CoRIM                       March 2026


     Processing a domain dependency graph (DDG) has the following
     objectives:

     *  Verify each edge in a DDG has a corresponding edge in a domain
        membership graph.  DDGs need not be isomorphic to domain
        membership graphs.

     *  Verify the DDG is acyclic.

     If, in a later processing phase, an appraisal policy for trust
     dependency exists, the DDG can be further evaluated.  For example, a
     trust dependency policy might specify a strength of function
     requirement for how Evidence about a TE is integrity protected by its
     AE.

     Domain Dependency ECTs are processed using the following algorithm:

     For each dde in the ddg staging array (outer loop):

     *  Check that the ACS.cmtype contains domain-member.

     *  Check that the dde.environment matches a domain member ACS entry
        environment.

     *  OR that the dde.environment matches one of it's
        ACS.members.environment.

     For each trustee _t_ in dde.trustees (inner loop):

     *  Check that the ACS.cmtype contains domain-member.

     *  Check that _t_ matches an ACS.environment.

     Outer loop resumes:

     *  If the dde.environment record AND all dde.trustees matched an ACS
        with cmtype domain-member entry.  Then add the dde to the ACS.

     *  Continue to the next dde until all are processed.

     Subsequent Verifier stages or Relying Party processing of the ACS can
     be impacted when Domain Dependency ECTs are not added to the ACS.
     For example, trust in an ACS entry that depends on trustee ACS
     entries might not be considered.







  Birkholz, et al.        Expires 3 September 2026               [Page 84]


  Internet-Draft                    CoRIM                       March 2026


  9.4.  Comparing a condition ECT against the ACS

     The Verifier SHALL iterate over all ACS entries and SHALL attempt to
     match the condition ECT against each ACS entry.  See Section 9.4.1.
     The Verifier SHALL create a "matched entries" set, and SHALL populate
     it with all ACS entries which matched the condition ECT.

     If the matched entries array is not empty, then the condition ECT
     matches the ACS.

     If the matched entries array is empty, then the condition ECT does
     not match the ACS.

  9.4.1.  Comparing a condition ECT against a single ACS entry

     If the condition ECT contains a profile and the profile defines an
     algorithm for a codepoint and environment-map then the Verifier MUST
     use the algorithm defined by the profile, or it MUST use a standard
     algorithm if the profile defines that.  If the condition ECT contains
     a profile, but the profile does not define an algorithm for a
     particular codepoint and environment-map then the verifier MUST use
     the standard algorithm described in this document to compare the data
     at that codepoint.

     The Verifier SHALL perform all of the comparisons defined in
     Section 9.4.2, Section 9.4.3, and Section 9.4.4.

     Each of these comparisons compares one field in the condition ECT
     against the same field in the ACS entry.

     If all of the fields match, then the condition ECT matches the ACS
     entry.

     If any of the fields does not match, then the condition ECT does not
     match the ACS entry.

  9.4.2.  Environment Comparison

     The Verifier SHALL compare each field which is present in the
     condition ECT environment-map against the corresponding field in the
     ACS entry environment-map using binary comparison.  Before performing
     the binary comparison, the Verifier SHOULD convert both environment-
     map fields into a form which meets CBOR Core Deterministic Encoding
     Requirements [STD94].

     If all fields which are present in the condition ECT environment-map
     (e.g., instance-id or group-id) are also present in the ACS entry and
     are binary identical, then the environments match.



  Birkholz, et al.        Expires 3 September 2026               [Page 85]


  Internet-Draft                    CoRIM                       March 2026


     If any field which is present in the condition ECT environment-map is
     not present in the ACS entry, then the environments do not match.

     If any field which is present in the condition ECT environment-map is
     not binary identical to the corresponding ACS entry field, then the
     environments do not match.

     If a field is not present in the condition ECT environment-map then
     the presence of, and value of, the corresponding ACS entry field
     SHALL NOT affect whether the environments match.

  9.4.3.  Authority comparison

     The Verifier MUST compare byte-by-byte the condition ECT's authority
     value to the candidate entry's authority value.

     If every entry in the condition ECT authority matches byte-by-byte a
     corresponding entry in the ACS entry authority field, then the
     authorities match.  The order of the fields in each authority field
     do not affect the result of the comparison.

     If any entry in the condition ECT authority does not have a matching
     entry in the ACS entry authority field then the authorities do not
     match.

     When comparing two $crypto-key-type-choice fields for equality, the
     Verifier SHALL treat them as equal if their deterministic CBOR
     encoding is binary equal.

  9.4.4.  Element list comparison

     The Verifier SHALL iterate over all the entries in the condition ECT
     element-list and compare each one against the corresponding entry in
     the ACS entry element-list.

     If every entry in the condition ECT element-list has a matching entry
     in the ACS entry element-list field then the element lists match.

     The order of the fields in each element-list field do not affect the
     result of the comparison.

     If any entry in the condition ECT element-list does not have a
     matching entry in the ACS entry element-list field then the element-
     list do not match.







  Birkholz, et al.        Expires 3 September 2026               [Page 86]


  Internet-Draft                    CoRIM                       March 2026


  9.4.5.  Element map comparison

     The Verifier SHALL compare each element-map within the condition ECT
     element-list against the ACS entry element-list.

     First, the Verifier SHALL locate the entries in the ACS entry
     element-list which have a matching element-id as the condition ECT
     element-map.  Two element-id fields are the same if they are either
     both omitted, or both present with binary identical deterministic
     encodings.

     Before performing the binary comparison, the Verifier SHOULD convert
     both fields into a form which meets CBOR Core Deterministic Encoding
     Requirements [STD94].

     If any condition ECT entry element-id does not have a corresponding
     element-id in the ACS entry then the element map does not match.

     If any condition ECT entry has multiple corresponding element-ids
     then the element map does not match.

     Second, the Verifier SHALL compare the element-claims field within
     the condition ECT element-list and the corresponding field from the
     ACS entry.  See Section 9.4.6.

  9.4.6.  Measurement values map map Comparison

     The Verifier SHALL iterate over the codepoints which are present in
     the condition ECT element's measurement-values-map.  Each of the
     codepoints present in the condition ECT measurement-values-map is
     compared against the same codepoint in the candidate entry
     measurement-values-map.

     If any codepoint present in the condition ECT measurement-values-map
     does not have a corresponding codepoint within the candidate entry
     measurement-values-map then Verifier SHALL remove that candidate
     entry from the candidate entries array.

     If any codepoint present in the condition ECT measurement-values-map
     does not match the same codepoint within the candidate entry
     measurement-values-map then Verifier SHALL remove that candidate
     entry from the candidate entries array.

  9.4.6.1.  Comparison of a single measurement-values-map codepoint

     The Verifier SHALL compare each condition ECT measurement-values-map
     value against the corresponding ACS entry value using the appropriate
     algorithm.



  Birkholz, et al.        Expires 3 September 2026               [Page 87]


  Internet-Draft                    CoRIM                       March 2026


     Non-negative codepoints represent standard data representations.  The
     comparison algorithms for these are defined in this document (in the
     sections below) or in other specifications.  For some non-negative
     codepoints their behavior is modified by the CBOR tag at the start of
     the condition ECT measurement-values-map value.

     Negative codepoints represent profile defined data representations.
     The Verifier SHALL use the codepoint number, the profile associated
     with the condition ECT, and, if present, the tag value to select the
     comparison algorithm.

     If the Verifier is unable to determine the comparison algorithm which
     applies to a codepoint then it SHALL behave as though the candidate
     entry does not match the condition ECT.

     Profile writers SHOULD use CBOR tags for widely applicable comparison
     methods to ease Verifier implementation compliance across profiles.

     The following subsections define the comparison algorithms for the
     measurement-values-map codepoints defined by this specification.

  9.4.6.1.1.  Comparison for version entries

     The value stored under measurement-values-map codepoint 0 is an
     version label, which MUST have type version-map.  Two version-map
     values can only be compared for equality, as they are colloquial
     versions that cannot specify ordering.

  9.4.6.1.2.  Comparison for svn entries

     The ACS entry value stored under measurement-values-map codepoint 1
     is a security version number, which MUST have type svn-type.

     If the entry svn-type is a uint or a uint tagged with #6.552, then
     comparison with the uint named as SVN is as follows.

     *  If the condition ECT value for measurement-values-map codepoint 1
        is an untagged uint or a uint tagged with #6.552 then an equality
        comparison is performed on the uint components.  The comparison
        MUST return true if the value of SVN is equal to the uint value in
        the condition ECT.

     *  If the condition ECT value for measurement-values-map codepoint 1
        is a uint tagged with #6.553 then a minimum comparison is
        performed.  The comparison MUST return true if the uint value in
        the condition ECT is less than or equal to the value of SVN.





  Birkholz, et al.        Expires 3 September 2026               [Page 88]


  Internet-Draft                    CoRIM                       March 2026


     If the entry svn-type is a uint tagged with #6.553, then comparison
     with the uint named as MINSVN is as follows.

     *  If the condition ECT value for measurement-values-map codepoint 1
        is an untagged uint or a uint tagged with #6.552 then the
        comparison MUST return false.

     *  If the condition ECT value for measurement-values-map codepoint 1
        is a uint tagged with #6.553 then an equality comparison is
        performed.  The comparison MUST return true if the value of MINSVN
        is equal to the uint value in the condition ECT.

     The meaning of a minimum SVN as an entry value is only meaningful as
     an endorsed value that has been added to the ACS.  The condition
     therefore treats the minimum SVN as an exact state and not one to
     compare with inequality.

  9.4.6.1.3.  Comparison for digests entries

     A digests entry contains one or more digests, each measuring the same
     object.  When multiple digests are provided, each represents a
     different algorithm acceptable to the condition ECT author.

     In the simple case, a condition ECT digests entry containing one
     digest matches a candidate entry containing a single entry with the
     same algorithm and value.

     If there are multiple algorithms in common between the condition ECT
     and candidate entry, then the bytes paired with common algorithms
     MUST be equal.  This is to prevent downgrade attacks.  The Verifier
     SHALL treat two algorithm identifiers as equal if they have the same
     deterministic binary encoding.  If both an integer and a string
     representation are defined for an algorithm then entities creating
     ECTs SHOULD use the integer representation.  If condition ECT and ACS
     entry use different names for the same algorithm, and the Verifier
     does not recognize that they are the same, then a downgrade attack is
     possible.

     The comparison MUST return false if the CBOR encoding of the digests
     entry in the condition ECT or the ACS value with the same codepoint
     is incorrect.  For example, if fields are missing or if they are the
     wrong type.

     The comparison MUST return false if the condition ECT digests entry
     does not contain any digests.

     The comparison MUST return false if either digests entry contains
     multiple values for the same hash algorithm.



  Birkholz, et al.        Expires 3 September 2026               [Page 89]


  Internet-Draft                    CoRIM                       March 2026


     The Verifier MUST iterate over the condition ECT digests array,
     locating the common hash algorithm identifiers which are present in
     both the condition ECT and in the candidate entry.  If the value
     associated with any common hash algorithm identifier in the condition
     ECT differs from the value for the same algorithm identifier in the
     candidate entry then the comparison MUST return false.

     The comparison MUST return false if there are no hash algorithms from
     the condition ECT in common with the hash algorithms from the
     candidate entry ECT.

  9.4.6.1.4.  Comparison for raw-value entries

     A raw-value entry contains binary data.

     The value stored under measurement-values-map codepoint 4 in an ACS
     entry MUST be a raw-value entry, which MUST be tagged and have type
     bytes.

     The value stored under the condition ECT measurement-values-map
     codepoint 4 may additionally be a tagged-masked-raw-value entry,
     which specifies an expected value and a mask.

     If the condition ECT measurement-value-map codepoint 4 is of tagged-
     bytes, and there is no value stored under codepoint 5, then the
     Verifier treats it in the same way as a tagged-masked-raw-value with
     the value field holding the same contents and a mask of the same
     length as the value with all bits set.  The standard comparison
     function defined in this document removes the tag before performing
     the comparison.

     For backwards compatibility, if the condition ECT measurement-value-
     map codepoint 4 is of type tagged-bytes, and there is a mask stored
     under codepoint 5, then the Verifier treats it in the same way as a
     tagged-masked-raw-value with the value field holding the same
     contents and a mask holding the contents of codepoint 5.

     The comparison MUST return false if the lengths of the candidate
     entry value and the condition ECT value are different.

     The comparison MUST return false if the lengths of the condition ECT
     mask and value are different.

     The comparison MUST use the mask to determine which bits to compare.
     If a bit in the mask is 0 then this indicates that the corresponding
     bit in the ACS Entry value may have either value.  If, for every bit
     position in the mask whose value is 1, the corresponding bits in both
     values are equal then the comparison MUST return true.



  Birkholz, et al.        Expires 3 September 2026               [Page 90]


  Internet-Draft                    CoRIM                       March 2026


  9.4.6.1.5.  Comparison for cryptokeys entries

     The CBOR tag of the first entry of the condition ECT cryptokeys array
     is compared with the CBOR tag of the first entry of the candidate
     entry cryptokeys value.  If the CBOR tags match, then the bytes
     following the CBOR tag from the condition ECT entry are compared
     byte-by-byte with the bytes following the CBOR tag from the candidate
     entry.  If the byte strings match and there is another array entry,
     then the next entry from the condition ECTs array is likewise
     compared with the next entry of the ACS array.  If all entries of the
     condition ECTs array match a corresponding entry in the ACS array,
     then the cryptokeys condition ECT matches.  Otherwise, cryptokeys
     does not match.

  9.4.6.1.6.  Comparison for Integrity Registers

     For each Integrity Register entry in the condition ECT, the Verifier
     will use the associated identifier (i.e., integrity-register-id-type-
     choice) to look up the matching Integrity Register entry in the
     candidate entry.  If no entry is found, the comparison MUST return
     false.  Instead, if an entry is found, the digest comparison proceeds
     as defined in Section 9.4.6.1.3 after equivalence has been found
     according to Section 5.1.4.7.  Note that it is not required for all
     the entries in the candidate entry to be used during matching: the
     condition ECT could consist of a subset of the device's register
     space.  In TPM parlance, a TPM "quote" may report all PCRs in
     Evidence, while a condition ECT could describe a subset of PCRs.

  9.4.6.1.7.  Comparison for int-range entries

     The ACS entry value stored under measurement-values-map codepoint 15
     is an int range value, which MUST have type int-range-type-choice.

     Consider an int ACS entry value named ENTRY in a measurement-values-
     map codepoint (e.g., 15) that allows comparing int against a either
     another int or an int-range named CONDITION.

     *  If CONDITION is an int then an equality comparison is performed
        with ENTRY.

     *  If CONDITION is an int-range (CBOR tag 564), then a range
        inclusion comparison is performed.  The comparison MUST return
        true if and only if all the following conditions are true:

        -  CONDITION.min is null or ENTRY is greater than or equal to
           CONDITION.min.





  Birkholz, et al.        Expires 3 September 2026               [Page 91]


  Internet-Draft                    CoRIM                       March 2026


        -  CONDITION.max is null or ENTRY is less than or equal to
           CONDITION.max.

     Consider an int-range or int-range (CBOR tag 564) value named ENTRY
     in a measurement-values-map codepoint (e.g., 15) that allows
     comparing an int-range against either another int-range or an int
     named CONDITION.

     *  If CONDITION is an int, then the comparison MUST return true if
        and only if ENTRY.min and ENTRY.max are both equal to CONDITION.

     *  If CONDITION is an int-range (CBOR tag 564), then a range
        subsumption comparison is performed (i.e., the condition range
        includes all values of the entry range).  The comparison MUST
        return true if and only if all the following conditions are true:

        -  CONDITION.min is null or ENTRY.min is an int that is greater
           than or equal to CONDITION.min

        -  CONDITION.max is null or ENTRY.max is an int that is less than
           or equal to CONDITION.max.

  9.4.7.  Profile-directed Comparison

     A profile MUST specify comparison algorithms for its additions to
     $-prefixed CoRIM CDDL codepoints when this specification does not
     prescribe binary comparison.  The profile MUST specify how to compare
     the CBOR tagged Reference Value against the ACS.

     Note that the Verifier may compare Reference Values in any order, so
     the comparison SHOULD NOT be stateful.

  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.





  Birkholz, et al.        Expires 3 September 2026               [Page 92]


  Internet-Draft                    CoRIM                       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".

  10.1.  Veraison

     *  Organization responsible for the implementation: Veraison Project,
        Linux Foundation

     *  Implementation's web page: https://github.com/veraison/corim/
        README.md (https://github.com/veraison/corim/blob/main/README.md)

     *  Brief general description: There are three CoRIM libraries under
        project Veraison.

        1.  CoRIM golang library (https://github.com/veraison/corim) The
            corim/corim and corim/comid packages provide a golang API for
            low-level manipulation of Concise Reference Integrity Manifest
            (CoRIM) and Concise Module Identifier (CoMID) tags
            respectively.

        2.  CoRIM rust library (https://github.com/veraison/corim-rs)
            provide a rust implementation of CoRIM specification.

        3.  CoRIM Processor (https://github.com/veraison/cover) provides a
            library for appraisal of Evidence by processing CoRIMs as
            outlined in Section 9} of this specification.

        In addition to the base CoRIM Libraries, the cocli package
        (https://github.com/veraison/cocli) uses the golang API above (as
        well as the API from the veraison/swid package) to provide a user
        command line interface for working with CoRIM, CoMID and CoSWID.
        Specifically, it allows creating, signing, verifying, displaying,
        uploading, and more.  See https://github.com/veraison/cocli/
        README.md (https://github.com/veraison/cocli/README.md) for
        further details.

     *  Implementation's level of maturity: alpha.

     *  Coverage: the whole protocol is implemented, including PSA-
        specific extensions [I-D.fdb-rats-psa-endorsements].

     *  Version compatibility: Version -06 of the draft





  Birkholz, et al.        Expires 3 September 2026               [Page 93]


  Internet-Draft                    CoRIM                       March 2026


     *  Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/
        LICENSE (https://github.com/veraison/corim/blob/main/LICENSE)

     *  Implementation experience: n/a

     *  Contact information: https://veraison.zulipchat.com
        (https://veraison.zulipchat.com)

     *  Last updated: https://github.com/veraison/corim/commits/main
        (https://github.com/veraison/corim/commits/main)
        https://github.com/veraison/corim-rs/commits/master/
        (https://github.com/veraison/corim-rs/commits/master/)
        https://github.com/veraison/cover/commits/main/
        (https://github.com/veraison/cover/commits/main/)

  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 procedure conducted by the Verifier 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 the Verifier system should be considered throughout
     its 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;

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






  Birkholz, et al.        Expires 3 September 2026               [Page 94]


  Internet-Draft                    CoRIM                       March 2026


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

     It is critical that appraisal procedures are auditable and
     reproducible.  The integrity of code and data during execution is an
     explicit objective, for example, ensuring that the appraisal
     functions are executed in an attestable trusted execution environment
     (TEE).

     Please review the Security and Privacy Considerations in Sections 8
     and 9 of [I-D.ietf-rats-endorsements]; these considerations apply to
     this document as well.

  12.  IANA Considerations

  12.1.  New COSE Header Parameters

  12.2.  New CBOR Tags

     IANA is requested to allocate the following tags in the "CBOR Tags"
     registry [IANA.cbor-tags], preferably with the specific CBOR tag
     value requested:

     +=========+=============+===============================+===========+
     | Tag     | Data Item   | Semantics                     | Reference |
     +=========+=============+===============================+===========+
     | 500     | tag         | Reserved for backward         | RFCthis   |
     |         |             | compatibility                 |           |
     +---------+-------------+-------------------------------+-----------+
     | 501     | map         | A tagged-unsigned-corim-      | RFCthis   |
     |         |             | map, see Section 4.1          |           |
     +---------+-------------+-------------------------------+-----------+
     | 502-504 | any         | Earmarked for CoRIM           | RFCthis   |
     +---------+-------------+-------------------------------+-----------+
     | 505     | bytes       | A tagged-concise-swid-        | RFCthis   |
     |         |             | tag, see Section 4.1.2        |           |
     +---------+-------------+-------------------------------+-----------+
     | 506     | bytes       | A tagged-concise-mid-tag,     | RFCthis   |
     |         |             | see Section 4.1.2             |           |



  Birkholz, et al.        Expires 3 September 2026               [Page 95]


  Internet-Draft                    CoRIM                       March 2026


     +---------+-------------+-------------------------------+-----------+
     | 507     | any         | Earmarked for CoRIM           | RFCthis   |
     +---------+-------------+-------------------------------+-----------+
     | 508     | bytes       | A tagged-concise-tl-tag,      | RFCthis   |
     |         |             | see Section 4.1.2             |           |
     +---------+-------------+-------------------------------+-----------+
     | 509-549 | any         | Earmarked for CoRIM           | RFCthis   |
     +---------+-------------+-------------------------------+-----------+
     | 550     | bytes .size | tagged-ueid-type, see         | RFCthis   |
     |         | (7..33)     | Section 7.5                   |           |
     +---------+-------------+-------------------------------+-----------+
     | 552     | uint        | tagged-svn, see               | RFCthis   |
     |         |             | Section 5.1.4.5.4             |           |
     +---------+-------------+-------------------------------+-----------+
     | 553     | uint        | tagged-min-svn, see           | RFCthis   |
     |         |             | Section 5.1.4.5.4             |           |
     +---------+-------------+-------------------------------+-----------+
     | 554     | text        | tagged-pkix-base64-key-       | RFCthis   |
     |         |             | type, see Section 5.1.4.6     |           |
     +---------+-------------+-------------------------------+-----------+
     | 555     | text        | tagged-pkix-base64-cert-      | RFCthis   |
     |         |             | type, see Section 5.1.4.6     |           |
     +---------+-------------+-------------------------------+-----------+
     | 556     | text        | tagged-pkix-base64-cert-      | RFCthis   |
     |         |             | path-type, see                |           |
     |         |             | Section 5.1.4.6               |           |
     +---------+-------------+-------------------------------+-----------+
     | 557     | [int/text,  | tagged-key-thumbprint-        | RFCthis   |
     |         | bytes]      | type, see Section 7.7         |           |
     +---------+-------------+-------------------------------+-----------+
     | 558     | COSE_Key    | tagged-cose-key-type, see     | RFCthis   |
     |         |             | Section 5.1.4.6               |           |
     +---------+-------------+-------------------------------+-----------+
     | 559     | digest      | tagged-cert-thumbprint-       | RFCthis   |
     |         |             | type, see Section 5.1.4.6     |           |
     +---------+-------------+-------------------------------+-----------+
     | 560     | bytes       | tagged-bytes, see             | RFCthis   |
     |         |             | Section 7.8                   |           |
     +---------+-------------+-------------------------------+-----------+
     | 561     | digest      | tagged-cert-path-             | RFCthis   |
     |         |             | thumbprint-type, see          |           |
     |         |             | Section 5.1.4.6               |           |
     +---------+-------------+-------------------------------+-----------+
     | 562     | bytes       | tagged-pkix-asn1der-cert-     | RFCthis   |
     |         |             | type, see Section 5.1.4.6     |           |
     +---------+-------------+-------------------------------+-----------+
     | 563     | tagged-     | tagged-masked-raw-value,      | RFCthis   |
     |         | masked-raw- | see Section 5.1.4.5.6         |           |



  Birkholz, et al.        Expires 3 September 2026               [Page 96]


  Internet-Draft                    CoRIM                       March 2026


     |         | value       |                               |           |
     +---------+-------------+-------------------------------+-----------+
     | 564     | array       | tagged-int-range, see         | RFCthis   |
     |         |             | Section 5.1.4.8               |           |
     +---------+-------------+-------------------------------+-----------+
     | 565-599 | any         | Earmarked for CoRIM           | RFCthis   |
     +---------+-------------+-------------------------------+-----------+

                                    Table 9

     Tags designated as "Earmarked for CoRIM" can be reassigned by IANA
     based on advice from the designated expert for the CBOR Tags
     registry.

  12.3.  CoRIM Map Registry

     This document defines a new registry titled "CoRIM Map".  The
     registry uses integer values as index values for items in corim-map
     CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                           Table 10: CoRIM Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoRIM Map" registry are provided
     below.  Assignments consist of an integer index value, the item name,
     and a reference to the defining specification.












  Birkholz, et al.        Expires 3 September 2026               [Page 97]


  Internet-Draft                    CoRIM                       March 2026


                  +=======+================+===============+
                  | Index | Item Name      | Specification |
                  +=======+================+===============+
                  | 0     | id             | RFCthis       |
                  +-------+----------------+---------------+
                  | 1     | tags           | RFCthis       |
                  +-------+----------------+---------------+
                  | 2     | dependent-rims | RFCthis       |
                  +-------+----------------+---------------+
                  | 3     | profile        | RFCthis       |
                  +-------+----------------+---------------+
                  | 4     | rim-validity   | RFCthis       |
                  +-------+----------------+---------------+
                  | 5     | entities       | RFCthis       |
                  +-------+----------------+---------------+
                  | 3-255 | Unassigned     |               |
                  +-------+----------------+---------------+

                      Table 11: CoRIM Map Items Initial
                                Registrations

  12.4.  CoRIM Entity Map Registry

     This document defines a new registry titled "CoRIM Entity Map".  The
     registry uses integer values as index values for items in corim-
     entity-map CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                        Table 12: CoRIM Entity Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoRIM Entity Map" registry are
     provided below.  Assignments consist of an integer index value, the
     item name, and a reference to the defining specification.





  Birkholz, et al.        Expires 3 September 2026               [Page 98]


  Internet-Draft                    CoRIM                       March 2026


      +=======+=============+==================+========================+
      | Index | Item Name   | Value Type       | Specification          |
      +=======+=============+==================+========================+
      | 0     | entity-name | text             | Name of the entity     |
      |       |             |                  | responsible for the    |
      |       |             |                  | actions of the role.   |
      +-------+-------------+------------------+------------------------+
      | 1     | reg-id      | uri              | A URI associated with  |
      |       |             |                  | the organization that  |
      |       |             |                  | owns the entity name.  |
      +-------+-------------+------------------+------------------------+
      | 2     | role        | [ + role-type-   | A type choice defining |
      |       |             | choice ]         | the roles that the     |
      |       |             |                  | entity is claiming.    |
      +-------+-------------+------------------+------------------------+
      | 3-255 | Unassigned  |                  |                        |
      +-------+-------------+------------------+------------------------+

             Table 13: CoRIM Entity Map Items Initial Registrations

  12.5.  CoRIM Signer Map Registry

     This document defines a new registry titled "CoRIM Signer Map".  The
     registry uses integer values as index values for items in corim-
     signer-map CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                        Table 14: CoRIM Signer Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoRIM Signer Map" registry are
     provided below.  Assignments consist of an integer index value, the
     item name, and a reference to the defining specification.






  Birkholz, et al.        Expires 3 September 2026               [Page 99]


  Internet-Draft                    CoRIM                       March 2026


                    +=======+=============+===============+
                    | Index | Item Name   | Specification |
                    +=======+=============+===============+
                    | 0     | signer-name | RFCthis       |
                    +-------+-------------+---------------+
                    | 1     | signer-uri  | RFCthis       |
                    +-------+-------------+---------------+
                    | 2-255 | Unassigned  |               |
                    +-------+-------------+---------------+

                        Table 15: CoRIM Signer Map Items
                             Initial Registrations

  12.6.  CoMID Map Registry

     This document defines a new registry titled "CoMID Map".  The
     registry uses integer values as index values for items in concise-
     mid-tag CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                           Table 16: CoMID Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoMID Map" registry are provided
     below.  Assignments consist of an integer index value, the item name,
     and a reference to the defining specification.













  Birkholz, et al.        Expires 3 September 2026              [Page 100]


  Internet-Draft                    CoRIM                       March 2026


                   +=======+==============+===============+
                   | Index | Item Name    | Specification |
                   +=======+==============+===============+
                   | 0     | language     | RFCthis       |
                   +-------+--------------+---------------+
                   | 1     | tag-identity | RFCthis       |
                   +-------+--------------+---------------+
                   | 2     | entity       | RFCthis       |
                   +-------+--------------+---------------+
                   | 3     | linked-tags  | RFCthis       |
                   +-------+--------------+---------------+
                   | 4     | triples      | RFCthis       |
                   +-------+--------------+---------------+
                   | 5-255 | Unassigned   |               |
                   +-------+--------------+---------------+

                      Table 17: CoMID Map Items Initial
                                Registrations

  12.7.  CoMID Entity Map Registry

     This document defines a new registry titled "CoRIM Entity Map".  The
     registry uses integer values as index values for items in corim-
     entity-map CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                        Table 18: CoMID Entity Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoMID Entity Map" registry are
     provided below.  Assignments consist of an integer index value, the
     item name, and a reference to the defining specification.







  Birkholz, et al.        Expires 3 September 2026              [Page 101]


  Internet-Draft                    CoRIM                       March 2026


      +=======+=============+==================+========================+
      | Index | Item Name   | Value Type       | Specification          |
      +=======+=============+==================+========================+
      | 0     | entity-name | text             | Name of the entity     |
      |       |             |                  | responsible for the    |
      |       |             |                  | actions of the role.   |
      +-------+-------------+------------------+------------------------+
      | 1     | reg-id      | uri              | A URI associated with  |
      |       |             |                  | the organization that  |
      |       |             |                  | owns the entity name.  |
      +-------+-------------+------------------+------------------------+
      | 2     | role        | [ + role-type-   | A type choice defining |
      |       |             | choice ]         | the roles that the     |
      |       |             |                  | entity is claiming.    |
      +-------+-------------+------------------+------------------------+
      | 3-255 | Unassigned  |                  |                        |
      +-------+-------------+------------------+------------------------+

             Table 19: CoMID Entity Map Items Initial Registrations

  12.8.  CoMID Triples Map Registry

     This document defines a new registry titled "CoMID Triples Map".  The
     registry uses integer values as index values for items in the
     triples-map CBOR maps in concise-mid-tag codepoint 4.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

           +============================+=========================+
           | Range                      | Registration Procedures |
           +============================+=========================+
           | 0-1023                     | Standards Action        |
           +----------------------------+-------------------------+
           | 1024-65535                 | Specification Required  |
           +----------------------------+-------------------------+
           | 65536-18446744073709551616 | First come first served |
           +----------------------------+-------------------------+

                Table 20: CoMID Triples Map Items Registration
                                  Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoMID Triples Map" registry are
     provided below.  Assignments consist of an integer index value, the
     item name, and a reference to the defining specification.




  Birkholz, et al.        Expires 3 September 2026              [Page 102]


  Internet-Draft                    CoRIM                       March 2026


         +=========================+================+===============+
         | Index                   | Item Name      | Specification |
         +=========================+================+===============+
         | 0                       | reference-     | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 1                       | endorsed-      | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 2                       | identity-      | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 3                       | attest-key-    | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 4                       | dependency-    | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 5                       | membership-    | RFCthis       |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 6                       | coswid-triples | RFCthis       |
         +-------------------------+----------------+---------------+
         | 7                       | (reserved)     | RFCthis       |
         +-------------------------+----------------+---------------+
         | 8                       | conditional-   | RFCthis       |
         |                         | endorsement-   |               |
         |                         | series-triples |               |
         +-------------------------+----------------+---------------+
         | 9                       | (reserved)     | RFCthis       |
         +-------------------------+----------------+---------------+
         | 10                      | conditional-   | RFCthis       |
         |                         | endorsement-   |               |
         |                         | triples        |               |
         +-------------------------+----------------+---------------+
         | 11-18446744073709551616 | Unassigned     |               |
         +-------------------------+----------------+---------------+

           Table 21: CoMID Triples Map Items Initial Registrations

  12.9.  CoMID Measurement Values Map Registry

     This document defines a new registry titled "CoMID Measurement Values
     Map".  The registry uses integer values as index values for items in
     multiple triples' representations.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:



  Birkholz, et al.        Expires 3 September 2026              [Page 103]


  Internet-Draft                    CoRIM                       March 2026


           +============================+=========================+
           | Range                      | Registration Procedures |
           +============================+=========================+
           | 0-1023                     | Standards Action        |
           +----------------------------+-------------------------+
           | 1024-65535                 | Specification Required  |
           +----------------------------+-------------------------+
           | 65536-18446744073709551616 | First come first served |
           +----------------------------+-------------------------+

                 Table 22: CoMID Measurement Values Map Items
                           Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoMID Measurement Values Map" registry
     are provided below.  Assignments consist of an integer index value,
     the item name, and a reference to the defining specification.

































  Birkholz, et al.        Expires 3 September 2026              [Page 104]


  Internet-Draft                    CoRIM                       March 2026


      +=======================+===========================+=============+
      |Index                  | Item Name                 |Specification|
      +=======================+===========================+=============+
      |0                      | version                   |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |1                      | svn                       |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |2                      | digests                   |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |3                      | flags                     |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |4                      | raw-value                 |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |5                      | raw-value-mask-DEPRECATED |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |6                      | mac-addr                  |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |7                      | ip-addr                   |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |8                      | serial-number             |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |9                      | ueid                      |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |10                     | uuid                      |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |11                     | name                      |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |12                     | (reserved)                |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |13                     | cryptokeys                |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |14                     | integrity-registers       |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |15                     | int-range                 |RFCthis      |
      +-----------------------+---------------------------+-------------+
      |16-18446744073709551616| Unassigned                |             |
      +-----------------------+---------------------------+-------------+

          Table 23: Measurement Values Map Items Initial Registrations

  12.10.  CoMID Flags Map Registry

     This document defines a new registry titled "CoMID Flags Map".  The
     registry uses integer values as index values for items in
     measurement-values-map codepoint 3.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:



  Birkholz, et al.        Expires 3 September 2026              [Page 105]


  Internet-Draft                    CoRIM                       March 2026


           +============================+=========================+
           | Range                      | Registration Procedures |
           +============================+=========================+
           | 0-1023                     | Standards Action        |
           +----------------------------+-------------------------+
           | 1024-65535                 | Specification Required  |
           +----------------------------+-------------------------+
           | 65536-18446744073709551616 | First come first served |
           +----------------------------+-------------------------+

           Table 24: CoMID Flags Map Items Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoMID Measurement Values Map" registry
     are provided below.  Assignments consist of an integer index value,
     the item name, and a reference to the defining specification.

     +=======================+============================+=============+
     |Index                  |Item Name                   |Specification|
     +=======================+============================+=============+
     |0                      |is-configured               |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |1                      |is-secure                   |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |2                      |is-recovery                 |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |3                      |is-debug                    |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |4                      |is-replay-protected         |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |5                      |is-integrity-protected      |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |6                      |is-runtime-meas             |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |7                      |is-immutable                |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |8                      |is-tcb                      |RFCthis      |
     +-----------------------+----------------------------+-------------+
     |9                      |is-confidentiality-protected|RFCthis      |
     +-----------------------+----------------------------+-------------+
     |10-18446744073709551616|Unassigned                  |             |
     +-----------------------+----------------------------+-------------+

               Table 25: Flags Map Items Initial Registrations






  Birkholz, et al.        Expires 3 September 2026              [Page 106]


  Internet-Draft                    CoRIM                       March 2026


  12.11.  CoTL Map Registry

     This document defines a new registry titled "CoTL Map".  The registry
     uses integer values as index values for items in 'concise-tl-tag'
     CBOR maps.

     Future registrations for this registry are to be made based on
     [RFC8126] as follows:

                     +=========+=========================+
                     | Range   | Registration Procedures |
                     +=========+=========================+
                     | 0-127   | Standards Action        |
                     +---------+-------------------------+
                     | 128-255 | Specification Required  |
                     +---------+-------------------------+

                            Table 26: CoTL Map Items
                            Registration Procedures

     All negative values are reserved for Private Use.

     Initial registrations for the "CoTL Map" registry are provided below.
     Assignments consist of an integer index value, the item name, and a
     reference to the defining specification.

                   +=======+==============+===============+
                   | Index | Item Name    | Specification |
                   +=======+==============+===============+
                   | 0     | tag-identity | RFCthis       |
                   +-------+--------------+---------------+
                   | 1     | tags-list    | RFCthis       |
                   +-------+--------------+---------------+
                   | 2     | tl-validity  | RFCthis       |
                   +-------+--------------+---------------+
                   | 3-255 | Unassigned   |               |
                   +-------+--------------+---------------+

                       Table 27: CoTL Map Items Initial
                                Registrations

  12.12.  New Media Types

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






  Birkholz, et al.        Expires 3 September 2026              [Page 107]


  Internet-Draft                    CoRIM                       March 2026


     +==========+======================+============================+
     | Name     | Template             | Reference                  |
     +==========+======================+============================+
     | rim+cbor | application/rim+cbor | RFCthis, (Section 12.12.1) |
     +----------+----------------------+----------------------------+
     | rim+cose | application/rim+cose | RFCthis, (Section 12.12.2) |
     +----------+----------------------+----------------------------+

                        Table 28: New Media Types

  12.12.1.  rim+cbor

     Type name:  application
     Subtype name:  rim+cbor
     Required parameters:  n/a
     Optional parameters:  "profile" (CoRIM profile in string format.
        OIDs MUST use the dotted-decimal notation.)
     Encoding considerations:  binary
     Security considerations:  Section 11 of RFCthis
     Interoperability considerations:  n/a
     Published specification:  RFCthis
     Applications that use this media type:  Attestation Verifiers,
        Endorsers and Reference-Value providers that need to transfer
        unprotected CoRIM payloads over HTTP(S), CoAP(S), and other
        transports.
     Fragment identifier considerations:  n/a
     Magic number(s):  D9 01 F5
     File extension(s):  .corim
     Macintosh file type code(s):  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?  Maybe

  12.12.2.  rim+cose

     Type name:  application
     Subtype name:  rim+cose
     Required parameters:  n/a (cose-type is explicitly not supported, as
        it is understood to be "cose-sign1")
     Optional parameters:  "profile" (CoRIM profile in string format.
        OIDs MUST use the dotted-decimal notation.)
     Encoding considerations:  binary
     Security considerations:  Section 11 of RFCthis
     Interoperability considerations:  n/a
     Published specification:  RFCthis



  Birkholz, et al.        Expires 3 September 2026              [Page 108]


  Internet-Draft                    CoRIM                       March 2026


     Applications that use this media type:  Attestation Verifiers,
        Endorsers and Reference-Value providers that need to transfer
        CoRIM payloads protected using COSE Sign1 over HTTP(S), CoAP(S),
        and other transports.
     Fragment identifier considerations:  n/a
     Magic number(s):  D2 84
     File extension(s):  .corim
     Macintosh file type code(s):  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?  Maybe

  12.13.  CoAP Content-Formats Registration

     IANA is requested to register the two following Content-Format
     numbers in the "CoAP Content-Formats" sub-registry, within the
     "Constrained RESTful Environments (CoRE) Parameters" Registry
     [IANA.core-parameters]:

     +======================+================+======+===========+
     | Content-Type         | Content Coding | ID   | Reference |
     +======================+================+======+===========+
     | application/rim+cbor | -              | TBD1 | RFCthis   |
     +----------------------+----------------+------+-----------+
     | application/rim+cose | -              | TBD2 | RFCthis   |
     +----------------------+----------------+------+-----------+

                    Table 29: New Content-Formats

  13.  References

  13.1.  Normative References

     [I-D.ietf-cose-hash-envelope]
                Steele, O., Lasker, S., and H. Birkholz, "COSE Hash
                Envelope", Work in Progress, Internet-Draft, draft-ietf-
                cose-hash-envelope-10, 15 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                hash-envelope-10>.









  Birkholz, et al.        Expires 3 September 2026              [Page 109]


  Internet-Draft                    CoRIM                       March 2026


     [I-D.ietf-rats-eat-measured-component]
                Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz,
                "Entity Attestation Token (EAT) Measured Component", Work
                in Progress, Internet-Draft, draft-ietf-rats-eat-measured-
                component-12, 20 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                eat-measured-component-12>.

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

     [IANA.cbor-tags]
                IANA, "Concise Binary Object Representation (CBOR) Tags",
                <https://www.iana.org/assignments/cbor-tags>.

     [IANA.core-parameters]
                IANA, "Constrained RESTful Environments (CoRE)
                Parameters",
                <https://www.iana.org/assignments/core-parameters>.

     [IANA.language-subtag-registry]
                IANA, "Language Subtag Registry",
                <https://www.iana.org/assignments/language-subtag-
                registry>.

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

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

     [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
                PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
                April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.




  Birkholz, et al.        Expires 3 September 2026              [Page 110]


  Internet-Draft                    CoRIM                       March 2026


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

     [RFC9090]  Bormann, C., "Concise Binary Object Representation (CBOR)
                Tags for Object Identifiers", RFC 9090,
                DOI 10.17487/RFC9090, July 2021,
                <https://www.rfc-editor.org/rfc/rfc9090>.

     [RFC9164]  Richardson, M. and C. Bormann, "Concise Binary Object
                Representation (CBOR) Tags for IPv4 and IPv6 Addresses and
                Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021,
                <https://www.rfc-editor.org/rfc/rfc9164>.

     [RFC9393]  Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
                Waltermire, "Concise Software Identification Tags",
                RFC 9393, DOI 10.17487/RFC9393, June 2023,
                <https://www.rfc-editor.org/rfc/rfc9393>.

     [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
                IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
                2024, <https://www.rfc-editor.org/rfc/rfc9562>.

     [RFC9597]  Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
                COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9597>.

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

     [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/rfc/rfc3986>.





  Birkholz, et al.        Expires 3 September 2026              [Page 111]


  Internet-Draft                    CoRIM                       March 2026


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

     [X.690]    International Telephone and Telegraph Consultative
                Committee, "ASN.1 encoding rules: Specification of basic
                encoding Rules (BER), Canonical encoding rules (CER) and
                Distinguished encoding rules (DER)", CCITT Recommendation
                X.690, July 2002.

  13.2.  Informative References

     [DICE.cert]
                Trusted Computing Group, "DICE Certificate Profiles",
                Version 1.0, Revision 0.01 , July 2020,
                <https://trustedcomputinggroup.org/wp-content/uploads/
                DICE-Certificate-Profiles-r01_pub.pdf>.

     [DICE.Layer]
                Trusted Computing Group, "DICE Layering Architecture",
                Version 1.0, Revision 0.19 , July 2020,
                <https://trustedcomputinggroup.org/wp-content/uploads/
                DICE-Layering-Architecture-r19_pub.pdf>.

     [I-D.fdb-rats-psa-endorsements]
                Fossati, T., Deshpande, Y., and H. Birkholz, "A CoRIM
                Profile for Arm's Platform Security Architecture (PSA)
                Endorsements", Work in Progress, Internet-Draft, draft-
                fdb-rats-psa-endorsements-09, 5 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-
                endorsements-09>.

     [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-
                09, 15 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                ar4si-09>.






  Birkholz, et al.        Expires 3 September 2026              [Page 112]


  Internet-Draft                    CoRIM                       March 2026


     [I-D.ietf-rats-concise-ta-stores]
                Wallace, C., Housley, R., Fossati, T., and Y. Deshpande,
                "Concise TA Stores (CoTS)", Work in Progress, Internet-
                Draft, draft-ietf-rats-concise-ta-stores-02, 5 December
                2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
                rats-concise-ta-stores-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>.

     [IANA.coswid]
                IANA, "Concise Software Identifier (CoSWID)",
                <https://www.iana.org/assignments/coswid>.

     [IEEE-802.OandA]
                "IEEE Standard for Local and Metropolitan Area Networks:
                Overview and Architecture", IEEE,
                DOI 10.1109/ieeestd.2014.6847097, ISBN ["9780738192192"],
                July 2014, <https://doi.org/10.1109/ieeestd.2014.6847097>.

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

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

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

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

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




  Birkholz, et al.        Expires 3 September 2026              [Page 113]


  Internet-Draft                    CoRIM                       March 2026


     [TNC.Arch] Trusted Computing Group, "TCG Trusted Network Connect TNC
                Architecture for Interoperability", Specification Version
                1.1 Revision 2 , May 2006,
                <https://trustedcomputinggroup.org/wp-content/uploads/
                TNC_Architecture_v1_1_r2.pdf>.

     [TPM2.Part1]
                Trusted Computing Group, "Trusted Platform Module Library,
                Part 1: Architecture", Family "2.0", Level 00, Revision
                01.83 , January 2024,
                <https://trustedcomputinggroup.org/resource/tpm-library-
                specification/>.

     [W3C.rdf11-primer]
                "RDF 1.1 Primer", W3C NOTE rdf11-primer, W3C rdf11-primer,
                <https://www.w3.org/TR/rdf11-primer/>.

  Appendix A.  Base CoRIM CDDL

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     corim = concise-rim-type-choice
     concise-rim-type-choice /= tagged-unsigned-corim-map / signed-corim
     concise-tl-tag = {
       &(tag-identity: 0) => tag-identity-map,
       &(tags-list: 1) => [+ tag-identity-map],
       &(tl-validity: 2) => validity-map,
     }
     $concise-tag-type-choice /= tagged-concise-swid-tag / tagged-concise\
                                          -mid-tag / tagged-concise-tl-tag
     corim-entity-map = entity-map<$corim-role-type-choice, $$corim-\
                                                     entity-map-extension>
     $corim-id-type-choice /= tstr / uuid-type
     corim-locator-map = {
       &(href: 0) => uri / [+ uri],
       ? &(thumbprint: 1) => eatmc.digest / [eatmc.digest],
     }
     corim-map = {
       &(id: 0) => $corim-id-type-choice,
       &(tags: 1) => [+ $concise-tag-type-choice],
       ? &(dependent-rims: 2) => [+ corim-locator-map],
       ? &(profile: 3) => $profile-type-choice,
       ? &(rim-validity: 4) => validity-map,
       ? &(entities: 5) => [+ corim-entity-map],
       * $$corim-map-extension,
     }
     unsigned-corim-map = corim-map
     corim-meta-map = {



  Birkholz, et al.        Expires 3 September 2026              [Page 114]


  Internet-Draft                    CoRIM                       March 2026


       &(signer: 0) => corim-signer-map,
       ? &(signature-validity: 1) => validity-map,
     }
     $corim-role-type-choice /= &(manifest-creator: 1) / &(manifest-\
                                                                signer: 2)
     corim-signer-map = {
       &(signer-name: 0) => $entity-name-type-choice,
       ? &(signer-uri: 1) => uri,
       * $$corim-signer-map-extension,
     }
     COSE-Sign1-corim = [
       protected: bstr .cbor protected-corim-header-map,
       unprotected: unprotected-corim-header-map,
       payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-\
                                                             digest / nil,
       signature: bstr,
     ]
     hash-envelope-digest = bstr
     $profile-type-choice /= uri / tagged-oid-type
     cwt-claims = {
       &(iss: 1) => tstr,
       ? &(sub: 2) => tstr,
       ? &(exp: 4) => int / float,
       ? &(nbf: 5) => int / float,
       * int => any,
     }
     protected-corim-header-map = protected-corim-header-map-inline / \
                                  protected-corim-header-map-hash-envelope
     protected-corim-header-map-inline = {
       &(alg: 1) => int,
       &(content-type: 3) => "application/rim+cbor",
       meta-group,
       * cose-label => cose-value,
     }
     protected-corim-header-map-hash-envelope = {
       &(alg: 1) => int,
       &(payload_hash_alg: 258) => int,
       &(payload_preimage_content_type: 259) => "application/rim+cbor",
       ? &(payload_location: 260) => tstr,
       meta-group,
       * cose-label => cose-value,
     }
     meta-group = ((
             corim-meta-identity,
             ? cwt-claims-identity,
           ) // cwt-claims-identity)
     corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim-meta-map)
     cwt-claims-identity = (&(CWT-Claims: 15) => cwt-claims)



  Birkholz, et al.        Expires 3 September 2026              [Page 115]


  Internet-Draft                    CoRIM                       March 2026


     signed-corim = #6.18(COSE-Sign1-corim)
     tagged-concise-swid-tag = #6.505(bytes .cbor coswid.concise-swid-tag)
     tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag)
     tagged-concise-tl-tag = #6.508(bytes .cbor concise-tl-tag)
     tagged-unsigned-corim-map = #6.501(unsigned-corim-map)
     unprotected-corim-header-map = {* cose-label => cose-value}
     validity-map = {
       ? &(not-before: 0) => time,
       &(not-after: 1) => time,
     }
     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],
     }>,
     ]
     $class-id-type-choice /= tagged-oid-type / tagged-uuid-type / 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) / &(creator: 1) / &(\
                                                            maintainer: 2)
     conditional-endorsement-series-triple-record = [
       condition: [
             environment: environment-map,
             claims-list: [* measurement-map],
             ? authorized-by: [+ $crypto-key-type-choice],
     ],
       series: [+ conditional-series-record],
     ]
     conditional-series-record = [



  Birkholz, et al.        Expires 3 September 2026              [Page 116]


  Internet-Draft                    CoRIM                       March 2026


       selection: [+ measurement-map],
       addition: [+ measurement-map],
     ]
     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,
       [+ coswid.tag-id],
     ]
     $crypto-key-type-choice /= tagged-pkix-base64-key-type / tagged-pkix\
     -base64-cert-type / tagged-pkix-base64-cert-path-type / tagged-cose-\
     key-type / tagged-pkix-asn1der-cert-type / tagged-key-thumbprint-\
     type / tagged-cert-thumbprint-type / tagged-cert-path-thumbprint-\
                                                       type / 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-key-thumbprint-type = #6.557(eatmc.digest)
     tagged-cose-key-type = #6.558(COSE_Key)
     tagged-cert-thumbprint-type = #6.559(eatmc.digest)
     tagged-cert-path-thumbprint-type = #6.561(eatmc.digest)
     tagged-pkix-asn1der-cert-type = #6.562(bstr)
     domain-dependency-triple-record = [
       domain-id: domain-type,
       trustees: [+ domain-type],
     ]
     domain-membership-triple-record = [
       domain-id: domain-type,
       members: [+ domain-type],
     ]
     conditional-endorsement-triple-record = [
       conditions: [+ stateful-environment-record],
       endorsements: [+ endorsed-triple-record],
     ]
     domain-type = environment-map
     endorsed-triple-record = [
       condition: environment-map,
       endorsement: [+ measurement-map],
     ]
     entity-map<role-type-choice, extension-socket> = {



  Birkholz, et al.        Expires 3 September 2026              [Page 117]


  Internet-Draft                    CoRIM                       March 2026


         &(entity-name: 0) => $entity-name-type-choice,
         ? &(reg-id: 1) => uri,
         &(role: 2) => [+ role-type-choice],
         * extension-socket,
     }
     $entity-name-type-choice /= text
     environment-map = non-empty<{
         ? &(class: 0) => class-map,
         ? &(instance: 1) => $instance-id-type-choice,
         ? &(group: 2) => $group-id-type-choice,
     }>
     flags-map = non-empty<{
         ? &(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 / 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 / tagged-uuid-type / \
     tagged-bytes / tagged-pkix-base64-key-type / tagged-pkix-base64-cert\
     -type / tagged-cose-key-type / tagged-key-thumbprint-type / tagged-\
                      cert-thumbprint-type / tagged-pkix-asn1der-cert-type
     ip-addr-type-choice /= cbor-ip.ipv4-address / cbor-ip.ipv6-address
     int-range-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,



  Birkholz, et al.        Expires 3 September 2026              [Page 118]


  Internet-Draft                    CoRIM                       March 2026


       &(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 / tagged-uuid-type \
                                                             / uint / 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-DEPRECATED: 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,
         ? &(int-range: 15) => int-range-type-choice,
         * $$measurement-values-map-extension,
     }>
     non-empty<M> = M .and ({+ any => any})
     oid-type = bytes
     tagged-oid-type = #6.111(oid-type)
     $raw-value-type-choice /= tagged-bytes / 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,



  Birkholz, et al.        Expires 3 September 2026              [Page 119]


  Internet-Draft                    CoRIM                       March 2026


       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 / uuid-type
     tag-identity-map = {
       &(tag-id: 0) => $tag-id-type-choice,
       ? &(tag-version: 1) => tag-version-type,
     }
     $tag-rel-type-choice /= &(supplements: 0) / &(replaces: 1)
     tag-version-type = uint .default 0
     tagged-bytes = #6.560(bytes)
     triples-map = non-empty<{
         ? &(reference-triples: 0) => [+ reference-triple-record],
         ? &(endorsed-triples: 1) => [+ endorsed-triple-record],
         ? &(identity-triples: 2) => [+ identity-triple-record],
         ? &(attest-key-triples: 3) => [+ attest-key-triple-record],
         ? &(dependency-triples: 4) => [+ domain-dependency-triple-record\
                                                                        ],
         ? &(membership-triples: 5) => [+ domain-membership-triple-record\
                                                                        ],
         ? &(coswid-triples: 6) => [+ coswid-triple-record],
         ? &(conditional-endorsement-series-triples: 8) => [+ conditional\
                                       -endorsement-series-triple-record],
         ? &(conditional-endorsement-triples: 10) => [+ conditional-\
                                               endorsement-triple-record],
         * $$triples-map-extension,
     }>
     ueid-type = bytes .size (7 .. 33)
     tagged-ueid-type = #6.550(ueid-type)
     uuid-type = bytes .size 16
     tagged-uuid-type = #6.37(uuid-type)
     version-map = {
       &(version: 0) => text,
       ? &(version-scheme: 1) => coswid.$version-scheme,
     }
     digests-type = [+ eatmc.digest]
     integrity-register-id-type-choice = uint / text
     integrity-registers = {+ integrity-register-id-type-choice => \
                                                             digests-type}
     eatmc.measured-component = {
       eatmc.component-id-label => eatmc.component-id,
       eatmc.measurement,
       ? eatmc.authorities-label => [+ eatmc.authority-id-type],



  Birkholz, et al.        Expires 3 September 2026              [Page 120]


  Internet-Draft                    CoRIM                       March 2026


       ? eatmc.flags-label => eatmc.flags-type,
     }
     eatmc.measurement //= (eatmc.digested-measurement-label => eatmc.\
                           digest // eatmc.raw-measurement-label => bytes)
     eatmc.authority-id-type = eatmc.eat.JC<eatmc.bytes-b64u, bytes>
     eatmc.flags-type = eatmc.eat.JC<eatmc.bytes8-b64u, eatmc.bytes8>
     eatmc.component-id = [
       name: text,
       ? version: eatmc.version,
     ]
     eatmc.version = [
       val: text,
       ? scheme: eatmc.coswid.$version-scheme,
     ]
     eatmc.digest = [
       alg: int / text,
       val: eatmc.digest-value-type,
     ]
     eatmc.digest-value-type = eatmc.eat.JC<eatmc.bytes-b64u, bytes>
     eatmc.bytes-b64u = text .b64u bytes
     eatmc.bytes8 = bytes .size 8
     eatmc.bytes8-b64u = text .b64u eatmc.bytes8
     eatmc.component-id-label = eatmc.eat.JC<"id", 1>
     eatmc.digested-measurement-label = eatmc.eat.JC<"digested-\
                                                          measurement", 2>
     eatmc.raw-measurement-label = eatmc.eat.JC<"raw-measurement", 5>
     eatmc.authorities-label = eatmc.eat.JC<"authorities", 3>
     eatmc.flags-label = eatmc.eat.JC<"flags", 4>
     eatmc.mc-cbor = bytes .cbor eatmc.measured-component
     eatmc.mc-json = text .json eatmc.measured-component
     eatmc.$measurements-body-cbor /= eatmc.mc-cbor / eatmc.mc-json
     eatmc.$measurements-body-json /= eatmc.mc-json / text .b64u eatmc.mc\
                                                                     -cbor
     eatmc.eat.JSON-ONLY<J> = J .feature "json"
     eatmc.eat.CBOR-ONLY<C> = C .feature "cbor"
     eatmc.eat.JC<J, C> = eatmc.eat.JSON-ONLY<J> / eatmc.eat.CBOR-ONLY<C>
     eatmc.coswid.$version-scheme /= eatmc.coswid.multipartnumeric / \
     eatmc.coswid.multipartnumeric-suffix / eatmc.coswid.alphanumeric / \
                   eatmc.coswid.decimal / eatmc.coswid.semver / int / text
     eatmc.coswid.multipartnumeric = 1
     eatmc.coswid.multipartnumeric-suffix = 2
     eatmc.coswid.alphanumeric = 3
     eatmc.coswid.decimal = 4
     eatmc.coswid.semver = 16384
     coswid.concise-swid-tag = {
       coswid.tag-id => text / bstr .size 16,
       coswid.tag-version => integer,
       ? coswid.corpus => bool,



  Birkholz, et al.        Expires 3 September 2026              [Page 121]


  Internet-Draft                    CoRIM                       March 2026


       ? coswid.patch => bool,
       ? coswid.supplemental => bool,
       coswid.software-name => text,
       ? coswid.software-version => text,
       ? coswid.version-scheme => coswid.$version-scheme,
       ? coswid.media => text,
       ? coswid.software-meta => coswid.one-or-more<coswid.software-meta-\
                                                                   entry>,
       coswid.entity => coswid.one-or-more<coswid.entity-entry>,
       ? coswid.link => coswid.one-or-more<coswid.link-entry>,
       ? coswid.payload-or-evidence,
       * $$coswid-extension,
       coswid.global-attributes,
     }
     coswid.tag-id = 0
     coswid.$version-scheme /= coswid.multipartnumeric / coswid.\
     multipartnumeric-suffix / coswid.alphanumeric / coswid.decimal / \
                                                coswid.semver / int / text
     coswid.one-or-more<T> = T / [2*T]
     coswid.tag-version = 12
     coswid.corpus = 8
     coswid.patch = 9
     coswid.supplemental = 11
     coswid.software-name = 1
     coswid.software-version = 13
     coswid.version-scheme = 14
     coswid.media = 10
     coswid.software-meta = 5
     coswid.software-meta-entry = {
       ? coswid.activation-status => text,
       ? coswid.channel-type => text,
       ? coswid.colloquial-version => text,
       ? coswid.description => text,
       ? coswid.edition => text,
       ? coswid.entitlement-data-required => bool,
       ? coswid.entitlement-key => text,
       ? coswid.generator => text / bstr .size 16,
       ? coswid.persistent-id => text,
       ? coswid.product => text,
       ? coswid.product-family => text,
       ? coswid.revision => text,
       ? coswid.summary => text,
       ? coswid.unspsc-code => text,
       ? coswid.unspsc-version => text,
       * $$software-meta-extension,
       coswid.global-attributes,
     }
     coswid.entity = 2



  Birkholz, et al.        Expires 3 September 2026              [Page 122]


  Internet-Draft                    CoRIM                       March 2026


     coswid.entity-entry = {
       coswid.entity-name => text,
       ? coswid.reg-id => coswid.any-uri,
       coswid.role => coswid.one-or-more<coswid.$role>,
       ? coswid.thumbprint => coswid.hash-entry,
       * $$entity-extension,
       coswid.global-attributes,
     }
     coswid.link = 4
     coswid.link-entry = {
       ? coswid.artifact => text,
       coswid.href => coswid.any-uri,
       ? coswid.media => text,
       ? coswid.ownership => coswid.$ownership,
       coswid.rel => coswid.$rel,
       ? coswid.media-type => text,
       ? coswid.use => coswid.$use,
       * $$link-extension,
       coswid.global-attributes,
     }
     coswid.payload-or-evidence //= (coswid.payload => coswid.payload-\
                        entry // coswid.evidence => coswid.evidence-entry)
     coswid.global-attributes = (
       ? coswid.lang => text,
       * coswid.any-attribute,
       )
     coswid.multipartnumeric = 1
     coswid.multipartnumeric-suffix = 2
     coswid.alphanumeric = 3
     coswid.decimal = 4
     coswid.semver = 16384
     coswid.activation-status = 43
     coswid.channel-type = 44
     coswid.colloquial-version = 45
     coswid.description = 46
     coswid.edition = 47
     coswid.entitlement-data-required = 48
     coswid.entitlement-key = 49
     coswid.generator = 50
     coswid.persistent-id = 51
     coswid.product = 52
     coswid.product-family = 53
     coswid.revision = 54
     coswid.summary = 55
     coswid.unspsc-code = 56
     coswid.unspsc-version = 57
     coswid.entity-name = 31
     coswid.reg-id = 32



  Birkholz, et al.        Expires 3 September 2026              [Page 123]


  Internet-Draft                    CoRIM                       March 2026


     coswid.any-uri = uri
     coswid.role = 33
     coswid.$role /= coswid.tag-creator / coswid.software-creator / \
     coswid.aggregator / coswid.distributor / coswid.licensor / coswid.\
                                                   maintainer / int / text
     coswid.thumbprint = 34
     coswid.hash-entry = [
       hash-alg-id: int,
       hash-value: bytes,
     ]
     coswid.artifact = 37
     coswid.href = 38
     coswid.ownership = 39
     coswid.$ownership /= coswid.shared / coswid.private / coswid.\
                                                      abandon / int / text
     coswid.rel = 40
     coswid.$rel /= coswid.ancestor / coswid.component / coswid.feature \
     / coswid.installationmedia / coswid.packageinstaller / coswid.\
     parent / coswid.patches / coswid.requires / coswid.see-also / coswid\
                  .supersedes / coswid.supplemental / -256 .. 65536 / text
     coswid.media-type = 41
     coswid.use = 42
     coswid.$use /= coswid.optional / coswid.required / coswid.\
                                                  recommended / int / text
     coswid.payload = 6
     coswid.payload-entry = {
       coswid.resource-collection,
       * $$payload-extension,
       coswid.global-attributes,
     }
     coswid.evidence = 3
     coswid.evidence-entry = {
       coswid.resource-collection,
       ? coswid.date => coswid.integer-time,
       ? coswid.device-id => text,
       ? coswid.location => text,
       * $$evidence-extension,
       coswid.global-attributes,
     }
     coswid.lang = 15
     coswid.any-attribute = (coswid.label => coswid.one-or-more<text> / \
                                                  coswid.one-or-more<int>)
     coswid.tag-creator = 1
     coswid.software-creator = 2
     coswid.aggregator = 3
     coswid.distributor = 4
     coswid.licensor = 5
     coswid.maintainer = 6



  Birkholz, et al.        Expires 3 September 2026              [Page 124]


  Internet-Draft                    CoRIM                       March 2026


     coswid.shared = 3
     coswid.private = 2
     coswid.abandon = 1
     coswid.ancestor = 1
     coswid.component = 2
     coswid.feature = 3
     coswid.installationmedia = 4
     coswid.packageinstaller = 5
     coswid.parent = 6
     coswid.patches = 7
     coswid.requires = 8
     coswid.see-also = 9
     coswid.supersedes = 10
     coswid.optional = 1
     coswid.required = 2
     coswid.recommended = 3
     coswid.resource-collection = (
       coswid.path-elements-group,
       ? coswid.process => coswid.one-or-more<coswid.process-entry>,
       ? coswid.resource => coswid.one-or-more<coswid.resource-entry>,
       * $$resource-collection-extension,
       )
     coswid.date = 35
     coswid.integer-time = #6.1(int)
     coswid.device-id = 36
     coswid.location = 23
     coswid.label = text / int
     coswid.path-elements-group = (
       ? coswid.directory => coswid.one-or-more<coswid.directory-entry>,
       ? coswid.file => coswid.one-or-more<coswid.file-entry>,
       )
     coswid.process = 18
     coswid.process-entry = {
       coswid.process-name => text,
       ? coswid.pid => integer,
       * $$process-extension,
       coswid.global-attributes,
     }
     coswid.resource = 19
     coswid.resource-entry = {
       coswid.type => text,
       * $$resource-extension,
       coswid.global-attributes,
     }
     coswid.directory = 16
     coswid.directory-entry = {
       coswid.filesystem-item,
       ? coswid.path-elements => {coswid.path-elements-group},



  Birkholz, et al.        Expires 3 September 2026              [Page 125]


  Internet-Draft                    CoRIM                       March 2026


       * $$directory-extension,
       coswid.global-attributes,
     }
     coswid.file = 17
     coswid.file-entry = {
       coswid.filesystem-item,
       ? coswid.size => uint,
       ? coswid.file-version => text,
       ? coswid.hash => coswid.hash-entry,
       * $$file-extension,
       coswid.global-attributes,
     }
     coswid.process-name = 27
     coswid.pid = 28
     coswid.type = 29
     coswid.filesystem-item = (
       ? coswid.key => bool,
       ? coswid.location => text,
       coswid.fs-name => text,
       ? coswid.root => text,
       )
     coswid.path-elements = 26
     coswid.size = 20
     coswid.file-version = 21
     coswid.hash = 7
     coswid.key = 22
     coswid.fs-name = 24
     coswid.root = 25
     cbor-ip.ipv4-address = bytes .size 4
     cbor-ip.ipv6-address = bytes .size 16

  Acknowledgments

     The authors would like to thank the following people for their review
     and comments on this document: Carl Wallace Hannes Tschofenig Steven
     Bellock Jag Raman Giri Mandyam Jeremy O'Donoghue and Michael
     Richardson

  Contributors

     Carsten Bormann
     Universität Bremen TZI
     Postfach 330440
     D-28359 Bremen
     Germany
     Phone: +49-421-218-63921
     Email: cabo@tzi.org




  Birkholz, et al.        Expires 3 September 2026              [Page 126]


  Internet-Draft                    CoRIM                       March 2026


     Carsten Bormann contributed to the CDDL specifications and the IANA
     considerations.

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


     Andrew contributed the concept, description, and semantics of
     conditional endorsements as well as consistent contribution to weekly
     reviews of others' edits.

     Dionna Glaze
     Google LLC
     Email: dionnaglaze@google.com


     Dionna contributed many clarifying questions and disambiguations to
     the semantics of attestation appraisal as well as consistent
     contribution to weekly reviews of others' edits.

  Authors' Addresses

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


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


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


     Ned Smith
     Independent
     Email: ned.smith.ietf@outlook.com


     Wei Pan
     Huawei Technologies
     Email: william.panwei@huawei.com





  Birkholz, et al.        Expires 3 September 2026              [Page 127]


name: draft-wu-savnet-inter-domain-architecture
rev: 12
title: Inter-domain Source Address Validation (SAVNET) Architecture
time: 2024-11-03T09:50:49Z
group_uri: /api/v1/group/group/2317/
expires: 2025-05-07T09:50:49Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.246799+00:00
source: ietf
source_id: 111293
source_url: https://datatracker.ietf.org/doc/draft-wu-savnet-inter-domain-architecture/
doc_status: active
abstract:
  This document introduces an inter-domain SAVNET architecture for
     performing AS-level SAV and provides a comprehensive framework for
     guiding the design of inter-domain SAV mechanisms.  The proposed
     architecture empowers ASes to generate SAV rules by sharing SAV-
     specific information between themselves, which can be used to
     generate more accurate and trustworthy SAV rules in a timely manner
     compared to the general information.  During the incremental or
     partial deployment of SAV-specific information, it can utilize
     general information to generate SAV rules, if an AS's SAV-specific
     information is unavailable.  Rather than delving into protocol
     extensions or implementations, this document primarily concentrates
     on proposing SAV-specific and general information and guiding how to
     utilize them to generate SAV rules.  To this end, it also defines
     some architectural components and their relations.

full_text:
  Internet Engineering Task Force                                    D. Li
  Internet-Draft                                       Tsinghua University
  Intended status: Standards Track                                 L. Chen
  Expires: 7 May 2025                              Zhongguancun Laboratory
                                                                   N. Geng
                                                                    Huawei
                                                                    L. Liu
                                                                    L. Qin
                                                   Zhongguancun Laboratory
                                                           3 November 2024


        Inter-domain Source Address Validation (SAVNET) Architecture
                draft-wu-savnet-inter-domain-architecture-12

  Abstract

     This document introduces an inter-domain SAVNET architecture for
     performing AS-level SAV and provides a comprehensive framework for
     guiding the design of inter-domain SAV mechanisms.  The proposed
     architecture empowers ASes to generate SAV rules by sharing SAV-
     specific information between themselves, which can be used to
     generate more accurate and trustworthy SAV rules in a timely manner
     compared to the general information.  During the incremental or
     partial deployment of SAV-specific information, it can utilize
     general information to generate SAV rules, if an AS's SAV-specific
     information is unavailable.  Rather than delving into protocol
     extensions or implementations, this document primarily concentrates
     on proposing SAV-specific and general information and guiding how to
     utilize them to generate SAV rules.  To this end, it also defines
     some architectural components and their relations.

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



  Li, et al.                 Expires 7 May 2025                   [Page 1]


  Internet-Draft      Inter-domain SAVNET Architecture       November 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Inter-domain SAVNET Architecture Overview . . . . . . . . . .   7
     5.  SAV-related Information . . . . . . . . . . . . . . . . . . .  12
       5.1.  General Information . . . . . . . . . . . . . . . . . . .  12
         5.1.1.  RPKI ROA objects and ASPA Objects . . . . . . . . . .  12
         5.1.2.  Local Routing Information . . . . . . . . . . . . . .  13
         5.1.3.  IRR Data  . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  SAV-specific Information  . . . . . . . . . . . . . . . .  13
     6.  SAV Information Base  . . . . . . . . . . . . . . . . . . . .  14
     7.  SAVNET Communication Mechanism  . . . . . . . . . . . . . . .  18
       7.1.  SAV-specific Information Communication Mechanism  . . . .  19
       7.2.  General Information Communication Mechanism . . . . . . .  22
       7.3.  Management Information Communication Mechanism  . . . . .  22
     8.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  23
       8.1.  SAV at Customer Interfaces  . . . . . . . . . . . . . . .  23
         8.1.1.  Limited Propagation of Prefixes . . . . . . . . . . .  23
         8.1.2.  Hidden Prefixes . . . . . . . . . . . . . . . . . . .  25
         8.1.3.  Reflection Attacks  . . . . . . . . . . . . . . . . .  26
         8.1.4.  Direct Attacks  . . . . . . . . . . . . . . . . . . .  27
       8.2.  SAV at Provider/Peer Interfaces . . . . . . . . . . . . .  28
         8.2.1.  Reflection Attacks  . . . . . . . . . . . . . . . . .  28
         8.2.2.  Direct Attacks  . . . . . . . . . . . . . . . . . . .  30
     9.  Meeting the Design Requirements of Inter-domain SAVNET  . . .  31
       9.1.  Improving Validation Accuracy over Existing Mechanisms  .  31
       9.2.  Working in Incremental/Partial Deployment . . . . . . . .  31
       9.3.  Reducing Operational Overhead . . . . . . . . . . . . . .  33
       9.4.  Guaranteeing Convergence  . . . . . . . . . . . . . . . .  33
       9.5.  Providing Necessary Security Guarantee  . . . . . . . . .  34
     10. Manageability Considerations  . . . . . . . . . . . . . . . .  36



  Li, et al.                 Expires 7 May 2025                   [Page 2]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  36
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
     13. Scope and Assumptions . . . . . . . . . . . . . . . . . . . .  36
     14. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  38
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  38
       15.2.  Informative References . . . . . . . . . . . . . . . . .  39
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  40
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

  1.  Introduction

     Attacks based on source IP address spoofing, such as reflective DDoS
     and flooding attacks, continue to present significant challenges to
     Internet security.  Mitigating these attacks in inter-domain networks
     requires effective source address validation (SAV).  While BCP84
     [RFC3704] [RFC8704] offers some SAV solutions, such as ACL-based
     ingress filtering and uRPF-based mechanisms, existing inter-domain
     SAV mechanisms have limitations in terms of validation accuracy and
     operational overhead in different scenarios [inter-domain-ps].

     There are various existing general information from different sources
     including RPKI ROA objects and ASPA objects, RIB, FIB, and Internet
     Routing Registry (IRR) data, which can be used for inter-domain SAV.
     Generating SAV rules based on general information, however, cannot
     well satisfy the requirements for new inter-domain SAV mechanisms
     proposed in [inter-domain-ps].  As analyzed in Section 5, general
     information from RPKI ROA objects and ASPA objects can be used to
     infer the prefixes and their permissible incoming directions yet
     cannot be updated in a timely manner to adapt to the prefix or route
     changes, and the local routing information, which represents the
     general information from RIB or FIB, cannot deal with the asymmetric
     routing scenarios and may lead to improper blocks or improper
     permits, while IRR data do not update in a timely manner either and
     are not always accurate.

     Consequently, to address these issues, the inter-domain SAVNET
     architecture focuses on providing a comprehensive framework and
     guidelines for the design and implementation of new inter-domain SAV
     mechanisms.  Inter-domain SAVNET architecture proposes SAV-specific
     information and uses it to generate SAV rules.  SAV-specific
     information consists of prefixes and their corresponding legitimate
     incoming direction to enter an AS.  Inter-domain SAVNET architecture
     can use it to generate more accurate SAV rules.  In order to gather
     the SAV-specific information, a SAV-specific information
     communication mechanism would be developed for origination,
     processing, propagation, and termination of the messages which carry
     the SAV-specific information, and it can be implemented by a new



  Li, et al.                 Expires 7 May 2025                   [Page 3]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     protocol or extending an existing protocol.  When the prefixes or
     routes change, it can update the SAV-specific information
     automatically in a timely manner.  Also, the inter-domain SAVNET
     architecture will communicate the SAV-specific information over a
     secure connection between authenticated ASes.

     Moreover, during the incremental/partial deployment period of the
     SAV-specific information, the inter-domain SAVNET architecture can
     leverage the general information to generate SAV rules, if the SAV-
     specific information of an AS is unavailable.  Multiple information
     sources may exist concurrently, to determine the one used for
     generating SAV rules, the inter-domain SAVNET architecture assigns
     priorities to the SAV-specific information and different general
     information and generates SAV rules using the SAV-related information
     with the highest-priority.  SAV-specific information has the highest
     priority and the priorities of RPKI ROA objects and ASPA objects,
     RIB, FIB, and IRR data decrease in turn.

     +-----------+
     | AS 1 (P1) #
     +-----------+ \
                    \           Spoofed Packets
                  +-+#+-------+ with Source Addresses in P1 +-----------+
                  |    AS 2   #-----------------------------#   AS 4    |
                  +-+#+-------+                             +-----------+
                    /
     +-----------+ /
     |   AS 3    #
     +-----------+
     AS 4 sends spoofed packets with source addresses in P1 to AS 3
     through AS 2.
     If AS 1 and AS 2 deploy inter-domain SAV, the spoofed packets
     can be blocked at AS 2.

        Figure 1: An example for illustrating the incentive of deploying
                       inter-domain SAVNET architecture.

     The inter-domain SAVNET architecture provides the incentive to deploy
     inter-domain SAV for operators.  Figure 1 illustrates this using an
     example.  P1 is the source prefix of AS 1, and AS 4 sends spoofing
     packets with P1 as source addresses to AS 3 through AS 2.  Assume AS
     4 does not deploy intra-domain SAV, these spoofing packets cannot be
     blocked by AS 4.  Although AS 1 can deploy intra-domain SAV to block
     incoming packets which spoof the addresses of AS 1, these spoofing
     traffic from AS 4 to AS 3 do not go through AS 1, so they cannot be
     blocked by AS 1.  Inter-domain SAVNET architecture can help in this
     scenario.  If AS 1 and AS 2 deploy inter-domain SAVNET architecture,
     AS 2 knows that the packets with P1 as source addresses should come



  Li, et al.                 Expires 7 May 2025                   [Page 4]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     from AS 1, and the spoofing packets can thus be blocked by AS 2 since
     they come from the incorrect direction.  Specifically, by proposing
     SAV-specific information and using it to generate SAV rules, the
     inter-domain SAVNET architecture gives more deployment incentive
     compared to existing inter-domain SAV mechanisms, which will be
     analyzed in Section 8.

     In addition, this document primarily proposes a high-level
     architecture for describing the communication flow of SAV-specific
     information and general information, guiding how to utilize the SAV-
     specific information and general information for generating SAV rules
     and deploy an inter-domain SAV mechanism between ASes.  This document
     does not specify protocol extensions or implementations.  Its purpose
     is to provide a conceptual framework and guidance for the design and
     development of inter-domain SAV mechanisms, allowing implementers to
     adapt and implement the architecture based on their specific
     requirements and network environments.

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

  2.  Terminology

     SAV Rule:
        The rule that indicates the validity of a specific source IP
        address or source IP prefix.

     SAV Table:
        The table or data structure that implements the SAV rules and is
        used for performing source address validation on the data plane.

     SAV-specific Information:
        The information that is specialized for SAV rule generation,
        includes the source prefixes and their legitimate incoming
        directions to enter an AS, and is gathered by the communication
        between ASes with the SAV-specific information communication
        mechanism.

     SAV-specific Information Communication Mechanism:
        The mechanism that is used to communicate SAV-specific information
        between ASes and can be implemented by a new protocol or an
        extension to an existing protocol.




  Li, et al.                 Expires 7 May 2025                   [Page 5]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Local Routing Information:
        The information that is stored in ASBR's local RIB or FIB and can
        be used to generate SAV rules in addition to the routing purpose.

     General Information:
        The information that is not specialized for SAV but can be
        utilized to generate SAV rules, and is initially utilized for
        other purposes.  Currently, the general information consists of
        the information from RPKI ROA objects and ASPA objects, local
        routing information, and the one from IRR data.

     SAV-related Information:
        The information that can be used to generate SAV rules and
        includes SAV-specific information and general information.

     SAVNET Agent:
        The agent within a SAVNET-adopting AS that is responsible for
        gathering SAV-related information and utilizing it to generate SAV
        rules.

     SAV Information Base:
        SAV information base is a table or data structure for storing SAV-
        related information collected from different SAV information
        sources and is a component within SAVNET agent.

     SAV Information Base Manager:
        SAV information base manager maitains the SAV-related information
        in the SAV information base and uses it to generate SAV rule
        accordingly, and is a component within SAVNET agent.

     Improper Block:
        The validation results that the packets with legitimate source
        addresses are blocked improperly due to inaccurate SAV rules.

     Improper Permit:
        The validation results that the packets with spoofed source
        addresses are permitted improperly due to inaccurate SAV rules.

     Source AS:
        The AS which deploys SAVNET agent and communicates its own SAV-
        specific information to other ASes for generating SAV rules.

     Validation AS:
        The AS which deploys SAVNET agent and generates SAV rules
        according to the received SAV-specific information from source
        ASes.





  Li, et al.                 Expires 7 May 2025                   [Page 6]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


  3.  Design Goals

     The inter-domain SAVNET architecture aims to improve SAV accuracy and
     facilitate partial deployment with low operational overhead, while
     guaranteeing convergence and providing security guarantees to the
     communicated information, which corresponds to the requirements for
     new inter-domain SAV mechanisms proposed in the inter-domain SAVNET
     architecture draft [inter-domain-ps].  The overall goal can be broken
     down into the following aspects:

     *  *G1*: The inter-domain SAVNET architecture should learn the real
        paths of source prefixes to any destination prefixes or
        permissible paths that can cover their real paths, and generate
        accurate SAV rules automatically based on the learned information
        to avoid improper blocks and reduce improper permits as much as
        possible.

     *  *G2*: The inter-domain SAVNET architecture should provide
        sufficient protection for the source prefixes of ASes that deploy
        it, even if only a portion of the Internet does the deployment.

     *  *G3*: The inter-domain SAVNET architecture should adapt to dynamic
        networks and asymmetric routing scenarios automatically.

     *  *G4*: The inter-domain SAVNET architecture should promptly detect
        the network changes and launch the convergence process in a timely
        manner, while reducing improper blocks and improper permits during
        the convergence process.

     *  *G5*: The inter-domain SAVNET architecture should provide security
        guarantees for the communicated SAV-specific information.

     Other design goals, such as low operational overhead and easy
     implementation, are also very important and should be considered in
     specific protocols or protocol extensions.

  4.  Inter-domain SAVNET Architecture Overview














  Li, et al.                 Expires 7 May 2025                   [Page 7]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


      +~~~~~~~~~~~~~~~~~~~~~~~~+       +--------------------+
      |RPKI Cache Server/IRR DB|       | AS X's Provider AS |
      +~~~~~~~~~~~~~~~~~~~~~~~~+       +------------+/\+/\+-+
        ROA & ASPA |                 BGP /            |  |
     Obj./IRR Data |            Message /             |  |
                   |                   /              |  | BGP
     +-----------+\/+----------------+\/+-+           |  | Message
     |                AS X                |  BGP  +--------------+
     | +--------------------------------+ |<------|AS X's Lateral|
     | |          SAVNET Agent          | |Message|   Peer  AS   |
     | +--------------------------------+ |       +--------------+
     +-----+/\+/\+----------------+/\+/\+-+
             |  |                   |  |
         BGP |  | SAV-specific      |  |
     Message |  | Message           |  |
     +------------------+           |  |
     |AS X's Customer AS|           |  |
     +-------+/\+-------+           |  |
               \                    |  |
            BGP \  SAV-specific     |  | BGP
         Message \ Message          |  | Message
         +------------------------------------+
         |          AS X's Customer AS        |
         | +--------------------------------+ |
         | |         SAVNET Agent           | |
         | +--------------------------------+ |
         +------------------------------------+
     AS X and one of its customer ASes have deployed SAVNET agent
     and can exchange SAV-specific information with each other.

                  Figure 2: Inter-domain SAVNET architecture.

     Figure 2 provides an overview of the inter-domain SAVNET
     architecture, showcasing an AS topology and the flow of SAV-related
     information among ASes.  The topology captures the full spectrum of
     AS relationships in the Internet, displaying all peer ASes of AS X
     including customers, lateral peers, and providers and the existence
     of multiple physical links between ASes.  Arrows in the figure
     indicate the direction of the corresponding SAV-related information
     from its source to AS X, such as gathering RPKI ROA objects and ASPA
     objects from RPKI cache server.  The inter-domain SAVNET architecture
     conveys the SAV-related information through various mediums such as
     SAV-specific messages, BGP messages, RTR messages, and FTP messages.
     Based on the SAV-related information, AS X generates SAV rules.  It
     is also worth noting that the inter-domain SAVNET architecture
     discusses AS-level inter-domain SAV.





  Li, et al.                 Expires 7 May 2025                   [Page 8]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Figure 2 uses AS X as the representative to illustrate that what SAV-
     related information the SAVNET agent within AS X will collect and
     where the information is from.  AS X has deployed SAVNET agent and
     can generate SAV rules to perform inter-domain SAV by consolidating
     the SAV-related information.  It can obtain SAV-specific information
     from its customer AS which deploys SAVNET agent and local routing
     information originating from the BGP update messages of its neighbor
     ASes.  Also, AS X can obtain RPKI ROA objects and ASPA objects from
     RPKI cache server and IRR data from IRR database.

     The inter-domain SAVNET architecture proposes SAV-specific
     information, which is more accurate and trustworthy than existing
     general information, and can update in a timely manner.  SAV-specific
     information consists of prefixes and their legitimate incoming
     directions.  The SAVNET agent communicates SAV-specific information
     between ASes via SAV-specific messages, when prefixes or routes
     change, it can launch SAV-specific messages timely to update SAV-
     specific information.  Additionally, when SAVNET agent receives SAV-
     specific messages, it will validate whether the SAV-specific
     connections for communicating SAV-specific messages are authentic
     connections from authenticated ASes.  Therefore, when SAV-specific
     information of an AS is available, SAVNET agent will use it to
     generate SAV rules.

     Furthermore, if the SAV-specific information is needed to communicate
     between ASes, a new SAV-specific information communication mechanism
     would be developed to exchange the SAV-specific messages between ASes
     which carry the SAV-specific information.  It should define the data
     structure or format for communicating the SAV-specific information
     and the operations and timing for originating, processing,
     propagating, and terminating the SAV-specific messages.

     The SAVNET agent should launch SAV-specific messages to adapt to the
     route changes in a timely manner.  The SAV-specific information
     communication mechanism should handle route changes carefully to
     avoid improper blocks.  The reasons for leading to improper blocks
     may include late detection of route changes, delayed message
     transmission, or packet losses.  During the convergence process of
     the SAV-specific information communication mechanism, the inter-
     domain SAVNET architecture can use the information from RPKI ROA
     objects and ASPA objects to generate SAV rules until the convergence
     process is finished, since these information includes topological
     information and is more stable, and can thus avoid improper blocks.
     However, the detailed design of the SAV-specific information
     communication mechanism for dealing with route changes is outside the
     scope of this document.





  Li, et al.                 Expires 7 May 2025                   [Page 9]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     In the incremental/partial deployment stage of the inter-domain
     SAVNET architecture, when the SAV-specific information of some ASes
     is unavailable, SAVNET agent can leverage general information to
     generate SAV rules.  If all these general information is available,
     it is recommended to use RPKI ROA objects and ASPA objects to
     generate SAV rules.  Since compared to the local routing information
     and IRR data, they can provide authoritative prefixes and topological
     information and have less improper blocks.  The systematic
     recommendations for the utilizations of SAV-related information and
     the corresponding rationale will be illustrated in Section 6.

     SAV-specific information communication mechanism will require
     specifying a new inter-router (or inter-AS) communication protocol or
     modifying an existing one.  Therefore, while this is pursued, a new
     SAV mechanism that utilizes RPKI objects (e.g., ROA, ASPA) and BGP
     data (RIB/FIB) can be pursued.  The latter solution may have the
     potential for deployment in the near term since it utilizes existing
     SAV-related information and can be deployed by network operators by
     policy configuration on routers.

     For ASes that support a network controller, such as a multi-AS or
     single-AS controller, operators can deploy the SAVNET agent on the
     controller to represent the ASes it manages and communicate SAV-
     specific information with others.  Additionally, ASes managed by the
     same controller may obtain SAV-specific information directly from the
     controller without needing to communicate with each other.

     Regarding the security concerns, the inter-domain SAVNET architecture
     shares the similar security threats with BGP and can leverage
     existing BGP security mechanisms to enhance both session and content
     security.




















  Li, et al.                 Expires 7 May 2025                  [Page 10]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     +-----------------------------------------------------------+
     |                           AS X                            |
     | +-------------------------------------------------------+ |
     | |                      SAVNET Agent                     | |
     | | +---------------------+  +--------------------------+ | |
     | | | General Information |  | SAV-specific Information | | |
     | | +---------------------+  +--------------------------+ | |
     | |            |                           |              | |
     | |           \/                          \/              | |
     | | +---------------------------------------------------+ | |
     | | | +-----------------------------------------------+ | | |
     | | | |              SAV Information Base             | | | |
     | | | +-----------------------------------------------+ | | |
     | | |            SAV Information Base Manager           | | |
     | | +---------------------------------------------------+ | |
     | |                          |SAV Rules                   | |
     | +-------------------------------------------------------+ |
     |                            |                              |
     |                           \/                              |
     | +-------------------------------------------------------+ |
     | |                      SAV Table                        | |
     | +-------------------------------------------------------+ |
     +-----------------------------------------------------------+

         Figure 3: SAVNET agent and SAV table within AS X in Figure 2.

     Figure 3 displays the SAVNET agent and SAV table within AS X.  The
     SAVNET agent can obtain the SAV-specific information and general
     information from various SAV information sources including SAV-
     specific messages from other ASes, RPKI cache server, and RIB or FIB
     as long as they are available.  The SAV information base (SIB) within
     the SAVNET agent can store the SAV-specific information and general
     information and is maintained by the SIB manager.  And SIB manager
     generates SAV rules based on the SIB and fills out the SAV table on
     the data plane.  Moreover, the SIB can be managed by network
     operators using various methods such as YANG [RFC6020], Command-Line
     Interface (CLI), remote triggered black hole (RTBH) [RFC5635], and
     Flowspec [RFC8955].  The detailed collection methods of the SAV-
     related information depend on the deployment and implementation of
     the inter-domain SAV mechanisms and are out of scope for this
     document.

     In the data plane, the packets coming from other ASes will be
     validated by the SAV table and only the packets which are permitted
     by the SAV table will be forwarded to the next hop.  To achieve this,
     the router looks up each packet's source address in its local SAV
     table and gets one of three validity states: "Valid", "Invalid" or
     "Unknown".  "Valid" means that there is a source prefix in SAV table



  Li, et al.                 Expires 7 May 2025                  [Page 11]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     covering the source address of the packet and the valid incoming
     interfaces covering the actual incoming interface of the packet.
     According to the SAV principle, "Valid" packets will be forwarded.
     "Invalid" means there is a source prefix in SAV table covering the
     source address, but the incoming interface of the packet does not
     match any valid incoming interface so that such packets will be
     dropped.  "Unknown" means there is no source prefix in SAV table
     covering the source address.  The packet with "unknown" addresses can
     be dropped or permitted, which depends on the choice of operators.
     The structure and detailed usage of SAV table can refer to
     [sav-table].

  5.  SAV-related Information

     SAV-related information represents the information that can be used
     for SAV and consists of RPKI ROA objects and ASPA objects, local
     routing information, IRR data, and SAV-specific information.  In the
     inter-domain SAVNET architecture, RPKI ROA objects and ASPA objects,
     local routing information, and IRR data are categorized into general
     information.  In the future, if a new information source is created
     and can be used for SAV, but is not originally and specially used for
     SAV, its information can be categorized into general information.  In
     other words, general information can also be considered as dual-use
     information.

  5.1.  General Information

     General information refers to the information that is not directly
     designed for SAV but can be utilized to generate SAV rules, and
     includes RPKI ROA objects and ASPA objects, local routing
     information, and IRR data.

  5.1.1.  RPKI ROA objects and ASPA Objects

     The RPKI ROA objects and ASPA objects are originally designed for the
     routing security purpose.  RPKI ROA objects consists of {prefix,
     maximum length, origin AS} information and are originally used to
     mitigate the route origin hijacking, while RPKI ASPA objects consists
     of {ASN, Provider AS Set} information and are originally used to
     mitigate the route leaks.  Both the objects are verified and
     authoritative.  They are also stable and will not be updated
     frequently.

     Based on ASPA objects, the AS-level network topology can be
     constructed.  And according to the ROA objects and the constructed
     AS-level topology information, an AS can learn all the permissible
     paths of the prefixes from its customer cone.  Therefore, the
     prefixes and all its permissible incoming directions can be obtained.



  Li, et al.                 Expires 7 May 2025                  [Page 12]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     SAV based on RPKI ROA and ASPA objects only may lead to improper
     blocks, because not all ASes register their ROA and ASPA objects at
     the current stage.  In addition, all the permissible incoming
     directions learned from ASPA objects do not only consist of the real
     incoming directions of the prefixes, but also the extra non-used
     incoming directions by the legitimate traffic.  Only utilizing RPKI
     ROA and ASPA objects for generating SAV rules with their full
     deployment within the customer cone may lead to improper permits when
     not all ASes perform SAV.

     According to a recent study [rpki-time-of-flight], the process of
     updating RPKI information typically requires several minutes to an
     hour.  This encompasses the addition or deletion of RPKI objects and
     the subsequent retrieval of updated information by ASes.

  5.1.2.  Local Routing Information

     The local routing information is originally used to guide the packet
     forwarding on each router and can be stored in the local RIB or FIB.
     It can be parsed from the BGP messages communicated between ASes.
     Existing uRPF-based SAV mechanisms [RFC3704] [RFC8704] use the local
     routing information to generate SAV rules.  As analyzed in
     [inter-domain-ps], in the asymmetric routing scenarios, these
     mechanisms, generating SAV rules using local routing information
     only, have accuracy problems and would lead to improper permits or
     improper blocks.

  5.1.3.  IRR Data

     The IRR data consist of ASes and their corresponding prefixes and can
     be used for SAV [RFC8704].  However, SAV using IRR data only would
     have limited functioning scope, in inter-domain networks, it may only
     be able to prevent spoofing by a stub AS.  In addition, the IRR data
     are not always accurate [RFC8704].

  5.2.  SAV-specific Information

     SAV-specific information is the information that is specifically
     designed for SAV and consists of prefixes and their legitimate
     incoming directions to enter ASes.  It can be contained in the SAV-
     specific messages which are communicated between ASes which deploy
     the inter-domain SAVNET architecture.  When parsing the SAV-specific
     messages and obtaining the SAV-specific information, ASes can learn
     the prefixes and their legitimate incoming direction to enter
     themselves.






  Li, et al.                 Expires 7 May 2025                  [Page 13]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Moreover, in the inter-domain SAVNET architecture, a SAV-specific
     information communication mechanism is used to communicate SAV-
     specific information between ASes and distribute the updated
     information to the relative ASes automatically in a timely manner
     once the prefixes or routes change.  Compared against general
     information, it may be expected that SAV-specific information is more
     accurate and trustworthy, while it can update the SAV rules in a
     timely manner to adapt to the prefix or route changes.

  6.  SAV Information Base

     +---------------------------------------------------+----------+
     |              SAV Information Sources              |Priorities|
     +---------------------------------------------------+----------+
     |              SAV-specific Information             |     1    |
     +---------------------+-----------------------------+----------+
     |                     | RPKI ROA Obj. and ASPA Obj. |     2    |
     |                     +-----------------------------+----------+
     |                     |             RIB             |     3    |
     | General Information +-----------------------------+----------+
     |                     |             FIB             |     4    |
     |                     +-----------------------------+----------+
     |                     |           IRR Data          |     5    |
     +---------------------+-----------------------------+----------+
     Priority ranking from 1 to 5 represents high to low priority.

          Figure 4: Priority ranking for the SAV information sources.

     The SIB is managed by the SIB manager, which can consolidate SAV-
     related information from different sources.  Figure 4 presents the
     priority ranking for the SAV-specific information and general
     information.  Priority ranking from 1 to 5 represents high to low
     priority.  Inter-domain SAVNET architecture can use SAV-related
     information from different sources to generate SAV rules based on
     their priorities.  Once the SAV-specific information for a prefix is
     available within the SIB, the inter-domain SAVNET uses it to generate
     SAV rules; otherwise, the inter-domain SAVNET can generate SAV rules
     based on general information.  The inter-domain SAVNET architecture
     assigns priorities to the information from different sources, and
     recommends using the information with the highest priority from all
     the available information to generate SAV rules.

     The priority ranking recommendation for different SAV information
     sources in Figure 4 is based on the accuracy, timeliness,
     trustworthiness of the information from these sources.  SAV-specific
     information has higher priority than the general information, since
     it is specifically designed to carry more accurate SAV information,
     and can be updated in a timely manner to adapt to the prefix or route



  Li, et al.                 Expires 7 May 2025                  [Page 14]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     changes.  The general information from RPKI ROA objects and ASPA
     objects, RIB, FIB, IRR data has different priorities, ranking 2, 3,
     4, and 5, respectively.  RPKI ROA objects and ASPA objects have
     higher priority than the one from RIB, FIB, and IRR data, this is
     because they can provide authoritative prefixes and topology
     information, which can be used to generate more accurate SAV rules.
     Also, they are more stable and can be used to reduce the risk of
     improper blocks during the convergence process of the network.
     Although the information source for RIB and FIB is the same, the RIB
     consists of more backup path information than the FIB, which can
     reduce improper blocks.  IRR data have the lowest priority compared
     to others, since they are usually updated in a slower manner than the
     real network changes and not always correct.

     It is noteworthy that the priority ranking of SAV information sources
     in Figure 4 is recommended rather than mandated.  If a new inter-
     domain SAV mechanism needs to generate SAV rules using low-priority
     SAV informaiton sources, it should ensure that the correct
     information is obtained from the corresponding sources and adopts
     appropriate SAV actions in the data plane to avoid improper block and
     minimize improper permit.  A new inter-domain SAVNET mechanism, in
     line with the inter-domain SAVNET architecture, has the flexibility
     to determine the utilized SAV information sources and their
     priorities accordingly.  Especially, when using RPKI ROA objects and
     ASPA objects as the SAV information source, the new inter-domain
     SAVNET mechanism should avoid jeopardizing the use of RPKI in routing
     security.
























  Li, et al.                 Expires 7 May 2025                  [Page 15]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


                             +----------------+
                             |    AS 3(P3)    |
                             +-+/\-----+/\+/\++
                                /        \  \
                      P3[AS 3] /          \  \ P3[AS 3]
                              /            \  \
                             / (C2P)        \  \
                    +----------------+       \  \
                    |    AS 4(P4)    |        \  \
                    ++/\+/\+/\+/\+/\++         \  \
       P6[AS 1, AS 2] /  /  |  |    \           \  \
            P2[AS 2] /  /   |  |     \           \  \
                    /  /    |  |      \           \  \
                   /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                  /  /      |  |        \           \  \
                 /  /(C2P)  |  |         \           \  \
     +----------------+     |  |          \           \  \
     |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
     +--------+/\+----+     |  | P6[AS 1]   \           \  \
       P6[AS 1] \           |  | NO_EXPORT   \           \  \
        P1[AS 1] \          |  |              \           \  \
        NO_EXPORT \         |  |               \           \  \
                   \ (C2P)  |  | (C2P/P2P) (C2P)\     (C2P) \  \
                +----------------+              +----------------+
                |  AS 1(P1, P6)  |              |    AS 5(P5)    |
                +----------------+              +----------------+
     Both AS 1 and AS 4 deploy the inter-domain SAVNET architecture
     and can exchange the SAV-specific information with each other,
     while other ASes do not deploy it.

                      Figure 5: An example of AS topology.




















  Li, et al.                 Expires 7 May 2025                  [Page 16]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     +-----+------+------------------+--------+------------------------+
     |Index|Prefix|Incoming Direction|Relation| SAV Information Source |
     +-----+------+------------------+--------+------------------------+
     |  0  |  P1  |       AS 2       |Customer|SAV-specific Information|
     +-----+------+------------------+--------+------------------------+
     |  1  |  P1  |       AS 1       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  2  |  P2  |       AS 2       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  3  |  P3  |       AS 3       |Provider|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  4  |  P5  |       AS 3       |Provider|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  5  |  P5  |       AS 5       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  6  |  P6  |       AS 2       |Customer|  General Information   |
     |     |      |                  |        |SAV-specific Information|
     +-----+------+------------------+--------+------------------------+
     |  7  |  P6  |       AS 1       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+

          Figure 6: An example for the SAV information base of AS 4 in
                                   Figure 6.

     We use the examples shown in Figure 5 and Figure 6 to introduce SIB
     and illustrate how to generate SAV rules based on the SIB.  Figure 6
     depicts an example of the SIB established in AS 4 displayed in
     Figure 5.  Each row of the SIB contains an index, prefix, incoming
     direction of the prefix, reltation between ASes, and the
     corresponding sources of the information.  The incoming direction
     consists of customer, provider, and peer.  For example, in Figure 6,
     the row with index 0 indicates the incoming direction of P1 is AS 2
     and the information source is SAV-specific information.  Note that
     the same SAV-related information may have multiple sources and the
     SIB records them all, such as the row indexed 6.  Moreover, SIB
     should be carefully implemented in the specific protocol or protocol
     extensions to avoid becoming a heavy burden of the router, and the
     similar optimization approaches used for the RIB may be applied.













  Li, et al.                 Expires 7 May 2025                  [Page 17]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Recall that inter-domain SAVNET architecture generates SAV rules
     based on the SAV-related information in the SIB and their priorities.
     In addition, in the case of an AS's interfaces facing provider or
     lateral peer ASes where loose SAV rules are applicable, the inter-
     domain SAVNET architecture recommends to use blocklist at such
     directions to only block the prefixes that are sure not to come at
     these directions, while in the case of an AS's interfaces facing
     customer ASes that necessitate stricter SAV rules, the inter-domain
     SAVNET architecture recommends to use allowlist to only permit the
     prefixes that are allowed to come at these directions.

     Based on the above rules, taking the SIB in Figure 6 as an example to
     illustrate how the inter-domain SAVNET generates rules, AS 4 can
     conduct SAV as follows: SAV at the interfaces facing AS 3 blocks P1,
     P2, and P6 according to the rows indexed 0, 2, and 6 in the SIB, SAV
     at the interfaces facing AS 2 permits P1, P2, and P6 according to the
     rows indexed 0, 2, and 6 in the SIB, SAV at the interfaces facing AS
     1 does not permit any prefixes according to the row indexed 0, 1, 6,
     and 7 in the SIB, and SAV at the interfaces facing AS 5 permits P5
     according to the row indexed 5 in the SIB.

  7.  SAVNET Communication Mechanism

     +------+
     |      | SAV-specific Information +-----------------------------+
     |      |<=========================|  SAVNET Agent in other ASes |
     |      |                          +-----------------------------+
     |      |                        +---------------------------------+
     |      |                        | +-----------------------------+ |
     |      |                        | | RPKI ROA Obj. and ASPA Obj. | |
     |      |                        | +-----------------------------+ |
     |      |                        | +-----------------------------+ |
     |      |                        | |             RIB             | |
     |SAVNET|  General Information   | +-----------------------------+ |
     |Agent |<-----------------------| +-----------------------------+ |
     |      |                        | |             FIB             | |
     |      |                        | +-----------------------------+ |
     |      |                        | +-----------------------------+ |
     |      |                        | |         IRR Database        | |
     |      |                        | +-----------------------------+ |
     |      |                        +---------------------------------+
     |      |  Management Information  +-----------------------------+
     |      |<-------------------------|      Network Operators      |
     |      |                          +-----------------------------+
     +------+

         Figure 7: Gathering SAV-related information from different SAV
                              information sources.



  Li, et al.                 Expires 7 May 2025                  [Page 18]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     SAV-specific information relies on the communication between SAVNET
     agents, and general information can be from RPKI ROA objects and ASPA
     objects, RIB, FIB, and IRR data.  Therefore, as illustrated in
     Figure 7, the SAVNET agent needs to receive the SAV-related
     information from these SAV information sources.  SAVNET agent also
     needs to accept the configurations from network operators for the
     management operations.  Gathering these types of information relies
     on the SAVNET communication mechanism, which includes SAV-specific
     information communication mechanism, general information
     communication mechanism, and management information communication
     mechanism.

  7.1.  SAV-specific Information Communication Mechanism

                    +------------------------+
                    |      AS 3(P3, P3')     |
                    |   +----------------+   |
                    |   |  SAVNET Agent  |   |
                    |   +----------------+   |
                    +-+/\+---------------+/\++
                       /                |  |
        SAV-specific  /                 |  |
         Messages[   /     SAV-specific |  |
        (P1, AS 2)] /         Messages[ |  |
                   /        (P3, AS 3), |  |
                  /        (P3', AS 3)] |  |
         +------------+                 |  |
         |  AS 2(P2)  |                 |  |
         +------+/\+--+                 |  | SAV-specific
     SAV-specific \                     |  | Messages[
        Messages[  \                    |  | (P1, AS 1)]
        (P1, AS 2)] \                   |  |
                     \                  |  |
                   +-------------------+\/+--+
                   |         AS 1(P1)        |
                   |    +--------------+     |
                   |    | SAVNET Agent |     |
                   |    +--------------+     |
                   +-------------------------+
     (1) The path of the legitimate traffic with source addresses in P1
         and destination addresses in P3 is [AS 1, AS 2, AS 3].
     (2) The path of the legitimate traffic with source addresses in P1
         and destination addresses in P3' is [AS 1, AS 3].
     (3) The path of the legitimate traffic with source addresses in P3
         or P3' and destination addresses in P1 is [AS 3, AS 1].






  Li, et al.                 Expires 7 May 2025                  [Page 19]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


       Figure 8: An example for exchanging SAV-specific information with
       SAV-specific information communication mechanism between AS 1 and
                                     AS 3.

     Figure 8 uses an example to show the exchange of SAV-specific
     information between AS 1 and AS 3 through SAV-specific messages.  The
     SAV-specific information is expressed as <Prefix, Incoming Direction>
     pairs, such as (P1, AS 1), (P1, AS 2), (P3, AS 3), and (P3', AS 3) in
     Figure 8.  AS 1 needs to determine the incoming direction to AS 3 for
     its prefix P1 to obtain SAV-specific information, such as (P1, AS 1)
     and (P1, AS 2).  It then assembles this information into SAV-specific
     messages to send to AS 3, which can subsequently generate SAV rules
     based on the received information.  This process may require AS 1 to
     collaborate with intermediate ASes between AS 1 and AS 3 to obtain
     the SAV-specific information.  Similarly, AS 3 needs to determine the
     incoming direction to AS 1 for its prefixes P3 and P3' and send the
     SAV-specific information, such as (P3, AS 3) and (P3', AS 3), to AS 1
     through SAV-specific messages, allowing AS 1 to generate the
     corresponding SAV rules.  AS 3 may also need to collaborate with
     intermediate ASes between AS 3 and AS 1 to gather the required
     information for obtaining the SAV-specific information.

     The SAV-specific information can be exchanged between ASes via SAV-
     specific messages.  SAV-specific messages are used to propagate or
     originate the SAV-specific information between ASes by the SAVNET
     agent.  For an AS which initiates its own SAV-specific messages, its
     SAVNET agent needs to obtain the incoming direction of its own
     prefixes to enter other ASes and assemble them into the SAV-specific
     messages to the corresponding ASes.  When ASes receive the SAV-
     specific messages, they parse the messages to obtain source prefixes
     and their corresponding incoming directions.

     Additionally, if SAV-specific information is communicated between
     ASes, a new SAV-specific information communication mechanism would
     need to be developed to communicate it and can be implemented by a
     new protocol or extending an existing protocol.  The SAV-specific
     information communication mechanism needs to define the data
     structure or format to communicate the SAV-specific messages and the
     operations and timing for originating, processing, propagating, and
     terminating the messages.  If an extension to an existing protocol is
     used to exchange SAV-specific information, the corresponding existing
     protocol should not be affected.  The SAVNET agent is the entity to
     support the SAV-specific communication mechanism.  By parsing the
     SAV-specific messages, it obtains the prefixes and their incoming AS
     direction for maintaining the SIB.  It is important to note that the
     SAVNET agent within an AS has the capability to establish connections
     with multiple SAVNET agents within different ASes, relying on either
     manual configurations by operators or an automatic mechanism.  In



  Li, et al.                 Expires 7 May 2025                  [Page 20]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     addition, SAVNET agents should validate the authenticity of the
     connection for communicating the SAV-specific information to verify
     whether the SAV-specific information is provided over a secure
     connection with an authenticated AS.

     The need for a SAV-specific communication mechanism arises from the
     facts that the SAV-specific information needs to be obtained and
     communicated between ASes.  Different from the general information
     such as routing information from the RIB, there are no existing
     mechanism which can support the perception and communication of SAV-
     specific information between ASes.  Hence, a SAV-specific
     communication mechanism is needed to provide a medium and set of
     rules to establish communication between different ASes for the
     exchange of SAV-specific information.

     Furthermore, in order to obtain all the source prefixes of an AS, the
     inter-domain SAVNET architecture may communicate with the intra-
     domain SAVNET architecture [intra-domain-arch] to obtain all the
     prefixes belonging to an AS.  If the legitimate incoming directions
     of SAV-specific information are learned from BGP AS_PATH information,
     it needs to note that BGP AS_PATH may hide some interfaces that exist
     between ASes in the scenarios involving topological fork and merge.

     Some scenarios, such as the ones where policy-based routing or static
     route exist in the inter-domain networks, may rely on the wider
     deployment of SAVNET agent or more interactive communication between
     ASes to make the inter-domain SAVNET work better.  In these
     scenarios, operators may override the default BGP decision by using
     policy-based routing or static route.  For example, in Figure 8, AS 2
     may use another AS which does not in the AS path [AS 1, AS 2, AS 3]
     to transmit the legitimate traffic with source addresses in P1 to AS
     3.  For such cases, inter-domain SAVNET may require AS 2 to deploy
     SAVNET agent to obtain the SAV-specific information for the
     legitimate traffic with source addresses in P1, or AS 1 and AS 3 may
     need more interactive communication to obtain the SAV-specific
     information.

     The preferred AS paths of an AS may change over time due to route
     changes caused by operator configurations or network failures.  In
     addition, the SAVNET agent should be aware of the route changes and
     launch SAV-specific messages to adapt to the route changes in a
     timely manner.  The SAV-specific information communication mechanism
     should handle route changes carefully to avoid improper blocks.  The
     reasons for leading to improper blocks may include late detection of
     route changes, delayed message transmission, or packet losses.  If
     the SAVNET agent cannot be aware of the route changes caused by
     failures, it may not be aware of the failures.  A wider deployment of
     SAVNET agent can make network failure sensing more sensitive.



  Li, et al.                 Expires 7 May 2025                  [Page 21]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     However, the detailed design of SAV-specific information
     communication mechanism for dealing with route changes is outside the
     scope of this document.

  7.2.  General Information Communication Mechanism

     The general information communication mechanism is used for
     communicating routing information between ASes, obtaining RPKI ROA
     objects and ASPA objects from RPKI cache servers, and obtaining the
     information about ASes and their prefixes from IRR databases.  The
     general communication mechanism can be implemented by using existing
     protocols for collecting the relative information, such as BGP, RTR
     [RFC8210], and FTP [RFC959].

  7.3.  Management Information Communication Mechanism

     The primary purpose of the management information communication
     mechanism is to deliver manual configurations of network operators.
     Examples of the management configurations include, but are not
     limited to:

     *  SAVNET configurations using YANG, CLI, RTBH, or Flowspec: Inter-
        domain SAVNET implementations on vendor devices need to accept the
        configurations from operators, such as the SAV rules directly
        configured by operators, and may support various tools to do this,
        such as YANG, CLI, RTBH, or Flowspec.

     *  SAVNET performance analysis: Inter-domain SAVNET implementations
        need to support various operation methods to report the statistics
        of SAVNET, such as alarm and exception reporting, performance
        monitoring and reporting for the control plane and data plane,
        which are discussed in detail in Section 10.

     *  SAVNET deployment provisioning: Inter-domain SAVNET
        implementations may support the configurations which relate to its
        deployment process, such as maximum hardware resources used, "on-
        off" of SAVNET, and access authority.

     Note that the management information can be delivered at any time and
     requires reliable delivery for the management information
     communication mechanism implementation.  Additionally, to support
     performance analysis, the management information communication
     mechanism can carry telemetry information, such as metrics pertaining
     to forwarding performance, the count of spoofing packets and
     discarded packets, and the information regarding the prefixes
     associated with the spoofing traffic, as observed until the most
     recent time.




  Li, et al.                 Expires 7 May 2025                  [Page 22]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


  8.  Use Cases

     This section utilizes the sample use cases to showcase that the
     inter-domain SAVNET architecture can improve the validation accuracy
     in the scenarios of limited propagation of prefixes, hidden prefixes,
     reflection attacks, and direct attacks, compared to existing SAV
     mechanisms, which are also utilized for the gap analysis of existing
     inter-domain SAV mechanisms in [inter-domain-ps].  In the following,
     these use cases are discussed for SAV at customer interfaces and SAV
     at provider/peer interfaces, respectively.

  8.1.  SAV at Customer Interfaces

     In order to prevent the source address spoofing, operators can enable
     ACL-based ingress filtering, source-based RTBH filtering, and/or
     uRPF-based mechanisms at customer interfaces, namely Strict uRPF, FP-
     uRPF, VRF uRPF, or EFP-uRPF [manrs] [nist].  However, as analyzed in
     [inter-domain-ps], uRPF-based mechanisms may lead to false positives
     in two inter-domain scenarios: limited propagation of prefixes and
     hidden prefixes, or may lead to false negatives in the scenarios of
     source address spoofing attacks within a customer cone, while ACL-
     based ingress filtering and source-based RTBH filtering need to
     update SAV rules in a timely manner and lead to high operational
     overhead.  The following showcases that the inter-domain SAVNET
     architecture can avoid false positives and false negatives in these
     scenarios.

  8.1.1.  Limited Propagation of Prefixes























  Li, et al.                 Expires 7 May 2025                  [Page 23]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


                             +----------------+
                             |    AS 3(P3)    |
                             +-+/\-----+/\+/\++
                                /        \  \
                      P3[AS 3] /          \  \ P3[AS 3]
                              /            \  \
                             / (C2P)        \  \
                    +----------------+       \  \
                    |    AS 4(P4)    |        \  \
                    ++/\+/\+/\+/\+/\++         \  \
                      /  /  |  |    \           \  \
            P2[AS 2] /  /   |  |     \           \  \
                    /  /    |  |      \           \  \
                   /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                  /  /      |  |        \           \  \
                 /  /(C2P)  |  |         \           \  \
     +----------------+     |  |          \           \  \
     |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
     +--------+/\+----+     |  | P6[AS 1]   \           \  \
                \           |  | NO_EXPORT   \           \  \
        P1[AS 1] \          |  |              \           \  \
        NO_EXPORT \         |  |               \           \  \
                   \ (C2P)  |  | (C2P/P2P) (C2P)\     (C2P) \  \
                +----------------+              +----------------+
                |  AS 1(P1, P6)  |              |    AS 5(P5)    |
                +----------------+              +----------------+

         Figure 9: Limited propagation of prefixes caused by NO_EXPORT.

     Figure 9 presents a scenario where the limited propagation of
     prefixes occurs due to the NO_EXPORT community attribute.  In this
     scenario, AS 1 is a customer of AS 2, AS 2 is a customer of AS 4, AS
     4 is a customer of AS 3, and AS 5 is a customer of both AS 3 and AS
     4.  The relationship between AS 1 and AS 4 can be either customer-to-
     provider (C2P) or peer-to-peer (P2P).  AS 1 advertises prefixes P1 to
     AS 2 and adds the NO_EXPORT community attribute to the BGP
     advertisement sent to AS 2, preventing AS 2 from further propagating
     the route for prefix P1 to AS 4.  Similarly, AS 1 adds the NO_EXPORT
     community attribute to the BGP advertisement sent to AS 4, resulting
     in AS 4 not propagating the route for prefix P6 to AS 3.
     Consequently, AS 4 only learns the route for prefix P1 from AS 1 in
     this scenario.  Suppose AS 1 and AS 4 have deployed inter-domain SAV
     while other ASes have not, and AS 4 has deployed EFP-uRPF at its
     customer interfaces.

     In this scenario, existing uRPF-based SAV mechanisms would block the
     traffic with P1 as source addresses improperly, and thus suffer from
     the problem of false positives [inter-domain-ps].  If the inter-



  Li, et al.                 Expires 7 May 2025                  [Page 24]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     domain SAVNET architecture is deployed, AS 1 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P1 as source addresses can arrive at the interfaces facing AS 1
     and AS 2.  As a result, the false positive problem can be avoided.

  8.1.2.  Hidden Prefixes

                                  +----------------+
                  Anycast Server+-+    AS 3(P3)    |
                                  +-+/\-----+/\+/\++
                                     /        \  \
                           P3[AS 3] /          \  \ P3[AS 3]
                                   /            \  \
                                  / (C2P)        \  \
                          +----------------+      \  \
                          |    AS 4(P4)    |       \  \
                          ++/\+/\+/\+/\+/\++        \  \
             P6[AS 1, AS 2] /  /  |  |   \           \  \
                  P2[AS 2] /  /   |  |    \           \  \
                          /  /    |  |     \           \  \
                         /  /     |  |      \ P5[AS 5]  \  \ P5[AS 5]
                        /  /      |  |       \           \  \
                       /  /(C2P)  |  |        \           \  \
           +----------------+     |  |         \           \  \
     User+-+    AS 2(P2)    |     |  | P1[AS 1] \           \  \
           +--------+/\+----+     |  | P6[AS 1]  \           \  \
             P6[AS 1] \           |  | NO_EXPORT  \           \  \
              P1[AS 1] \          |  |             \           \  \
              NO_EXPORT \         |  |              \           \  \
                         \ (C2P)  |  | (C2P)   (C2P) \     (C2P) \  \
                      +----------------+            +----------------+
         Edge Server+-+  AS 1(P1, P6)  |            |    AS 5(P5)    |
                      +----------------+            +----------------+
     P3 is the anycast prefix and is only advertised by AS 3 through BGP.

               Figure 10: A Direct Server Return (DSR) scenario.

     Figure 10 illustrates a direct server return (DSR) scenario where the
     anycast IP prefix P3 is only advertised by AS 3 through BGP.  In this
     example, AS 3 is the provider of AS 4 and AS 5, AS 4 is the provider
     of AS 1, AS 2, and AS 5, and AS 2 is the provider of AS 1.  AS 1 and
     AS 4 have deployed inter-domain SAV, while other ASes have not.  When
     users in AS 2 send requests to the anycast destination IP, the
     forwarding path is AS 2->AS 4->AS 3.  The anycast servers in AS 3
     receive the requests and tunnel them to the edge servers in AS 1.
     Finally, the edge servers send the content to the users with source
     addresses in prefix P3.  The reverse forwarding path is AS 1->AS
     4->AS 2.



  Li, et al.                 Expires 7 May 2025                  [Page 25]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     In this scenario, existing uRPF-based mechanisms will improperly
     block the legitimate response packets from AS 1 at the customer
     interface of AS 4 facing AS 1 [inter-domain-ps].  In contrast, if the
     inter-domain SAVNET architecture is deployed, AS 1 can communicate
     the SAV-specific information to AS 4 and AS 4 will be aware that the
     traffic with P3 as source addresses can arrive at the interfaces
     facing AS 1 and AS 3.  As a result, the legitimate response packets
     with P3 as source addresses from AS 1 can be allowed and the false
     positive problem can be avoided.

  8.1.3.  Reflection Attacks

                                     +----------------+
                                     |    AS 3(P3)    |
                                     +-+/\-----+/\+/\++
                                           /     \  \
                                          /       \  \
                                         /         \  \
                                        / (C2P)     \  \
                               +----------------+    \  \
                               |    AS 4(P4)    |     \  \
                               ++/\+/\+/\+/\+/\++      \  \
                  P6[AS 1, AS 2] /  /  |  |    \        \  \
                       P2[AS 2] /  /   |  |     \        \  \
                               /  /    |  |      \        \  \
                              /  /     |  |       \P5[AS 5]\  \ P5[AS 5]
                             /  /      |  |        \        \  \
                            /  /(C2P)  |  |         \        \  \
                +----------------+     |  |          \        \  \
  Attacker(P1')-+    AS 2(P2)    |     |  | P1[AS 1]  \        \  \
                +--------+/\+----+     |  | P6[AS 1]   \        \  \
                  P6[AS 1] \           |  | NO_EXPORT   \        \  \
                   P1[AS 1] \          |  |              \        \  \
                   NO_EXPORT \         |  |               \        \  \
                              \ (C2P)  |  | (C2P) (C2P)    \  (C2P) \  \
                           +----------------+           +----------------+
                   Victim+-+  AS 1(P1, P6)  |   Server+-+    AS 5(P5)    |
                           +----------------+           +----------------+
  P1' is the spoofed source prefix P1 by the attacker which is inside of
  AS 2 or connected to AS 2 through other ASes.

      Figure 11: A scenario of reflection attacks by source address
                     spoofing within a customer cone.

     Figure 11 depicts the scenario of reflection attacks by source
     address spoofing within a customer cone.  The reflection attack by
     source address spoofing takes place within AS 4's customer cone,
     where the attacker spoofs the victim's IP address (P1) and sends



  Li, et al.                 Expires 7 May 2025                  [Page 26]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     requests to servers' IP address (P5) that are designed to respond to
     such requests.  As a result, the server sends overwhelming responses
     back to the victim, thereby exhausting its network resources.  The
     arrows in Figure 11 illustrate the commercial relationships between
     ASes.  AS 3 serves as the provider for AS 4 and AS 5, while AS 4 acts
     as the provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 1 and AS 4 have deployed inter-domain
     SAV, while the other ASes have not.

     In this scenario, EFP-uRPF with algorithm A/B will improperly permit
     the spoofing attacks originating from AS 2 [inter-domain-ps].  If the
     inter-domain SAVNET architecture is deployed, AS 1 can communicate
     the SAV-specific information to AS 4 and AS 4 will be aware that the
     traffic with P1 as source addresses can only arrive at the interface
     facing AS 1.  Therefore, at the interface of AS 4 facing AS 2, the
     spoofing traffic can be blocked.

  8.1.4.  Direct Attacks

                                     +----------------+
                                     |    AS 3(P3)    |
                                     +-+/\-----+/\+/\++
                                        |        \  \
                                        |         \  \
                                        |          \  \
                                        | (C2P)     \  \
                               +----------------+    \  \
                               |    AS 4(P4)    |     \  \
                               ++/\+/\+/\+/\+/\++      \  \
                  P6[AS 1, AS 2] /  /  |  |   \         \  \
                       P2[AS 2] /  /   |  |    \         \  \
                               /  /    |  |     \         \  \
                              /  /     |  |      \P5[AS 5] \  \ P5[AS 5]
                             /  /      |  |       \         \  \
                            /  /(C2P)  |  |        \         \  \
                +----------------+     |  |         \         \  \
  Attacker(P5')-+    AS 2(P2)    |     |  | P1[AS 1] \         \  \
                +--------+/\+----+     |  | P6[AS 1]  \         \  \
                  P6[AS 1] \           |  | NO_EXPORT  \         \  \
                   P1[AS 1] \          |  |             \         \  \
                   NO_EXPORT \         |  |              \         \  \
                              \ (C2P)  |  | (C2P)   (C2P) \   (C2P) \  \
                           +----------------+           +----------------+
                   Victim+-+  AS 1(P1, P6)  |           |    AS 5(P5)    |
                           +----------------+           +----------------+
  P1' is the spoofed source prefix P1 by the attacker which is inside of
  AS 2 or connected to AS 2 through other ASes.




  Li, et al.                 Expires 7 May 2025                  [Page 27]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


      Figure 12: A scenario of the direct attacks by source address
                     spoofing within a customer cone.

     Figure 12 portrays a scenario of direct attacks by source address
     spoofing within a customer cone and is used to analyze the gaps of
     uRPF-based mechanisms below.  The direct attack by source address
     spoofing takes place within AS 4's customer cone, where the attacker
     spoofs a source address (P5) and directly targets the victim's IP
     address (P1), overwhelming its network resources.  The arrows in
     Figure 12 illustrate the commercial relationships between ASes.  AS 3
     serves as the provider for AS 4 and AS 5, while AS 4 acts as the
     provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 4 and AS 5 have deployed inter-domain
     SAV, while the other ASes have not.

     In this scenario, EFP-uRPF with algorithm A/B will improperly permit
     the spoofing attacks [inter-domain-ps].  If the inter-domain SAVNET
     architecture is deployed, AS 5 can communicate the SAV-specific
     information to AS 4 and AS 4 will be aware that the traffic with P5
     as source addresses can arrive at the interface facing AS 3 and AS 5.
     Therefore, at the interface of AS 4 facing AS 2, the spoofing traffic
     can be blocked.

  8.2.  SAV at Provider/Peer Interfaces

     In order to prevent packets with spoofed source addresses from the
     provider/peer AS, ACL-based ingress filtering, Loose uRPF, and/or
     source-based RTBH filtering can be deployed [nist]. [inter-domain-ps]
     exposes the limitations of ACL-based ingress filtering, source-based
     RTBH filtering, and Loose uRPF for SAV at provider/peer interfaces in
     scenarios of source address spoofing attacks from provider/peer AS.
     The source address spoofing attacks from provider/peer AS include
     reflection attacks from provider/peer AS and direct attacks from
     provider/peer AS.  The following showcases that the inter-domain
     SAVNET architecture can avoid false negatives in these scenarios.

  8.2.1.  Reflection Attacks














  Li, et al.                 Expires 7 May 2025                  [Page 28]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


                                   +----------------+
                    Attacker(P1')+-+    AS 3(P3)    |
                                   +-+/\-----+/\+/\++
                                      /        \  \
                                     /          \  \
                                    /            \  \
                                   / (C2P/P2P)    \  \
                           +----------------+      \  \
                           |    AS 4(P4)    |       \  \
                           ++/\+/\+/\+/\+/\++        \  \
              P6[AS 1, AS 2] /  /  |  |    \          \  \
                   P2[AS 2] /  /   |  |     \          \  \
                           /  /    |  |      \          \  \
                          /  /     |  |       \ P5[AS 5] \  \ P5[AS 5]
                         /  /      |  |        \          \  \
                        /  /(C2P)  |  |         \          \  \
            +----------------+     |  |          \          \  \
    Server+-+    AS 2(P2)    |     |  | P1[AS 1]  \          \  \
            +--------+/\+----+     |  | P6[AS 1]   \          \  \
              P6[AS 1] \           |  | NO_EXPORT   \          \  \
               P1[AS 1] \          |  |              \          \  \
               NO_EXPORT \         |  |               \          \  \
                          \ (C2P)  |  | (C2P)    (C2P) \    (C2P) \  \
                       +----------------+             +----------------+
               Victim+-+  AS 1(P1, P6)  |             |    AS 5(P5)    |
                       +----------------+             +----------------+
    P1' is the spoofed source prefix P1 by the attacker which is inside of
    AS 3 or connected to AS 3 through other ASes.

        Figure 13: A scenario of reflection attacks by source address
                       spoofing from provider/peer AS.

     Figure 13 depicts the scenario of reflection attacks by source
     address spoofing from provider/peer AS.  In this case, the attacker
     spoofs the victim's IP address (P1) and sends requests to servers' IP
     address (P2) that respond to such requests.  The servers then send
     overwhelming responses back to the victim, exhausting its network
     resources.  The arrows in Figure 13 represent the commercial
     relationships between ASes.  AS 3 acts as the provider or lateral
     peer of AS 4 and the provider for AS 5, while AS 4 serves as the
     provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 1 and AS 4 have deployed inter-domain
     SAV, while the other ASes have not.

     Both ACL-based ingress filtering and source-based RTBH filtering will
     induce additional operational overhead, and Loose uRPF may improperly
     permit spoofed packets [inter-domain-ps].  If the inter-domain SAVNET
     architecture is deployed, AS 1 can communicate the SAV-specific



  Li, et al.                 Expires 7 May 2025                  [Page 29]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     information to AS 4 and AS 4 will be aware that the traffic with P1
     as source addresses can arrive at the interface facing AS 1 and AS 2.
     Therefore, at the interface of AS 4 facing AS 3, the spoofing traffic
     can be blocked.

  8.2.2.  Direct Attacks

                            +----------------+
             Attacker(P2')+-+    AS 3(P3)    |
                            +-+/\-----+/\+/\++
                               /        \  \
                              /          \  \
                             /            \  \
                            / (C2P/P2P)    \  \
                   +----------------+       \  \
                   |    AS 4(P4)    |        \  \
                   ++/\+/\+/\+/\+/\++         \  \
      P6[AS 1, AS 2] /  /  |  |    \           \  \
           P2[AS 2] /  /   |  |     \           \  \
                   /  /    |  |      \           \  \
                  /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                 /  /      |  |        \           \  \
                /  /(C2P)  |  |         \           \  \
    +----------------+     |  |          \           \  \
    |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
    +--------+/\+----+     |  | P6[AS 1]   \           \  \
      P6[AS 1] \           |  | NO_EXPORT   \           \  \
       P1[AS 1] \          |  |              \           \  \
       NO_EXPORT \         |  |               \           \  \
                  \ (C2P)  |  | (C2P)    (C2P) \     (C2P) \  \
               +----------------+              +----------------+
       Victim+-+  AS 1(P1, P6)  |              |    AS 5(P5)    |
               +----------------+              +----------------+
    P2' is the spoofed source prefix P2 by the attacker which is inside of
    AS 3 or connected to AS 3 through other ASes.

          Figure 14: A scenario of direct attacks by source address
                       spoofing from provider/peer AS.

     Figure 14 showcases a scenario of direct attack by source address
     spoofing from provider/peer AS.  In this case, the attacker spoofs
     another source address (P2) and directly targets the victim's IP
     address (P1), overwhelming its network resources.  The arrows in
     Figure 14 represent the commercial relationships between ASes.  AS 3
     acts as the provider or lateral peer of AS 4 and the provider for AS
     5, while AS 4 serves as the provider for AS 1, AS 2, and AS 5.
     Additionally, AS 2 is the provider for AS 1.  Suppose AS 1 and AS 4
     have deployed inter-domain SAV, while the other ASes have not.



  Li, et al.                 Expires 7 May 2025                  [Page 30]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Also, in this scenario, both ACL-based ingress filtering and source-
     based RTBH filtering will induce additional operational overhead, and
     Loose uRPF may improperly permit spoofed packets [inter-domain-ps].
     If the inter-domain SAVNET architecture is deployed, AS 2 can
     communicate the SAV-specific information to AS 4 and AS 4 will be
     aware that the traffic with P2 as source addresses can only arrive at
     the interface facing AS 2.  Therefore, at the interface of AS 4
     facing AS 3, the spoofing traffic can be blocked.

  9.  Meeting the Design Requirements of Inter-domain SAVNET

     The inter-domain SAVNET architecture proposes the guidelines for the
     design of new inter-domain SAV mechanisms to meet the requirments
     defined in [inter-domain-ps].  The followings illustrate the design
     guidelines to meet the requirements one by one.

  9.1.  Improving Validation Accuracy over Existing Mechanisms

     As analyzed in Section 8, existing uRPF-based SAV mechanisms may have
     improper block or improper permit problems in the scenarios of
     limited propagation of prefixes, hidden prefixes, reflection attacks,
     and direct attacks for SAV at customer interfaces, and the scenarios
     of reflection attacks and direct attacks for SAV at provider/peer
     interfaces.

     Inter-domain SAVNET proposes SAV-specific information, which consists
     of the source prefixes of ASes and their corresponding legitimate
     incoming direction to enter other ASes.  ASes which deploy SAVNET
     agent can communicate SAV-specific information with each other and
     generate accurate SAV rules for the prefixes from the SAV-specific
     information.  The use cases shown in Section 8 has demonstrated
     inter-domain SAVNET can improve validation accuracy compared to
     existing SAV mechanisms.  Along with more ASes deploy SAVNET agent
     and communicate SAV-specific information with each other, accurate
     SAV rules can be generated for these ASes and their prefixes can
     obtain better protection.

  9.2.  Working in Incremental/Partial Deployment

     A new inter-domain SAVNET mechanism should consider incremental/
     partial deployment as it is not feasible to deploy SAVNET agent
     simultaneously in all ASes, due to various constraints, such as
     device capabilities, versions, or vendors.

     Inter-domain SAVNET can support incremental/partial deployment, as it
     is not mandatory for all ASes to deploy SAVNET agents for
     communicating SAV-specific information.  ASes which deploy SAVNET
     agents can establish a logical neighboring relationship with other



  Li, et al.                 Expires 7 May 2025                  [Page 31]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     ASes.  The connections for communicating SAV-specific information can
     be achieved by manual configurations set by operators or an automatic
     neighbor discovery mechanism.  An automatic neighbor discovery
     mechanism can utilize existing protocols or tools to collect the
     SAVNET neighboring information.  This flexibility enables the inter-
     domain SAVNET to accommodate varying degrees of deployment, promoting
     interoperability and collaboration among participating ASes.  During
     the partial/incremental deployment of SAVNET agent, the SAV-specific
     information for the ASes which do not deploy SAVNET agent cannot be
     obtained.  To protect the prefixes of these ASes, inter-domain SAVNET
     can use the general information in the SIB to generate SAV rules.
     When using the general information, inter-domain SAVNET needs to
     guarantee the SAV accuracy for the corresponding application
     scenarios.  The use cases in Section 8 demonstrates that inter-domain
     SAVNET supports incremental/partial deployment.

     As more ASes adopt the inter-domain SAVNET, the "deployed area"
     expands, thereby increasing the collective defense capability against
     source address spoofing.  Furthermore, if multiple "deployed areas"
     can be logically interconnected across "non-deployed areas", these
     interconnected "deployed areas" can form a logical alliance,
     providing enhanced protection against address spoofing.  Especially,
     along with more ASes deploy SAVNET agent and support the
     communication of SAV-specific information, the generated SAV rules
     will become more accurate, as well as enhancing the protection
     capability against source address spoofing.

     In addition, releasing the SAV functions of the inter-domain SAVNET
     incrementally is RECOMMENDED as one potential way to reduce the
     deployment risks and can be considered in its deployment by network
     operators:

     *  First, the inter-domain SAVNET can only do the measurement in the
        data plane and do not take any other actions.  Based on the
        measurement data, the operators can evaluate the effect of the
        inter-domain SAVNET on the legitimate traffic, including
        validation accuracy and forwarding performance, as well as the
        operational overhead.

     *  Second, the inter-domain SAVNET can open the function to limit the
        rate of the traffic that is justified as spoofing traffic.  The
        operators can further evaluate the effect of the inter-domain
        SAVNET on the legitimate traffic and spoofing traffic, such as
        limiting the rate of all the spoofing traffic without hurting the
        legitimate traffic.






  Li, et al.                 Expires 7 May 2025                  [Page 32]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     *  Third, when the validation accuracy, forwarding performance, and
        operational overhead have been verified on a large scale by the
        live network, the inter-domain SAVNET can open the function to
        directly block the spoofing traffic that is justified by the SAV
        table in the data plane.

  9.3.  Reducing Operational Overhead

     The inter-domain routes or the prefixes of ASes usually change
     dynamically, which requires the SAV rules to be updated
     acutomatically.  ACL-based ingress filtering and source-based RTBH
     filtering requires manual configuration to update SAV rules to adapt
     to the routing or prefix changes, which leads to high operational
     overhead.

     Inter-domain SAVNET proposes the SAV-specific information
     communication mechanism and utilizes it to communicate SAV-specific
     information automatically between ASes which deploy SAVNET agent.
     Upon receiving the SAV-specific information, SAVNET agent will use it
     to generate SAV rules.  The use cases displayed in Section 8.2 show
     that inter-domain SAVNET reduces operational overhead compared to
     ACL-based ingress filtering and source-based RTBH filtering.

  9.4.  Guaranteeing Convergence

     Convergence issues SHOULD be carefully considered due to the dynamic
     nature of the Internet.  Internet routes undergo continuous changes,
     and SAV rules MUST proactively adapt to these changes, such as prefix
     and route changes, in order to avoid improper block and reduce
     improper permit.  To effectively track these changes, the SAVNET
     agent should proactively communicate the changes of SAV-specific
     information between ASes and generate SAV rules in a timely manner.

     The SAVNET agent should launch SAV-specific messages to adapt to the
     route or prefix changes in a timely manner.  During the routing
     convergence process, the traffic paths of the source prefixes can
     undergo rapid changes within a short period.  The changes of the SAV-
     specific information may not be communicated in time between ASes to
     update SAV rules, improper block or improper permit may happen.  Such
     inaccurate validation is caused by the delays in communicating SAV-
     specific information between ASes, which occur due to the factors
     like packet losses, unpredictable network latencies, or message
     processing latencies.  The detailed design of the SAV-specific
     information communication mechanism should consider these issues to
     reduce the inaccurate validation.






  Li, et al.                 Expires 7 May 2025                  [Page 33]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Besides, for the inter-domain SAVNET, the potential ways to deal with
     the inaccurate validation issues during the convergence of the SAV-
     specific information communication mechanism is to consider using the
     information from RPKI ROA objects and ASPA objects to generate SAV
     rules until the convergence process of the SAV-specific communication
     mechanism is finished, since these information is more stable and can
     help avoid improper block, and thus avoiding the impact to the
     legitimate traffic.

  9.5.  Providing Necessary Security Guarantee

     For inter-domain SAVNET, the SAVNET agent plays a crucial role in
     generating and disseminating SAV-specific messages across different
     ASes.  To safeguard against the potential risks posed by a malicious
     AS generating incorrect or forged SAV-specific messages, it is
     important for the SAVNET agents to employ security authentication
     measures for each received SAV-specific message.  The majour security
     threats faced by inter-domain SAVNET can be categorized into two
     aspects: session security and content security.  Session security
     pertains to verifying the identities of both parties involved in a
     session and ensuring the integrity of the session content.  Content
     security, on the other hand, focuses on verifying the authenticity
     and reliability of the session content, thereby enabling the
     identification of forged SAV-specific messages.

     The threats to session security include:

     *  Session identity impersonation: This occurs when a malicious
        router deceitfully poses as a legitimate peer router to establish
        a session with the targeted router.  By impersonating another
        router, the malicious entity can gain unauthorized access and
        potentially manipulate or disrupt the communication between the
        legitimate routers.

     *  Session integrity destruction: In this scenario, a malicious
        intermediate router situated between two peering routers
        intentionally tampers with or destroys the content of the relayed
        SAV-specific message.  By interfering with the integrity of the
        session content, the attacker can disrupt the reliable
        transmission of information, potentially leading to
        miscommunication or inaccurate SAV-related data being propagated.

     The threats to content security include:

     *  Message alteration: A malicious router has the ability to
        manipulate or forge any portion of a SAV-specific message.  For
        example, the attacker may employ techniques such as using a
        spoofed Autonomous System Number (ASN) or modifying the AS path



  Li, et al.                 Expires 7 May 2025                  [Page 34]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


        information within the message.  By tampering with the content,
        the attacker can potentially introduce inaccuracies or deceive the
        receiving ASes, compromising the integrity and reliability of the
        SAV-related information.

     *  Message injection: A malicious router injects a seemingly
        "legitimate" SAV-specific message into the communication stream
        and directs it to the corresponding next-hop AS.  This type of
        attack can be likened to a replay attack, where the attacker
        attempts to retransmit previously captured or fabricated messages
        to manipulate the behavior or decisions of the receiving ASes.
        The injected message may contain malicious instructions or false
        information, leading to incorrect SAV rule generation or improper
        validation.

     *  Path deviation: A malicious router intentionally diverts a SAV-
        specific message to an incorrect next-hop AS, contrary to the
        expected path defined by the AS path.  By deviating from the
        intended routing path, the attacker can disrupt the proper
        dissemination of SAV-related information and introduce
        inconsistencies or conflicts in the validation process.  This can
        undermine the effectiveness and accuracy of source address
        validation within the inter-domain SAVNET architecture.

     Overall, inter-domain SAVNET shares similar security threats with BGP
     and can leverage existing BGP security mechanisms to enhance both
     session and content security.  Session security can be enhanced by
     employing session authentication mechanisms used in BGP.  Similarly,
     content security can benefit from the deployment of existing BGP
     security mechanisms like RPKI, BGPsec, and ASPA.  While these
     mechanisms can address content security threats, their widespread
     deployment is crucial.  Until then, it is necessary to develop an
     independent security mechanism specifically designed for inter-domain
     SAVNET.  One potential approach is for each source AS to calculate a
     digital signature for each AS path and include these digital
     signatures within the SAV-specific messages.  Upon receiving a SAV-
     specific message, the SAVNET agent can verify the digital signature
     to ascertain the message's authenticity.  Furthermore, it is worth
     noting that the SAV-specific information communication mechanism may
     need to operate over a network link that is currently under a source
     address spoofing attack.  As a result, it may experience severe
     packet loss and high latency due to the ongoing attack, and the
     implementation of the SAV-specific communication mechanism should
     ensure uninterrupted communication.  Detailed security designs and
     considerations will be addressed in a separate draft, ensuring the
     robust security of inter-domain SAVNET.





  Li, et al.                 Expires 7 May 2025                  [Page 35]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


  10.  Manageability Considerations

     It is crucial to consider the operations and management aspects of
     SAV information sources, the SAV-specific communication mechanism,
     SIB, SIM, and SAV table in the inter-domain SAVNET architecture.  The
     following guidelines should be followed for their effective
     management:

     First, management interoperability should be supported across devices
     from different vendors or different releases of the same product,
     based on a unified data model such as YANG [RFC6020].  This is
     essential because the Internet comprises devices from various vendors
     and different product releases that coexist simultaneously.

     Second, scalable operation and management methods such as NETCONF
     [RFC6241] and syslog protocol [RFC5424] should be supported.  This is
     important as an AS may have hundreds or thousands of border routers
     that require efficient operation and management.

     Third, management operations, including default initial
     configuration, alarm and exception reporting, logging, performance
     monitoring and reporting for the control plane and data plane, as
     well as debugging, should be designed and implemented in the
     protocols or protocol extensions.  These operations can be performed
     either locally or remotely, based on the operational requirements.

     By adhering to these rules, the management of SAV information sources
     and related components can be effectively carried out, ensuring
     interoperability, scalability, and efficient operations and
     management of the inter-domain SAVNET architecture.

  11.  Privacy Considerations

     TBD

  12.  IANA Considerations

     This document has no IANA requirements.

  13.  Scope and Assumptions

     In this architecture, the choice of protocols used for communication
     between the SIM and different SAV information sources is not limited.
     The inter-domain SAVNET architecture presents considerations on how
     to consolidate SAV-related information from various sources to
     generate SAV rules and perform SAV using the SAV table in the
     dataplane.  The detailed design and implementation for SAV rule
     generation and SAV execution depend on the specific inter-domain SAV



  Li, et al.                 Expires 7 May 2025                  [Page 36]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     mechanisms employed.

     This document does not cover administrative or business agreements
     that may be established between the involved inter-domain SAVNET
     parties.  These considerations are beyond the scope of this document.
     However, it is assumed that authentication and authorization
     mechanisms can be implemented to ensure that only authorized ASes can
     communicate SAV-related information.

     This document makes the following assumptions:

     *  All ASes where the inter-domain SAVNET is deployed are assumed to
        provide the necessary connectivity between SAVNET agent and any
        intermediate network elements.  However, the architecture does not
        impose any specific limitations on the form or nature of this
        connectivity.

     *  Congestion and resource exhaustion can occur at various points in
        the inter-domain networks.  Hence, in general, network conditions
        should be assumed to be hostile.  The inter-domain SAVNET
        architecture must be capable of functioning reliably under all
        circumstances, including scenarios where the paths for delivering
        SAV-related information are severely impaired.  It is crucial to
        design the inter-domain SAVNET system with a high level of
        resilience, particularly under extremely hostile network
        conditions.  The architecture should ensure uninterrupted
        communication between inter-domain SAVNET agents, even when data-
        plane traffic saturates the link.

     *  The inter-domain SAVNET architecture does not impose rigid
        requirements for the SAV information sources that can be used to
        generate SAV rules.  Similarly, it does not dictate strict rules
        on how to utilize the SAV-related information from diverse sources
        or perform SAV in the dataplane.  Network operators have the
        flexibility to choose their approaches to generate SAV rules and
        perform SAV based on their specific requirements and preferences.
        Operators can either follow the recommendations outlined in the
        inter-domain SAVNET architecture or manually specify the rules for
        governing the use of SAV-related information, the generation of
        SAV rules, and the execution of SAV in the dataplane.

     *  The inter-domain SAVNET architecture does not impose restrictions
        on the selection of the local AS with which AS to communicate SAV-
        specific Information.  The ASes have the flexibility to establish
        connections for SAV-specific communication based on the manual
        configurations set by operators or other automatic mechanisms.





  Li, et al.                 Expires 7 May 2025                  [Page 37]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     *  The inter-domain SAVNET architecture provides the flexibility to
        accommodate Quality-of-Service (QoS) policy agreements between
        SAVNET-enabled ASes or local QoS prioritization measures, but it
        does not make assumptions about their presence.  These agreements
        or prioritization efforts are aimed at ensuring the reliable
        delivery of SAV-specific Information between SAVNET agents.  It is
        important to note that QoS is considered as an operational
        consideration rather than a functional component of the inter-
        domain SAVNET architecture.

     *  The SAVNET communication mechanisms are loosely coupled and are
        used for communicating or gathering SAV-related information, and
        how the inter-domain SAVNET synchronizes the management and
        operation configurations is out of scope of this document.

  14.  Contributors

     Mingqing Huang
     Zhongguancun Laboratory
     Beijing
     China
     Email: huangmq@mail.zgclab.edu.cn

     Igor Lubashev
     Akamai Technologies
     145 Broadway
     Cambridge, MA, 02142
     United States of America
     Email: ilubashe@akamai.com

     Many thanks to Mingqing Huang and Igor Lubashev for the significantly
     helpful discussions and revision suggestions.

  15.  References

  15.1.  Normative References

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

     [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
                Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
                2004, <https://www.rfc-editor.org/rfc/rfc3704>.







  Li, et al.                 Expires 7 May 2025                  [Page 38]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
                Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
                RFC 8704, DOI 10.17487/RFC8704, February 2020,
                <https://www.rfc-editor.org/rfc/rfc8704>.

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/rfc/rfc6020>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6241>.

     [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
                DOI 10.17487/RFC5424, March 2009,
                <https://www.rfc-editor.org/rfc/rfc5424>.

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

  15.2.  Informative References

     [inter-domain-ps]
                "Source Address Validation in Inter-domain Networks Gap
                Analysis, Problem Statement, and Requirements", 2024,
                <https://datatracker.ietf.org/doc/draft-ietf-savnet-inter-
                domain-problem-statement/>.

     [intra-domain-arch]
                "Intra-domain Source Address Validation (SAVNET)
                Architecture", 2024, <https://datatracker.ietf.org/doc/
                draft-ietf-savnet-intra-domain-architecture/>.

     [RFC5635]  Kumari, W. and D. McPherson, "Remote Triggered Black Hole
                Filtering with Unicast Reverse Path Forwarding (uRPF)",
                RFC 5635, DOI 10.17487/RFC5635, August 2009,
                <https://www.rfc-editor.org/rfc/rfc5635>.

     [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
                Bacher, "Dissemination of Flow Specification Rules",
                RFC 8955, DOI 10.17487/RFC8955, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8955>.





  Li, et al.                 Expires 7 May 2025                  [Page 39]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
                Infrastructure (RPKI) to Router Protocol, Version 1",
                RFC 8210, DOI 10.17487/RFC8210, September 2017,
                <https://www.rfc-editor.org/rfc/rfc8210>.

     [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
                STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
                <https://www.rfc-editor.org/rfc/rfc959>.

     [manrs]    MANRS, "MANRS Implementation Guide", 2023,
                <https://www.manrs.org/netops/guide/antispoofing/>.

     [nist]     NIST, "Resilient Interdomain Traffic Exchange: BGP
                Security and DDos Mitigation", 2019,
                <https://www.nist.gov/publications/resilient-interdomain-
                traffic-exchange-bgp-security-and-ddos-mitigation>.

     [rpki-time-of-flight]
                ISOC, "RPKI Time-of-Flight&#58; Tracking Delays in the
                Management, Control, and Data Planes", n.d.,
                <https://dl.acm.org/doi/10.1007/978-3-031-28486-1_18>.

     [sav-table]
                "General Source Address Validation Capabilities", 2023,
                <https://datatracker.ietf.org/doc/draft-huang-savnet-sav-
                table/>.

  Acknowledgements

     Many thanks to Alvaro Retana, Kotikalapudi Sriram, Rüdiger Volk,
     Xueyan Song, Ben Maddison, Jared Mauch, Joel Halpern, Aijun Wang,
     Jeffrey Haas, Xiangqing Chang, Changwang Lin, Mingxing Liu, Zhen Tan,
     Yuanyuan Zhang, Yangyang Wang, Antoin Verschuren, Olaf Struck, Siyuan
     Teng, Gert Doering etc. for their valuable comments on this document.

  Authors' Addresses

     Dan Li
     Tsinghua University
     Beijing
     China
     Email: tolidan@tsinghua.edu.cn


     Li Chen
     Zhongguancun Laboratory
     Beijing
     China



  Li, et al.                 Expires 7 May 2025                  [Page 40]


  Internet-Draft      Inter-domain SAVNET Architecture       November 2024


     Email: lichen@zgclab.edu.cn


     Nan Geng
     Huawei
     Beijing
     China
     Email: gengnan@huawei.com


     Libin Liu
     Zhongguancun Laboratory
     Beijing
     China
     Email: liulb@zgclab.edu.cn


     Lancheng Qin
     Zhongguancun Laboratory
     Beijing
     China
     Email: qinlc@mail.zgclab.edu.cn





























  Li, et al.                 Expires 7 May 2025                  [Page 41]


