Trustworthy Enrollment of Secure Credentials
draft-bdnr-rats-trustworthy-credentials-01

RATS Working Group                                              M. Novak
Internet-Draft                                         J.P. Morgan Chase
Intended status: Informational                             M. Richardson
Expires: 7 January 2027                         Sandelman Software Works
                                                             H. Birkholz
                                                        Franhaufer Inst.
                                                             6 July 2026

              Trustworthy Enrollment of Secure Credentials
               draft-bdnr-rats-trustworthy-credentials-01

Abstract

   To be written last

   There is a large class of "RATS-Unaware" Relying Parties (RUPs) that
   Attesters nevertheless need to interoperate with.  Existing deployed
   services, which precede the introduction of Remote Attestation, are
   often difficult to change/update in significant ways due to
   regulatory and cryptographic review policies.  Yet there are
   significant advantages if clients can be incrementally updated in the
   trustworthiness of the platform.

   This document details a protocol by which the trusthworthiness of an
   Attesters is reviewed as part of the process of it being provided
   with some form of an Identity Document (a key, or a credential) to
   authenticate to RUPs.

   This specification illustrates how the RATS Architecture can be
   applied to interoperate with RUPs by providing Attesters with such
   Identity Documents.

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-bdnr-rats-trustworthy-
   credentials/.

   Discussion of this document takes place on the RATS Working Group
   mailing list (mailto:rats@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/rats/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/rats/.

   Source for this draft and an issue tracker can be found at
   https://github.com/mcr/twi-rats.

Novak, et al.            Expires 7 January 2027                 [Page 1]
Internet-Draft                     ESC                         July 2026

Status of This Memo

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

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

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

   This Internet-Draft will expire on 7 January 2027.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Assumptions about Workload Immutability . . . . . . . . .   4
     1.2.  Hostile Regulator . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Overview of Mechanism . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Types of Credentials  . . . . . . . . . . . . . . . . . .   7
     3.2.  Deployment of Credentials . . . . . . . . . . . . . . . .   8
   4.  Details of protocol . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Use of Enrollment over Secure Transport (EST) . . . . . .   9
       4.1.1.  Credential Broker as Identity Provider  . . . . . . .   9
       4.1.2.  Credential Broker as Secure Repository  . . . . . . .   9
       4.1.3.  Credential Broker as short-term Bearer Token
               issuer  . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10

Novak, et al.            Expires 7 January 2027                 [Page 2]
Internet-Draft                     ESC                         July 2026

   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Success of a technology is ultimately measured by its adoption.  The
   RATS Architecture requires that RATS Relying Parties understand
   Attestation Results expressed using standards such as EAT and AR4SI,
   execute Appraisal Policy for Attestation Results, and have trust in
   Verifiers.  Additionally, there is an unstated assumption present in
   the RATS Architecture that a change in Evidence may lead to a change
   in either the Attestation Results or Appraisal Policy for Attestation
   Results.  This requirement may pose a significant adoption blocker.

   One key requirement for successful deployment of Remote Attestation-
   capable workloads is minimal blast radius.  When a workload is moved
   from a legacy to a remotely attestable (e.g. Trusted Execution)
   environment, including Intel SGX, AMD SEV-SNP, ARM TrustZone, that
   workload can use Remote Attestation to obtain a stable and
   trustworthy Identity Document while its clients and servers do not
   notice anything different.

   For that, a mechanism is required by means of which a Credential
   Broker, a Key Broker, or a Credential Authority takes on the role of
   RATS Relying Party.  This provides an intermediation between
   Attestation Results, expressed using formats such as EAT and AR4SI,
   and the RATS-Unaware Relying Parties whose authentication and
   authorization policies may precede the introduction of Remotely
   Attestable Workloads and remain static for long periods of time.

   For the RATS-Unaware Relying Parties, these adoption barriers are
   eliminated, as these RUPs are capable of authenticating their clients
   utilizing appropriate Identity Documents.  This includes shared
   symmetric keys (bearer tokens), credentials including PKIX
   certificates [RFC5280], JWTs [RFC7515], or WIMSE WITs
   [I-D.ietf-wimse-workload-creds].  In this world, the Attester uses
   Remote Attestation to obtain from the RATS Relying Party a key, token
   or credential that is compatible with the RUP.

   This document details an architecture by which legacy Identity
   Document Identity Document issuance mechanisms are replaced with
   identical Identity Documents issued, but with the additional
   prerequisite of successful Remote Attestation of the workloads in
   question.

Novak, et al.            Expires 7 January 2027                 [Page 3]
Internet-Draft                     ESC                         July 2026

1.1.  Assumptions about Workload Immutability

   While updates and upgrades to the workload and the RATS Unaware Party
   to add a Remote Attestation capability are not possible in this
   environment, some changes to the Attesting environment are required
   in order to do anything.

   The assumption is that the workload may be a compiled object or
   container provided by a third party.  Or the workload may be in a
   language not easily changed or upgraded with new capabilities.  At an
   extreme example, it could be an ancient COBOL program compiled into a
   WASM object, perhaps connected to the network via virtual paper-tape
   and virtual printer interfaces.  Further, such a system may require
   extensive and significant review by an authority before changes to
   the core algorithm can be made.

   These workloads run in a virtual machine (VM with unique kernel), or
   in a containerized environment (common kernel).  They never run on
   bare hardware, and there is a hypervisor and/or orchestration
   environment that arranges the workload and any needed configurations.

   However, it is assumed that some the following changes _can_ be made:

   *  network connections use mutual TLS, and the origin of the keypair
      used for client authentication can be changed or configured by an
      operator

   *  the TLS code, while built-in to the application, can be configured
      to use a Secure Element or TPM as the source for the private key.
      Current TLS stacks such as OpenSSL can be configured to use
      engines or providers to do asymmetric operations, and providers
      exist that talk to a TPM for all private key operations.

   *  in the case of bearer token authentication, that the token can be
      configured external to the code

   *  that other components or configurations can be added to the
      execution environment by the operator

   *  that the orchestration environment can be extended with new
      capabilities without affecting the workload itself

Novak, et al.            Expires 7 January 2027                 [Page 4]
Internet-Draft                     ESC                         July 2026

1.2.  Hostile Regulator

   A motivating factor in this work is that there are workloads that are
   mandated to operate in specific geographies under inspection by a
   local authority.  The inspection process by the regulator may include
   agents that must run within the secured environment, where it may
   examine inputs and outputs to the workload.  These agents do not have
   the full trust of the workload owners or RATS Unaware Party.

   The trustworthiness of the workload is not absolute (no trust ever
   is), however there is a need to provide assurance that only the
   regulator's agent is present, and no additional malware has been
   introduced.  (For instance, the agent may have exploits known to
   additional parties, not yet revealed or fixed by the regulator)

2.  Conventions and Definitions

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

   This document uses terms and concepts defined by the WIMSE and RATS
   architectures, as well as the terms defined by the Trustworthy
   Workload Identity Special Interest Group at the Confidential
   Computing Consortium.  For a complete glossary, see Section 4 of
   [RFC9334], [I-D.ietf-wimse-arch] & [TWISIGDef].

   The definitions of terms like Trustworthy Workload Identity and
   Workload Credential match those specified by the TWI SIG Definitions
   [TWISIGDef].

   Broker:  an entity that deals out pre-existing keys or credential.
      Constrast to a Credential Authority which mints new credentials.

   RUP:  The RATS Unaware Party (RUP).  A target service that interacts
      with many clients based upon credentials provided.  This is
      sometimes called the Collaborating Party.

   Workload:  [I-D.ietf-wimse-arch] defines 'Workload' as "an instance
      of software executing for a specific purpose".  Here we restrict
      that definition to the portions of the deployed software and its
      configuration that are subject to Remote Attestation.

   Workload Duration:  the lifespan of the workload.  While some

Novak, et al.            Expires 7 January 2027                 [Page 5]
Internet-Draft                     ESC                         July 2026

      workloads can be very long lived, but many workloads are created
      for a brief period of time, often added on demand to support
      rising demand, and persisting for only minutes to a small fraction
      of a day.

   Workload Owner:  the entity that manages a workload, arranging to
      provision it with appropriate Workload Credentials before Workload
      is launched

   Workload Credential:  an ephemeral identity document containing an
      identity and a number of additional claims, that can be short-
      lived or long-lived, and that is used to access a service

   Proof of possession credential:  this is a credential, such as a JWT,
      that contains no other identity or authorization claims.  It is
      trusted by the RUP due to local policy.

   Collaborating Party:  see RUP.

   Verifier:  an entity performing the role of Attestation Verification,
      as documented in Section 4 of [RFC9334]

3.  Overview of Mechanism

   A newly created workload connects to the Credential Broker to obtain
   a set of credentials to be used to perform it's functions.

   Within this connection, Evidence is transferred to the Credential
   Broker to demonstrate the workloads' trusthworthiness.  The
   Credential Broker is acting as a RATS Relying Party, the workload is
   the Attester.  The Credential Broker contacts (using the background
   check model), a Verifier that it trusts in order to evaluate the
   Evidence, obtaining an Attestation Result.

   Figure Figure 1 extends the [RFC9334] architecture to show how the
   workload and credential broker take on the roles of Attester and
   Relying Party.

   If the Attestation Result is acceptable, then the Credential Broker
   provides the set of credentials that the workload needs to accomplish
   it's task.

Novak, et al.            Expires 7 January 2027                 [Page 6]
Internet-Draft                     ESC                         July 2026

      .----------.   .-----------.  .----------.  .---------.
      | Endorser +.  | Reference |  | Verifier |  | Relying |
      '----------' | |   Value   |  |  Owner   |  |  Party  |
                   | | Provider  |  '-+--------'  |  Owner  |
                   | '-+---------'    |           '-------+-'
                   |   |              | Appraisal         |
                   |   | Reference    | Policy for        |
                   |   | Values       | Evidence          |
                   v   v              v                   |
                  .-------------------------.             |
             .--->|         Verifier        +------.      |
            |     '-------------------------'       |     |
            |                                       |     |
            | Evidence                  Attestation |     |
            |                           Results     |     |
            |                                       |     |
            |                                       v     v
      .-----+----.                                .-------------------.
      | Attester |                                |   Relying Party   |
      |----------|------------enrollment--------->|-------------------|
      | workload |                                | credential broker |
      '-----+----'                                '-------------------'
             \
              \   authentication        .---------------------.
               `----work-data---------->|    RATS Unaware     |
                                        |    Relying Party    |
                                        | Collaborating Party |
                                        '---------------------'
                                          RATS-Unaware ^
                                        Authentication |
                                                Policy |
                                        .--------------+-.
                                        |  RATS-Unaware  |
                                        | Relying Party  |
                                        |     Owner      |
                                        '----------------'

                Figure 1: Credential Enrollment Architecture

3.1.  Types of Credentials

   There are three kinds of credentials that can be involved.  Some
   workloads might use a few of each, possibly with each one being used
   with a different RATS Unaware Party.

Novak, et al.            Expires 7 January 2027                 [Page 7]
Internet-Draft                     ESC                         July 2026

   1.  The Credential Broker is also an Identity Provider (IdP), and
       acts as an Registration Authority (possibly including the
       Certification Authority).  It issues new credentials in the form
       of PKIX certificates to each trustworthy workload.

   2.  The Credential Broker is a respository for a credential issued by
       another Identity Provider (IdP).  The Credential Broker has both
       the private key (encrypted) and the certificate, and it discloses
       these to trustworthy workloads by returning them in a unique
       encryption, bound to the workload identity.

   3.  The Credential Broker is a resposity for a bearer token issued by
       a Resource Owner, or a Workload Identity Tokens (WITs) defined in
       Section 3.1 of [I-D.ietf-wimse-identifier].  The Credential
       Broker discloses this to trustworthy workloads by returning them
       in a unique encryption, bound to the workload identity.

   The use of a shared assymetric private key is unorthodox.  This
   architecture is justified by the need to rapidly scale the number of
   workers and to recover from hardware or network failures.  The
   alternatives is that external Identity Providers would need to be
   willing to respond to spikes of hundreds of credential requests
   within a small period of time.  This would look like a denial of
   service attack, and it may also require additional human
   authorization for each.

   The patterns of communication shown in figure Figure 1 are designed
   specifically such that as few modifications are required to the
   workload, and no changes to the Collaborating Party are required.

3.2.  Deployment of Credentials

   Workloads are expected to include a (virtual) Trusted Platform Module
   (TPM) (or equivalent) by which they will collect and sign Evidence to
   be used in the Remote Attestation process.

   The credential that will be shared by the Credential Broker will be
   encrypted to a key involved in the Remote Attestation process.  The
   most natural mechanism is to encrypt to a key that is available only
   to the TPM.  The credential are then decrypted by the TPM, and the
   keypair can then be made available to the workload, while never
   permitting the workload to ever see the key.

   In this way, a workload that be designed to do mutual TLS using a
   client-certificate, and for which the location of the private key can
   be configured to be in a TPM, can be adapted to the mechanism
   described in this document without any significant change to the
   workload itself.

Novak, et al.            Expires 7 January 2027                 [Page 8]
Internet-Draft                     ESC                         July 2026

4.  Details of protocol

   As there are three major types of credentials that may be used, it is
   not unreasonable that they may get provisioned in different ways,
   using different protocols.

4.1.  Use of Enrollment over Secure Transport (EST)

   EST ([RFC7030]) describes a mechanism to enroll with a certification
   authority using a TLS secured HTTP based protocol.

4.1.1.  Credential Broker as Identity Provider

   EST is used by the hypervisor (or container orchestrator) to connect
   to the Identity Provider.  The EST protocol is extended to include
   transmission of Evidence from the Attester to the Identity Provider.
   This Identity Provider acts as a RATS Relying Party, in Background-
   Check mode.  The Evidence is passed to an appropriately trusted
   Verifier, and evaluated.

   Based upon the Attestation Results, the Identity Provide then allows
   the hypervisor to use the EST /simpleenroll mechanism to provide a
   CSR, and retrieve an appropriate certificate.  The private key for
   the certificate can be generated within a TPM, never to leave.  The
   hypervisor then inserts the certificate into an appropriate place for
   inline transmission by mutual TLS.

   There are three ways to handle the Evidence:

   *  via a new, Remote Attestation extension to EST

   *  using [I-D.ietf-lamps-csr-attestation] extensions to the CSR
      itself

   *  within TLS itself, using for instance, [I-D.fossati-seat-expat],
      or whichever protocol the SEAT WG standardizes

4.1.2.  Credential Broker as Secure Repository

   EST is used by the hypervisor (or container orchestrator) to connect
   to the Secure Repository The EST protocol is extended to include
   transmission of Evidence from the Attester to the Secure Repository.

   The EST /serverkeygen mechanism is used.  The server does not
   generate a fresh key, but rather retrieves the keypair (private key
   and certificate) from the store.  This is encrypted back to the
   client using one of the mechanisms described in RFC7030.  (TBD: This
   needs more detail, particularly for the mTLS used in the EST)

Novak, et al.            Expires 7 January 2027                 [Page 9]
Internet-Draft                     ESC                         July 2026

   As before, there are three possible ways to transmit the Evidence:

   *  via a new, Remote Attestation extension to EST

   *  using [I-D.ietf-lamps-csr-attestation] extensions to the CSR
      itself.  The serverkeygen mechanism still sends a CSR, with a fake
      public key.

   *  within TLS itself, using for instance, [I-D.fossati-seat-expat],
      or whichever protocol the SEAT WG standardizes

4.1.3.  Credential Broker as short-term Bearer Token issuer

   EST is not appropriate for this use case.  Another protocol will be
   required.

   TBD.

5.  Security Considerations

   All communications between entities (Workload to Credential
   Authority, Workload to Verifier etc) MUST be secured using mutually
   authenticated, confidential, and integrity-protected channels (e.g.,
   TLS).

   In addition to the considerations herein, Verifier, which is a
   central point of anchor for Trustworthy Workload Identifer MUST
   follow the security guidance detailed in the "Security and Privacy
   considerations" as detailed in the RATS Architecture Section 11 and
   Section 12 of [RFC9334].

   The credential key MUST always be stored securely at all time, for
   example in a secure element of the underlying platform running the
   Workload.

   There is a risk that a live Workload Migration may render some of the
   claims about the Workload invalid (e.g., live-migrating a Workload
   between Germany and France may incorrectly preserve the
   "Country=Germany" claim, but correctly preserve the "Region=Europe"
   claim).

6.  Privacy Considerations

   Remote Attestation of a Workload requires exchange of attestation
   related messages, for example, Evidence and Attestation Results.
   This can potentially leak sensitive information about the Workload.

Novak, et al.            Expires 7 January 2027                [Page 10]
Internet-Draft                     ESC                         July 2026

   Confidentiality: Encryption could be used to prevent unauthorised
   parties from accessing sensitive information from Evidence or
   Attestation Results.  This is crucial in multi-tenant environments.
   The Credential Key to be released to a Workload MUST always be
   encrypted to avoid potential leakage to unauthorised actors.

7.  IANA Considerations

   This document has no IANA actions (yet).

8.  References

8.1.  Normative References

   [I-D.ietf-lamps-csr-attestation]
              Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
              and N. Smith, "Use of Remote Attestation with
              Certification Signing Requests", Work in Progress,
              Internet-Draft, draft-ietf-lamps-csr-attestation-28, 16
              June 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-csr-attestation-28>.

   [I-D.ietf-wimse-workload-creds]
              Campbell, B., Salowey, J. A., Schwenkschuster, A.,
              Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
              Credentials", Work in Progress, Internet-Draft, draft-
              ietf-wimse-workload-creds-02, 2 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              workload-creds-02>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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

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

Novak, et al.            Expires 7 January 2027                [Page 11]
Internet-Draft                     ESC                         July 2026

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

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

8.2.  Informative References

   [I-D.fossati-seat-expat]
              Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y.,
              Tschofenig, H., and I. Mihalcea, "Remote Attestation with
              Exported Authenticators", Work in Progress, Internet-
              Draft, draft-fossati-seat-expat-03, 4 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-fossati-seat-
              expat-03>.

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-wimse-arch-08, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-08>.

   [I-D.ietf-wimse-identifier]
              Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
              Work in Progress, Internet-Draft, draft-ietf-wimse-
              identifier-03, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              identifier-03>.

   [I-D.mihalcea-seat-use-cases]
              Mihalcea, I., Sardar, M. U., Fossati, T., Reddy.K, T.,
              Jiang, Y., and M. Chen, "Security Goals and Use Cases for
              Integrating Remote Attestation with Secure Channel
              Protocols", Work in Progress, Internet-Draft, draft-
              mihalcea-seat-use-cases-03, 16 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-mihalcea-
              seat-use-cases-03>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334>.

Novak, et al.            Expires 7 January 2027                [Page 12]
Internet-Draft                     ESC                         July 2026

   [TWISIGDef]
              Confidential Computing Consortium Trustworthy Workload
              Identity SIG, "Trustworthy Workload Identity (TWI) Special
              Interest Group — Definitions", n.d., <https://github.com/
              confidential-computing/twi/blob/main/TWI_Definitions.md>.

Acknowledgments

Authors' Addresses

   Mark Novak
   J.P. Morgan Chase
   Email: mark.f.novak@jpmchase.com

   Michael Richardson
   Sandelman Software Works
   Canada
   Email: mcr+ietf@sandelman.ca

   Henk Birkholz
   Franhaufer Inst.
   Email: Henk.Birkholz@ietf.contact

Novak, et al.            Expires 7 January 2027                [Page 13]