Internet-Draft JWS-voucher November 2024
Werner & Richardson Expires 2 June 2025 [Page]
Workgroup:
anima Working Group
Internet-Draft:
draft-ietf-anima-jws-voucher-14
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Werner
Siemens AG
M. Richardson
Sandelman Software Works

JWS signed Voucher Artifacts for Bootstrapping Protocols

Abstract

I-D.ietf-anima-rfc8366bis defines a digital artifact (known as a voucher) as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS. In addition to specifying the format, the "application/voucher-jws+json" media type is registered and examples are provided.

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

▲

Table of Contents

1. Introduction

"A Voucher Artifact for Bootstrapping Protocols" [I-D.ietf-anima-rfc8366bis] defines a YANG data model used in "Bootstrapping Remote Secure Key Infrastructure" (BRSKI) [RFC8995] and "Secure Zero Touch Provisioning" (SZTP) [RFC8572] to transfer ownership of a device from a manufacturer to a new owner (customer or operational domain). That document provides a serialization of the voucher data to JSON [RFC8259] with cryptographic signing according to the Cryptographic Message Syntax (CMS) [RFC5652]. That resulting voucher artifact has the media type application/voucher-cms+json.

This document provides cryptographic signing of voucher data in form of JSON Web Signature (JWS) [RFC7515] and the media type application/voucher-jws+json to identify the voucher format. The encoding specified in this document is used by [I-D.ietf-anima-brski-prm] and may be more handy for use cases already using Javascript Object Signing and Encryption (JOSE).

This document should be considered as enhancement of [I-D.ietf-anima-rfc8366bis], as it provides a new voucher format. It is similar to [I-D.ietf-anima-constrained-voucher], which provides cryptographic signing according COSE [RFC8812] and the media type application/voucher-cose+cbor. These documents do not change nor extend the YANG definitions of [I-D.ietf-anima-rfc8366bis].

With the availability of different voucher formats, it is up to an industry-specific application statement to decide which format is to be used. The associated media types are used to distinguish different voucher formats.

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 uses the following terms:

JSON Voucher Data:

An unsigned JSON representation of the voucher data.

JWS Voucher:

A JWS structure signing the JSON Voucher Data.

Voucher:

A short form for voucher artifact and refers to the signed statement from Manufacturer Authorized Signing Authority (MASA) service that indicates to a Pledge the cryptographic identity of the domain it should trust, per [I-D.ietf-anima-rfc8366bis].

Voucher Data:

The raw (serialized) representation of the ietf-voucher YANG module without any enclosing signature, per [I-D.ietf-anima-rfc8366bis].

MASA (Manufacturer Authorized Signing Authority):

The entity that, for the purpose of this document, issues and signs the vouchers for manufacturer's pledges. In some onboarding protocols, the MASA may have an Internet presence and be integral to the onboarding process, whereas in other protocols the MASA may be an offline service that has no active role in the onboarding process, per [I-D.ietf-anima-rfc8366bis].

Pledge:

The prospective component attempting to find and securely join a domain. When shipped or in factory reset mode, it only trusts authorized representatives of the manufacturer, per [I-D.ietf-anima-rfc8366bis].

Registrar:

A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain, per [I-D.ietf-anima-rfc8366bis].

This document uses the following encoding notations:

BASE64URL(OCTETS):

Denotes the base64url encoding of OCTETS, per Section 2 of [RFC7515].

UTF8(STRING):

Denotes the octets of the UTF-8 [RFC3629] representation of STRING, per Section 1 of [RFC7515].

3. Voucher Artifact with JSON Web Signature

JWS voucher artifacts MUST use the "General JWS JSON Serialization Syntax" defined in Section 7.2.1 of [RFC7515]. This syntax supports multiple signatures as already supported by [RFC8366] for CMS-signed vouchers. The following figure summarizes the serialization of JWS voucher artifacts:

    {
      "payload": BASE64URL(UTF8(JSON Voucher Data)),
      "signatures": [
        {
          "protected": BASE64URL(UTF8(JWS Protected Header)),
          "signature": BASE64URL(JWS Signature)
        }
      ]
    }
Figure 1: Voucher Representation in General JWS JSON Serialization Syntax (JWS Voucher)

The JSON Voucher 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.

3.1. JSON Voucher Data

The JSON Voucher Data is an unsigned JSON document [RFC8259] that conforms with the data model described by the ietf-voucher YANG module [RFC7950] defined in Section 7.3 of [I-D.ietf-anima-rfc8366bis] and is encoded using the rules defined in [RFC7951]. The following figure provides an example of JSON Voucher Data:

    {
      "ietf-voucher:voucher": {
        "assertion": "logged",
        "serial-number": "0123456789",
        "nonce": "5742698422680472",
        "created-on": "2022-07-08T03:01:24.618Z",
        "pinned-domain-cert": "base64encodedvalue=="
      }
    }
Figure 2: JSON Voucher Data Example

3.2. JWS Protected Header

The JWS Protected Header defined in [RFC7515] uses the standard header parameters alg, typ, and x5c:

  • The alg parameter MUST contain the algorithm type (e.g., ES256) used to create the signature as defined in Section 4.1.1 of [RFC7515].

  • The typ parameter is optional and used when more than one kind of object could be present in an application data structure as described in Section 4.1.9 of [RFC7515]. If present, the typ parameter MUST contain the value voucher-jws+json.

  • If X.509 (PKIX) certificates [RFC5280] are used, the x5c parameter MUST contain the base64-encoded (not base64url-encoded) X.509 v3 (DER) certificate as defined in Section 4.1.6 of [RFC7515] and SHOULD also contain the certificate chain.

