# drafts

name: draft-ietf-anima-brski-prm
rev: 23
title: BRSKI with Pledge in Responder Mode (BRSKI-PRM)
time: 2025-06-07T14:05:30Z
group: anima
group_uri: /api/v1/group/group/1956/
expires: 2025-12-05T15:40:46Z
ad: /api/v1/person/person/107859/
shepherd: /api/v1/person/email/ietf@kovatsch.net/
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.109204+00:00
source: ietf
abstract:
  This document defines enhancements to Bootstrapping Remote Secure Key
     Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
     Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
     devices, referred to as pledges, into a domain where direct
     communication with the registrar is either limited or not possible at
     all.  To facilitate interaction between a pledge and a domain
     registrar the registrar-agent is introduced as new component.  The
     registrar-agent supports the reversal of the interaction model from a
     pledge-initiated mode, to a pledge-responding mode, where the pledge
     is in a server role.  To establish the trust relation between pledge
     and registrar, BRSKI-PRM relies on object security rather than
     transport security.  This approach is agnostic to enrollment
     protocols that connect a domain registrar to a key infrastructure
     (e.g., domain Certification Authority).

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/12/", "/api/v1/doc/state/44/"]

full_text:
  ANIMA WG                                                        S. Fries
  Internet-Draft                                                 T. Werner
  Intended status: Standards Track                                 Siemens
  Expires: 5 December 2025                                         E. Lear
                                                             Cisco Systems
                                                             M. Richardson
                                                  Sandelman Software Works
                                                               3 June 2025


              BRSKI with Pledge in Responder Mode (BRSKI-PRM)
                       draft-ietf-anima-brski-prm-23

  Abstract

     This document defines enhancements to Bootstrapping Remote Secure Key
     Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
     Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
     devices, referred to as pledges, into a domain where direct
     communication with the registrar is either limited or not possible at
     all.  To facilitate interaction between a pledge and a domain
     registrar the registrar-agent is introduced as new component.  The
     registrar-agent supports the reversal of the interaction model from a
     pledge-initiated mode, to a pledge-responding mode, where the pledge
     is in a server role.  To establish the trust relation between pledge
     and registrar, BRSKI-PRM relies on object security rather than
     transport security.  This approach is agnostic to enrollment
     protocols that connect a domain registrar to a key infrastructure
     (e.g., domain Certification Authority).

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/.

     Source for this draft and an issue tracker can be found at
     https://github.com/anima-wg/anima-brski-prm.

  Status of This Memo

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







  Fries, et al.            Expires 5 December 2025                [Page 1]


  Internet-Draft                  BRSKI-PRM                      June 2025


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

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 5 December 2025.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Scope of Solution . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.  Supported Environments and Use Case Examples  . . . . . .   8
         3.1.1.  Building Automation . . . . . . . . . . . . . . . . .   9
         3.1.2.  Infrastructure Isolation Policy . . . . . . . . . . .   9
         3.1.3.  Less Operational Security in the Target-Domain  . . .  10
       3.2.  Potential Limitations . . . . . . . . . . . . . . . . . .  10
     4.  Requirements Discussion and Mapping to BRSKI-PRM Functional
             Elements  . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  TLS support required  . . . . . . . . . . . . . . . . . .  12
     5.  Solution Architecture . . . . . . . . . . . . . . . . . . . .  12
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  Nomadic Connectivity  . . . . . . . . . . . . . . . . . .  16
       5.3.  Co-located Registrar-Agent and Domain Registrar . . . . .  18
       5.4.  Agent Proximity Assertion . . . . . . . . . . . . . . . .  19
     6.  System Components . . . . . . . . . . . . . . . . . . . . . .  20
       6.1.  Registrar-Agent . . . . . . . . . . . . . . . . . . . . .  20
         6.1.1.  Discovery of the Registrar  . . . . . . . . . . . . .  22
         6.1.2.  Discovery of the Pledge . . . . . . . . . . . . . . .  22



  Fries, et al.            Expires 5 December 2025                [Page 2]


  Internet-Draft                  BRSKI-PRM                      June 2025


       6.2.  Pledge in Responder Mode  . . . . . . . . . . . . . . . .  24
         6.2.1.  Pledge with Combined Functionality  . . . . . . . . .  25
         6.2.2.  Pledgestatus "reason-context" Values  . . . . . . . .  25
         6.2.3.  Voucher Status and Enroll Status Telemetry
                 "reason-context" Values . . . . . . . . . . . . . . .  26
       6.3.  Domain Registrar  . . . . . . . . . . . . . . . . . . . .  27
         6.3.1.  Domain Registrar with Combined Functionality  . . . .  28
       6.4.  MASA  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
     7.  Exchanges and Artifacts . . . . . . . . . . . . . . . . . . .  29
       7.1.  Trigger Pledge Voucher-Request  . . . . . . . . . . . . .  33
         7.1.1.  Request Artifact: Pledge Voucher-Request Trigger
                 (tPVR)  . . . . . . . . . . . . . . . . . . . . . . .  35
         7.1.2.  Response Artifact: Pledge Voucher-Request (PVR) . . .  37
       7.2.  Trigger Pledge Enroll-Request . . . . . . . . . . . . . .  39
         7.2.1.  Request Artifact: Pledge Enroll-Request Trigger
                 (tPER)  . . . . . . . . . . . . . . . . . . . . . . .  41
         7.2.2.  Response Artifact: Pledge Enroll-Request (PER)  . . .  42
       7.3.  Supply PVR to Registrar (including MASA interaction)  . .  44
         7.3.1.  MASA Interaction  . . . . . . . . . . . . . . . . . .  47
         7.3.2.  Supply Voucher to Registrar-Agent . . . . . . . . . .  49
         7.3.3.  Request Artifact: Pledge Voucher-Request (PVR)  . . .  49
         7.3.4.  Backend Request Artifact: Registrar Voucher-Request
                 (RVR) . . . . . . . . . . . . . . . . . . . . . . . .  50
         7.3.5.  Backend Response Artifact: Voucher  . . . . . . . . .  52
         7.3.6.  Response Artifact: Registrar-Countersigned Voucher  .  52
       7.4.  Supply PER to Registrar (including Key Infrastructure
              interaction; requestenroll)  . . . . . . . . . . . . . .  54
         7.4.1.  Request Artifact: Pledge Enroll-Request (PER) . . . .  57
         7.4.2.  Response Artifact: Registrar Enroll-Response
                 (Enroll-Resp) . . . . . . . . . . . . . . . . . . . .  57
       7.5.  Obtain CA Certificates (wrappedcacerts) . . . . . . . . .  57
         7.5.1.  Request (no artifact) . . . . . . . . . . . . . . . .  58
         7.5.2.  Response Artifact: CA-Certificates (caCerts)  . . . .  58
       7.6.  Supply Voucher to Pledge (svr)  . . . . . . . . . . . . .  61
         7.6.1.  Request Artifact: Registrar-Countersigned Voucher . .  63
         7.6.2.  Response Artifact: Voucher Status (vStatus) . . . . .  63
       7.7.  Supply CA Certificates to Pledge (scac) . . . . . . . . .  66
         7.7.1.  Request Artifact: CA-Certificates (caCerts) . . . . .  67
         7.7.2.  Response (no artifact)  . . . . . . . . . . . . . . .  67
       7.8.  Supply Enroll-Response to Pledge (ser)  . . . . . . . . .  68
         7.8.1.  Request Artifact: Enroll-Response (Enroll-Resp) . . .  69
         7.8.2.  Response Artifact: Enroll Status (eStatus)  . . . . .  69
       7.9.  Voucher Status Telemetry (including MASA interaction) . .  71
         7.9.1.  Request Artifact: Voucher Status (vStatus)  . . . . .  73
         7.9.2.  Response (no artifact)  . . . . . . . . . . . . . . .  73
       7.10. Enroll Status Telemetry . . . . . . . . . . . . . . . . .  73
         7.10.1.  Request Artifact: Enroll Status (eStatus)  . . . . .  74
         7.10.2.  Response (no artifact) . . . . . . . . . . . . . . .  74



  Fries, et al.            Expires 5 December 2025                [Page 3]


  Internet-Draft                  BRSKI-PRM                      June 2025


       7.11. Query Pledge Status (qps) . . . . . . . . . . . . . . . .  75
         7.11.1.  Request Artifact: Status Trigger (tStatus) . . . . .  76
         7.11.2.  Response Artifact: Pledge Status (pStatus) . . . . .  79
     8.  Logging Considerations  . . . . . . . . . . . . . . . . . . .  83
     9.  Operational Considerations  . . . . . . . . . . . . . . . . .  85
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  86
       10.1.  BRSKI Well-Known URIs  . . . . . . . . . . . . . . . . .  86
       10.2.  Service Name and Transport Protocol Port Number
              Registry . . . . . . . . . . . . . . . . . . . . . . . .  87
     11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  87
       11.1.  Registrar-Agent identity Privacy Considerations  . . . .  88
       11.2.  Registar-Agent/Pledge communications . . . . . . . . . .  88
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  89
       12.1.  Denial of Service (DoS) Attack on Pledge . . . . . . . .  90
       12.2.  Misuse of acquired PVR and PER by Registrar-Agent  . . .  90
       12.3.  Misuse of Registrar-Agent  . . . . . . . . . . . . . . .  91
       12.4.  Misuse of DNS-SD with mDNS to obtain list of pledges . .  91
       12.5.  YANG Module Security Considerations  . . . . . . . . . .  92
     13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  92
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  92
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  92
       14.2.  Informative References . . . . . . . . . . . . . . . . .  94
     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  98
       A.1.  Example Pledge Voucher-Request (PVR) - from Pledge to
             Registrar-Agent . . . . . . . . . . . . . . . . . . . . .  98
       A.2.  Example Registrar Voucher-Request (RVR) - from Registrar to
             MASA  . . . . . . . . . . . . . . . . . . . . . . . . . .  99
       A.3.  Example Voucher - from MASA to Pledge, via Registrar and
             Registrar-Agent . . . . . . . . . . . . . . . . . . . . . 102
       A.4.  Example Voucher, MASA issued Voucher with additional
             Registrar signature (from MASA to Pledge, via Registrar and
             Registrar-Agent)  . . . . . . . . . . . . . . . . . . . . 103
     Appendix B.  HTTP-over-TLS operations between Registrar-Agent and
             Pledge  . . . . . . . . . . . . . . . . . . . . . . . . . 105
     Appendix C.  History of Changes "RFC Editor: please delete" . . . 106
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 122
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 123

  1.  Introduction

     BRSKI as defined in [RFC8995] specifies a solution for secure zero-
     touch (automated) bootstrapping of devices (pledges) in a customer
     domain, which may be associated with a specific installation
     location.  This includes the discovery of the BRSKI registrar in the
     customer domain and the exchange of security information necessary to
     establish trust between a pledge and the domain.





  Fries, et al.            Expires 5 December 2025                [Page 4]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Security information pertaining to the customer domain, specifically,
     the customer domain certificate, is exchanged and authenticated
     through the use of signed data objects, namely the voucher artifacts,
     as defined in [I-D.ietf-anima-rfc8366bis].  In response to a voucher-
     request, the Manufacturer Authorized Signing Authority (MASA) issues
     the voucher and provides it via the domain registrar to the pledge.
     [I-D.ietf-anima-rfc8366bis] specifies the format of the voucher
     artifacts, including the voucher-request artifact.

     For the certificate enrollment of devices, BRSKI relies on Enrollment
     over Secure Transport (EST, [RFC7030]) to request and distribute
     customer domain specific device certificates.  EST in turn relies for
     the authentication and authorization of the certification request on
     the credentials used by the underlying TLS between the EST client and
     an EST server.

     BRSKI addresses scenarios in which a pledge initiates the
     bootstrapping acting as client (referred to as initiator mode by this
     document).  BRSKI with Pledge in Responder Mode (BRSKI-PRM) defined
     in this document allows the pledge to act as server, so that it can
     be triggered externally and at a specific time to generate
     bootstrapping requests in the customer domain.  For this approach,
     this document:

     *  defines additional endpoints for the domain registrar and new
        endpoints for the pledge to enable responder mode.

     *  introduces the Registrar-Agent as new component to facilitate the
        communication between the pledge and a domain registrar.  The
        Registrar-Agent may be implemented as an integrated functionality
        of a commissioning tool or be co-located with the domain registrar
        itself.  BRSKI-PRM supports the identification of the Registrar-
        Agent that was performing the bootstrapping allowing for
        accountability of the pledges installation, when the Registrar-
        Agent is a component used by an installer and not co-located with
        the domain registrar.

     *  specifies additional artifacts for the exchanges between a pledge
        acting as server, the Registrar-Agent acting as client, and the
        domain registrar acting as server toward the Registrar-Agent.

     *  allows the application of Registrar-Agent credentials to establish
        TLS connections to a domain registrar; these are different from
        the pledge IDevID credentials.

     *  also enables the usage of alternative transports, both IP-based
        and non-IP (e.g., Bluetooth-based or NFC-based communication),
        between the pledge and the domain registrar via the Registrar-



  Fries, et al.            Expires 5 December 2025                [Page 5]


  Internet-Draft                  BRSKI-PRM                      June 2025


        Agent; security is addressed at the application layer through
        object security with an additional signature wrapping the
        exchanged artifacts.

     The term endpoint used in the context of this document is equivalent
     to resource in HTTP [RFC9110] and CoAP [RFC7252]; it is not used to
     describe a device.  Endpoints are accessible via Well-Known URIs
     [RFC8615].

     To utilize EST [RFC7030] for enrollment, the domain registrar
     performs pre-processing of the wrapping signature before actually
     using EST as defined in [RFC7030].

     There may be pledges that can support both modes, initiator and
     responder mode.  In these cases, BRSKI-PRM can be combined with BRSKI
     as defined in [RFC8995] or BRSKI-AE [RFC9733] to allow for more
     bootstrapping flexibility.  Providing information about capabilities
     of BRSKI components like the pledge or registrar is handled as part
     of the discovery.  BRSKI-PRM relies only on a minimum necessary set
     of capabilities for the interaction and leaves the definition of more
     advanced mechanisms allowing to signal specific capabilities to
     [I-D.ietf-anima-brski-discovery].

  2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document makes use of the terms defined in Section 1.2 of
     [RFC8995].  The following terms are defined in addition:

     authenticated self-contained object:  Describes a data object, which
        is cryptographically bound to an end entity (EE) certificate.  The
        binding is assumed to be provided through a digital signature of
        the actual object using the corresponding private key of the
        certificate.

     CA:  Certification Authority.  An entity, which issues certificates
        and maintains certificate revocation information.

     CMS:  Cryptographic Message Syntax, as defined in [RFC5652].

     Commissioning tool:  Tool to interact with devices to provide
        configuration data.




  Fries, et al.            Expires 5 December 2025                [Page 6]


  Internet-Draft                  BRSKI-PRM                      June 2025


     CSR:  Certificate Signing Request, as defined in [RFC2986].

     Domain registrar:  An entity in the customer domain, which
        facilitates the interaction of a pledge or Registrar-Agent with a
        manufacturer service (MASA).  It operates as BRSKI-EST server for
        the pledge when requesting vouchers and certificates and acts as
        the client BRSKI-MASA client when requesting vouchers from the
        MASA.  This component was introduced in [RFC8995].

     Drop ship:  delivery of a component or product.  This component was
        introduced in [RFC8995].

     EE:  End entity, as defined in [RFC9483].  Typically, a device or
        service that owns a public-private key pair for which it manages a
        public key certificate.

     EE certificate:  the certificate of the EE signed by its owner (e.g.,
        CA).  For domain components, the EE certificate is signed by the
        domain owner.  For the pledge, the EE certificate is either the
        IDevID certificate signed by the manufacturer or the LDevID
        certificate signed by the domain owner or an application-specific
        EE certificate signed by the domain owner.

     endpoint:  Term equivalent to resource in HTTP [RFC9110].  Endpoints
        are accessible via Well-Known URIs [RFC8615].

     IDevID:  An Initial Device Identifier X.509 certificate installed by
        the vendor on new equipment.  This is a term from 802.1AR
        [IEEE-802.1AR].

     LDevID:  A Local Device Identifier X.509 certificate installed by the
        owner of the equipment.  This is a term from 802.1AR
        [IEEE-802.1AR].

     mTLS:  mutual Transport Layer Security, refers to mutual
        authenticated TLS as specified in [RFC8446].

     PER:  Pledge Enroll-Request is a signature-wrapped CSR, signed by the
        pledge that requests enrollment to a domain via the Registrar-
        Agent.

     POI:  Proof-of-Identity, as defined in [RFC5272].

     POP:  Proof-of-Possession (of a private key), as defined in
        [RFC5272].

     PVR:  Pledge Voucher-Request is a signature-wrapped voucher-request,




  Fries, et al.            Expires 5 December 2025                [Page 7]


  Internet-Draft                  BRSKI-PRM                      June 2025


        signed by the pledge that sends it to the domain registrar via the
        Registrar-Agent.

     RA:  Registration Authority, an optional system component to which a
        CA delegates certificate management functions such as
        authorization checks.  In BRSKI-PRM, this is a functionality of
        the domain registrar, as in BRSKI [RFC8995].

     Registrar-Agent:  Component facilitating the data exchange between a
        pledge in responder mode and a domain registrar.

     RVR:  Registrar Voucher-Request is a signature-wrapped voucher-
        request, signed by the domain registrar that sends it to the MASA.
        For BRSKI-PRM, it contains a copy of the original PVR received
        from the pledge.

     This document uses the following encoding notations in the given JWS-
     signed artifact examples:

     BASE64(OCTETS):  Denotes the base64 encoding of an octet sequence
        using the character set defined in Section 4 of [RFC4648] and
        without the inclusion of any line breaks, whitespace, or other
        additional characters.  Note that the base64 encoding of the empty
        octet sequence is the empty string.

     BASE64URL(OCTETS):  Denotes the base64url encoding of an octet
        sequence, per Section 2 of [RFC7515].

     UTF8(STRING):  Denotes the octet sequence of the UTF-8 [RFC3629]
        representation of STRING, per Section 1 of [RFC7515].

     This document includes many examples that would contain many long
     sequences of base64-encoded objects with no content directly
     comprehensible to a human reader.  In order to keep those examples
     short, they use the token base64encodedvalue== as a placeholder for
     base64 data.  The full base64 data is included in the appendices of
     this document.  Note, base64-encoded values are mainly used for
     fields related to certificates like: x5bag, x5c, agent-provided-
     proximity-registrar-cert, p10-csr

  3.  Scope of Solution

  3.1.  Supported Environments and Use Case Examples

     BRSKI-PRM is applicable to scenarios where pledges may have no direct
     connection to a domain registrar, may have no continuous connection,
     or require coordination of the pledge requests to be provided to a
     domain registrar.



  Fries, et al.            Expires 5 December 2025                [Page 8]


  Internet-Draft                  BRSKI-PRM                      June 2025


     This can be motivated by pledges deployed in environments not yet
     connected to the operational customer domain network, e.g., at a
     building construction site, or environments intentionally
     disconnected from the Internet, e.g., critical industrial facilities.
     Another example is the assembly of electrical cabinets, which are
     prepared in advance before the installation at a customer domain.

  3.1.1.  Building Automation

     In building automation, a typical use case exists where a detached
     building or the basement is equipped with sensors, actuators, and
     controllers, but with only limited or no connection to the central
     building management system.  This limited connectivity may exist
     during installation time or also during operation time.

     During the installation, for instance, a service technician collects
     the device-specific information from the basement network and
     provides them to the central building management system.  This could
     be done using a laptop, common mobile device, or dedicated
     commissioning tool to transport the information.  The service
     technician may successively collect device-specific information in
     different parts of the building before connecting to the domain
     registrar for bulk bootstrapping.

     A domain registrar may be part of the central building management
     system and already be operational in the installation network.  The
     central building management system can then provide operational
     parameters for the specific devices in the basement or other detached
     areas.  These operational parameters may comprise values and settings
     required in the operational phase of the sensors/actuators, among
     them a certificate issued by the operator to authenticate against
     other components and services.  These operational parameters are then
     provided to the devices in the basement facilitated by the service
     technician's laptop.  The Registrar-Agent, defined in this document,
     may be run on the technician's laptop to interact with pledges.

  3.1.2.  Infrastructure Isolation Policy

     This refers to any case in which the network infrastructure is
     normally isolated from the Internet as a matter of policy, most
     likely for security reasons.  In such a case, limited access to a
     domain registrar may be allowed in carefully controlled short periods
     of time, for example when a batch of new devices are deployed, but
     prohibited at other times.







  Fries, et al.            Expires 5 December 2025                [Page 9]


  Internet-Draft                  BRSKI-PRM                      June 2025


  3.1.3.  Less Operational Security in the Target-Domain

     The registration authority (RA) performing the authorization of a
     certificate request is a critical PKI component and therefore
     requires higher operational security than other components utilizing
     the issued certificates.  CAs may also require higher security in the
     registration procedures.  There may be situations in which the
     customer domain does not offer enough physical security to operate an
     RA/CA and therefore this service is transferred to a backend that
     offers a higher level of operational security.

  3.2.  Potential Limitations

     The mechanism described in this document presumes the ability of the
     pledge and the Registrar-Agent to communicate with one another.  This
     may not be possible in constrained environments where, in particular,
     power must be conserved.  In these situations, it is anticipated that
     the transceiver will be powered down most of the time.  This presents
     a rendezvous problem: the pledge is unavailable for certain periods
     of time, and the Registrar-Agent is similarly presumed to be
     unavailable for certain periods of time.  To overcome this situation,
     the pledges may need to be powered on, either manually or by sending
     a trigger signal.

  4.  Requirements Discussion and Mapping to BRSKI-PRM Functional Elements

     Based on the intended target environment described in Section 3.1,
     the following boundary conditions are derived to support
     bootstrapping of pledges in responder mode (acting as server):

     *  To facilitate the communication between a pledge in responder mode
        and a registrar, additional functionality is needed either on the
        registrar or as a stand-alone component.  This new functionality
        is defined as Registrar-Agent and acts as an agent of the
        registrar to trigger the pledge to generate requests for voucher
        and enrollment.  These requests are then provided by the
        Registrar-Agent to the registrar.  This requires the definition of
        pledge endpoints to allow interaction with the Registrar-Agent.

     *  The security of communication between the Registrar-Agent and the
        pledge does not rely on Transport Layer Security (TLS) to enable
        application of BRSKI-PRM in environments, in which the
        communication between the Registrar-Agent and the pledge is done
        over other technologies like Bluetooth Low Energy (BLE) or NFC,
        which may not support TLS protected communication.  In addition,
        the pledge does not have a certificate that can easily be verified
        by [RFC9525] methods.




  Fries, et al.            Expires 5 December 2025               [Page 10]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  The use of authenticated self-contained objects addresses both,
        the TLS connection establishment challenges and the technology
        stack challenge.  Note that the chosen approach does not provide
        confidentiality for the self-contained object, which can be
        provided by employing TLS.

     *  By contrast, the Registrar-Agent can be authenticated by the
        registrar as a component, acting on behalf of the registrar.  In
        addition, the registrar must be able to verify, which Registrar-
        Agent was in direct contact with the pledge.

     *  It would be inaccurate for the voucher-request and voucher-
        response to use the assertion type proximity in the voucher, as
        the pledge was not in direct contact with the registrar for
        bootstrapping.  Therefore, a new assertion type is necessary for
        distinguishing assertions the MASA can state.

     At least the following properties are required for the voucher and
     enrollment processing:

     *  POI: provides data-origin authentication of an artifact, e.g., a
        voucher-request or an Enroll-Request, utilizing an existing
        IDevID.  Certificate updates may utilize the certificate that is
        to be updated.

     *  POP: proves that an entity possesses and controls the private key
        corresponding to the public key contained in the certification
        request, typically by adding a signature computed using the
        private key to the certification request.

     Solution examples based on existing technology are provided with the
     focus on existing IETF RFCs:

     *  Voucher-Requests and Vouchers as used in [RFC8995] already provide
        both, POP and POI, through a digital signature to protect the
        integrity of the voucher, while the corresponding signing
        certificate contains the identity of the signer.

     *  Enroll-Requests are data structures containing the information
        from a requester for a CA to create a certificate.  The
        certification request format in BRSKI is PKCS#10 [RFC2986].  In
        PKCS#10, the structure is signed to ensure integrity protection
        and POP of the private key of the requester that corresponds to
        the contained public key.  In the application examples, this POP
        alone is not sufficient.  A POI is also required for the
        certification request and therefore the certification request
        needs to be additionally bound to the existing pledge IDevID
        credential.  This binding supports the authorization decision for



  Fries, et al.            Expires 5 December 2025               [Page 11]


  Internet-Draft                  BRSKI-PRM                      June 2025


        the certification request and may be provided directly with the
        certification request.  While BRSKI uses the binding to TLS,
        BRSKI-PRM aims at an additional signature of the PKCS#10 using
        existing credentials on the pledge (IDevID).  This allows the
        process to be independent of the selected transport.

  4.1.  TLS support required

     As already stated in [RFC8995], and required by
     [I-D.ietf-uta-require-tls13], the use of TLS 1.3 (or newer) is
     encouraged.  TLS 1.2 or newer is REQUIRED on the Registrar-Agent
     side.  TLS 1.3 (or newer) SHOULD be available on the registrar, but
     TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be available on the
     MASA, but TLS 1.2 MAY be used.

     [I-D.ietf-uta-require-tls13] allows for continued use of TLS 1.2 for
     operational reasons.  [RFC8995] specified TLS 1.2 was the minimum,
     consistent with [RFC8996].  [RFC8995] requires mutual TLS, and many
     frameworks, embedded SDKs and hardware load balancers did not, at the
     time of writing, have APIs that permitted mutual TLS to be done
     consistently across TLS 1.2 and TLS 1.3.  While TLS 1.3 is common in
     browsers, the use of mutual TLS with 1.3 is uncommon in browsers, and
     so working support for mutual TLS in frameworks is also uncommon.

     On the Registrar and MASA side, mutual TLS authentication combined
     with hardware TLS offload requires specific support for extensions
     such as [RFC9440] or an equivalent.  TLS 1.2 and TLS 1.3 do client
     authentication at a different point in the state machine, and not all
     frameworks support both at the time of this writing.

     Many security certification schemes, such as FIPS-140, do not certify
     source code, but rather the resulting binary executable.  Even while
     TLS 1.3 source code is available, and new software can be added to
     existing platforms, replacing the TLS libraries on many embedded
     systems requires that the SDK vendor recertify the platform first.
     In industrial settings, these platforms have long lifecycles, and it
     takes some time to recertify all platforms.

     Thus, [RFC8995] and this document can not turn off TLS 1.2 until all
     parts of the ecosystem can run TLS 1.3.  That does not stop any of
     the parts of this ecosystem from deploying TLS 1.3 when possible, and
     for each part of the two or three transactions from negotiating TLS
     1.3 in preference to TLS 1.2.

  5.  Solution Architecture






  Fries, et al.            Expires 5 December 2025               [Page 12]


  Internet-Draft                  BRSKI-PRM                      June 2025


  5.1.  Overview

     For BRSKI-PRM, the base system architecture defined in BRSKI
     [RFC8995] is enhanced to facilitate new use cases in which the pledge
     acts as server.  The responder mode allows delegated bootstrapping
     using a Registrar-Agent instead of a direct connection between the
     pledge and the domain registrar.

     Necessary enhancements to support authenticated self-contained
     objects for certificate enrollment are kept at a minimum to enable
     reuse of already defined architecture elements and interactions.  The
     format of the bootstrapping objects produced or consumed by the
     pledge is usually based on JSON Web Signature (JWS) [RFC7515] and
     further specified in Section 7 to address the requirements stated in
     Section 4.  In constrained environments, it may be based on COSE
     [RFC9052].

     An abstract overview of the BRSKI-PRM protocol can be found on slide
     8 of [BRSKI-PRM-abstract].

     To support mutual trust establishment between the domain registrar
     and pledges not directly connected to the customer domain, this
     document specifies the exchange of authenticated self-contained
     objects with the help of the Registrar-Agent.

     This leads to extensions of the logical components in the BRSKI
     architecture as shown in Figure 1.

     Note that the Join Proxy is not shown in the figure.  In certain
     situations the Join Proxy may still be present and could be used by
     the Registrar-Agent to connect to the Registrar.  For example, a
     Registrar-Agent application on a smartphone often can connect to
     local Wi-Fi without giving up their cellular network connection
     [androidnsd], but only can make link-local connections.

     The Registrar-Agent interacts with the pledge to transfer the
     required data objects for bootstrapping, which are then also
     exchanged between the Registrar-Agent and the domain registrar.  The
     addition of the Registrar-Agent influences the sequences of the data
     exchange between the pledge and the domain registrar described in
     [RFC8995].  To enable reuse of BRSKI defined functionality as much as
     possible, BRSKI-PRM:

     *  uses existing endpoints where the required functionality is
        provided.

     *  enhances existing endpoints with new supported media types, e.g.,
        for JWS voucher.



  Fries, et al.            Expires 5 December 2025               [Page 13]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  defines new endpoints where additional functionality is required,
        e.g., for wrapped certification request, wrapped CA certificates,
        and new status information.

                                    +---------------------------+
               ..... Drop Ship .....| Vendor Services           |
               :                    +---------------+-----------+
               :                    | M anufacturer |           |
               :                    | A uthorized   | Ownership |
               :                    | S igning      | Tracker   |
               :                    | A uthority    |           |
               :                    +---------------+-----------+
               :                                         ^
               :                                         | BRSKI-
               :                                         | MASA
               :          ...............................|.........
               V          .                              v        .
           +--------+     .  +------------+        +-----------+  .
           |        |     .  |            |        |           |  .
           | Pledge | BRSKI- | Registrar- | BRSKI- | Domain    |  .
           |        |  PRM   | Agent      |  PRM   | Registrar |  .
           |        |<------>|            |<------>|           |  .
           |        |     .  |   EE cert. |        |  EE cert. |  .
           |        |     .  +------------+        +-----+-----+  .
           | IDevID |     .                              |        .
           |        |     .           +------------------+-----+  .
           +--------+     .           | Key Infrastructure     |  .
                          .           | (e.g., PKI CA)         |  .
                          .           +------------------------+  .
                          .........................................
                                       Customer Domain

        Figure 1: BRSKI-PRM architecture overview using Registrar-Agent

     Figure 1 shows the relations between the following main components:

     *  Pledge: Is expected to respond with the necessary data objects for
        bootstrapping to a Registrar-Agent.  The protocol used between the
        pledge and the Registrar-Agent is assumed to be HTTP(S) in the
        context of this document.  Any other protocol can be used as long
        as it supports the exchange of the necessary artifacts.  This
        includes CoAP or protocols to be used over Bluetooth or NFC
        connections.  A pledge acting as server leads to the following
        differences compared to BRSKI [RFC8995]:

        -  The pledge no longer initiates bootstrapping, but is discovered
           and triggered by a Registrar-Agent as defined in Section 6.1.2.




  Fries, et al.            Expires 5 December 2025               [Page 14]


  Internet-Draft                  BRSKI-PRM                      June 2025


        -  The pledge offers additional endpoints as defined in
           Section 6.2, so that a Registrar-Agent can request data
           required for bootstrapping the pledge.

        -  The pledge includes additional data in the PVR, which is
           provided and signed by a Registrar-Agent as defined in
           Section 7.1.  This allows the registrar to identify with which
           Registrar-Agent the pledge was in contact (see Section 5.4).

        -  The artifacts exchanged between the pledge and the registrar
           via the Registrar-Agent are authenticated self-contained
           objects (i.e., signature-wrapped artifacts).

     *  Registrar-Agent: Is a new component defined in Section 6.1 that
        provides a store and forward communication path to exchange data
        objects between the pledge and a domain registrar.  This is for
        situations in which a domain registrar is not directly reachable
        by the pledge, which may be due to a different technology stacks
        or due to missing connectivity.  A Registrar-Agent acting as
        client leads to the following new aspects:

        -  The order of exchanges in the BRSKI-PRM call flow is different
           from that in BRSKI [RFC8995], as the Registrar-Agent can
           trigger one or more pledges and collects the PVR and PER
           artifacts simultaneously as defined in Section 7.  This enables
           bulk bootstrapping of several devices.

        -  There is no trust assumption between the pledge and the
           Registrar-Agent as only authenticated self-contained objects
           are used, which are transported via the Registrar-Agent and
           provided either by the pledge or the domain registrar.

        -  The trust assumption between the Registrar-Agent and the domain
           registrar may be based on EE certificates that are both signed
           by the domain owner.

        -  The Registrar-Agent may be realized as stand-alone component
           supporting nomadic activities of a service technician moving
           between different installation sites.

        -  Alternatively, the Registrar-Agent may also be realized as co-
           located functionality for a registrar, to support pledges in
           responder mode.

     *  Join Proxy (not shown): Has the same functionality as described in
        [RFC8995] if needed.  Note that a Registrar-Agent may use a join
        proxy to facilitate the TLS connection to the registrar in the
        same way that a BRSKI pledge would use a join proxy.  This is



  Fries, et al.            Expires 5 December 2025               [Page 15]


  Internet-Draft                  BRSKI-PRM                      June 2025


        useful in cases where the Registrar-Agent does not have full IP
        connectivity via the domain network or cases where it has no other
        means to locate the registrar on the network.

     *  Domain registrar: In general fulfills the same functionality
        regarding the bootstrapping of the pledge in a customer domain by
        facilitating the communication of the pledge with the MASA service
        and the domain key infrastructure (PKI).  However, there are also
        differences compared to BRSKI [RFC8995]:

        -  A BRSKI-PRM domain registrar does not interact with a pledge
           directly, but through the Registrar-Agent as defined in
           Section 7.

        -  A BRSKI-PRM domain registrar offers additional endpoints as
           defined in Section 6.3 to support the signature-wrapped
           artifacts used by BRSKI-PRM.

     *  Vendor services: Encompass MASA and Ownership Tracker and are used
        as defined in [RFC8995].  A MASA responsible for pledges that
        implement BRSKI-PRM is expected to support BRSKI-PRM extensions:

        -  The default format for voucher artifacts (including voucher-
           request) is JWS-signed JSON as defined in
           [I-D.ietf-anima-jws-voucher].

        -  The Agent Proximity Assertion (see Section 5.4) requires
           additional validation steps as defined in Section 7.3.1.

  5.2.  Nomadic Connectivity

     In one example instance of the PRM architecture as shown in Figure 2,
     there is no connectivity between the location in which the pledge is
     installed and the location of the domain registrar.  This is often
     the case in the building automation use case mentioned in
     Section 3.1.1.















  Fries, et al.            Expires 5 December 2025               [Page 16]


  Internet-Draft                  BRSKI-PRM                      June 2025


                                    +---------------------------+
               ..... Drop Ship .....| Vendor Services           |
               :                    +---------------------------+
               :                                          ^
           ........................................       |
           .   v                                  .       |
           . +--------+           .-.-.-.-.-.-.-. .       |
           . |        | BRSKI-PRM : Registrar-  : .       |
           . | Pledge |<--------->: Agent       : .       |
           . +--------+ L2 or L3  :-.-.-.-.-.-.-: .       | BRSKI-
           .          connectivity   ^            .       | MASA
           ..........................!.............       |
              Pledge Installation    !                    |
              Location               ! Nomadic            |
                                     ! connectivity       |
                                     !                    |
                          ...........!....................|.........
                          .          v                    v        .
                          .  .-.-.-.-.-.-.-. BRSKI- +-----------+  .
                          .  : Registrar-  :  PRM   | Domain    |  .
                          .  : Agent       :<------>| Registrar |  .
                          .  :-.-.-.-.-.-.-:        +-----+-----+  .
                          .                               |        .
                          .           +-------------------+-----+  .
                          .           | Key Infrastructure      |  .
                          .           | (e.g., PKI CA)          |  .
                          .           +-------------------------+  .
                          ..........................................
                                       Customer Domain

             Figure 2: Registrar-Agent nomadic connectivity example

     BRSKI-PRM enables support of this case through nomadic connectivity
     of the Registrar-Agent.  To perform enrollment in this setup,
     multiple round trips of the Registrar-Agent between the pledge
     installation location and the domain registrar are required.

     1.  Connectivity to domain registrar: preparation tasks for pledge
         bootstrapping not part of the BRSKI-PRM protocol definition, like
         retrieval of list of pledges to enroll.

     2.  Connectivity to pledge installation location: retrieve
         information about available pledges (IDevID), collect request
         objects (i.e., Pledge Voucher-Requests and Pledge Enroll-Requests
         using the BRSKI-PRM approach described in Section 7.1 and
         Section 7.2).





  Fries, et al.            Expires 5 December 2025               [Page 17]


  Internet-Draft                  BRSKI-PRM                      June 2025


     3.  Connectivity to domain registrar, submit collected request
         information of pledges, retrieve response objects (i.e., Voucher
         and Enroll-Response) using the BRSKI-PRM approach described in
         Section 7.3 and Section 7.4.

     4.  Connectivity to pledge installation location, provide retrieved
         objects to the pledges to enroll pledges and collect status using
         the BRSKI-PRM approach described in Section 7.6, Section 7.7, and
         Section 7.8.

     5.  Connectivity to domain registrar, submit Voucher Status and
         Enrollment Status using the BRSKI-PRM approach described in
         Section 7.9 and Section 7.10.

     Variations of this setup include cases where the Registrar-Agent uses
     for example, WiFi to connect to the pledge installation network, and
     mobile network connectivity to connect to the domain registrar.  Both
     connections may also be possible in a single location at the same
     time, based on installation building conditions.

  5.3.  Co-located Registrar-Agent and Domain Registrar

     Compared to [RFC8995] BRSKI, pledges supporting BRSKI-PRM can be
     completely passive and only need to react when being requested to
     react by a Registrar-Agent.  In [RFC8995], pledges instead need to
     continuously interact with a domain registrar during onboarding,
     through discovery, voucher exchange, and enrollment.  This may
     increase the load on the domain registrar, specifically, if a larger
     number of pledges onboards simultaneously.






















  Fries, et al.            Expires 5 December 2025               [Page 18]


  Internet-Draft                  BRSKI-PRM                      June 2025


                                   +---------------------------+
              ..... Drop Ship .....| Vendor Service            |
              :                    +---------------------------+
              :                                         ^
              :                                         | BRSKI-MASA
              :          ...............................|.........
              :          .                              v        .
              v          .          +-------------------------+  .
           +--------+    . BRSKI-   |..............           |  .
           |        |    .  PRM     |. Registrar- . Domain    |  .
           | Pledge |<------------->|. Agent      . Registrar |  .
           +--------+ L2 or L3      |..............           |  .
                      connectivity  +-------------------+-----+  .
                         .                              |        .
                         .           +------------------+-----+  .
                         .           | Key Infrastructure     |  .
                         .           +------------------------+  .
                         .........................................
                                      Customer Domain

       Figure 3: Registrar-Agent integrated into Domain Registrar example

     The benefits of BRSKI-PRM can be achieved even without the
     operational complexity of stand-alone Registrar-Agents by integrating
     the necessary functionality of the Registrar-Agent as a module into
     the domain registrar as shown in Figure 3 so that it can support the
     BRSKI-PRM communications to the pledge.

  5.4.  Agent Proximity Assertion

     "Agent proximity" is a statement in the PVR and the voucher that the
     registrar communicates via a Registrar-Agent as defined in Section 7
     and not directly to the pledge.  It is therefore a different
     assertion than "network proximity", which is defined in Section 3 of
     [RFC8995].  Hence, [I-D.ietf-anima-rfc8366bis] defines the additional
     assertion type agent-proximity.  This assertion type can be verified
     by the registrar and MASA during BRSKI-PRM voucher-request
     processing.

     In BRSKI, the pledge verifies POP of the registrar end-entity (EE)
     credentials via the TLS handshake and pins that public key as the
     proximity-registrar-cert into the voucher request.  This allows the
     MASA to verify the proximity of the pledge and registrar,
     facilitating a decision to assign the pledge to that domain owner.
     In BRSKI, the TLS session is considered provisional until the pledge
     receives the voucher to verify POI.





  Fries, et al.            Expires 5 December 2025               [Page 19]


  Internet-Draft                  BRSKI-PRM                      June 2025


     In contrast, in BRSKI-PRM the pledge has no direct connection to the
     registrar and MUST accept the supplied registrar EE certificate
     provisionally until it receives the voucher as described in
     Section 7.6 to verify both POP and POI.  The provisional registrar EE
     certificate is used for the object security along the authenticated
     self-contained objects that in BRSKI-PRM replace the direct TLS
     connection to the registrar available in BRSKI [RFC8995].  See also
     Section 5 of [RFC8995] on "provisional state".

     For the Agent Proximity Assertion, the Registrar-Agent EE certificate
     and registrar EE certificate must be signed by the same domain owner,
     i.e., MUST possess a common domain trust anchor in their certificate
     chain.  Akin to the Network Proximity Assertion in BRSKI [RFC8995],
     the Agent Proximity Assertion provides pledge proximity evidence to
     the MASA.  But additionally, the Agent Proximity Assertion allows the
     domain registrar to be sure that the PVR supplied by the Registrar-
     Agent was in fact collected by the Registrar-Agent to which the
     registrar is connected by utilizing an agent-signed data object.

  6.  System Components

  6.1.  Registrar-Agent

     The Registrar-Agent uses its own EE certificate and corresponding
     credentials (i.e., private key) for TLS client authentication and for
     signing agent-signed data objects.

     The Registrar-Agent EE certificate MUST include a
     SubjectKeyIdentifier as defined in Section 4.2.1.2 of [RFC5280],
     which is used as a reference within agent-signed data objects as
     defined in Section 7.1.1.1.  Note that this is an additional
     requirement for issuing the Registrar-Agent EE certificate.
     [RFC8995] has a similar requirement for the registrar EE certificate.

     The SubjectKeyIdentifier is used in favor of providing the complete
     Registrar-Agent EE certificate in agent-signed data objects to
     accommodate also constrained environments and reduce bandwidth needed
     for communication with the pledge.  In addition, it follows the
     recommendation from BRSKI to use SubjectKeyIdentifier in favor of a
     certificate fingerprint to avoid additional computations.

     The provisioning of the Registrar-Agent EE certificate is out of
     scope for this document, but may be done using its own BRSKI run or
     by other means such as configuration.  It is RECOMMENDED to use
     short-lived Registrar-Agent EE certificates in the range of days or
     weeks.  This is to address the assumed nature of stand-alone
     Registrar-Agents as nomadic devices (see Section 5.2) and to avoid
     potential misuse as outlined in Section 12.3.



  Fries, et al.            Expires 5 December 2025               [Page 20]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Further, the Registrar-Agent requires the registrar EE certificate to
     provide it to the pledge.  It MAY use the certificate verified during
     server authentication within an initial TLS session with the
     registrar; in this case, the Registrar-Agent MUST possess the domain
     trust anchor (i.e., CA certificate) for the registrar EE certificate
     to verify the certificate chain.  Alternatively, the registrar EE
     certificate MAY be provided via configuration.  The registrar IP
     address or hostname is provided either by configuration or by using
     the discovery mechanism defined in [RFC8995] (see Section 6.1.1).

     In addition to the certificates, the Registrar-Agent is provided with
     the product-serial-number(s) of the pledge(s) to be bootstrapped.
     This is necessary to allow for the discovery of pledges by the
     Registrar-Agent using DNS-SD with mDNS (see Section 6.1.2).  The list
     may be provided by prior administrative means or the Registrar-Agent
     may get the information via an (out-of-band) interaction with the
     pledge.  For instance, [RFC9238] describes scanning of a QR code,
     where the product-serial-number would be initialized from the 12N
     B005 Product Serial Number data record.

     In summary, the following information MUST be available at the
     Registrar-Agent before the interaction with a pledge:

     *  Registrar-Agent EE certificate and corresponding private key: own
        operational credentials to authenticate and sign agent-signed data

     *  Registrar EE certificate: certificate of the domain registrar to
        be provided to the pledge

     *  Serial number(s): product-serial-number(s) of pledge(s) to be
        bootstrapped; used for discovery

     Further, the Registrar-Agent SHOULD have synchronized time.  In case
     the registrar-agent does not have synchronized time, it may not be
     able to verify the registrar EE certificate during the optional TLS
     handshake.  As the registrar-agent is recommended to utilize short-
     lived certificates in Section 12.3, a registrar-agent may use the
     valid from time of its short-lived certificate for time
     synchronization.

     Finally, the Registrar-Agent MAY possess the IDevID (root or issuing)
     CA certificate of the pledge manufacturer/vendor to validate the
     IDevID certificate on returned PVR or in case of optional TLS usage
     for pledge communication (see Appendix B).  The distribution of
     IDevID CA certificates to the Registrar-Agent is out of scope of this
     document and may be done by a manual configuration.





  Fries, et al.            Expires 5 December 2025               [Page 21]


  Internet-Draft                  BRSKI-PRM                      June 2025


  6.1.1.  Discovery of the Registrar

     While the Registrar-Agent requires an IP address of a domain
     registrar to initiate a TLS session, a separate discovery of the
     registrar is likely not needed and a configuration of the domain
     registrar IP address or hostname is assumed.  Registrar-Agent and
     registrar are domain components that already have a trust relation,
     as a Registrar-Agent acts as representative of the domain registrar
     towards the pledge or may even be collocated with the domain
     registrar.  Further, other communication (not part of this document)
     between the Registrar-Agent and the registrar is assumed, e.g., to
     exchange information about product-serial-number(s) of pledges to be
     discovered as outlined in Section 5.2.

     Moreover, the discovery described in Section 4 of [RFC8995] and
     Appendix A.2 of [RFC8995] does not support identification of
     registrars with an enhanced feature set (like the support of BRSKI-
     PRM), and hence that discovery is not applicable.

     As a more general solution, the BRSKI discovery mechanism can be
     extended to provide upfront information on the capabilities of
     registrars, such as the mode of operation (pledge-responder-mode or
     registrar-responder-mode).  Defining discovery extensions is out of
     scope of this document.  For further discussion, see
     [I-D.ietf-anima-brski-discovery].

  6.1.2.  Discovery of the Pledge

     The discovery of the pledge by the Registrar-Agent in the context of
     this document describes the minimum discovery approach that MUST be
     supported.  A more general discovery mechanism, also supporting GRASP
     besides DNS-SD with mDNS, is discussed in
     [I-D.ietf-anima-brski-discovery].

     Discovery in BRSKI-PRM uses DNS-based Service Discovery [RFC6763]
     over Multicast DNS [RFC6762] to discover the pledge.  Note that
     Section 9 of [RFC6762] provides support for conflict resolution in
     situations when a DNS-SD with mDNS responder receives an mDNS
     response with inconsistent data.  Note that [RFC8990] does not
     support conflict resolution of mDNS, which may be a limitation for
     its application.










  Fries, et al.            Expires 5 December 2025               [Page 22]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The pledge constructs a Service Instance Name based on device local
     information (manufacturer/vendor name and serial number), which
     results in <product-serial-number>._brski-pledge._tcp.local.  The
     product-serial-number composition is manufacturer-dependent and may
     contain information regarding the manufacturer, the product type, and
     further information specific to the product instance.  To allow
     distinction of pledges, the product-serial-number therefore needs to
     be sufficiently unique.

     Note that the service name definition is not fully inline with the
     naming recommendation of [RFC6763] due to the positioning of _tcp.
     However, the definition of the product-serial-number has to align
     with the allowed character set (see [RFC6763]) to avoid discovery
     problems.  This check is necessary as the product-serial-number is
     also contained in the certificate as X520SerialNumber, that has a
     larger allowed character set.  Using the product-serial-number as
     part of the service name allows to discover specific instances of a
     pledge.

     The _brski-pledge._tcp service, however, targets machine-to-machine
     discovery.

     For discovery the Registrar-Agent MUST use

     *  <product-serial-number>._brski-pledge._tcp.local, to discover a
        specific pledge, e.g., when connected to a local network

     *  _brski-pledge._tcp.local to get a list of pledges to be
        bootstrapped

     if it does not support a more general discovery such as defined in
     [I-D.ietf-anima-brski-discovery].

     When supporting different options for discovery, as outlined in
     [I-D.ietf-anima-brski-discovery], a manufacturer may support
     configuration of preferred options.

     A manufacturer may allow the pledge to react on DNS-SD with mDNS
     discovery without its product-serial-number contained.  This allows a
     commissioning tool to discover pledges to be bootstrapped in the
     domain.  The manufacturer supports this functionality as outlined in
     Section 12.4.

     Establishing network connectivity of the pledge is out of scope of
     this document but necessary to apply DNS-SD with mDNS.  For Ethernet,
     network connectivity can be provided, e.g., via a switch to an
     operational network or to a specific VLAN for bootstrapping,
     depending on an operators security policy.  For WiFi networks,



  Fries, et al.            Expires 5 December 2025               [Page 23]


  Internet-Draft                  BRSKI-PRM                      June 2025


     connectivity can be provided by using a pre-agreed SSID for
     bootstrapping, e.g., as proposed in [I-D.draft-ietf-emu-eap-arpa].
     The same approach can be used by 6LoWPAN/mesh using a pre-agreed PAN
     ID.  How to gain network connectivity is out of scope of this
     document.

  6.2.  Pledge in Responder Mode

     In BRSKI-PRM, the pledge is triggered by a Registrar-Agent to create
     the PVR and PER.  It is also triggered for processing of the
     responses and the generation of status information once the
     Registrar-Agent has received the responses from the registrar later
     in the process.

     To enable interaction as responder with a Registrar-Agent, pledges in
     responder mode MUST act as servers and MUST provide the endpoints
     "tpvr", "tper", "svr", "scac", and "ser" defined in Table 1 within
     the BRSKI-defined /.well-known/brski/ URI path.  The optional
     endpoint "qps" SHOULD be supported.  The endpoints are defined with
     short names to also accommodate for resource-constrained devices.

        +==========+========================+========================+
        | Endpoint | Operation              | Exchange and Artifacts |
        +==========+========================+========================+
        | tpvr     | Trigger Pledge         | Section 7.1            |
        |          | Voucher-Request        |                        |
        +----------+------------------------+------------------------+
        | tper     | Trigger Pledge Enroll- | Section 7.2            |
        |          | Request                |                        |
        +----------+------------------------+------------------------+
        | svr      | Supply Voucher to      | Section 7.6            |
        |          | Pledge                 |                        |
        +----------+------------------------+------------------------+
        | scac     | Supply CA Certificates | Section 7.7            |
        |          | to Pledge              |                        |
        +----------+------------------------+------------------------+
        | ser      | Supply Enroll-Response | Section 7.8            |
        |          | to Pledge              |                        |
        +----------+------------------------+------------------------+
        | qps      | Query Pledge Status    | Section 7.11           |
        +----------+------------------------+------------------------+

         Table 1: Well-Known Endpoints on a Pledge in Responder Mode

     HTTP(S) uses the Host header field (or :authority in HTTP/2) to allow
     for name-based virtual hosting as explained in Section 7.2 of
     [RFC9110].  This header field is mandatory, and so a compliant
     HTTP(S) client is going to insert it, which may be just an IP



  Fries, et al.            Expires 5 December 2025               [Page 24]


  Internet-Draft                  BRSKI-PRM                      June 2025


     address.  In the absence of a security policy the pledge MUST respond
     to all requests regardless of the Host header field provided by the
     client (i.e., ignore it).  A security policy may include a rate
     limiting for requests to avoid susceptibility of the pledge to
     overload.  Note that there is no requirement for the pledge to
     operate its BRSKI-PRM service on port numbers 80 or 443, so there is
     no reason for name-based virtual hosting.

     For instance, when the Registrar-Agent reaches out to the "tpvr"
     endpoint on a pledge in responder mode with the full URI
     http://pledge.example.com/.well-known/brski/tpvr, it sets the Host
     header field to pledge.example.com and the absolute path /.well-
     known/brski/tpbr.  In practice, however, the pledge is usually known
     by a .local hostname or only its IP address as returned by a
     discovery protocol, which will be included in the Host header field.

     As BRSKI-PRM uses authenticated self-contained objects between the
     pledge and the domain registrar, the binding of the pledge identity
     to the voucher-requests is provided by the wrapping signature
     employing the pledge IDevID credential.  Hence, pledges MUST have an
     Initial Device Identifier (IDevID) installed in them at the factory.

  6.2.1.  Pledge with Combined Functionality

     Pledges may support both initiator and responder mode.

     A pledge in initiator mode should listen for announcement messages as
     described in Section 4.1 of [RFC8995].  Upon discovery of a potential
     registrar, it initiates the bootstrapping to that registrar.  At the
     same time (so as to avoid the Slowloris-like attack described in
     [RFC8995]), it SHOULD also respond to the triggers for responder mode
     described in this document.

     Once a pledge with combined functionality has been bootstrapped, it
     MAY act as client for enrollment of further certificates needed,
     e.g., using the enrollment protocol of choice.  If it still acts as
     server, the defined BRSKI-PRM endpoints to trigger a Pledge Enroll-
     Request (PER) or to provide an Enroll-Response can be used for
     further certificates.

  6.2.2.  Pledgestatus "reason-context" Values

     The following table provides an overview of "reason-context" values
     and further details of pledgestatus data objects:







  Fries, et al.            Expires 5 December 2025               [Page 25]


  Internet-Draft                  BRSKI-PRM                      June 2025


     +==================+=================+==============================+
     | "reason-context" | Predef.         | Description                  |
     | Value            | Details         |                              |
     +==================+=================+==============================+
     | pbs-details      |                 | Pledge bootstrap status      |
     |                  |                 | details, Section 7.11.2.1    |
     +------------------+-----------------+------------------------------+
     |                  | factory-default | Pledge has not been          |
     |                  |                 | bootstrapped                 |
     +------------------+-----------------+------------------------------+
     |                  | voucher-success | Pledge processed voucher     |
     |                  |                 | exchange successfully        |
     +------------------+-----------------+------------------------------+
     |                  | voucher-error   | Pledge voucher processing    |
     |                  |                 | with error                   |
     +------------------+-----------------+------------------------------+
     |                  | enroll-success  | Pledge processed enrollment  |
     |                  |                 | exchange successfully        |
     +------------------+-----------------+------------------------------+
     |                  | enroll-error    | Pledge enrollment-response   |
     |                  |                 | processing with error        |
     +------------------+-----------------+------------------------------+
     | pos-details      |                 | Pledge operation status      |
     |                  |                 | details, Section 7.11.2.1    |
     +------------------+-----------------+------------------------------+
     |                  | connect-success | Pledge successfully          |
     |                  |                 | establish connection to      |
     |                  |                 | peer                         |
     +------------------+-----------------+------------------------------+
     |                  | connect-error   | Pledge connection            |
     |                  |                 | establishment with error     |
     +------------------+-----------------+------------------------------+

           Table 2: Pledgestatus "reason-context" values and details

     Note that the predefined details listed in Table 2 may be enhanced by
     other specifications if necessary.  The currently defined details
     reflect the different stages during onboarding along the exchanges
     shown in Figure 4.

  6.2.3.  Voucher Status and Enroll Status Telemetry "reason-context"
          Values

     The following table provides an overview of "reason-context" values
     and further details of voucher status and enroll status telemetry
     data objects:





  Fries, et al.            Expires 5 December 2025               [Page 26]


  Internet-Draft                  BRSKI-PRM                      June 2025


      +========================+==============+========================+
      | "reason-context" Value | Details type | Description            |
      +========================+==============+========================+
      | pvs-details            | STRING       | Pledge voucher status  |
      |                        |              | details, Section 7.6.2 |
      +------------------------+--------------+------------------------+
      | pes-details            | STRING       | Pledge enroll status   |
      |                        |              | details, Section 7.8.2 |
      +------------------------+--------------+------------------------+

         Table 3: Voucher Status and Enroll Status Telemetry "reason-
                         context" values and details

  6.3.  Domain Registrar

     The domain registrar provides the endpoints already specified in
     [RFC8995] (derived from EST [RFC7030]) where suitable.  In addition,
     it MUST provide the endpoints defined in Table 4 within the BRSKI-
     defined /.well-known/brski/ Well-Known URI path.  These endpoints
     accommodate for the authenticated self-contained objects used by
     BRSKI-PRM to provide Pledge Enroll-Request (PER) artifacts and
     signature-wrapped CA certificates via the Registrar-Agent.

     +================+=========================+========================+
     | Endpoint       | Operation               | Exchange and Artifacts |
     +================+=========================+========================+
     | requestenroll  | Supply PER              | Section 7.4            |
     |                | to Registrar            |                        |
     +----------------+-------------------------+------------------------+
     | wrappedcacerts | Obtain CA               | Section 7.5            |
     |                | Certificates            |                        |
     +----------------+-------------------------+------------------------+

       Table 4: Additional Well-Known Endpoints on a BRSKI-PRM Registrar

     For the supply of the PVR to the registrar, the pledge uses the
     endpoint "requestvoucher", defined in [RFC8995] as described in
     Section 7.3.

     The registrar possesses its own EE certificate and corresponding
     private key for authenticating and signing.  It MUST use the same
     certificate/credentials for authentication in the TLS session with a
     Registrar-Agent and for signing artifacts for that Registrar-Agent
     and its pledges (see Section 7.3.6).

     According to Section 5.3 of [RFC8995], a domain registrar performs
     the pledge authorization for bootstrapping within its domain based on
     the Pledge Voucher-Request.  For this, it MUST possess the IDevID



  Fries, et al.            Expires 5 December 2025               [Page 27]


  Internet-Draft                  BRSKI-PRM                      June 2025


     trust anchor(s) (i.e., root or issuing CA certificate(s)) of the
     pledge vendor(s)/manufacturer(s).  This behavior is retained in
     BRSKI-PRM.

     In its role as EST server [RFC7030], the domain registrar MUST also
     possess the domain CA certificates as defined in Section 5.9 of
     [RFC8995].

     Finally, the domain registrar MUST possess the Registrar-Agent EE
     certificate(s) to validate agent-signed data and to provide it to the
     MASA.  The registrar MAY use the certificate verified during client
     authentication within the TLS sessions with the Registrar-Agent; in
     this case, the registrar MUST possess the domain trust anchor (i.e.,
     domain CA certificate) for the Registrar-Agent EE certificate to
     verify the certificate chain.  Alternatively, the Registrar-Agent EE
     certificate(s) MAY be provided via configuration or a repository.

  6.3.1.  Domain Registrar with Combined Functionality

     A registrar with combined BRSKI and BRSKI-PRM functionality MAY
     detect if the bootstrapping is performed by the pledge directly
     (BRSKI case) or by a Registrar-Agent (BRSKI-PRM case) based on the
     utilized credentials for client authentication during the TLS session
     establishment and switch the operational mode from BRSKI to BRSKI-
     PRM.

     This may be supported by a specific naming in the SAN (subject
     alternative name) component of the Registrar-Agent EE certificate,
     which allows the domain registrar to explicitly detect already in the
     TLS session establishment that the connecting client is a Registrar-
     Agent.

     The registrar MAY be configured to only accept certain Registrar-
     Agents, which authenticate using the Registrar-Agent EE certificate.

     Note that using an EE certificate for TLS client authentication of
     the Registrar-Agent is a deviation from [RFC8995], in which the
     pledge IDevID certificate is used to perform TLS client
     authentication.

  6.4.  MASA

     The Manufacturer Authorized Signing Authority (MASA) is a vendor
     service that generates and signs voucher artifacts for pledges by the
     same vendor.  When these pledges support BRSKI-PRM, the MASA needs to
     implement the following functionality in addition to BRSKI [RFC8995].





  Fries, et al.            Expires 5 December 2025               [Page 28]


  Internet-Draft                  BRSKI-PRM                      June 2025


     A MASA for pledges in responder mode MUST support the voucher format
     defined in [I-D.ietf-anima-jws-voucher] to parse and process JWS-
     signed voucher-request artifacts and generate JWS-signed voucher
     artifacts.

     Further, a MASA for pledges in responder mode MUST support the Agent
     Proximity Assertion (Section 5.4) through the validation steps
     defined in Section 7.3.1 based on the Pledge Voucher-Request (PVR)
     and Registrar Voucher-Request (RVR) artifact fields defined in
     Section 7.1.2 and Section 7.3.4, respectively.

  7.  Exchanges and Artifacts

     The interaction of the pledge with the Registrar-Agent may be
     accomplished using different transports (i.e., protocols and/or
     network technologies).  This specification utilizes HTTP(S) as
     default transport.  Other specifications may define alternative
     transports such as CoAP, Bluetooth Low Energy (BLE), or Near Field
     Communication (NFC).  These transports may differ from and are
     independent of the ones used between the Registrar-Agent and the
     registrar.

     Transport independence is realized through authenticated self-
     contained objects that are not bound to a specific transport security
     and stay the same along the communication path from the pledge via
     the Registrar-Agent to the registrar.  [I-D.ietf-anima-rfc8366bis]
     defines CMS-signed JSON structures as format for artifacts
     representing authenticated self-contained objects.  This
     specification utilizes JWS-signed JSON structures as default format
     for BRSKI-PRM.  Other specifications may define alternative formats
     for representing authenticated self-contained objects such as COSE-
     signed CBOR structures.

     Figure 4 provides an overview of the exchanges detailed in the
     following subsections.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    |     discover     |                 |                 |            |
    |      pledge      |                 |                 |            |
    |    mDNS query    |                 |                 |            |
    |<-----------------|                 |                 |            |
    |----------------->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~



  Fries, et al.            Expires 5 December 2025               [Page 29]


  Internet-Draft                  BRSKI-PRM                      June 2025


   (1) Trigger Pledge Voucher-Request
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<------tPVR-------|                 |                 |            |
    |--------PVR------>|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (2) Trigger Pledge Enroll-Request
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<------tPER-------|                 |                 |            |
    |--------PER------>|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (3) Supply PVR to Registrar (including MASA interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<-----mTLS------>|                 |            |
    |                  |                 |                 |            |
    |                  |         [Registrar-Agent          |            |
    |                  |    authenticated&authorized?]     |            |
    |                  |                 |                 |            |
    |                  |-------PVR------>|                 |            |
    |                  |                 |                 |            |
    |                  |          [accept device?]         |            |
    |                  |                 |                 |            |
    |                  |                 |<------------mTLS------------>|
    |                  |                 |--------------RVR------------>|
    |                  |                 |                 ~            |
    |                  |                 |              [extract DomainID]
    |                  |                 |              [update audit-log]
    |                  |                 |                 ~            |
    |                  |                 |<-----------Voucher-----------|
    |                  |<----Voucher''---|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (4) Supply PER to Registrar (including Key Infrastructure interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<---((mTLS))---->|                 |            |
    |                  |-------PER------>|                 |            |
    |                  |                 |----[Request]--->|            |
    |                  |                 |<--[Certificate]-|            |
    |                  |<--Enroll-Resp---|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~



  Fries, et al.            Expires 5 December 2025               [Page 30]


  Internet-Draft                  BRSKI-PRM                      June 2025


   (5) Obtain CA Certificates
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<----(mTLS)----->|                 |            |
    |                  |<----caCerts-----|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (6) Supply Voucher to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----Voucher''---|                 |                 |            |
    |------vStatus---->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (7) Supply CA Certificates to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----caCerts-----|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (8) Supply Enroll-Response to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<---Enroll-Resp---|                 |                 |            |
    |-----eStatus----->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (9) Voucher Status Telemetry (including backend interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<----(mTLS)----->|                 |            |
    |                  |-----vStatus---->|                 |            |
    |                  |                 |<-----------(mTLS)----------->|
    |                  |                 |-----req device audit-log---->|
    |                  |                 |<------device audit-log-------|
    |                  |                 |                 |            |
    |                  |        [verify audit-log]         |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~
   (10) Enroll Status Telemetry
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<----(mTLS)----->|                 |            |
    |                  |-----eStatus---->|                 |            |
    |                  |                 |                 |            |



  Fries, et al.            Expires 5 December 2025               [Page 31]


  Internet-Draft                  BRSKI-PRM                      June 2025


    ~                  ~                 ~                 ~            ~
   (11) Query Pledge Status
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----tStatus-----|                 |                 |            |
    |------pStatus---->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

             Figure 4: Overview pledge-responder-mode exchanges

     The following subsections split the interactions shown in Figure 4
     between the different components into:

     1.   Section 7.1 describes the acquisition exchange for the Pledge
          Voucher-Request initiated by the Registrar-Agent to the pledge.

     2.   Section 7.2 describes the acquisition exchange for the Pledge
          Enroll-Request initiated by the Registrar-Agent to the pledge.

     3.   Section 7.3 describes the issuing exchange for the Voucher
          initiated by the Registrar-Agent to the registrar, including the
          interaction of the registrar with the MASA using the RVR
          Section 7.3.4, as well as the artifact processing by these
          entities.

     4.   Section 7.4 describes the enroll exchange initiated by the
          Registrar-Agent to the registrar including the interaction of
          the registrar with the CA using the PER as well as the artifact
          processing by these entities.

     5.   Section 7.5 describes the retrieval exchange for the optional CA
          certificate provisioning to the pledge initiated by the
          Registrar-Agent to the CA.

     6.   Section 7.6 describes the Voucher exchange initiated by the
          Registrar-Agent to the pledge and the returned status
          information.

     7.   Section 7.7 describes the CA certificate exchange initiated by
          the Registrar-Agent to the pledge.

     8.   Section 7.8 describes the Enroll-Response exchange initiated by
          the Registrar-Agent to the pledge (containing a new pledge EE
          certificate) and the returned status information.





  Fries, et al.            Expires 5 December 2025               [Page 32]


  Internet-Draft                  BRSKI-PRM                      June 2025


     9.   Section 7.9 describes the Voucher Status telemetry exchange
          initiated by the Registrar-Agent to the registrar, including the
          interaction of the registrar with the MASA.

     10.  Section 7.10 describes the Enroll Status telemetry exchange
          initiated by the Registrar-Agent to the registrar.

     11.  Section 7.11 describes the Pledge Status exchange about the
          general bootstrapping state initiated by the Registrar-Agent to
          the pledge.

  7.1.  Trigger Pledge Voucher-Request

     The Registrar-Agent begins the sequence of exchanges by sending the
     Pledge Voucher-Request Trigger (tPVR).  This assumes that the
     Registrar-Agent has already discovered the pledge, for instance as
     described in Section 6.1.2 based on DNS-SD or similar.

     TLS MAY be used to provide transport security, e.g., privacy and peer
     authentication, for the exchange between the Registrar-Agent and the
     pledge (see Appendix B).

     Figure 5 shows the acquisition of the Pledge Voucher-Request (PVR)
     and the following subsections describe the corresponding artifacts.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (1) Trigger Pledge Voucher-Request
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<------tPVR-------|                 |                 |            |
    |--------PVR------>|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                     Figure 5: PVR acquisition exchange










  Fries, et al.            Expires 5 December 2025               [Page 33]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The Registrar-Agent triggers the pledge to create a PVR via HTTP(S)
     POST to the pledge endpoint at /.well-known/brski/tpvr.  The request
     body MUST contain the JSON-based Pledge Voucher-Request Trigger
     (tPVR) artifact as defined in Section 7.1.1.  In the request header,
     the Content-Type field MUST be set to application/json and the Accept
     field SHOULD be set to application/voucher-jws+json as defined in
     [I-D.ietf-anima-jws-voucher].

     Upon receiving a valid tPVR, the pledge MUST reply with the PVR
     artifact as defined in Section 7.1.2 in the body of an HTTP 200 OK
     response.  If the Accept header was not provided in the PVR, the
     pledge assumes that the accepted response format is application/
     voucher-jws+json and proceeds processing.  In the response header,
     the Content-Type field MUST be set to application/voucher-jws+json as
     defined in [I-D.ietf-anima-jws-voucher].

     Note that the pledge provisionally accepts the registrar EE
     certificate contained in the tPVR until it receives the voucher (see
     Section 5.4).  The pledge will take the last received tPVR for the
     provisional accept of the received registrar EE certificate, if it
     does not have the capability to store more that one registrar EE
     certificate.

     If the pledge is unable to create the PVR, it responds with an HTTP
     error status code to the Registrar-Agent.  The following client error
     status codes can be used:

     *  400 Bad Request: if the pledge detects an error in the format of
        the request, e.g., missing field, wrong data types, etc. or if the
        request is not valid JSON even though the Content-Type request
        header field was set to application/json.

     *  406 Not Acceptable: if the Accept request header field indicates a
        type that is unknown or unsupported, e.g., a type other than
        application/voucher-jws+json.

     *  415 Unsupported Media Type: if the Content-Type request header
        field indicates a type that is unknown or unsupported, e.g., a
        type other than application/json.

     The pledge MAY use the response body to signal success/failure
     details to the service technician operating the Registrar-Agent.

     While BRSKI-PRM does not specify which content may be provided in the
     response body, it is recommended to provided it as JSON encoded
     information as other BRSKI-PRM exchanges also utilize this encoding.





  Fries, et al.            Expires 5 December 2025               [Page 34]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.1.1.  Request Artifact: Pledge Voucher-Request Trigger (tPVR)

     The Pledge Voucher-Request Trigger (tPVR) artifact SHALL be an
     unsigned data object, providing the necessary parameters for
     generating the Pledge Voucher-Request (PVR) artifact such that the
     Agent Proximity Assertion can be verified by registrar and MASA: the
     registrar EE certificate and an agent-signed data object containing
     the product-serial-number and a timestamp.  The artifact is unsigned
     because at the time of receiving the tPVR, the pledge could not
     verify any signature.

     For the JSON-based format used by this specification, the tPVR
     artifact SHALL be a UTF-8 encoded JSON document [RFC8259] that
     conforms with the CDDL [RFC8610] data model defined in Figure 6:

       pledgevoucherrequesttrigger = {
         "agent-provided-proximity-registrar-cert": bytes,
         "agent-signed-data": bytes
       }

               Figure 6: CDDL for Pledge Voucher-Request Trigger
                         (pledgevoucherrequesttrigger)

     The agent-provided-proximity-registrar-cert member SHALL contain the
     base64-encoded registrar EE certificate in X.509 v3 (DER) format.
     The agent-signed-data member SHALL contain the base64-encoded JWS
     Agent-Signed Data as defined in Section 7.1.1.1.  Figure 7 summarizes
     the serialization the JSON tPVR artifact:

     {
       "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
       "agent-signed-data": BASE64(UTF8(JWS Agent-Signed Data))
     }

                     Figure 7: tPVR Representation in JSON

  7.1.1.1.  JWS Agent-Signed Data

     To enable alternative formats, the YANG module in
     [I-D.ietf-anima-rfc8366bis] defines the leaf agent-signed-data as
     binary.  For the JWS-signed JSON format used by this specification,
     the agent-signed-data leaf SHALL be a UTF-8 encoded JWS structure in
     "General JWS JSON Serialization Syntax" as defined in Section 7.2.1
     of [RFC7515] signing the JSON Agent-Signed Data defined in
     Section 7.1.1.1.1.  Figure 8 summarizes this JWS structure for the
     agent-signed-data member of the tPVR artifact:





  Fries, et al.            Expires 5 December 2025               [Page 35]


  Internet-Draft                  BRSKI-PRM                      June 2025


     {
       "payload": BASE64URL(UTF8(JSON Agent-Signed Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

       Figure 8: JWS Agent-Signed Data in General JWS JSON Serialization
                                     Syntax

     The JSON Agent-Signed Data MUST be UTF-8 encoded to become the octet-
     based JWS Payload defined in [RFC7515].  The JWS Payload is further
     base64url-encoded to become the string value of the payload member as
     described in Section 3.2 of [RFC7515].  The octets of the UTF-8
     representation of the JWS Protected Header are base64url-encoded to
     become the string value of the protected member.  The generated JWS
     Signature is base64url-encoded to become the string value of the
     signature member.

  7.1.1.1.1.  JSON Agent-Signed Data

     The JSON Agent-Signed Data SHALL be a JSON document [RFC8259] that
     MUST conform with the CDDL [RFC8610] data model defined in Figure 9:

       prmasd = {
         "created-on": tdate,
         "serial-number": text
       }

               Figure 9: CDDL for JSON Agent-Signed Data (prmasd)

     The created-on member SHALL contain the current date and time at tPVR
     creation as standard date/time string as defined in Section 5.6 of
     [RFC3339].

     The serial-number member SHALL contain the product-serial-number of
     the pledge with which the Registrar-Agent assumes to communicate as
     string.  The format MUST correspond to the X520SerialNumber field of
     IDevID certificates.

     Figure 10 below shows an example for the JSON Agent-Signed Data:







  Fries, et al.            Expires 5 December 2025               [Page 36]


  Internet-Draft                  BRSKI-PRM                      June 2025


     {
       "created-on": "2021-04-16T00:00:01.000Z",
       "serial-number": "vendor-pledge4711"
     }

                   Figure 10: JSON Agent-Signed Data Example

  7.1.1.1.2.  JWS Protected Header

     The JWS Protected Header of the agent-signed-data member MUST contain
     the following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

     *  kid: SHALL contain the base64-encoded OCTET STRING value of the
        SubjectKeyIdentifier of the Registrar-Agent EE certificate as
        described in Section 6.1.

     Figure 11 shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "kid": "base64encodedvalue=="
     }

                  Figure 11: JWS Protected Header Example for

  7.1.1.1.3.  JWS Signature

     The Registrar-Agent MUST sign the agent-signed-data member using its
     EE credentials.  The JWS Signature is generated over the JWS
     Protected Header and the JWS Payload as described in Section 5.1 of
     [RFC7515].  Algorithms used for JWS signatures MUST support ES256 as
     recommended in [RFC7518] and MAY support further algorithms.

  7.1.2.  Response Artifact: Pledge Voucher-Request (PVR)

     The Pledge Voucher-Request (PVR) artifact SHALL be an authenticated
     self-contained object signed by the pledge, containing an extended
     Voucher-Request artifact based on Section 5.2 of [RFC8995].  The
     BRSKI-PRM related enhancements of the ietf-voucher-request YANG
     module are defined in [I-D.ietf-anima-rfc8366bis].








  Fries, et al.            Expires 5 December 2025               [Page 37]


  Internet-Draft                  BRSKI-PRM                      June 2025


     For the JWS-signed JSON format used by this specification, the PVR
     artifact MUST be a JWS Voucher structure as defined in
     [I-D.ietf-anima-jws-voucher], which MUST contain the JSON PVR Data
     defined in Section 7.1.2.1 in the JWS Payload.  Figure 12 summarizes
     the serialization of the JWS-signed JSON PVR artifact:

     {
       "payload": BASE64URL(UTF8(JSON PVR Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

        Figure 12: PVR Representation in General JWS JSON Serialization
                                     Syntax

  7.1.2.1.  JSON PVR Data

     The JSON PVR Data MUST contain the following fields of the ietf-
     voucher-request YANG module as defined in
     [I-D.ietf-anima-rfc8366bis]; note that this makes optional leaf data
     nodes in the YANG definition mandatory for the PVR artifact:

     *  created-on: SHALL contain the current date and time at PVR
        creation as standard date/time string as defined in Section 5.6 of
        [RFC3339]; if the pledge does not have synchronized time, it SHALL
        use the created-on value from the JSON Agent-Signed Data received
        with the tPVR artifact and SHOULD advance that value based on its
        local clock to reflect the PVR creation time.

     *  nonce: SHALL contain a cryptographically strong random or pseudo-
        random number nonce (see Section 6.2 of [RFC4086]).

     *  serial-number: SHALL contain the product-serial-number in the
        X520SerialNumber field of the pledge IDevID certificate as string
        as defined in Section 2.3.1 of [RFC8995].

     *  assertion: SHALL contain the assertion type agent-proximity to
        indicate the pledge request (different from BRSKI [RFC8995]).

     *  agent-provided-proximity-registrar-cert: SHALL contain the
        base64-encoded registrar EE certificate provided in the tPVR by
        the Registrar-Agent; enables the registrar and MASA to verify the
        Agent Proximity Assertion.




  Fries, et al.            Expires 5 December 2025               [Page 38]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  agent-signed-data: SHALL contain the same value as the agent-
        signed-data member in the tPVR provided by the Registrar-Agent;
        enables the registrar and MASA to verify the Agent Proximity
        Assertion; also enables the registrar to log which Registrar-Agent
        was in contact with the pledge.

     Figure 13 shows an example for the JSON PVR Data:

   {
     "ietf-voucher-request:voucher": {
        "created-on": "2021-04-16T00:00:02.000Z",
        "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
        "serial-number": "vendor-pledge4711",
        "assertion": "agent-proximity",
        "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
        "agent-signed-data": "base64encodedvalue=="
     }
   }

                      Figure 13: JSON PVR Data Example

  7.1.2.2.  JWS Protected Header

     The JWS Protected Header MUST follow the definitions of Section 3.2
     of [I-D.ietf-anima-jws-voucher].

  7.1.2.3.  JWS Signature

     The pledge MUST sign the PVR artifact using its IDevID credential
     following the definitions of Section 3.3 of
     [I-D.ietf-anima-jws-voucher].  Algorithms used for JWS signatures
     MUST support ES256 as recommended in [RFC7518] and MAY support
     further algorithms.

  7.2.  Trigger Pledge Enroll-Request

     Once the Registrar-Agent has received the PVR it can trigger the
     pledge to generate a Pledge Enroll-Request (PER).

     TLS MAY be used to provide privacy for this exchange between the
     Registrar-Agent and the pledge (see Appendix B).

     Figure 14 shows the acquisition of the PER and the following
     subsections describe the corresponding artifacts.







  Fries, et al.            Expires 5 December 2025               [Page 39]


  Internet-Draft                  BRSKI-PRM                      June 2025


   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (2) Trigger Pledge Enroll-Request
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<------tPER-------|                 |                 |            |
    |--------PER------>|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                    Figure 14: PER acquisition exchange

     The Registrar-Agent triggers the pledge to create the PER via HTTP(S)
     POST to the pledge endpoint at /.well-known/brski/tper.  The request
     body MUST contain the JSON-based Pledge Enroll-Request Trigger (tPER)
     artifact as defined in Section 7.2.1.  In the request header, the
     Content-Type field MUST be set to application/json and the Accept
     field SHOULD be set to application/jose+json.

     Upon receiving a valid tPER, the pledge MUST reply with the PER
     artifact as defined in Section 7.2.2 in the body of an HTTP 200 OK
     response.  If the Accept header was not provided in the PER, the
     pledge assumes that the accepted response format is application/
     voucher-jws+json and proceeds processing.  In the response header,
     the Content-Type field MUST be set to application/jose+json.

     If the pledge is unable to create the PER, it responds with an HTTP
     error status code to the Registrar-Agent.  The following client error
     status codes can be used:

     *  400 Bad Request: if the pledge detects an error in the format of
        the request.

     *  406 Not Acceptable: if the Accept request header field indicates a
        type that is unknown or unsupported, e.g., a type other than
        application/jose+json.

     *  415 Unsupported Media Type: if the Content-Type request header
        field indicates a type that is unknown or unsupported, e.g., a
        type other than application/json.






  Fries, et al.            Expires 5 December 2025               [Page 40]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The pledge MAY use the response body to signal success/failure
     details to the service technician operating the Registrar-Agent.
     While BRSKI-PRM does not specify which content may be provided in the
     response body, it is recommended to provided it as JSON encoded
     information as other BRSKI-PRM exchanges also utilize this encoding.

  7.2.1.  Request Artifact: Pledge Enroll-Request Trigger (tPER)

     The Pledge Enroll-Request Trigger (tPVR) artifact SHALL be an
     unsigned data object, providing enrollment parameters.  This document
     specifies only the basic parameter for a generic, device-related
     LDevID certificate with no CSR attributes provided to the pledge.  If
     specific attributes in the certificate are required, they have to be
     inserted by the issuing Key Infrastructure.

     The Pledge Enroll-Request Trigger (tPER) artifact MAY be used to
     provide additional enrollment parameters such as CSR attributes.  How
     to provide and use such additional data is out of scope for this
     specification.

     For the JSON-based format used by this specification, the tPER
     artifact MUST be a UTF-8 encoded JSON document [RFC8259] that
     conforms with the CDDL [RFC8610] data model defined in Figure 15:

     pledgeenrollrequesttrigger = {
         "enroll-type": $enroll-type
     }

     $enroll-type /= "enroll-generic-cert"

               Figure 15: CDDL for Pledge Enroll-Request Trigger
                          (pledgeenrollrequesttrigger)

     The enroll-type member allows for specifying which type of
     certificate is to be enrolled.  As shown in Figure 15, BRSKI-PRM only
     defines the enumeration value enroll-generic-cert for the enrollment
     of the generic, device-related LDevID certificate.  Other
     specifications using this artifact may define further enum values,
     e.g., to bootstrap application-related EE certificates with
     additional CSR attributes.











  Fries, et al.            Expires 5 December 2025               [Page 41]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.2.2.  Response Artifact: Pledge Enroll-Request (PER)

     The Pledge Enroll-Request (PER) artifact SHALL be an authenticated
     self-contained object signed by the pledge, containing a PKCS#10
     Certificate Signing Request (CSR) [RFC2986].  The CSR already assures
     POP of the private key corresponding to the contained public key.  In
     addition, based on the PER signature using the IDevID of the pledge,
     POI is provided.

     For the JWS-signed JSON format used by this specification, the PER
     artifact MUST use the "General JWS JSON Serialization Syntax" defined
     in Section 7.2.1 of [RFC7515], which MUST contain the JSON CSR Data
     defined in Section 7.2.2.1 in the JWS Payload.  Figure 16 summarizes
     the serialization of the JWS-signed JSON PER artifact:

     {
       "payload": BASE64URL(UTF8(JSON CSR Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

        Figure 16: PER Representation in General JWS JSON Serialization
                                     Syntax

     The JSON CSR Data MUST be UTF-8 encoded to become the octet-based JWS
     Payload defined in [RFC7515].  The JWS Payload is further base64url-
     encoded to become the string value of the payload member as described
     in Section 3.2 of [RFC7515].  The octets of the UTF-8 representation
     of the JWS Protected Header are base64url-encoded to become the
     string value of the protected member.  The generated JWS Signature is
     base64url-encoded to become the string value of the signature member.

  7.2.2.1.  JSON CSR Data

     The JSON CSR Data SHALL be a JSON document [RFC8259] that MUST
     conform with the data model described by the csr-grouping of the
     ietf-ztp-types YANG module defined in Section 3.2 of [RFC9646] and
     MUST be encoded using the rules defined in [RFC7951].  Note that
     [RFC9646] also allows for inclusion of CSRs in different formats used
     by CMP and CMC.  For PKCS#10 CSRs as used in BRSKI and BRSKI-PRM, the
     p10-csr case of the csr-grouping MUST be used.

     Figure 17 below shows an example for the JSON CSR Data:




  Fries, et al.            Expires 5 December 2025               [Page 42]


  Internet-Draft                  BRSKI-PRM                      June 2025


     {
       "ietf-ztp-types": {
          "p10-csr": "base64encodedvalue=="
        }
     }

                        Figure 17: JSON CSR Data Example

  7.2.2.2.  JWS Protected Header

     The JWS Protected Header of the PER artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

     *  x5c: SHALL contain the base64-encoded pledge EE certificate used
        to sign the PER artifact and it SHOULD also contain the
        certificate chain for this certificate.  The certificate chain
        MUST be available for certificate verification.  If it is not
        contained in the x5c Header Parameter it is provided to the
        relying party by other means such as configuration.

     *  crit: SHALL indicate the extension Header Parameter created-on to
        ensure that it must be understood and validated by the receiver as
        defined in Section 4.1.11 of [RFC7515].

     In addition, the JWS Protected Header of the PER artifact MUST
     contain the following extension Header Parameter:

     *  created-on: SHALL contain the current date and time at PER
        creation as standard date/time string as defined in Section 5.6 of
        [RFC3339]; if the pledge does not have synchronized time, it SHALL
        use the created-on value from the JSON Agent-Signed Data received
        with the tPVR artifact and SHOULD advance that value based on its
        local clock to reflect the PER creation time.

     The new protected Header Parameter created-on is introduced to
     reflect freshness of the PER.  It allows the registrar to verify the
     timely correlation between the PER artifact and previous exchanges,
     i.e., created-on of PER >= created-on of PVR >= created-on of PVR
     trigger.  The registrar MAY ignore any but the newest PER artifact
     from the same pledge in case the registrar has at any point in time
     more than one pending PER from the pledge.

     Figure 18 shows an example for this JWS Protected Header:





  Fries, et al.            Expires 5 December 2025               [Page 43]


  Internet-Draft                  BRSKI-PRM                      June 2025


     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ],
       "crit": ["created-on"],
       "created-on": "2025-01-13T00:00:02.000Z"
     }

               Figure 18: JWS Protected Header Example within PER

  7.2.2.3.  JWS Signature

     The pledge MUST sign the PER artifact using its IDevID credential.
     The JWS Signature is generated over the JWS Protected Header and the
     JWS Payload as described in Section 5.1 of [RFC7515].  Algorithms
     used for JWS signatures MUST support ES256 as recommended in
     [RFC7518] and MAY support further algorithms.

     While BRSKI-PRM targets the initial enrollment, re-enrollment can be
     supported similarly.  In this case, the pledge MAY use its current,
     potentially application-related EE credential instead of its IDevID
     credential to sign the PER artifact.  The issuing CA can associate
     the re-enrollment request with the pledge based on the previously
     issued and still valid EE certificate.  Note that a pledge that does
     not have synchronized time needs to advance the last known current
     date and time based on its local clock over a longer period, which
     also requires persisting the local clock advancements across reboots.

  7.3.  Supply PVR to Registrar (including MASA interaction)

     Once the Registrar-Agent has acquired one or more PVR and PER object
     pairs, it starts the interaction with the domain registrar.
     Collecting multiple pairs allows bulk bootstrapping of several
     pledges using the same session with the registrar.

     The Registrar-Agent MUST establish a TLS session to the registrar
     with mutual authentication.  In contrast to BRSKI [RFC8995], the TLS
     client authentication uses the Registrar-Agent EE certificate instead
     of the pledge IDevID certificate.  Consequently, the domain registrar
     can distinguish BRSKI (pledge-initiator-mode) from BRSKI-PRM (pledge-
     responder-mode).

     Figure 19 shows the voucher-request processing and the following
     subsections describe the corresponding artifacts.





  Fries, et al.            Expires 5 December 2025               [Page 44]


  Internet-Draft                  BRSKI-PRM                      June 2025


   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (3) Supply PVR to Registrar (including backend interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<-----mTLS------>|                 |            |
    |                  |                 |                 |            |
    |                  |         [Registrar-Agent          |            |
    |                  |    authenticated&authorized?]     |            |
    |                  |                 |                 |            |
    |                  |-------PVR------>|                 |            |
    |                  |                 |                 |            |
    |                  |          [accept device?]         |            |
    |                  |                 |                 |            |
    |                  |                 |<------------mTLS------------>|
    |                  |                 |--------------RVR------------>|
    |                  |                 |                 ~            |
    |                  |                 |              [extract DomainID]
    |                  |                 |              [update audit-log]
    |                  |                 |                 ~            |
    |                  |                 |<-----------Voucher-----------|
    |                  |<----Voucher''---|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                    Figure 19: Voucher issuing exchange

     As a first step of the interaction with the domain registrar, the
     Registrar-Agent SHALL supply the PVR artifact(s) to the registrar via
     HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/
     requestvoucher.  Note that this is the same endpoint as for BRSKI
     described in Section 5.2 of [RFC8995].  The request body MUST contain
     one previously acquired PVR artifact as defined in Section 7.1.2.  In
     the request header, the Content-Type field MUST be set to
     application/voucher-jws+json and the Accept field SHOULD be set to
     application/voucher-jws+json as defined in
     [I-D.ietf-anima-jws-voucher].

     Upon receiving a PVR artifact, the registrar accepts or declines the
     request to join the domain.  For this, it MUST perform pledge
     authorization as defined in Section 5.3 of [RFC8995].  Due to the
     Registrar-Agent in the middle, the registrar MUST verify in addition
     that




  Fries, et al.            Expires 5 December 2025               [Page 45]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  the agent-provided-proximity-registrar-cert field of the PVR
        contains a registrar EE certificate signed by the same domain
        owner as the registrar EE certificate used to sign the RVR; note
        that this check allows for installations with multiple domain
        registrars and for registrar EE certificate renewal between
        exchanges with the Registrar-Agent (see Section 5.2); in many
        installations with a single registrar the contained certificate is
        identical to the signing certificate.

     *  the agent-signed-data field of the PVR is signed with the private
        key corresponding to the Registrar-Agent EE certificate as known
        by the registrar (see Section 6.3); this is done via the
        SubjectKeyIdentifier of the certificate in the kid Header
        Parameter of the JWS Protected Header of the agent-signed-data
        field.

     *  the product-serial-number inside the agent-signed-data is equal to
        the serial-number field of the PVR as well as the X520SerialNumber
        field of the pledge IDevID certificate, which is contained in the
        JWS Protected Header of the PVR.

     *  the Registrar-Agent EE certificate is still valid; this is
        necessary to avoid that a rogue Registrar-Agent generates agent-
        signed-data objects to onboard arbitrary pledges at a later point
        in time, see also Section 12.3.

     If the registrar is unable to process the request or validate the
     PVR, it responds with an HTTP client error status code to the
     Registrar-Agent.  The following client error status codes can be
     used:

     *  400 Bad Request: if the registrar detects an error in the format
        of the request.

     *  403 Forbidden: if the registrar detected that one or more security
        related fields are not valid or if the pledge-provided information
        could not be used with automated allowance.

     *  406 Not Acceptable: if the Accept request header field indicates a
        type that is unknown or unsupported.

     *  415 Unsupported Media Type: if the Content-Type request header
        field indicates a type that is unknown or unsupported.

     Otherwise, the registrar converts the PVR artifact to a Registrar
     Voucher-Request (RVR) artifact (see Section 7.3.4) and starts the
     backend interaction with the MASA.




  Fries, et al.            Expires 5 December 2025               [Page 46]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The domain registrar can respond with an HTTP 202 Accepted response
     status code to the Registrar-Agent at this point following
     Section 5.6 of [RFC8995], while the rules defined for the pledge also
     apply to the Registrar-Agent; in this case, the registrar still
     continues with the MASA interaction to provide the Voucher artifact
     to the retry request.

     The registrar MAY use the response body to signal success/failure
     details to the service technician operating the Registrar-Agent.

  7.3.1.  MASA Interaction

     The domain registrar MUST establish a TLS session with mutual
     authentication to the MASA of the pledge according to Section 5.4 of
     [RFC8995].  It requests the voucher from the MASA according to
     Section 5.5 of [RFC8995] via HTTP-over-TLS POST to the MASA endpoint
     at /.well-known/brski/requestvoucher.  The request body MUST contain
     the RVR artifact as defined in Section 7.3.4.  In the request header,
     the Content-Type field and the Accept field MUST be set to the same
     media type as the incoming PVR artifact.  For the default format used
     in this specification, this is application/voucher-jws+json as
     defined in [I-D.ietf-anima-jws-voucher].

     The assumption is that a pledge typically supports a single artifact
     format and creates the PVR in the supported format; to ensure that
     the pledge is able to process the voucher, the registrar requests
     this format via the HTTP Accept header field when requesting the
     voucher.  Further, the RVR artifact and the PVR artifact inside
     should also use the same format to limit the number of required
     format encoders.  Note that BRSKI-PRM allows for alternative formats
     such as CMS-signed JSON as used in BRSKI [RFC8995] or COSE-signed
     CBOR for constrained environments, when defined by other
     specifications.  Overall, a MASA responsible for BRSKI-PRM capable
     pledges consequently supports the same formats as supported by those
     pledges.

     Once the MASA receives the RVR artifact, it MUST perform the
     verification as described in Section 5.5 of [RFC8995].  Depending on
     policy, the MASA MAY choose the type of assertion to perform.  For
     the Agent Proximity Assertion of BRSKI-PRM (see Section 5.4), the
     MASA MUST skip the verification described in Section 5.5.5 of
     [RFC8995] and instead MUST verify for the PVR contained in the prior-
     signed-voucher-request field of the RVR that








  Fries, et al.            Expires 5 December 2025               [Page 47]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  the agent-provided-proximity-registrar-cert field contains an EE
        certificate that is signed by the same domain owner as the EE
        certificate/credentials used to sign the RVR; note that this check
        allows for installations with multiple domain registrars and for
        registrar EE certificate renewal while PVRs are collected by the
        Registrar-Agent.

     *  the registrar EE certificate in the agent-provided-proximity-
        registrar-cert field and the Registrar-Agent EE certificate in the
        agent-sign-cert field of the RVR are signed by the same domain
        owner.

     *  the agent-signed-data field is signed with the credentials
        corresponding to the Registrar-Agent EE certificate in the agent-
        sign-cert field of the RVR; this is done via the
        SubjectKeyIdentifier of the certificate in the kid Header
        Parameter of the JWS Protected Header in the agent-signed-data
        field.

     *  the product-serial-number inside the agent-signed-data is equal to
        the serial-number field of PVR and the serial-number field of the
        RVR as well as the X520SerialNumber field of the pledge IDevID
        certificate, which is contained in the JWS Protected Header of the
        PVR.

     If the agent-sign-cert field in the RVR is not set, the MASA MAY
     state a lower level assertion value instead of failing the
     verification, e.g., "logged" or "verified".

     If the verification fails, the MASA responds with an HTTP client
     error status code to the registrar.  The client error status codes
     are kept the same as defined in Section 5.6 of [RFC8995]:

     *  403 Forbidden: if the voucher-request is not signed correctly or
        is stale or if the pledge has another outstanding voucher that
        cannot be overridden.

     *  404 Not Found: if the request is for a device that is not known to
        the MASA.

     *  406 Not Acceptable: if a voucher of the desired type or that uses
        the desired algorithms (as indicated by the "Accept" header fields
        and algorithms used in the signature) cannot be issued as such
        because the MASA knows the pledge cannot process that type.

     *  415 Unsupported Media Type: if the request uses an artifact format
        or Accept header value that is not supported by the MASA.




  Fries, et al.            Expires 5 December 2025               [Page 48]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Otherwise, the MASA creates a Voucher artifact as defined in
     Section 7.3.5 and updates the audit-log as described in Section 5.5
     of [RFC8995].  The Voucher is then supplied to the registrar within
     the body of an HTTP 200 OK response according to Section 5.6 of
     [RFC8995].  In the response header, the Content-Type field MUST be
     set to the media type of the incoming RVR artifact.  For the default
     format used in this specification, this is application/voucher-
     jws+json as defined in [I-D.ietf-anima-jws-voucher].

  7.3.2.  Supply Voucher to Registrar-Agent

     After receiving the Voucher from the MASA, the registrar SHOULD
     evaluate it for transparency and logging purposes as outlined in
     Section 5.6 of [RFC8995].  It then countersigns the Voucher for
     delivery to the pledge via the Registrar-Agent.

     The registrar MUST reply to the Registrar-Agent with the registrar-
     countersigned Voucher artifact ('Voucher') as defined in
     Section 7.3.6 in the body of an HTTP 200 OK response.  In the
     response header, the Content-Type field MUST be set to the media type
     of the incoming PVR artifact.  For the default format used in this
     specification, this is application/voucher-jws+json as defined in
     [I-D.ietf-anima-jws-voucher].

     If the domain registrar is unable to return the Voucher, it responds
     with an HTTP server error status code to the Registrar-Agent.  The
     following server error status codes can be used:

     *  500 Internal Server Error: if both Registrar-Agent request and
        MASA response are valid, but the registrar still failed to return
        the Voucher, e.g., due to missing configuration or a program
        failure.

     *  502 Bad Gateway: if the registrar received an invalid response
        from the MASA.

     *  503 Service Unavailable: if a simple retry of the Registrar-Agent
        request might lead to a successful response; this error response
        MUST include the Retry-After response header field with an
        appropriate value.

     *  504 Gateway Timeout: if the backend request to the MASA timed out.

  7.3.3.  Request Artifact: Pledge Voucher-Request (PVR)

     Identical to the PVR artifact received from the pledge as defined in
     Section 7.1.2.  The Registrar-Agent MUST NOT modify PVRs.




  Fries, et al.            Expires 5 December 2025               [Page 49]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.3.4.  Backend Request Artifact: Registrar Voucher-Request (RVR)

     The Registrar Voucher-Request (RVR) artifact SHALL be an extended
     Voucher-Request artifact based on Section 5.5 of [RFC8995].  The
     BRSKI-PRM related enhancements of the ietf-voucher-request YANG
     module are defined in [I-D.ietf-anima-rfc8366bis].

     For the JWS-signed JSON format used by this specification, the RVR
     artifact MUST be a JWS Voucher structure as defined in
     [I-D.ietf-anima-jws-voucher], which MUST contain the JSON RVR Data
     defined in Section 7.3.4.1 in the JWS Payload.  Figure 20 summarizes
     the serialization of the JWS-signed JSON RVR artifact:

     {
       "payload": BASE64URL(UTF8(JSON RVR Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

        Figure 20: RVR Representation in General JWS JSON Serialization
                                     Syntax

  7.3.4.1.  JSON RVR Data

     The JSON RVR Data MUST contain the following fields of the ietf-
     voucher-request YANG module as defined in
     [I-D.ietf-anima-rfc8366bis]; note that this makes optional leaves in
     the YANG definition mandatory for the RVR artifact:

     *  created-on: SHALL contain the current date and time at RVR
        creation as standard date/time string as defined in Section 5.6 of
        [RFC3339]

     *  nonce: SHALL contain a copy of the nonce field from the JSON PVR
        Data the registrar provides this information to assure successful
        verification of Registrar-Agent proximity based on the agent-
        signed-data

     *  serial-number: SHALL contain the product-serial-number of the
        pledge; note the required verification by the registrar defined in
        Section 7.3






  Fries, et al.            Expires 5 December 2025               [Page 50]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  idevid-issuer: SHALL contain the issuer value from the pledge
        IDevID certificate obtained from the PVR JWS Protected Header x5c
        field

     *  prior-signed-voucher-request: SHALL contain the PVR artifact as
        received from the Registrar-Agent, see Section 7.1

     As BRSKI-PRM uses the Agent Proximity Assertion (see Section 5.4),
     the JSON RVR Data MUST also contain the following fields:

     *  assertion: SHALL contain the value agent-proximity to indicate
        successful verification of the Agent Proximity Assertion (see
        Section 5.4) by the registrar.

     *  agent-sign-cert: SHALL be a JSON array that contains the
        base64-encoded Registrar-Agent EE certificate as possessed by the
        registrar (see Section 6.3) as the first item; subsequent items
        MUST contain the corresponding certificate chain for verification
        at the MASA; the field is used for verification of the agent-
        signed-data field of the contained PVR.

     Note that the ietf-voucher-request YANG module defines the leaf
     agent-sign-cert as binary; this specification refines it as a JSON
     array structure similar to the x5c Header Parameter defined in
     Section 4.1.6 of [RFC7515].

     Figure 21 shows an example for the JSON RVR Data:

     {
       "ietf-voucher-request:voucher": {
          "created-on": "2025-01-04T02:37:39.235Z",
          "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
          "serial-number": "vendor-pledge4711",
          "idevid-issuer": "base64encodedvalue==",
          "prior-signed-voucher-request": "base64encodedvalue==",
          "assertion": "agent-proximity",
          "agent-sign-cert": [
            "base64encodedvalue==",
            "base64encodedvalue==",
            "..."
          ]
       }
     }

                        Figure 21: JSON RVR Data Example






  Fries, et al.            Expires 5 December 2025               [Page 51]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.3.4.2.  JWS Protected Header

     The JWS Protected Header MUST follow the definitions of Section 3.2
     of [I-D.ietf-anima-jws-voucher].

  7.3.4.3.  JWS Signature

     The domain registrar MUST sign the RVR artifact using its EE
     credentials following the definitions of Section 3.3 of
     [I-D.ietf-anima-jws-voucher].  Algorithms used for JWS signatures
     MUST support ES256 as recommended in [RFC7518] and MAY support
     further algorithms.

  7.3.5.  Backend Response Artifact: Voucher

     The Voucher artifact is defined in Section 5.6 of [RFC8995] (cf.
     "voucher response").  The only difference for BRSKI-PRM is that the
     assertion field MAY contain the value agent-proximity as defined in
     [I-D.ietf-anima-rfc8366bis], when the Agent-Proximity Assertion (see
     Section 5.4) is performed by the MASA.

     For the JWS-signed JSON format used by this specification, the
     Voucher artifact MUST be a JWS Voucher structure as defined in
     [I-D.ietf-anima-jws-voucher].  It contains JSON Voucher Data in the
     JWS Payload, for which an example is given in Figure 22:

     {
       "ietf-voucher:voucher": {
         "created-on": "2025-01-04T00:00:02.000Z",
         "nonce": "base64encodedvalue==",
         "assertion": "agent-proximity",
         "pinned-domain-cert": "base64encodedvalue==",
         "serial-number": "vendor-pledge4711"
       }
     }

                        Figure 22: JSON RVR Data Example

  7.3.6.  Response Artifact: Registrar-Countersigned Voucher

     The Registrar-Countersigned Voucher (Voucher') artifact SHALL be an
     extended Voucher artifact based on Section 5.6 of [RFC8995] using the
     format defined in Section 7.3.5.

     For BRSKI-PRM, the domain registrar MUST add an JWS Protected Header
     and JWS Signature to the MASA-provided Voucher.  Figure 23 summarizes
     the serialization of the JWS-signed JSON Voucher' artifact:




  Fries, et al.            Expires 5 December 2025               [Page 52]


  Internet-Draft                  BRSKI-PRM                      June 2025


     {
       "payload": BASE64URL(JSON Voucher Data),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header (MASA))),
           "signature": BASE64URL(JWS Signature (MASA))
         },
         {
           "protected": BASE64URL(UTF8(JWS Protected Header (Registrar))),
           "signature": BASE64URL(JWS Signature (Registrar))
         }
       ]
     }

             Figure 23: Voucher' Representation in General JWS JSON
                              Serialization Syntax

     In BRSKI [RFC8995], the registrar proves possession of its credential
     through the server authentication within the TLS session with the
     pledge.  While the pledge cannot verify the registrar certificate at
     the time of TLS session establishment, it can verify the TLS server
     certificate through the certificate in the pinned-domain-cert field
     upon receiving the Voucher artifact (see Section 5.6.2 of [RFC8995]).

     In BRSKI-PRM with the Registrar-Agent mediating all communication,
     this second signature provides verification and POP of the private
     key for the registrar EE certificate provided in the initial tPVR
     artifact from the Registrar-Agent (see Section 7.1.1).

     Depending on the security policy of the operator, this signature can
     also be interpreted as explicit authorization of the registrar to
     install the contained trust anchor (i.e., pinned domain certificate).

  7.3.6.1.  JSON Voucher Data

     As provided by the MASA inside the JWS Payload.  The domain registrar
     MUST NOT modify the JWS Payload.

  7.3.6.2.  JWS Protected Header (Registrar)

     The registrar-added JWS Protected Header (Registrar) MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].






  Fries, et al.            Expires 5 December 2025               [Page 53]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  x5c: SHALL contain the base64-encoded registrar EE certificate
        used to sign the voucher as well as the certificate chain up to
        (but not including) the pinned domain certificate (the initial
        domain trust anchor); the pinned domain certificate is already
        contained in the JSON Voucher Data.

     Note that for many installations with a single registrar credential,
     the registrar EE certificate is pinned.

  7.3.6.3.  JWS Signature (Registrar)

     The signature is created by signing the registrar-added JWS Protected
     Header (Registrar) and the original JWS Payload produced by the MASA
     as described in Section 5.1 of [RFC7515].  Algorithms used for JWS
     signatures MUST support ES256 as recommended in [RFC7518] and MAY
     support further algorithms.

     The registrar MUST use its EE credentials to sign.

     Note that the credentials need to be the same as used for server
     authentication in the TLS session with the Registrar-Agent receiving
     this artifact (see Section 6.3).

  7.4.  Supply PER to Registrar (including Key Infrastructure interaction;
        requestenroll)

     After receiving the Voucher artifact, the Registrar-Agent sends the
     PER to the domain registrar within the same TLS session.

     In case the TLS session to the registrar is already closed, the
     Registrar-Agent establishes a new session as described in
     Section 7.3.  The registrar is able to correlate the PVR and PER
     artifacts based on the signatures and the contained product-serial-
     number.  Note that this also addresses situations in which a
     nonceless voucher is used and may be pre-provisioned to the pledge.

     Figure 24 depicts exchanges for the PER-request handling and the
     following subsections describe the corresponding artifacts.  Note
     that "Request" and "Certificate" do not denote BRSKI-PRM defined
     artifacts, but are data objects depending on the certificate
     management protocol used by the domain Key Infrastructure.










  Fries, et al.            Expires 5 December 2025               [Page 54]


  Internet-Draft                  BRSKI-PRM                      June 2025


   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (4) Supply PER to Registrar (including Key Infrastructure interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<----(mTLS)----->|                 |            |
    |                  |-------PER------>|                 |            |
    |                  |                 |----[Request]--->|            |
    |                  |                 |<--[Certificate]-|            |
    |                  |<--Enroll-Resp---|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                         Figure 24: Enroll exchange

     As a second step of the interaction with the domain registrar, the
     Registrar-Agent SHALL supply the PER artifact(s) to the registrar via
     HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/
     requestenroll.  The request body MUST contain one previously acquired
     PER artifact as defined in Section 7.2.2.  In the request header, the
     Content-Type field MUST be set to application/jose+json and the
     Accept field SHOULD be set to application/jose+json.

     Note that this is different from the EST [RFC7030] endpoint used in
     BRSKI, as the PER artifact is signature-wrapped.  Hence, upon
     receiving a PER artifact, the registrar MUST verify that

     *  the PER was signed with the private key corresponding to the
        pledge EE certificate, which is contained in the JWS Protected
        Header of the PER.

     *  the pledge identified by its EE certificate is accepted to join
        the domain after successful validation of the corresponding PVR.

     If the registrar is unable to process the request or validate the
     PER, it responds with an HTTP client error status code to the
     Registrar-Agent.  The following client error status codes can be
     used:

     *  400 Bad Request: if the registrar detects an error in the format
        of the request.

     *  403 Forbidden: if the signature of the PER cannot be verified.




  Fries, et al.            Expires 5 December 2025               [Page 55]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  404 Not Found: if the PER is for a device that is not known to the
        registrar.

     *  406 Not Acceptable: if the Accept request header field indicates a
        type that is unknown or unsupported, e.g., a type other than
        application/jose+json.

     *  415 Unsupported Media Type: if the PER uses an artifact format
        that is not supported by the registrar, e.g., a type other than
        application/jose+json.

     Otherwise, the registrar extracts the PKCS#10 Certificate Signing
     Request (CSR) inside the PER (see Section 7.2.2) and uses the CSR to
     request a new pledge EE certificate from the domain Key
     Infrastructure.  The exact interaction and exchanged data objects
     depends on the certificate management protocol used by the Key
     Infrastructure, and is out of scope for this document.

     A successful interaction with the Key Infrastructure will result in a
     pledge EE certificate signed by the domain owner (e.g., LDevID
     certificate).  The registrar MUST reply to the Registrar-Agent with
     the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the
     body of an HTTP 200 OK response.  In the response header, the
     Content-Type field MUST be set to application/pkcs7-mime with an
     smime-type parameter certs-only, as specified in [RFC7030] and
     [RFC5273].

     If the domain registrar is unable to return the Enroll-Resp, it
     responds with an HTTP server error status code to the Registrar-
     Agent.  The following server error status codes can be used:

     *  500 Internal Server Error: if the Key Infrastructure response is
        valid, but the registrar still failed to return the Enroll-Resp,
        e.g., due to missing configuration or a program failure.

     *  502 Bad Gateway: if the registrar received an invalid response
        from the Key Infrastructure.

     *  503 Service Unavailable: if a simple retry of the Registrar-Agent
        request might lead to a successful response; this error response
        MUST include the Retry-After response header field with an
        appropriate value.

     *  504 Gateway Timeout: if the backend request to the Key
        Infrastructure timed out.






  Fries, et al.            Expires 5 December 2025               [Page 56]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Note that while BRSKI-PRM targets the initial enrollment, re-
     enrollment may be supported similarly with the exception that the
     current, potentially application-related pledge EE certificate is
     used instead of the IDevID certificate to sign the PER artifact (see
     also Section 7.2).  Hence, there is no verification whether the
     pledge is accepted to join the domain, as the still valid EE
     certificate signed by the domain owner identifies the pledge as
     already accepted component of the domain.

  7.4.1.  Request Artifact: Pledge Enroll-Request (PER)

     Identical to the PER artifact defined in Section 7.2.2.  The
     Registrar-Agent MUST NOT modify PERs received from pledges.

  7.4.2.  Response Artifact: Registrar Enroll-Response (Enroll-Resp)

     The Enroll-Response (Enroll-Resp) artifact SHALL be an authenticated
     self-contained object signed by the domain owner, containing a pledge
     EE certificate.

     For this specification, the Enroll-Resp artifact MUST be a certs-only
     CMC Simple PKI Response (PKCS#7) as defined in Section 4.1 of
     [RFC5272] (following EST [RFC7030]).  Note that it only contains the
     pledge EE certificate, but not the certificate chain.  The chain is
     provided with the CA certificates.

  7.5.  Obtain CA Certificates (wrappedcacerts)

     The pinned domain certificate in the voucher is only the initial
     trust anchor for only the domain registrar.  To fully trust the
     domain and also to verify its own EE certificate, the pledge also
     needs the corresponding domain CA certificate(s).  A bag of CA
     certificates signed by the registrar will allow the pledge to verify
     the authorization to install the received CA certificate(s) through
     the pinned domain certificate in the voucher.

     Note that this is a deviation from EST [RFC7030] used in BRSKI
     [RFC8995].

     The Registrar-Agent obtains this artifact within the same TLS
     session.  In case the TLS session to the registrar is already closed,
     the Registrar-Agent establishes a new session as described in
     Section 7.3.  The CA certificates do not need to be correlated to a
     specific voucher or Enroll-Response; they only need to be fresh.

     Figure 25 shows the acquisition of the CA certificate(s) and the
     following subsections describe the corresponding artifact.




  Fries, et al.            Expires 5 December 2025               [Page 57]


  Internet-Draft                  BRSKI-PRM                      June 2025


   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (5) Obtain CA Certificates
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<----(mTLS)----->|                 |            |
    |                  |<----caCerts-----|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

               Figure 25: CA certificates retrieval exchange

     As a third step of the interaction with the domain registrar, the
     Registrar-Agent SHALL obtain the CA-Certificates artifact from the
     registrar via HTTP-over-TLS GET to the registrar endpoint at /.well-
     known/brski/wrappedcacerts.  In the request header, the Accept field
     SHOULD be set to application/jose+json.

     Upon receiving a GET request at /.well-known/brski/wrappedcacerts,
     the domain registrar MUST reply with the CA-Certificates artifact as
     defined in Section 7.5.2 in the body of an HTTP 200 OK response.  In
     the response header, the Content-Type field MUST be set to
     application/jose+json.

  7.5.1.  Request (no artifact)

     In this exchange, the request is a result of the HTTP(S) default
     transport for this specification.  There is no artifact provided to
     the registrar.  As the caCerts artifact processing on the pledge may
     result in errors, signaled via HTTP status codes, the Registrar-Agent
     should log these for evaluation as outlined in Section 8.

  7.5.2.  Response Artifact: CA-Certificates (caCerts)

     The CA-Certificates (caCerts) artifact SHALL be an authenticated
     self-contained object signed by the registrar, containing the domain
     trust anchors and the certificate chain for the pledge domain EE
     certificate, i.e., the root CA certificate(s) and possibly
     intermediate certificate(s) as described in Section 4.1.3 of
     [RFC7030].







  Fries, et al.            Expires 5 December 2025               [Page 58]


  Internet-Draft                  BRSKI-PRM                      June 2025


     For the JWS-signed JSON format used by this specification, the
     caCerts artifact MUST use the "General JWS JSON Serialization Syntax"
     defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON CA
     Data defined in Section 7.5.2.1 in the JWS Payload.

     Figure 26 summarizes the serialization of the JWS-signed JSON caCerts
     artifact:

     {
       "payload": BASE64URL(UTF8(JSON CA Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

             Figure 26: Voucher' Representation in General JWS JSON
                              Serialization Syntax

     The JSON CA Data MUST be UTF-8 encoded to become the octet-based JWS
     Payload defined in [RFC7515].  The JWS Payload is further base64url-
     encoded to become the string value of the payload member as described
     in Section 3.2 of [RFC7515].  The octets of the UTF-8 representation
     of the JWS Protected Header are base64url-encoded to become the
     string value of the protected member.  The generated JWS Signature is
     base64url-encoded to become the string value of the signature member.

  7.5.2.1.  JSON CA Data

     The JSON CA Data SHALL be a JSON document [RFC8259] that MUST conform
     with the CDDL [RFC8610] data model defined in Figure 27:

     cacerts = {
         "x5bag": bytes / [2* bytes]
     }

                   Figure 27: CDDL for JSON CA Data (cacerts)

     The x5bag member MUST follow the definition of the x5bag COSE Header
     Parameter in Section 2 of [RFC9360].  It is either a single X.509 v3
     certificate or an array of at least two X.509 v3 certificates in DER
     format.  For JSON syntax, the octet-based certificates MUST be
     base64-encoded.  It SHALL contain one or more domain CA (root or
     issuing) certificates.





  Fries, et al.            Expires 5 December 2025               [Page 59]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Note that as per [RFC8995], the domain registrar acts as EST server,
     and hence is expected to possess the CA certificates applicable for
     the domain and can thus deliver them to the pledge (see Section 6.3).

     Figure 28 below shows an example for the JSON CA Data:

     {
       "x5bag": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }

                        Figure 28: JSON CA Data Example

  7.5.2.2.  JWS Protected Header

     The JWS Protected Header of the caCerts artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

     *  x5c: SHALL contain the base64-encoded registrar EE certificate
        used to sign the caCerts artifact as well as the certificate chain
        up to (but not including) the pinned domain certificate

     Figure 29 below shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }

               Figure 29: JWS Protected Header Example within PER

  7.5.2.3.  JWS Signature

     The registrar MUST sign the caCerts artifact using its EE
     credentials.  The JWS Signature is generated over the JWS Protected
     Header and the JWS Payload as described in Section 5.1 of [RFC7515].
     Algorithms used for JWS signatures MUST support ES256 as recommended
     in [RFC7518] and MAY support further algorithms.





  Fries, et al.            Expires 5 December 2025               [Page 60]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.6.  Supply Voucher to Pledge (svr)

     Once the Registrar-Agent has acquired the following three
     bootstrapping artifacts, it can supply them to the pledge starting
     with the Voucher':

     *  Voucher': voucher countersigned by the registrar (from MASA via
        Registrar)

     *  Enroll-Resp: pledge EE certificate signed by the domain owner
        (from Key Infrastructure via registrar)

     *  caCerts: domain trust anchors (from Key Infrastructure via
        Registrar)

     Reconnecting to the pledge might require to re-discover the pledge as
     described in Section 6.1.2.  The Registrar-Agent MAY store
     information from the first connection with the pledge to optimize
     this process.

     TLS MAY be used to provide privacy for this exchange between the
     Registrar-Agent and the pledge (see Appendix B).

     Figure 30 shows the provisioning of the voucher to the pledge and the
     following subsections describe the corresponding artifacts.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (6) Supply Voucher to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----Voucher''---|                 |                 |            |
    |------vStatus---->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                        Figure 30: Voucher exchange

     The Registrar-Agent SHALL supply the voucher to the pledge via
     HTTP(S) POST to the pledge endpoint at /.well-known/brski/svr.  The
     request body MUST contain the Registrar-Countersigned Voucher
     (Voucher') artifact previously acquired from the domain registrar as
     defined in Section 7.3.6.  In the request header, the Content-Type



  Fries, et al.            Expires 5 December 2025               [Page 61]


  Internet-Draft                  BRSKI-PRM                      June 2025


     field MUST be set to application/voucher-jws+json as defined in
     [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to
     application/jose+json, to indicate the encoding of the vStatus
     response object status telemetry message.

     Upon receiving the voucher, the pledge SHALL perform the signature
     verification in the following order:

     1.  Verify the MASA signature as described in Section 5.6.1 of
         [RFC8995] against the pre-installed manufacturer trust anchor
         (e.g., IDevID).

     2.  Provisionally install the initial domain trust anchor contained
         in the pinned-domain-cert field of the voucher.

     3.  Validate the registrar EE certificate received in the agent-
         provided-proximity-registrar-cert field of the previously
         received tPVR artifact using the pinned domain certificate; this
         terminates the "provisional state" for the object security within
         the authenticated self-contained objects that in BRSKI-PRM
         replace the direct TLS connection to the registrar in BRSKI
         [RFC8995] (see Section 5.4).

     4.  Verify registrar signature of the Voucher' artifact similar as
         described in Section 5.6.1 of [RFC8995], but using the pinned
         domain certificate instead of the MASA certificate for the
         verification.

     If all steps above complete successfully, the pledge SHALL terminate
     the "provisional state" for the initial domain trust anchor (i.e.,
     the pinned domain certificate).

     A nonceless voucher MAY be accepted as in [RFC8995] if allowed by the
     pledge implementation of the manufacturer.  A manufacturer may opt to
     provide the acceptance of nonceless voucher as configurable item.

     After voucher validation and verification, the pledge needs to reply
     with a status telemetry message as defined in Section 5.7 of
     [RFC8995].  The pledge MUST generate the Voucher Status (vStatus)
     artifact as defined in Section 7.6.2 and MUST provide it to the
     Registrar-Agent in the body of an HTTP 200 OK response.  In the
     response header, the Content-Type field MUST be set to application/
     jose+json.

     If the pledge is unable to validate or verify the voucher, it MUST
     report the reason in the corresponding field of the Voucher Status.





  Fries, et al.            Expires 5 December 2025               [Page 62]


  Internet-Draft                  BRSKI-PRM                      June 2025


     If the pledge did not provide voucher status telemetry information
     after processing the voucher, the Registrar-Agent MAY query the
     pledge status explicitly as described in Section 7.11.  It MAY resend
     the voucher depending on the Pledge status following the same
     procedure.

  7.6.1.  Request Artifact: Registrar-Countersigned Voucher

     Identical to the Registrar-Countersigned Voucher (Voucher') artifact
     received from the registrar as defined in Section 7.3.6.  The
     Registrar-Agent MUST NOT modify countersigned vouchers.

  7.6.2.  Response Artifact: Voucher Status (vStatus)

     The Voucher Status (vStatus) artifact SHALL be an authenticated self-
     contained object signed by the pledge, containing status telemetry as
     defined in Section 5.7 of [RFC8995].

     For the JWS-signed JSON format used by this specification, the
     vStatus artifact MUST use the "General JWS JSON Serialization Syntax"
     defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
     Voucher Status Data defined in Section 7.6.2.1 in the JWS Payload.
     Figure 31 summarizes the serialization of the JWS-signed JSON vStatus
     artifact:

     {
       "payload": BASE64URL(UTF8(JSON Voucher Status Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

             Figure 31: vStatus Representation in General JWS JSON
                              Serialization Syntax

     The JSON Status Data MUST be UTF-8 encoded to become the octet-based
     JWS Payload defined in [RFC7515].  The JWS Payload is further
     base64url-encoded to become the string value of the payload member as
     described in Section 3.2 of [RFC7515].  The octets of the UTF-8
     representation of the JWS Protected Header are base64url-encoded to
     become the string value of the protected member.  The generated JWS
     Signature is base64url-encoded to become the string value of the
     signature member.





  Fries, et al.            Expires 5 December 2025               [Page 63]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.6.2.1.  JSON Voucher Status Data

     The JSON Status Data SHALL be a JSON document [RFC8259] that MUST
     conform with the voucherstatus-post CDDL [RFC8610] data model defined
     in Section 5.7 of [RFC8995]:

     *  version: contains a version number for the format and semantics of
        the other fields; this specification assumes version 1 just like
        BRSKI [RFC8995].

     *  status: contains the boolean value true in case of success and
        false in case of failure.

     *  reason: contains a human-readable message; should not provide
        information beneficial to an attacker.  As the pledge is not
        localized at this point in time language selection cannot be done.
        Therefore, English is taken as a default here for this diagnostic
        messages.  The internationalization of text is expected to be done
        on another level.

     *  reason-context: contains a JSON object that provides additional
        information specific to a failure; in contrast to Section 5.7 of
        [RFC8995], MUST be provided;

     BRSKI-PRM implementations utilize the reason-context field to provide
     a distinguishable token, which enables the registrar to detect status
     artifacts provided to the wrong endpoint.  For vStatus artifacts, the
     JSON object in the reason-context field MUST contain the member pvs-
     details.

     Figure 32 shows an example for the JSON Voucher Status Data in case
     of success and Figure 33 in case of failure:

     HTTP/1.1 200 OK
     Content-Type: application/jose+json
     Content-Language: en

     {
       "version": 1,
       "status": true,
       "reason": "Voucher successfully processed.",
       "reason-context": {
         "pvs-details": "Current date 5/23/2024"
       }
     }

              Figure 32: JSON Voucher Status Data Success Example




  Fries, et al.            Expires 5 December 2025               [Page 64]


  Internet-Draft                  BRSKI-PRM                      June 2025


     HTTP/1.1 400 Bad Request
     Content-Type: application/jose+json
     Content-Language: en

     {
       "version": 1,
       "status": false,
       "reason": "Failed to authenticate MASA certificate.",
       "reason-context": {
         "pvs-details": "Current date 1/1/1970 < valid from 1/1/2023"
       }
     }

              Figure 33: JSON Voucher Status Data Failure Example

  7.6.2.2.  JWS Protected Header

     The JWS Protected Header of the vStatus artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

     *  x5c: SHALL contain the base64-encoded pledge IDevID certificate
        used to sign the vStatus artifact and it SHOULD also contain the
        certificate chain for this certificate.  The certificate chain
        MUST be available for certificate verification.  If it is not
        contained in the x5c Header Parameter it is provided to the
        relying party by other means such as configuration.

     Figure 34 shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }

             Figure 34: JWS Protected Header Example within vStatus










  Fries, et al.            Expires 5 December 2025               [Page 65]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.6.2.3.  JWS Signature

     The pledge MUST sign the vStatus artifact using its IDevID
     credential.  The JWS Signature is generated over the JWS Protected
     Header and the JWS Payload as described in Section 5.1 of [RFC7515].
     Algorithms used for JWS signatures MUST support ES256 as recommended
     in [RFC7518] and MAY support further algorithms.

  7.7.  Supply CA Certificates to Pledge (scac)

     Before supplying the pledge EE certificate, the Registrar-Agent
     supplies the domain CA certificates to the pledge, so the pledge can
     verify its EE certificate in the next exchange.  As the CA
     certificate provisioning is crucial from a security perspective, this
     exchange SHOULD only be done if supplying the voucher in the previous
     exchange (Section 7.6) has been successfully processed by the pledge
     as reflected in the vStatus artifact.

     TLS MAY be used to provide privacy for this exchange between the
     Registrar-Agent and the pledge (see Appendix B).

     Figure 35 shows the provisioning of the CA certificates to the pledge
     and the following subsections describe the corresponding artifacts.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (7) Supply CA Certificates to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----caCerts-----|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                Figure 35: Certificate provisioning exchange

     The Registrar-Agent SHALL provide the bag of CA certificates
     requested from and signed by the registrar to the pledge by HTTP(S)
     POST to the pledge endpoint at /.well-known/brski/scac.  The request
     body MUST contain the caCerts artifact as defined in Section 7.5.2.
     In the request header, the Content-Type field MUST be set to
     application/jose+json.





  Fries, et al.            Expires 5 December 2025               [Page 66]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Upon receiving valid caCerts artifact, the pledge MUST first verify
     the signature of the registrar using the initial trust anchor (pinned
     domain certificate).  In the case of success, the pledge MUST install
     the contained CA certificates as trust anchors as described in
     Section 4.1.3 of [RFC7030].  This includes the verification of all
     intermediate CA certificates (i.e., not self-signed CA certificates).

     If the pledge is unable to process the caCerts, it responds with an
     HTTP error status code to the Registrar-Agent.  The following client
     error status codes can be used:

     *  400 Bad Request: if the pledge detects an error in the format of
        the request.

     *  403 Forbidden: if the signature of the registrar cannot be
        verified against the installed initial trust anchor (pinned domain
        certificate).

     *  403 Forbidden: if one of the intermediate CA certificates cannot
        be verified against the available trust anchors (e.g., self-signed
        CA certificates).

     *  415 Unsupported Media Type: if the Content-Type request header
        field indicates a type that is unknown or unsupported, e.g., a
        type other than application/jose+json.

     Otherwise, if processing completes successfully, the pledge SHOULD
     reply with HTTP 200 OK without a response body.  The pledge MAY use
     the response body to signal success/failure details to the service
     technician operating the Registrar-Agent.

  7.7.1.  Request Artifact: CA-Certificates (caCerts)

     Identical to the CA-Certificates (caCerts) artifact received from the
     registrar as defined in Section 7.5.2.  The Registrar-Agent MUST NOT
     modify CA-Certificates artifacts.

  7.7.2.  Response (no artifact)

     In this exchange, the response is a result of the HTTP(S) default
     transport for this specification.  There is no artifact provided to
     the Registrar-Agent.  The pledge MAY use the response body to signal
     success/failure details to the service technician operating the
     Registrar-Agent.  While BRSKI-PRM does not specify which content may
     be provided in the response body, it is recommended to provided it as
     JSON encoded information as other BRSKI-PRM exchanges also utilize
     this encoding.




  Fries, et al.            Expires 5 December 2025               [Page 67]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.8.  Supply Enroll-Response to Pledge (ser)

     After supplying the CA certificates, the Registrar-Agent supplies the
     pledge EE certificate to the pledge.

     TLS MAY be used to provide privacy for this exchange between the
     Registrar-Agent and the pledge (see Appendix B).

     Figure 36 shows the provisioning of the domain-owner signed EE
     certificate to the pledge and the following subsections describe the
     corresponding artifacts.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (8) Supply Enroll-Response to Pledge
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<---Enroll-Resp---|                 |                 |            |
    |-----eStatus----->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                    Figure 36: Enroll-Response exchange

     The Registrar-Agent SHALL send the domain-owner signed EE certificate
     to the pledge by HTTP(S) POST to the pledge endpoint at /.well-
     known/brski/ser.  The request body MUST contain the Enroll-Response
     (Enroll-Resp) artifact previously acquired from the domain registrar
     as defined in Section 7.4.2.  In the request header, the Content-Type
     field MUST be set to application/pkcs7-mime with an smime-type
     parameter certs-only, as specified in [RFC7030] and [RFC5273], and
     the Accept field SHOULD be set to application/jose+json.

     Upon reception, the pledge SHALL verify the received EE certificate
     using the installed trust anchors.  After Enroll-Resp validation and
     verification, the pledge needs to reply with a status telemetry
     message as defined in Section 5.9.4 of [RFC8995].  The pledge MUST
     generate the Enroll Status (eStatus) artifact as defined in
     Section 7.8.2 and MUST provide it to the Registrar-Agent in the body
     of an HTTP 200 OK response.  In the response header, the Content-Type
     field MUST be set to application/jose+json.





  Fries, et al.            Expires 5 December 2025               [Page 68]


  Internet-Draft                  BRSKI-PRM                      June 2025


     If the pledge is unable to validate or verify the Enroll-Response, it
     MUST report the reason in the corresponding field of the Enroll
     Status.

  7.8.1.  Request Artifact: Enroll-Response (Enroll-Resp)

     Identical to the Enroll-Response (Enroll-Resp) artifact received from
     the registrar as defined in Section 7.4.2.  The Registrar-Agent MUST
     NOT modify Enroll-Response artifacts.

  7.8.2.  Response Artifact: Enroll Status (eStatus)

     The Enroll Status (eStatus) artifact SHALL be an authenticated self-
     contained object signed by the pledge, containing status telemetry as
     defined in Section 5.9.4 of [RFC8995].

     For the JWS-signed JSON format used by this specification, the
     eStatus artifact MUST use the "General JWS JSON Serialization Syntax"
     defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
     Enroll Status Data defined in Section 7.8.2.1 in the JWS Payload.
     Figure 37 summarizes the serialization of the JWS-signed JSON eStatus
     artifact:

     {
       "payload": BASE64URL(UTF8(JSON Enroll Status Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

             Figure 37: eStatus Representation in General JWS JSON
                              Serialization Syntax

     The JSON Enroll Status Data MUST be UTF-8 encoded to become the
     octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
     further base64url-encoded to become the string value of the payload
     member as described in Section 3.2 of [RFC7515].  The octets of the
     UTF-8 representation of the JWS Protected Header are base64url-
     encoded to become the string value of the protected member.  The
     generated JWS Signature is base64url-encoded to become the string
     value of the signature member.







  Fries, et al.            Expires 5 December 2025               [Page 69]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.8.2.1.  JSON Enroll Status Data

     The JSON Status Data SHALL be a JSON document [RFC8259] that MUST
     conform with the enrollstatus-post CDDL [RFC8610] data model defined
     in Section 5.9.4 of [RFC8995].  The members are the same as for the
     JSON Voucher Status Data and follow the same definitions as given in
     Section 7.6.2.1 (including making reason-context mandatory).

     BRSKI-PRM implementations again utilize the reason-context field to
     provide a distinguishable token.  For eStatus artifacts, the JSON
     object in the reason-context field MUST contain the member pes-
     details.

     Figure 38 below shows an example for the JSON Enroll Status Data in
     case of success and Figure 39 in case of failure:

     {
       "version": 1,
       "status": true,
       "reason": "Enroll-Response successfully processed.",
       "reason-context": {
         "pes-details": "Successfully enrolled"
       }
     }

               Figure 38: JSON Enroll Status Data Success Example

     {
       "version": 1,
       "status": false,
       "reason": "Enroll-Response could not be verified.",
       "reason-context": {
         "pes-details": "No matching trust anchor"
       }
     }

               Figure 39: JSON Enroll Status Data Failure Example

  7.8.2.2.  JWS Protected Header

     The JWS Protected Header of the eStatus artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]






  Fries, et al.            Expires 5 December 2025               [Page 70]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  x5c: SHALL contain the base64-encoded pledge EE certificate used
        to sign the eStatus artifact and it SHOULD also contain the
        certificate chain for this certificate.  The certificate chain
        MUST be available for certificate verification.  If it is not
        contained in the x5c Header Parameter it is provided to the
        relying party by other means such as configuration.

     Figure 40 below shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }

             Figure 40: JWS Protected Header Example within eStatus

  7.8.2.3.  JWS Signature

     If the pledge verified the received EE certificate successfully, it
     MUST sign the eStatus artifact using its new EE credentials.  In
     failure case, the pledge MUST sign it using its IDevID credentials.
     The JWS Signature is generated over the JWS Protected Header and the
     JWS Payload as described in Section 5.1 of [RFC7515].  Algorithms
     used for JWS signatures MUST support ES256 as recommended in
     [RFC7518] and MAY support further algorithms.

  7.9.  Voucher Status Telemetry (including MASA interaction)

     Once the Registrar-Agent has collected both status artifacts from one
     or more pledges, it SHALL provide the status information to the
     domain registrar for further processing, beginning with the voucher
     status telemetry.

     In case the TLS session to the registrar is closed, the Registrar-
     Agent establishes a new session as described in Section 7.3.

     Figure 41 shows the provisioning of the voucher status information
     from the pledge(s) to the registrar and the following subsections
     describe the corresponding artifact and MASA interaction.









  Fries, et al.            Expires 5 December 2025               [Page 71]


  Internet-Draft                  BRSKI-PRM                      June 2025


   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (9) Voucher Status Telemetry (including backend interaction)
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<---((mTLS))---->|                 |            |
    |                  |-----vStatus---->|                 |            |
    |                  |                 |<----------((mTLS))---------->|
    |                  |                 |-----req device audit-log---->|
    |                  |                 |<------device audit-log-------|
    |                  |                 |                 |            |
    |                  |        [verify audit-log]         |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                Figure 41: Voucher Status telemetry exchange

     First, the Registrar-Agent SHALL supply the voucher status telemetry
     to the registrar via HTTP-over-TLS POST to the registrar endpoint at
     /.well-known/brski/voucher_status.  The request body MUST contain one
     previously acquired vStatus artifact as defined in Section 7.6.2.  In
     the request header, the Content-Type field MUST be set to
     application/jose+json.

     Upon receiving a vStatus artifact, the registrar MUST process it as
     described in Section 5.7 of [RFC8995].  Due to the Registrar-Agent in
     the middle, the registrar MUST in addition verify the signature of
     the vStatus and that it belongs to an accepted device of the domain
     based on the serial-number field of the IDevID certificate contained
     in the JWS Protected Header of the vStatus.

     According to Section 5.7 of [RFC8995], the registrar responds with an
     HTTP 200 OK without a response body in the success case or fail with
     an HTTP error status code.  The registrar MAY use the response body
     to signal success/failure details to the service technician operating
     the Registrar-Agent.

     The registrar SHOULD proceed with the audit-log request to the MASA
     as in BRSKI described in Section 5.8 of [RFC8995].








  Fries, et al.            Expires 5 December 2025               [Page 72]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.9.1.  Request Artifact: Voucher Status (vStatus)

     Identical to the Voucher Status (vStatus) artifact received from the
     pledge as defined in Section 7.6.2.  The Registrar-Agent MUST NOT
     modify vStatus artifacts.

  7.9.2.  Response (no artifact)

     In this exchange, the response is a result of the HTTP(S) default
     transport for this specification.  There is no artifact provided to
     the Registrar-Agent.

  7.10.  Enroll Status Telemetry

     The Registrar-Agent SHALL complete the sequence of exchanges for
     bootstrapping with providing the enroll status telemetry to the
     domain registrar.  This status indicates whether the pledge could
     process the Enroll-Response (pledge EE certificate signed by the
     domain owner) and holds the corresponding private key.

     In case the TLS session to the registrar is already closed, the
     Registrar-Agent establishes a new session as described in
     Section 7.3.

     Figure 42 shows the provisioning of the enroll status information
     from the pledge(s) to the registrar and the following subsections
     describe the corresponding artifact.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (10) Enroll Status Telemetry
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |                  |<---((mTLS))---->|                 |            |
    |                  |-----eStatus---->|                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                Figure 42: Enroll Status telemetry exchange








  Fries, et al.            Expires 5 December 2025               [Page 73]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The Registrar-Agent SHALL supply the enroll status telemetry to the
     registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-
     known/brski/enrollstatus.  The request body MUST contain one
     previously acquired eStatus artifact as defined in Section 7.8.2.  In
     the request header, the Content-Type field MUST be set to
     application/jose+json.

     Upon receiving an eStatus artifact, the registrar MUST process it as
     described in Section 5.9.4 of [RFC8995].  Due to the Registrar-Agent
     in the middle, instead of the BRSKI TLS session with the pledge, the
     registrar MUST verify the signature of the eStatus artifact and that
     it belongs to an accepted device of the domain based on the serial-
     number field of the EE certificate contained in the JWS Protected
     Header of the eStatus.  Note that if the Enroll Status indicates
     success, the eStatus artifact is signed with the new pledge EE
     credentials; if it indicates failure, the pledge was unable to
     process the supplied EE certificate and therefore signed with its
     IDevID credentials.

     According to Section 5.9.4 of [RFC8995], the registrar responds with
     an HTTP 200 OK in the success case or can fail with an HTTP 404
     client error status code.  The registrar MAY use the response body to
     signal success/failure details to the service technician operating
     the Registrar-Agent.

     If the eStatus indicates failure, the registrar MAY decide that for
     security reasons the pledge is not allowed to reside in the domain.
     In this case, the registrar MUST revoke the pledge EE certificate.
     An example case for the registrar revoking the issued certificate is
     when the pledge was not able to verify the received EE certificate
     and therefore did not accept it for installation.

  7.10.1.  Request Artifact: Enroll Status (eStatus)

     Identical to the Enroll Status (eStatus) artifact received from the
     pledge as defined in Section 7.8.2.  The Registrar-Agent MUST NOT
     modify eStatus artifacts.

  7.10.2.  Response (no artifact)

     In this exchange, the response is a result of the HTTP(S) default
     transport for this specification.  There is no artifact provided to
     the Registrar-Agent.








  Fries, et al.            Expires 5 December 2025               [Page 74]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.11.  Query Pledge Status (qps)

     The following assumes that a Registrar-Agent may need to query the
     overall status of a pledge.  This information can be useful to solve
     errors, when the pledge was not able to connect to the target domain
     during bootstrapping.  A pledge MAY omit the dedicated endpoint for
     the Query Pledge Status operation (see Section 6.2).

     TLS MAY be used to provide privacy for this exchange between the
     Registrar-Agent and the pledge (see Appendix B).

     Figure 43 shows the query and response for the overall pledge status
     and the following subsections describe the corresponding artifacts.

   +--------+    +------------+    +-----------+    +--------+    +------+
   | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
   |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
   +--------+    +------------+    +-----------+    +--------+    +------+
    |                  |                 |                 |   Internet |
    ~                  ~                 ~                 ~            ~
   (11) Query Pledge Status
    ~                  ~                 ~                 ~            ~
    |                  |                 |                 |            |
    |<----opt. TLS---->|                 |                 |            |
    |<-----tStatus-----|                 |                 |            |
    |------pStatus---->|                 |                 |            |
    |                  |                 |                 |            |
    ~                  ~                 ~                 ~            ~

                     Figure 43: Pledge Status exchange

     The Registrar-Agent SHALL query the pledge via HTTP(S) POST to the
     pledge endpoint at /.well-known/brski/qps.  The request body MUST
     contain the Status Trigger (tStatus) artifact as defined in
     Section 7.11.1.  In the request header, the Content-Type field MUST
     be set to application/jose+json and the Accept field SHOULD be set to
     application/jose+json.

     If the pledge implements the Query Pledge Status endpoint, it MUST
     first verify the signature of the tStatus artifact using its trust
     anchors.  If the pledge does not possess any domain trust anchor yet,
     it MAY skip the signature verification and choose to reply without
     it.  In the case of success, it MUST reply with the Pledge Status
     (pStatus) artifact as defined in Section 7.11.2 in the body of an
     HTTP 200 OK response.  In the response header, the Content-Type field
     MUST be set to application/jose+json.





  Fries, et al.            Expires 5 December 2025               [Page 75]


  Internet-Draft                  BRSKI-PRM                      June 2025


     If the pledge is unable to create the pStatus artifact, the pledge
     responds with an HTTP error status code to the Registrar-Agent.  The
     following client error status codes can be used:

     *  400 Bad Request: if the pledge detects an error in the format of
        the request.

     *  403 Forbidden: if the signature of the Registrar-Agent cannot be
        verified using the installed trust anchors.

     *  406 Not Acceptable: if the Accept request header field indicates a
        type that is unknown or unsupported, e.g., a type other than
        application/jose+json.

     *  415 Unsupported Media Type: if the Content-Type request header
        field indicates a type that is unknown or unsupported, e.g., a
        type other than application/jose+json.

     The pledge MAY use the response body to signal failure details to the
     service technician operating the Registrar-Agent.

  7.11.1.  Request Artifact: Status Trigger (tStatus)

     The Status Query (tStatus) artifact SHALL be an authenticated self-
     contained object signed by the pledge, providing status query
     parameters.

     For the JWS-signed JSON format used by this specification, the
     tStatus artifact MUST use the "General JWS JSON Serialization Syntax"
     defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
     Status Trigger Data defined in Section 7.11.1.1 in the JWS Payload.
     Figure 44 summarizes the serialization of the JWS-signed JSON PER
     artifact:

     {
       "payload": BASE64URL(UTF8(JSON Status Trigger Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

             Figure 44: tStatus Representation in General JWS JSON
                              Serialization Syntax





  Fries, et al.            Expires 5 December 2025               [Page 76]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The JSON Status Trigger Data MUST be UTF-8 encoded to become the
     octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
     further base64url-encoded to become the string value of the payload
     member as described in Section 3.2 of [RFC7515].  The octets of the
     UTF-8 representation of the JWS Protected Header are base64url-
     encoded to become the string value of the protected member.  The
     generated JWS Signature is base64url-encoded to become the string
     value of the signature member.

  7.11.1.1.  JSON Status Trigger Data

     The JSON Status Trigger Data SHALL be a JSON document [RFC8259] that
     MUST conform with the CDDL [RFC8610] data model defined in Figure 45:

       statustrigger = {
           "version": uint,
           "serial-number": text,
           "created-on": tdate,
           "status-type": $status-type
       }

       $status-type /= "bootstrap"
       $status-type /= "operation"

          Figure 45: CDDL for JSON Status Trigger Data (statustrigger)

     The version member is included to permit significant changes to the
     pledge status artifacts in the future.  The format and semantics in
     this document follow the status telemetry definitions of [RFC8995].
     Hence, the version SHALL be set to 1.  A pledge (or Registrar-Agent)
     that receives a version larger than it knows about SHOULD log the
     contents and emit an operational notification.

     The serial-number member SHALL contain the product-serial-number
     corresponding to the X520SerialNumber field of the pledge IDevID
     certificate; it can be correlated with the product-serial-number in
     the signing certificate contained in the JWS Protected Header of the
     Pledge Status response artifact.

     The created-on member SHALL contain the current date and time at
     tStatus creation as standard date/time string as defined in
     Section 5.6 of [RFC3339]; it can be used as reference time for the
     corresponding Pledge Status response artifact after correlating via
     the product-serial-number; note that pledges may not have
     synchronized time to provide the created-on date and time on their
     own.





  Fries, et al.            Expires 5 December 2025               [Page 77]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The status-type allows for specifying which status information is to
     be returned.  As shown in Figure 45, BRSKI-PRM defines two
     enumeration values:

     *  bootstrap to query current status information regarding the
        bootstrapping status (e.g., voucher processing and enrollment of
        the pledge into a domain).

     *  operation to query current status information regarding the
        operational status (e.g., utilization of the bootstrapped EE
        credentials in communication with other peers).

     Other specifications using this artifact may define further
     enumeration values, e.g., to query application-related status.

     Figure 46 shows an example for the JSON Status Trigger Data using the
     status type bootstrap:

     {
       "version": 1,
       "created-on": "2025-01-12T02:37:39.235Z",
       "serial-number": "vendor-pledge4711",
       "status-type": "bootstrap"
     }

                  Figure 46: JSON Status Trigger Data Example

  7.11.1.2.  JWS Protected Header

     The JWS Protected Header of the tStatus artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

     *  x5c: SHALL contain the base64-encoded Registrar-Agent EE
        certificate used to sign the tStatus artifact as well as the
        certificate chain

     Figure 47 shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }



  Fries, et al.            Expires 5 December 2025               [Page 78]


  Internet-Draft                  BRSKI-PRM                      June 2025


             Figure 47: JWS Protected Header Example within tStatus

  7.11.1.3.  JWS Signature

     The Registrar-Agent MUST sign the tStatus artifact using its EE
     credentials.  The JWS Signature is generated over the JWS Protected
     Header and the JWS Payload as described in Section 5.1 of [RFC7515].
     Algorithms used for JWS signatures MUST support ES256 as recommended
     in [RFC7518] and MAY support further algorithms.

  7.11.2.  Response Artifact: Pledge Status (pStatus)

     The Pledge Status (pStatus) artifact SHALL be an authenticated self-
     contained object signed by the pledge, containing status telemetry
     information.  The exact content depends on the Status Trigger
     parameter status-type.

     For the JWS-signed JSON format used by this specification, the
     pStatus artifact MUST use the "General JWS JSON Serialization Syntax"
     defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
     Pledge Status Data defined in Section 7.11.2.1 in the JWS Payload.
     Figure 48 summarizes the serialization of the JWS-signed JSON PER
     artifact:

     {
       "payload": BASE64URL(UTF8(JSON Pledge Status Data)),
       "signatures": [
         {
           "protected": BASE64URL(UTF8(JWS Protected Header)),
           "signature": BASE64URL(JWS Signature)
         }
       ]
     }

             Figure 48: pStatus Representation in General JWS JSON
                              Serialization Syntax

     The JSON Pledge Status Data MUST be UTF-8 encoded to become the
     octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
     further base64url-encoded to become the string value of the payload
     member as described in Section 3.2 of [RFC7515].  The octets of the
     UTF-8 representation of the JWS Protected Header are base64url-
     encoded to become the string value of the protected member.  The
     generated JWS Signature is base64url-encoded to become the string
     value of the signature member.






  Fries, et al.            Expires 5 December 2025               [Page 79]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.11.2.1.  JSON Pledge Status Data

     The JSON Pledge Status Data SHALL be a JSON document [RFC8259] that
     MUST conform with the CDDL [RFC8610] data model defined in Figure 49,
     which has the same members as the voucherstatus-post CDDL defined in
     Section 5.7 of [RFC8995] and the enrollstatus-post CDDL defined in
     Section 5.9.4 of [RFC8995].

       pledgestatus = {
         "version": uint,
         "status": bool,
         ?"reason" : text,
         "reason-context": { * $$arbitrary-map }
       }

           Figure 49: CDDL for JSON Pledge Status Data (pledgestatus)

     The version member follows the definition in Section 7.11.1.1 (same
     as in JSON Status Query Data).

     The reason and reason-context members follow the definitions in
     Section 7.6.2.1, i.e., in contrast to [RFC8995], reason-context MUST
     be provided.

     The new pStatus artifact also utilizes the reason-context field to
     provide a distinguishable token.  For pStatus artifacts, the JSON
     object in the reason-context field MUST contain either the

     *  pbs-details member for status information corresponding to the
        status-type bootstrap, or the

     *  pos-details member for status information corresponding to the
        status-type operation (see Section 7.11.1.1)

     Other documents may add additional reason-context members correlating
     to other statustrigger status-types or to include further status
     information.

     For the pbs-details member, the following values with the given
     semantics are defined, while additional information MAY be provided
     in the top-level reason member:

     *  factory-default: Pledge has not been bootstrapped.  The pledge
        signs the response message using its IDevID certificate/
        credentials.






  Fries, et al.            Expires 5 December 2025               [Page 80]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  voucher-success: Pledge processed the voucher exchange
        successfully.  The pledge signs the response message using its
        IDevID certificate/credentials.

     *  voucher-error: Pledge voucher processing terminated with error.
        Additional information may be provided in the reason or reason-
        context members.  The pledge signs the response message using its
        IDevID certificate/credentials.

     *  enroll-success: Pledge processed the enrollment exchange
        successfully.  Additional information may be provided in the
        reason or reason-context members.  The pledge signs the response
        message using its domain-owner signed EE certificate/credentials.

     *  enroll-error: Pledge enrollment-response processing terminated
        with error.  Additional information may be provided in the reason
        or reason-context members.  The pledge signs the response message
        using its IDevID certificate/credentials.

     The pbs-details values SHALL be cumulative in the sense that enroll-
     success and enroll-error imply voucher-success.  Figure 50 below
     provides an example for bootstrap status information in the JSON
     Pledge Status Data:

     {
       "version": 1,
       "status": true,
       "reason": "Pledge processed enrollment exchange successfully.",
       "reason-context": {
         "pbs-details": "enroll-success"
       }
     }

          Figure 50: status-bootstrap JSON Pledge Status Data Example

     For the pos-details member, the following values with the given
     semantics are defined, while additional information MAY be provided
     in the top-level reason member:

     *  connect-success: Pledge could successfully establish a connection
        to another peer.  The pledge signs the response message using its
        domain-owner signed EE certificate/credentials.

     *  connect-error: Pledge connection establishment terminated with
        error.  The pledge signs the response message using its domain-
        owner signed EE certificate/credentials.





  Fries, et al.            Expires 5 December 2025               [Page 81]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Figure 51 provides an example for operational status information in
     the JSON Pledge Status Data:

     {
       "version": 1,
       "status": false,
       "reason": "TLS certificate could not be verified.",
       "reason-context": {
         "pos-details" : "connect-error"
       }
     }

          Figure 51: status-operation JSON Pledge Status Data Example

  7.11.2.2.  JWS Protected Header

     The JWS Protected Header of the pStatus artifact MUST contain the
     following standard Header Parameters as defined in [RFC7515]:

     *  alg: SHALL contain the algorithm type used to create the
        signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

     *  x5c: SHALL contain the base64-encoded pledge EE certificate used
        to sign the pStatus artifact and it SHOULD also contain the
        certificate chain for this certificate The certificate chain MUST
        be available for certificate verification.  If it is not contained
        in the x5c Header Parameter it is provided to the relying party by
        other means such as configuration.

     Figure 52 shows an example for this JWS Protected Header:

     {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ]
     }

             Figure 52: JWS Protected Header Example within pStatus











  Fries, et al.            Expires 5 December 2025               [Page 82]


  Internet-Draft                  BRSKI-PRM                      June 2025


  7.11.2.3.  JWS Signature

     The pledge MUST sign the tStatus artifact using its IDevID or domain-
     owner signed EE credentials according to its bootstrapping status as
     defined in Section 7.11.2.1.  The JWS Signature is generated over the
     JWS Protected Header and the JWS Payload as described in Section 5.1
     of [RFC7515].  Algorithms used for JWS signatures MUST support ES256
     as recommended in [RFC7518] and MAY support further algorithms.

  8.  Logging Considerations

     The registrar SHOULD log certain events to provide an audit trail for
     the onboarding of pledges into its domain.  This audit trail may
     support the root cause analysis in case of device or system failures.
     Recommend key events for logging comprise:

     *  Communication attempts between the pledge, Registrar-Agent, and
        registrar.

     *  Protocol handshakes and onboarding steps.

     *  Voucher requests and responses.

     *  Authentication successes or failures.

     The logging SHOULD include the identity of the pledge, the identity
     of the Registrar-Agent that was interacting with the pledge, and
     relevant artifact fields, in particular telemetry information:

     *  PVR received from Registrar-Agent

     *  Acceptance of a pledge into the domain

     *  Voucher provided to Registrar-Agent

     *  PER received from Registrar-Agent

     *  Pledge EE certificate requested

     *  Pledge EE certificate received from Domain CA

     *  Pledge EE certificate provided to Registrar-Agent

     *  CA Certificates provided to Registrar-Agent

     *  Voucher Status received from Registrar-Agent

     *  Enroll Status received from Registrar-Agent



  Fries, et al.            Expires 5 December 2025               [Page 83]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Pledge Status received from Registrar-Agent

     *  Pledge EE certificate revoked

     Furthermore, it is recommended to:

     *  support adjustable logging levels (severity) to cater to different
        operational needs or failure situations.

     *  include meta information to distinguish logs that relate to
        different BRSKI approaches (e.g., BRSKI, BRSKI-AE, BRSKI-PRM,
        constraint BRSKI) that are likely supported in the same domain in
        parallel.

     *  include detailed error codes and diagnostics information as
        defined throughout the document or stemming from other used
        components or libraries also in the logging information.

     *  support synchronized time (e.g., via NTP) to include timestamps in
        logging to enable sequencing and correlation of events.

     *  utilize standard logging formats (e.g., syslog) to allow for easy
        integration into log analysis tools and SIEM systems.

     *  utilize secure transmission of logs to centralized log servers,
        particularly in cloud or distributed environments (e.g., in case
        of syslog, [RFC9662] updates the utilized cipher suites for TLS
        and DTLS).

     *  allow for definition of key operational thresholds (e.g., high
        latency, failed onboarding attempts) to trigger alerts for
        proactive issue resolution.

     *  avoid inclusion of sensitive information (see also Section 11)

     For log analysis the following may be considered:

     *  The registrar knows which Registrar-Agent collected which PVR from
        the included agent-signed-data object.

     *  The registrar always knows the connecting Registrar-Agent from the
        TLS client authentication using the Registrar-Agent EE certificate
        and can log it accordingly.








  Fries, et al.            Expires 5 December 2025               [Page 84]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  The telemetry information from the pledge can be correlated to the
        voucher through the product-serial-number in the EE certificate
        contained in the JWS Protected Header of the status artifacts and
        the product-serial-number contained in the voucher.  By this it
        can also be related to the PER.

     With this, it can for instance be analyzed if multiple Registrar-
     Agents are involved in bootstrapping devices.  In addition, within
     the domain it can be analyzed, if the onboarding involved different
     Registrar-Agents or if different registrars have been used.

     In order to protect the registrar from overload attacks, a rate-
     limiting may be used by logging events from the same type just once.

  9.  Operational Considerations

     As outlined in Section 5, BRSKI-PRM introduces an additional
     component with the Registrar-Agent in the BRSKI architecture in
     addition to new modes of interaction to facilitate the communication
     between the pledge and the registrar.  As outlined in Section 5.3 the
     functional support of BRSKI-PRM can also be achieved using a
     Registrar-Agent co-located with the Registrar instead of a stand-
     alone Registrar-Agent, which may reduce operational complexity.

     This has an influence on the configuration and operation not only of
     the Registrar-Agent, but also for the registrar and the pledge.

     As outlined in Section 6, there are additional configuration items
     dues to the introduction of the Registrar-Agent.  This may increase
     operational complexity and potential misconfigurations in deploying
     and managing this entity:

     *  A Registrar-Agent needs to be provided with a Registrar-Agent EE
        certificate, the domain registrar EE certificate and the list of
        pledges.  BRSKI-PRM is open regarding the selected provisioning
        method, which may be automated or by configuration.

     *  Pledges may support either BRSKI-PRM only or combined with other
        modes of operation.

     *  Registrars may support either BRSKI-PRM only or combined with
        other BRSKI modes of operation.  The distinction of BRSKI and
        BRSKI-PRM is done based on the provided endpoints of the
        registrar.  An operator deploying pledges with a mixed set of
        operation need to ensure that the domain registrar supports all
        necessary options to ensure bootstrapping of pledges depending of
        the supported operational mode.




  Fries, et al.            Expires 5 December 2025               [Page 85]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  In addition, registrars may support a co-located Registrar-Agent,
        if nomadic operation of the Registrar-Agent is not required.  This
        facilitates situations in which an operator wants to deploy BRSKI
        pledges acting as clients and BSKI pledges acting as servers.

     With the Registrar-Agent enhancement a new component is introduced in
     the communication path between the pledge and the registrar.  This
     likely increases the latency of the communication between the pledge
     and the registrar.  The increase in latency due to this additional
     component may be neglected given that the Registrar-Agent operates
     with nomadic connectivity as outlined in Section 5.2.

     BRSKI-PRM requires pledges to possess an IDevID to enable onboarding
     in new domains.  IDevID (and corresponding trust anchors) are
     expected to have a rather long lifetime.  This may allow for a longer
     period between device acquisition and initial onboarding.  Contrary,
     if devices that have been provided with an LDevID (and corresponding
     trust anchors) and temporarily taken out of service, immediate
     connectivity when bringing them back to operation may not be given,
     as the LDevIDs typically have a much shorter validity period compared
     to IDevIDs.  It is therefore recommended to onboard them as new
     devices to ensure they possess valid LDevIDs.

     The key infrastructure as part of the customer domain discussed in
     Section 5 may be operated locally by the operator of that domain or
     may be provided as a third party service.

     Requirements to the utilized credentials authenticating and artifact
     signatures on the registrar as outlined in Section 6.3 may have
     operational implications when the registrar is part of a scalable
     framework as described in Section 1.3.1 of
     [I-D.richardson-anima-registrar-considerations].

     Besides the above, also consider the existing document on operational
     modes for BRSKI MASA in [I-D.richardson-anima-masa-considerations].

  10.  IANA Considerations

     This document requires the following IANA actions.

  10.1.  BRSKI Well-Known URIs

     IANA is requested to enhance the Registry entitled: "BRSKI Well-Known
     URIs" with the following endpoints:







  Fries, et al.            Expires 5 December 2025               [Page 86]


  Internet-Draft                  BRSKI-PRM                      June 2025


       +================+==================================+===========+
       | Path Segment   | Description                      | Reference |
       +================+==================================+===========+
       | requestenroll  | Supply PER to registrar          | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | wrappedcacerts | Obtain wrapped CA certificates   | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | tpvr           | Trigger Pledge Voucher-Request   | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | tper           | Trigger Pledge Enroll-Request    | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | svr            | Supply voucher to pledge         | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | scac           | Supply CA certificates to pledge | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | ser            | Supply Enroll-Response to pledge | [THISRFC] |
       +----------------+----------------------------------+-----------+
       | qps            | Query pledge status              | [THISRFC] |
       +----------------+----------------------------------+-----------+

                    Table 5: BRSKI Well-Known URIs Additions

  10.2.  Service Name and Transport Protocol Port Number Registry

     IANA is requested to register the following service names:

     *Service Name:* brski-pledge
     *Transport Protocol(s):* tcp
     *Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org)
     *Contact:* IETF Chair chair@ietf.org (mailto:chair@ietf.org)
     *Description:* The Bootstrapping Remote Secure Key Infrastructure
     Pledge
     *Reference:* [THISRFC]

  11.  Privacy Considerations

     The privacy considerations of [RFC8995] also apply for BRSKI-PRM.
     Two architectural changes in this document require some additional
     consideration:

     *  the introduction of the additional component Registrar-Agent

     *  no TLS between Registrar-Agent and pledge

     As logging is recommended to better handle failure situations, it is
     necessary to avoid capturing sensitive or personal data.  Privacy-
     preserving measures in logs SHOULD be applied, such as:




  Fries, et al.            Expires 5 December 2025               [Page 87]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Avoid logging personally identifiable information unless
        unavoidable.

     *  Anonymize or pseudonymize data where possible.

  11.1.  Registrar-Agent identity Privacy Considerations

     The credentials used by the Registrar-Agent to sign the data for the
     pledge SHOULD NOT contain any personal information about the owner/
     operator of the Registar-Agent.  So for instance, issuing an EE
     certificate to the Registrar-Agent that has a Subject DN saying
     something like "Frank Jones' Commissioning Tablet" would be a
     problem.

     Therefore, it is recommended to use an EE certificate associated with
     the commissioning device instead of an EE certificate associated with
     the service technician operating the device.  This avoids revealing
     potentially included personal information to any eavesdroppers on the
     Registrar-Agent/Pledge communication.  Along the Registrar-Agent/
     Registrar communication path, if TLS 1.2 is used, the client
     certificate details will be revealed to any on path passive attacker.
     This is one of the advantages of using TLS 1.3.

  11.2.  Registar-Agent/Pledge communications

     The communication between the pledge and the Registrar-Agent is
     performed over plain HTTP.  HTTPS can not be easily used as the
     Pledge's long-term IDevID certificate does not contain a
     SubjectAltName that [RFC9525] DNS-ID verification can use to validate
     the certificate.  In order for this connection to be more secure, the
     Registrar-Agent would need to know precisely which devices (down to
     the serial number) it expects to onboard.  There are some very
     constrained cases where this might be the case, but for many
     installations, it is not practical.

     An active on-path attacker [onpath] could trivially impersonate the
     Pledge at the network layer, which is exactly the same situation when
     not using TLS.  For many installations, a physical cable may be
     invoved (such as ethernet over USB), or a very low power wireless
     network will be used.  Any active on-path attacker would have to be
     physically present at the site of the device.  Such a physically
     present attacker could learn the identity of the Pledge by simply
     pretending to be a Registrar-Agent, and asking the device for its
     identity.  It could equally do this over TLS/HTTPS.







  Fries, et al.            Expires 5 December 2025               [Page 88]


  Internet-Draft                  BRSKI-PRM                      June 2025


     It is impossible for an active on-path attacker to replace the signed
     objects that the Pledge and Registrar-Agent exchange undetected
     because those objects are signed by keys contained in the respective
     devices.

     Depending on the requests and responses, the following information is
     disclosed:

     *  the Pledge product-serial-number is contained in the trigger
        message for the PVR and in all responses from the pledge.  This
        information reveals the identity of the devices being bootstrapped
        and allows deduction of which products an operator is using in
        their environment.  As the communication between the pledge and
        the Registrar-Agent may be realized over wireless link, this
        information could easily be eavesdropped, if the wireless network
        is not encrypted.  Even if the wireless network is encrypted, if
        it uses a network-wide key, then layer-2 attacks (ARP/ND spoofing)
        could insert an on-path observer into the path.

     *  the Timestamp data could reveal the activation time of the device.

     *  the Status data of the device could reveal information about the
        current state of the device in the domain network.

     Section 7.1 describes to optionally apply TLS to protect the
     communication between the Registrar-Agent and the pledge.  The
     following is therefore applicable to the communication without the
     TLS protection.

  12.  Security Considerations

     In general, the security considerations of [RFC8995] apply for BRSKI-
     PRM also.  Further security aspects are considered in the following
     subsections related to:

     *  the introduction of the additional component Registrar-Agent and
        related attack options.

     *  the reversal of the pledge communication direction (push mode,
        compared to BRSKI).

     *  no usage of TLS between Registrar-Agent and pledge and the
        resulting impact on transport of sensitive information (see
        Section 7.1 regarding optional use of TLS to protect the
        communication between the Registrar-Agent and the pledge)






  Fries, et al.            Expires 5 December 2025               [Page 89]


  Internet-Draft                  BRSKI-PRM                      June 2025


  12.1.  Denial of Service (DoS) Attack on Pledge

     Disrupting the pledge behavior by a DoS attack may prevent the
     bootstrapping of the pledge to a new domain.  Because in BRSKI-PRM
     the pledge responds to requests from real or illicit Registrar-
     Agents, pledges are more subject to DoS-attacks from Registrar-Agents
     in BRSKI-PRM than they are from illicit registrars in [RFC8995],
     where pledges do initiate the connections.

     A DoS attack with a faked Registrar-Agent may block the bootstrapping
     of the pledge due changing state on the pledge (the pledge may
     produce a voucher-request, and refuse to produce another one).  One
     mitigation may be that the pledge does not limit the number of
     voucher-requests it creates until at least one has finished.  An
     alternative may be that the onboarding state may expire after a
     certain time, if no further interaction has happened.

     In addition, the pledge may assume that repeated triggering for PVR
     are the result of a communication error with the Registrar-Agent.  In
     that case the pledge MAY simply resend the PVR previously sent.  Note
     that in case of re-sending, a contained nonce and also the contained
     agent-signed-data in the PVR would consequently be reused.

  12.2.  Misuse of acquired PVR and PER by Registrar-Agent

     A Registrar-Agent that uses previously requested PVR and PER for
     domain-A, may attempt to onboard the device into domain-B.  This can
     be detected by the domain registrar while PVR processing.  The domain
     registrar needs to verify that the proximity-registrar-cert field in
     the PVR matches its own registrar EE certificate.  In addition, the
     domain registrar needs to verify the association of the pledge to its
     domain based on the product-serial-number contained in the PVR and in
     the pledge IDevID certificate.  (This is just part of the supply
     chain integration).  Moreover, the domain registrar verifies if the
     Registrar-Agent is authorized to interact with the pledge for
     voucher-requests and enroll-requests, based on the Registrar-Agent EE
     certificate data contained in the PVR.

     Mis-binding of a pledge by a faked domain registrar is countered as
     described in BRSKI security considerations Section 11.4 of [RFC8995].











  Fries, et al.            Expires 5 December 2025               [Page 90]


  Internet-Draft                  BRSKI-PRM                      June 2025


  12.3.  Misuse of Registrar-Agent

     Concerns of misuse of a Registrar-Agent with a valid Registrar-Agent
     EE certificate may be addressed by utilizing short-lived certificates
     (e.g., valid for a day) to authenticate the Registrar-Agent against
     the domain registrar.  The Registrar-Agent EE certificate may have
     been acquired by a prior BRSKI run for the Registrar-Agent, if an
     IDevID is available on Registrar-Agent.  Alternatively, the
     Registrar-Agent EE certificate may be acquired by a service
     technician from the domain PKI system in an authenticated way.

     In addition, it is required that the Registrar-Agent EE certificate
     is valid for the complete bootstrapping phase.  This avoids that a
     Registrar-Agent could be misused to create arbitrary "agent-signed-
     data" objects to perform an authorized bootstrapping of a rogue
     pledge at a later point in time.  In this misuse "agent-signed-data"
     could be dated after the validity time of the Registrar-Agent EE
     certificate, due to missing trusted timestamp in the Registrar-Agents
     signature.  To address this, the registrar SHOULD verify the
     certificate used to create the signature on "agent-signed-data".

     Furthermore, the registrar also verifies the Registrar-Agent EE
     certificate used in the TLS handshake with the Registrar-Agent.  If
     both certificates are verified successfully, the Registrar-Agent's
     signature can be considered as valid.  If the registrar detects a
     mismatch in the utilized certificates, it may conclude the usage of
     either an outdated "agent-signed-data" component in the PVR or a man-
     in-the-middle attack by a potentially unauthorized Registrar-Agent.

  12.4.  Misuse of DNS-SD with mDNS to obtain list of pledges

     To discover a specific pledge a Registrar-Agent may query the Service
     Type in combination with the product-serial-number of a specific
     pledge, e.g., in the Service Instance Name or Service Subtype.  The
     pledge reacts on this if its product-serial-number is part of the
     query message.

     If the Registrar-Agent performs DNS-based Service Discovery without a
     specific product-serial-number, all pledges in the domain react if
     the functionality is supported.  This functionality enumerates and
     reveals the information of devices available in the domain.  The
     information about this is provided here as a feature to support the
     commissioning of devices.  A manufacturer may decide to support this
     feature only for devices not possessing an LDevID or to not support
     this feature at all, to avoid an enumeration in an operative domain.






  Fries, et al.            Expires 5 December 2025               [Page 91]


  Internet-Draft                  BRSKI-PRM                      June 2025


  12.5.  YANG Module Security Considerations

     The enhanced voucher-request described in [I-D.ietf-anima-rfc8366bis]
     is based on [RFC8995], but uses a different encoding based on
     [I-D.ietf-anima-jws-voucher].  The security considerations as
     described in Section 11.7 of [RFC8995] (Security Considerations)
     apply.

     The YANG module specified in [I-D.ietf-anima-rfc8366bis] defines the
     schema for data that is subsequently encapsulated by a JOSE signed-
     data Content-type as described in [I-D.ietf-anima-jws-voucher].  As
     such, all of the YANG-modeled data is protected against modification.

     Documents that define exclusively modules following the extension in
     [RFC8971] are not required to include the YANG security template per
     guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].

  13.  Acknowledgments

     We would like to thank the various reviewers, in particular Brian E.
     Carpenter, Charlie Kaufman (Early SECDIR review), Martin Björklund
     (Early YANGDOCTORS review), Marco Tiloca (Early IOTDIR review), Oskar
     Camenzind, Hendrik Brockhaus, and Ingo Wenda for their input and
     discussion on use cases and call flows.  Further review input was
     provided by Jesser Bouzid, Dominik Tacke, Christian Spindler, and
     Julian Krieger.  Special thanks to Esko Dijk for the in deep review
     and the improving proposals.  Another special thanks for the detailed
     Shepherad review and connected discussions to Matthias Kovatsch.
     Support in PoC implementations and comments resulting from the
     implementation was provided by Hong Rui Li and He Peng Jia. Review
     comments in the context of a formal analysis of BRSKI-PRM have been
     provided by Marco Calipari.

  14.  References

  14.1.  Normative References

     [I-D.ietf-anima-jws-voucher]
                Werner, T. and M. Richardson, "JWS signed Voucher
                Artifacts for Bootstrapping Protocols", Work in Progress,
                Internet-Draft, draft-ietf-anima-jws-voucher-16, 15
                January 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-anima-jws-voucher-16>.

     [I-D.ietf-anima-rfc8366bis]
                Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
                and Q. Ma, "A Voucher Artifact for Bootstrapping
                Protocols", Work in Progress, Internet-Draft, draft-ietf-



  Fries, et al.            Expires 5 December 2025               [Page 92]


  Internet-Draft                  BRSKI-PRM                      June 2025


                anima-rfc8366bis-14, 1 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                rfc8366bis-14>.

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

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/rfc/rfc3339>.

     [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC 4086,
                DOI 10.17487/RFC4086, June 2005,
                <https://www.rfc-editor.org/rfc/rfc4086>.

     [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
                (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
                <https://www.rfc-editor.org/rfc/rfc5272>.

     [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
                (CMC): Transport Protocols", RFC 5273,
                DOI 10.17487/RFC5273, June 2008,
                <https://www.rfc-editor.org/rfc/rfc5273>.

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

     [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
                DOI 10.17487/RFC6762, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6762>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6763>.

     [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
                "Enrollment over Secure Transport", RFC 7030,
                DOI 10.17487/RFC7030, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7030>.






  Fries, et al.            Expires 5 December 2025               [Page 93]


  Internet-Draft                  BRSKI-PRM                      June 2025


     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/rfc/rfc7515>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7518>.

     [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
                RFC 7951, DOI 10.17487/RFC7951, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7951>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

     [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Header Parameters for Carrying and Referencing X.509
                Certificates", RFC 9360, DOI 10.17487/RFC9360, February
                2023, <https://www.rfc-editor.org/rfc/rfc9360>.

     [RFC9646]  Watsen, K., Housley, R., and S. Turner, "Conveying a
                Certificate Signing Request (CSR) in a Secure Zero-Touch
                Provisioning (SZTP) Bootstrapping Request", RFC 9646,
                DOI 10.17487/RFC9646, October 2024,
                <https://www.rfc-editor.org/rfc/rfc9646>.

  14.2.  Informative References



  Fries, et al.            Expires 5 December 2025               [Page 94]


  Internet-Draft                  BRSKI-PRM                      June 2025


     [androidnsd]
                "Android Developer: Connect devices wirelessly", archived
                at https://web.archive.org/web/20230000000000*/https://dev
                eloper.android.com/training/connect-devices-wirelessly,
                n.d., <https://developer.android.com/training/connect-
                devices-wirelessly>.

     [androidtrustfail]
                "Security with Network Protocols", archived at https://web
                .archive.org/web/20230326153937/https://developer.android.
                com/training/articles/security-ssl, n.d.,
                <https://developer.android.com/training/articles/security-
                ssl>.

     [BRSKI-PRM-abstract]
                "Abstract BRSKI-PRM Protocol Overview", March 2022,
                <https://datatracker.ietf.org/meeting/113/materials/
                slides-113-anima-update-on-brski-with-pledge-in-responder-
                mode-brski-prm-00>.

     [I-D.draft-ietf-emu-eap-arpa]
                DeKok, A., "The eap.arpa domain and EAP provisioning",
                Work in Progress, Internet-Draft, draft-ietf-emu-eap-arpa-
                06, 29 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
                arpa-06>.

     [I-D.ietf-anima-brski-discovery]
                Eckert, T. T. and E. Dijk, "BRSKI discovery and
                variations", Work in Progress, Internet-Draft, draft-ietf-
                anima-brski-discovery-05, 21 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                brski-discovery-05>.

     [I-D.ietf-netmod-rfc8407bis]
                Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
                Authors and Reviewers of Documents Containing YANG Data
                Models", Work in Progress, Internet-Draft, draft-ietf-
                netmod-rfc8407bis-25, 5 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
                rfc8407bis-25>.

     [I-D.ietf-uta-require-tls13]
                Salz, R. and N. Aviram, "New Protocols Using TLS Must
                Require TLS 1.3", Work in Progress, Internet-Draft, draft-
                ietf-uta-require-tls13-12, 14 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
                require-tls13-12>.



  Fries, et al.            Expires 5 December 2025               [Page 95]


  Internet-Draft                  BRSKI-PRM                      June 2025


     [I-D.irtf-t2trg-taxonomy-manufacturer-anchors]
                Richardson, M., "A Taxonomy of operational security
                considerations for manufacturer installed keys and Trust
                Anchors", Work in Progress, Internet-Draft, draft-irtf-
                t2trg-taxonomy-manufacturer-anchors-09, 28 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-
                taxonomy-manufacturer-anchors-09>.

     [I-D.richardson-anima-masa-considerations]
                Richardson, M. and W. Pan, "Operational Considerations for
                Voucher infrastructure for BRSKI MASA", Work in Progress,
                Internet-Draft, draft-richardson-anima-masa-
                considerations-09, 22 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-richardson-
                anima-masa-considerations-09>.

     [I-D.richardson-anima-registrar-considerations]
                Richardson, M. and W. Pan, "Operational Considerations for
                BRSKI Registrar", Work in Progress, Internet-Draft, draft-
                richardson-anima-registrar-considerations-09, 22 January
                2025, <https://datatracker.ietf.org/doc/html/draft-
                richardson-anima-registrar-considerations-09>.

     [IEEE-802.1AR]
                Institute of Electrical and Electronics Engineers, "IEEE
                802.1AR Secure Device Identifier", IEEE 802.1AR, June
                2018.

     [onpath]   "can an on-path attacker drop traffic?", n.d.,
                <https://mailarchive.ietf.org/arch/msg/saag/
                m1r9uo4xYznOcf85Eyk0Rhut598/>.

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.

     [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
                2003, <https://www.rfc-editor.org/rfc/rfc3629>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4648>.

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.



  Fries, et al.            Expires 5 December 2025               [Page 96]


  Internet-Draft                  BRSKI-PRM                      June 2025


     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
                "Handling Long Lines in Content of Internet-Drafts and
                RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
                <https://www.rfc-editor.org/rfc/rfc8792>.

     [RFC8971]  Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S.,
                Govindan, V., and M. Mudigonda, "Bidirectional Forwarding
                Detection (BFD) for Virtual eXtensible Local Area Network
                (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8971>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8990>.

     [RFC8996]  Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
                1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
                <https://www.rfc-editor.org/rfc/rfc8996>.

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

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC9238]  Richardson, M., Latour, J., and H. Habibi Gharakheili,
                "Loading Manufacturer Usage Description (MUD) URLs from QR
                Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022,
                <https://www.rfc-editor.org/rfc/rfc9238>.

     [RFC9440]  Campbell, B. and M. Bishop, "Client-Cert HTTP Header
                Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
                <https://www.rfc-editor.org/rfc/rfc9440>.




  Fries, et al.            Expires 5 December 2025               [Page 97]


  Internet-Draft                  BRSKI-PRM                      June 2025


     [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
                Certificate Management Protocol (CMP) Profile", RFC 9483,
                DOI 10.17487/RFC9483, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9483>.

     [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
                RFC 9525, DOI 10.17487/RFC9525, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9525>.

     [RFC9662]  Lonvick, C., Turner, S., and J. Salowey, "Updates to the
                Cipher Suites in Secure Syslog", RFC 9662,
                DOI 10.17487/RFC9662, October 2024,
                <https://www.rfc-editor.org/rfc/rfc9662>.

     [RFC9733]  von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI
                with Alternative Enrollment (BRSKI-AE)", RFC 9733,
                DOI 10.17487/RFC9733, March 2025,
                <https://www.rfc-editor.org/rfc/rfc9733>.

  Appendix A.  Examples

     These examples are folded according to [RFC8792] Single Backslash
     rule.

  A.1.  Example Pledge Voucher-Request (PVR) - from Pledge to Registrar-
        Agent

     The following is an example request sent from a Pledge to the
     Registrar-Agent, in "General JWS JSON Serialization".  The message
     size of this PVR is: 2973 bytes

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

     {
       "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
     NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
     c4OSIsIm5vbmNlIjoia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbi\
     I6IjIwMjQtMDYtMjRUMDk6MDE6MjQuNTU2WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbW\
     l0eS1yZWdpc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW\
     9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQm\
     dOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd0\
     5qRTRNVEphRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVn\
     phVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibE\
     psWjJsemRISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNk\
     svaTc5b1JrSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1\
     dSZmZlV2t5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUU\
     dDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQV\
     lEVlIwUkJFRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1Wl\



  Fries, et al.            Expires 5 December 2025               [Page 98]


  Internet-Draft                  BRSKI-PRM                      June 2025


     hTQ0huSmxaMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncW\
     hrak9QUVFEQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUm\
     F1YnBDN01hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaD\
     R4SVhrMSIsImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRn\
     BZVW0xTVdGcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VV\
     hSak1teHVZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSm\
     FrbDNUV3BKZEUxRWEzUk5ha3BWVFVSVk5rNUVUVFpPVkVGMVRWUkpNVmRwU1hOSmJrNX\
     NZMjFzYUdKRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaX\
     dpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYV\
     VwVlZFZE5NMWRZYUV4V2JGWldaVzVLTTFKVVRsSlhWRlpEV2xaa2IyTXlNVVZOTW1NNV\
     NXbDNhVmxYZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrd3\
     lZVEJsY3pWZkxXZHNZVjkwTjFVME1VbFJXRmxJU1RSQlMxVldVRkZmTTFSbGQxUTFiMF\
     ZWWVVOdFVIQktaMmRyU0c1d09WTk1aVFZ1YWkxbldGbFRiMk5sT1RoeFFXSnROa0YwZF\
     MxRlIxUkxZMDVSSW4xZGZRMEsifX0",
       "signatures": [
         {
           "protected": "eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNV\
     NU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
     eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
     Q0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3\
     Q1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZ\
     RFZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRt\
     bGpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpj\
     RUVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2\
     TXgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcx\
     aGMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1C\
     YUFGRlFMak56UC9TL2tvdWpRd2pnNUU1ZnZ3Y1liTUJNR0ExVWRKUVFNTUFvR0NDc0dB\
     UVVGQndNQ01BNEdBMVVkRHdFQi93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBREJF\
     QWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnWENt\
     SkxUekVsdkQycG9LNmR4NmwxL3V5bVRuYlFERGZKbGF0dVgyUm9PRT0iXSwidHlwIjoi\
     dm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0",
           "signature": "ntAgC7GT7xIDYcHBXoYej8uIUI6WR2Iv-7T1CaR-J6-xS60D\
     iWS1-vfc5Uu5INZS1dyWZ4vVH6uaoPceRxNc8g"
         }
       ]
     }

                Figure 53: Example Pledge-Voucher-Request - PVR

  A.2.  Example Registrar Voucher-Request (RVR) - from Registrar to MASA

     The following is an example registrar-voucher-request (RVR) sent from
     the Registrar to the MASA, in "General JWS JSON Serialization".  Note
     that the previous PVR can be seen in the payload as "prior-signed-
     voucher-request".  The message size of this RVR is: 7533 bytes






  Fries, et al.            Expires 5 December 2025               [Page 99]


  Internet-Draft                  BRSKI-PRM                      June 2025


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

     {
       "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
     NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
     c4OSIsImlkZXZpZC1pc3N1ZXIiOiJCQmd3Rm9BVVZBdU0zTS85TCtTaTZORENPRGtUbC\
     svQnhocz0iLCJub25jZSI6ImtoTnlLcE10aGNjaWExclh3NDQvdlE9PSIsInByaW9yLX\
     NpZ25lZC12b3VjaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbT\
     FNV0ZwMlpGZE9iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYV\
     VrMlpYbEthR016VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1\
     pFaHJhVXhEU25wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFVMUVSWGxOZWxFeFRtcG\
     pORTlUU1hOSmJUVjJZbTFPYkVscWIybGhNbWhQWlZWMGQxUllVbTlaTWs1d1dWUkdlVm\
     RJWXpCT1F6a3lWVlF3T1VscGQybFpNMHBzV1ZoU2JGcERNWFppYVVrMlNXcEpkMDFxVV\
     hSTlJGbDBUV3BTVlUxRWF6Wk5SRVUyVFdwUmRVNVVWVEpYYVVselNXMUdibHBYTlRCTV\
     dFSjVZak5hY0ZwSFZtdE1XRUo1WWpOb2NHSlhiREJsVXpGNVdsZGtjR016VW5sWldFbD\
     BXVEpXZVdSRFNUWkphekZLVTFWSk1HRnJUa1JSVm14d1dqQkdNMU5WU2tKYU1HeElVVl\
     pvV2s1NlNtbFpiSEJPVVZjNVNGRXdUbmhTTVU1T1RrUnNRMUZWTVVSVVZWSldaVVZXTm\
     xGV1NrTmFNRFZYVVd0R2RsUlZUbkpOVkZaU1lteGFObGxXWXpGaVIwMTZWRmhvUlZaRl\
     JrMVJiV1JQVm10S1Fsa3dNVU5TYXpWM1drVmtWbVZGVWpaUlZUVkRXakExVjFGclJrNV\
     VWVXB6VlcxNGFrMHhTa1ZWVmxKQ1dsVmFNMDFJYkU1U1JWWTFWRlZTYW1Rd05YRlNWRk\
     pPVmtWd2FGSnVZM2RsYXpGRlVsaHNUbEpIVGpOVWJYQkdUa1V4VlZOdFJrNVNSRkkwVW\
     xod1FsVnJTbTVVYkZwRFVWYzVUbEV5YzNoT1ZrWjFWbTV3YUZaNlZuTlplazVPWlVWU1\
     ZWRlZlRU5hTURWWFVXdEdhbFJWU2tkVWJrSnJVakZXTkZJd1VrSldNRXB1Vkd4YVExRl\
     ZNVTVTUkVKVFpHMUtXRkp1UW1saVJYQnpWMnBLYzJWdFVrbFRiV2hxWVd0S1lWUlZTaz\
     VTTUVvMVkxVmtWRlJVVVRWUlYyUkdVakJPUkdOVlpGUlVWRkUxVVZoa1JsTkZSWGRUVl\
     VaRFVXMXplRTVyYzNaaFZHTTFZakZLY2xONlZscFpiVlpSV25wb1ZsVXhTVFJNTTFaNl\
     RWZFNVVlpYYkdGVFJURXdZakowVkZwSVJreFdlbFp0WW14a2VsRnRVWEpqVmtwTlRqRm\
     tVMXB0V214V01uUTFXakpXYVdJd2NHMVRWM2h6WkZoS2FtRlVTVEZrTWpWdllWVTVWMU\
     V3WkhGYVdIQkRUbFV4UTAxRlpFSk5WbFpyVTJ4R1VsWXdNVU5WVldSRVVUTk9TRkZXUm\
     xaU2Ewb3pWRlZLUTFveVpIbFJiV1JHVW10S1Vsa3dVa2xTUlVaUVVXMWtUMVpyYUZKUF\
     JVcENXbXBvUmxGclJrNVJNRWt3VVZoa1ZGRldiRVZXYkVsM1ZXdEtSbEpZWkZGT1JXeH\
     JXVEl4VjJKdFJsbFVha0pxWWxWYU5WUkdhRk5pUjAxNlZWaFdhazF0ZUhOWmJHUlhaRm\
     RPTlUxWGJHdFJlbFl4VjJ4b1ZGRXdhSFZUYlhoaFRXMTRObHBGYUV0aFIwNXdUVlJDWV\
     ZkRk5IZFViV3N4WlcxR1dGWnVVbUZXZWxZMlZFWmtTMDFGZUhST1YzaHJVa1ZHVEZGdF\
     pHNWpWMmh5WVdzNVVWVldSa1ZSVjJSUFUxVkdSVkZyV2tKaFZVbzBZa2RTUTJGR2NIaE\
     5SVll5VGxWd1RVMXNRbmxXTUU0d1pWWk5NbUZGVWxwV2VrWTFVVEE0ZGxWdFJqRlpia0\
     pFVGpBeGFGTlZVbTVUVjJoQ1ZFWk9TMWx0WkUxaWJXUnZXVzFLUWxwNlFtdFpNV1JIVm\
     xaYWRrd3laRWhVYWtGMllXNWtObE5zYjNkVk1uZDVZVVJTTkZOV2FISk5VMGx6U1cxR2\
     JscFhOVEJNV0U1d1dqSTFiRnBETVd0WldGSm9TV3B2YVZwWWJFdGtNV3haWWtoT2FVMX\
     JXbkpUVjNCMllWWndXV0pGZEdwU2JrSmFWbGN3ZUZSV1pFZGpSRXBoVW0xU1VGbHFSbm\
     RYVms1WlZXMXdhVlpzYnpCWGExcHJWakpXZEZWclVrNVhSMUp4V1d4U1FrMXNaRmRhUj\
     NScFVqQndNVlpXYUZOaGF6RjBaVWhXV21KVVJsaFpWRUkwVjBaV2RHRkhkRk5OUmxwM1\
     ZrUkpNV1Z0UmxkaE0zQlVZbGhvWVZZd1drdGpNV1J5VkZob2EySlZjSGRWTVZKaFUyMU\
     djbUpFVGxWV00wSkxXa1ZWZUZKWFJYcFZhelZvWVROQ1YxWkdWbE5XYXpWeVRsVldWVl\
     pHY0ZCV2ExWkhUVlpTVjFWcmNFNVdiVkozVlRGb1QxTnRTbkpPV0U1YVRXcEdlbGxWWk\
     V0U1JURlpWbTEwVjJWclduZFdNbmh2VTIxR1ZrOVlRbFJYUjFKUFZtdFdjMDVzVW5KVm\
     JGcE9ZWHBWTWxkdWNGZFRiVXB4VWxSV1NtRllaSEJaZWtwelltMUtkRkpxUW10WFJYQn\
     pXVE5zU2s1c1kzcGpNbXhxVTBWd01scEZaRmRoYlZKSVZtMTBTbUZ0T1hCWGJHaHpVek\



  Fries, et al.            Expires 5 December 2025              [Page 100]


  Internet-Draft                  BRSKI-PRM                      June 2025


     pPZEZKc2FGWldNbmhSV1ZaV2QxWnNXa1phUlRWT1RWZFNXbGxWVmpSV01rcEhWMnhrWV\
     ZaNlZreFVWRVpMVmxaU2MxTnNhRmRTYkhCRlZqSjRZV0V5U1hsVVdHeE9WbFphVDFSWE\
     1VNU9WazVZWWtST2FGWnRlRmxhVldNeFUyMUdkRTlZUWxaaVJuQlBXbFpWTVZaV1pGaG\
     lSekZXVlRCc2VsTlhOVTlqUm05NVRsZG9hMU5HV2pWWGJFNUtUbXRzY21RemJGcFdSVX\
     B6V1ROd1YxcHJlRmhhU0U1YVZtcHJkMVJxUmxaTlJURldZa1pLV0ZKdGVFcFZNVkpUVV\
     d4TmVGWnNaRlpTYTFwdFZGUkdVMkpIVVhoVlZFWnBUVVphVjFkV1ZrOWtSbFpKVVd0MF\
     lVMXRVbmxWTUdNeFpEQTVWMVJyTVdGV1Jsb3hXVmRyZUdKc1pFZGlSbEpwVFdzMWMxUX\
     hVbTlsUmtaWVUyNVNUMkV3V1hkYVJrMTRVbXhKZUZWcmVGcE5SRlpUVTFjMGVGcEhXbE\
     pOUlhOcFpsZ3dJaXdpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWl\
     hsS05FNVhUV2xQYkhOcFZGVnNTbEZwZEZWUk1FNUNXVlZPYmxGWVpFcFJhMFp1VTFWa1\
     FsZEhOVmRoYms1V1RsVXhRbUl3WkVSUk0wWklWVEF3TUU5VlNrSlVWVTVPVWtSQ05GRX\
     pjRUpUYTBwdVZHeGFRMUZXYkZWUlYzUkhWV3N4VTFaWVpFWmtNV3hGVm14R1VsTXdVa0\
     psUlhSb1ZucFdkVlV5TVhOa1ZtOTNWRzVhYW1KclJqUlNibkJDVm10S2JsUnNXa05SVl\
     RGT1VrZDBkMk5IU25SYVJYUm9WbnBXZFZaclpGZGxiVkpHVkd0S1RsRXdSbGxTUmxKS1\
     pVVXhSVmRZWkU5U1JVVjRWR3RTV21WRk5VZGlNV3hGWlcxek1WUXhVbkpsUlRGeFZGaG\
     9UbUZyTUhoVU1WSldUbFprY1ZGc1RrNVZXRTR6VVRGR1dsSkdXbEpWVldSR1pEQndRMV\
     pXVWtaV2F6RkRWRlZrUWsxV1ZrWlJNbVF6VkZaT2RHSklWbUZOU0VKM1dXMHhhMUpIU1\
     hwVGJtUk9WV3N4TTFKV1JscFNSbHBTVlZWYVJtUXlPVE5VVmxKS1pXczFSVlpVU2s5bG\
     JXTXhWRlpLYW1Rd1dsSlhWVkpYVlZaR1JWSkZSVEZUTWtaWVRsYzFWR0pYZURGWGFrSl\
     RZa2RTZEdKSGNHRldSVXBoVkZWS1RsSXdTalZqVldSVVZGUlJOVkZYWkVaU01FNUVZMV\
     ZrVkZSVVVUVlJXR1JHVTBWRmQxTlZSa05SZW1NMVlrZHNhRlZ0VGtOaGJIQnFVbFZXV1\
     dSNlpIbFdWMVpvWkc1U1NGTnJSakZUUkZKM1lYcFNTazVFU2pKWlZVcE9ZekZWZUUxWG\
     JFMVNSVTVFVkVkMFYyRklVbFpXYWtsNFlsaGFhRk13VGpKVVdHZDVWMU4wVkZSWFpGSl\
     BSMXB0WkRCM2VVMHpiM3BXUld4WFVXeGtjVnBHVWtObGF6RkVZekJrUkZFelRraFJWa1\
     pXVW10S00xSlhaRU5SYW1oWVUwWmplR0ZIVFhsU1dGSnJVakZhTmxwRlRURmxiVVpZVm\
     01U1lWWjZWalpVUm1STFRVVjRkRTVYZUd0U1J6Z3hWR3RTVW1Wck1VTlBSV1JDVFZaV2\
     ExTllaRkpYVlRGRFdWVkdSMUpzUmsxaGF6VTJWVU01VkV3eWRIWmtWM0JTWkRKd2JrNV\
     ZWVEZhYmxveldURnNhVlJWU2s1U01FVjRWbGRTUzFWV1JrNVVWVVoyVWpCT1JHTXdaRU\
     pWVmxaSFVXNWtUbEV3TVVKT1JXUkNUVlpXYTFKSVpFWlJhVGt6VlZWV1FtUXdiRWxhTU\
     ZKQ1V6QktibG96Um05aE1uQlFWVVpHVWxKRlJtNVVhMmhDVWtWS1JsRlhiRU5rVkU0el\
     ZXdEtUV013Y0U1VlJGWjZWRlJCTTAxRlozSldWVnA1WlZVMVZrNXRaRXhsYTNoUVZXMU\
     9SMlZXU2xOVU1uaDRZMVZvY0Zvd2JHNVhSVTUwVTJ0NFZXVnJWbk5rYTFGNVkwYzVURT\
     V0VWpST2JYZDRURE5XTldKV1VuVlpiRVpGVWtkYVMySkhSakJrVm1kNVZXMDVVRkpVTU\
     dsWVUzZHBaRWhzZDBscWIybGtiVGt4V1RKb2JHTnBNWEZrTTAxeVlXNU9kbUpwU1hOSm\
     JVWnpXbmxKTmtsclZsUk5hbFV5U1c0d0lpd2ljMmxuYm1GMGRYSmxJam9pYm5SQlowTT\
     NSMVEzZUVsRVdXTklRbGh2V1dWcU9IVkpWVWsyVjFJeVNYWXROMVF4UTJGU0xVbzJMWG\
     hUTmpCRWFWZFRNUzEyWm1NMVZYVTFTVTVhVXpGa2VWZGFOSFpXU0RaMVlXOVFZMlZTZU\
     U1ak9HY2lmVjE5IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMjRUMDk6MDI6MTUuNTczWi\
     IsImFnZW50LXNpZ24tY2VydCI6WyJNSUlCOWpDQ0FaMmdBd0lCQWdJRVl4WHM3VEFLQm\
     dncWhrak9QUVFEQWpBK01STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRF\
     ZRUUhEQVJUYVhSbE1SZ3dGZ1lEVlFRRERBOVVaWE4wVUhWemFFMXZaR1ZzUTBFd0hoY0\
     5Nakl3T1RBMU1USXpORFV6V2hjTk1qVXdPVEExTVRJek5EVXpXakJnTVFzd0NRWURWUV\
     FHRXdKQlVURVNNQkFHQTFVRUNnd0pUWGxEYjIxd1lXNTVNUlV3RXdZRFZRUUxEQXhOZV\
     ZOMVluTnBaR2xoY25reEpqQWtCZ05WQkFNTUhVMTVVMmwwWlZCMWMyaE5iMlJsYkZKbF\
     oybHpkSEpoY2tGblpXNTBNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQU\
     V4aHZuYWtDSmVpZ3pqWkFVYU5adVAwMWUrUWxVY1E5UjJMSWs2UkI2dmtjdFdMS3BaWC\
     85TGthNEdxckFWWmhhM3ZKcmhGc0l4OEdUQkhqWnZLMVd1Nk5uTUdVd0RnWURWUjBQQV\
     FIL0JBUURBZ09JTUI4R0ExVWRJd1FZTUJhQUZHK2hQVzUxN1ovb3NSQ0ZUc2NlUDY4bj\



  Fries, et al.            Expires 5 December 2025              [Page 101]


  Internet-Draft                  BRSKI-PRM                      June 2025


     kzc2pNQjBHQTFVZERnUVdCQlJNdHp0akVwVlJUT3ZBVGRCamtGNWFHeVlQZURBVEJnTl\
     ZIU1VFRERBS0JnZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05IQURCRUFpQmJoRG\
     pwbDJ2cWNONnBSVjRuZVU0dFFsWWFOTit4ZjNnSnUrMHBKblNBL1FJZ0ljcXpsZmhYaU\
     Qxc0g3VTVQdUtwVVpzSWpkRjRSenhzQTZxSnRFTEQyUHM9Il19fQ",
       "signatures": [
         {
           "protected": "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJ\
     Rk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
     QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweE9UQTVN\
     VEV3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXpKYU1GUXhFekFSQmdOVkJBb01DazE1\
     UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJs\
     emRISmhjaUJXYjNWamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJn\
     Y3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5XaFhwUXNr\
     YVB5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPLzBDREVqSWtCUW9idzhZS3Fq\
     dHhKSFZTR1RqOUtPb3ljd0pUQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RIREFPQmdO\
     VkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdZcjJMZnFvYUNL\
     REY0UkFjTW1KaStOQ1pxZFNpdVZ1Z0lTQTdPaEtScTNZQ0lEeG5QTU1ucFhBTVRyUEp1\
     UFd5Y2VFUjExUHhIT24rMENwU0hpMnFncFdYIl0sInR5cCI6InZvdWNoZXItandzK2pz\
     b24iLCJhbGciOiJFUzI1NiJ9",
           "signature": "_mcsO5vo0g2rFmBvTb-UsOWkEmhYNfQ5XmbuKHKH0ZLjea-7\
     911BilAMdFORmT4vCzWKBSH6HSqtpIRcSSxx7Q"
         }
       ]
     }

               Figure 54: Example Registrar-Voucher-Request - RVR

  A.3.  Example Voucher - from MASA to Pledge, via Registrar and
        Registrar-Agent

     The following is an example voucher-response from MASA to Pledge via
     Registrar and Registrar-Agent, in "General JWS JSON Serialization".
     The message size of this Voucher is: 1916 bytes


















  Fries, et al.            Expires 5 December 2025              [Page 102]


  Internet-Draft                  BRSKI-PRM                      June 2025


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

     {
       "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
     udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
     iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
     UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
     3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
     RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
     EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
     BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
     nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
     CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
     ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
     FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
     CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
     BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
     HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
       "signatures":[{
         "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
     Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
     hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
     YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
     VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
     3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
     CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
     wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
     CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
     qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
     FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
     FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ",
         "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\
     TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw"
       }]
     }

                 Figure 55: Example Voucher-Response from MASA

  A.4.  Example Voucher, MASA issued Voucher with additional Registrar
        signature (from MASA to Pledge, via Registrar and Registrar-Agent)

     The following is an example voucher-response from MASA to Pledge via
     Registrar and Registrar-Agent, in "General JWS JSON Serialization".
     The message size of this Voucher is: 2994 bytes







  Fries, et al.            Expires 5 December 2025              [Page 103]


  Internet-Draft                  BRSKI-PRM                      June 2025


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

     {
       "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2\
     VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIj\
     oia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMj\
     RUMDk6MDI6MTYuMjQ0WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0\
     F3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMT\
     VRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1\
     JEUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RX\
     pBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTk\
     JnTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSU\
     FCT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2\
     NZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRX\
     dFQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0\
     JCVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQk\
     dBaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUU\
     RHMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
       "signatures": [
         {
           "protected": "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNr\
     WU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
     eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
     QjRYRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtH\
     QTFVRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFV\
     RUF3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dU\
     QVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJz\
     OFIwWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZP\
     S0dCSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29a\
     SXpqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4L3R6VW9RL1NzeWRMMzBEUUlO\
     RXRjTjltQ1RYUEFpRUF2SWIzbytGTzNCVG5jTEZzYUpaUkFrZDd6T3Vzbi8vWktPYUVL\
     YnNWRGlVPSJdLCJ0eXAiOiJ2b3VjaGVyLWp3cytqc29uIiwiYWxnIjoiRVMyNTYifQ",
           "signature": "SFtc2xqK8xN2KVqkYKJl7EUU8UJAai3VvCuK8LIfH8HZFvrr\
     hqGiY8vK5cbQHQCjVcroFLn7IyhH708XAdstAQ"
         },
         {
           "protected": "eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJi\
     Wk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
     QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlN\
     RGN3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1\
     UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldG\
     cGJsSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJC\
     azE2Sy9pNzlvUmtLNVliZVBnOFVTUjgvdXMxZFBVaVpITXRva1NkcUtXNWZuV3NCZCtx\
     Ukw3V1JmZmVXa3lnZWJvSmZJbGx1cmNpMjV3bmhpT1ZDR2plekI1TUIwR0ExVWRKUVFX\
     TUJRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREhEQU9CZ05WSFE4QkFmOEVCQU1DQjRB\
     d1NBWURWUjBSQkVFd1A0SWRjbVZuYVhOMGNtRnlMWFJsYzNRdWMybGxiV1Z1Y3kxaWRD\
     NXVaWFNDSG5KbFoybHpkSEpoY2kxMFpYTjBOaTV6YVdWdFpXNXpMV0owTG01bGREQUtC\
     Z2dxaGtqT1BRUURBZ05JQURCRkFpQnhsZEJoWnEwRXY1SkwyUHJXQ3R5UzZoRFlXMXlD\



  Fries, et al.            Expires 5 December 2025              [Page 104]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Ty9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm8vZ0dOMC9qd3pKWjBT\
     bDJoNHhJWGsxIl0sInR5cCI6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9\
     ",
           "signature": "0Q7_a7L4ahn2vmfSxxkKg1xsOMMc8_D7B_Ilzqv5DKzCMkc7\
     8YeeezDsuh4Z5JNVQUYHPp7LsK_AS_WH8TdVzA"
         }
       ]
     }

         Figure 56: Example Voucher-Response from MASA, with additional
                              Registrar signature

  Appendix B.  HTTP-over-TLS operations between Registrar-Agent and Pledge

     The use of HTTP-over-TLS between Registrar-Agent and pledge has been
     identified as an optional mechanism.

     Provided that the key-agreement in the underlying TLS protocol
     connection can be properly authenticated, the use of TLS provides
     privacy for the voucher and enrollment operations between the pledge
     and the Registrar-Agent.  The authenticity of the onboarding and
     enrollment is not dependent upon the security of the TLS connection.

     The use of HTTP-over-TLS is not mandated by this document for two
     main reasons:

     1.  A certificate is generally required in order to do TLS.  While
         there are other modes of authentication including PSK, various
         EAP methods, and raw public key, they do not help as there is no
         previous relationship between the Registrar-Agent and the pledge.

     2.  The pledge can use its IDevID certificate to authenticate itself,
         but [RFC9525] DNS-ID methods do not apply, as the pledge does not
         have a FQDN, and hence cannot be identified by DNS name.  Instead
         a new mechanism is required, which authenticates the
         X520SerialNumber DN attribute that must be present in every
         IDevID.

     If the Registrar-Agent has a pre-configured list of which product-
     serial-number(s), from which manufacturers it expects to see, then it
     can attempt to match this pledge against a list of potential devices.

     In many cases only the list of manufacturers is known ahead of time,
     so at most the Registrar-Agent can show the X520SerialNumber to the
     (human) operator who may then attempt to confirm that they are
     standing in front of a device with that product-serial-number.  The
     use of scannable QR codes may help automate this in some cases.




  Fries, et al.            Expires 5 December 2025              [Page 105]


  Internet-Draft                  BRSKI-PRM                      June 2025


     The CA used to sign the IDevID will be a manufacturer private PKI as
     described in Section 4.1 of
     [I-D.irtf-t2trg-taxonomy-manufacturer-anchors].  The anchors for this
     PKI will never be part of the public WebPKI anchors which are
     distributed with most smartphone operating systems.  A Registrar-
     Agent application will need to use different APIs in order to
     initiate an HTTP-over-TLS connection without performing WebPKI
     verification.  The application will then have to do its own
     certificate chain verification against a store of manufacturer trust
     anchors.  In the Android ecosystem this involves use of a customer
     TrustManager: many application developers do not create these
     correctly, and there is significant push to remove this option as it
     has repeatedly resulted in security failures (see
     [androidtrustfail]).

     Also note that an Extended Key Usage (EKU) for TLS WWW Server
     authentication cannot be expected in the pledge IDevID certificate.
     IDevID certificates are intended to be widely usable and EKU does not
     support that use.

  Appendix C.  History of Changes "RFC Editor: please delete"

     Proof of Concept Code available

     From IETF draft 22 -> IETF draft 23:

     *  editorial update of new section on TLS usage clarifications
        Section 4.1

     *  structural and editorial improvements to privacy considerations
        Section 11

     From IETF draft 21 -> IETF draft 22:

     *  addressed remaining issues from telechat

        -  included overview subsections for reason-context definition and
           usage in Section 6.2

        -  updated status detail examples to correctly use the defined
           types in the status structure.

        -  new section on TLS usage clarifications Section 4.1

     From IETF draft 20 -> IETF draft 21:

     *  addressed remaining issues from telechat




  Fries, et al.            Expires 5 December 2025              [Page 106]


  Internet-Draft                  BRSKI-PRM                      June 2025


        -  RetryAfter response to be always provided in case of 503
           Service unavailable response

     From IETF draft 19 -> IETF draft 20:

     *  addressed last comments and nits before telechat

     From IETF draft 18 -> IETF draft 19:

     *  addressed DISCUSS received during telechat preparation:

        -  issue 136: included hint for reaction on HTTP requests to avoid
           DoS (rate limiting) in Section 6.2

        -  issue 137: HTTP error handling BCP RFC 9205: removed normative
           language for HTTP status codes

        -  issue 139: usage of TLS 1.3 emphasized by also referencing UTA
           draft in Section 7.3

        -  issue 140: provided hint for time synchronization of registrar-
           agent in Section 6.1

        -  issue 145: clarified language tagging in status information in
           Section 7.6.2.1

     *  addressed COMMENT, NITS, received during telechat preparation,
        specifically

        -  issue 140: synchronized time

        -  issue 141: config options for discovery and nonceless vouchers
           in Section 7.6 and Section 6.1

        -  issue 142: addressed TTL of provisional accept state by
           utilizing the last received tPVR for the binding in Section 7.1

        -  issue 144: clarified usage of "MUST ...unless" in Section 6.2

        -  issue 146: added MTI algorithm for JWS signatures

        -  issue 147: definitions of reason-context in status objects

     *  updated reference of BRSKI-AE (now RFC 9733).

     *  removed unused references

     From IETF draft 17 -> IETF draft 18:



  Fries, et al.            Expires 5 December 2025              [Page 107]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  addressed nits received from the GenART review

     *  addressed comment from IANA to update contact for service name
        registration from IESG to IETF Chair in Section 10.2

     *  SECDIR review: included reasoning for short lived certificates in
        Section 6.1

     *  SECDIR review: enhanced reasoning for optional TLS usage in
        Section 7.1

     *  SECDIR review: added hint for handling if the accept header is not
        used in Section 7.1 and Section 7.2

     *  SECDIR review: added hint for response body encoding in
        Section 7.1 and Section 7.2

     *  SECDIR review: added hint regarding IDevID and LDevID validity in
        Section 9

     *  DNSDIR review: renamed Section 10.2 to Service Name and Transport
        Protocol Port Number Registry

     *  from IANA expert review: included registered service names in
        headings

     From IETF draft 16 -> IETF draft 17:

     *  updated formatting of key events in Section 8

     *  updated reference to corresponding sections for JWS Header and
        Signature in [I-D.ietf-anima-jws-voucher] in Section 7.1.2.1 and
        Section 7.3.4.1

     *  simplified description for JWS Protected Header aligning with the
        update in draft-ietf-anima-jws-voucher-15 to always include the
        certificate chain in Section 7.1.2.1 and Section 7.3.4.1

     From IETF draft 15 -> IETF draft 16:

     *  issue #135: corrections from IOTDIR review (clarification
        regarding minimum supported discovery in Section 6.1.2,
        clarification regarding CDDl notation in Figure 27 and editorial
        nits.

     *  updated references (draft-ietf-netconf-sztp-csr became RFC 9646,
        included RFC 9662, operational considerations drafts for registrar
        and MASA)



  Fries, et al.            Expires 5 December 2025              [Page 108]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  AD review: included term Registrar-Agent in Terminology section

     *  AD review: enhanced interaction information in Figure 1 and
        Figure 2

     *  AD review: included new section on Section 9 to outline
        operational considerations

     *  AD review: enhanced Section 8 with more detailed recommendations
        on logging

     *  AD review: enhanced Section 11 with enhanced recommendations
        concerning logging

     *  AD review: enhanced Section 12.3 with more information about
        misuse of the Registrar-Agent

     *  IOTDIR/OPSDIR/AD review: addressed various nits received
        throughout the draft

     From IETF draft 14 -> IETF draft 15:

     *  issue #134: editorial clarifications on references to
        [I-D.ietf-anima-brski-discovery] in Section 6.1.1 and
        Section 6.1.2

     From IETF draft 13 -> IETF draft 14:

     *  Update of the examples in Appendix A to align with the defined
        prototypes

     *  Changes incorporated based on Shepherd review PR #133:

        -  Terminology alignment and clarification throughout the document
           to use terms more consistently

        -  Restructuring of Section 7 for protocol steps to align to the
           general approach: Overview, data description, CDDL description
           (if necessary), JWS Header an Signature.  This lead to some
           movement of text between existing and new subsections.

        -  Inclusion of new section on logging hints Section 8 to give
           recommendations on which events to be logged for auditing

        -  Alignment of pledge status response data across
           Section 7.6.2.1, Section 7.8.2.1, and Section 7.11.2.1.





  Fries, et al.            Expires 5 December 2025              [Page 109]


  Internet-Draft                  BRSKI-PRM                      June 2025


        -  Included MASA component in description of affected components
           in Section 6

        -  Moved host header field handling from Appendix B to Section 6.2
           as generally applicable

        -  Updated status artifacts (vStatus, eStatus, pStatus) to align
           with BRSKI CDDL definition, but made reason-context mandatory
           to have distinguishable objects for the registrar-agent

        -  Correction of terminology of local host name vs. service
           instance name in Section 6.1.2

     *  Update of informative references and nits

     From IETF draft 12 -> IETF draft 13:

     *  Deleted figure in Section "Request Artifact: Pledge Voucher-
        Request Trigger (tPVR)" for JSON representation of tPVR, as it has
        been replaced by CDDL

     *  Updated reason-content description in status response messages
        (enroll-status, voucher-status, and status-response).

     *  Updated CDDL source code integration to allow for automatic
        verification

     *  Reordered description in Section 7.3 in Section 7.2 to better
        match the order of communication and artifact processing.

     *  Updated CDDL for the request-enroll trigger in Figure 15 according
        to the outcome of the interim ANIMA WG meeting discussions on
        April 19, 2024

     *  Included statement in Section 7.2.2 for using the advanced
        created-on time from the agent-signed-data also for the PER, when
        the pledge has no synchronized clock

     From IETF draft 11 -> IETF draft 12:

     *  Updated acknowledgments to reflect early reviews

     *  Addressed Shepherd review part 2 (Pull Request #132); containing:
        terminology alignment, structural improvements of the document;
        deletion of leftovers from previous draft versions; change of
        definitions to CDDL, when no YANG is available

     From IETF draft 10 -> IETF draft 11:



  Fries, et al.            Expires 5 December 2025              [Page 110]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  issue #79, clarified that BRSKI discovery in the context of BRSKI-
        PRM is not needed in Section 6.1.1.

     *  issue #103, removed step 6 in verification handling for the
        wrapped CA certificate provisioning as only applicable after
        enrollment Section 7.7

     *  issue #128: included notation of nomadic operation of the
        Registrar-Agent in Section 5, including proposed text from PR #131

     *  issue #130, introduced DNS service discovery name for brski_pledge
        to enable discovery by the Registrar-Agent in Section 10

     *  removed unused reference RFC 5280

     *  removed site terminology

     *  deleted duplicated text in Section 6.2

     *  clarified registrar discovery and relation to BRSKI-Discovery in
        Section 6.1.1

     *  clarified discovery of pledges by the Registrar-Agent in
        Section 6.1.2, deleted reference to GRASP as handled in BRSKI-
        Discovery

     *  addressed comments from SECDIR early review

     From IETF draft 09 -> IETF draft 10:

     *  issue #79, clarified discovery in the context of BRSKI-PRM and
        included information about future discovery enhancements in a
        separate draft in Section 6.1.1.

     *  issue #93, included information about conflict resolution in mDNS
        and GRASP in Section 6.1.2

     *  issue #103, included verification handling for the wrapped CA
        certificate provisioning in Section 7.7

     *  issue #106, included additional text to elaborate more the
        registrar status handling in Section 7.9 and Section 7.10

     *  issue #116, enhanced DoS description in Section 12.1

     *  issue #120, included statement regarding pledge host header
        processing in Section 6.2




  Fries, et al.            Expires 5 December 2025              [Page 111]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  issue #122, availability of product-serial-number information on
        registrar agent clarified in Section 7.1

     *  issue #123, Clarified usage of alternative voucher formats in
        Section 7.3.4

     *  issue #124, determination of pinned domain certificate done as in
        RFC 8995 included in Section 7.3.5

     *  issue #125, remove strength comparison of voucher assertions in
        Section 5.4 and Section 7

     *  issue #130, aligned the usage of site and domain throughout the
        document

     *  changed naming of registrar certificate from LDevID(RegAgt) to
        Registrar-Agent EE certificate throughout the document

     *  change x5b to x5bag according to [RFC9360]

     *  updated JSON examples -> "signature": BASE64URL(JWS Signature)

     From IETF draft 08 -> IETF draft 09:

     *  issue #80, enhanced Section 6.1.2 with clarification on the
        product-serial-number and the inclusion of GRASP

     *  issue #81, enhanced introduction with motivation for
        agent_signed_data

     *  issue #82, included optional TLS protection of the communication
        link between Registrar-Agent and pledge in the introduction
        Section 4, and Section 7.1

     *  issue #83, enhanced Section 7.2 and Section 7.3 with note to re-
        enrollment

     *  issue #87, clarified available information at the Registrar-Agent
        in Section 7.1

     *  issue #88, clarified, that the PVR in Section 7.1 and PER in
        Section 7.2 may contain the certificate chain.  If not contained
        it MUST be available at the registrar.

     *  issue #91, clarified that a separate HTTP connection may also be
        used to provide the PER in Section 7.4





  Fries, et al.            Expires 5 December 2025              [Page 112]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  resolved remaining editorial issues discovered after WGLC
        (responded to on the mailing list in Reply 1 and Reply 2)
        resulting in more consistent descriptions

     *  issue #92: kept separate endpoint for wrapped CSR on registrar
        Section 7.5

     *  issue #94: clarified terminology (possess vs. obtained)

     *  issue #95: clarified optional IDevID CA certificates on Registrar-
        Agent

     *  issue #96: updated exchangesfig_uc2_3 to correct to just one CA
        certificate provisioning

     *  issue #97: deleted format explanation in exchanges_uc2_3 as it may
        be misleading

     *  issue #99: motivated verification of second signature on voucher
        in Section 7.6

     *  issue #100: included negative example in Figure 33

     *  issue #101: included handling if Section 7.6 voucher telemetry
        information has not been received by the Registrar-Agent

     *  issue #102: relaxed requirements for CA certs provisioning in
        Section 7.7

     *  issue #105: included negative example in Figure 39

     *  issue #107: included example for certificate revocation in
        Section 7.10

     *  issue #108: renamed heading to Pledge-Status Request of
        Section 7.11

     *  issue #111: included pledge-status response processing for
        authenticated requests in Section 7.11

     *  issue #112: added "Example key word in pledge-status response in
        Figure 50

     *  issue #113: enhanced description of status reply for "factory-
        default" in Section 7.11

     *  issue #114: Consideration of optional TLS usage in Privacy
        Considerations



  Fries, et al.            Expires 5 December 2025              [Page 113]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  issue #115: Consideration of optional TLS usage in Privacy
        Considerations to protect potentially privacy related information
        in the bootstrapping like status information, etc.

     *  issue #116: Enhanced DoS description and mitigation options in
        security consideration section

     *  updated references

     From IETF draft 07 -> IETF draft 08:

     *  resolved editorial issues discovered after WGLC (still open issues
        remaining)

     *  resolved first comments from the Shepherd review as discussed in
        PR #85 on the ANIMA github

     From IETF draft 06 -> IETF draft 07:

     *  WGLC resulted in a removal of the voucher enhancements completely
        from this document to RFC 8366bis, containing all enhancements and
        augmentations of the voucher, including the voucher-request as
        well as the tree diagrams

     *  smaller editorial corrections

     From IETF draft 05 -> IETF draft 06:

     *  Update of list of reviewers

     *  Issue #67, shortened the pledge endpoints to prepare for
        constraint deployments

     *  Included table for new endpoints on the registrar in the overview
        of the Registrar-Agent

     *  addressed review comments from SECDIR early review (terminology
        clarifications, editorial improvements)

     *  addressed review comments from IOTDIR early review (terminology
        clarifications, editorial improvements)

     From IETF draft 04 -> IETF draft 05:

     *  Restructured document to have a distinct section for the object
        flow and handling and shortened introduction, issue #72





  Fries, et al.            Expires 5 December 2025              [Page 114]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Added security considerations for using mDNS without a specific
        product-serial-number, issue #75

     *  Clarified pledge-status responses are cumulative, issue #73

     *  Removed agent-sign-cert from trigger data to save bandwidth and
        remove complexity through options, issue #70

     *  Changed terminology for LDevID(Reg) certificate to registrar
        LDevID certificate, as it does not need to be an LDevID, issue #66

     *  Added new protected header parameter (created-on) in PER to
        support freshness validation, issue #63

     *  Removed reference to CAB Forum as not needed for BRSKI-PRM
        specifically, issue #65

     *  Enhanced error codes in section 5.5.1, issue #39, #64

     *  Enhanced security considerations and privacy considerations, issue
        #59

     *  Issue #50 addressed by referring to the utilized enrollment
        protocol

     *  Issue #47 MASA verification of LDevID(RegAgt) to the same
        registrar LDevID certificate domain CA

     *  Reworked terminology of "enrollment object", "certification
        object", "enrollment request object", etc., issue #27

     *  Reworked all message representations to align with encoding

     *  Added explanation of MASA requiring domain CA cert in section
        5.5.1 and section 5.5.2, issue #36

     *  Defined new endpoint for pledge bootstrapping status inquiry,
        issue #35 in section Section 7.11, IANA considerations and section
        Section 6.2

     *  Included examples for several objects in section Appendix A
        including message example sizes, issue #33

     *  PoP for private key to registrar certificate included as
        mandatory, issues #32 and #49

     *  Issue #31, clarified that combined pledge may act as client/server
        for further (re)enrollment



  Fries, et al.            Expires 5 December 2025              [Page 115]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Issue #42, clarified that Registrar needs to verify the status
        responses with and ensure that they match the audit log response
        from the MASA, otherwise it needs drop the pledge and revoke the
        certificate

     *  Issue #43, clarified that the pledge shall use the create time
        from the trigger message if the time has not been synchronized,
        yet.

     *  Several editorial changes and enhancements to increasing
        readability.

     From IETF draft 03 -> IETF draft 04:

     *  In deep Review by Esko Dijk lead to issues #22-#61, which are bein
        stepwise integrated

     *  Simplified YANG definition by augmenting the voucher-request from
        RFC 8995 instead of redefining it.

     *  Added explanation for terminology "endpoint" used in this
        document, issue #16

     *  Added clarification that Registrar-Agent may collect PVR or PER or
        both in one run, issue #17

     *  Added a statement that nonceless voucher may be accepted, issue
        #18

     *  Simplified structure in section Section 3.1, issue #19

     *  Removed join proxy in Figure 1 and added explanatory text, issue
        #20

     *  Added description of pledge-CAcerts endpoint plus further handling
        of providing a wrapped CA certs response to the pledge in section
        Section 7.7; also added new required registrar endpoint (section
        Section 7.3 and IANA considerations) for the registrar to provide
        a wrapped CA certs response, issue #21

     *  utilized defined abbreviations in the document consistently, issue
        #22

     *  Reworked text on discovery according to issue #23 to clarify scope
        and handling

     *  Added several clarifications based on review comments




  Fries, et al.            Expires 5 December 2025              [Page 116]


  Internet-Draft                  BRSKI-PRM                      June 2025


     From IETF draft 02 -> IETF draft 03:

     *  Updated examples to state "base64encodedvalue==" for x5c
        occurrences

     *  Include link to SVG graphic as general overview

     *  Restructuring of section 5 to flatten hierarchy

     *  Enhanced requirements and motivation in Section 4

     *  Several editorial improvements based on review comments

     From IETF draft 01 -> IETF draft 02:

     *  Issue #15 included additional signature on voucher from registrar
        in section Section 7.3 and section Section 5.4 The verification of
        multiple signatures is described in section Section 7.6

     *  Included representation for General JWS JSON Serialization for
        examples

     *  Included error responses from pledge if it is not able to create a
        Pledge-Voucher-Request or an enrollment request in section
        Section 7.1

     *  Removed open issue regarding handling of multiple CSRs and Enroll-
        Responses during the bootstrapping as the initial target it the
        provisioning of a generic LDevID certificate.  The defined
        endpoint on the pledge may also be used for management of further
        certificates.

     From IETF draft 00 -> IETF draft 01:

     *  Issue #15 lead to the inclusion of an option for an additional
        signature of the registrar on the voucher received from the MASA
        before forwarding to the Registrar-Agent to support verification
        of POP of the registrars private key in section Section 7.3 and
        exchanges_uc2_3.

     *  Based on issue #11, a new endpoint was defined for the registrar
        to enable delivery of the wrapped enrollment request from the
        pledge (in contrast to plain PKCS#10 in simple enroll).








  Fries, et al.            Expires 5 December 2025              [Page 117]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Decision on issue #8 to not provide an additional signature on the
        enrollment-response object by the registrar.  As the Enroll-
        Response will only contain the generic LDevID certificate.  This
        credential builds the base for further configuration outside the
        initial enrollment.

     *  Decision on issue #7 to not support multiple CSRs during the
        bootstrapping, as based on the generic LDevID certificate the
        pledge may enroll for further certificates.

     *  Closed open issue #5 regarding verification of ietf-ztp-types
        usage as verified via a proof-of-concept in section Section 7.1.

     *  Housekeeping: Removed already addressed open issues stated in the
        draft directly.

     *  Reworked text in from introduction to section pledge-responder-
        mode

     *  Fixed "serial-number" encoding in PVR/RVR

     *  Added prior-signed-voucher-request in the parameter description of
        the registrar-voucher-request in Section 7.3.

     *  Note added in Section 7.3 if sub-CAs are used, that the
        corresponding information is to be provided to the MASA.

     *  Inclusion of limitation section (pledge sleeps and needs to be
        waked up.  Pledge is awake but Registrar-Agent is not available)
        (Issue #10).

     *  Assertion-type aligned with voucher in RFC8366bis, deleted related
        open issues.  (Issue #4)

     *  Included table for endpoints in Section 6.2 for better
        readability.

     *  Included registrar authorization check for Registrar-Agent during
        TLS handshake in section Section 7.3.  Also enhanced figure
        Figure 4 with the authorization step on TLS level.

     *  Enhanced description of registrar authorization check for
        Registrar-Agent based on the agent-signed-data in section
        Section 7.3.  Also enhanced figure Figure 4 with the authorization
        step on Pledge-Voucher-Request level.






  Fries, et al.            Expires 5 December 2025              [Page 118]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Changed agent-signed-cert to an array to allow for providing
        further certificate information like the issuing CA cert for the
        LDevID(RegAgt) certificate in case the registrar and the
        Registrar-Agent have different issuing CAs in Figure 4 (issue
        #12).  This also required changes in the YANG module in
        [I-D.ietf-anima-rfc8366bis]

     *  Addressed YANG warning (issue #1)

     *  Inclusion of examples for a trigger to create a Pledge-Voucher-
        Request and a Pledge Enroll-Request.

     From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski-
     prm-00:

     *  Moved UC2 related parts defining the Pledge in Responder Mode from
        draft-ietf-anima-brski-async-enroll-03 to this document This
        required changes and adaptations in several sections to remove the
        description and references to UC1.

     *  Addressed feedback for voucher-request enhancements from YANG
        doctor early review, meanwhile moved to
        [I-D.ietf-anima-rfc8366bis] as well as in the security
        considerations (formerly named ietf-async-voucher-request).

     *  Renamed ietf-async-voucher-request to IETF-voucher-request-prm to
        to allow better listing of voucher related extensions; aligned
        with constraint voucher (#20)

     *  Utilized ietf-voucher-request-async instead of ietf-voucher-
        request in voucher exchanges to utilize the enhanced voucher-
        request.

     *  Included changes from draft-ietf-netconf-sztp-csr-06 regarding the
        YANG definition of csr-types into the enrollment request exchange.

     From IETF draft 02 -> IETF draft 03:

     *  Housekeeping, deleted open issue regarding YANG voucher-request in
        Section 7.1 as voucher-request was enhanced with additional leaf.

     *  Included open issues in YANG model in Section 5 regarding
        assertion value agent-proximity and csr encapsulation using SZTP
        sub module).

     From IETF draft 01 -> IETF draft 02:





  Fries, et al.            Expires 5 December 2025              [Page 119]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Defined call flow and objects for interactions in UC2.  Object
        format based on draft for JOSE signed voucher artifacts and
        aligned the remaining objects with this approach in Section 7.

     *  Terminology change: issue #2 pledge-agent -> Registrar-Agent to
        better underline Registrar-Agent relation.

     *  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
        and pledge-responder-mode to better address the pledge operation.

     *  Communication approach between pledge and Registrar-Agent changed
        by removing TLS-PSK (former section TLS establishment) and
        associated references to other drafts in favor of relying on
        higher layer exchange of signed data objects.  These data objects
        are included also in the Pledge-Voucher-Request and lead to an
        extension of the YANG module for the voucher-request (issue #12).

     *  Details on trust relationship between Registrar-Agent and
        registrar (issue #4, #5, #9) included in Section 5.

     *  Recommendation regarding short-lived certificates for Registrar-
        Agent authentication towards registrar (issue #7) in the security
        considerations.

     *  Introduction of reference to Registrar-Agent signing certificate
        using SubjectKeyIdentifier in Registrar-Agent signed data (issue
        #37).

     *  Enhanced objects in exchanges between pledge and Registrar-Agent
        to allow the registrar to verify agent-proximity to the pledge
        (issue #1) in Section 7.

     *  Details on trust relationship between Registrar-Agent and pledge
        (issue #5) included in Section 5.

     *  Split of use case 2 call flow into sub sections in Section 7.

     From IETF draft 00 -> IETF draft 01:

     *  Update of scope in Section 3.1 to include in which the pledge acts
        as a server.  This is one main motivation for use case 2.

     *  Rework of use case 2 in Section 5 to consider the transport
        between the pledge and the pledge-agent.  Addressed is the TLS
        channel establishment between the pledge-agent and the pledge as
        well as the endpoint definition on the pledge.

     *  First description of exchanged object types (needs more work)



  Fries, et al.            Expires 5 December 2025              [Page 120]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Clarification in discovery options for enrollment endpoints at the
        domain registrar based on well-known endpoints do not result in
        additional /.well-known URIs.  Update of the illustrative example.
        Note that the change to /brski for the voucher related endpoints
        has been taken over in the BRSKI main document.

     *  Updated references.

     *  Included Thomas Werner as additional author for the document.

     From individual version 03 -> IETF draft 00:

     *  Inclusion of discovery options of enrollment endpoints at the
        domain registrar based on well-known endpoints in new section as
        replacement of section 5.1.3 in the individual draft.  This is
        intended to support both use cases in the document.  An
        illustrative example is provided.

     *  Missing details provided for the description and call flow in
        pledge-agent use case Section 5, e.g. to accommodate distribution
        of CA certificates.

     *  Updated CMP example in to use lightweight CMP instead of CMP, as
        the draft already provides the necessary /.well-known endpoints.

     *  Requirements discussion moved to separate section in Section 4.
        Shortened description of proof of identity binding and mapping to
        existing protocols.

     *  Removal of copied call flows for voucher exchange and registrar
        discovery flow from [RFC8995] in UC1 to avoid doubling or text or
        inconsistencies.

     *  Reworked abstract and introduction to be more crisp regarding the
        targeted solution.  Several structural changes in the document to
        have a better distinction between requirements, use case
        description, and solution description as separate sections.
        History moved to appendix.

     From individual version 02 -> 03:

     *  Update of terminology from self-contained to authenticated self-
        contained object to be consistent in the wording and to underline
        the protection of the object with an existing credential.  Note
        that the naming of this object may be discussed.  An alternative
        name may be attestation object.





  Fries, et al.            Expires 5 December 2025              [Page 121]


  Internet-Draft                  BRSKI-PRM                      June 2025


     *  Simplification of the architecture approach for the initial use
        case having an offsite PKI.

     *  Introduction of a new use case utilizing authenticated self-
        contain objects to onboard a pledge using a commissioning tool
        containing a pledge-agent.  This requires additional changes in
        the BRSKI call flow sequence and led to changes in the
        introduction, the application example,and also in the related
        BRSKI-PRM call flow.

     From individual version 01 -> 02:

     *  Update of introduction text to clearly relate to the usage of
        IDevID and LDevID.

     *  Update of description of architecture elements and changes to
        BRSKI in Section 5.

     *  Enhanced consideration of existing enrollment protocols in the
        context of mapping the requirements to existing solutions in
        Section 4.

     From individual version 00 -> 01:

     *  Update of examples, specifically for building automation as well
        as two new application use cases in Section 3.1.

     *  Deletion of asynchronous interaction with MASA to not complicate
        the use case.  Note that the voucher exchange can already be
        handled in an asynchronous manner and is therefore not considered
        further.  This resulted in removal of the alternative path the
        MASA in Figure 1 and the associated description in Section 5.

     *  Enhancement of description of architecture elements and changes to
        BRSKI in Section 5.

     *  Consideration of existing enrollment protocols in the context of
        mapping the requirements to existing solutions in Section 4.

     *  New section starting with the mapping to existing enrollment
        protocols by collecting boundary conditions.

  Contributors

     Esko Dijk
     IoTconsultancy.nl
     Email: esko.dijk@iotconsultancy.nl




  Fries, et al.            Expires 5 December 2025              [Page 122]


  Internet-Draft                  BRSKI-PRM                      June 2025


     Toerless Eckert
     Futurewei
     Email: tte@cs.fau.de


     Matthias Kovatsch
     Siemens Schweiz AG
     Email: ietf@kovatsch.net


  Authors' Addresses

     Steffen Fries
     Siemens AG
     Otto-Hahn-Ring 6
     81739 Munich
     Germany
     Email: steffen.fries@siemens.com
     URI:   https://www.siemens.com/


     Thomas Werner
     Siemens AG
     Otto-Hahn-Ring 6
     81739 Munich
     Germany
     Email: thomas-werner@siemens.com
     URI:   https://www.siemens.com/


     Eliot Lear
     Cisco Systems
     Richtistrasse 7
     CH-8304 Wallisellen
     Switzerland
     Phone: +41 44 878 9200
     Email: lear@cisco.com


     Michael C. Richardson
     Sandelman Software Works
     Email: mcr+ietf@sandelman.ca
     URI:   http://www.sandelman.ca/








  Fries, et al.            Expires 5 December 2025              [Page 123]


name: draft-vinaysingh-awp-wellknown
rev: 00
title: The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation
time: 2025-11-02T16:22:40Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T16:22:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.123289+00:00
source: ietf
abstract:
  This document registers a Well-Known URI, /.well-known/awp.json, and
     a companion Link Relation Type, awp.  The resource exposes a small,
     machine-readable description of common website workflows (states,
     actions, and resulting events) so automated agents can act
     predictably without scraping.  The format is JSON and intentionally
     minimal.

full_text:
  Network Working Group                                           V. Singh
  Internet-Draft                                                  Ajna.inc
  Intended status: Standards Track                                D. McKay
  Expires: 5 May 2026                                             Verid.id
                                                           1 November 2025


  The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation
                     draft-vinaysingh-awp-wellknown-00

  Abstract

     This document registers a Well-Known URI, /.well-known/awp.json, and
     a companion Link Relation Type, awp.  The resource exposes a small,
     machine-readable description of common website workflows (states,
     actions, and resulting events) so automated agents can act
     predictably without scraping.  The format is JSON and intentionally
     minimal.

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-vinaysingh-awp-wellknown/.


     Source for this draft and an issue tracker can be found at
     https://github.com/vinaysingh8866/awp-wellknown-draft.

  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 5 May 2026.





  Singh & McKay              Expires 5 May 2026                   [Page 1]


  Internet-Draft               AWP Well-Known                November 2025


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  The AWP Resource  . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Discovery via Link Relation . . . . . . . . . . . . . . . . .   4
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Well-Known URI Registration . . . . . . . . . . . . . . .   5
       5.2.  Link Relation Type Registration . . . . . . . . . . . . .   5
     Appendix A.  References . . . . . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     Automation on the Web often relies on brittle scraping.  Many sites
     already publish machine metadata (e.g., OpenAPI descriptions,
     sitemaps).  This document defines a single optional entry point — a
     Well-Known resource — that advertises a compact, typed map of site
     workflows.  Agents can use it to perform tasks deterministically
     (e.g., sign in, search, checkout).

     This document registers:

     *  the Well-Known URI: /.well-known/awp.json, and

     *  the Link Relation Type: awp.

     The resource is read-only and does not alter authorization; normal
     Web security controls continue to apply.

  2.  The AWP Resource

     An origin *MAY* expose a JSON resource at:




  Singh & McKay              Expires 5 May 2026                   [Page 2]


  Internet-Draft               AWP Well-Known                November 2025


     GET /.well-known/awp.json Content-Type: application/awp+json

     The document contains:

     *  version — semantic version (required),

     *  initial — the starting state (required),

     *  states — a map of state → allowed action names (required),

     *  transitions — event-driven edges (from, event, to) (required),

     *  actions — named HTTP operations with form bindings (required),

     *  schemas — JSON Schema 2020-12 objects referenced by expects/
        produces (required),

     *  site — site metadata with name and baseUrl (required),

     *  template_id — unique identifier (optional),

     *  title — human-readable name (optional),

     *  description — template description (optional),

     *  openapi — link to OpenAPI spec (optional),

     *  policies — rate limiting and other policies (optional).

     A minimal example follows:





















  Singh & McKay              Expires 5 May 2026                   [Page 3]


  Internet-Draft               AWP Well-Known                November 2025


     {
       "version": "1.0.0",
       "initial": "Anon",
       "states": {
         "Anon":          { "available": ["login"] },
         "Authenticated": { "available": ["search","checkout"] }
       },
       "transitions": [
         { "from": "Anon", "event": "login_ok", "to": "Authenticated" }
       ],
       "actions": {
         "login": {
           "form": { "method": "POST", "target": "/api/login", "contentType": "application/json" },
           "expects":  { "$ref": "#/schemas/LoginInput" },
           "emits": { "onSuccess": "login_ok", "onError": "login_failed" }
         }
       },
       "schemas": {
         "LoginInput": {
           "$schema": "https://json-schema.org/draft/2020-12/schema",
           "type": "object",
           "required": ["email","password"],
           "properties": {
             "email": { "type": "string", "format": "email" },
             "password": { "type": "string", "minLength": 8 }
           }
         }
       },
       "site": {
         "name": "Example Shop",
         "baseUrl": "https://shop.example.com"
       }
     }

     Servers *MAY* use RFC 6570 URI Templates in form.target (e.g., /api/
     search{?q,limit,offset}).  API errors *SHOULD* use RFC 9457 Problem
     Details to allow deterministic branching by clients.

  3.  Discovery via Link Relation

     Origins *SHOULD* advertise the resource with:

     Link: </.well-known/awp.json>; rel="awp"

     The awp relation identifies the AWP manifest for the current origin.






  Singh & McKay              Expires 5 May 2026                   [Page 4]


  Internet-Draft               AWP Well-Known                November 2025


  4.  Security Considerations

     *  The manifest is advisory; authentication and authorization remain
        unchanged.

     *  Do not place secrets or user-specific data in the manifest.

     *  Consider cache lifetimes so changes propagate appropriately.

     *  Implement normal rate-limiting/abuse controls on operational
        endpoints referenced by the manifest.

     *  Cross-origin access is governed by existing Web mechanisms (e.g.,
        CORS).

  5.  IANA Considerations

  5.1.  Well-Known URI Registration

     IANA is requested to register the following in the “Well-Known URIs”
     registry:

     *  *URI Suffix:* awp.json

     *  *Change Controller:* IETF

     *  *Specification Document:* This document, Section 2

     *  *Status:* permanent

     *  *Related Information:* JSON manifest describing site workflows for
        automated agents.

  5.2.  Link Relation Type Registration

     IANA is requested to register the following in the “Link Relation
     Types” registry:

     *  *Relation Name:* awp

     *  *Description:* Identifies the Agent Workflow Protocol (AWP)
        manifest for this origin.

     *  *Reference:* This document, Section 3







  Singh & McKay              Expires 5 May 2026                   [Page 5]


  Internet-Draft               AWP Well-Known                November 2025


  Appendix A.  References

     *  RFC 8615 — Well-Known URIs

     *  RFC 8288 — Web Linking

     *  RFC 6570 — URI Templates

     *  RFC 9457 — Problem Details for HTTP APIs

     *  JSON Schema 2020-12 — Core & Validation

  Authors' Addresses

     Vinay Singh
     Ajna.inc
     Email: vinay@ajna.inc


     Dave McKay
     Verid.id
     Email: dave@verid.id





























  Singh & McKay              Expires 5 May 2026                   [Page 6]


name: draft-yang-ioa-protocol
rev: 00
title: Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent Collaboration
time: 2025-07-20T18:52:34Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-01-21T18:52:34Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.133483+00:00
source: ietf
abstract:
  This draft defines a new agent collaboration protocol, named the
     Internet of Agents Protocol (IoA Protocol), to support distributed,
     heterogeneous agent collaboration in intelligent systems.  The IoA
     Protocol enables dynamic team formation, adaptive task coordination,
     and structured communication among agents with diverse architectures,
     tools, and knowledge sources.  Through a layered architecture and
     extensible message format, it supports decentralized deployment
     across devices and can interoperate with existing frameworks.  The
     protocol is particularly suited to emerging 6G application scenarios
     such as intelligent transportation, smart healthcare, and large-scale
     human–AI teaming.

full_text:
  Dispatch Working Group                                           C. Yang
  Internet-Draft        Beijing University of Posts and Telecommunications
  Intended status: Standards Track                                  Z. Liu
  Expires: 21 January 2026                             Tsinghua University
                                                                   A. Wang
                                                             China Telecom
                                                              20 July 2025


     Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent
                               Collaboration
                         draft-yang-ioa-protocol-00

  Abstract

     This draft defines a new agent collaboration protocol, named the
     Internet of Agents Protocol (IoA Protocol), to support distributed,
     heterogeneous agent collaboration in intelligent systems.  The IoA
     Protocol enables dynamic team formation, adaptive task coordination,
     and structured communication among agents with diverse architectures,
     tools, and knowledge sources.  Through a layered architecture and
     extensible message format, it supports decentralized deployment
     across devices and can interoperate with existing frameworks.  The
     protocol is particularly suited to emerging 6G application scenarios
     such as intelligent transportation, smart healthcare, and large-scale
     human–AI teaming.

  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 21 January 2026.

  Copyright Notice

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



  Yang, et al.             Expires 21 January 2026                [Page 1]


  Internet-Draft                IoA Protocol                     July 2025


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions used in this document . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  IOA Methods . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  IOA Architecture  . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Heterogeneous Agent Integration . . . . . . . . . . . . .   6
       4.3.  Autonomous Team Formation . . . . . . . . . . . . . . . .   7
       4.4.  Session and Task Management Method  . . . . . . . . . . .   7
       4.5.  Message Protocol Overview . . . . . . . . . . . . . . . .   7
     5.  Relation to the A2A Protocol  . . . . . . . . . . . . . . . .   8
     6.  Future Enhancements for 6G-Enabled IoA Protocol . . . . . . .   9
       6.1.  Distributed Agent Registration and Discovery  . . . . . .  10
       6.2.  Positioning of the Protocol in the Network Layering
             System  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.3.  Enhanced Scalability and Fault Tolerance  . . . . . . . .  11
       6.4.  Semantic Interoperability and Ontology Alignment  . . . .  11
       6.5.  Security and Privacy Enhancements . . . . . . . . . . . .  11
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     With the rapid advancement of large language models (LLMs) and
     multimodal autonomous agents, modern intelligent systems are
     increasingly constructed as collaborative networks of multiple
     agents.  These agents are expected to work together to solve complex,
     open-ended tasks.  However, they often differ in capabilities, tools,
     runtime environments, and communication patterns, leading to
     significant challenges in interoperability, dynamic coordination, and
     cross-device deployment.  As a result, current multi-agent frameworks
     fall short of the flexibility and generality required in real-world
     applications.





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


  Internet-Draft                IoA Protocol                     July 2025


     In a typical collaborative setting shown in Figure 1, agents with
     specialized functions—including a Google Scholar Agent for academic
     search, an AI Research Specialist for conceptual planning, a PDF
     Agent for document analysis, and an Academic Writing Agent for
     content generation—must work together to complete a research paper on
     “Internet of Agents.” These agents are distributed across devices
     (e.g., laptops, edge nodes, cloud services), and each relies on
     different execution frameworks or data formats.

  +---------------------------------------------------------------------------------------+
  |                                                                                       |
  |                 Task: Write a research paper on "Internet of Agents"                  |
  |                                                                                       |
  |        +----------------+        +----------------+        +----------------+         |
  |        | AI Research    |<------>| Google Scholar |<------>| Academic       |         |
  |        | Specialist     |        | Agent          |        | Writing Agent  |         |
  |        | (Device A)     |        | (Device B)     |        | (Device C)     |         |
  |        +----------------+        +----------------+        +----------------+         |
  |                    \                     |                       /                    |
  |                     \                    |                      /                     |
  |                      \                   |                     /                      |
  |                       \                  |                    /                       |
  |                        \                 |                   /                        |
  |                         \                |                  /                         |
  |                          +---------------+-----------------+                          |
  |                                          |                                            |
  |                                 +----------------+                                    |
  |                                 | PDF Agent      |                                    |
  |                                 | (Device D)     |                                    |
  |                                 +----------------+                                    |
  |                                          |                                            |
  |                             +------------+-------------+                              |
  |                             |                          |                              |
  |                             |       IoA Server         |                              |
  |                             |                          |                              |
  |                             +--------------------------+                              |
  |                                                                                       |
  +---------------------------------------------------------------------------------------+

                        Figure 1: Multi-agent collaboration scenario

     When the Google Scholar Agent encounters a specialized PDF parsing
     task beyond its capability, existing frameworks often fail to
     dynamically recruit the PDF Agent due to rigid team formation rules.
     Likewise, when the AI Research Specialist and Writing Agent attempt
     to synchronize intermediate results in real time, inflexible
     communication channels may result in delays or dropped information.




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


  Internet-Draft                IoA Protocol                     July 2025


     Existing solutions exhibit several key limitations:

     *  Closed frameworks that restrict integration with third-party
        agents such as AutoGPT or Open Interpreter;

     *  Single-device simulation that fails to reflect cross-device
        deployment scenarios typical in edge-cloud collaboration;

     *  Hard-coded workflows that prevent agents from switching between
        synchronous and asynchronous task execution at runtime.

     To address these challenges, this draft introduces the Internet of
     Agents (IoA) Protocol—a layered, extensible collaboration standard
     designed for intelligent multi-agent systems.  The core goal of the
     protocol is to enable seamless collaboration among heterogeneous
     agents across devices, tools, and execution environments.  It
     supports:

     *  Agent integration via a standardized interface and registration
        mechanism;

     *  Dynamic team formation across distributed environments;

     *  Finite-state machine-based session control for flexible and
        autonomous dialogue management;

     *  Structured message formats with group routing, task assignment,
        and response coordination.

     The design of the IoA Protocol aligns naturally with the vision of 6G
     networks, which aim to support ubiquitous intelligence through large-
     scale, low-latency, and semantic-driven communication.  By enabling
     agent collaboration across edge devices, mobile terminals, and cloud
     nodes, IoA complements 6G’s emphasis on edge-cloud-device
     coordination and distributed AI.  Its structured message design,
     dynamic team formation, and abstracted dialogue control offer the
     necessary protocol foundation to orchestrate intelligent services
     over future 6G infrastructures.

  2.  Conventions used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119] .







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


  Internet-Draft                IoA Protocol                     July 2025


  3.  Terminology

     The following terms are defined in this draft:

     *  IoA: Internet of Agents, a protocol enabling distributed
        collaboration among heterogeneous agents across devices and 6G
        networks, defined in Section 4

     *  Agent Registry Block: A server-side module storing structured
        capability descriptions of all registered agents, supporting
        semantic search for team formation, defined in Section 4

     *  Team Formation Block: A client-side module responsible for
        initiating, joining, or disbanding agent teams based on task
        requirements, including nested sub-teams, defined in Section 4

     *  Session State Machine: A finite-state model governing
        collaboration states (Discussion, Synchronous Task Assignment,
        Asynchronous Task Assignment, Pause and Trigger, Conclusion) for
        adaptive dialogue management, defined in Section 4

     *  HTTP: Hypertext Transfer Protocol, a application-layer protocol
        for distributed, collaborative, hypermedia information systems,
        referenced in IoA for interoperability with web-based agents,
        defined in [RFC9110]

     *  JSON-RPC: A remote procedure call protocol encoded in JSON,
        referenced in IoA for structured communication between web-based
        agents, defined in [RFC8259]

     *  QUIC: A transport layer protocol providing secure, low-latency
        communication over UDP, used in IoA for real-time agent messaging,
        defined in [RFC9000]

  4.  IOA Methods

  4.1.  IOA Architecture

     The Internet of Agents Protocol (IoA Protocol) enables distributed
     collaboration among heterogeneous agents through a layered
     architecture and distributed communication protocol.  It supports
     seamless integration across devices, toolchains, and runtime
     environments.

     The IoA system adopts a three-layer architecture implemented
     symmetrically at both the server and client side:





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


  Internet-Draft                IoA Protocol                     July 2025


     *  Server-side: Handles global coordination, agent discovery, group
        management, and message routing.

     *  Client-side: Encapsulates individual agents and provides
        interfaces for team collaboration and local task execution.

     An overview of the layered structure is shown in Figure 2.

  +----------------------------------------------------------------------------+ +----------------------------------------------------------------------------+
  |                                   Server                                   | |                                   Client                                   |
  |----------------------------------------------------------------------------| |----------------------------------------------------------------------------|
  | Interaction Layer:                                                         | | Interaction Layer:                                                         |
  |   - Agent Query Block: Handles semantic agent search queries               | |   - Team Formation Block: Forms/join teams for assigned goals              |
  |   - Group Setup Block: Manages group/team creation                         | |   - Communication Block: Handles chat messaging and event updates          |
  |   - Message Routing Block: Routes messages within chat groups              | |----------------------------------------------------------------------------|
  |----------------------------------------------------------------------------| | Data Layer:                                                                |
  | Data Layer:                                                                | |   - Agent Contact Block: Caches past collaborators                         |
  |   - Agent Registry Block: Stores capability descriptions of all agents     | |   - Group Info Block: Stores task metadata and group state                 |
  |   - Session Management Block: Tracks WebSocket sessions and group states   | |   - Task Management Block: Tracks subtasks, assignment, and progress       |
  |----------------------------------------------------------------------------| |----------------------------------------------------------------------------|
  | Foundation Layer:                                                          | | Foundation Layer:                                                          |
  |   - Data Infra Block: Vector database (e.g., Milvus) for semantic search   | |   - Agent Integration Block: Adapter for third-party agents                |
  |   - Network Infra Block: WebSocket infrastructure                          | |   - Data Infra Block: Local DB (e.g., SQLite)                              |
  |   - Security Block: Authentication and permission control                  | |   - Network Infra Block: WebSocket-based communication                     |
  +----------------------------------------------------------------------------+ +----------------------------------------------------------------------------+

                    Figure 2: Layered architecture of IoA system

  4.2.  Heterogeneous Agent Integration

     IoA supports the integration of heterogeneous agents from diverse
     sources through a unified interface, including third-party agents
     such as AutoGPT, Open Interpreter, and embodied robotic agents.

     When a new agent joins the IoA, its client wrapper undergoes a
     registration process with the server.  During this registration, the
     agent is expected to provide a comprehensive description of its
     capabilities, skills, and domains of expertise.  For an agent c_i,
     its description is denoted as d_i, and is stored in the Agent
     Registry Block within the Data Layer of the server.

     The set of all registered agents is denoted as C = {c₁, c₂, ..., cₙ},
     where each c_i is associated with its capability description d_i.
     This mechanism enables future semantic matching and intelligent task
     allocation.






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


  Internet-Draft                IoA Protocol                     July 2025


  4.3.  Autonomous Team Formation

     Agents initiate the search process by submitting capability
     requirements to the Agent Query Block.  The server performs semantic
     matching using vector similarity and returns candidate agents from
     the Agent Registry Block.

     IoA supports nested team structures.  An initial group is formed for
     the main goal, and subgroups are recursively created if subtasks
     require new capabilities.  This forms a hierarchical tree structure,
     reducing communication complexity and organizational overhead.

     The entire team formation process is autonomous, task-driven, device-
     agnostic, and self-organizing.

  4.4.  Session and Task Management Method

     IoA models group conversations and collaboration using a finite-state
     machine with five abstract states:

     *  Discussion: Agents engage in general dialogue, exchange ideas, and
        clarify task require ments;

     *  Synchronous task assignment: Tasks are assigned to specific
        agents, pausing the group chat until completion;

     *  Asynchronous task assignment: Tasks are assigned without
        interrupting the ongoing discus sion;

     *  Pause & trigger: The group chat is paused, waiting for the
        completion of specified asyn chronous tasks;

     *  Conclusion: Marks the end of the collaboration, prompting a final
        summary.

     State transitions are managed autonomously by a coordinator agent
     using the conversation history and session context to determine the
     next state and speaker.

  4.5.  Message Protocol Overview

     The agent message protocol in IoA is designed for extensibility and
     flexibility, enabling effective collaboration among heterogeneous
     agents.  Each message consists of two main parts: a header and a
     payload.

     The header contains essential metadata to ensure proper routing and
     processing.  Key fields include:



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


  Internet-Draft                IoA Protocol                     July 2025


     *  sender: The unique identifier of the agent sending the message.

     *  group_id: The identifier of the group chat to which the message
        belongs.

     The payload carries the main content of the message and varies
     depending on message type.  Common fields include:

     *  message_type: Indicates the purpose of the message (e.g.,
        discussion, task assignment, pause and trigger).

     *  next_speaker: The identifier(s) of the agent(s) expected to
        respond.

     The full structure of the message format is illustrated in Figure 3.

        +--------------------------+   +-----------------------------+
        |         Header           |   |  Autonomous Team Formation  |
        +--------------------------+   +-----------------------------+
        | sender: str              |   | goal: str                   |
        | state: enum              |   | team_members: list[str]     |
        | comm_id: str             |   | team_up_depth: int          |
        +--------------------------+   | max_turns: int              |
        +--------------------------+   +-----------------------------+
        |       Discussion         |   |      Task Assignment        |
        +--------------------------+   +-----------------------------+
        | content: str             |   | task_id: str                |
        | type: enum               |   | task_desc: str              |
        | next_speaker: list[str]  |   | task_conclusion: str        |
        +--------------------------+   | task_abstract: str          |
        +--------------------------+   +-----------------------------+
        |    Pause & Trigger       |
        +--------------------------+
        | triggers: list[str]      |
        +--------------------------+

               Figure 3: Structure of IoA Message Protocol

  5.  Relation to the A2A Protocol

     The Agent-to-Agent (A2A) protocol is a communication standard
     designed to support standardized, secure, and modality-agnostic
     interaction between AI agents.  Built upon existing web technologies
     such as HTTP, Server-Sent Events (SSE), and JSON-RPC, A2A emphasizes
     default security, support for long-running tasks, and cross-modality
     interoperability.  It introduces the concept of an AgentCard to
     describe agent capabilities, enabling effective discovery and
     invocation.



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


  Internet-Draft                IoA Protocol                     July 2025


     The Internet of Agents (IoA) protocol shares the same fundamental
     goal with A2A: to break down communication barriers among agents and
     improve the overall efficiency of multi-agent systems.  Both
     protocols rely on network communication technologies and adopt
     similar approaches to message encoding, decoding, and task
     coordination.

     However, the two protocols diverge significantly in terms of design
     philosophy and core mechanisms:

     *  A2A focuses on enabling standardized communication through web-
        native technologies, effectively creating a "free trade zone" for
        agents where interoperability is built-in.  In contrast, the IoA
        protocol draws inspiration from Internet architecture and targets
        the problem of ecosystem fragmentation.  It establishes a system-
        level collaboration platform where heterogeneous agents can freely
        register, discover one another, and collaborate across platforms
        and devices.

     *  A2A is based on HTTP and JSON-RPC for communication, combined with
        task lifecycle management and capability discovery through
        AgentCard.  IoA, on the other hand, offers a more comprehensive
        collaboration framework, including agent registration, autonomous
        nested team formation, finite-state-machine-driven session
        control, and trigger-based task coordination.

     *  While A2A is suitable for standardized task responses and
        streaming updates, it lacks native support for dynamic session
        management and nested subtask structures.  IoA enables adaptive
        interaction flow via a session state machine, and its
        team_up_depth field supports recursive team formation and state
        transitions—making it more effective for handling complex and
        evolving task scenarios.

     In summary, A2A is well-suited for lightweight, standardized task
     interfaces, whereas IoA provides a more flexible and system-oriented
     protocol for large-scale, heterogeneous, and dynamic multi-agent
     collaboration.  The two protocols can complement each other at
     different layers, jointly advancing the development of agent
     communication technologies.

  6.  Future Enhancements for 6G-Enabled IoA Protocol

     To fully realize the potential of 6G-enabled intelligent systems, the
     Internet of Agents (IoA) protocol requires continuous architectural
     evolution and standardization.  This section outlines key directions
     for future enhancements to improve scalability, decentralization,
     interoperability, and network integration.



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


  Internet-Draft                IoA Protocol                     July 2025


  6.1.  Distributed Agent Registration and Discovery

     The current IoA design relies on a centralized server model, which
     may limit scalability and introduce single points of failure under
     large-scale deployment.  A promising direction is to adopt a
     decentralized registration and discovery mechanism, where agents can
     publish their capabilities to a shared registry accessible via a 6G-
     compatible web-based interface.  Inspired by Domain Name System (DNS)
     and search engines, agents could be discoverable through keyword-
     based or semantic search at scale, enabling lightweight browser-based
     or API-based discovery across domains.

     This decentralized lookup layer would allow IoA to support scenarios
     where agents operate across multiple domains, owners, and physical
     networks, while still maintaining secure and authenticated
     interaction through digital signatures and trust mechanisms.

  6.2.  Positioning of the Protocol in the Network Layering System

     To achieve efficient integration of the IOA protocol with the 6G
     network protocol stack, the current design primarily positions IOA at
     the application layer, built on top of transport and session
     protocols such as TCP, UDP, WebSocket, and QUIC.  From the
     perspective of functional mapping, the corresponding relationship
     between IOA's three-layer architecture and the computer network
     layers is as follows:

     *  Interaction Layer → Maps to the application layer, responsible for
        high-level logic such as message protocols, group collaboration,
        and session state transitions.

     *  Data Layer → Spans the application layer and session layer,
        managing agent states, group metadata, and context tracking.

     *  Foundation Layer → Corresponds to the transport layer and system
        infrastructure, including secure communication channels (e.g.,
        WebSocket/QUIC), databases, and network service modules.

     Since the IOA protocol involves intelligent behaviors such as agent
     orchestration, semantic-driven interaction, and session control, an
     intelligence layer can be introduced above the traditional
     application layer.  This layer encapsulates core intelligent
     collaboration logic—such as semantic-based agent matching, AI-driven
     session strategy optimization, dynamic task decomposition, and 6G-
     aware team reorganization—into standardized message formats.  This
     layer shields upper-layer applications and lower-layer protocols from
     the complexity of intelligent decision-making, enabling them to focus
     on their core functions without concerning themselves with the



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


  Internet-Draft                IoA Protocol                     July 2025


     details of how intelligence is implemented (e.g., scenario-specific
     task execution at the application layer, reliable data transmission
     at the transport layer).  Its advantages are reflected in:
     standardizing the collaboration of heterogeneous agents, reducing
     integration costs across 6G scenarios; improving communication
     efficiency through semantic compression and 6G feature adaptation;
     and easily expanding to support new intelligent behaviors and 6G
     application scenarios through modular updates of the intelligence
     layer.

  6.3.  Enhanced Scalability and Fault Tolerance

     To scale beyond millions of agents, the IoA protocol should adopt
     sharding and region-based message routing.  Distributed registries
     and dynamic load balancing can reduce latency and avoid bottlenecks.
     Caching of frequent agent metadata at edge nodes is also critical for
     fast retrieval in latency-sensitive 6G use cases.

  6.4.  Semantic Interoperability and Ontology Alignment

     In highly heterogeneous environments, agents may describe their
     capabilities using different terminologies.  To address this, the IoA
     protocol should support ontology mapping and alignment mechanisms.
     This allows agents with differing skill descriptors to still
     interoperate, using shared or translated task definitions during team
     formation and dialogue.

  6.5.  Security and Privacy Enhancements

     For mission-critical 6G scenarios (e.g., autonomous vehicles, medical
     AI), the protocol must incorporate stronger security primitives.
     This includes:

     *  End-to-end encryption with forward secrecy.

     *  Support for zero-trust architectures with agent attestation and
        secure enclaves.

     *  Fine-grained access control based on agent role and session
        context.











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


  Internet-Draft                IoA Protocol                     July 2025


  7.  Security Considerations

     IOA servers and agents store sensitive data including capability
     descriptors, session state metadata, and task execution logs, which
     consume memory and computational resources.  To mitigate risks of
     resource exhaustion and unauthorized access, [RFC6749] (OAuth 2.0)
     mandates that IOA entities must authenticate peers via token-based
     validation before processing registration requests or collaboration
     messages.  Additionally, all data transmission between entities must
     use TLS 1.3 as specified in [RFC8446] to ensure confidentiality and
     integrity, preventing eavesdropping or tampering.

  8.  IANA Considerations

     [TBD] This document defines a new protocol for heterogeneous agent
     collaboration: the Internet of Agents (IoA) Protocol.  The protocol's
     code point allocation will be determined in subsequent revisions as
     the standard matures, in accordance with IANA's relevant registration
     procedures.

  9.  Acknowledgement

     Thanks Weize Chen, Ziming You, Ran Li, Yitong Guan, Chen Qian,
     Chenyang Zhao, Ruobing Xie, Maosong Sun and Yu Hao for their valuable
     comments on this draft.

  10.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
                Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
                Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
                2015, <https://www.rfc-editor.org/info/rfc7432>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.





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


  Internet-Draft                IoA Protocol                     July 2025


     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/info/rfc9000>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

  Authors' Addresses

     Cheng Yang
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     Beijing, 100876
     China
     Email: yangcheng@bupt.edu.cn


     Zhiyuan Liu
     Tsinghua University
     30 Shuangqing Road, Haidian District
     Beijing
     Beijing, 100084
     China
     Email: liuzy@tsinghua.edu.cn


     Aijun Wang
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: wangaj3@chinatelecom.cn










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


name: draft-blahaj-grow-rpki-oauth
rev: 00
time: 2026-01-02T07:09:04Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-01-01T13:36:57Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.137306+00:00
source: ietf
title:
  Attesting the Identities of Parties in OpenID Connect (OIDC) using the Resource Public Key Infrastructure (RPKI)

abstract:
  The Peering API currently under discussion in the GROW Working Group
     does not provide a standardised mechanism to authenticate parties
     engaged in the Peering API.  This document specifies a method to
     attest as to the identities of parties in an OpenID Connect (OIDC)
     exchange, binding the authentication flow to agents of ASNs.

  Discussion

     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.molgen.mpg.de/q/rpki-peering-api-discovery.

full_text:
  grow                                                           Q. Misell
  Internet-Draft                                                  AS207960
  Intended status: Standards Track                            30 June 2025
  Expires: 1 January 2026


   Attesting the Identities of Parties in OpenID Connect (OIDC) using the
                 Resource Public Key Infrastructure (RPKI)
                      draft-blahaj-grow-rpki-oauth-00

  Abstract

     The Peering API currently under discussion in the GROW Working Group
     does not provide a standardised mechanism to authenticate parties
     engaged in the Peering API.  This document specifies a method to
     attest as to the identities of parties in an OpenID Connect (OIDC)
     exchange, binding the authentication flow to agents of ASNs.

  Discussion

     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.molgen.mpg.de/q/rpki-peering-api-discovery.

  Status of This Memo

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

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

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 1 January 2026.

  Copyright Notice

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





  Misell                   Expires 1 January 2026                 [Page 1]


  Internet-Draft             RPKI Attested OIDC                  June 2025


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     2.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Endpoint Discovery  . . . . . . . . . . . . . . . . . . . . .   4
     5.  Extensions to IdP Metadata  . . . . . . . . . . . . . . . . .   4
     6.  Extensions to Dynamic Client Registration . . . . . . . . . .   4
     7.  RPKI Attested JWK Set . . . . . . . . . . . . . . . . . . . .   5
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
       9.1.  RPKI Signed Message well-known purposes . . . . . . . . .   5
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     An API allowing programmatic configuration of BGP peering sessions is
     defined in [I-D.ramseyer-grow-peering-api].  The API defined in that
     document does not provide a standardised mechanism to authenticate
     parties engaged in the Peering API.  To this end, this documents
     defines extensions to OpenID Connect to allow verifying an AS's
     Identity Provider (IdP), its Relying Parties (RP), and agents
     thereof.

  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 [BCP14] when, and only
     when, they appear in all capitals, as shown here.









  Misell                   Expires 1 January 2026                 [Page 2]


  Internet-Draft             RPKI Attested OIDC                  June 2025


  2.  Problem statement

     The Peering API currently under discussion at the Global Routing
     Operations Working Group [I-D.ramseyer-grow-peering-api]is in need of
     a way to authenticate parties involved in such API exchanges.  The
     draft, as it is currently conceived, relies on the OAuth service
     provided by PeeringDB to authenticate Autonomous Systems and their
     agents.  It is undesirable, in the scope of an IETF document to rely
     on such external parties as a core part of the specification.  We
     therefore set out to define an alternative OAuth federation mechanism
     based on the RPKI[RFC6480], one that is not tied to one entity, and
     is usable by anyone within the Internet ecosystem.

     The reasons for adapting OAuth and not defining a new authentication
     mechanism are twofold; firstly, OAuth is a familiar protocol for
     authentication in application development, and many libraries exist
     that support it, secondly, and perhaps more crucially, is the large
     extant deployment of corporate IdPs using OAuth.  From discussions
     from the proponents of the Peering API, the need to identify not only
     the Autonomous System from which the request originates, but in
     addition _which agent_ of the AS has made the request.  That is, it
     would be beneficial be able to say not only that AS64496 submitted a
     peering request, but that John of AS64496 did so.

     Given the prevalence of corporate IdPs, specifically those that
     support OAuth, it seems fitting to extend this to also provide
     authentication to a peering API.  OAuth already provides the dynamic
     client registration, and token introspection, required to integrate a
     third party service with a corporate IdP.  This document serves to
     build upon this by creating a tie between resources attested in the
     RPKI and their IdPs and RPs.

     In addition to the peering API, there likely will be other APIs one
     may wish to establish between ASNs, and this OAuth extensions
     provides a natual basis for them.

  3.  Terminology

     For brevity, within this document the following terminology is used

     Service Provider  An AS offering a (e.g. REST API) service to other
        ASes.

     Consumer  An AS consuming the service provided by the Service
        Provider.






  Misell                   Expires 1 January 2026                 [Page 3]


  Internet-Draft             RPKI Attested OIDC                  June 2025


  4.  Endpoint Discovery

     All endpoints required for this protocol to function not defined
     herein, are to be discovered via OpenID Connect Discovery
     [OpenID.Discovery]

  5.  Extensions to IdP Metadata

     An RP must be able to verify that an IdP is allowed to issue
     authorization tokens for resources.  To this end, the JWK Key Set
     presented in the OpenID Connect Discovery jwks_url MUST be an RPKI
     Attested JWK Set. That is, the JWK used to sign the JWTs used in an
     OAuth exchange is itself signed using the RPKI, attesting that this
     IdP is authoritative for Internet resources.  An IdP is considered
     authoritative for all resources in the EE Certificate contained in
     the RSM used to attest the JWK Key Set.

     An RP SHOULD regularly check for updates to the JWK Key Set, and its
     associated attestation, and MUST not cache the attestation and its
     attested resources beyond the end of the validity of the RSM.

  6.  Extensions to Dynamic Client Registration

     Once the RP of a Service Provider is aware which IdP will be used by
     the Consumer to authenticate to it, it must register with that IdP,
     if it hasn't done so already.  This allows it to be issued an
     authentication token scoped to it, and to engage in Token
     Introspection [OpenID.Core] to verify tokens given in API requests.

     The manner in which the base URL of an IdP is communicated to an RP
     is out of the scope of this document, and is intended to be defined
     in subservient documents.

     The RP submits an OIDC Dynamic Client Registration request to the
     Consumer's IdP [OpenID.Registration], containing any well-known
     scopes as defined in subservient specifications required for which
     services the RP provides.  Updates to these scopes in future may be
     made via the Client Configuration Endpoint.

     Such that the Idp can validate the identity of the RP making the
     registration request, the request MUST be signed using HTTP
     signatures[RFC9421].  The signature keyid parameter MUST be URL to an
     RPKI Attested JWK Set.  The fragment of such a URL is used to
     identify the exact kid used to sign the request.

     This signature MUST be over at least the following components:

     *  @method



  Misell                   Expires 1 January 2026                 [Page 4]


  Internet-Draft             RPKI Attested OIDC                  June 2025


     *  @target-uri

     *  content-digest

     The body of the HTTP request MUST be included in the signature by the
     use of a HTTP Digest [RFC9530].

     This signature MUST contain at least the following parameters:

     *  @created

     *  @nonce

     *  @keyid

     The response to such a registration request need not be signed, as
     the identity of the IdP is validated via its TLS domain identity and
     its attested discovery metadata.

  7.  RPKI Attested JWK Set

     An RPKI Attested JWK Set is as a normal JWK Set[RFC7517], that MUST
     contain an rpki_attestation parameter.  The construction of such a
     parameter is the base64url encoding [RFC7515] of an RPKI Signed
     Message over the JWK Set without the rpki_attestation parameter,
     using the JWK Thumbprint JSON hash input calculation
     algorithm[RFC7638].

     The audience field for such an RSM MUST be the Global Audience
     (1.3.6.1.5.5.TBD.0.0).

     The purpose field for such an RSM MUST be the OAuth Attestation
     Audience (1.3.6.1.5.5.TBD.1.1).

  8.  Security Considerations

     The security considerations of this protocol have been left until the
     protocol proper is further refined.

  9.  IANA Considerations

  9.1.  RPKI Signed Message well-known purposes

     The IANA is requested to allocate a new OID under the "RPKI Signed
     Message well-known purposes" registry:






  Misell                   Expires 1 January 2026                 [Page 5]


  Internet-Draft             RPKI Attested OIDC                  June 2025


                +=========+===================+===============+
                | Decimal | Description       | References    |
                +=========+===================+===============+
                | 1       | OAuth Attestation | This document |
                +---------+-------------------+---------------+

                                    Table 1

  10.  References

  10.1.  Normative References

     [BCP14]    Best Current Practice 14,
                <https://www.rfc-editor.org/info/bcp14>.
                At the time of writing, this BCP comprises the following:

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

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

     [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
                Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
                February 2012, <https://www.rfc-editor.org/info/rfc6480>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/info/rfc7517>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.

     [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
                Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
                2015, <https://www.rfc-editor.org/info/rfc7638>.

     [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
                Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
                February 2024, <https://www.rfc-editor.org/info/rfc9421>.

     [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
                DOI 10.17487/RFC9530, February 2024,
                <https://www.rfc-editor.org/info/rfc9530>.



  Misell                   Expires 1 January 2026                 [Page 6]


  Internet-Draft             RPKI Attested OIDC                  June 2025


     [I-D.ramseyer-grow-peering-api]
                Aguado, C., Griswold, M., Ramseyer, J., Servin, A., and T.
                Strickx, "Peering API", Work in Progress, Internet-Draft,
                draft-ramseyer-grow-peering-api-05, 30 May 2024,
                <https://datatracker.ietf.org/doc/html/draft-ramseyer-
                grow-peering-api-05>.

     [OpenID.Core]
                Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
                C. Mortimore, "OpenID Connect Core 1.0 incorporating
                errata set 2", The OpenID Foundation, 15 December 2023,
                <https://openid.net/specs/openid-connect-core-1_0.html>.

     [OpenID.Discovery]
                Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
                Connect Discovery 1.0 incorporating errata set 2", The
                OpenID Foundation, 15 December 2023,
                <https://openid.net/specs/openid-connect-discovery-
                1_0.html>.

     [OpenID.Registration]
                Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
                Dynamic Client Registration 1.0 incorporating errata set
                2", The OpenID Foundation, 15 December 2023,
                <https://openid.net/specs/openid-connect-registration-
                1_0.html>.

  Author's Address

     Q Misell
     AS207960 Cyfyngedig
     13 Pen-y-lan Terrace
     Caerdydd
     CF23 9EU
     United Kingdom
     Email: q@as207960.net, q@magicalcodewit.ch
     URI:   https://magicalcodewit.ch














  Misell                   Expires 1 January 2026                 [Page 7]


name: draft-cui-nmrg-llm-benchmark
rev: 01
title: A Framework to Evaluate LLM Agents for Network Configuration
time: 2025-12-30T09:04:54Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-07-03T09:04:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.140523+00:00
source: ietf
abstract:
  This document specifies an evaluation framework and related
     definitions for intent-driven network configuration using Large
     Language Model(LLM)-based agents.  The framework combines an
     emulator-based interactive environment, a suite of representative
     tasks, and multi-dimensional metrics to assess reasoning quality,
     command accuracy, and functional correctness.  The framework aims to
     enable reproducible, comprehensive, and fair comparisons among LLM-
     driven network configuration approaches.

full_text:
  Network Management Research Group                                 Y. Cui
  Internet-Draft                                                    C. Liu
  Intended status: Informational                                    X. Xie
  Expires: 3 July 2026                                 Tsinghua University
                                                                     C. Du
                                                   Zhongguancun Laboratory
                                                          30 December 2025


        A Framework to Evaluate LLM Agents for Network Configuration
                      draft-cui-nmrg-llm-benchmark-01

  Abstract

     This document specifies an evaluation framework and related
     definitions for intent-driven network configuration using Large
     Language Model(LLM)-based agents.  The framework combines an
     emulator-based interactive environment, a suite of representative
     tasks, and multi-dimensional metrics to assess reasoning quality,
     command accuracy, and functional correctness.  The framework aims to
     enable reproducible, comprehensive, and fair comparisons among LLM-
     driven network configuration approaches.

  About This Document

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

     The latest revision of this draft can be found at
     https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.

     Discussion of this document takes place on the Network Management
     Research Group mailing list (mailto:nmrg@irtf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/nmrg.  Subscribe at
     https://www.ietf.org/mailman/listinfo/nmrg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/nobrowning/draft_llm_conf_benchmark.

  Status of This Memo

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







  Cui, et al.                Expires 3 July 2026                  [Page 1]


  Internet-Draft                NetConfBench                 December 2025


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

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 3 July 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Components  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  Task Definition Schema  . . . . . . . . . . . . . . . . .  11
       4.2.  Agent-Network Interface (ANI) . . . . . . . . . . . . . .  13
       4.3.  Task Evaluation Interface . . . . . . . . . . . . . . . .  15
     5.  MCP-Based Implementation  . . . . . . . . . . . . . . . . . .  16
       5.1.  Benefits of MCP Integration . . . . . . . . . . . . . . .  16
       5.2.  MCP Tool Definitions for ANI Operations . . . . . . . . .  17
         5.2.1.  1. get_topology . . . . . . . . . . . . . . . . . . .  17
         5.2.2.  2. get_running_config . . . . . . . . . . . . . . . .  18
         5.2.3.  3. update_config  . . . . . . . . . . . . . . . . . .  19
       5.3.  Additional MCP Tools for Advanced Scenarios . . . . . . .  22
         5.3.1.  batch_configure_devices . . . . . . . . . . . . . . .  22
         5.3.2.  check_device_status . . . . . . . . . . . . . . . . .  22
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  24



  Cui, et al.                Expires 3 July 2026                  [Page 2]


  Internet-Draft                NetConfBench                 December 2025


     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     Network configuration is fundamental to ensuring network stability,
     scalability, and conformance with intended design behavior.
     Effective configuration requires not only a comprehensive
     understanding of network technologies but also advanced capabilities
     for interpreting complex topologies, analyzing dependencies, and
     specifying parameters accurately.  Traditional automation approaches
     such as Ansible playbooks[A2023], NETCONF[RFC6241]/YANG
     models[RFC7950], or program-synthesis methods-either demand extensive
     manual scripting or are limited to narrow problem
     domains[Kreutz2014].  In parallel, Large Language Models (LLMs) have
     demonstrated the ability to interpret natural-language instructions
     and generate device-specific commands, showing promise for intent-
     driven automation in networking.  However, existing work remains
     fragmented and lacks a standardized way to measure whether an LLM can
     truly operate as an autonomous agent in realistic, multi-step
     configuration scenarios.

     Despite encouraging results in individual subtasks, most
     evaluations[Wang2024NetConfEval] rely on static datasets and ad hoc
     metrics that do not reflect real-world complexity.  As a result: -
     There is no common benchmark suite covering diverse configuration
     domains (routing, QoS, security) with clearly defined intents,
     topologies, and ground truth. - Existing tests seldom involve
     interactive environments that emulate vendor-specific device behavior
     or provide runtime feedback on command execution. - Evaluation
     metrics are often limited to simple syntactic checks or isolated
     command validation, failing to capture whether the intended network
     behavior is actually achieved.

     Consequently, it is difficult to compare different LLM approaches or
     to identify gaps in reasoning, context-sensitivity, and error-
     correction capabilities[Long2025][Liu2024][Fuad2024][Lira2024].  To
     address these shortcomings, this document introduce *NetConfBench*, a
     holistic framework that provides: 1.  An emulator-based environment
     (built on GNS3) to simulate realistic device interactions. 2.  A
     benchmark suite of forty tasks spanning routing, QoS, and security,
     each defined by intent, topology, initial state, ground-truth
     configuration, annotated reasoning trace, and expert-crafted
     testcases. 3.  Multidimensional metrics-_reasoning score_, _command
     score_, and _testcase score_-that evaluate an agent's internal
     reasoning coherence, semantic correctness of generated commands, and
     functional outcomes in the emulated network.




  Cui, et al.                Expires 3 July 2026                  [Page 3]


  Internet-Draft                NetConfBench                 December 2025


     NetConfBench aims to enable reproducible, comprehensive comparisons
     among single-turn LLMs, ReAct-style multiturn agents, and knowledge-
     augmented variants, guiding future research toward truly autonomous,
     intent-driven network configuration.

  2.  Terminology

     For clarity within this document, the following terms and
     abbreviations are defined:

     *  Agent: A software component powered by an LLM that consumes a task
        intent, interacts with a network environment, and issues
        configuration commands autonomously.

     *  Configuration Command: A device-specific instruction (e.g., a
        Cisco IOS CLI line or a Juniper Junos set statement) sent by the
        agent to a network device.

     *  Environment: An emulated or real network instance that exposes
        device status, topology information, and feedback on applied
        commands.

     *  Intent: A high-level specification of desired network behavior or
        objective, expressed in natural language or a structured format
        defined in this document.

     *  Task: A single evaluation unit defined by (1) a scenario category,
        (2) an environment topology, (3) initial device configurations,
        and (4) an intent.  The agent is evaluated on its ability to
        fulfill the intent in the given environment.

     *  Testcase: A concrete, executable set of verification steps (e.g.,
        ping tests, traffic-flow validation, policy checks) used to assert
        whether the agent's final configuration satisfies the intent.

     *  MCP (Model Context Protocol): An open standard protocol designed
        to facilitate communication between LLMs and external data sources
        or tools, enabling standardized tool discovery, invocation, and
        result handling.

  3.  Framework Overview










  Cui, et al.                Expires 3 July 2026                  [Page 4]


  Internet-Draft                NetConfBench                 December 2025


     +------------------+
     |    Task Dataset  |                     +-------------------------+
     |+----------------+|    +-----------+    |        Evaluator        |
     ||Network Intents ||(1) |           |(4) |+----------+ +----------+|
     ||+--------+      |---->| LLM Agent |<--->|Reasoning | |Grnd Truth||
     |||Routing |      ||    |           |    ||Trajectory| |Reasoning ||
     |||Policy  | +---+||    +-----------+    |+----------+ +----------+|
     ||+--------+ |QoS|||          |          |     \             /     |
     ||+--------+ +---+||          |          |      Rouge/Cos. Sim.    |
     |||Security|      ||         (3)         |                         |
     ||+--------+      ||          |          |+----------+ +----------+|
     |+----------------+|          |       (5)|| Final    | |Grnd Truth||
     |+----------------+|          |        +->| Configs  | |Configs   ||
     ||Network Topology||    +-----------+  | |+----------+ +----------+|
     ||+-----+ +-----+ ||(2) |Environment|  | |     \             /     |
     |||Nodes| |Links| |---->|           |-+  |    Precision/Recall     |
     ||+-----+ +-----+ ||    | R2 --- R1 |    |                         |
     |+----------------+|    | |(GNS3)|  |(6) | +---------------------+ |
     |                  |    | R3 --- R4 |<-->| |     Testcases       | |
     |+----------------+|(2) |           |    | +---------------------+ |
     ||Initial Configs |---->| Emulator- |    |            |            |
     |+----------------+|    |  based    |    |        Pass Rate        |
     +------------------+    +-----------+    +-------------------------+

     Legend:
     (1)Task Assignment             (2)Environment Setup
     (3)Interactive Task Execution  (4)Reasoning Trajectory Export
     (5)Final Configuration Export  (6)Testcase Execution

     Figure 1: The NetConfBench Framework

     The proposed framework is shown in Figure 1.  The flow begins with a
     *Task Dataset* defining network intents and topologies.  The *LLM
     Agent* perceives the environment, reasons about required actions, and
     applies configuration commands.  The *Environment* simulates or
     controls real devices, providing feedback for each action.  Finally,
     the *Evaluator* compares the agent's outputs against ground-truth
     configurations and reasoning, computing scores for accuracy and
     completion.

     The framework supports multiple communication protocols for agent-
     environment interaction, including direct API calls and standardized
     protocols such as MCP.  When using MCP, network operations are
     encapsulated as tools that can be discovered and invoked by the LLM
     agent through the MCP client-server architecture.






  Cui, et al.                Expires 3 July 2026                  [Page 5]


  Internet-Draft                NetConfBench                 December 2025


  3.1.  Components

     NetConfBench consists of four key components:

     1.  *Task Dataset*
         A repository of forty configuration tasks, each defined as a JSON
         object with:

         *  *Intent*: One or more natural language instructions.

         *  *Topology*: A list of node names and link definitions.

         *  *Initial Configuration*: The initial configuration state of
            all nodes.

         *  *Ground Truth Configuration*: Expert-validated CLI commands
            that achieve the intent.

         *  *Ground Truth Reasoning*: A textual record of the agent's
            step-by-step reasoning that maps high-level intent to low-
            level configuration actions.

         *  *Testcases*: A set of verification procedures (e.g., _show_,
            _ping_, _ACL_ checks) that confirm functional intent
            satisfaction.

     2.  *Emulator Environment*
         Built on GNS3, this component launches official vendor images for
         routers and switches, replicating realistic CLI behavior.  Key
         interfaces include:

         *  *Agent-Network Interface (ANI)*: Based on the key stages
            commonly involved in intent-driven network configuration, the
            framework provides an Agent-Network Interface to facilitate
            structured interactions between the LLM agent and the emulated
            network environment.  This interface supports four core
            actions: get-topology, get-running-cfg, update-cfg, and
            execute_validation.

            -  get-topology: provides this information in a format
               interpretable by the LLM.

            -  get-running-cfg: enables the agent to obtain the active
               configurations of specified devices, providing essential
               context for planning subsequent updates.






  Cui, et al.                Expires 3 July 2026                  [Page 6]


  Internet-Draft                NetConfBench                 December 2025


            -  update-cfg: allows the agent to apply new configuration
               commands and provides detailed feedback on their execution,
               including whether each command was accepted or resulted in
               any errors.

            -  execute_validation: accepts a device name and a command
               string as parameters and returns the resulting output.

         *  *Task Evaluation Interface*: To enable reliable and objective
            assessment of the LLM agent's configuration behavior, the
            environment provides a Task Evaluation Interface that allows
            the evaluation module to access relevant execution results.
            Specifically, this interface supports:

            -  *Exporting the final configurations of all devices*: This
               allows for direct comparison with ground truth
               configurations to evaluate the correctness and completeness
               of the agent's output.

            -  *Executing a set of predefined testcases*: These testcases
               are designed to verify whether the resulting network
               behavior accurately reflects the intended configuration
               objectives, as defined by the network intent.

     3.  *LLM Agent*
         A modular component that can be implemented with any LLM (open-
         source or closed-source).  It interacts with the emulator via the
         *Agent-Network Interface* (ANI), issuing queries such as get-
         topology, get-running-cfg, update-cfg, and execute_validation.
         Agents may use:

         *  *Single-Turn Generation*: The entire reasoning and command
            generation in one pass.

         *  *ReAct-Style Multi-Turn Interaction*: Interleaved reasoning
            and actions, with runtime feedback guiding subsequent steps.

         *  *External Knowledge Retrieval*: (Optional) Queries to a
            command manual to resolve vendor-specific syntax.

     4.  *Evaluator*
         Computes three core metrics for each task:

         *  *Reasoning Score (S_reasoning)*

            The reasoning score evaluates whether the agent can coherently
            map network intents to concrete configuration actions through
            semantically aligned reasoning.  This score compares the



  Cui, et al.                Expires 3 July 2026                  [Page 7]


  Internet-Draft                NetConfBench                 December 2025


            agent's reasoning process with a predefined ground truth
            reasoning process, focusing on logical consistency and
            semantic similarity.

            For one-shot prediction, prompts are designed to elicit the
            reasoning process prior to command generation, enabling direct
            comparison.  For multi-turn interaction, an auxiliary LLM
            summarizes the interleaved steps into a unified reasoning
            process, which is then compared against the ground truth.  The
            reasoning score is computed using cosine similarity:

            S_reasoning = (r_agent * r_gt) / (||r_agent|| * ||r_gt||)

            where r_agent is the embedding of the agent's reasoning
            process, and r_gt is the embedding of the ground truth
            reasoning process.

         *  *Command Score (S_command)*

            This evaluation comprehensively assesses the effectiveness of
            configuration commands generated by the agent.  While
            syntactic correctness is a prerequisite, it does not ensure
            that configuration commands are correctly applied to the
            device, particularly when commands must be issued within
            specific configuration contexts.

            After the agent completes its configuration task, the final
            configurations of all devices are exported and compared to
            their initial configurations to extract the set of commands
            that were actually applied.  Hierarchical parsing using the
            Python library ciscoconfparse ensures structural completeness
            during comparison.  Since certain configuration parameters
            (e.g., ACL numbers, route policy names) are manually defined
            and do not have fixed values, wildcard-based fuzzy matching is
            introduced to ignore non-essential differences and focus on
            semantic equivalence.

            Based on the extracted command sets, standard precision and
            recall are computed: - Precision measures the proportion of
            correctly generated commands among all generated commands -
            Recall measures the proportion of correctly generated commands
            relative to the ground truth command set

            The command score is reported as the harmonic mean of
            precision and recall:

            S_command = (2 * Precision * Recall) / (Precision + Recall)




  Cui, et al.                Expires 3 July 2026                  [Page 8]


  Internet-Draft                NetConfBench                 December 2025


         *  *Testcase Score (S_testcase)*

            While command-level evaluation based on configuration
            differences can effectively measure the semantic correctness
            of generated commands, it does not fully reflect whether the
            configuration actually achieves the intended network
            behaviors.  To address this limitation, a testcase-driven
            evaluation strategy is introduced that directly verifies the
            functional correctness of the agent's configuration in the
            target environment.

            A set of validation testcases is defined for each task, where
            each testcase encodes a network intent in the form of
            executable verification commands.  To support complex tasks
            involving multiple sub-goals, the overall intent is decomposed
            into sub-intents based on node-specific configuration
            objectives.  Each sub-intent is then formulated as an
            individual testcase to enable fine-grained evaluation and
            enhance interpretability.

            Examples of testcases include: - *Routing intent*: Verifying
            the next hop selection on intermediate routers to confirm end-
            to-end path correctness - *ACL intent*: Simulating traffic
            flows and validating whether they are allowed or denied as
            expected - *QoS intent*: Inspecting interface statistics to
            check whether QoS policies are properly enforced

            The testcase score is defined as the proportion of passed
            testcases among all defined testcases:

            S_testcase = |Passed Testcases| / |Total Testcases|

            This score reflects the agent's ability to produce
            configurations that meet functional requirements and
            demonstrates practical applicability in real-world deployment
            scenarios.

  3.2.  Workflow

     The evaluation workflow for each task proceeds through six stages:

     1.  *Task Assignment*
         NetConfBench selects a task from the JSON dataset and provides
         only the high-level intent(s) to the LLM agent.







  Cui, et al.                Expires 3 July 2026                  [Page 9]


  Internet-Draft                NetConfBench                 December 2025


     2.  *Environment Setup*
         The framework instantiates a GNS3 topology based on the task's
         topology and applies the startup-config to each device.  Once the
         emulated network reaches a stable state, control transfers to the
         agent.

     3.  *Interactive Execution*
         The LLM agent receives the partial prompt containing:

         *  The API specification for get-topology, get-running-cfg,
            update-cfg, and execute_validation.

         *  The natural language intent.

         *  (Optionally) Device model/version hints.

         *  The agent issues a sequence of API calls; for single-turn
            agents, it outputs reasoning followed by a batch of CLI
            commands.  For multi-turn agents, it alternates reasoning
            traces and API calls.  When using MCP, network operations are
            encapsulated as tools that can be discovered and invoked by
            the LLM agent through the MCP client-server architecture.

     4.  *Reasoning Trajectory Export*
         After execution completes (agent signals "task done" or after a
         predefined command budget), NetConfBench captures the entire
         reasoning log:

         *  For single-turn: the reasoning paragraph embedded in the LLM's
            output.

         *  For ReAct: an auxiliary summarization LLM condenses the
            interleaved reasoning and actions into a single coherent
            trace.

     5.  *Final Configuration Export*
         The framework uses the Task Evaluation Interface to extract the
         final running configs from each device.

     6.  *Testcase Execution and Scoring*

         *  *Command Score:* Hierarchical diff against ground truth
            commands.

         *  *Testcase Score:* Execute each testcase in sequence; record
            pass/fail.





  Cui, et al.                Expires 3 July 2026                 [Page 10]


  Internet-Draft                NetConfBench                 December 2025


         *  *Reasoning Score:* Compute embedding similarity between the
            agent's reasoning trace and ground truth reasoning.

     The final per-task score is typically reported as a tuple
     (S_reasoning, S_command, S_testcase).  Aggregate results across the
     forty tasks enable comparisons among LLMs and interaction strategies.

  4.  Data Model

     This section specifies the JSON schemas and interface conventions
     used to represent tasks and to enable structured interaction between
     the LLM agent and the emulated environment.

  4.1.  Task Definition Schema

     Each configuration task is defined as a JSON object with the
     following structure:


































  Cui, et al.                Expires 3 July 2026                 [Page 11]


  Internet-Draft                NetConfBench                 December 2025


     {
       "task_name": "Static Routing",
       "intents": [
         "NewYork: create a static route pointing to the Loopback0 on
         Washington, traffic should pass the 192.168.1.0 network.",
         "NewYork: create a backup static route pointing to the Loopback0
         on Washington, administrative distance should be 100."
         ...
       ],
       "topology": {
         "nodes": ["NewYork", "Washington"],
         "links": [
           "NewYork S0/0 <-> Washington S0/0 ",
           "NewYork S0/1 <-> Washington S0/1"
         ]
       },
       "startup_configs": {
         "NewYork": "!\r\nversion 12.4\r\nservice timestamps
         debug datetime msec\r\n...",
         "Washington": "!\r\nversion 12.4\r\nservice timestamps
         debug datetime msec\r\n...",
       },
       "ground_truth_configs": {
         "NewYork": [
           "ip route 2.2.2.0 255.255.255.252 192.168.1.2",
           "ip route 2.2.2.0 255.255.255.252 192.168.2.2 100"
         ],
         ...
       },
       "ground_truth_reasoning": "NewYork to Washington Loopback
       (primary path): add a static route for Washington's
       Loopback0 network (2.2.2.0/30) pointing to the
       next-hop 192.168.1.2...",
       "testcases": [
         {
           "name": "Static Route from NewYork to Washington",
           "expected_result": {
             "protocol": "static",
             "next_hop": "192.168.1.2"
           }
         },
         ...
       ]
     }







  Cui, et al.                Expires 3 July 2026                 [Page 12]


  Internet-Draft                NetConfBench                 December 2025


  4.2.  Agent-Network Interface (ANI)

     The Agent-Network Interface defines the minimal API primitives
     necessary for intent-driven configuration.  Each primitive uses JSON-
     RPC style request/response with the following methods:

     1.  *get-topology*

         *  *Request*:

            {
              "method": "get-topology",
              "params": {
                "devices": ["R1", "R2", ...]
              }
            }

         *  *Response*:

            {
              "topology": {
                "nodes": [...],
                "links": [...]
              }
            }

         *  *Description*: Returns the full topology for the specified
            subset of devices.  If "devices" is empty or omitted, returns
            the entire topology.

     2.  *get-running-cfg*

         *  *Request*:

            {
              "method": "get-running-cfg",
              "params": {
                "device": "R1"
              }
            }

         *  *Response*:









  Cui, et al.                Expires 3 July 2026                 [Page 13]


  Internet-Draft                NetConfBench                 December 2025


            {
              "running_config": "
               interface Gig0/0
               ip address 192.168.1.1 255.255.255.255
               ...
              "
            }

         *  *Description*: Retrieves the active (running) configuration of
            the specified device.

     3.  *update-cfg*

         *  *Request*:

            {
              "method": "update-cfg",
              "params": {
                "device": "R1",
                "commands": [
                  "configure terminal",
                  "ip route 2.2.2.0 255.255.255.252 192.168.1.2"
                ]
              }
            }

         *  *Response*:

            {
              "results": [
                { "command": "configure terminal", "status": "success" },
                {
                "command": "ip route 2.2.2.0 255.255.255.252 192.168.1.2",
                "status": "success" }
              ]
            }

         *  *Description*: Applies a sequence of CLI commands to the
            specified device.  Returns per-command status and any error
            messages.

     4.  *execute_validation*

         *  *Request*:







  Cui, et al.                Expires 3 July 2026                 [Page 14]


  Internet-Draft                NetConfBench                 December 2025


            {
              "method": "execute_validation",
              "params": {
                "device": "R1",
                "command": "show ip route 2.2.2.0 255.255.255.252"
              }
            }

         *  *Response*:

            {
              "output": "S 2.2.2.0/30 [1/0] via 192.168.1.2"
            }

         *  *Description*: Executes a read-only command on the specified
            device and returns its output.  Must not alter device state.

  4.3.  Task Evaluation Interface

     After the agent signals completion, the framework uses the Task
     Evaluation Interface to retrieve results:

     *  *export-final-cfg*

        -  *Request*:

           {
             "method": "export-final-cfg"
           }

        -  *Response*:

           {
             "configs": {
               "R1": "!\nversion 15.2\n...",
               "R2": "!\nversion 15.2\n..."
             }
           }

        -  *Description*: Returns the final running-configuration of each
           device.

     *  *run-testcases*

        -  *Request*:






  Cui, et al.                Expires 3 July 2026                 [Page 15]


  Internet-Draft                NetConfBench                 December 2025


           {
             "method": "run-testcases",
             "params": {
               "testcases": [
                 {
                   "device": "R1",
                   "commands": ["show ip route 2.2.2.0 255.255.255.252"],
                   "expected_output": "S 2.2.2.0/30 [1/0] via 192.168.1.2"
                 },
                 ...
               ]
             }
           }

        -  *Response*:

           {
             "results": [
               {
                 "name": "Verify primary static route on R1",
                 "status": "pass"
               },
               {
                 "name": "Verify backup static route on R1",
                 "status": "fail"
               }
             ]
           }

        -  *Description*: Executes each verification command sequence on
           the appropriate device and compares actual output against
           expected_output (regular expression).  Returns pass/fail for
           each testcase.

  5.  MCP-Based Implementation

     The Model Context Protocol (MCP) provides a standardized approach for
     implementing the Agent-Network Interface (ANI).  This section
     describes how MCP can be applied to NetConfBench for LLM-driven
     network configuration evaluation.

  5.1.  Benefits of MCP Integration

     Integrating MCP into NetConfBench provides several advantages:

     1.  *Standardization*: MCP provides a uniform interface for tool
         invocation across different LLM implementations and network
         environments.



  Cui, et al.                Expires 3 July 2026                 [Page 16]


  Internet-Draft                NetConfBench                 December 2025


     2.  *Vendor Abstraction*: The MCP server can handle vendor-specific
         command translation, allowing the LLM to work with high-level
         operations without needing detailed knowledge of each vendor's
         CLI syntax.

     3.  *Tool Extensibility*: New network operations can be easily added
         as MCP tools without modifying the LLM agent implementation.

     4.  *Traceability*: The structured MCP communication protocol enables
         detailed logging of all tool invocations and results,
         facilitating debugging and analysis.

     5.  *Ecosystem Integration*: MCP-enabled network tools can
         potentially be reused across different AI applications beyond
         network configuration evaluation.

  5.2.  MCP Tool Definitions for ANI Operations

     This subsection provides the complete MCP tool definitions for the
     four core Agent-Network Interface operations: get-topology, get-
     running-cfg, update-cfg, and execute_validation.  These definitions
     use JSON Schema to specify tool parameters and enable LLMs to
     understand and invoke network operations through the MCP protocol.

  5.2.1.  1. get_topology

     This tool provides network topology information in a format
     interpretable by the LLM, returning topology for specified devices or
     the entire network if no devices are specified.






















  Cui, et al.                Expires 3 July 2026                 [Page 17]


  Internet-Draft                NetConfBench                 December 2025


     {

       "name": "get_topology",
       "description": "Retrieve network topology information including
        nodes and their interconnections. Returns topology for
        specified devices or entire network if no devices specified.",
       "inputSchema": {
         "type": "object",
         "properties": {
           "devices": {
             "type": "array",
             "items": {
               "type": "string"
             },
             "description": "List of device names. Leave empty for
             entire network topology."
           }
         }
       }
     }

     *Usage Example*:

     {
       "method": "tools/call",
       "params": {
         "name": "get_topology",
         "arguments": {
           "devices": ["R1", "R2", "R3"]
         }
       }
     }

  5.2.2.  2. get_running_config

     This tool enables the agent to obtain the active configurations of
     specified devices, providing essential context for planning
     subsequent updates.













  Cui, et al.                Expires 3 July 2026                 [Page 18]


  Internet-Draft                NetConfBench                 December 2025


     {
       "name": "get_running_config",
       "description": "Retrieve the active running configuration
       from a network device. Returns the complete configuration
       as a text string.",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device": {
             "type": "string",
             "description": "Device name or identifier to retrieve
              configuration from"
           }
         },
         "required": ["device"]
       }
     }

     *Usage Example*:

     {
       "method": "tools/call",
       "params": {
         "name": "get_running_config",
         "arguments": {
           "device": "R1"
         }
       }
     }

  5.2.3.  3. update_config

     This tool allows the agent to apply new configuration commands and
     provides detailed feedback on their execution, including whether each
     command was accepted or resulted in any errors.
















  Cui, et al.                Expires 3 July 2026                 [Page 19]


  Internet-Draft                NetConfBench                 December 2025


     {
       "name": "update_config",
       "description": "Apply configuration commands to a network
        device. Executes a sequence of CLI commands and returns
         detailed status for each command.",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device": {
             "type": "string",
             "description": "Device name or identifier to apply
              configuration to"
           },
           "commands": {
             "type": "array",
             "items": {
               "type": "string"
             },
             "description": "Ordered list of CLI commands to
              execute on the device"
           }
         },
         "required": ["device", "commands"]
       }

     }

     *Usage Example*:

     {
       "method": "tools/call",
       "params": {
         "name": "update_config",
         "arguments": {
           "device": "R1",
           "commands": [
             "configure terminal",
             "interface GigabitEthernet0/0",
             "ip address 192.168.1.1 255.255.255.0",
             "no shutdown"
           ]
         }
       }
     }

     ### 4. execute_cmd





  Cui, et al.                Expires 3 July 2026                 [Page 20]


  Internet-Draft                NetConfBench                 December 2025


     This tool accepts a device name and a read-only command string as
     parameters and returns the resulting output.  It must not alter the
     device state and is intended for validation and status inspection.

     {
       "name": "execute_validation",
       "description": "Execute a read-only validation command
        on a network device to verify configuration or check
         device status. This command must not alter the
         device state.",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device": {
             "type": "string",
             "description": "Device name or identifier to
             execute command on"
           },
           "command": {
             "type": "string",
             "description": "Read-only command to execute
              (e.g., show commands)"
           }
         },
         "required": ["device", "command"]
       }
     }

     *Usage Example*:

     {
       "method": "tools/call",
       "params": {
         "name": "execute_validation",
         "arguments": {
           "device": "R1",
           "command": "show ip route 2.2.2.0 255.255.255.252"
         }
       }
     }

     These four tools form the core MCP interface for NetConfBench.  The
     MCP server must register these tools and handle the translation
     between MCP tool invocations and actual device communication
     protocols (CLI, NETCONF, RESTCONF, etc.).  The JSON Schema
     definitions in inputSchema enable LLMs to automatically understand
     parameter requirements and generate valid tool calls.




  Cui, et al.                Expires 3 July 2026                 [Page 21]


  Internet-Draft                NetConfBench                 December 2025


  5.3.  Additional MCP Tools for Advanced Scenarios

     Beyond the four core ANI operations, additional MCP tools can be
     defined for more complex scenarios.  The following examples
     demonstrate extended tool definitions:

  5.3.1.  batch_configure_devices

     For batch operations across multiple devices:

     {
       "name": "batch_configure_devices",
       "description": "Apply configuration commands to
        multiple network devices simultaneously",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device_ips": {
             "type": "array",
             "items": {"type": "string"},
             "description": "List of device IP addresses"
           },
           "commands": {
             "type": "array",
             "items": {"type": "string"},
             "description": "CLI command sequence to execute"
           },
           "credential_id": {
             "type": "string",
             "description": "Authentication credential
              identifier"
           }
         },
         "required": ["device_ips", "commands"]
       }
     }

  5.3.2.  check_device_status

     For comprehensive device health monitoring:











  Cui, et al.                Expires 3 July 2026                 [Page 22]


  Internet-Draft                NetConfBench                 December 2025


     {
       "name": "check_device_status",
       "description": "Check operational status of network
        devices including CPU, memory, and interface metrics",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device_ip": {
             "type": "string",
             "description": "Device IP address to check"
           },
           "metrics": {
             "type": "array",
             "items": {
               "enum": ["cpu", "memory", "interface"]
             },
             "description": "List of metrics to retrieve"
           }
         },
         "required": ["device_ip", "metrics"]
       }
     }

     These additional tools demonstrate the extensibility of the MCP
     approach, allowing the framework to support advanced scenarios such
     as batch operations and comprehensive device monitoring.

  6.  Security Considerations

     LLM-driven network configuration introduces risks such as unintended
     or malicious commands, emulator vulnerabilities, and data exposure;
     to mitigate these, NetConfBench should enforce strict input
     validation (e.g., YANG/XML schema checks), run emulated devices in
     isolated sandboxes with limited privileges, encrypt and restrict
     access to task definitions and logs, employ human-in-the-loop
     approval for generated configurations, and use curated prompt
     templates and fine-tuning to reduce LLM hallucinations.  Validation
     endpoints must enforce read-only execution (e.g., execute-validation)
     to prevent unintended state changes.  Where appropriate, human-in-
     the-loop approval should gate privileged write operations (update-
     cfg/update-config) identified as high-impact.

  7.  IANA Considerations

     This document has no IANA actions.

  8.  References




  Cui, et al.                Expires 3 July 2026                 [Page 23]


  Internet-Draft                NetConfBench                 December 2025


  8.1.  Normative References

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

     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7950>.

  8.2.  Informative References

     [A2023]    Hat, R., "Ansible", 2023.

     [Fuad2024] Fuad, A., Ahmed, A. H., Riegler, M. A., and T. Cicic, "An
                intent-based networks framework based on large language
                models", 2024.

     [Kreutz2014]
                Kreutz, D., Ramos, F. M. V., Verissimo, P. E., Rothenberg,
                C. E., Azodolmolky, S., and S. Uhlig, "Software-defined
                networking: A comprehensive survey", 2014.

     [Lira2024] Lira, O. G., Caicedo, O. M., and N. L. S. da. Fonseca,
                "Large language models for zero touch network
                configuration management", 2024.

     [Liu2024]  Liu, C., Xie, X., Zhang, X., and Y. Cui, "Large language
                models for networking: Workflow, advances and challenges",
                2024.

     [Long2025] Long, S., Tan, J., Mao, B., Tang, F., Li, Y., Zhao, M.,
                and N. Kato, "A Survey on Intelligent Network Operations
                and Performance Optimization Based on Large Language
                Models", 2025.

     [Wang2024NetConfEval]
                Wang, C., Scazzariello, M., Farshin, A., Ferlin, S.,
                Kostic, D., and M. Chiesa, "Netconfeval: Can llms
                facilitate network configuration?", 2024.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses




  Cui, et al.                Expires 3 July 2026                 [Page 24]


  Internet-Draft                NetConfBench                 December 2025


     Yong Cui
     Tsinghua University
     Beijing, 100084
     China
     Email: cuiyong@tsinghua.edu.cn
     URI:   http://www.cuiyong.net/


     Chang Liu
     Tsinghua University
     Beijing, 100084
     China
     Email: liuchang23@mails.tsinghua.edu.cn


     Xiaohui Xie
     Tsinghua University
     Beijing, 100084
     China
     Email: xiexiaohui@tsinghua.edu.cn


     Chenguang Du
     Zhongguancun Laboratory
     Beijing, 100094
     China
     Email: ducg@zgclab.edu.cn
























  Cui, et al.                Expires 3 July 2026                 [Page 25]


