Internet-Draft | JWS-voucher | August 2023 |
Werner & Richardson | Expires 19 February 2024 | [Page] |
RFC8366 defines a digital artifact called 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 explaining how the format is created, 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 19 February 2024.¶
Copyright (c) 2023 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.draft-ietf-anima-rfc8366bis] defines a YANG-based data structure used in "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 (site domain). That document provides a serialization of the voucher data to JSON [RFC8259] with a signature according to the Cryptographic Message Syntax (CMS) [RFC5652]. The resulting voucher artifact has the media type "application/voucher-cms+json".¶
[I-D.ietf-anima-constrained-voucher] provides a serialization of the voucher to CBOR [RFC8949] with the signature format of COSE [RFC8812] and the media type "application/voucher-cose+cbor".¶
This document provides a serialization of the voucher data to JSON [RFC8259] with the signature in form of JSON Web Signature (JWS) [RFC7515] and the media type "application/voucher-jws+json". The encoding specified in this document is used by [I-D.ietf-anima-brski-prm] and may be more handy for use cases requiring signed JSON objects.¶
This document does not extend the YANG definition of [I-D.draft-ietf-anima-rfc8366bis].¶
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, [BRSKI] provides this context via the media type for the voucher artifact. This document utilizes the optional "typ" (Type) Header Parameter of JWS [RFC7515] to provide information about the signed object.¶
This document should be considered an update to [I-D.draft-ietf-anima-rfc8366bis] in the category of "See Also" as per [I-D.kuehlewind-update-tag]. TODO: double check with RFC8366bis¶
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.¶
A signed statement from the MASA service [I-D.draft-ietf-anima-rfc8366bis].¶
A JWS structure signing the JSON Voucher Data.¶
An unsigned JSON document that conforms with the data model described by the ietf-voucher YANG module.¶
Denotes the base64url encoding of OCTETS, per Section 2 of [RFC7515].¶
Denotes the octets of the UTF-8 [RFC3629] representation of STRING, per Section 1 of [RFC7515].¶
[RFC7515] defines the following serializations for JWS:¶
This document makes use of the "General JWS JSON Serialization Syntax" of [RFC7515] to support multiple signatures, as already supported by [RFC8366] for CMS-signed vouchers.¶
JWS Voucher artifacts MUST use the "General JWS JSON Serialization Syntax" defined in Section 7.2.1 of [RFC7515]. A "JWS JSON Serialization Overview" is given in Section 3.2 of [RFC7515] and more details on the JWS serializations in Section 7 of [RFC7515]. The following figure summarizes the serialization of JWS Voucher artifacts:¶
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 5.3 of [I-D.draft-ietf-anima-rfc8366bis] and is encoded using the rules defined in [RFC7951]. The following figure provides an example of JSON Voucher Data:¶
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 JWS Protected Header defined in [RFC7515] uses the standard header parameters "alg", "typ", and "x5c". The octets of the UTF-8 representation of the JWS Protected Header are base64url-encoded to become the string value of the "protected" member as described in Section 3.2 of [RFC7515].¶
The "alg" parameter MUST contain the algorithm type used to create the signature, e.g., "ES256" as defined in Section 4.1.1 of [RFC7515]. If present, the "typ" parameter SHOULD contain the value "TODO: voucher-jws+json" as defined in Section 4.1.9 of [RFC7515].¶
If X.509 (PKIX) certificates [RFC5280] are used, the "x5c" parameter SHOULD contain the base64-encoded (not base64url-encoded) DER certificate and chain as defined in Section 4.1.6 of [RFC7515]. 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. Note, a trust anchor SHOULD be provided differently to be trusted. This is consistent with Section 5.5.2 of [BRSKI].¶
The following figure gives an example of a JWS Protected Header in JSON syntax:¶
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 generated JWS Signature is base64url-encoded to become the string value of the "signature" member.¶
The Voucher Request reveals the IDevID of the component (Pledge) that is in the process of bootstrapping.¶
This request occurs via HTTP-over-TLS, however, for the Pledge-to-Registrar TLS connection, the Pledge is provisionally accepting the Registrar server certificate. Hence it is subject to disclosure by a Dolev-Yao attacker (a "malicious messenger") [ON-PATH], as explained in Section 10.2 of [BRSKI].¶
The use of a JWS header brings no new privacy considerations.¶
The issues of how [I-D.draft-ietf-anima-rfc8366bis] vouchers are used in a [BRSKI] system is addressed in Section 11 of [BRSKI]. 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 [SZTP] deals with voucher use in Secure Zero Touch Provisioning, for which this document also makes no changes to security.¶
This section registers the "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, ...TODO Support in PoC implementations Hong Rui Li and He Peng Jia, ...TODO¶
[RFC Editor: please delete] TODO: ...¶
-- back¶
These examples are folded according to [RFC8792] 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 [BRSKI], 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".¶