Implementation Note:

base64-encoded values, in contrast to base64url-encoded values, may contain slashes (/). JSON [RFC8259] optionally allows escaping these with backslashes (\\). Hence, depending on the JSON parser/serializer implementation used, they may or may not be included. JWS Voucher parsers MUST be prepared accordingly to extract certificates correctly.

To validate voucher signatures, all certificates of the certificate chain are required up to the trust anchor. Note, to establish trust the trust anchor SHOULD be provided out-of-band up front.

The following figure gives an example of a JWS Protected Header:

    {
      "alg": "ES256",
      "typ": "voucher-jws+json",
      "x5c": [
        "base64encodedvalue1==",
        "base64encodedvalue2=="
      ]
    }
Figure 3: JWS Protected Header Example

3.3. JWS Signature

The JWS Signature is generated over the JWS Protected Header and the JWS Payload (= UTF-8 encoded JSON Voucher Data) as described in Section 5.1 of [RFC7515].

4. Privacy Considerations

The Pledge-Voucher-Request (PVR) reveals the IDevID of the component (Pledge) that is in the process of bootstrapping.

A PVR is transported via HTTP-over-TLS. However, for the Pledge-to-Registrar TLS connection a Pledge provisionally accepts the Registrar server certificate during the TLS server authentication. Hence, it is subject to disclosure by a Dolev-Yao attacker (a "malicious messenger") [ON-PATH], as explained in Section 10.2 of [RFC8995].

The use of a JWS header brings no new privacy considerations.

5. Security Considerations

The issues of how [I-D.ietf-anima-rfc8366bis] vouchers are used in a BRSKI system is addressed in Section 11 of [RFC8995]. This document does not change any of those issues, it just changes the signature technology used for voucher request and response artifacts.

Section 9 of [RFC8572] deals with voucher use in Secure Zero Touch Provisioning (SZTP), for which this document also makes no changes to security.

6. IANA Considerations

6.1. Media-Type Registry

This section registers application/voucher-jws+json in the "Media Types" registry.

6.1.1. application/voucher-jws+json 

Type name:  application
Subtype name:  voucher-jws+json
Required parameters:  none
Optional parameters:  none
Encoding considerations:  JWS+JSON vouchers are JOSE objects
                          signed with one or multiple signers.
Security considerations:  See section [Security Considerations]
Interoperability considerations:  The format is designed to be
  broadly interoperable.
Published specification:  THIS RFC
Applications that use this media type:  ANIMA, 6tisch, and other
  zero-touch bootstrapping/provisioning solutions
Additional information:
  Magic number(s):  None
  File extension(s):  .vjj
  Macintosh file type code(s):  none
Person & email address to contact for further information:  IETF
  ANIMA WG
Intended usage:  LIMITED
Restrictions on usage:  NONE
Author:  ANIMA WG
Change controller:  IETF
Provisional registration? (standards tree only):  NO

7. Acknowledgments

We would like to thank the various reviewers for their input, in particular Steffen Fries, Ingo Wenda, Esko Dijk and Toerless Eckert. Thanks for the supporting PoC implementations to Hong Rui Li and He Peng Jia.

8. Examples

These examples are folded according to the [RFC8792] Single Backslash rule.

8.1. Example Pledge-Voucher-Request (PVR)

