< draft-ietf-anima-constrained-voucher-09.txt   draft-ietf-anima-constrained-voucher-10.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: May 6, 2021 vanderstok consultancy Expires: August 24, 2021 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
November 02, 2020 E. Dijk
IoTconsultancy.nl
February 20, 2021
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-09 draft-ietf-anima-constrained-voucher-10
Abstract Abstract
This document defines a strategy to securely assign a pledge to an This document defines a protocol to securely assign a Pledge to an
owner, using an artifact signed, directly or indirectly, by the owner and to enroll it into the owner's network. The protocol uses
pledge's manufacturer. This artifact is known as a "voucher". an artifact that is signed by the Pledge's manufacturer. This
artifact is known as a "voucher".
This document builds upon the work in [RFC8366], encoding the This document builds upon the work in [RFC8366] and [BRSKI], but
resulting artifact in CBOR. Use with two signature technologies are defines an encoding of the voucher in CBOR rather than JSON, and
described. enables the Pledge to perform its transactions using CoAP rather than
HTTPS.
Additionally, this document explains how constrained vouchers may be The use of Raw Public Keys instead of X.509 certificates for security
transported as an extension to the [I-D.ietf-ace-coap-est] protocol. operations is also explained.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 6, 2021. This Internet-Draft will expire on August 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 6
6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 7
6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7 6.1. Discovery, URIs and Content Formats . . . . . . . . . . . 7
6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7 6.2. Discovery, URIs and Content Formats . . . . . . . . . . . 7
6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 8 6.3. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 9 6.4. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 8
6.1.4. Example voucher request artifact . . . . . . . . . . 13 6.4.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 8
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 13 6.4.2. Registrar Extensions . . . . . . . . . . . . . . . . 10
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 14 7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14 8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 15 8.1. Registrar Identity Selection and Encoding . . . . . . . . 11
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 17 8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 12
6.3. Signing voucher and voucher-request artifacts . . . . . . 18 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 13
6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 18 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 19 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 20 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 16
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 20 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 17
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 20 9.1.4. Example voucher request artifact . . . . . . . . . . 21
8.3. Test Domain Certificate Validity when Signing . . . . . . 20 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 21
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 20 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 22
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 22
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 21 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 25
9.4. The RFC SID range assignment sub-registry . . . . . . . . 21 9.3. Signing voucher and voucher-request artifacts with COSE . 26
9.5. The SMI Security for S/MIME CMS Content Type Registry . . 22 10. Design Considerations . . . . . . . . . . . . . . . . . . . . 26
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 22 11.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 27
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 22 11.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 27
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 23 11.3. Test Domain Certificate Validity when Signing . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Resource Type Registry . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.3. The YANG Module Names Registry . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.4. The RFC SID range assignment sub-registry . . . . . . . 28
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 26 12.5. Media-Type Registry . . . . . . . . . . . . . . . . . . 28
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 26 12.5.1. application/voucher-cose+cbor . . . . . . . . . . . 28
A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 28 12.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 29
Appendix B. CMS signed messages . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
B.1. signed requestvoucher . . . . . . . . . . . . . . . . . . 28 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.2. requestauditing . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.3. CMS signed voucher-request example . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 30
Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 34 15.2. Informative References . . . . . . . . . . . . . . . . . 32
C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 38 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 33
C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 38 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 33
C.1.2. Registrar private key . . . . . . . . . . . . . . . . 38 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 34
C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 39 Appendix B. COSE examples . . . . . . . . . . . . . . . . . . . 35
C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 39 B.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 38
C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 39 B.1.1. Pledge private key . . . . . . . . . . . . . . . . . 38
C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 41 B.1.2. Registrar private key . . . . . . . . . . . . . . . . 39
C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 43 B.1.3. MASA private key . . . . . . . . . . . . . . . . . . 39
C.3. COSE signed voucher request from pledge to Registrar . . 45 B.2. Pledge, Registrar and MASA certificates . . . . . . . . . 40
C.4. COSE signed voucher request from Registrar to MASA . . . 47 B.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 40
C.5. COSE signed voucher from MASA to Pledge via Registrar . . 49 B.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 B.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 43
B.3. COSE signed voucher request from Pledge to Registrar . . 45
B.4. COSE signed voucher request from Registrar to MASA . . . 47
B.5. COSE signed voucher from MASA to Pledge via Registrar . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
Enrollment of new nodes into constrained networks with constrained Secure enrollment of new nodes into constrained networks with
nodes present unique challenges. constrained nodes presents unique challenges. There are network
bandwidth and code size issues to contend with. A solution for
There are bandwidth and code space issues to contend. A solution autonomous enrollment such as [I-D.ietf-anima-bootstrapping-keyinfra]
such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in may be too large in terms of code size or bandwidth required.
terms of code space or bandwidth required.
This document defines a constrained version of [RFC8366]. Rather
than serializing the YANG definition in JSON, it is serialized into
CBOR ([RFC7049]).
This document follows a similar, but not identical structure as Therefore, this document defines a constrained version of the voucher
[RFC8366] and supplements the brski part to [I-D.ietf-ace-coap-est]. artifact [RFC8366], along with a constrained version of BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] that makes use of the
constrained CoAP-based version of EST, EST-coaps
[I-D.ietf-ace-coap-est] rather than EST over HTTPS [RFC7030].
There are three constrained situations described in this document: 1. While the [RFC8366] voucher is by default serialized to JSON with a
CMS signed CBOR encoded vouchers transported using CoAP, protected by signature in CMS, this document defines a new voucher serialization
DTLS (coaps). 2. COSE signed CBOR encoded vouchers transported using to CBOR ([RFC7049]) with a signature in COSE
CoAP, protected by EDHOC or DTLS. 3. COSE signed CBOR encoded [I-D.ietf-cose-rfc8152bis-struct]. This COSE-signed CBOR-encoded
vouchers, integrated into the key exchange as described by voucher can be transported using secured CoAP or HTTP. The CoAP
[I-D.selander-ace-ake-authz] connection (between Pledge and Registrar) is to be protected by
either OSCORE+EDHOC, or DTLS (CoAPS). The HTTP connection (between
Registrar and MASA) is to be protected using TLS (HTTPS).
Additional sections have been added concerning: This document has a similar structure to [RFC8366] but adds sections
concerning:
1. Addition of voucher-request specification as defined in 1. Voucher-request artifact specification based on Section 3 of
[I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-bootstrapping-keyinfra],
2. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests 2. Voucher(-request) transport over CoAP based on Section 3 of
over CoAP. [I-D.ietf-anima-bootstrapping-keyinfra] and on
[I-D.ietf-ace-coap-est].
The CBOR definitions for this constrained voucher format are defined The CBOR definitions for the constrained voucher format are defined
using the mechanism describe 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 an 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 should be considered
normative rather than the output of the pyang tool. normative rather than the output of the pyang tool.
Two methods of signing the resulting CBOR object are described in There is additional work when the voucher is integrated into the key-
this document: exchange, described in [I-D.selander-ace-ake-authz]. This work is
not in scope for this document.
1. One is CMS [RFC5652].
2. The other is COSE_Sign1 [RFC8152] objects.
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, imprint, domain, 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, Trust of First Use (TOFU), and Voucher. Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and
Voucher.
The following terms from [I-D.ietf-anima-bootstrapping-keyinfra] are
used identically as in that document: Domain CA, enrollment, IDevID,
Join Proxy, LDevID, 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. Survey of Voucher Types 4. Survey of Voucher Types
[RFC8366] provides for vouchers that assert proximity, that [RFC8366] provides for vouchers that assert proximity, that
authenticate the registrar and that include different amounts of authenticate the Registrar and that can offer varying levels of anti-
anti-replay protection. replay protection.
This document does not make any extensions to the types of vouchers. This document does not make any extensions to the semantic meanings
of vouchers, only the encoding has been changed to optimize for
constrained devices and networks.
Time based vouchers are included 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 is very unlikely. Most users of these constrained vouchers their use is very unlikely. Most Pledges using these constrained
will be online and will use live nonces to provide anti-replay vouchers will be online during enrollment and will use live nonces to
protection. provide anti-replay protection.
[RFC8366] defined only the voucher artifact, and not the Voucher [RFC8366] defined only the voucher artifact, and not the Voucher
Request artifact, which was defined in Request artifact, which was defined in
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra]. This document defines both
a constrained voucher and a constrained voucher-request. They are
This document defines both a constrained voucher and a constrained presented in the order "voucher-request", followed by a "voucher"
voucher-request. They are presented in the order "voucher-request", response as this is the order that they occur in the protocol.
followed by a "voucher" response as this is the time order that they
occur.
This document defines both CMS-signed voucher requests and responses, The constrained voucher request MUST be signed by the Pledge. It can
and COSE signed voucher requests and responses. The use of CMS sign using its IDevID X.509 certificate, or if an IDevID is not
signatures implies the use of PKIX format certificates. The pinned- available its manufacturer-installed raw public key (RPK). The
domain-cert present in a voucher, is the certificate of the constrained voucher MUST be signed by the MASA.
Registrar.
The constrained voucher and constrained voucher request MUST be For the constrained voucher request this document defines two
signed. distinct methods for the Pledge to identify the Registrar: using
either the Registrar's X.509 certificate, or using a raw public key
(RPK) of the Registrar. For the constrained voucher also these two
methods are supported to indicate (pin) a trusted domain identity:
using either a pinned domain X.509 certificate, or a pinned raw
public key (RPK).
The use of the two signing formats permit the use of both PKIX format When the Pledge is known by MASA to support RPK but not X.509
certificates, and raw public keys (RPK). certificates, the voucher produced by the MASA pins the raw public
key of the Registrar in the "pinned-domain-subject-public-key-info"
field of a voucher. This is described in more detail in the YANG
definition for the constrained voucher and in section Section 8.
When RPKs are used, the voucher produced by the MASA pins the raw When the Pledge is known by MASA to support PKIX format certificates,
public key of the Registrar: the pinned-domain-subject-public-key- the "pinned-domain-cert" field present in a voucher typically pins a
info in a voucher, is the raw public key of the Registrar. This is domain certificate. That can be either the End-Entity certificate of
described in the YANG definition for the constrained voucher. the Registrar, or the certificate of a domain CA of the Registrar's
domain. However, if the Pledge is known to also support RPK pinning
and the MASA intends to pin the Registrar's identity (not a CA), then
MASA MAY pin the RPK of the Registrar instead of the Registrar's End-
Entity certificate in order to save space in the voucher.
5. Discovery and URI 5. Discovery and URI
This section describes the BRSKI extensions to EST-coaps This section describes the 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,
proxy and pledge over CoAP. The extensions are targeted to low- join proxy and Pledge over CoAP. The extensions are targeted to low-
resource networks with small packets. Saving header space is resource networks with small packets. Saving header space is
important and the EST-coaps URI is shorter than the EST URI. important and the EST-coaps URI is shorter than the EST URI.
The presence and location of (path to) the management data are The presence and location of (path to) the management data are
discovered by sending a GET request to "/.well-known/core" including discovered by sending a GET request to "/.well-known/core" including
a resource type (RT) parameter with the value "ace.est" [RFC6690]. a resource type (RT) parameter with the value "ace.est" [RFC6690].
Upon success, the return payload will contain the root resource of Upon success, the return payload will contain the root resource of
the EST resources. It is up to the implementation to choose its root the EST resources. It is up to the implementation to choose its root
resource; throughout this document the example root resource /est is resource; throughout this document the example root resource /est is
used. used.
The EST-coaps server URIs differ from the EST URI by replacing the The EST-coaps server URIs differ from the EST URI 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:
coaps://www.example.com/est/short-name coaps://www.example.com/est/short-name
Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and
corresponding paths which are supported by EST. Table 1 provides the corresponding paths which are supported by EST. Table 1 provides the
mapping from the BRSKI extension URI path to the EST-coaps URI path. mapping from the BRSKI extension URI path to the EST-coaps URI path.
+------------------+-----------+ +-----------------+-----------+
| BRSKI | EST-coaps | | BRSKI | EST-coaps |
+------------------+-----------+ +-----------------+-----------+
| /requestvoucher | /rv | | /requestvoucher | /rv |
| | | | | |
| /voucher_status | /vs | | /voucher_status | /vs |
| | | | | |
| /enrollstatus | /es | | /enrollstatus | /es |
| | | +-----------------+-----------+
| /requestauditlog | /ra |
+------------------+-----------+
Table 1: BRSKI path to EST-coaps path Table 1: BRSKI path to EST-coaps path
/requestvoucher, /voucher_status and /enrollstatus are needed between /requestvoucher, /voucher_status and /enrollstatus occur between the
pledge and Registrar. Pledge and Registrar (the BRSKI-EST protocol) and also between
Registrar and MASA, but, as described in Section 7, this document
addresses only the BRSKI-EST portion of the protocol.
When discovering the root path for the EST resources, the server MAY When discovering the root path for the EST resources, the server MAY
return the full resource paths and the used content types. This is return the full resource paths and the used content types. This is
useful when multiple content types are specified for EST-coaps useful when multiple content types are specified for EST-coaps
server. For example, the following more complete response is server. For example, the following more complete response is
possible. possible.
[ EDNOTE: spell out where voucher artifacts are used in BRSKI flows 6. BRSKI-EST Protocol
since the APIs ]
[ EDNOTE: The /requestauditlog and /voucher-status are exchanged by The constrained BRSKI-EST protocol described in this section is
the Registrar and MASA. The JRC will likely talk to MASA over a between the Pledge and the Registrar only. (probably via a join
normal (not constrained) medium. Do we need /ra and /vs? Do we need proxy, such as described in [I-D.ietf-anima-constrained-join-proxy])
to remove them from the example too? Also what happens to the It extends both the BRSKI and EST-coaps protocols.
voucher-request and response in this case? Is MASA supposed to
support contrained vouchers? ] 6.1. Discovery, URIs and Content Formats
The constrained BRSKI-EST protocol described in this section is
between the Pledge and the Registrar only. (probably via a join
proxy, such as described in [I-D.ietf-anima-constrained-join-proxy])
It extends both the BRSKI and EST-coaps protocols.
6.2. Discovery, URIs and Content Formats
TBD: content overlaps with Section 5, to be fixed - issue #79
The Pledge MAY perform a discovery operation on the "/.well-known/
core?rt=brski*" resource of the Registrar if it wishes to discover
possibly shorter URLs for the functions, or if it has the possibility
to use a variety of onboarding protocols or certificate enrollment
protocols and it wants to discover which of these protocols are
available.
For example, if the Registrar supports a short BRSKI URL (/b) and
supports the voucher format "application/voucher-cose+cbor" (TBD3),
and status reporting in both CBOR and JSON formats:
REQ: GET /.well-known/core?rt=brski* REQ: GET /.well-known/core?rt=brski*
RES: 2.05 Content RES: 2.05 Content
</b>; rt="brski" Content-Format: 40
</b/rv>; rt="brski.rv";ct=TBD2 TBD3 Payload:
</b/vs>; rt="brski.vs";ct=50 60 </b>;rt=brski,
</b/es>; rt="brski.es";ct=50 60 </b/rv>;rt=brski.rv;ct=TBD3,
</b/vs>;rt=brski.vs;ct="50 60",
</b/es>;rt=brski.es;ct="50 60"
The return of the content-types allows the client to choose the most The Registrar is under no obligation to provide shorter URLs, and MAY
appropriate one from multiple content types. respond to this query with only the "/.well-known/brski" end points
defined in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.
ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and Registrars that have implemented shorter URLs MUST also respond in
ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". equivalent ways to the "/.well-known/brski" URLs, and MUST NOT
distinguish between them. In particular, a Pledge MAY use the longer
and shorter URLs in combination.
Content-Formats TBD2 and TBD3 are defined in this document. The return of multiple content-types in the "ct" attribute allows the
Pledge to choose the most appropriate one. Note that Content-Format
TBD3 is defined in this document.
The Content-Format ("application/json") 50 MAY be supported. The Content-Format ("application/json") 50 MAY be supported and 60
Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be MUST be supported by the Registrar for the /vs and /es resources.
supported by the Registrar. Content-Format TBD3 MUST be supported by the Registrar for the /rv
resource. If the "ct" attribute is not indicated for this resource,
this implies that at least TBD3 is supported.
The Pledge and MASA need to support one or more formats for the The Pledge and MASA need to support one or more formats (at least
voucher. The MASA needds to support whatever formats that the TBD3) for the voucher and for the voucher request. The MASA needs to
pledge's produced by that manufacturer supports. support all formats that the Pledge, produced by that manufacturer,
supports.
6. Artifacts 6.3. Extensions to BRSKI
A Pledge that only supports the EST-coaps enrollment method SHOULD
NOT use discovery for BRSKI resources, since it is more efficient to
just try the supported enrollment method via the well-known BRSKI/
EST-coaps resources, and it avoids the Pledge having to do complex
CoRE Link Format parsing. A Registrar SHOULD host any discoverable
BRSKI resources on the same (UDP) server port that the Pledge's DTLS
connection is using. This avoids the Pledge having to reconnect
using DTLS, in order to access these resources.
6.4. Extensions to EST-coaps
A Pledge that only supports the EST-coaps enrollment method SHOULD
NOT use discovery for EST-coaps resources, for similar reasons as
stated in the previous section. A Registrar SHOULD host any
discoverable EST-coaps resources on the same (UDP) server port that
the Pledge's DTLS connection is using. This avoids the Pledge having
to reconnect using DTLS, in order to access these resources.
6.4.1. Pledge Extensions
A constrained Pledge SHOULD NOT perform the optional "CSR attributes
request" (/att) to minimize network traffic and reduce code size
(i.e. by not implementing the complex CSR attributes parsing code).
When creating the CSR, the Pledge selects itself which attributes to
include. One or more Subject Distinguished Name fields MUST be
included. If the Pledge has no specific information on what
attributes/fields are desired in the CSR, it MUST use the Subject
Distinguished Name fields from its IDevID unmodified. The Pledge may
receive such information via the voucher (encoded in a vendor-
specific way) or some other, out-of-band means.
A constrained Pledge MAY use the following optimized EST-coaps
procedure to minimize both network traffic and code size:
1. if the BRSKI-received voucher, validating the current EST server,
contains a pinned domain CA certificate, the Pledge provisionally
considers this single certificate as the sole EST trust anchor,
in other words, the single result of "CA certificates request"
(/crts) to the EST server.
2. Using this trust anchor it proceeds with EST simple enrollment
(/sen) to obtain its provisionally trusted LDevID.
3. Then, the Pledge attempts to validate that the trust anchor CA is
the signer of the LDevID. If this is the case, the Pledge
finally accepts the pinned domain CA certificate as the
legitimate trust anchor CA for its domain and it also accepts its
LDevID.
4. If this is not the case, the Pledge MUST perform an actual "CA
certificates request" (/crts) to the EST server to obtain the EST
CA trust anchors since these obviously differ from the
(temporary) pinned domain CA.
5. When doing this request, the Pledge MAY use a CoAP Accept Option
with value TBD287 ("application/pkix-cert") to limit the number
of returned EST CA trust anchors to only one. Such limiting to
only one has the advantages that storage requirements for CA
certificates are reduced, network traffic can be reduced, and
code size can be reduced (by not having to parse the alternative
format 281 "application/pkcs7-mime;smime-type=certs-only" and not
having to support CoAP block-wise transfer).
6. If the Pledge cannot obtain the single CA certificate or the
finally validated CA certificate cannot be chained to the LDevID,
then the Pledge MUST abort the enrollment process and report the
error using the enrollment status telemetry (/es).
The Content-Format ("application/json") 50 MAY be supported and 60
MUST be supported by the Registrar for the /vs and /es resources.
Content-Format TBD3 MUST be supported by the Registrar for the /rv
resource. If the "ct" attribute is not indicated for this resource,
this implies that at least TBD3 is supported.
When a Registrar receives a "CA certificates request" (/crts) request
with a CoAP Accept Option with value TBD287 it SHOULD return only the
single CA certificate that is the envisioned or actual authority for
the current, authenticated Pledge making the request. The only
exception case is when the Registrar is configured to not support a
request for a single CA certificate for operational or security
reasons, e.g. because every device enrolled into the domain needs to
use at least multiple CAs. In such exception case the Registrar
returns the CoAP response 4.06 Not Acceptable to indicate that only
the default Content-Format of 281 "application/pkcs7-mime;smime-
type=certs-only" is available.
6.4.2. Registrar Extensions
When a Registrar receives a "CA certificates request" (/crts) request
with a CoAP Accept Option with value TBD287 it SHOULD return only the
single CA certificate that is the envisioned or actual authority for
the current, authenticated Pledge making the request. The only
exception case is when the Registrar is configured to not support a
request for a single CA certificate for operational or security
reasons, e.g. because every device enrolled into the domain needs to
use at least multiple CAs. In such exception case the Registrar
returns the CoAP response 4.06 Not Acceptable to indicate that only
the default Content-Format of 281 "application/pkcs7-mime;smime-
type=certs-only" is available.
7. BRSKI-MASA Protocol
[I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 describes a
connection between the Registrar and the MASA as being a normal TLS
connection using HTTPS. This document does not change that. The use
of CoAP for the BRSKI-MASA connection is NOT supported.
Some consideration was made to specify CoAP support for consistency
but:
o the Registrar is not expected to be so constrained that it cannot
support HTTPS client connections.
o the technology and experience to build Internet-scale HTTPS
responders (which the MASA is) is common, while the experience
doing the same for CoAP is much less common.
o in many Enterprise networks, outgoing UDP connections are often
treated as suspicious, and there seems to be no advantage to using
CoAP in that environment.
o a Registrar is likely to provide onboarding services to both
constrained and non-constrained devices. Such a Registrar would
need to speak HTTPS anyway.
o similarly, a manufacturer is likely to offer both constrained and
non-constrained devices, so there may in practice be no situation
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
third-party service provider, reducing the complexity would also
seem to reduce the cost of that function.
8. Pinning in Voucher Artifacts
The voucher is a statement from the MASA to the Pledge indicating who
the Pledge's owner is. This section deals with the question of how
that owner's identity is determined and how it is encoded within the
voucher.
8.1. Registrar Identity Selection and Encoding
Section 5.5 of [I-D.ietf-anima-bootstrapping-keyinfra] describes
BRSKI policies for selection of the owner identity. It indicates
some of the flexibility that is possible for the Registrar. The
recommendation made there is for the Registrar to include only
certificates in the (CMS) signing structure which participate in the
certificate chain that is to be pinned.
The MASA is expected to evaluate the certificates included by the
Registrar in its voucher request, forming them into a chain with the
Registrar's (signing) identity on one end. Then, it pins a
certificate selected from the chain. For instance, for a domain with
a two-level certification authority, where the voucher-request has
been signed by "Registrar" its signing structure includes two
additional CA certificates:
.-------------.
| priv-CA (1) |
'-------------'
|
v
.------------.
| Int-CA (2) |
'------------'
|
v
.--------------.
| Registrar(3) |
'--------------'
Figure 1: Two Level PKI
When the Registrar is using a COSE-signed constrained format voucher
request towards MASA, instead of a regular CMS-signed voucher
request, the COSE_Sign1 object contains a protected and an
unprotected header, and according to [I-D.ietf-cose-x509], would
carry all the certificates of the chain in an "x5bag" attribute
placed in the unprotected header.
8.2. MASA Pinning Policy
The MASA, having assembled and verified the chain in the signing
structure, will now need to select a certificate to pin in the
voucher in case there are multiple available. (For the case that
only the Registrar's End-Entity certificate is included, only this
certificate can be selected and this section does not apply.) The
BRSKI policy for pinning by the MASA as described in Section 5.5.2 of
[I-D.ietf-anima-bootstrapping-keyinfra] leaves much flexibility to
the manufacturer. The present document adds the following rules to
the MASA pinning policy, in order to reduce on average the duration
of BRSKI/EST on constrained, low-bandwidth networks:
1. for a voucher containing a nonce, it SHOULD select the most
specific (lowest-level) CA certificate in the chain.
2. for a nonceless voucher, it SHOULD select the least-specific
(highest-level) CA certificate in the chain that is allowed under
the MASA's policy for this specific customer (domain).
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
Pledge and Registrar anyway, so it would have no benefit to pin a
higher-level CA. By pinning the most specific CA the constrained
Pledge can validate its DTLS connection using less crypto operations.
The rationale for pinning a CA instead of the Registrar's End-Entity
certificate directly is the following benefit on constrained
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
during the operational phase that follows after EST enrollment, as
explained elsewhere in this document. Doing so avoids an additional
transmission of this trust anchor over the network during the EST
enrollment, saving potentially 100s of bytes and a CoAP transaction.
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
[I-D.ietf-anima-bootstrapping-keyinfra]).
Using the previous example of a domain with a two-level certification
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
only the Registrar's End-Entity certificate pinned would omit the
"priv-CA" and "Sub-CA" certificates from the voucher-request.
In case of a nonceless voucher, the MASA would depending on trust
level pin only "Registrar" certificate (low trust in customer), or
the "Sub-CA" certificate (in case of medium trust, implying that any
Registrar of that sub-domain is acceptable), or even the "priv-CA"
certificate (in case of high trust in the customer, and possibly a
pre-agreed need of the customer to obtain flexible long-lived
vouchers).
8.3. Pinning of Raw Public Keys
Specifically for constrained use cases, the pinning of the raw public
key (RPK) of the Registrar is also supported in the constrained
voucher, instead of an X.509 certificate. If an RPK is pinned it
MUST be the RPK of the Registrar.
.------------.
| pub-CA (1) |
'------------'
|
v
.------------.
| sub-CA (2) |
'------------'
|
v
.--------------.
| Registrar(3) |
| [RPK3] |
'--------------'
Figure 2: Raw Public Key pinning
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
Registrar in the "pinned-domain-subject-public-key-info" field of a
voucher. This is described in more detail in the YANG definition for
the constrained voucher. A Pledge that does not support X.509
certificates cannot use EST to enroll; it has to use another method
for certificate-less enrollment and the Registrar has to support this
method also. It is possible that the Pledge will not enroll, but
instead only a network join operation will occur, such as described
in [I-D.ietf-6tisch-minimal-security]. How the Pledge discovers this
method and details of the enrollment method are out of scope of this
document.
When the Pledge is known by MASA to support PKIX format certificates,
the "pinned-domain-cert" field present in a voucher typically pins a
domain certificate. That can be either the End-Entity certificate of
the Registrar, or the certificate of a domain CA of the Registrar's
domain. However, if the Pledge is known 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 in figure Figure 2) of the Registrar
instead of the Registrar's End-Entity certificate in order to save
space in the voucher.
To Be Completed further (TBD): Note, the above paragraphs are
duplicated from the section Section 4 so we may have to resolve this
duplication.
9. Artifacts
This section describes the abstract (tree) definition as explained in This section describes the abstract (tree) definition as explained in
[I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high-
level view of the contents of each artifact. level 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], with an allocation that was
made via the http://comi.space service. made via the http://comi.space service.
6.1. Voucher Request artifact 9.1. Voucher Request artifact
6.1.1. Tree Diagram 9.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 proximity-registrar-subject-public- [RFC8366], with the addition of proximity-registrar-subject-public-
key-info, proximity-registrar-cert, and prior-signed-voucher-request. key-info, proximity-registrar-cert, and prior-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-subject-public-key-info replaces the MASA. proximity-registrar-subject-public-key-info replaces
proximity-registrar-cert for the extremely constrained cases. proximity-registrar-cert for the extremely constrained cases.
module: ietf-constrained-voucher-request module: ietf-constrained-voucher-request
skipping to change at page 8, line 36 skipping to change at page 16, line 36
| yang:date-and-time | yang:date-and-time
+-- proximity-registrar-subject-public-key-info? +-- proximity-registrar-subject-public-key-info?
| binary | binary
+-- proximity-registrar-sha256-of-subject-public-key-info? +-- proximity-registrar-sha256-of-subject-public-key-info?
| binary | binary
+-- proximity-registrar-cert? +-- proximity-registrar-cert?
| binary | binary
+-- prior-signed-voucher-request? +-- prior-signed-voucher-request?
binary binary
6.1.2. SID values 9.1.2. SID values
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
2501 data /ietf-constrained-voucher-request:voucher 2501 data /ietf-constrained-voucher-request:voucher
2502 data .../assertion 2502 data .../assertion
2503 data .../created-on 2503 data .../created-on
2504 data .../domain-cert-revocation-checks 2504 data .../domain-cert-revocation-checks
2505 data .../expires-on 2505 data .../expires-on
2506 data .../idevid-issuer 2506 data .../idevid-issuer
2507 data .../last-renewal-date 2507 data .../last-renewal-date
2508 data /ietf-constrained-voucher-request:voucher/nonce 2508 data /ietf-constrained-voucher-request:voucher/nonce
2509 data .../pinned-domain-cert 2509 data .../pinned-domain-cert
2510 data .../prior-signed-voucher-request 2510 data .../prior-signed-voucher-request
2511 data .../proximity-registrar-cert 2511 data .../proximity-registrar-cert
2512 data mity-registrar-sha256-of-subject-public-key-info 2512 data mity-registrar-sha256-of-subject-public-key-info
2513 data .../proximity-registrar-subject-public-key-info 2513 data .../proximity-registrar-subject-public-key-info
2514 data .../serial-number 2514 data .../serial-number
WARNING, obsolete definitions WARNING, obsolete definitions
6.1.3. YANG Module 9.1.3. YANG Module
In the constrained-voucher-request YANG module, the voucher is In the constrained-voucher-request YANG module, the voucher is
"augmented" within the "used" grouping statement such that one "augmented" within the "used" grouping statement such that one
continuous set of SID values is generated for the constrained- continuous set of SID values is generated for the constrained-
voucher-request module name, all voucher attributes, and the voucher-request module name, all voucher attributes, and the
constrained-voucher-request attribute. Two attributes of the voucher constrained-voucher-request attribute. Two attributes of the voucher
are "refined" to be optional. are "refined" to be optional.
<CODE BEGINS> file "ietf-constrained-voucher-request@2019-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher-request@2019-09-01.yang"
module ietf-constrained-voucher-request { module ietf-constrained-voucher-request {
skipping to change at page 13, line 12 skipping to change at page 21, line 12
signing a voucher for imprinting so as to minimize the signing a voucher for imprinting so as to minimize the
final voucher size."; final voucher size.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.1.4. Example voucher request artifact 9.1.4. Example voucher request artifact
Below is a CBOR serialization of the constrained-voucher-request is Below is a CBOR serialization of an example constrained voucher
shown in diagnostic CBOR notation. The enum value of the assertion request from a Pledge to a Registrar, shown in CBOR diagnostic
field is calculated to be zero by following the algorithm described notation. The enum value of the assertion field is calculated to be
in section 9.6.4.2 of [RFC7950]. 2 by following the algorithm described in section 9.6.4.2 of
[RFC7950]. Four dots ("....") in a CBOR byte string denotes a
sequence of bytes that are not shown for brevity.
{ {
2501: { 2501: {
+2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on / +2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on /
+4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on / +4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on /
+1 : 2, / SID= 2502, assertion / +1 : 2, / SID= 2502, assertion /
/ "proximity" / / "proximity" /
+13: "JADA123456789", / SID= 2514, serial-number / +13: "JADA123456789", / SID= 2514, serial-number /
+5 : h'01020D0F', / SID= 2506, idevid-issuer / +5 : h'01020D0F', / SID= 2506, idevid-issuer /
+10: h'cert.der', / SID=2511, proximity-registrar-cert/ +10: h'cert.der', / SID=2511, proximity-registrar-cert/
+3 : true, / SID= 2504, domain-cert +3 : true, / SID= 2504, domain-cert
-revocation-checks/ -revocation-checks/
+6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date /
+12: h'key_info' / SID= 2513, proximity-registrar +12: h'key_info' / SID= 2513, proximity-registrar
-subject-public-key-info / -subject-public-key-info /
} }
} }
6.2. Voucher artifact <CODE ENDS>
The voucher's primary purpose is to securely assign a pledge to an 9.2. Voucher artifact
owner. The voucher informs the pledge which entity it should
consider to be its owner.
This document defines a voucher that is a CBOR encoded instance of The voucher's primary purpose is to securely assign a Pledge to an
the YANG module defined in Section 5.3 that has been signed with CMS owner. The voucher informs the Pledge which entity it should
or with COSE. consider to be its owner.
6.2.1. Tree Diagram 9.2.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 only the addition of pinned-domain-subject-public- [RFC8366], with only the addition of pinned-domain-subject-public-
key-info. key-info.
module: ietf-constrained-voucher module: ietf-constrained-voucher
grouping voucher-constrained-grouping grouping voucher-constrained-grouping
+-- voucher +-- voucher
+-- created-on? +-- created-on?
skipping to change at page 14, line 29 skipping to change at page 22, line 23
+-- assertion enumeration +-- assertion enumeration
+-- serial-number string +-- serial-number string
+-- idevid-issuer? binary +-- idevid-issuer? binary
+-- pinned-domain-cert? binary +-- pinned-domain-cert? binary
+-- domain-cert-revocation-checks? boolean +-- domain-cert-revocation-checks? boolean
+-- nonce? binary +-- nonce? binary
+-- last-renewal-date? +-- last-renewal-date?
| yang:date-and-time | yang:date-and-time
+-- pinned-domain-subject-public-key-info? binary +-- pinned-domain-subject-public-key-info? binary
+-- pinned-sha256-of-subject-public-key-info? binary +-- pinned-sha256-of-subject-public-key-info? binary
<CODE ENDS>
6.2.2. SID values 9.2.2. SID values
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
2451 data /ietf-constrained-voucher:voucher 2451 data /ietf-constrained-voucher:voucher
2452 data /ietf-constrained-voucher:voucher/assertion 2452 data /ietf-constrained-voucher:voucher/assertion
2453 data /ietf-constrained-voucher:voucher/created-on 2453 data /ietf-constrained-voucher:voucher/created-on
2454 data .../domain-cert-revocation-checks 2454 data .../domain-cert-revocation-checks
2455 data /ietf-constrained-voucher:voucher/expires-on 2455 data /ietf-constrained-voucher:voucher/expires-on
2456 data /ietf-constrained-voucher:voucher/idevid-issuer 2456 data /ietf-constrained-voucher:voucher/idevid-issuer
2457 data .../last-renewal-date 2457 data .../last-renewal-date
2458 data /ietf-constrained-voucher:voucher/nonce 2458 data /ietf-constrained-voucher:voucher/nonce
2459 data .../pinned-domain-cert 2459 data .../pinned-domain-cert
2460 data .../pinned-domain-subject-public-key-info 2460 data .../pinned-domain-subject-public-key-info
2461 data .../pinned-sha256-of-subject-public-key-info 2461 data .../pinned-sha256-of-subject-public-key-info
2462 data /ietf-constrained-voucher:voucher/serial-number 2462 data /ietf-constrained-voucher:voucher/serial-number
WARNING, obsolete definitions WARNING, obsolete definitions
<CODE ENDS>
6.2.3. YANG Module 9.2.3. YANG Module
In the constrained-voucher YANG module, the voucher is "augmented" In the constrained-voucher YANG module, the voucher is "augmented"
within the "used" grouping statement such that one continuous set of within the "used" grouping statement such that one continuous set of
SID values is generated for the constrained-voucher module name, all SID values is generated for the constrained-voucher module name, all
voucher attributes, and the constrained-voucher attribute. Two voucher attributes, and the constrained-voucher attribute. Two
attributes of the voucher are "refined" to be optional. attributes of the voucher are "refined" to be optional.
<CODE BEGINS> file "ietf-constrained-voucher@2019-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher@2019-09-01.yang"
module ietf-constrained-voucher { module ietf-constrained-voucher {
yang-version 1.1; yang-version 1.1;
skipping to change at page 17, line 35 skipping to change at page 25, line 25
a 256-bit ECDSA public-key. a 256-bit ECDSA public-key.
Algorithm agility is provided by extensions to this Algorithm agility is provided by extensions to this
specifications which define new leaf for other hash types"; specifications which define new leaf for other hash types";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.2.4. Example voucher artifacts 9.2.4. Example voucher artifacts
Below a the CBOR serialization of the constrained-voucher is shown in Below the CBOR serialization of an example constrained voucher is
diagnostic CBOR notation. The enum value of the assertion field is shown in CBOR diagnostic notation. The enum value of the assertion
calculated to be zero by following the algorithm described in section field is calculated to be zero by following the algorithm described
9.6.4.2 of [RFC7950]. in section 9.6.4.2 of [RFC7950]. Four dots ("....") in a CBOR byte
string denotes a sequence of bytes that are not shown for brevity.
{ {
2451: { 2451: {
+2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on /
+1 : 0, / SID = 2452, assertion / +1 : 0, / SID = 2452, assertion "verified" /
/ "verified" /
+11: "JADA123456789", / SID = 2462, serial-number / +11: "JADA123456789", / SID = 2462, serial-number /
+5 : h'01020D0F', / SID = 2456, idevid-issuer / +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer /
+8 : h'cert.der', / SID = 2459, pinned-domain-cert/ +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/
+3 : true, / SID = 2454, domain-cert +3 : true, / SID = 2454, domain-cert /
-revocation-checks / / -revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 2457, last-renewal-date / +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date /
+9 : h'key-info' / SID = 2460, pinned-domain
-subject-public-key-info /
} }
} }
The signing of the example is shown in Appendix B.3. <CODE ENDS>
6.3. Signing voucher and voucher-request artifacts
6.3.1. CMS signing
The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed
voucher is much like the equivalent voucher defined in [RFC8366].
A different eContentType of TBD1 is used to indicate that the
contents are in a different format than in [RFC8366]. The id-ct-
animaJSONVoucher allocated by [RFC8366] indicates a voucher and
voucher-request encoded in JSON, and the new value TBD1 indicates
that the voucher and voucher-request are encoded in CBOR.
The ContentInfo structure contains a payload consisting of the CBOR
encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding
creates a canonical ordering for the keys on the wire. This
canonical ordering is not important as there is no expectation that
the content will be reproduced during the validation process.
Normally the recipient is the pledge and the signer is the MASA.
[I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and
unsigned voucher requests from the pledge to the JRC. In this
specification, voucher-request artifact is not signed from the pledge
to the registrar. [EDNOTE: Confirm that voucher requests do not need
to be signed ] From the JRC to the MASA, the voucher-request artifact
MUST be signed by the domain owner key which is requesting ownership.
The considerations of [RFC5652] section 5.1, concerning validating
CMS objects which are really PKCS7 objects (cmsVersion=1) applies.
The CMS structure SHOULD also contain all the certificates leading up
to and including the signer's trust anchor certificate known to the
recipient. The inclusion of the trust anchor is unusual in many
applications, but without it third parties can not accurately audit
the transaction.
The CMS structure MAY also contain revocation objects for any
intermediate certificate authorities (CAs) between the voucher-issuer
and the trust anchor known to the recipient. However, the use of
CRLs and other validity mechanisms is discouraged, as the pledge is
unlikely to be able to perform online checks, and is unlikely to have
a trusted clock source. As described below, the use of short-lived
vouchers and/or pledge provided nonce provides a freshness guarantee.
6.3.2. COSE signing 9.3. Signing voucher and voucher-request artifacts with COSE
The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. The COSE-Sign1 structure is discussed in section 4.2 of
The CBOR object that carries the body, the signature, and the [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the
information about the body and signature is called the COSE_Sign1 body, the signature, and the information about the body and signature
structure. It is used when only one signature is used on the body. is called the COSE_Sign1 structure. It is used when only one
Support for ECDSA with sha256 (secp256k1 and prime256v1 curves) is signature is used on the body. Support for ECDSA with sha256
compulsory. (secp256k1 and prime256v1 curves) is compulsory.
The supported COSE-sign1 object stucture is shown in Figure 1. The supported COSE-sign1 object stucture is shown in Figure 3.
Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference
why. ] why. ]
COSE_Sign1( COSE_Sign1(
[ [
h'A101382E', # { "alg": EC256K1 } h'A101382E', # { "alg": EC256K1 }
{ {
"kid" : h'789' # hash256(public key) "kid" : h'789' # hash256(public key)
}, },
h'123', #voucher-request binary content h'123', #voucher-request binary content
h'456', #voucher-request binary public signature h'456', #voucher-request binary public signature
] ]
) )
Figure 1: cose-sign1 example Figure 3: cose-sign1 example
The [COSE-registry] specifies the integers that replace the strings The [COSE-registry] specifies the integers that replace the strings
and the mnemonics in Figure 1. The value of the "kid" parameter is and the mnemonics in Figure 3. The value of the "kid" parameter is
an example value. Usually a hash of the public key is used to an example value. Usually a hash of the public key is used to
idientify the public key. The public key and its hash are derived idientify the public key. The public key and its hash are derived
from the relevant certificate (Pledge, Registrar or MASA from the relevant certificate (Pledge, Registrar or MASA
certificate). certificate).
In Appendix C a binary cose-sign1 object is shown based on the In Appendix B a binary cose-sign1 object is shown based on the
voucher-request example of Section 6.1.4. voucher-request example of Section 9.1.4.
7. Design Considerations 10. Design Considerations
The design considerations for the CBOR encoding of vouchers is much The design considerations for the CBOR encoding of vouchers is much
the same as for [RFC8366]. the same as for [RFC8366].
One key difference is that the names of the leaves in the YANG does One key difference is that the names of the leaves in the YANG does
not have a material effect on the size of the resulting CBOR, as the not have a material effect on the size of the resulting CBOR, as the
SID translation process assigns integers to the names. SID translation process assigns integers to the names.
8. Security Considerations Any POST request to the Registrar with resource /est/vs or /est/es
returns a 2.05 response with empty payload. The client should be
aware that the server may use a piggybacked CoAP response (ACK, 2.05)
but may also respond with a separate CoAP response, i.e. first an
(ACK, 0.0) that is an acknowledgement of the request reception
followed by a (CON, 2.05) response in a separate CoAP message.
8.1. Clock Sensitivity 11. Security Considerations
11.1. Clock Sensitivity
TBD. TBD.
8.2. Protect Voucher PKI in HSM 11.2. Protect Voucher PKI in HSM
TBD. TBD.
8.3. Test Domain Certificate Validity when Signing 11.3. Test Domain Certificate Validity when Signing
TBD. TBD.
9. IANA Considerations 12. IANA Considerations
9.1. Resource Type Registry 12.1. Resource Type Registry
Additions to the sub-registry "CoAP Resource Type", within the "CoRE Additions to the sub-registry "CoAP Resource Type", within the "CoRE
parameters" registry are specified below. These can be registered parameters" registry are specified below. These can be registered
either in the Expert Review range (0-255) or IETF Review range either in the Expert Review range (0-255) or IETF Review range
(256-9999). (256-9999).
ace.rt.rv needs registration with IANA ace.rt.rv needs registration with IANA
ace.rt.vs needs registration with IANA ace.rt.vs needs registration with IANA
ace.rt.es needs registration with IANA ace.rt.es needs registration with IANA
ace.rt.ra needs registration with IANA ace.rt.ra needs registration with IANA
9.2. The IETF XML Registry 12.2. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in [RFC3688], the following registration is
requested: requested:
URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
9.3. The YANG Module Names Registry 12.3. The YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. Following the format defined in [RFC6020], the registry [RFC6020]. Following the format defined in [RFC6020], the
the following registration is requested: the following registration is requested:
name: ietf-constrained-voucher name: ietf-constrained-voucher
namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
name: ietf-constrained-voucher-request name: ietf-constrained-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-constrained namespace: urn:ietf:params:xml:ns:yang:ietf-constrained
-voucher-request -voucher-request
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
9.4. The RFC SID range assignment sub-registry 12.4. The RFC SID range assignment sub-registry
------------ ------ --------------------------- ------------ ------------ ------ --------------------------- ------------
Entry-point | Size | Module name | RFC Number Entry-point | Size | Module name | RFC Number
------------ ------ --------------------------- ------------ ------------ ------ --------------------------- ------------
2450 50 ietf-constrained-voucher [ThisRFC] 2450 50 ietf-constrained-voucher [ThisRFC]
2500 50 ietf-constrained-voucher [ThisRFC} 2500 50 ietf-constrained-voucher [ThisRFC}
-request -request
----------- ------ --------------------------- ------------ ----------- ------ --------------------------- ------------
Warning: These SID values are defined in [I-D.ietf-core-sid], not as Warning: These SID values are defined in [I-D.ietf-core-sid], not as
an Early Allocation. an Early Allocation.
9.5. The SMI Security for S/MIME CMS Content Type Registry 12.5. Media-Type Registry
This document registers an OID in the "SMI Security for S/MIME CMS
Content Type" registry (1.2.840.113549.1.9.16.1), with the value:
Decimal Description References
------- -------------------------------------- ----------
46 id-ct-animaCBORVoucher [ThisRFC]
9.6. Media-Type Registry
This section registers the 'application/voucher-cms+cbor' media type
and the 'application/voucher-cose+cbor' in the "Media Types"
registry. These media types are used to indicate that the content is
a CBOR voucher either signed with a cms structure or a COSE_Sign1
structure [RFC8152].
9.6.1. application/voucher-cms+cbor
Type name: application This section registers the the 'application/voucher-cose+cbor' in the
Subtype name: voucher-cms+cbor "Media Types" registry. These media types are used to indicate that
Required parameters: none the content is a CBOR voucher either signed with a COSE_Sign1
Optional parameters: none structure [I-D.ietf-cose-rfc8152bis-struct].
Encoding considerations: CMS-signed CBOR vouchers are CBOR
encoded.
Security considerations: See Security Considerations, Section
Interoperability considerations: The format is designed to be
broadly interoperable.
Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch, and other
zero-touch imprinting systems
Additional information:
Magic number(s): None
File extension(s): .vch
Macintosh file type code(s): none
Person & email address to contact for further information: IETF
ANIMA WG
Intended usage: LIMITED
Restrictions on usage: NONE
Author: ANIMA WG
Change controller: IETF
Provisional registration? (standards tree only): NO
9.6.2. 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: cose-type
Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects
signed with one signer. signed with one signer.
Security considerations: See Security Considerations, Section 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.
skipping to change at page 23, line 28 skipping to change at page 29, line 28
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
9.7. 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 mime type Encoding ID References
---------------------------- ----------- --------- ---- ---------- ---------------------------- ----------- --------- ---- ----------
application/voucher-cms+cbor - - CBOR TBD2 [This RFC]
application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC]
10. 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 correctinging earlier version choices. Also thanks to Jim Schaad for correctinging earlier version
of the COSE Sign1 objects. of 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 support
the SID allocation process, and this document was among the first the SID allocation process, and this document was among the first
users. users.
We are grateful for the suggestions done by Esko Dijk. 14. Changelog
11. Changelog -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
skipping to change at page 24, line 32 skipping to change at page 30, line 34
Example of requestvoucher with unsigned appllication/cbor is added Example of requestvoucher with unsigned appllication/cbor is added
attributes of voucher "refined" to optional attributes of voucher "refined" to optional
CBOR serialization of vouchers improved CBOR serialization of vouchers improved
Discovery port numbers are specified Discovery port numbers are specified
-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
12. References 15. References
12.1. Normative References 15.1. Normative References
[I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-
6tisch-minimal-security-15 (work in progress), December
2019.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S.
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- Raza, "EST over secure CoAP (EST-coaps)", draft-ietf-ace-
est-18 (work in progress), January 2020. coap-est-18 (work in progress), January 2020.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M.
and K. Watsen, "Bootstrapping Remote Secure Key H., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-44 (work in progress), September 2020. keyinfra-45 (work in progress), November 2020.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item
iDentifier (YANG SID)", draft-ietf-core-sid-14 (work in iDentifier (YANG SID)", draft-ietf-core-sid-15 (work in
progress), July 2020. progress), January 2021.
[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., and A. Pelov, "CBOR Encoding of
Data Modeled with YANG", draft-ietf-core-yang-cbor-13 Data Modeled with YANG", draft-ietf-core-yang-cbor-15
(work in progress), July 2020. (work in progress), January 2021.
[I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis-
struct-15 (work in progress), February 2021.
[I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509
certificates", draft-ietf-cose-x509-08 (work in progress),
December 2020.
[I-D.selander-ace-ake-authz] [I-D.selander-ace-ake-authz]
Selander, G., Mattsson, J., Vucinic, M., Richardson, M., Selander, G., Mattsson, J. P., Vucinic, M., Richardson,
and A. Schellenbaum, "Lightweight Authorization for M., and A. Schellenbaum, "Lightweight Authorization for
Authenticated Key Exchange.", draft-selander-ace-ake- Authenticated Key Exchange.", draft-selander-ace-ake-
authz-01 (work in progress), March 2020. authz-02 (work in progress), November 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 25, line 42 skipping to change at page 32, line 18
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
12.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-anima-constrained-join-proxy]
Richardson, M., Stok, P. V. D., and P. Kampanakis,
"Constrained Join Proxy for Bootstrapping Protocols",
draft-ietf-anima-constrained-join-proxy-02 (work in
progress), February 2021.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-06 (work in progress), ietf-netmod-yang-tree-diagrams-06 (work in progress),
February 2018. February 2018.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
skipping to change at page 26, line 41 skipping to change at page 33, line 15
Appendix A. EST messages to EST-coaps Appendix A. EST messages to EST-coaps
This section extends the examples from Appendix A of This section extends the examples from Appendix A of
[I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for
the enrollstatus example. the enrollstatus example.
A.1. enrollstatus A.1. enrollstatus
A coaps enrollstatus message can be : A coaps enrollstatus message can be :
GET coaps://[192.0.2.1:8085]/est/es POST coaps://192.0.2.1:8085/est/es
The corresponding coap header fields are shown below. The corresponding coap header fields are shown below.
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.01 is GET) 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 = 0x3 Option Length = 0x3
Option Value = "est" Option Value = "est"
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"
Payload = [Empty] Payload = [Empty]
skipping to change at page 28, line 11 skipping to change at page 34, line 35
496E666F726D61746976652068756D616E207265616461626C65206D 496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874 6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E 764164646974696F6E616C20696E666F726D6174696F6E
The binary payload disassembles to the above CBOR diagnostic code. The binary payload disassembles to the above CBOR diagnostic code.
A.2. voucher_status A.2. voucher_status
A coaps voucher_status message can be: A coaps voucher_status message can be:
GET coaps://[2001:db8::2:1]:61616]/est/vs POST coaps://[2001:db8::2:1]:61616/est/vs
A 2.05 Content response with a non signed CBOR voucher status (ct=60) A 2.05 Content response with a non signed CBOR voucher status (ct=60)
will then be: will then be:
2.05 Content (Content-Format: application/cbor) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
A46776657273696F6E6131665374617475730166526561736F6E7822 a46776657273696f6e6131665374617475730166526561736f6e7822496e666f7
496E666F726D61746976652068756D616E207265616461626C65206D 26d61746976652068756d616e207265616461626c65206d6573736167656e7265
6573736167656e726561736F6E2D636F6E74657874 61736f6e2d636f6e74657874764164646974696f6e616c20696e666f726d61746
764164646974696F6E616C20696E666F726D6174696F6E 96f6e<CODE ENDS>
Appendix B. CMS signed messages
Signed request-voucher-request payloads are sent from pledge to
Registrar, as explained in Section 5.2 of
[I-D.ietf-anima-bootstrapping-keyinfra].
B.1. signed requestvoucher
A CMS signed requestvoucher message from JRC to MASA is shown below.
It would be CoAP POSTED to /est/rv.
POST coaps://[2001:db8::2:1]:61616]/est/rv
(Content-Format: application/voucher-cms+cbor)
The payload would be in binary, but is presented in base64 in this
document.
MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ
KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49
BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh
bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw
Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx
CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV
BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz
NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ
TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl
n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3
rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P
AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7
CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9
ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK
3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD
QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp
b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC
AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ
XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/
n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh
MEgF10vqXv02gL1jLw==
A 2.04 Changed response returning CBOR voucher signed with a cms
structure(ct=TBD2) will then be:
2.04 Changed (Content-Format: application/voucher-cms+cbor)
MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ
KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49
BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh
bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw
Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx
CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV
BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz
NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ
TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl
n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3
rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P
AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7
CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9
ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK
3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD
QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp
b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC
AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he
uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG
kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX
hlG/g+OgTUftYMJ32so=
B.2. requestauditing
A coaps requestauditing message contains the signed CBOR voucher :
POST coaps://[2001:db8::2:1]:61616]/est/ra
(Content-Format: application/voucher-cms+cbor)
Payload =
TO BE FILLED
A 2.05 Content response returning a log of the voucher (ct=60) will
then be:
2.05 Content (Content-Format: application/cbor)
Payload =
{
"version":"1",
"events":[
{
"date":"<date/time of the entry>",
"domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>"
"truncated":"<the number of domainID entries truncated>"
},
{
"date":"<date/time of the entry>",
"domainID":"<anotherDomainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>"
}
],
"truncation": {
"nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": "<total number of entries truncated>",
"arbitrary": "<number of domainID entries removed entirely>"
}
}
[EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary]
B.3. CMS signed voucher-request example
The voucher-request example, visualized in CBOR diagnostic notation
in Section 6.1.4 is shown as a hexadecimal dump of the binary file.
a11909c5a90274323031362d31302d30375431393a33313a34325a0474323031
362d31302d32315431393a33313a34325a01020d6d4a414441313233343536
373839054401020d0f0a4401020d0f03f50674323031372d31302d30375431
393a33313a34325a0c4401020d0f
The voucher-request example has been signed by using the WT1234
certificate and key pair shown in Appendix C of
[I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher-
request leads to a binary signed voucher-request, shown with a
hexadecimal representation shown in the payload of the request part
of Appendix B.1 and Appendix B.2.
The breakdown of the CMS signed binary voucher-request file is
visualized below:
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent: <ABSENT>
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 9112578475118446130
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA
validity:
notBefore: Jan 31 11:29:16 2019 GMT
notAfter: Dec 31 23:59:59 9999 GMT
subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf
000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15
001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df
002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8
0038 - 16 a2 b2 3b 56 38 e5 9f-d9
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Basic Constraints (2.5.29.19)
critical: BOOL ABSENT
value:
0000 - 30
0002 - <SPACES/NULS>
object: X509v3 Subject Key Identifier (2.5.29.14)
critical: BOOL ABSENT
value:
0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0
000d - ac 76 07 77 ad 66 5d 02-a0
object: X509v3 Authority Key Identifier (2.5.29.35)
critical: BOOL ABSENT
value:
0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a
000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60
object: X509v3 Key Usage (2.5.29.15)
critical: TRUE
value:
0000 - 03 02 05 a0
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: BOOL ABSENT
value:
0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08
000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4
001a - 3b 0a 01 04 04 01 02 03-04
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c
000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17
001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c
002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20
003c - f1 50 64 21 18 8a 0a de-6d 34 92 36
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA
serialNumber: 9112578475118446130
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Jul 3 08:53:30 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4) The payload above is represented in hexadecimal.
value.set:
OCTET STRING:
0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d
000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f
001a - 0b 4f 44 9e 25
0020 - <SPACES/NULS>
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64
000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf
001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4
002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af
003c - 2b 59 16 cc 36 63 e7 91-89 39 df df
unsignedAttrs:
<EMPTY>
Appendix C. COSE examples {"version": "1", "Status": 1, "Reason": "Informative human
readable message", "reason-context": "Additional information"}<CODE ENDS>
Appendix B. COSE examples
These examples are generated on a pie 4 and a PC running BASH. Keys These examples are generated on a pie 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
sn=8 sn=8
DevID=pledge.1.2.3.4 DevID=pledge.1.2.3.4
serialNumber="serialNumber=$DevID" serialNumber="serialNumber=$DevID"
export hwType=1.3.6.1.4.1.6715.10.1 export hwType=1.3.6.1.4.1.6715.10.1
export hwSerialNum=01020304 export hwSerialNum=01020304 # Some hex
export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname"
echo $hwType - $hwSerialNum echo $hwType - $hwSerialNum
echo $serialNumber echo $serialNumber
OPENSSL_BIN="openssl"
# remove all files # remove all files
rm -r ./brski/* rm -r ./brski/*
# #
# initialize file structure # initialize file structure
# root level # root level
cd $cadir cd $cadir
mkdir certs crl csr newcerts private mkdir certs crl csr newcerts private
chmod 700 private chmod 700 private
touch index.txt touch index.txt
touch serial touch serial
echo 11223344556600 >serial echo 11223344556600 >serial
echo 1000 > crlnumber echo 1000 > crlnumber
# intermediate level # intermediate level
mkdir intermediate mkdir intermediate
cd intermediate cd intermediate
mkdir certs crl csr newcerts private mkdir certs crl csr newcerts private
chmod 700 private chmod 700 private
touch index.txt touch index.txt
echo 11223344556600 >serial echo 11223344556600 >serial
echo 1000 > crlnumber echo 1000 > crlnumber
cd ../.. cd ../..
# file structure is cleaned start filling # file structure is cleaned start filling
echo "#############################" echo "#############################"
echo "create registrar keys and certificates " echo "create registrar keys and certificates "
echo "#############################" echo "#############################"
echo "create root registrar certificate using ecdsa with sha256" echo "create root registrar certificate using ecdsa with sha 256 key"
openssl ecparam -name prime256v1 -genkey \ $OPENSSL_BIN ecparam -name prime256v1 -genkey \
-noout -out $cadir/private/ca-regis.key -noout -out $cadir/private/ca-regis.key
openssl req -new -x509 \ $OPENSSL_BIN req -new -x509 \
-key $cadir/private/ca-regis.key \ -config $cnfdir/openssl-regis.cnf \
-out $cadir/certs/ca-regis.crt \ -key $cadir/private/ca-regis.key \
-extensions v3_ca\ -out $cadir/certs/ca-regis.crt \
-days 365 \ -extensions v3_ca\
-subj "/C=NL/ST=NB/L=Helmond/O=vanderstok\ -days 365 \
"/OU=consultancy/CN=registrar.stok.nl" -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \
/CN=registrar.stok.nl"
# Combine authority certificate and key # Combine authority certificate and key
echo "Combine authority certificate and key" echo "Combine authority certificate and key"
openssl pkcs12 -passin pass:watnietweet \ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-passout pass:watnietweet \ -inkey $cadir/private/ca-regis.key \
-inkey $cadir/private/ca-regis.key \ -in $cadir/certs/ca-regis.crt -export \
-in $cadir/certs/ca-regis.crt -export \ -out $cadir/certs/ca-regis-comb.pfx
-out $cadir/certs/ca-regis-comb.pfx
# converteer authority pkcs12 file to pem # converteer authority pkcs12 file to pem
echo "converteer authority pkcs12 file to pem" echo "converteer authority pkcs12 file to pem"
openssl pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-in $cadir/certs/ca-regis-comb.pfx \\ -in $cadir/certs/ca-regis-comb.pfx \
-out $cadir/certs/ca-regis-comb.crt -nodes -out $cadir/certs/ca-regis-comb.crt -nodes
#show certificate in registrar combined certificate #show certificate in registrar combined certificate
openssl x509 -in $cadir/certs/ca-regis-comb.crt -text $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text
# #
# Certificate Authority for MASA # Certificate Authority for MASA
# #
echo "#############################" echo "#############################"
echo "create MASA keys and certificates " echo "create MASA keys and certificates "
echo "#############################" echo "#############################"
echo "create root MASA certificate using ecdsa with sha 256 key" echo "create root MASA certificate using ecdsa with sha 256 key"
openssl ecparam -name prime256v1 -genkey -noout \ $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \
-out $cadir/private/ca-masa.key -out $cadir/private/ca-masa.key
openssl req -new -x509 \ $OPENSSL_BIN req -new -x509 \
-days 365 -key $cadir/private/ca-masa.key \ -config $cnfdir/openssl-masa.cnf \
-out $cadir/certs/ca-masa.crt \ -days 1000 -key $cadir/private/ca-masa.key \
-extensions v3_ca\ -out $cadir/certs/ca-masa.crt \
-subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/\ -extensions v3_ca\
OU=manufacturer/CN=masa.stok.nl" -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\
/CN=masa.stok.nl"
# Combine authority certificate and key # Combine authority certificate and key
echo "Combine authority certificate and key for masa" echo "Combine authority certificate and key for masa"
openssl pkcs12 -passin pass:watnietweet \ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-passout pass:watnietweet\ -inkey $cadir/private/ca-masa.key \
-inkey $cadir/private/ca-masa.key \ -in $cadir/certs/ca-masa.crt -export \
-in $cadir/certs/ca-masa.crt -export \ -out $cadir/certs/ca-masa-comb.pfx
-out $cadir/certs/ca-masa-comb.pfx
# converteer authority pkcs12 file to pem for masa # converteer authority pkcs12 file to pem for masa
echo "converteer authority pkcs12 file to pem for masa" echo "converteer authority pkcs12 file to pem for masa"
openssl pkcs12 -passin pass:watnietweet \ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-passout pass:watnietweet\ -in $cadir/certs/ca-masa-comb.pfx \
-in $cadir/certs/ca-masa-comb.pfx \ -out $cadir/certs/ca-masa-comb.crt -nodes
-out $cadir/certs/ca-masa-comb.crt -nodes
#show certificate in pledge combined certificate #show certificate in pledge combined certificate
openssl x509 -in $cadir/certs/ca-masa-comb.crt -text $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text
# #
# Certificate for Pledge derived from MASA certificate # Certificate for Pledge derived from MASA certificate
# #
echo "#############################" echo "#############################"
echo "create pledge keys and certificates " echo "create pledge keys and certificates "
echo "#############################" echo "#############################"
# Pledge derived Certificate # Pledge derived Certificate
echo "create pledge derived certificate using ecdsa with sha256" echo "create pledge derived certificate using ecdsa with sha 256 key"
openssl ecparam -name prime256v1 -genkey \ $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \
-noout -out $dir/private/pledge.key -out $dir/private/pledge.key
echo "create pledge certificate request" echo "create pledge certificate request"
openssl req -nodes -new -sha256 \ $OPENSSL_BIN req -nodes -new -sha256 \
-key $dir/private/pledge.key -out $dir/csr/pledge.csr \ -key $dir/private/pledge.key -out $dir/csr/pledge.csr \
-subj \ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\
"/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ /CN=uuid:$DevID/$serialNumber"
/CN=uuid:$DevID/$serialNumber"
# Sign pledge derived Certificate # Sign pledge derived Certificate
echo "sign pledge derived certificate " echo "sign pledge derived certificate "
openssl ca -config $cnfdir/openssl-pledge.cnf \ $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \
-extensions 8021ar_idevid\ -extensions 8021ar_idevid\
-days 365 -in $dir/csr/pledge.csr -out $dir/certs/pledge.crt -days 365 -in $dir/csr/pledge.csr \
-out $dir/certs/pledge.crt
# Add pledge key and pledge certificate to pkcs12 file # Add pledge key and pledge certificate to pkcs12 file
echo "Add pledge key and pledge certificate to pkcs12 file" echo "Add derived pledge key and derived pledge \
openssl pkcs12 -passin pass:watnietweet\ certificate to pkcs12 file"
-passout pass:watnietweet\ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-inkey $dir/private/pledge.key \ -inkey $dir/private/pledge.key \
-in $dir/certs/pledge.crt -export \ -in $dir/certs/pledge.crt -export \
-out $dir/certs/pledge-comb.pfx -out $dir/certs/pledge-comb.pfx
# converteer pledge pkcs12 file to pem # converteer pledge pkcs12 file to pem
echo "converteer pledge pkcs12 file to pem" echo "converteer pledge pkcs12 file to pem"
openssl pkcs12 -passin pass:watnietweet \ $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\
-passout pass:watnietweet\ -in $dir/certs/pledge-comb.pfx \
-in $dir/certs/pledge-comb.pfx \ -out $dir/certs/pledge-comb.crt -nodes
-out $dir/certs/pledge-comb.crt -nodes
#show certificate in pledge-comb.crt #show certificate in pledge-comb.crt
openssl x509 -in $dir/certs/pledge-comb.crt -text $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text
#show private key in pledge-comb.crt #show private key in pledge-comb.crt
openssl ecparam -name prime256v1 \ $OPENSSL_BIN ecparam -name prime256v1\
-in $dir/certs/pledge-comb.crt -text -in $dir/certs/pledge-comb.crt -text
<CODE ENDS>
The xxxx-comb certificates have been generated as required by libcoap The xxxx-comb certificates have been generated as required by libcoap
for the DTLS connection generation. for the DTLS connection generation.
C.1. Pledge, Registrar and MASA keys B.1. Pledge, Registrar and MASA keys
This first section documents the public and private keys used in the This first section documents the public and private keys used in the
subsequent test vectors below. These keys come from test code and subsequent test vectors below. These keys come from test code and
are not used in any production system, and should only be used only are not used in any production system, and should only be used only
to validate implementations. to validate implementations.
C.1.1. Pledge private key B.1.1. Pledge private key
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgIpP20ud7muTl460b
xFzupPkaMoaCIIIFwSOf0hvhQByhRANCAASKnIauvAtx6ZFWQniQOqvP0Zpdaudy
Ve6Vrc80AjyWRGnN3oyQ0rnr5dXynfG2xq8+cY+uGwTrAJYp9OyoZCAs
-----END PRIVATE KEY-----
Private-Key: (256 bit) Private-Key: (256 bit)
priv: priv:
22:93:f6:d2:e7:7b:9a:e4:e5:e3:ad:1b:c4:5c:ee: 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0:
a4:f9:1a:32:86:82:20:82:05:c1:23:9f:d2:1b:e1: 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2:
40:1c 9c:9a
pub: pub:
04:8a:9c:86:ae:bc:0b:71:e9:91:56:42:78:90:3a: 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02:
ab:cf:d1:9a:5d:6a:e7:72:55:ee:95:ad:cf:34:02: ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c:
3c:96:44:69:cd:de:8c:90:d2:b9:eb:e5:d5:f2:9d: ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04:
f1:b6:c6:af:3e:71:8f:ae:1b:04:eb:00:96:29:f4: 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40:
ec:a8:64:20:2c 60:eb:95:5c:54
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
<CODE ENDS>
C.1.2. Registrar private key B.1.2. Registrar private key
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgHCCOKLhln+l8pLnx
gWtMUm7zRY4ugkznuFimYDKbrNihRANCAARqJKniS+I00XrUfnYMlLXh3E7hFa2J
ESrUpqZLsb9o+Rd9cOkQnLSMmw3H3yZBGZ0MLb/yHtWEA4rIP0eBvhOO
-----END PRIVATE KEY-----
Private-Key: (256 bit) Private-Key: (256 bit)
priv: priv:
1c:20:8e:28:b8:65:9f:e9:7c:a4:b9:f1:81:6b:4c: 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9:
52:6e:f3:45:8e:2e:82:4c:e7:b8:58:a6:60:32:9b: e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb:
ac:d8 21:7e
pub: pub:
04:6a:24:a9:e2:4b:e2:34:d1:7a:d4:7e:76:0c:94: 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed:
b5:e1:dc:4e:e1:15:ad:89:11:2a:d4:a6:a6:4b:b1: 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0:
bf:68:f9:17:7d:70:e9:10:9c:b4:8c:9b:0d:c7:df: 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d:
26:41:19:9d:0c:2d:bf:f2:1e:d5:84:03:8a:c8:3f: a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92:
47:81:be:13:8e 3e:d0:2d:c7:b7
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
<CODE ENDS>
C.1.3. MASA private key B.1.3. MASA private key
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgQODnSgB7xR/aa3Ea
JrPGz9lZhJ1aEc/56OEPiBr86SKhRANCAASB9HLsnEeyjtHrODNBANNi9khQ2gLQ
VrIie8hLgFmVdwfQw1iMPPI8WwCDeVTaDdGwr6HC6M0sO9CGRZ+JcwrL
-----END PRIVATE KEY-----
Private-Key: (256 bit) Private-Key: (256 bit)
priv: priv:
40:e0:e7:4a:00:7b:c5:1f:da:6b:71:1a:26:b3:c6: c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31:
cf:d9:59:84:9d:5a:11:cf:f9:e8:e1:0f:88:1a:fc: 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32:
e9:22 ec:31
pub: pub:
04:81:f4:72:ec:9c:47:b2:8e:d1:eb:38:33:41:00: 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86:
d3:62:f6:48:50:da:02:d0:56:b2:22:7b:c8:4b:80: db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02:
59:95:77:07:d0:c3:58:8c:3c:f2:3c:5b:00:83:79: 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83:
54:da:0d:d1:b0:af:a1:c2:e8:cd:2c:3b:d0:86:45: 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6:
9f:89:73:0a:cb ed:f3:17:5c:f1
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
<CODE ENDS>
C.2. Pledge, Registrar and MASA certificates B.2. Pledge, Registrar and MASA certificates
Below the certificates that accompany the keys. The certificate Below the certificates that accompany the keys. The certificate
description is followed by the hexadecimal DER of the certificate description is followed by the hexadecimal DER of the certificate
C.2.1. Pledge IDevID certificate B.2.1. Pledge IDevID certificate
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4822678189204992 (0x11223344556600)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok,
OU=manufacturer, CN=masa.stok.nl
Validity
Not Before: Sep 9 07:42:03 2020 GMT
Not After : Dec 31 23:59:59 9999 GMT
Subject: C=NL, ST=NB, L=Helmond, O=vanderstok,
OU=manufacturing,
CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:8a:9c:86:ae:bc:0b:71:e9:91:56:42:78:90:3a:
ab:cf:d1:9a:5d:6a:e7:72:55:ee:95:ad:cf:34:02:
3c:96:44:69:cd:de:8c:90:d2:b9:eb:e5:d5:f2:9d:
f1:b6:c6:af:3e:71:8f:ae:1b:04:eb:00:96:29:f4:
ec:a8:64:20:2c
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
59:B1:E1:19:F4:68:53:E9:0E:7C:9F:29:D0:FB:5B:1F:AC:C3:82:49
X509v3 Authority Key Identifier:
keyid:
22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4
X509v3 Key Usage: critical Certificate:
Digital Signature, Key Encipherment Data:
Signature Algorithm: ecdsa-with-SHA256 Version: 3 (0x2)
30:45:02:20:4d:fd:a8:83:78:31:d2:62:a4:e5:48:a2:e0:a7: Serial Number: 4822678189204992 (0x11223344556600)
3b:c5:14:e9:7e:46:13:45:bc:30:fd:1d:e5:d6:63:3e:d8:f4: Signature Algorithm: ecdsa-with-SHA256
02:21:00:a8:e5:1e:c2:79:77:90:fc:40:a8:7a:bf:b1:bd:81: Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer,
8b:ee:d7:56:1a:04:4d:8f:c8:3d:76:5f:4d:6e:36:a2:c2 CN=masa.stok.nl
Validity
Not Before: Dec 9 10:02:36 2020 GMT
Not After : Dec 31 23:59:59 9999 GMT
Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing,
CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02:
ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c:
ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04:
10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40:
60:eb:95:5c:54
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Authority Key Identifier:
keyid:
E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe:
d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17:
bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9:
a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f
<CODE ENDS>
This is the hexadecimal representation in (request-)voucher examples This is the hexadecimal representation in (request-)voucher examples
referred to as pledge-cert-hex. referred to as pledge-cert-hex.
30820254308201faa003020102020711223344556600300a06082a8648ce3d04 30820226308201cba003020102020711223344556600300a06082a8648ce3d04
0302306f310b3009060355040613024e4c310b300906035504080c024e423110 0302306f310b3009060355040613024e4c310b300906035504080c024e423110
300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465
7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013
06035504030c0c6d6173612e73746f6b2e6e6c3020170d323030393039303734 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030
3230335a180f39393939313233313233353935395a308190310b300906035504 3233365a180f39393939313233313233353935395a308190310b300906035504
0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c
6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355
040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964
3a706c656467652e312e322e332e34311730150603550405130e706c65646765 3a706c656467652e312e322e332e34311730150603550405130e706c65646765
2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703
4200048a9c86aebc0b71e991564278903aabcfd19a5d6ae77255ee95adcf3402 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c
3c964469cdde8c90d2b9ebe5d5f29df1b6c6af3e718fae1b04eb009629f4eca8 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb
64202ca35d305b30090603551d1304023000301d0603551d0e0416041459b1e1 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4
19f46853e90e7c9f29d0fb5b1facc38249301f0603551d2304183016801422bc 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203
b820d9c56d2d5bb3bb648be08ba7865eceb4300e0603551d0f0101ff04040302 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c
05a0300a06082a8648ce3d040302034800304502204dfda8837831d262a4e548 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80
a2e0a73bc514e97e461345bc30fd1de5d6633ed8f4022100a8e51ec2797790fc bb5688bc031de51e316f<CODE ENDS>
40a87abfb1bd818beed7561a044d8fc83d765f4d6e36a2c2
C.2.2. Registrar Certificate B.2.2. Registrar Certificate
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
39:73:74:f3:fa:81:2a:0d:37:10:3b:68:c1:84:81:c5:01:bc:7c:fe 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy,
OU=consultancy, CN=registrar.stok.nl CN=registrar.stok.nl
Validity Validity
Not Before: Sep 9 07:42:03 2020 GMT Not Before: Dec 9 10:02:36 2020 GMT
Not After : Sep 9 07:42:03 2021 GMT Not After : Dec 9 10:02:36 2021 GMT
Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy,
OU=consultancy, CN=registrar.stok.nl CN=registrar.stok.nl
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:6a:24:a9:e2:4b:e2:34:d1:7a:d4:7e:76:0c:94: 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed:
b5:e1:dc:4e:e1:15:ad:89:11:2a:d4:a6:a6:4b:b1: 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0:
bf:68:f9:17:7d:70:e9:10:9c:b4:8c:9b:0d:c7:df: 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d:
26:41:19:9d:0c:2d:bf:f2:1e:d5:84:03:8a:c8:3f: a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92:
47:81:be:13:8e 3e:d0:2d:c7:b7
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
25:CD:93:71:B5:A1:5F:6D:1E:E8:C3:7A:51:13:BE:0B:8F:13:2C:C2 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3
X509v3 Authority Key Identifier: X509v3 Authority Key Identifier:
keyid: keyid:
25:CD:93:71:B5:A1:5F:6D:1E:E8:C3:7A:51:13:BE:0B:8F:13:2C:C2 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3
X509v3 Basic Constraints: X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Extended Key Usage:
CMC Registration Authority, TLS Web Server
Authentication, TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment,
Data Encipherment, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:a6:6d:9e:24:f9:de:08:b7:f0:cf:43:c3:c0: 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46:
ee:57:cc:b6:60:de:ae:2e:70:cc:61:a1:a2:b3:35:35:02:5b: fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6:
ba:02:21:00:bf:fd:74:6a:99:eb:da:01:77:fc:6c:37:95:75: 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02:
8a:f4:a0:9f:99:8e:bc:4a:90:62:49:f0:7a:c9:65:96:dc:75 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f
<CODE ENDS>
This the hexadecimal representation, in (request-)voucher examples This the hexadecimal representation, in (request-)voucher examples
referred to as regis-cert-hex referred to as regis-cert-hex
30820239308201dea0030201020214397374f3fa812a0d37103b68c18481c501
bc7cfe300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c
f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b
300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330
11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e
73756c74616e6379311a301806035504030c117265676973747261722e73746f 73756c74616e6379311a301806035504030c117265676973747261722e73746f
6b2e6e6c301e170d3230303930393037343230335a170d323130393039303734 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030
3230335a3073310b3009060355040613024e4c310b300906035504080c024e42 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42
3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e
64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30
1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a
8648ce3d020106082a8648ce3d030107034200046a24a9e24be234d17ad47e76 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03
0c94b5e1dc4ee115ad89112ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d
2641199d0c2dbff21ed584038ac83f4781be138ea350304e301d0603551d0e04 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d
16041425cd9371b5a15f6d1ee8c37a5113be0b8f132cc2301f0603551d230418 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23
3016801425cd9371b5a15f6d1ee8c37a5113be0b8f132cc2300c0603551d1304 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d
0530030101ff300a06082a8648ce3d0403020349003046022100a66d9e24f9de 130101ff040530030101ff30270603551d250420301e06082b0601050507031c
08b7f0cf43c3c0ee57ccb660deae2e70cc61a1a2b33535025bba022100bffd74 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404
6a99ebda0177fc6c3795758af4a09f998ebc4a906249f07ac96596dc75 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc
fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e
78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f<CODE ENDS>
B.2.3. MASA Certificate
C.2.3. MASA Certificate
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
70:5a:34:7e:67:d2:4d:70:b0:c6:ca:60:ff:fb:75:d9:46:82:e6:0e 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok,
OU=manufacturer, CN=masa.stok.nl OU=manufacturer, CN=masa.stok.nl
Validity Validity
Not Before: Sep 9 07:42:03 2020 GMT Not Before: Dec 9 10:02:36 2020 GMT
Not After : Sep 9 07:42:03 2021 GMT Not After : Sep 5 10:02:36 2023 GMT
Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, Subject: C=NL, ST=NB, L=Helmond, O=vanderstok,
OU=manufacturer, CN=masa.stok.nl OU=manufacturer, CN=masa.stok.nl
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:81:f4:72:ec:9c:47:b2:8e:d1:eb:38:33:41:00: 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86:
d3:62:f6:48:50:da:02:d0:56:b2:22:7b:c8:4b:80: db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02:
59:95:77:07:d0:c3:58:8c:3c:f2:3c:5b:00:83:79: 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83:
54:da:0d:d1:b0:af:a1:c2:e8:cd:2c:3b:d0:86:45: 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6:
9f:89:73:0a:cb
ed:f3:17:5c:f1
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3
X509v3 Authority Key Identifier: X509v3 Authority Key Identifier:
keyid: keyid:
22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3
X509v3 Basic Constraints: X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Extended Key Usage:
CMC Registration Authority,
TLS Web Server Authentication,
TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment,
Data Encipherment, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:04:ac:8d:48:62:a2:a5:04:4f:61:fd:38:83:53: 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67:
9f:00:e7:d6:4b:4d:30:1b:84:29:d4:2d:35:58:b0:a0:0c:7d: 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53:
02:21:00:8c:f1:f4:f9:a2:11:fe:64:46:a9:87:9f:58:ca:ea: 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d:
da:4f:0a:42:32:c2:6a:e8:c5:9d:62:c0:67:f0:b8:44:43 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c
<CODE ENDS>
This is the hexadecimal representation, in (request-)voucher examples This is the hexadecimal representation, in (request-)voucher examples
referred to as masa-cert-hex. referred to as masa-cert-hex.
30820230308201d6a0030201020214705a347e67d24d70b0c6ca60fffb75d946 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5
82e60e300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b
300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330
11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e
7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c
301e170d3230303930393037343230335a170d3231303930393037343230335a 301e170d3230313230393130303233365a170d3233303930353130303233365a
306f310b3009060355040613024e4c310b300906035504080c024e423110300e 306f310b3009060355040613024e4c310b300906035504080c024e423110300e
06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273
746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603
5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608
2a8648ce3d0301070342000481f472ec9c47b28ed1eb38334100d362f64850da 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a
02d056b2227bc84b8059957707d0c3588c3cf23c5b00837954da0dd1b0afa1c2 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797
e8cd2c3bd086459f89730acba350304e301d0603551d0e0416041422bcb820d9 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393
c56d2d5bb3bb648be08ba7865eceb4301f0603551d2304183016801422bcb820 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403
d9c56d2d5bb3bb648be08ba7865eceb4300c0603551d13040530030101ff300a 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003
06082a8648ce3d0403020348003045022004ac8d4862a2a5044f61fd3883539f 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507
00e7d64b4d301b8429d42d3558b0a00c7d0221008cf1f4f9a211fe6446a9879f 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608
58caeada4f0a4232c26ae8c59d62c067f0b84443 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe
fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c
7d98edd884536184a7f913064ca9b28f5c<CODE ENDS>
C.3. COSE signed voucher request from pledge to Registrar B.3. COSE signed voucher request from Pledge to Registrar
In this example the voucher request has been signed by the pledge, In this example the voucher request has been signed by the Pledge,
and has been sent to the JRC over CoAPS. This example uses the and has been sent to the JRC over CoAPS. The Pledge uses the
proximity-registrar-cert mechanism to request a voucher that pins the proximity assertion together with an included proximity-registrar-
certificate of the registrar. cert field to inform MASA about its proximity to the specific
Registrar.
POST coaps://registrar.example.com/est/rv POST coaps://registrar.example.com/est/rv
(Content-Format: application/voucher-cose+cbor) (Content-Format: application/voucher-cose+cbor)
signed_request_voucher signed_request_voucher
The payload signed_request_voucher is shown as hexadecimal dump (with The payload signed_request_voucher is shown as hexadecimal dump (with
lf added): lf added):
d28444a101382ea1045820f8926f5ba385b7bccf23592b97a73c1b00bffc01023 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164be89d023a5f3d
0f647f06960870b1fd6ee5902aca11909c5a61909c77818323032302d31302d35 f52699c0fbfb55902d2a11909c5a60274323032302d31322d32335431323a30353a32325a
5431333a34363a31332d30303a30301909c97818323032322d31302d355431333 0474323032322d31322d32335431323a30353a32325a01020750684ca83e27230aff97630
a34363a31332d30303a30301909c6021909cc5029c7bafb81a2c6160d3357d229 cf2c1ec409a0d6e706c656467652e312e322e332e340a590279308202753082021ca00302
11f5101909d26e706c656467652e312e322e332e341909cf59023d30820239308 010202147056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d0403023
201dea0030201020214397374f3fa812a0d37103b68c18481c501bc7cfe300a06 073310b3009060355040613024e4c310b300906035504080c024e423110300e0603550407
082a8648ce3d0403023073310b3009060355040613024e4c310b3009060355040 0c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b3114301206035
80c024e423110300e06035504070c0748656c6d6f6e6431133011060355040a0c 5040b0c0b636f6e73756c74616e6379311a301806035504030c117265676973747261722e
0a76616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e637 73746f6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030323
9311a301806035504030c117265676973747261722e73746f6b2e6e6c301e170d 3365a3073310b3009060355040613024e4c310b300906035504080c024e423110300e0603
3230303930393037343230335a170d3231303930393037343230335a3073310b3 5504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b3114301
009060355040613024e4c310b300906035504080c024e423110300e0603550407 2060355040b0c0b636f6e73756c74616e6379311a301806035504030c1172656769737472
0c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b31143 61722e73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d0301070342000
012060355040b0c0b636f6e73756c74616e6379311a301806035504030c117265 4507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb9
676973747261722e73746f6b2e6e6c3059301306072a8648ce3d020106082a864 4e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0
8ce3d030107034200046a24a9e24be234d17ad47e760c94b5e1dc4ee115ad8911 603551d0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d2304
2ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df2641199d0c2dbff21ed5840 183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff040
38ac83f4781be138ea350304e301d0603551d0e0416041425cd9371b5a15f6d1e 530030101ff30270603551d250420301e06082b0601050507031c06082b06010505070301
e8c37a5113be0b8f132cc2301f0603551d2304183016801425cd9371b5a15f6d1 06082b06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648ce3d040
ee8c37a5113be0b8f132cc2300c0603551d13040530030101ff300a06082a8648 30203470030440220744c99008513b2f1bcfdf9021a46fb174cf883a27ca1d93faeacf31e
ce3d0403020349003046022100a66d9e24f9de08b7f0cf43c3c0ee57ccb660dea 4edd12c60220114714dbf51a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c
e2e70cc61a1a2b33535025bba022100bffd746a99ebda0177fc6c3795758af4a0 35f58473045022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3336b
9f998ebc4a906249f07ac96596dc7558473045022100fc28be418e5f25152590e 8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f299148
872b4bbdbe334cd31d1ebb0a806e7a172cad5cff604022056ee414ddac438e7f5 4e9
1dda9ddf6ec6e31a78cdde6574717fe46dd3a7c60f5bb5 <CODE ENDS>
The representiation of signed_voucher_request in CBOR diagnostic The representiation of signed_voucher_request in CBOR diagnostic
format is: format is:
Diagnose(signed_request_voucher) = Diagnose(signed_request_voucher) =
18([ 18([
h'A101382E', # {"alg": -47} h'A101382E', # {"alg": -47}
{4:h'F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1F {4: h'97113DB094EEE8EAE48683E7337875C0372164BE89D023A5F3DF52699C0FBFB5'},
D6EE'}, h'request_voucher',
h'request_voucher' h'3045022063766C7BBD1B339DBC398E764AF3563E93B25A69104BEFE9AAC2B3336B8F56E
h'3045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A17 1022100CD0419559AD960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F2991484E9'
2CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE4 ])
6DD3A7C60F5BB5'])
Diagnose(request_voucher) =
{2501: {2503: "2020-10-5T13:46:13-00:00",
2505: "2022-10-5T13:46:13-00:00",
2502: 2,
2508: h'29C7BAFB81A2C6160D3357D22911F510',
2514: "pledge.1.2.3.4",
2511: h'regis-cert-hex'}},
C.4. COSE signed voucher request from Registrar to MASA Diagnose(request_voucher) =
{2501: {2: "2020-12-23T12:05:22Z",
4: "2022-12-23T12:05:22Z",
1: 2,
7: h'684CA83E27230AFF97630CF2C1EC409A',
13: "pledge.1.2.3.4",
10: h'regis-cert-hex'}}
<CODE ENDS>
B.4. COSE signed voucher request from Registrar to MASA
In this example the voucher request has been signed by the JRC using In this example the voucher request has been signed by the JRC using
the private key from Appendix C.1.2. Contained within this voucher the private key from Appendix B.1.2. Contained within this voucher
request is the voucher request from the pledge to JRC. request is the voucher request from the Pledge to JRC.
POST coaps://masa.example.com/est/rv POST coaps://masa.example.com/est/rv
(Content-Format: application/voucher-cose+cbor) (Content-Format: application/voucher-cose+cbor)
signed_masa_request_voucher signed_masa_request_voucher
The payload signed_masa_voucher_request is shown as hexadecimal dump The payload signed_masa_voucher_request is shown as hexadecimal dump
(with lf added): (with lf added):
d28444a101382ea1045820b86ae808f79af17e5948cbda731f158d04bd091c73f d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c11131b205efec5d03
485f2409eac08ee7ddb5c5903fea11909c5a61909c77818323032302d31302d35 13bad84c5cd05590414a11909c5a60274323032302d31322d32385431303a30333a33355a
5431333a34363a31332d30303a30301909c97818323032322d31302d355431333 0474323032322d31322d32385431303a30333a33355a07501551631f6e0416bd162ba53ea
a34363a31332d30303a30301909cc5029c7bafb81a2c6160d3357d22911f51019 00c2a050d6e706c656467652e312e322e332e3405587131322d32385431303a30333a3335
09d26e706c656467652e312e322e332e341909ca586b433d4e4c2c2053543d4e4 5a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e34055
22c204c3d48656c6d6f6e642c204f3d76616e64657273746f6b2c204f553d6d61 87131322d32385431303a300000000000000000000000000416bd162ba53ea00c2a050d6e
6e75666163747572696e672c20434e3d757569643a706c656467652e312e322e3 706c656467652e312e322e332e3405587131322d32385431303a09590349d28444a101382
32e342c2073657269616c4e756d6265723d706c656467652e312e322e332e3419 ea104582097113db094eee8eae48683e7337875c0372164be89d023a5f3df52699c0fbfb5
09ce590323d28444a101382ea1045820f8926f5ba385b7bccf23592b97a73c1b0 5902d2a11909c5a60274323032302d31322d32385431303a30333a33355a0474323032322
0bffc010230f647f06960870b1fd6ee5902aca11909c5a61909c7781832303230 d31322d32385431303a30333a33355a010207501551631f6e0416bd162ba53ea00c2a050d
2d31302d355431333a34363a31332d30303a30301909c97818323032322d31302 6e706c656467652e312e322e332e340a590279308202753082021ca00302010202147056e
d355431333a34363a31332d30303a30301909c6021909cc5029c7bafb81a2c616 aaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d0403023073310b300906
0d3357d22911f5101909d26e706c656467652e312e322e332e341909cf59023d3 0355040613024e4c310b300906035504080c024e423110300e06035504070c0748656c6d6
0820239308201dea0030201020214397374f3fa812a0d37103b68c18481c501bc f6e6431133011060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f
7cfe300a06082a8648ce3d0403023073310b3009060355040613024e4c310b300 6e73756c74616e6379311a301806035504030c117265676973747261722e73746f6b2e6e6
906035504080c024e423110300e06035504070c0748656c6d6f6e643113301106 c301e170d3230313230393130303233365a170d3231313230393130303233365a3073310b
0355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e73756 3009060355040613024e4c310b300906035504080c024e423110300e06035504070c07486
c74616e6379311a301806035504030c117265676973747261722e73746f6b2e6e 56c6d6f6e6431133011060355040a0c0a76616e64657273746f6b31143012060355040b0c
6c301e170d3230303930393037343230335a170d3231303930393037343230335 0b636f6e73756c74616e6379311a301806035504030c117265676973747261722e73746f6
a3073310b3009060355040613024e4c310b300906035504080c024e423110300e b2e6e6c3059301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a8c
06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e646572737 69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b89340218
46f6b31143012060355040b0c0b636f6e73756c74616e6379311a301806035504 98da789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d0e0416
030c117265676973747261722e73746f6b2e6e6c3059301306072a8648ce3d020 041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c
106082a8648ce3d030107034200046a24a9e24be234d17ad47e760c94b5e1dc4e 2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30
e115ad89112ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df2641199d0c2db 270603551d250420301e06082b0601050507031c06082b0601050507030106082b0601050
ff21ed584038ac83f4781be138ea350304e301d0603551d0e0416041425cd9371 5070302300e0603551d0f0101ff0404030201f6300a06082a8648ce3d0403020347003044
b5a15f6d1ee8c37a5113be0b8f132cc2301f0603551d2304183016801425cd937 0220744c99008513b2f1bcfdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c602201
1b5a15f6d1ee8c37a5113be0b8f132cc2300c0603551d13040530030101ff300a 14714dbf51a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f5847304502
06082a8648ce3d0403020349003046022100a66d9e24f9de08b7f0cf43c3c0ee5 2063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100c
7ccb660deae2e70cc61a1a2b33535025bba022100bffd746a99ebda0177fc6c37 d0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484e95847304502
95758af4a09f998ebc4a906249f07ac96596dc7558473045022100fc28be418e5 2100e6b45558c1b806bba23f4ac626c9bdb6fd354ef4330d8dfb7c529f29cca934c802203
f25152590e872b4bbdbe334cd31d1ebb0<<a806e7a172cad5cff604022056ee41 c1f2ccbbac89733d17ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8
4ddac438e7f51dda9ddf6ec6e31a78cdde6574717fe46dd3a7c60f5bb55847304
5022047b5314c72cbb2d1212e51198061167c79e1002874cd2665a5b643fa6436
3c30022100ce49ac309f760bd0e75660a7e29edee82f0251724c124150f5326b9
b2654927c
<CODE ENDS>
The representiation of signed_masa_voucher_request in CBOR diagnostic The representiation of signed_masa_voucher_request in CBOR diagnostic
format is: format is:
Diagnose(signed_masa_request_voucher) = Diagnose(signed_registrar_request-voucher)
18([
18([ h'A101382E', # {"alg": -47}
h'A101382E', # {"alg": -47} h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84C5CD0
{4:h'B86AE808F79AF17E5948CBDA731F158D04BD091C73F485F2409EAC08EE7D 5'},
DB5C'}, h'registrar_request_voucher',
h'masa_request_voucher', h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB7C529
h'3045022047B5314C72CBB2D1212E51198061167C79E1002874CD2665A5B643F F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96AFBA2741CC3
A64363C30022100CE49AC309F760BD0E75660A7E29EDEE82F0251724C124150F5 1532444AA8FED8'
326B9B2654927C']) ])
Diagnose(masa_request_voucher) = Diagnose(registrar_request_voucher)
{2501: {2501:
{2503: "2020-10-5T13:46:13-00:00", {2: "2020-12-28T10:03:35Z",
2505: "2022-10-5T13:46:13-00:00", 4: "2022-12-28T10:03:35Z",
2508: h'29C7BAFB81A2C6160D3357D22911F510', 7: h'1551631F6E0416BD162BA53EA00C2A05',
2514: "pledge.1.2.3.4", 13: "pledge.1.2.3.4",
2506:h'433D4E4C2C2053543D4E422C204C3D48656C6D6F6E642C 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD162BA53EA00C2
204F3D76616E64657273746F6B2C204F553D6D616E75666163747572696E672C2 A050D6E706C656467652E312E322E332E3405587131322D32385431303A300000
0434E3D757569643A706C656467652E312E322E332E342C2073657269616C4E75 000000000000000000000416BD162BA53EA00C2A050D6E706C656467652E312E3
6D6265723D706C656467652E312E322E332E34', 22E332E3405587131322D32385431303A',
2510: h'request_voucher'}}, 9: h'signed_request_voucher'}}
<CODE ENDS>
C.5. COSE signed voucher from MASA to Pledge via Registrar B.5. COSE signed voucher from MASA to Pledge via Registrar
The resulting voucher is created by the MASA and returned via the JRC The resulting voucher is created by the MASA and returned via the JRC
to the Pledge. It is signed by the MASA's private key Appendix C.1.3 to the Pledge. It is signed by the MASA's private key Appendix B.1.3
and can be verified by the pledge using the MASA's public key and can be verified by the Pledge using the MASA's public key
contained within the MASA certificate. contained within the MASA certificate.
This is the raw binary signed_voucher, encoded in hexadecimal (with This is the raw binary signed_voucher, encoded in hexadecimal (with
lf added): lf added):
d28444a101382ea1045820ab59b0679fcf65d5223d4ce4266a27a9c7432702466 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9029f7784daf11
ff5f3648e822a64d61b145902b0a1190993a71909957818323032302d31302d35 2614b19445d5158cfa1190993a70274323032302d31322d32335431353a30333a31325a04
5431333a34363a31342d30303a30301909977818323032322d31302d355431333 74323032302d31322d32335431353a32333a31325a010007506508e06b2959d5089d7a316
a34363a31342d30303a30301909940319099a5029c7bafb81a2c6160d3357d229 9ea889a490b6e706c656467652e312e322e332e340858753073310b300906035504061302
11f51019099e6e706c656467652e312e322e332e3419099b59023d30820239308 4e4c310b300906035504080c024e423110300e06035504070c0748656c6d6f6e643113301
201dea0030201020214397374f3fa812a0d37103b68c18481c501bc7cfe300a06 1060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e73756c7461
082a8648ce3d0403023073310b3009060355040613024e4c310b3009060355040 6e6379311a301806035504030c117265676973747261722e73746f6b2e6e6c03f45847304
80c024e423110300e06035504070c0748656c6d6f6e6431133011060355040a0c 5022022515d96cd12224ee5d3ac673237163bba24ad84815699285d9618f463ee73fa0221
0a76616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e637 00a6bff9d8585c1c9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f
9311a301806035504030c117265676973747261722e73746f6b2e6e6c301e170d
3230303930393037343230335a170d3231303930393037343230335a3073310b3
009060355040613024e4c310b300906035504080c024e423110300e0603550407
0c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b31143
012060355040b0c0b636f6e73756c74616e6379311a301806035504030c117265
676973747261722e73746f6b2e6e6c3059301306072a8648ce3d020106082a864
8ce3d030107034200046a24a9e24be234d17ad47e760c94b5e1dc4ee115ad8911
2ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df2641199d0c2dbff21ed5840
38ac83f4781be138ea350304e301d0603551d0e0416041425cd9371b5a15f6d1e
e8c37a5113be0b8f132cc2301f0603551d2304183016801425cd9371b5a15f6d1
ee8c37a5113be0b8f132cc2300c0603551d13040530030101ff300a06082a8648
ce3d0403020349003046022100a66d9e24f9de08b7f0cf43c3c0ee57ccb660dea
e2e70cc61a1a2b33535025bba022100bffd746a99ebda0177fc6c3795758af4a0
9f998ebc4a906249f07ac96596dc751909960058483046022100d07cadc5c2836
e7845d6d2e2652527386bd40258d20ab24b6bbce5515df915e9022100aba68a07
b2295c4b49d53f73ea370ca66f761ad5d8d8c11c19a2d505729285cb
<CODE ENDS>
The representiation of signed_voucher in CBOR diagnostic format is: The representiation of signed_voucher in CBOR diagnostic format is:
Diagnose (signed_voucher) = Diagnose(signed_voucher) =
18([ 18([
h'A101382E', # {"alg": -47} h'A101382E', # {"alg": -47}
{4: h'AB59B0679FCF65D5223D4CE4266A27A9C7432702466FF5F3648E822A64D61 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194
B14'}, 45D51'},
h'voucher', h'voucher',
h'3046022100D07CADC5C2836E7845D6D2E2652527386BD40258D20AB24B6BBCE h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F
5515DF915E9022100ABA68A07B2295C4B49D53F73EA370CA66F761AD5D8D8C11C 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B
19A2D505729285CB']) 3AEF58344C512F'
])
Diagnose (voucher) =
Diagnose(voucher) =
{2451: {2451:
{2453: "2020-10-5T13:46:14-00:00", {2: "2020-12-23T15:03:12Z",
2455: "2022-10-5T13:46:14-00:00", 4: "2020-12-23T15:23:12Z",
2452: 3, 1: 0,
2458: h'29C7BAFB81A2C6160D3357D22911F510', 7: h'6508E06B2959D5089D7A3169EA889A49',
2462: "pledge.1.2.3.4", 11: "pledge.1.2.3.4",
2459: h'regis-cert-hex', 8: h'regis-cert-hex',
2454: 0}} 3: false}}
<CODE ENDS>
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: consultancy@vanderstok.org
Panos Kampanakis Panos Kampanakis
Cisco Systems Cisco Systems
Email: pkampana@cisco.com Email: pkampana@cisco.com
Esko Dijk
IoTconsultancy.nl
Email: esko.dijk@iotconsultancy.nl
 End of changes. 196 change blocks. 
1025 lines changed or deleted 1060 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/