]> Siemens AG

thomas-werner@siemens.com

Sandelman Software Works

mcr+ietf@sandelman.ca

Internet anima Working Group Internet-Draft This document introduces a variant of the RFC8366 voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515. This supports 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.

Introduction This document provides cryptographic signing of voucher data in form of JSON Web Signature (JWS) and the media type application/voucher-jws+json to identify the voucher format. The encoding specified in this document is used by and may be more handy for use cases already using Javascript Object Signing and Encryption (JOSE). This is an extension to "A Voucher Artifact for Bootstrapping Protocols" in which the YANG data model is used by "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" and "Secure Zero Touch Provisioning (SZTP)" 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 with cryptographic signing according to the Cryptographic Message Syntax (CMS) . This document is similar to , which provides cryptographic signing according COSE . These documents do not change nor extend the YANG definitions of . 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.

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 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 a Manufacturer Authorized Signing Authority (MASA) service that indicates to a Pledge the cryptographic identity of the domain it should trust, per .

Voucher Data:

The raw (serialized) representation of the ietf-voucher YANG module without any enclosing signature, per .

MASA (Manufacturer Authorized Signing Authority):

The entity that, for the purpose of this document, issues and signs the vouchers for the 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 .

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 .

Registrar:

A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain, per .

This document uses the following encoding notations:

BASE64URL(OCTETS):

Denotes the base64url encoding of OCTETS, per .

UTF8(STRING):

Denotes the octets of the UTF-8 representation of STRING, per .

Voucher Artifact with JSON Web Signature JWS voucher artifacts MUST use the "General JWS JSON Serialization Syntax" defined in . This syntax supports multiple signatures as already supported by for CMS-signed vouchers. The following figure summarizes the serialization of JWS voucher artifacts:

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 . The JWS Payload is further base64url-encoded to become the string value of the payload member as described in . 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.

JSON Voucher Data The JSON Voucher Data is an unsigned JSON document that conforms with the data model described by the ietf-voucher YANG module defined in and is encoded using the rules defined in . The following figure provides an example of JSON Voucher Data:

JSON Voucher Data Example

JWS Protected Header The JWS Protected Header defined in 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 .
• 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 . If present, the typ parameter MUST contain the value voucher-jws+json.
• If X.509 (PKIX) certificates are used, the x5c parameter MUST contain the base64-encoded (not base64url-encoded) X.509 v3 (DER) certificate as defined in and MUST also contain the certificate chain.

Implementation Note:

base64-encoded values, in contrast to base64url-encoded values, may contain slashes (/). JSON 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 MUST be provided out-of-band up front. The following figure gives an example of a JWS Protected Header:

JWS Protected Header Example

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 .

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") , as explained in . The use of a JWS header, with mentioned standard header parameters alg, typ, and x5c, brings no new privacy considerations next to .

Security Considerations The issues of how vouchers are used in a BRSKI system is addressed in . This document does not change any of those issues, it just changes the signature technology used for voucher request and response artifacts. deals with voucher use in Secure Zero Touch Provisioning (SZTP), for which this document also makes no changes to security.

IANA Considerations

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

application/voucher-jws+json

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.

Examples These examples are folded according to the Single Backslash rule.

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:

Example Pledge-Voucher-Request (PVR)

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

Example Registrar-Voucher-Request (RVR) 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.

Example Registrar-Voucher-Request (RVR)

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

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.

Example Voucher Response

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

References Normative References This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Watsen Networks Sandelman Software Cisco Systems Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. n.d. Siemens AG Siemens AG Cisco Systems Sandelman Software Works This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the Key Infrastructure (e.g., domain CA). Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148.

Contributors Futurewei Technologies Inc.

tte+ietf@cs.fau.de

esko.dijk@iotconsultancy.nl

Siemens AG

steffen.fries@siemens.com