The following is an example of a Pledge-Voucher-Request (PVR) as JWS Voucher artifact, which would be sent from a Pledge to the Registrar:

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
1udW1iZXIiOiJraXQtOTg3NjU0MzIxIiwibm9uY2UiOiJUYXV2SytZL2NjMlJmSUZ2cF\
p6ZktRPT0iLCJjcmVhdGVkLW9uIjoiMjAyNC0xMS0yOVQwOTozNDoxNi40MjZaIiwicH\
JveGltaXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQ0RUQ0NBYk9nQXdJQkFnSUdBWk4zTk\
RtUE1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0\
RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BME\
dBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHlORE\
V4TWprd09URTFNekZhRncwek5ERXhNamt3T1RFMU16RmFNR0l4Q3pBSkJnTlZCQVlUQW\
tGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGREFTQmdOVkJBc01DMDE1VTNWaW\
MybGtZWEo1TVE4d0RRWURWUVFIREFaTmVWTnBkR1V4R0RBV0JnTlZCQU1NRDAxNVUybD\
BaVkpsWjJsemRISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQU\
grTFptbnRncGgralUvc2NUQnhkVHpzd2xmUTZ1Sy9BOWFJYkpaS2U0UGl0VnhraE5HWW\
d0Nm9wMytDaVFLTHdaOWdEMHFXMjIxQUxZNSs3bVFKNnlqV3pCWk1CMEdBMVVkSlFRV0\
1CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QX\
dLQVlEVlIwUkJDRXdINElkYlhsemFYUmxjbVZuYVhOMGNtRnlMbTE1WTI5dGNHRnVlUz\
VqYjIwd0NnWUlLb1pJemowRUF3SURTQUF3UlFJZ0Q3a0J4MU82TzJGVFBPUlgwNDdTcF\
N2cGF6dC8rR3YyOXM4N3lyTXU2UE1DSVFEeU90cGJ2bEwvd1c4Zy9ESUx2T0RZZ01PT1\
VrVDE1ZHZZTUVOR1QyQ3V5Zz09In19",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQ056Q0NBZDJnQXdJQkFnSUdBWk4zTkRt\
S01Bb0dDQ3FHU000OUJBTUNNRmd4Q3pBSkJnTlZCQVlUQWtGUk1Sc3dHUVlEVlFRS0RC\
Sk5ZVzUxWm1GamRIVnlaWEl3TURFZ1FVY3hFekFSQmdOVkJBc01Dazl5WjFnZ1ZXNXBk\
RUV4RnpBVkJnTlZCQU1NRGsxaGJuVm1ZV04wZFhKbGNrTkJNQ0FYRFRJME1URXlPVEE1\
TVRVek1Wb1lEems1T1RreE1qTXhNak0xT1RVNVdqQnZNUXN3Q1FZRFZRUUdFd0pCVVRF\
Yk1Ca0dBMVVFQ2d3U1RXRnVkV1poWTNSMWNtVnlNREF4SUVGSE1STXdFUVlEVlFRTERB\
cFBjbWRZSUZWdWFYUkJNUll3RkFZRFZRUUZFdzFyYVhRdE9UZzNOalUwTXpJeE1SWXdG\
QVlEVlFRRERBMUJRa016TGtVM05TMHhNREJCTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJ\
emowREFRY0RRZ0FFZ05rMXc2ZlBFRFlyekRJam5ybUV4RjU0WGsrK1psZjJITTRrQ29P\
bkt2VHJPMFY4YUJoMW11enlRVlUwano2VTd6OTFBSjlvNlNSQmxibTJmQlRPYTZONk1I\
Z3dNQVlJS3dZQkJRVUhBU0FFSkJZaWJXRnpZUzEwWlhOMExuaDVlbTFoYm5WbVlXTjBk\
WEpsY2k1amIyMDZPVFEwTXpBZkJnTlZIU01FR0RBV2dCU1ZUdFYrM1FxK2lrdlBLTVpv\
MEhaOXhESUg5VEFUQmdOVkhTVUVEREFLQmdnckJnRUZCUWNEQWpBT0JnTlZIUThCQWY4\
RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUlnVTJUNkpTOHVqUTAzK1QvdDE2\
dVNoZ2lsOE0vbWFHVnhuSzRxek9OUFVKRUNJUURHTVRxcmkyVzBMSUltajZCS1d0QU95\
WDJmRWdvaFI4RFVyTDNCMjFvRGlnPT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIs\
ImFsZyI6IkVTMjU2In0",
      "signature": "ehYSVTUFgJ890sF5F8ky5nfOXsG9JMfBVBv9POlwHVZGQnFQ\
hP3F0BQj6bj4mGICcfk5FGPD8rJKs7txuBfKgA"
    }
  ]
}
Figure 4: Example Pledge-Voucher-Request (PVR)

The following private key (of the IDevID) is used to sign a Pledge-Voucher-Request (PVR) by Pledge:

-----BEGIN PRIVATE KEY-----
MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCA4b574lJvkZZt+ij+D
ughPm8xFg95HMW3BHKCbQEaxUw==
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICNzCCAd2gAwIBAgIGAZN3NDmKMAoGCCqGSM49BAMCMFgxCzAJBgNVBAYTAkFR
MRswGQYDVQQKDBJNYW51ZmFjdHVyZXIwMDEgQUcxEzARBgNVBAsMCk9yZ1ggVW5p
dEExFzAVBgNVBAMMDk1hbnVmYWN0dXJlckNBMCAXDTI0MTEyOTA5MTUzMVoYDzk5
OTkxMjMxMjM1OTU5WjBvMQswCQYDVQQGEwJBUTEbMBkGA1UECgwSTWFudWZhY3R1
cmVyMDAxIEFHMRMwEQYDVQQLDApPcmdYIFVuaXRBMRYwFAYDVQQFEw1raXQtOTg3
NjU0MzIxMRYwFAYDVQQDDA1BQkMzLkU3NS0xMDBBMFkwEwYHKoZIzj0CAQYIKoZI
zj0DAQcDQgAEgNk1w6fPEDYrzDIjnrmExF54Xk++Zlf2HM4kCoOnKvTrO0V8aBh1
muzyQVU0jz6U7z91AJ9o6SRBlbm2fBTOa6N6MHgwMAYIKwYBBQUHASAEJBYibWFz
YS10ZXN0Lnh5em1hbnVmYWN0dXJlci5jb206OTQ0MzAfBgNVHSMEGDAWgBSVTtV+
3Qq+ikvPKMZo0HZ9xDIH9TATBgNVHSUEDDAKBggrBgEFBQcDAjAOBgNVHQ8BAf8E
BAMCB4AwCgYIKoZIzj0EAwIDSAAwRQIgU2T6JS8ujQ03+T/t16uShgil8M/maGVx
nK4qzONPUJECIQDGMTqri2W0LIImj6BKWtAOyX2fEgohR8DUrL3B21oDig==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB6DCCAY+gAwIBAgIGAZN3NDl2MAoGCCqGSM49BAMCMFgxCzAJBgNVBAYTAkFR
MRswGQYDVQQKDBJNYW51ZmFjdHVyZXIwMDEgQUcxEzARBgNVBAsMCk9yZ1ggVW5p
dEExFzAVBgNVBAMMDk1hbnVmYWN0dXJlckNBMB4XDTI0MTEyOTA5MTUzMVoXDTM5
MTEyOTA5MTUzMVowWDELMAkGA1UEBhMCQVExGzAZBgNVBAoMEk1hbnVmYWN0dXJl
cjAwMSBBRzETMBEGA1UECwwKT3JnWCBVbml0QTEXMBUGA1UEAwwOTWFudWZhY3R1
cmVyQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATfl/ScKL8rB6DPTjOX4ug/
mCmtrry59h0q4J0r/yEMmGGzKhNSskJ54u22q2kdGcMpAISH59a0SZ6mip60FzLz
o0UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwICBDAdBgNVHQ4E
FgQUlU7Vft0KvopLzyjGaNB2fcQyB/UwCgYIKoZIzj0EAwIDRwAwRAIgN0nzFkSM
iSMygrUBhPARioFiAb+zVPc7sdSy/o3nfSYCIBxGrzP3BssOJTjniu8loqHXyf9m
JKYL4lAyT0nAC0jc
-----END CERTIFICATE-----

