draft-ietf-anima-constrained-voucher-11.txt   draft-ietf-anima-constrained-voucher-12.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 December 2021 vanderstok consultancy Expires: 12 January 2022 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
E. Dijk E. Dijk
IoTconsultancy.nl IoTconsultancy.nl
10 June 2021 11 July 2021
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-11 draft-ietf-anima-constrained-voucher-12
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 December 2021. This Internet-Draft will expire on 12 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 11
7. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 12 7. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11
7.1. Registrar Identity Selection and Encoding . . . . . . . . 12 7.1. Registrar Identity Selection and Encoding . . . . . . . . 12
7.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 13 7.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 13
7.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 14 7.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 14
8. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15 8.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15
8.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 8.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15
8.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 21 8.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 21 8.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 20
8.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 21 8.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 21
8.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 22 8.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 21
8.2.4. Example voucher artifacts . . . . . . . . . . . . . . 25 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
COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Design Considerations . . . . . . . . . . . . . . . . . . . . 26 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 26
10. Raw Public Key Use Considerations . . . . . . . . . . . . . . 26 10. Raw Public Key Use Considerations . . . . . . . . . . . . . . 26
10.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 27 10.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 26
10.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 27 10.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 27
10.3. The Voucher Response . . . . . . . . . . . . . . . . . . 27 10.3. The Voucher Response . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 28 11.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 27
11.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 28 11.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . 34 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
Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 38 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 38
C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 42 C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 42
C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 42 C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 42
C.1.2. Registrar private key . . . . . . . . . . . . . . . . 42 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 42
C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 43 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 43
C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 43 C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 43
C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 43 C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 43
C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 45 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 45
C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 47 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 47
C.3. COSE signed voucher request from Pledge to Registrar . . 49 C.3. COSE signed voucher request from Pledge to Registrar . . 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
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 [I-D.ietf-anima-bootstrapping-keyinfra] autonomous enrollment such as BRSKI [RFC8995] may be too large in
may be too large in terms of code size or bandwidth required. terms 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
[I-D.ietf-anima-bootstrapping-keyinfra] that makes use of the [RFC8995] that makes use of the constrained CoAP-based version of
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 [I-D.ietf-anima-bootstrapping-keyinfra], and on Section 3 of [RFC8995], and voucher(-request) transport over CoAP
voucher(-request) transport over CoAP based on Section 3 of based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est].
[I-D.ietf-anima-bootstrapping-keyinfra] 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 should 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 [I-D.ietf-anima-bootstrapping-keyinfra] are The following terms from [RFC8995] are used identically as in that
used identically as in that document: Domain CA, enrollment, IDevID, document: Domain CA, enrollment, IDevID, Join Proxy, LDevID,
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.
4. Overview of Protocol 4. Overview of Protocol
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 [I-D.ietf-anima-bootstrapping-keyinfra]. artifact was defined in [RFC8995]. This document defines both a
This document defines both a constrained voucher and a constrained constrained voucher and a constrained voucher-request. They are
voucher-request. They are presented in the order "voucher-request", presented in the order "voucher-request", followed by a "voucher"
followed by a "voucher" response as this is the order that they occur response as this is the order that they occur in the protocol.
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.
The constrained voucher MUST be signed by the MASA. The constrained voucher MUST be signed by the MASA.
For the constrained voucher request this document defines two For the constrained voucher request this document defines two
skipping to change at page 6, line 33 skipping to change at page 6, line 33
This section describes the constrained BRSKI extensions to EST-coaps This section describes the constrained BRSKI extensions to EST-coaps
[I-D.ietf-ace-coap-est] to transport the voucher between Registrar [I-D.ietf-ace-coap-est] to transport the voucher between Registrar
and Pledge (optionally via a Join Proxy) over CoAP. The extensions and Pledge (optionally via a Join Proxy) over CoAP. The extensions
are targeting low-resource networks with small packets. are targeting low-resource networks with small packets.
The constrained BRSKI-EST protocol described in this section is The constrained BRSKI-EST protocol described in this section is
between the Pledge and the Registrar only. between the Pledge and the Registrar only.
5.1. Discovery, URIs and Content Formats 5.1. Discovery, URIs and Content Formats
Saving header space is important and this is the reason that the EST- To keep the protocol messages small the EST-coaps and constrained-
coaps and constrained-BRSKI URIs are shorter than the respective EST BRSKI URIs are shorter than the respective EST and BRSKI URIs.
and BRSKI URIs.
The EST-coaps server URIs differ from the EST URIs by replacing the The EST-coaps server URIs differ from the EST URIs by replacing the
scheme https by coaps and by specifying shorter resource path names. scheme https by coaps and by specifying shorter resource path names.
Below are some examples; the first two using a discovered short path Below are some examples; the first two using a discovered short path
name and the last one using the well-known URI of EST which requires name and the last one using the well-known URI of EST which requires
no discovery. no discovery.
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 [I-D.ietf-anima-bootstrapping-keyinfra] brski" prefix as defined in [RFC8995] Section 5.
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 8, line 38 skipping to change at page 8, line 28
for a particular resource on the server. The server responds with for a particular resource on the server. The server responds with
only the root path for the BRSKI resource (rt=brski, resource /b in only the root path for the BRSKI resource (rt=brski, resource /b in
above example) and no others in case the client queries for only above example) and no others in case the client queries for only
rt=brski type resources. (So, a query for rt=brski, without the rt=brski type resources. (So, a query for rt=brski, without the
wildcard character.) wildcard character.)
The return of multiple content-types in the "ct" attribute allows the The return of multiple content-types in the "ct" attribute allows the
Pledge to choose the most appropriate one. Note that Content-Format Pledge to choose the most appropriate one. Note that Content-Format
TBD3 ("application/voucher-cose+cbor") is defined in this document. TBD3 ("application/voucher-cose+cbor") is defined in this document.
The Content-Format 50 ("application/json") MAY be supported and 60 The Content-Format 50 ("application/json") MAY be supported and
("application/cbor") MUST be supported by the Registrar for the /vs Content-Format 60 ("application/cbor") MUST be supported by the
and /es resources. Content-Format TBD3 MUST be supported by the Registrar for the /vs and /es resources. Content-Format TBD3 MUST be
Registrar for the /rv resource. If the "ct" attribute is not supported by the Registrar for the /rv resource. If the "ct"
indicated for the /rv resource in the link format description, this attribute is not indicated for the /rv resource in the link format
implies that at least TBD3 is supported. description, this implies that at least TBD3 is supported.
The Pledge and MASA need to support one or more formats (at least The Pledge and MASA need to support one or more formats (at least
TBD3) for the voucher and for the voucher request. The MASA needs to TBD3) for the voucher and for the voucher request. The MASA needs to
support all formats that the Pledge, produced by that manufacturer, support all formats that the Pledge, produced by that manufacturer,
supports. supports.
5.2. Extensions to BRSKI 5.2. Extensions to BRSKI
A Pledge that only supports the BRSKI bootstrap method and already A Pledge that only supports the BRSKI bootstrap method and already
knows the IP address and port of a Registrar or Join Proxy to use knows the IP address and port of a Registrar or Join Proxy to use
skipping to change at page 11, line 12 skipping to change at page 10, line 41
the Registrar for the /vs and /es resources. Content-Format TBD3 the Registrar for the /vs and /es resources. Content-Format TBD3
MUST be supported by the Registrar for the /rv resource. MUST be supported by the Registrar for the /rv resource.
When a Registrar receives a "CA certificates request" (/crts) request When a Registrar receives a "CA certificates request" (/crts) request
with a CoAP Accept Option with value TBD287 ("application/pkix-cert") with a CoAP Accept Option with value TBD287 ("application/pkix-cert")
it SHOULD return only the single CA certificate that is the it SHOULD return only the single CA certificate that is the
envisioned or actual authority for the current, authenticated Pledge envisioned or actual authority for the current, authenticated Pledge
making the request. The only exception case is when the Registrar is making the request. The only exception case is when the Registrar is
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 at least multiple CAs. In such into the domain needs to use multiple CAs. In such exception case
exception case the Registrar returns the CoAP response 4.06 Not the Registrar returns the CoAP response 4.06 Not Acceptable to
Acceptable to indicate that only the default Content-Format of 281 indicate that only the default Content-Format of 281 "application/
"application/pkcs7-mime;smime-type=certs-only" which supports pkcs7-mime;smime-type=certs-only" which supports multiple
multiple certificates is available. certificates is available.
6. BRSKI-MASA Protocol 6. BRSKI-MASA Protocol
[I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 describes a [RFC8995] section 5.4 describes a connection between the Registrar
connection between the Registrar and the MASA as being a normal TLS and the MASA as being a normal TLS connection using HTTPS. This
connection using HTTPS. This document does not change that. The document does not change that. The Registrar MAY use the new format
Registrar MAY use the new format "application/voucher-cose+cbor" in "application/voucher-cose+cbor" in its voucher request to MASA, or
its voucher request to MASA, or the existing BRSKI format the existing BRSKI format "application/voucher-cms+json" defined by
"application/voucher-cms+json" defined by [RFC8995]. The MASA MUST support both formats. The Registrar
[I-D.ietf-anima-bootstrapping-keyinfra]. The MASA MUST support both indicates the voucher format it wants to receive from MASA using the
formats. The Registrar indicates the voucher format it wants to HTTP Accept header.
receive from MASA using the 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.
* the technology and experience to build Internet-scale HTTPS * the technology and experience to build Internet-scale HTTPS
skipping to change at page 12, line 10 skipping to change at page 11, line 45
* similarly, a manufacturer is likely to offer both constrained and * similarly, a manufacturer is likely to offer both constrained and
non-constrained devices, so there may in practice be no situation non-constrained devices, so there may in practice be no situation
in which the MASA could be CoAP-only. Additionally, as the MASA in which the MASA could be CoAP-only. Additionally, as the MASA
is intended to be a function that can easily be oursourced to a is intended to be a function that can easily be oursourced to a
third-party service provider, reducing the complexity would also third-party service provider, reducing the complexity would also
seem to reduce the cost of that function. seem to reduce the cost of that function.
7. Pinning in Voucher Artifacts 7. Pinning in Voucher Artifacts
The voucher is a statement from the MASA to the Pledge indicating the The voucher is a statement by the MASA for use by the Pledge that
owner of the Pledge. This section describes how the owner's identity provide the identity of the Pledge's owner. This section describes
is determined and how it is encoded within the voucher. how the owner's identity is determined and how it is encoded within
the voucher.
7.1. Registrar Identity Selection and Encoding 7.1. Registrar Identity Selection and Encoding
Section 5.5 of [I-D.ietf-anima-bootstrapping-keyinfra] describes Section 5.5 of [RFC8995] describes BRSKI policies for selection of
BRSKI policies for selection of the owner identity. It indicates the owner identity. It indicates some of the flexibility that is
some of the flexibility that is possible for the Registrar. The possible for the Registrar. The recommendation made there is for the
recommendation made there is for the Registrar to include only Registrar to include only certificates in the voucher request (CMS)
certificates in the voucher request (CMS) signing structure which signing structure which participate in the certificate chain that is
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 7 skipping to change at page 12, line 45
.----------------. .----------------.
| domain | | domain |
| Registrar (3) | | Registrar (3) |
| EE certificate | | EE certificate |
'----------------' '----------------'
Figure 1: Two-Level CA PKI Figure 1: Two-Level CA PKI
When the Registrar is using a COSE-signed constrained voucher request When the Registrar is using a COSE-signed constrained voucher request
towards MASA, instead of a regular CMS-signed voucher request, the towards MASA, instead of a regular CMS-signed voucher request, the
COSE_Sign1 object contains a protected and an unprotected header, and COSE_Sign1 object contains a protected and an unprotected header.
according to [I-D.ietf-cose-x509], would carry all the certificates The Registrar MUST place all the certificates for the chain in an
of the chain in an "x5bag" or "x5chain" attribute placed in the "x5bag" attribute in the unprotected header [I-D.ietf-cose-x509].
unprotected header.
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 in the voucher in case there are multiple certificate to pin. (For the case that only the Registrar's End-
available. (For the case that only the Registrar's End-Entity Entity certificate is included, only this certificate can be selected
certificate is included, only this certificate can be selected and and this section does not apply.) The BRSKI policy for pinning by
this section does not apply.) The BRSKI policy for pinning by the the MASA as described in Section 5.5.2 of [RFC8995] leaves much
MASA as described in Section 5.5.2 of flexibility to the manufacturer. The present document adds the
[I-D.ietf-anima-bootstrapping-keyinfra] leaves much flexibility to following rules to the MASA pinning policy to reduce the network
the manufacturer. The present document adds the following rules to load:
the MASA pinning policy to reduce the network 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.
The rationale for 1. is that in case of a voucher with nonce, the The rationale for 1. is that in case of a voucher with nonce, the
voucher is valid only in scope of the present DTLS connection between voucher is valid only in scope of the present DTLS connection between
skipping to change at page 13, line 46 skipping to change at page 13, line 38
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
[I-D.ietf-anima-bootstrapping-keyinfra]). [RFC8995]).
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 14, line 25 skipping to change at page 14, line 17
Specifically for constrained use cases, the pinning of the raw public Specifically for constrained use cases, the pinning of the raw public
key (RPK) of the Registrar is also supported in the constrained key (RPK) of the Registrar is also supported in the constrained
voucher, instead of an X.509 certificate. If an RPK is pinned it voucher, instead of an X.509 certificate. If an RPK is pinned it
MUST be the RPK of the Registrar. MUST be the RPK of the Registrar.
When the Pledge is known by MASA to support RPK but not X.509 When the Pledge is known by MASA to support RPK but not X.509
certificates, the voucher produced by the MASA pins the RPK of the certificates, the voucher produced by the MASA pins the RPK of the
Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk- Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk-
sha256" field of a voucher. This is described in more detail in sha256" field of a voucher. This is described in more detail in
Section 8.2.3. A Pledge that does not support X.509 certificates Section 8.2.3. A Pledge that does not support X.509 certificates
cannot use EST to enroll; it has to use another method for cannot use EST to enroll; it has to use another method for enrollment
certificate-less enrollment and the Registrar has to support this without certificates and the Registrar has to support this method
method also. It is possible that the Pledge will not enroll, but also. It is possible that the Pledge will not enroll, but instead
instead only a network join operation will occur, such as described only a network join operation will occur, such as described in
in [I-D.ietf-6tisch-minimal-security]. How the Pledge discovers this [I-D.ietf-6tisch-minimal-security]. How the Pledge discovers this
method and details of the enrollment method are out of scope of this method and details of the enrollment method are out of scope of this
document. document.
When the Pledge is known by MASA to support PKIX format certificates, When the Pledge is known by MASA to support PKIX format certificates,
the "pinned-domain-cert" field present in a voucher typically pins a the "pinned-domain-cert" field present in a voucher typically pins a
domain certificate. That can be either the End-Entity certificate of domain certificate. That can be either the End-Entity certificate of
the Registrar, or the certificate of a domain CA of the Registrar's the Registrar, or the certificate of a domain CA of the Registrar's
domain as specified in Section 7.2. However, if the Pledge is known domain as specified in Section 7.2. However, if the Pledge is known
to also support RPK pinning and the MASA intends to pin the to also support RPK pinning and the MASA intends to pin the
Registrar's identity (not a CA), then MASA SHOULD pin the RPK (RPK3 Registrar's identity (not a CA), then MASA SHOULD pin the RPK (RPK3
in Figure 2) of the Registrar instead of the Registrar's End-Entity in Figure 2) of the Registrar instead of the Registrar's End-Entity
certificate to save space in the voucher. certificate to save space in the voucher.
.---------------. .------------.
| domain CA (1) | | pub-CA (1) |
'---------------' '------------'
| |
v v
.---------------. .------------.
| Sub-CA (2) | | sub-CA (2) |
'---------------' '------------'
| |
v v
.-----------------. .--------------.
| Registrar(3) | | Registrar(3) |
| [RPK3] | | RPK3 |
'-----------------' '--------------'
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.
skipping to change at page 27, line 9 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
[I-D.ietf-anima-bootstrapping-keyinfra]. The Registrar provides its [RFC8995]. The Registrar provides its public key in a
public key in a TLSServerCertificate, and the Pledge uses that to TLSServerCertificate, and the Pledge uses that to validate that
validate that integrity of the (D)TLS connection, but it does not integrity of the (D)TLS connection, but it does not validate the
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
send a Certificate or a Raw Public key: this is determined by the send a Certificate or a Raw Public key: this is determined by the
pledge including the server_certificate_type of RawPublicKey. This pledge including the server_certificate_type of RawPublicKey. This
is shown in section 5 of [RFC7250]. is shown in section 5 of [RFC7250].
skipping to change at page 27, line 45 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 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.6.2). state (see [RFC8995] 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,
the CMS structure has a place for such certificates. In the COSE- the CMS structure has a place for such certificates. In the COSE-
signed Constrained Vouchers described in this document, the x5bag signed Constrained Vouchers described in this document, the x5bag
attribute from [I-D.ietf-cose-x509] is to be used for this. attribute from [I-D.ietf-cose-x509] is to be used for this.
11. Security Considerations 11. Security Considerations
11.1. Clock Sensitivity 11.1. Clock Sensitivity
skipping to change at page 32, line 5 skipping to change at page 32, line 5
<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.
Raza, "EST over secure CoAP (EST-coaps)", Work in Raza, "EST over secure CoAP (EST-coaps)", Work in
Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
January 2020, <https://www.ietf.org/archive/id/draft-ietf- January 2020, <https://www.ietf.org/archive/id/draft-ietf-
ace-coap-est-18.txt>. ace-coap-est-18.txt>.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M.
H., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
draft-ietf-anima-bootstrapping-keyinfra-45, 11 November
2020, <https://www.ietf.org/archive/id/draft-ietf-anima-
bootstrapping-keyinfra-45.txt>.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item Veillette, M., Pelov, A., Petrov, I., and C. Bormann,
iDentifier (YANG SID)", Work in Progress, Internet-Draft, "YANG Schema Item iDentifier (YANG SID)", Work in
draft-ietf-core-sid-15, 17 January 2021, Progress, Internet-Draft, draft-ietf-core-sid-16, 24 June
<https://www.ietf.org/archive/id/draft-ietf-core-sid- 2021, <https://www.ietf.org/archive/id/draft-ietf-core-
15.txt>. sid-16.txt>.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of Veillette, M., Petrov, I., Pelov, A., and C. Bormann,
Data Modeled with YANG", Work in Progress, Internet-Draft, "CBOR Encoding of Data Modeled with YANG", Work in
draft-ietf-core-yang-cbor-15, 25 January 2021, Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 24
<https://www.ietf.org/archive/id/draft-ietf-core-yang- June 2021, <https://www.ietf.org/archive/id/draft-ietf-
cbor-15.txt>. core-yang-cbor-16.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-struct-15.txt>. rfc8152bis-struct-15.txt>.
[I-D.ietf-cose-x509] [I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
skipping to change at page 34, line 9 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 37, line 35 skipping to change at page 37, line 35
Code = 0x02 (0.02 is POST) Code = 0x02 (0.02 is POST)
Options Options
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0xb (option nr = 11) Option Delta = 0xb (option nr = 11)
Option Length = 0x1 Option Length = 0x1
Option Value = "b" Option Value = "b"
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0x0 (option nr = 11) Option Delta = 0x0 (option nr = 11)
Option Length = 0x2 Option Length = 0x2
Option Value = "es" Option Value = "es"
Option (Content-Format)
Option Delta = 0x1 (option nr = 12)
Option Length = 0x1
Option Value = 60 (application/cbor)
Payload Marker = 0xFF Payload Marker = 0xFF
Payload = <binary CBOR enrollstatus document> Payload = <binary CBOR enrollstatus document>
The Uri-Host and Uri-Port Options are omitted because they coincide The Uri-Host and Uri-Port Options are omitted because they coincide
with the transport protocol destination address and port with the transport protocol destination address and port
respectively. respectively. TBD - Show the binary CBOR payload of this example.
A 2.04 Changed response will then be: A 2.04 Changed response from the Registrar will then be:
2.04 Changed 2.04 Changed
With CoAP fields: With CoAP fields:
Ver=1 Ver=1
T=2 (ACK) T=2 (ACK)
Code = 0x44 (2.04 Changed) Code = 0x44 (2.04 Changed)
TBD - remove this payload or modify example to be the request payload
of the POST. // The binary payload is:
A46776657273696F6E6131665374617475730166526561736F6E7822
496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E
The binary payload disassembles to the above CBOR diagnostic code.
B.2. voucher_status B.2. voucher_status
A coaps voucher_status message can be: A coaps voucher_status message can be:
POST coaps://[2001:db8::2:1]:61616/b/vs POST coaps://[2001:db8::2:1]:61616/b/vs
Content-Format: 60 (application/cbor)
Payload =
a46776657273696f6e0166737461747573f466726561736f6e7828496e66
6f726d61746976652068756d616e2d7265616461626c65206572726f7220
6d6573736167656e726561736f6e2d636f6e74657874a100764164646974
696f6e616c20696e666f726d6174696f6e
<CODE ENDS>
A 2.04 Changed response will then be: The request payload above is binary CBOR but represented here in
hexadecimal for readability. Below is the equivalent CBOR diagnostic
format.
TBD modify this example to let Pledge POST status to Registrar - {"version": 1, "status": false,
direction change. Change 2.05 to 2.04. "reason": "Informative human-readable error message",
"reason-context": { 0: "Additional information" } }
2.05 Content (Content-Format: application/cbor) <CODE ENDS>
Payload =
a46776657273696f6e6131665374617475730166526561736f6e7822496e666f7
26d61746976652068756d616e207265616461626c65206d6573736167656e7265
61736f6e2d636f6e74657874764164646974696f6e616c20696e666f726d61746
96f6e<CODE ENDS>
The payload above is represented in hexadecimal. A 2.04 Changed response without payload will then be sent by the
Registrar back to the Pledge.
{"version": "1", "Status": 1, 2.04 Changed
"Reason": "Informative human readable message",
"reason-context": "Additional information"}
<CODE ENDS>
Appendix C. COSE examples Appendix C. COSE examples
These examples are generated on a pie 4 and a PC running BASH. Keys These examples are generated on a Pi 4 and a PC running BASH. Keys
and Certificates have been generated with openssl with the following and Certificates have been generated with openssl with the following
shell script: shell script:
#!/bin/bash #!/bin/bash
#try-cert.sh #try-cert.sh
export dir=./brski/intermediate export dir=./brski/intermediate
export cadir=./brski export cadir=./brski
export cnfdir=./conf export cnfdir=./conf
export format=pem export format=pem
export default_crl_days=30 export default_crl_days=30
skipping to change at page 54, line 43 skipping to change at page 54, line 43
{2451: {2451:
{2: "2020-12-23T15:03:12Z", {2: "2020-12-23T15:03:12Z",
4: "2020-12-23T15:23:12Z", 4: "2020-12-23T15:23:12Z",
1: 0, 1: 0,
7: h'6508E06B2959D5089D7A3169EA889A49', 7: h'6508E06B2959D5089D7A3169EA889A49',
11: "pledge.1.2.3.4", 11: "pledge.1.2.3.4",
8: h'regis-cert-hex', 8: h'regis-cert-hex',
3: false}} 3: false}}
<CODE ENDS> <CODE ENDS>
Authors' Addresses Contributors
Russ Housley
Email: housley@vigilsec.com
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: consultancy@vanderstok.org
Panos Kampanakis Panos Kampanakis
Cisco Systems Cisco Systems
Email: pkampana@cisco.com Email: pkampana@cisco.com
 End of changes. 56 change blocks. 
149 lines changed or deleted 142 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/