Internet-Draft | JWS-voucher | November 2024 |
Werner & Richardson | Expires 9 May 2025 | [Page] |
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.¶
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 9 May 2025.¶
Copyright (c) 2024 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.¶
"A Voucher Artifact for Bootstrapping Protocols" [I-D.ietf-anima-rfc8366bis] defines a YANG-based data structure
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.¶
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:¶
An unsigned JSON representation of the voucher data.¶
A JWS structure signing the JSON Voucher Data.¶
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].¶
The raw (serialized) representation of the ietf-voucher
YANG module without any enclosing signature, per [I-D.ietf-anima-rfc8366bis].¶
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].¶
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].¶
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:¶
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:¶
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.¶
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:¶
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.¶
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 need to 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:¶
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].¶
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.¶
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.¶
This section registers application/voucher-jws+json
in the "Media Types" registry.¶
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¶
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.¶
These examples are folded according to the [RFC8792] Single Backslash rule.¶
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:¶
The term parboiled refers to food which is partially cooked. In [BRSKI], 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 that the previous PVR can be seen in the payload in the field prior-signed-voucher-request
.¶
The following is an example voucher response as JWS Voucher artifact, which would be sent from the MASA to the Pledge via Registrar.¶