8.2. Example Parboiled Registrar-Voucher-Request (RVR)

The term parboiled refers to food which is partially cooked. In BRSKI [RFC8995], the term refers to a Pledge-Voucher-Request (PVR) that was received by the Registrar, then has been processed by the Registrar ("cooked"), and is now being forwarded to the MASA.

The following is an example Registrar-Voucher-Request (RVR) as JWS Voucher artifact, which would be sent from the Registrar to the MASA. Note, the previous PVR can be seen in the payload in the field prior-signed-voucher-request.

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
1udW1iZXIiOiJraXQtOTg3NjU0MzIxIiwiaWRldmlkLWlzc3VlciI6IkJCZ3dGb0FVbF\
U3VmZ0MEt2b3BMenlqR2FOQjJmY1F5Qi9VPSIsIm5vbmNlIjoiVGF1dksrWS9jYzJSZk\
lGdnBaemZLUT09IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6ImV5SndZWG\
xzYjJGa0lqb2laWGxLY0ZwWVVtMU1XRnAyWkZkT2IxcFlTWFJqYlZaNFpGZFdlbVJFY0\
RKaU0xWnFZVWRXZVVscWNEZEpiazVzWTIxc2FHSkRNWFZrVnpGcFdsaEphVTlwU25KaF\
dGRjBUMVJuTTA1cVZUQk5la2w0U1dsM2FXSnRPWFZaTWxWcFQybEtWVmxZVmpKVGVYUm\
FUREpPYWsxc1NtMVRWVm95WTBad05scHJkRkpRVkRCcFRFTkthbU50Vm1oa1IxWnJURm\
M1ZFVscWIybE5ha0Y1VGtNd2VFMVRNSGxQVmxGM1QxUnZlazVFYjNoT2FUUXdUV3BhWV\
VscGQybGpTRXAyWlVkc2RHRllValZNV0Vwc1dqSnNlbVJJU21oamFURnFXbGhLTUVscW\
IybFVWV3hLVVRCU1ZWRXdUa0paYXpsdVVWaGtTbEZyUm01VFZXUkNWMnMwZWxSclVuUl\
ZSVEZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U2JtUTBVVE53UWxOclNtNVViRn\
BEVVZac1ZWRlhkRWRWYXpGVFUxaGtSbEZXYkVWV2JFWlNVekJTUW1KRk5XeFdWVFV5V1\
d4b1EyRkhTblZoTTJoSFZrVkdWVkZ0WkU5V2EwcENZekF4UlZKVVJURldWRTVYWVZkTm\
VXSkhkR2hXTUZvMVdsWlNSbFZGTVVKTlJXUkNUVlpXUmxGdVpETlNNVkpaWWtaU2FGZE\
dTbk5VVmtwR1pEQlNNMWRWVWxkVlZrWkZVa1ZHYjFSdFZsZFVia0pyVWpGYVJWVldVa0\
phVlZvelRVaHNUMUpGVmpSVVYzQnlaREE1VlZKVVJrNWxhMXBvVW01amQyVnJOVVZTV0\
doT1lXMTBNMVF4VWtaTlZURTJVbTFHVGxJd2JEUlJNM0JDVTJ0S2JsUnNXa05SVm14Vl\
VWZDBSMVZyTVZOVFdHUkdVVlpzUlZac1JsSlRNRkpDWWtVMWJGWlZOVEpaYkdoRFlVZE\
tkV0V6YUVkU1JVWlVVVzFrVDFaclNrSmpNREZFVFVSRk1WWlVUbGRoVjAxNVlrZDBXbG\
RGYnpGVVZrVTBaREJTVWxkVlVsZFZWa1pKVWtWR1lWUnRWbGRVYmtKclVqRldORkl3VW\
tKV01FcHVWR3hhUTFGVk1VNVNSRUY0VGxaVmVXSkVRbUZXYTNCelYycEtjMlZ0VWtsVG\
JXaHFZV3RLWVZSVlNrNVNNRW8xWTFWa1ZGUlVVVFZSVjJSR1VqQk9SR05WWkZSVVZGRT\
FVVmhrUmxORlJYZFRWVVpEVVZWbmNsUkdjSFJpYmxKdVkwZG5jbUZzVlhaak1rNVZVVz\
VvYTFaSWNIcGtNbmh0VlZSYU1WTjVPVUpQVjBaS1dXdHdZVk15VlRCVlIyd3dWbTVvY2\
1GRk5VaFhWMlF3VG0wNWQwMTVkRVJoVmtaTVZFaGtZVTlYWkVWTlNFWllUV3BKZUZGVm\
VGcE9VM016WWxaR1MwNXViSEZXTTNCRFYyc3hRMDFGWkVKTlZsWnJVMnhHVWxZd01VTl\
ZWV1JFVVROT1NGRldSbFpTYTBvelZGVktRMW95WkhsUmJXUkdVbXRLVWxrd1VrbFNSVV\
pRVVcxa1QxWnJhRkpQUlVwQ1dtcG9SbEZyUms1Uk1Fa3dVVmhrVEZGV2JFVldiRWwzVl\
d0S1JGSllaRWxPUld4cldXeG9jMlZ0UmxsVmJYaHFZbFphZFZsV2FFOU5SMDUwVW01c1\
RXSlVSVEZYVkVrMVpFZE9TRkp1Vm14VmVsWnhXV3BKZDJRd1RtNVhWV3hNWWpGd1NtVn\
RiM2RTVlVZelUxVlNWRkZWUmpOVmJFWktXakJSTTJFd1NqUk5WVGd5VkhwS1IxWkdRbE\
JWYkdkM1RrUmtWR05HVGpKalIwWTJaRU00Y2xJeldYbFBXRTAwVGpOc2VWUllWVEpWUl\
RGRVUxWkdSV1ZWT1RCalIwb3lZa1YzZG1ReFl6UmFlVGxGVTFWNE1sUXdVbHBhTURGUV\
ZERldjbFpFUlRGYVNGcGFWRlZXVDFJeFVYbFJNMVkxV25vd09VbHVNVGtpTENKemFXZH\
VZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYVU5c2MybFVWV3\
hLVVRBMU5sRXdUa0phUkVwdVVWaGtTbEZyUm01VFZXUkNWMnMwZWxSclVuUlRNREZDWW\
pCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U2JXUTBVVE53UWxOclNtNVViRnBEVVZac1\
ZWRlhkRWRWYXpGVFl6TmtTRlZXYkVWV2JFWlNVekJTUTFOck5WcFdlbFY0VjIweFIyRn\
RVa2xXYm14aFYwVnNNMVJWVWtaYU1VWldXVE5vUm1WclJsTlJiV1JQVm10S1FtTXdNVV\
JoZW13MVYycEdibG94V2xoT1dFSnJVbFZXTkZKdWNFSldhMHB1Vkd4YVExRlZNVTVTUj\
NONFlVZEtkVlp0TVZwV01EUjNXa1pvUzJKSFRuSlVhMHBPVVRCR1dWSkdVa3BOUlRGVl\
VsaHNVRlpGUlRGVVZsSldaV3N4VjJJeGJFVmxiWE14VkRGU2NtVkZNWEZVV0doT1lXc3\
dlRlF4VWxaT1ZtUnhVVzVhVGxWWVRqTlJNVVphVWtaYVVsVlZaRVprTUhCRFZsWlNSbG\
xyTVVOaE1HUkNUVlpXUmxFeVpETlZNVkpZVW01V2ExWXhjRzlYVkU1VFRWZE9kRlp1Yk\
U1U1JVWTBVMVZXUjFORk1WTlVXR1JHVlZac1JWWnNSbEpVUlZKQ1kwWkNhbUpYVWxwVF\
ZWcFhaRmRHV1ZWclNrNVZiR3d6VW10R1dsSkdXbEpWVlZwR1pIcEdlVmxXYUZKa1JUbF\
ZXbnBPVDJGc1ZYZFVXSEJLWlVVeFUxZFlaRWRSVm14RlZteEdVbEpGVWtKTlZVcFNZVE\
F4TmxSSGRGWk5NRFZVVFVob1RsSkZTa05VVlZweVpEQldNMWRWYUV4aU1YQktaVzF2ZD\
FFd1JsSlhWV3hNWWpGd1NtVnRiM2RTUlVaU1dUQlNVbG93UmtaYU1EVnlUVmhqTWxwc1\
FrWlNSbXg1Wld0U1NtRnROWGxpVlZZMFVtcFZNRmRIYzNKTE1YQnpXbXBLU1ZSVVVuSl\
JNamxRWW10ME1sWklTbEJOUmxrMFdWVktiMDFYTVRGbGJteFNWbXhWZDJGdWJ6SldWR1\
EyVDFSR1FsTnFiSFpPYkU1VFVXMTRhV0pVU20xUmJGSlFXVlJhVDA1ck1VbGFNMlJPVV\
Zac1NsTXpaRnBSYTBwU1ZsVm9RbFV3UmtaVGEwcGFZVmRLV0ZKdWNGcFZla1YzVjJ4b1\
QwMUZlSFZoUkZac1lsUkdiMWx0TlZkaVZteFlWR3BDYTFkRmNITlpNbXN4WVcxSmVVMU\
VXbEJXUmtWM1ZGaHdRbHByU201VWJGcEpWVEF4UmxJd1VrSldNbVJEVlRGYVZXUkdXWE\
pOTVVaNFN6SnNjbVJzUWt4VVZuQjJUVVZvWVU5WWFFVlRWV2MxVmtWR1ZWRnRaRTlXYT\
JoVVZsVldSVkpGUmt4UmJXUnVZMnRLYmxKVldrTlZWMDVGVVZkd1FsUXdTbTVVYkZwSl\
ZWUm9RMUZYV1RSU1ZVcENWRlZPUTA1RlJqTlJNbVJhVTFWMGRsZHJiRFpoYWtKR1VWaG\
tTbEpHVGtKUldHUlRWVlZzYmxaVVNsVk9hM0JVVDBoV2NWVlVRWHBMTVZGMlpFUkZNbV\
JXVG05YU1teHpUMFV3ZG1KWFJraFdibWgxVTNwU2VHVnJPVTlWUmxaTFVsVk9TbFZWVW\
toVVZsSjRZMjFyZVZaNlFrMVRWV3gwWVdwYVExTXhaREJSVlRrMVYwUktiVkpYWkhaaF\
JrazBVa1pXZVZSRVRrTk5ha1oyVWtkc2JsQlVNR2xZVTNkcFpFaHNkMGxxYjJsa2JUa3\
hXVEpvYkdOcE1YRmtNMDF5WVc1T2RtSnBTWE5KYlVaeldubEpOa2xyVmxSTmFsVXlTVz\
R3SWl3aWMybG5ibUYwZFhKbElqb2laV2haVTFaVVZVWm5Tamc1TUhOR05VWTRhM2sxYm\
1aUFdITkhPVXBOWmtKV1FuWTVVRTlzZDBoV1drZFJia1pSYUZBelJqQkNVV28yWW1vMG\
JVZEpRMk5tYXpWR1IxQkVPSEpLUzNNM2RIaDFRbVpMWjBFaWZWMTkiLCJjcmVhdGVkLW\
9uIjoiMjAyNC0xMS0yOVQwOTozNDoxNi41ODBaIn19",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWk4zTkRt\
Uk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RB\
bE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdB\
MVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHlOREV4\
TWprd09URTFNekZhRncwek5ERXhNamt3T1RFMU16RmFNSGt4Q3pBSkJnTlZCQVlUQWtG\
Uk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMy\
bGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU1pXZHBj\
M1J5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dFd1lI\
S29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXh3ejJJQzdNaW16VGhpS1huczMzTkhT\
SitIdzl2ZHRFb1Y4b2lwQWlPazJtclpWK2dGZVBNNmdadWczby84ak9VZ0NGeGRxb0l2\
U1Y3dkxEU2lic2lxTW5NQ1V3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXh3d0RnWURW\
UjBQQVFIL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSVFENDhKeDh2TlJw\
VE9LREtjWmtjR0xTb2V6REFuTktndDNkU25DNFFkTGpBUUlnZmFxYkFvREtTZnpWcS9p\
cy9Cc2duaUpwQ2VUcU1FTUV0SUIwOGJsRDA5az0iXSwidHlwIjoidm91Y2hlci1qd3Mr\
anNvbiIsImFsZyI6IkVTMjU2In0",
      "signature": "4K-jQbrBtzj_YE9zgJoMZYC1QPgEEU3gTKiaLh5TdO5dcgB1\
z_zguJPSvR_QdpIbZmjkEyIyL9GJDZ2jACLKVg"
    }
  ]
}
Figure 5: Example Parboiled Registrar-Voucher-Request (RVR)

