draft-ietf-anima-constrained-voucher-12.txt   draft-ietf-anima-constrained-voucher-13.txt 
anima Working Group M. Richardson anima Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track P. van der Stok Intended status: Standards Track P. van der Stok
Expires: 12 January 2022 vanderstok consultancy Expires: 26 January 2022 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
E. Dijk E. Dijk
IoTconsultancy.nl IoTconsultancy.nl
11 July 2021 25 July 2021
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-12 draft-ietf-anima-constrained-voucher-13
Abstract Abstract
This document defines a protocol to securely assign a Pledge to an This document defines a protocol to securely assign a Pledge to an
owner and to enroll it into the owner's network. The protocol uses owner and to enroll it into the owner's network. The protocol uses
an artifact that is signed by the Pledge's manufacturer. This an artifact that is signed by the Pledge's manufacturer. This
artifact is known as a "voucher". artifact is known as a "voucher".
This document builds upon the work in [RFC8366] and [BRSKI], but This document builds upon the work in [RFC8366] and [BRSKI], but
defines an encoding of the voucher in CBOR rather than JSON, and defines an encoding of the voucher in CBOR rather than JSON, and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 January 2022. This Internet-Draft will expire on 26 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 5
5. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 6 5. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 6
5.1. Discovery, URIs and Content Formats . . . . . . . . . . . 6 5.1. Discovery, URIs and Content Formats . . . . . . . . . . . 6
5.2. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8 5.2. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8
5.3. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 9 5.3. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 9
5.3.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 9 5.3.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 9
5.3.2. Registrar Extensions . . . . . . . . . . . . . . . . 10 5.3.2. Registrar Extensions . . . . . . . . . . . . . . . . 10
6. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 11 6. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 10
7. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11 7. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11
7.1. Registrar Identity Selection and Encoding . . . . . . . . 12 7.1. Registrar Identity Selection and Encoding . . . . . . . . 11
7.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 13 7.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 12
7.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 14 7.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 13
8. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15 8.1. Voucher Request artifact . . . . . . . . . . . . . . . . 14
8.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 8.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15
8.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 15 8.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 15
8.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 16 8.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 16
8.1.4. Example voucher request artifact . . . . . . . . . . 20 8.1.4. Example voucher request artifact . . . . . . . . . . 20
8.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 20 8.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 20 8.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 20
8.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 21 8.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 21
8.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 21 8.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 21
8.2.4. Example voucher artifacts . . . . . . . . . . . . . . 24 8.2.4. Example voucher artifacts . . . . . . . . . . . . . . 24
8.3. Signing voucher and voucher-request artifacts with 8.3. Signing voucher and voucher-request artifacts with
skipping to change at page 3, line 18 skipping to change at page 3, line 18
11.3. Test Domain Certificate Validity when Signing . . . . . 28 11.3. Test Domain Certificate Validity when Signing . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. Resource Type Registry . . . . . . . . . . . . . . . . . 28 12.1. Resource Type Registry . . . . . . . . . . . . . . . . . 28
12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 28 12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 28
12.3. The YANG Module Names Registry . . . . . . . . . . . . . 28 12.3. The YANG Module Names Registry . . . . . . . . . . . . . 28
12.4. The RFC SID range assignment sub-registry . . . . . . . 29 12.4. The RFC SID range assignment sub-registry . . . . . . . 29
12.5. Media Types Registry . . . . . . . . . . . . . . . . . . 29 12.5. Media Types Registry . . . . . . . . . . . . . . . . . . 29
12.5.1. application/voucher-cose+cbor . . . . . . . . . . . 29 12.5.1. application/voucher-cose+cbor . . . . . . . . . . . 29
12.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 30 12.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 30
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Library support for BRSKI . . . . . . . . . . . . . 34 Appendix A. Library support for BRSKI . . . . . . . . . . . . . 34
A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 35 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3. wolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . 37 A.3. wolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Constrained BRSKI-EST messages . . . . . . . . . . . 37 Appendix B. Constrained BRSKI-EST messages . . . . . . . . . . . 37
B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 37 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 37
B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 38 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 38
skipping to change at page 3, line 49 skipping to change at page 3, line 49
C.4. COSE signed voucher request from Registrar to MASA . . . 51 C.4. COSE signed voucher request from Registrar to MASA . . . 51
C.5. COSE signed voucher from MASA to Pledge via Registrar . . 53 C.5. COSE signed voucher from MASA to Pledge via Registrar . . 53
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Secure enrollment of new nodes into constrained networks with Secure enrollment of new nodes into constrained networks with
constrained nodes presents unique challenges. There are network constrained nodes presents unique challenges. There are network
bandwidth and code size issues to contend with. A solution for bandwidth and code size issues to contend with. A solution for
autonomous enrollment such as BRSKI [RFC8995] may be too large in autonomous enrollment such as BRSKI [BRSKI] may be too large in terms
terms of code size or bandwidth required. of code size or bandwidth required.
Therefore, this document defines a constrained version of the voucher Therefore, this document defines a constrained version of the voucher
artifact [RFC8366], along with a constrained version of BRSKI artifact [RFC8366], along with a constrained version of [BRSKI] that
[RFC8995] that makes use of the constrained CoAP-based version of makes use of the constrained CoAP-based version of EST, EST-coaps
EST, EST-coaps [I-D.ietf-ace-coap-est] rather than EST over HTTPS [I-D.ietf-ace-coap-est] rather than EST over HTTPS [RFC7030].
[RFC7030].
While the [RFC8366] voucher is by default serialized to JSON with a While the [RFC8366] voucher is by default serialized to JSON with a
signature in CMS, this document defines a new voucher serialization signature in CMS, this document defines a new voucher serialization
to CBOR ([RFC7049]) with a signature in COSE to CBOR ([RFC7049]) with a signature in COSE
[I-D.ietf-cose-rfc8152bis-struct]. This COSE-signed CBOR-encoded [I-D.ietf-cose-rfc8152bis-struct]. This COSE-signed CBOR-encoded
voucher can be transported using secured CoAP or HTTP. The CoAP voucher can be transported using secured CoAP or HTTP. The CoAP
connection (between Pledge and Registrar) is to be protected by connection (between Pledge and Registrar) is to be protected by
either OSCORE+EDHOC or DTLS (CoAPS). The HTTP connection (between either OSCORE+EDHOC or DTLS (CoAPS). The HTTP connection (between
Registrar and MASA) is to be protected using TLS (HTTPS). Registrar and MASA) is to be protected using TLS (HTTPS).
This document specifies a constrained voucher-request artifact based This document specifies a constrained voucher-request artifact based
on Section 3 of [RFC8995], and voucher(-request) transport over CoAP on Section 3 of [BRSKI], and voucher(-request) transport over CoAP
based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est]. based on Section 3 of [BRSKI] and on [I-D.ietf-ace-coap-est].
The CBOR definitions for the constrained voucher format are defined The CBOR definitions for the constrained voucher format are defined
using the mechanism described in [I-D.ietf-core-yang-cbor] using the using the mechanism described in [I-D.ietf-core-yang-cbor] using the
SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to
convert YANG documents into a list of SID keys is still in its convert YANG documents into a list of SID keys is still in its
infancy, the table of SID values presented here MUST be considered infancy, the table of SID values presented here MUST be considered
normative rather than the output of the pyang tool. normative rather than the output of the pyang tool.
There is additional work when the voucher is integrated into the key- There is additional work when the voucher is integrated into the key-
exchange, described in [I-D.selander-ace-ake-authz]. This work is exchange, described in [I-D.selander-ace-ake-authz]. This work is
not in scope for this document. not in scope for this document.
2. Terminology 2. Terminology
The following terms are defined in [RFC8366], and are used The following terms are defined in [RFC8366], and are used
identically as in that document: artifact, domain, imprint, Join identically as in that document: artifact, domain, imprint, Join
Registrar/Coordinator (JRC), Manufacturer Authorized Signing Registrar/Coordinator (JRC), Manufacturer Authorized Signing
Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and
Voucher. Voucher.
The following terms from [RFC8995] are used identically as in that The following terms from [BRSKI] are used identically as in that
document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, document: Domain CA, enrollment, IDevID, Join Proxy, LDevID,
manufacturer, nonced, nonceless, PKIX. manufacturer, nonced, nonceless, PKIX.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 33 skipping to change at page 5, line 25
protocol between Pledge and Registrar, and BRSKI-MASA for the protocol between Pledge and Registrar, and BRSKI-MASA for the
protocol between the Registrar and the MASA. protocol between the Registrar and the MASA.
Time-based vouchers are supported in this definition, but given that Time-based vouchers are supported in this definition, but given that
constrained devices are extremely unlikely to have accurate time, constrained devices are extremely unlikely to have accurate time,
their use will be uncommon. Most Pledges using these constrained their use will be uncommon. Most Pledges using these constrained
vouchers will be online during enrollment and will use live nonces to vouchers will be online during enrollment and will use live nonces to
provide anti-replay protection rather than expiry times. provide anti-replay protection rather than expiry times.
[RFC8366] defines the voucher artifact, while the Voucher Request [RFC8366] defines the voucher artifact, while the Voucher Request
artifact was defined in [RFC8995]. This document defines both a artifact was defined in [BRSKI]. This document defines both a
constrained voucher and a constrained voucher-request. They are constrained voucher and a constrained voucher-request. They are
presented in the order "voucher-request", followed by a "voucher" presented in the order "voucher-request", followed by a "voucher"
response as this is the order that they occur in the protocol. response as this is the order that they occur in the protocol.
The constrained voucher request MUST be signed by the Pledge. It The constrained voucher request MUST be signed by the Pledge. It
signs using the private key associated with its IDevID X.509 signs using the private key associated with its IDevID X.509
certificate, or if an IDevID is not available, then the private key certificate, or if an IDevID is not available, then the private key
associated with its manufacturer-installed raw public key (RPK). associated with its manufacturer-installed raw public key (RPK).
Section 10 provides additional details on PKIX-less operations. Section 10 provides additional details on PKIX-less operations.
skipping to change at page 6, line 51 skipping to change at page 6, line 42
coaps://server.example.com/est/<short-name> coaps://server.example.com/est/<short-name>
coaps://server.example.com/e/<short-name> coaps://server.example.com/e/<short-name>
coaps://server.example.com/.well-known/est/<short-name> coaps://server.example.com/.well-known/est/<short-name>
Similarly the constrained BRSKI server URIs differ from the BRSKI Similarly the constrained BRSKI server URIs differ from the BRSKI
URIs by replacing the scheme https by coaps and by specifying shorter URIs by replacing the scheme https by coaps and by specifying shorter
resource path names. Below are some examples; the first two using a resource path names. Below are some examples; the first two using a
discovered short path name and the last one using the well-known URI discovered short path name and the last one using the well-known URI
prefix which requires no discovery. This is the same "/.well-known/ prefix which requires no discovery. This is the same "/.well-known/
brski" prefix as defined in [RFC8995] Section 5. brski" prefix as defined in [BRSKI] Section 5.
coaps://server.example.com/brski/<short-name> coaps://server.example.com/brski/<short-name>
coaps://server.example.com/b/<short-name> coaps://server.example.com/b/<short-name>
coaps://server.example.com/.well-known/brski/<short-name> coaps://server.example.com/.well-known/brski/<short-name>
Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations
supported by EST, for which Table 1 in Section 5.1 of supported by EST, for which Table 1 in Section 5.1 of
[I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short [I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short
path names. Similarly, Table 1 provides the mapping from the path names. Similarly, Table 1 provides the mapping from the
supported BRSKI extension URI paths to the constrained-BRSKI URI supported BRSKI extension URI paths to the constrained-BRSKI URI
skipping to change at page 11, line 7 skipping to change at page 10, line 45
configured to not support a request for a single CA certificate for configured to not support a request for a single CA certificate for
operational or security reasons, e.g. because every device enrolled operational or security reasons, e.g. because every device enrolled
into the domain needs to use multiple CAs. In such exception case into the domain needs to use multiple CAs. In such exception case
the Registrar returns the CoAP response 4.06 Not Acceptable to the Registrar returns the CoAP response 4.06 Not Acceptable to
indicate that only the default Content-Format of 281 "application/ indicate that only the default Content-Format of 281 "application/
pkcs7-mime;smime-type=certs-only" which supports multiple pkcs7-mime;smime-type=certs-only" which supports multiple
certificates is available. certificates is available.
6. BRSKI-MASA Protocol 6. BRSKI-MASA Protocol
[RFC8995] section 5.4 describes a connection between the Registrar [BRSKI] section 5.4 describes a connection between the Registrar and
and the MASA as being a normal TLS connection using HTTPS. This the MASA as being a normal TLS connection using HTTPS. This document
document does not change that. The Registrar MAY use the new format does not change that. The Registrar MAY use the new format
"application/voucher-cose+cbor" in its voucher request to MASA, or "application/voucher-cose+cbor" in its voucher request to MASA, or
the existing BRSKI format "application/voucher-cms+json" defined by the existing BRSKI format "application/voucher-cms+json" defined by
[RFC8995]. The MASA MUST support both formats. The Registrar [BRSKI]. The MASA MUST support both formats. The Registrar
indicates the voucher format it wants to receive from MASA using the indicates the voucher format it wants to receive from MASA using the
HTTP Accept header. HTTP Accept header.
At the moment of writing the creation of coaps based MASAs is deemed At the moment of writing the creation of coaps based MASAs is deemed
unrealistic. The use of CoAP for the BRSKI-MASA connection can be unrealistic. The use of CoAP for the BRSKI-MASA connection can be
the subject of another document. Some consideration was made to the subject of another document. Some consideration was made to
specify CoAP support for consistency, but: specify CoAP support for consistency, but:
* the Registrar is not expected to be so constrained that it cannot * the Registrar is not expected to be so constrained that it cannot
support HTTPS client connections. support HTTPS client connections.
skipping to change at page 12, line 7 skipping to change at page 11, line 41
7. Pinning in Voucher Artifacts 7. Pinning in Voucher Artifacts
The voucher is a statement by the MASA for use by the Pledge that The voucher is a statement by the MASA for use by the Pledge that
provide the identity of the Pledge's owner. This section describes provide the identity of the Pledge's owner. This section describes
how the owner's identity is determined and how it is encoded within how the owner's identity is determined and how it is encoded within
the voucher. the voucher.
7.1. Registrar Identity Selection and Encoding 7.1. Registrar Identity Selection and Encoding
Section 5.5 of [RFC8995] describes BRSKI policies for selection of Section 5.5 of [BRSKI] describes BRSKI policies for selection of the
the owner identity. It indicates some of the flexibility that is owner identity. It indicates some of the flexibility that is
possible for the Registrar. The recommendation made there is for the possible for the Registrar. The recommendation made there is for the
Registrar to include only certificates in the voucher request (CMS) Registrar to include only certificates in the voucher request (CMS)
signing structure which participate in the certificate chain that is signing structure that participate in the certificate chain that is
to be pinned. to be pinned.
The MASA is expected to evaluate the certificates included by the The MASA is expected to evaluate the certificates included by the
Registrar in its voucher request, forming them into a chain with the Registrar in its voucher request, forming them into a chain with the
Registrar's (signing) identity on one end. Then, it pins a Registrar's (signing) identity on one end. Then, it pins a
certificate selected from the chain. For instance, for a domain with certificate selected from the chain. For instance, for a domain with
a two-level certification authority (see Figure 1), where the a two-level certification authority (see Figure 1), where the
voucher-request has been signed by "Registrar", its signing structure voucher-request has been signed by "Registrar", its signing structure
includes two additional CA certificates: includes two additional CA certificates:
skipping to change at page 13, line 12 skipping to change at page 12, line 47
The Registrar MUST place all the certificates for the chain in an The Registrar MUST place all the certificates for the chain in an
"x5bag" attribute in the unprotected header [I-D.ietf-cose-x509]. "x5bag" attribute in the unprotected header [I-D.ietf-cose-x509].
7.2. MASA Pinning Policy 7.2. MASA Pinning Policy
The MASA, having assembled and verified the chain in the signing The MASA, having assembled and verified the chain in the signing
structure of the voucher request, will now need to select a structure of the voucher request, will now need to select a
certificate to pin. (For the case that only the Registrar's End- certificate to pin. (For the case that only the Registrar's End-
Entity certificate is included, only this certificate can be selected Entity certificate is included, only this certificate can be selected
and this section does not apply.) The BRSKI policy for pinning by and this section does not apply.) The BRSKI policy for pinning by
the MASA as described in Section 5.5.2 of [RFC8995] leaves much the MASA as described in Section 5.5.2 of [BRSKI] leaves much
flexibility to the manufacturer. The present document adds the flexibility to the manufacturer. The present document adds the
following rules to the MASA pinning policy to reduce the network following rules to the MASA pinning policy to reduce the network
load: load:
1. for a voucher containing a nonce, it SHOULD select the most 1. for a voucher containing a nonce, it SHOULD select the most
specific (lowest-level) CA certificate in the chain. specific (lowest-level) CA certificate in the chain.
2. for a nonceless voucher, it SHOULD select the least-specific 2. for a nonceless voucher, it SHOULD select the least-specific
(highest-level) CA certificate in the chain that is allowed under (highest-level) CA certificate in the chain that is allowed under
the MASA's policy for this specific domain. the MASA's policy for this specific domain.
skipping to change at page 13, line 38 skipping to change at page 13, line 26
Pledge can validate its DTLS connection using less crypto operations. Pledge can validate its DTLS connection using less crypto operations.
The rationale for pinning a CA instead of the Registrar's End-Entity The rationale for pinning a CA instead of the Registrar's End-Entity
certificate directly is the following benefit on constrained certificate directly is the following benefit on constrained
networks: the pinned certificate in the voucher can in common cases networks: the pinned certificate in the voucher can in common cases
be re-used as a Domain CA trust anchor during the EST enrollment and be re-used as a Domain CA trust anchor during the EST enrollment and
during the operational phase that follows after EST enrollment, as during the operational phase that follows after EST enrollment, as
explained in Section 5.3.1. explained in Section 5.3.1.
The rationale for 2. follows from the flexible BRSKI trust model for, The rationale for 2. follows from the flexible BRSKI trust model for,
and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of
[RFC8995]). [BRSKI]).
Using the previous example of a domain with a two-level certification Using the previous example of a domain with a two-level certification
authority, the most specific CA ("Sub-CA") is the identity that is authority, the most specific CA ("Sub-CA") is the identity that is
pinned by MASA in a nonced voucher. A Registrar that wished to have pinned by MASA in a nonced voucher. A Registrar that wished to have
only the Registrar's End-Entity certificate pinned would omit the only the Registrar's End-Entity certificate pinned would omit the
"domain CA" and "Sub-CA" certificates from the voucher-request. "domain CA" and "Sub-CA" certificates from the voucher-request.
In case of a nonceless voucher, the MASA would depending on trust In case of a nonceless voucher, the MASA would depending on trust
level pin only "Registrar" certificate (low trust in customer), or level pin only "Registrar" certificate (low trust in customer), or
the "Sub-CA" certificate (in case of medium trust, implying that any the "Sub-CA" certificate (in case of medium trust, implying that any
skipping to change at page 15, line 13 skipping to change at page 14, line 48
Figure 2: Raw Public Key pinning Figure 2: Raw Public Key pinning
8. Artifacts 8. Artifacts
This section describes for both the voucher request and the voucher This section describes for both the voucher request and the voucher
first the abstract (tree) definition as explained in first the abstract (tree) definition as explained in
[I-D.ietf-netmod-yang-tree-diagrams]. This provides a high-level [I-D.ietf-netmod-yang-tree-diagrams]. This provides a high-level
view of the contents of each artifact. view of the contents of each artifact.
Then the assigned SID values are presented. These have been assigned Then the assigned SID values are presented. These have been assigned
using the rules in [I-D.ietf-core-sid], with an allocation that was using the rules in [I-D.ietf-core-sid].
made via the http://comi.space service.
8.1. Voucher Request artifact 8.1. Voucher Request artifact
8.1.1. Tree Diagram 8.1.1. Tree Diagram
The following diagram is largely a duplicate of the contents of The following diagram is largely a duplicate of the contents of
[RFC8366], with the addition of the fields proximity-registrar-pubk, [RFC8366], with the addition of the fields proximity-registrar-pubk,
proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior- proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior-
signed-voucher-request. signed-voucher-request.
prior-signed-voucher-request is only used between the Registrar and prior-signed-voucher-request is only used between the Registrar and
the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256 the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256
optionally replaces proximity-registrar-cert for the most constrained optionally replaces proximity-registrar-cert for the most constrained
skipping to change at page 25, line 36 skipping to change at page 25, line 36
is called the COSE_Sign1 structure. It is used when only one is called the COSE_Sign1 structure. It is used when only one
signature is used on the body. Support for ECDSA with sha256 signature is used on the body. Support for ECDSA with sha256
(secp256k1 and prime256v1 curves) is REQUIRED. Support for EdDSA is (secp256k1 and prime256v1 curves) is REQUIRED. Support for EdDSA is
encouraged. [TBD EDNOTE: Expand and add a reference why. ] encouraged. [TBD EDNOTE: Expand and add a reference why. ]
An example of the supported COSE-sign1 object structure is shown in An example of the supported COSE-sign1 object structure is shown in
Figure 3. Figure 3.
COSE_Sign1( COSE_Sign1(
[ [
h'A101382E', # { "alg": EC256K1 } h'A101382E', # { "alg": ES256K }
{ {
"kid" : h'7890....1234' # hash256(public key) "kid" : h'7890....1234' # hash256(public key)
}, },
h'1234....5678', #voucher-request binary content h'1234....5678', #voucher-request binary content
h'4567....1234', #voucher-request binary public signature h'4567....1234', #voucher-request binary public signature
] ]
) )
Figure 3: cose-sign1 example in CBOR diagnostic notation Figure 3: cose-sign1 example in CBOR diagnostic notation
skipping to change at page 26, line 39 skipping to change at page 26, line 39
This section explains techniques to reduce the number of bytes that This section explains techniques to reduce the number of bytes that
are sent over the wire during the BRSKI bootstrap. The use of a raw are sent over the wire during the BRSKI bootstrap. The use of a raw
public key (RPK) in the pinning process can significantly reduce the public key (RPK) in the pinning process can significantly reduce the
number of bytes and round trips, but it comes with a few significant number of bytes and round trips, but it comes with a few significant
operational limitations. operational limitations.
10.1. The Registrar Trust Anchor 10.1. The Registrar Trust Anchor
When the Pledge first connects to the Registrar, the connection to When the Pledge first connects to the Registrar, the connection to
the Registrar is provisional, as explained in section 5.6.2 of the Registrar is provisional, as explained in section 5.6.2 of
[RFC8995]. The Registrar provides its public key in a [BRSKI]. The Registrar provides its public key in a
TLSServerCertificate, and the Pledge uses that to validate that TLSServerCertificate, and the Pledge uses that to validate that
integrity of the (D)TLS connection, but it does not validate the integrity of the (D)TLS connection, but it does not validate the
identity of the provided certificate. identity of the provided certificate.
As the TLSServerCertificate object is never verified directly by the As the TLSServerCertificate object is never verified directly by the
pledge, sending it can be considered superfluous. Instead of using a pledge, sending it can be considered superfluous. Instead of using a
(TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]), (TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]),
a RawPublicKey object is used. a RawPublicKey object is used.
A Registrar operating in a mixed environment can determine whether to A Registrar operating in a mixed environment can determine whether to
skipping to change at page 27, line 31 skipping to change at page 27, line 31
As the format of the pubk field is identical to the TLS Certificate As the format of the pubk field is identical to the TLS Certificate
RawPublicKey, no manipulation at all is needed to insert this into a RawPublicKey, no manipulation at all is needed to insert this into a
voucher-request. voucher-request.
10.3. The Voucher Response 10.3. The Voucher Response
A returned voucher will have a pinned-domain-subk field with the A returned voucher will have a pinned-domain-subk field with the
identical key as was found in the proximity-registrar-pubk field identical key as was found in the proximity-registrar-pubk field
above, as well as in the TLS connection. Validation of this key by above, as well as in the TLS connection. Validation of this key by
the pledge is what takes the DTLS connection out of the provisional the pledge is what takes the DTLS connection out of the provisional
state (see [RFC8995] section 5.6.2). state (see [BRSKI] section 5.6.2).
The voucher needs to be validated first. The Pledge needs to have a The voucher needs to be validated first. The Pledge needs to have a
public key to validate the signature from the MASA on the voucher. public key to validate the signature from the MASA on the voucher.
In certain cases, the MASA's public key counterpart of the (private) In certain cases, the MASA's public key counterpart of the (private)
signing key is already installed in the Pledge at manufacturing time. signing key is already installed in the Pledge at manufacturing time.
In other cases, if the MASA signing key is based upon a PKI (see In other cases, if the MASA signing key is based upon a PKI (see
[I-D.richardson-anima-masa-considerations] Section 2.3), then a [I-D.richardson-anima-masa-considerations] Section 2.3), then a
certificate chain may need to be included with the voucher in order certificate chain may need to be included with the voucher in order
for the pledge to validate the signature. In CMS signed artifacts, for the pledge to validate the signature. In CMS signed artifacts,
skipping to change at page 30, line 7 skipping to change at page 30, line 7
This section registers the 'application/voucher-cose+cbor' in the This section registers the 'application/voucher-cose+cbor' in the
IANA "Media Types" registry. This media type is used to indicate IANA "Media Types" registry. This media type is used to indicate
that the content is a CBOR voucher or voucher request signed with a that the content is a CBOR voucher or voucher request signed with a
COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct]. COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct].
12.5.1. application/voucher-cose+cbor 12.5.1. application/voucher-cose+cbor
Type name: application Type name: application
Subtype name: voucher-cose+cbor Subtype name: voucher-cose+cbor
Required parameters: none Required parameters: none
Optional parameters: cose-type Optional parameters: none
Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects Encoding considerations: binary
signed with one signer. Security considerations: Security Considerations of THIS RFC.
Security considerations: See Security Considerations, Section
Interoperability considerations: The format is designed to be Interoperability considerations: The format is designed to be
broadly interoperable. broadly interoperable.
Published specification: THIS RFC. Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch, and other Applications that use this media type: ANIMA, 6tisch, and other
zero-touch imprinting systems zero-touch onboarding systems
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .vch File extension(s): .vch
Macintosh file type code(s): none Macintosh file type code(s): none
Person & email address to contact for further information: IETF Person & email address to contact for further information: IETF
ANIMA WG ANIMA WG
Intended usage: LIMITED Intended usage: LIMITED
Restrictions on usage: NONE Restrictions on usage: NONE
Author: ANIMA WG Author: ANIMA WG
Change controller: IETF Change controller: IETF
Provisional registration? (standards tree only): NO Provisional registration? (standards tree only): NO
12.6. CoAP Content-Format Registry 12.6. CoAP Content-Format Registry
Additions to the sub-registry "CoAP Content-Formats", within the Additions to the sub-registry "CoAP Content-Formats", within the
"CoRE Parameters" registry are needed for two media types. These can "CoRE Parameters" registry are needed for two media types. These can
be registered either in the Expert Review range (0-255) or IETF be registered either in the Expert Review range (0-255) or IETF
Review range (256-9999). Review range (256-9999).
Media type mime type Encoding ID References Media type Encoding ID References
---------------------------- ----------- --------- ---- ---------- ---------------------------- --------- ---- ----------
application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] application/voucher-cose+cbor TBD3 [This RFC]
13. Acknowledgements 13. Acknowledgements
We are very grateful to Jim Schaad for explaining COSE and CMS We are very grateful to Jim Schaad for explaining COSE and CMS
choices. Also thanks to Jim Schaad for correcting earlier version of choices. Also thanks to Jim Schaad for correcting earlier version of
the COSE Sign1 objects. the COSE Sign1 objects.
Michel Veillette did extensive work on pyang to extend it to support Michel Veillette did extensive work on _pyang_ to extend it to
the SID allocation process, and this document was among its first support the SID allocation process, and this document was among its
uses. first users.
14. Changelog 14. Changelog
-10 Design considerations extended Examples made consistent -10 Design considerations extended Examples made consistent
-08 Examples for cose_sign1 are completed and improved. -08 Examples for cose_sign1 are completed and improved.
-06 New SID values assigned; regenerated examples -06 New SID values assigned; regenerated examples
-04 voucher and request-voucher MUST be signed examples for signed -04 voucher and request-voucher MUST be signed examples for signed
request are added in appendix IANA SID registration is updated SID request are added in appendix IANA SID registration is updated SID
values in examples are aligned signed cms examples aligned with new values in examples are aligned signed cms examples aligned with new
SIDs SIDs
-03 -03
skipping to change at page 31, line 38 skipping to change at page 31, line 33
-01 -01
application/json is optional, application/cbor is compulsory application/json is optional, application/cbor is compulsory
Cms and cose mediatypes are introduced Cms and cose mediatypes are introduced
15. References 15. References
15.1. Normative References 15.1. Normative References
[BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Constrained Join Protocol (CoJP) for 6TiSCH", Work in "Constrained Join Protocol (CoJP) for 6TiSCH", Work in
Progress, Internet-Draft, draft-ietf-6tisch-minimal- Progress, Internet-Draft, draft-ietf-6tisch-minimal-
security-15, 10 December 2019, security-15, 10 December 2019,
<https://www.ietf.org/archive/id/draft-ietf-6tisch- <https://www.ietf.org/archive/id/draft-ietf-6tisch-
minimal-security-15.txt>. minimal-security-15.txt>.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S.
skipping to change at page 33, line 45 skipping to change at page 33, line 45
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
15.2. Informative References 15.2. Informative References
[COSE-registry] [COSE-registry]
IANA, ., "CBOR Object Signing and Encryption (COSE) IANA, ., "CBOR Object Signing and Encryption (COSE)
registry", 2017, registry", 2017,
<https://www.iana.org/assignments/cose/cose.xhtml>. <https://www.iana.org/assignments/cose/cose.xhtml>.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Work in Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-tree- Progress, Internet-Draft, draft-ietf-netmod-yang-tree-
skipping to change at page 55, line 12 skipping to change at page 55, line 12
Authors' Addresses Authors' Addresses
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Peter van der Stok Peter van der Stok
vanderstok consultancy vanderstok consultancy
Email: consultancy@vanderstok.org Email: stokcons@bbhmail.nl
Panos Kampanakis Panos Kampanakis
Cisco Systems Cisco Systems
Email: pkampana@cisco.com Email: pkampana@cisco.com
Esko Dijk Esko Dijk
IoTconsultancy.nl IoTconsultancy.nl
Email: esko.dijk@iotconsultancy.nl Email: esko.dijk@iotconsultancy.nl
 End of changes. 33 change blocks. 
56 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/