Sandelman Software Works

mcr+ietf@sandelman.ca

Siemens AG

thomas-werner@siemens.com

Internet anima Working Group Internet-Draft RFC8366 defines a digital artifact called voucher as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. This memo introduces a variant of the voucher structure in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to better support use-cases in which JOSE is preferred over CMS. In addition to explaining how the format is created, MIME types are registered and examples are provided.

“A Voucher Artifact for Bootstrapping Protocols”, describes a voucher artifact used in “Bootstrapping Remote Secure Key Infrastructure” and “Secure Zero Touch Provisioning” to transfer ownership of a device from a manufacturer to an owner. That document defines the base YANG module, and also the initial serialization to JSON , with a signature provided by . Other work, provides a mapping of the YANG to CBOR with a signature format of COSE . This document provides an equivalent mapping of JSON format with the signature format as JSON Web Signature (JWS) . The encoding specified in this document is required for and may be required and/or preferred in other use cases, for example when JWS is already used in other parts of the use case, but CMS is not. This document does not extend the YANG definition of at all, but accepts that other efforts such as , , and do. This document supports signing any of the extended schemas defined in those documents and any new documents that may appear after this one. With the availability of different encoded vouchers, it is up to an industry specific application statement to indicate/decide which voucher signature format is to be used. There is no provision across the different voucher signature formats that a receiver could safely recognize which format it uses unless additional context is provided. For example, provides this context via the MIME-Type for the voucher payload. This document should be considered an Update to in the category of “See Also” as per .

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.

[RFC Editor: please delete] /* TODO: … */ defines two serializations: the “JWS Compact Serialization” and the “JWS JSON Serialization”. The JSON structure consists of a nested map, the outer part of which is:

this is considered the JSON payload as described in section 3. A JWS JSON Serialization Overview is given by in section 3.2 and section 7.2.1 provides more details. It works out to:

There are a number of attributes. They are:

[RFC Editor: please delete] /* TODO: … */

The standard “typ” and “alg” values described in are expected in the protected headers. It remains to be determined (XXX), what values, if any, should go into the “typ” header, as in the use cases, there are additional HTTP MIME type headers to indicate content types. The “alg” should contain the algorithm type such as “ES256”. If PKIX format certificates are used then the section 4.1.6 “x5c” certificate chain SHOULD be used to contain the certificate and chain. Vouchers will often need all certificates in the chain, including what would be considered the trust anchor certificate because intermediate devices (such as the Registrar) may need to audit the artifact, or end systems may need to pin a trust anchor for future operations. This is consistent with section 5.5.2.

The Voucher Request reveals the IDevID of the component (Pledge) that is on-boarding. This request occurs over HTTP-over-TLS, however the Pledge to Registrar transaction is over a provisional TLS session, and it is subject to disclosure via by a Dolev-Yao attacker (a “malicious messenger”). This is explained in section 10.2. The use of a JWS header brings no new privacy considerations.

The issues of how vouchers are used in a system is addressed in section 11 of that document. This document does not change any of those issues, it just changes the signature technology used for vouchers and voucher requests. section 9 deals with voucher use in Secure Zero Touch Provisioning, and this document also makes no changes to security.

This section registers the ‘application/voucher-jws+json’ in the “Media Types” registry.

Added adoption call comments from Toerless. Changed from [RFCxxxx] to [THING] style for some key references. Updated references “I-D.ietf-anima-brski-async-enroll” switched to “I-D.ietf-anima-brski-prm” Switch from “JWS Compact Serialization” to “General JWS JSON Serialization”, as focus is now on “General JWS JSON Serialization” Include Voucher representation in “General JWS JSON Serialization” syntax Include examples A1, A2, A3 using “General JWS JSON Serialization”

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. 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. 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. 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. 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] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping 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. Constrained BRSKI 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 is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher 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 CoAPS. Siemens AG Siemens AG Cisco Systems Sandelman Software Works This document defines enhancements to bootstrapping a remote secure key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in domains featuring no or only timely limited connectivity between a pledge and the domain registrar. It specifically targets situations, in which the interaction model changes from a pledge-initiator-mode, as used in BRSKI, to a pledge-responder-mode as described in this document. To support both, BRSKI-PRM introduces a new registrar- agent component, which facilitates the communication between pledge and registrar during the bootstrapping phase. For the establishment of a trust relation between pledge and domain registrar, BRSKI-PRM relies on the exchange of authenticated self-contained objects (signature-wrapped objects). The defined approach is agnostic regarding the utilized enrollment protocol, deployed by the domain registrar to communicate with the Domain CA. Sandelman Software Works Huawei Technologies This document describes an extension of the RFC8366 Voucher Artifact in order to support delegation of signing authority. The initial voucher pins a public identity, and that public indentity can then issue additional vouchers. This chain of authorization can support permission-less resale of devices, as well as guarding against business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] Manufacturer Authorized Signing Authority (MASA). Cisco Auth0 Sandelman Software Works This document specifies the behaviour of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud Ericsson Kaloom An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases.

These examples are folded according to Single Backslash rule.

The following is an example request sent from a Pledge to the Registrar, in “General JWS JSON Serialization”.

The term parboiled refers to food which is partially cooked. In , the term refers to a Pledge voucher-request (PVR) which has been received by the Registrar, and 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) 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 following is an example voucher response from MASA to Pledge via Registrar, in “General JWS JSON Serialization”.