The following private key is used to sign a Registrar-Voucher-Request (RVR) by Registrar:

-----BEGIN PRIVATE KEY-----
MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCDU/WkJnGR67oUgP8L1
bmvYpUPt4i6Rc/OUSg0C8SiWdg==
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIB8DCCAZagAwIBAgIGAZN3NDmRMAoGCCqGSM49BAMCMFwxCzAJBgNVBAYTAkFR
MRIwEAYDVQQKDAlNeUNvbXBhbnkxFTATBgNVBAsMDE15U3Vic2lkaWFyeTEPMA0G
A1UEBwwGTXlTaXRlMREwDwYDVQQDDAhNeVNpdGVDQTAeFw0yNDExMjkwOTE1MzFa
Fw0zNDExMjkwOTE1MzFaMHkxCzAJBgNVBAYTAkFRMRIwEAYDVQQKDAlNeUNvbXBh
bnkxFTATBgNVBAsMDE15U3Vic2lkaWFyeTEPMA0GA1UEBwwGTXlTaXRlMS4wLAYD
VQQDDCVSZWdpc3RyYXIgVm91Y2hlciBSZXF1ZXN0IFNpZ25pbmcgS2V5MFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAExwz2IC7MimzThiKXns33NHSJ+Hw9vdtEoV8o
ipAiOk2mrZV+gFePM6gZug3o/8jOUgCFxdqoIvSV7vLDSibsiqMnMCUwEwYDVR0l
BAwwCgYIKwYBBQUHAxwwDgYDVR0PAQH/BAQDAgeAMAoGCCqGSM49BAMCA0gAMEUC
IQD48Jx8vNRpTOKDKcZkcGLSoezDAnNKgt3dSnC4QdLjAQIgfaqbAoDKSfzVq/is
/BsgniJpCeTqMEMEtIB08blD09k=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB8TCCAZegAwIBAgIGAZN3NDmNMAoGCCqGSM49BAMCMFwxCzAJBgNVBAYTAkFR
MRIwEAYDVQQKDAlNeUNvbXBhbnkxFTATBgNVBAsMDE15U3Vic2lkaWFyeTEPMA0G
A1UEBwwGTXlTaXRlMREwDwYDVQQDDAhNeVNpdGVDQTAeFw0yNDExMjkwOTE1MzFa
Fw0zNDExMjkwOTE1MzFaMFwxCzAJBgNVBAYTAkFRMRIwEAYDVQQKDAlNeUNvbXBh
bnkxFTATBgNVBAsMDE15U3Vic2lkaWFyeTEPMA0GA1UEBwwGTXlTaXRlMREwDwYD
VQQDDAhNeVNpdGVDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABH8hjPIRu6cq
PCZbwd8ACcrHVP0v4Z/DR3lmzHJiYmkpf3+rIeKkOFnFHD7Kywp31QQNz5y8S7QM
4+mprsZMfIKjRTBDMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgIE
MB0GA1UdDgQWBBRqyc1RS4d6zEgDmlDZNYo4hEsLVzAKBggqhkjOPQQDAgNIADBF
AiEAgIe1EsssVJwFrfzD1Wm+aB7kkOr1lde9M7F0zu3F6+kCICatHWEpji/0Vdc/
lDY0RNsylZpJBL3zW+ikOCvvaJEu
-----END CERTIFICATE-----

8.3. Example Voucher Response

The following is an example voucher response as JWS Voucher artifact, which would be sent from the MASA to the Pledge via Registrar.

{
  "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2\
dnZWQiLCJzZXJpYWwtbnVtYmVyIjoia2l0LTk4NzY1NDMyMSIsIm5vbmNlIjoiVGF1dk\
srWS9jYzJSZklGdnBaemZLUT09IiwiY3JlYXRlZC1vbiI6IjIwMjQtMTEtMjlUMDk6Mz\
Q6MTcuMDI5WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUI4VENDQVplZ0F3SUJBZ0\
lHQVpOM05EbU5NQW9HQ0NxR1NNNDlCQU1DTUZ3eEN6QUpCZ05WQkFZVEFrRlJNUkl3RU\
FZRFZRUUtEQWxOZVVOdmJYQmhibmt4RlRBVEJnTlZCQXNNREUxNVUzVmljMmxrYVdGeW\
VURVBNQTBHQTFVRUJ3d0dUWGxUYVhSbE1SRXdEd1lEVlFRRERBaE5lVk5wZEdWRFFUQW\
VGdzB5TkRFeE1qa3dPVEUxTXpGYUZ3MHpOREV4TWprd09URTFNekZhTUZ3eEN6QUpCZ0\
5WQkFZVEFrRlJNUkl3RUFZRFZRUUtEQWxOZVVOdmJYQmhibmt4RlRBVEJnTlZCQXNNRE\
UxNVUzVmljMmxrYVdGeWVURVBNQTBHQTFVRUJ3d0dUWGxUYVhSbE1SRXdEd1lEVlFRRE\
RBaE5lVk5wZEdWRFFUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJIOG\
hqUElSdTZjcVBDWmJ3ZDhBQ2NySFZQMHY0Wi9EUjNsbXpISmlZbWtwZjMrckllS2tPRm\
5GSEQ3S3l3cDMxUVFOejV5OFM3UU00K21wcnNaTWZJS2pSVEJETUJJR0ExVWRFd0VCL3\
dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIL0JBUURBZ0lFTUIwR0ExVWREZ1FXQkJScX\
ljMVJTNGQ2ekVnRG1sRFpOWW80aEVzTFZ6QUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRU\
FnSWUxRXNzc1ZKd0ZyZnpEMVdtK2FCN2trT3IxbGRlOU03RjB6dTNGNitrQ0lDYXRIV0\
VwamkvMFZkYy9sRFkwUk5zeWxacEpCTDN6Vytpa09DdnZhSkV1In19",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQnh6Q0NBVzZnQXdJQkFnSUdBWk4zTkRs\
L01Bb0dDQ3FHU000OUJBTUNNRmd4Q3pBSkJnTlZCQVlUQWtGUk1Sc3dHUVlEVlFRS0RC\
Sk5ZVzUxWm1GamRIVnlaWEl3TURFZ1FVY3hFekFSQmdOVkJBc01Dazl5WjFnZ1ZXNXBk\
RUV4RnpBVkJnTlZCQU1NRGsxaGJuVm1ZV04wZFhKbGNrTkJNQjRYRFRJME1URXlPVEE1\
TVRVek1Wb1hEVE0wTVRFeU9UQTVNVFV6TVZvd2FqRUxNQWtHQTFVRUJoTUNRVkV4R3pB\
WkJnTlZCQW9NRWsxaGJuVm1ZV04wZFhKbGNqQXdNU0JCUnpFVE1CRUdBMVVFQ3d3S1Qz\
Sm5XQ0JWYm1sMFFURXBNQ2NHQTFVRUF3d2dUV0Z1ZFdaaFkzUjFjbVZ5SUZadmRXTm9a\
WElnVTJsbmJtbHVaeUJMWlhrd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05D\
QUFSR0NJM0gwL0xrWnNZNDV1OEZTZ1RLNlpLMUk3d2s1eWZEWk12elo2L3Y5NGJoNFB0\
UG9SU3cwSjBvemhiL2hrRkVGeE5mbkt6WUtvT3dDdU9nUENNUm94SXdFREFPQmdOVkhR\
OEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdCcUF3WkYxRm9kRFBB\
Nzhjcnp2bWJqSHBMUlRUM0hGcWI5UHRXTzhwTjYwQ0lBV1l6aUpUQk9xNXcxNXl2Q05V\
S1pYSEVGMSt2TkUxcjMyTnpVWTBQSEY1Il0sInR5cCI6InZvdWNoZXItandzK2pzb24i\
LCJhbGciOiJFUzI1NiJ9",
      "signature": "TYwc3Nzi4l5A_326zr0IFvpqfzt7v7SqidFK_Go4wNFVCnXa\
t5GngoTboMGXOMelfbx0LqxStz5Tq-5nFSvD2w"
    }
  ]
}
Figure 6: Example Voucher Response

The following private key is used to sign a Voucher by MASA:

-----BEGIN PRIVATE KEY-----
MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCAergZDU0lUzsqylxKs
I0KZZsqgcx+LKJglpD0agoiaWQ==
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIBxzCCAW6gAwIBAgIGAZN3NDl/MAoGCCqGSM49BAMCMFgxCzAJBgNVBAYTAkFR
MRswGQYDVQQKDBJNYW51ZmFjdHVyZXIwMDEgQUcxEzARBgNVBAsMCk9yZ1ggVW5p
dEExFzAVBgNVBAMMDk1hbnVmYWN0dXJlckNBMB4XDTI0MTEyOTA5MTUzMVoXDTM0
MTEyOTA5MTUzMVowajELMAkGA1UEBhMCQVExGzAZBgNVBAoMEk1hbnVmYWN0dXJl
cjAwMSBBRzETMBEGA1UECwwKT3JnWCBVbml0QTEpMCcGA1UEAwwgTWFudWZhY3R1
cmVyIFZvdWNoZXIgU2lnbmluZyBLZXkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AARGCI3H0/LkZsY45u8FSgTK6ZK1I7wk5yfDZMvzZ6/v94bh4PtPoRSw0J0ozhb/
hkFEFxNfnKzYKoOwCuOgPCMRoxIwEDAOBgNVHQ8BAf8EBAMCB4AwCgYIKoZIzj0E
AwIDRwAwRAIgBqAwZF1FodDPA78crzvmbjHpLRTT3HFqb9PtWO8pN60CIAWYziJT
BOq5w15yvCNUKZXHEF1+vNE1r32NzUY0PHF5
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB6DCCAY+gAwIBAgIGAZN3NDl2MAoGCCqGSM49BAMCMFgxCzAJBgNVBAYTAkFR
MRswGQYDVQQKDBJNYW51ZmFjdHVyZXIwMDEgQUcxEzARBgNVBAsMCk9yZ1ggVW5p
dEExFzAVBgNVBAMMDk1hbnVmYWN0dXJlckNBMB4XDTI0MTEyOTA5MTUzMVoXDTM5
MTEyOTA5MTUzMVowWDELMAkGA1UEBhMCQVExGzAZBgNVBAoMEk1hbnVmYWN0dXJl
cjAwMSBBRzETMBEGA1UECwwKT3JnWCBVbml0QTEXMBUGA1UEAwwOTWFudWZhY3R1
cmVyQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATfl/ScKL8rB6DPTjOX4ug/
mCmtrry59h0q4J0r/yEMmGGzKhNSskJ54u22q2kdGcMpAISH59a0SZ6mip60FzLz
o0UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwICBDAdBgNVHQ4E
FgQUlU7Vft0KvopLzyjGaNB2fcQyB/UwCgYIKoZIzj0EAwIDRwAwRAIgN0nzFkSM
iSMygrUBhPARioFiAb+zVPc7sdSy/o3nfSYCIBxGrzP3BssOJTjniu8loqHXyf9m
JKYL4lAyT0nAC0jc
-----END CERTIFICATE-----

9. References

9.1. Normative References

[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-anima-rfc8366bis-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-rfc8366bis-12>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8995]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <https://www.rfc-editor.org/rfc/rfc8995>.

9.2. Informative References

[I-D.ietf-anima-brski-prm]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in Progress, Internet-Draft, draft-ietf-anima-brski-prm-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-15>.
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Van der Stok, P., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-25, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-25>.
[ON-PATH]
"can an on-path attacker drop traffic?", n.d., <https://mailarchive.ietf.org/arch/msg/saag/m1r9uo4xYznOcf85Eyk0Rhut598/>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/rfc/rfc5652>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/rfc/rfc7951>.
[RFC8366]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, , <https://www.rfc-editor.org/rfc/rfc8366>.
[RFC8572]
Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, , <https://www.rfc-editor.org/rfc/rfc8572>.
[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, , <https://www.rfc-editor.org/rfc/rfc8792>.
[RFC8812]
Jones, M., "CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms", RFC 8812, DOI 10.17487/RFC8812, , <https://www.rfc-editor.org/rfc/rfc8812>.

Contributors

Toerless Eckert
Futurewei Technologies Inc.
Esko Dijk
Steffen Fries
Siemens AG

Authors' Addresses

Thomas Werner
Siemens AG
Michael Richardson
Sandelman Software Works