< draft-ietf-anima-constrained-voucher-04.txt   draft-ietf-anima-constrained-voucher-05.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: January 5, 2020 vanderstok consultancy Expires: January 9, 2020 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
July 04, 2019 July 08, 2019
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-04 draft-ietf-anima-constrained-voucher-05
Abstract Abstract
This document defines a strategy to securely assign a pledge to an This document defines a strategy to securely assign a pledge to an
owner, using an artifact signed, directly or indirectly, by the owner, using an artifact signed, directly or indirectly, by the
pledge's manufacturer. This artifact is known as a "voucher". 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], encoding the
resulting artifact in CBOR. Use with two signature technologies are resulting artifact in CBOR. Use with two signature technologies are
described. described.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 January 5, 2020. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . 4
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5
6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7
6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7
6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 8 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 8
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 9 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 9
6.1.4. Example voucher request artifact . . . . . . . . . . 13 6.1.4. Example voucher request artifact . . . . . . . . . . 13
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 14 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 18 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 17
6.3. Signing voucher and voucher-request artifacts . . . . . . 19 6.3. Signing voucher and voucher-request artifacts . . . . . . 18
6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 19 6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 20 6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 19
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 21 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 21 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 19
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 21 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 20
8.3. Test Domain Certificate Validity when Signing . . . . . . 21 8.3. Test Domain Certificate Validity when Signing . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 21 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 20
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 20
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 22 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 20
9.4. The RFC SID range assignment sub-registry . . . . . . . . 22 9.4. The RFC SID range assignment sub-registry . . . . . . . . 21
9.5. The SMI Security for S/MIME CMS Content Type Registry . . 22 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 21
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 23 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 21
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 23 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 21
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 23 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 22
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 24 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 27 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 27
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 28 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 27
A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 29 A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 28
A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 30 A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 29
A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 31 A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 30
Appendix B. Signed voucher-request examples . . . . . . . . . . 33 Appendix B. Signed voucher-request examples . . . . . . . . . . 32
B.1. CMS signed voucher-request example . . . . . . . . . . . 33 B.1. CMS signed voucher-request example . . . . . . . . . . . 32
Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 36 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 35
C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 36 C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 35
C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 36 C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 35
C.1.2. Device private key . . . . . . . . . . . . . . . . . 38 C.1.2. Device private key . . . . . . . . . . . . . . . . . 36
C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 38 C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 37
C.1.4. Registrar private key . . . . . . . . . . . . . . . . 38 C.1.4. Registrar private key . . . . . . . . . . . . . . . . 37
C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 38 C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 37
C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 39 C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 37
C.2. COSE signed requestvoucher with registrar certificate C.2. COSE signed requestvoucher with registrar certificate
pinned . . . . . . . . . . . . . . . . . . . . . . . . . 39 pinned . . . . . . . . . . . . . . . . . . . . . . . . . 38
C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 40 C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 38
C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 42 C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Enrollment of new nodes into constrained networks with constrained Enrollment of new nodes into constrained networks with constrained
nodes present unique challenges. nodes present unique challenges.
There are bandwidth and code space issues to contend. A solution There are bandwidth and code space issues to contend. A solution
such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in
terms of code space or bandwidth required. terms of code space or bandwidth required.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
CBOR ([RFC7049]). CBOR ([RFC7049]).
This document follows a similar, but not identical structure as This document follows a similar, but not identical structure as
[RFC8366]. Some sections are left out entirely. Additional sections [RFC8366]. Some sections are left out entirely. Additional sections
have been added concerning: have been added concerning:
1. Addition of voucher-request specification as defined in 1. Addition of voucher-request specification as defined in
[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. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests
over coap. over CoAP.
The CBOR definitions for this constrained voucher format are defined The CBOR definitions for this constrained voucher format are defined
using the mechanism describe in [I-D.ietf-core-yang-cbor] using the using the mechanism describe 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 an 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 Two methods of signing the resulting CBOR object are described in
this document: this document:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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, imprint, domain, 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, Trust of First Use (TOFU), and Voucher.
3. Requirements Language 3. Requirements Language
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119] and indicate requirement levels for compliant STuPiD 14 [RFC2119] [RFC8174] when, and only when, they appear in all
implementations. 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 include different amounts of
anti-replay protection. anti-replay protection.
This document does not make any extensions to the types of vouchers. This document does not make any extensions to the types of vouchers.
Time based vouchers are included in this definition, but given that Time based vouchers are included in this definition, but given that
constrained devices are extremely unlikely to know the correct 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 users of these constrained vouchers
will be online and will use live nonces to provide anti-replay will be online and will use live nonces to provide anti-replay
protection. 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 This document defines both a constrained voucher and a constrained
voucher-request. They are presented in the order voucher-request, voucher-request. They are presented in the order voucher-request,
followed by voucher response as this is the time order that they followed by a voucher response as this is the time order that they
occur. occur.
This document defines both CMS-signed voucher requests and responses, This document defines both CMS-signed voucher requests and responses,
and COSE signed voucher requests and responses. The use of CMS and COSE signed voucher requests and responses. The use of CMS
signatures implies the use of PKIX format certificates. The pinned- signatures implies the use of PKIX format certificates. The pinned-
domain-cert present in such a voucher, is the certificate of the domain-cert present in such a voucher, is the certificate of the
Registrar. Registrar.
The constrained voucher and constrained voucher request MUST be The constrained voucher and constrained voucher request MUST be
signed. signed.
The use of the two signing formats permit the use of both PKIX format The use of the two signing formats permit the use of both PKIX format
certificates, and also raw public keys (RPK). When RPKs are used, certificates, and raw public keys (RPK). When RPKs are used, the
the voucher produced by the MASA pins the raw public key of the voucher produced by the MASA pins the raw public key of the
Registrar: the pinned-domain-subject-public-key-info in such a Registrar: the pinned-domain-subject-public-key-info in such a
voucher, is the raw public key of the Registrar. This is described voucher, is the raw public key of the Registrar. This is described
in the YANG definition for the constrained voucher. in the YANG definition for the constrained 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- 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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 | | /requestauditlog | /ra |
+------------------+-----------+ +------------------+-----------+
Table 1: BRSKI path to EST-coaps path Table 1: BRSKI path to EST-coaps path
/requestvoucher and /enrollstatus are needed between pledge and /requestvoucher, /voucher_status and /enrollstatus are needed between
Registrar. pledge and Registrar.
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.
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content RES: 2.05 Content
</est>; rt="ace.est" </est>; rt="ace.est"
</est/rv>; rt="ace.est/rv";ct=TBD2 TBD3 </est/rv>; rt="ace.est/rv";ct=TBD2 TBD3
</est/vs>; rt="ace.est/vs";ct=50 60 </est/vs>; rt="ace.est/vs";ct=50 60
</est/es>; rt="ace.est/es";ct=50 60 </est/es>; rt="ace.est/es";ct=50 60
</est/ra>; rt="ace.est/ra";ct=TBD2 TBD3 </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3
The return of the content-types allows the client to choose the most The return of the content-types allows the client to choose the most
appropriate one from multiple content types. appropriate one from multiple content types.
Port numbers, not returned in the example, are assumed to be the
default numbers 5683 and 5684 for coap and coaps respectively
(sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY
be returned in the <href> of the payload.
ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and
ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". ct=TBD3 stands for Content-Format "application/voucher-cose+cbor".
Content-Formats TBD2 and TBD3 are defined in this document. Content-Formats TBD2 and TBD3 are defined in this document.
The Content-Format ("application/json") 50 MAY be supported. The Content-Format ("application/json") 50 MAY be supported.
Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be
supported. supported.
6. Artifacts 6. Artifacts
skipping to change at page 9, line 4 skipping to change at page 9, line 4
+-- 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 6.1.2. SID values
Base SID value for voucher request: 1001150.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001167 module ietf-constrained-voucher-request 1001154 data /ietf-constrained-voucher-request:voucher
1001168 module ietf-restconf
1001169 module ietf-voucher
1001170 module ietf-yang-types
1001171 data /ietf-constrained-voucher-request:voucher
1001154 data .../ietf-constrained-voucher-request:voucher
1001155 data .../assertion 1001155 data .../assertion
1001156 data .../created-on 1001156 data .../created-on
1001157 data .../domain-cert-revocation-checks 1001157 data .../domain-cert-revocation-checks
1001158 data .../expires-on 1001158 data .../expires-on
1001159 data .../idevid-issuer 1001159 data .../idevid-issuer
1001160 data .../last-renewal-date 1001160 data .../last-renewal-date
1001161 data .../nonce 1001161 data /ietf-constrained-voucher-request:voucher/nonce
1001162 data .../pinned-domain-cert 1001162 data .../pinned-domain-cert
1001165 data .../prior-signed-voucher-request 1001165 data .../prior-signed-voucher-request
1001166 data .../proximity-registrar-cert 1001166 data .../proximity-registrar-cert
1001167 data mity-registrar-sha256-of-subject-public-key-info
1001163 data .../proximity-registrar-subject-public-key-info 1001163 data .../proximity-registrar-subject-public-key-info
1001164 data .../serial-number 1001164 data .../serial-number
1001172 data .../assertion
1001173 data .../created-on
1001174 data .../domain-cert-revocation-checks
1001175 data .../expires-on
1001176 data .../idevid-issuer
1001177 data .../last-renewal-date
1001178 data /ietf-constrained-voucher-request:voucher/nonce
1001179 data .../pinned-domain-cert
1001180 data .../prior-signed-voucher-request
1001181 data .../proximity-registrar-cert
1001182 data .../proximity-registrar-subject-public-key-info
1001183 data .../serial-number
1001150 data ietf-constrained-voucher-request
1001151 data ietf-restconf
1001152 data ietf-voucher
1001153 data ietf-yang-types
WARNING, obsolete definitions
6.1.3. YANG Module 6.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.
skipping to change at page 13, line 31 skipping to change at page 13, line 4
information for the purposes of policy decisions. information for the purposes of policy decisions.
For example this information could be useful to a For example this information could be useful to a
MASA to determine that both pledge and registrar MASA to determine that both pledge and registrar
agree on proximity assertions. The MASA SHOULD agree on proximity assertions. The MASA SHOULD
remove all prior-signed-voucher-request information when remove all prior-signed-voucher-request information when
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 6.1.4. Example voucher request artifact
Below a CBOR serialization of the constrained-voucher-request is Below is a CBOR serialization of the constrained-voucher-request is
shown in diagnostic CBOR notation. The enum value of the assertion shown in diagnostic CBOR notation. The enum value of the assertion
field is calculated to be zero by following the algorithm described field is calculated to be zero by following the algorithm described
in section 9.6.4.2 of [RFC7950]. in section 9.6.4.2 of [RFC7950].
{ {
1001154: { 1001154: {
+2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on / +2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on /
+4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on / +4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on /
+1 : 2, / SID= 1001155, assertion / +1 : 2, / SID= 1001155, assertion /
/ "proximity" / / "proximity" /
skipping to change at page 15, line 26 skipping to change at page 14, line 26
+-- 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
6.2.2. SID values 6.2.2. SID values
Base SID value for voucher request: 1001101.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001115 module ietf-constrained-voucher 1001104 data /ietf-constrained-voucher:voucher
1001116 module ietf-restconf 1001105 data /ietf-constrained-voucher:voucher/assertion
1001117 module ietf-voucher 1001106 data /ietf-constrained-voucher:voucher/created-on
1001118 module ietf-yang-types
1001119 data /ietf-constrained-voucher:voucher
1001104 data .../ietf-constrained-voucher:voucher
1001105 data .../assertion
1001106 data .../created-on
1001107 data .../domain-cert-revocation-checks 1001107 data .../domain-cert-revocation-checks
1001108 data .../expires-on 1001108 data /ietf-constrained-voucher:voucher/expires-on
1001109 data .../idevid-issuer 1001109 data /ietf-constrained-voucher:voucher/idevid-issuer
1001110 data .../last-renewal-date 1001110 data .../last-renewal-date
1001111 data .../nonce 1001111 data /ietf-constrained-voucher:voucher/nonce
1001112 data .../pinned-domain-cert 1001112 data .../pinned-domain-cert
1001113 data .../pinned-domain-subject-public-key-info 1001113 data .../pinned-domain-subject-public-key-info
1001114 data .../serial-number 1001115 data .../pinned-sha256-of-subject-public-key-info
1001114 data /ietf-constrained-voucher:voucher/serial-number
6.2.3. YANG Module 6.2.3. YANG Module
In the constraine-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@2018-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher@2018-09-01.yang"
module ietf-constrained-voucher { module ietf-constrained-voucher {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher";
prefix "constrained"; prefix "constrained";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description description
"This import statement is only present to access "This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference "RFC 8040: RESTCONF Protocol";
skipping to change at page 18, line 31 skipping to change at page 17, line 24
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 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the the constrained-voucher is Below a the CBOR serialization of the constrained-voucher is shown in
shown in diagnostic CBOR notation. The enum value of the assertion diagnostic CBOR notation. The enum value of the assertion field is
field is calculated to be zero by following the algorithm described calculated to be zero by following the algorithm described in section
in section 9.6.4.2 of [RFC7950]. 9.6.4.2 of [RFC7950].
{ {
1001104: { 1001104: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on /
+1 : 0, / SID = 1001105, assertion / +1 : 0, / SID = 1001105, assertion /
/ "verified" / / "verified" /
+11: "JADA123456789", / SID = 1001115, serial-number / +11: "JADA123456789", / SID = 1001115, serial-number /
+5 : h'01020D0F', / SID = 1001109, idevid-issuer / +5 : h'01020D0F', / SID = 1001109, idevid-issuer /
+8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/ +8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/
skipping to change at page 20, line 30 skipping to change at page 19, line 11
In Appendix B.1 an example for the CMS signing of the voucher-request In Appendix B.1 an example for the CMS signing of the voucher-request
is shown. is shown.
6.3.2. COSE signing 6.3.2. COSE signing
The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152].
The CBOR object that carries the body, the signature, and the The CBOR object that carries the body, the signature, and the
information about the body and signature is called the COSE_Sign1 information about the body and signature is called the COSE_Sign1
structure. It is used when only one signature is used on the body. structure. It is used when only one signature is used on the body.
Support for EDdsa 256 with Ed25519 is compulsory. Support for EdDSA 256 with Ed25519 is compulsory.
The supported COSE-sign1 object stucture is shown in Figure 1. The supported COSE-sign1 object stucture is shown in Figure 1.
COSE_Sign1( COSE_Sign1(
[ [
h'a10126', #{ "alg": EDdsa 256 } h'a10126', #{ "alg": EDdsa 256 }
{ {
"crv": Ed25519, "crv": Ed25519,
"kty": OKP, "kty": OKP,
"key_ops": "verify" "key_ops": "verify"
skipping to change at page 23, line 8 skipping to change at page 21, line 43
Decimal Description References Decimal Description References
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
TBD1 id-ct-animaCBORVoucher [ThisRFC] TBD1 id-ct-animaCBORVoucher [ThisRFC]
EDNOTE: should a separate value be used for Voucher Requests? EDNOTE: should a separate value be used for Voucher Requests?
9.6. Media-Type Registry 9.6. Media-Type Registry
This section registers the 'application/voucher-cms+cbor' media type This section registers the 'application/voucher-cms+cbor' media type
and the 'application/voucher-cose+cbor'in the "Media Types" registry. and the 'application/voucher-cose+cbor' in the "Media Types"
These media types are used to indicate that the content is a CBOR registry. These media types are used to indicate that the content is
voucher either signed with a cms structure or a COSE_Sign1 structure a CBOR voucher either signed with a cms structure or a COSE_Sign1
[RFC8152]. structure [RFC8152].
9.6.1. application/voucher-cms+cbor 9.6.1. application/voucher-cms+cbor
Type name: application Type name: application
Subtype name: voucher-cms+cbor Subtype name: voucher-cms+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: CMS-signed CBOR vouchers are CBOR Encoding considerations: CMS-signed CBOR vouchers are CBOR
encoded. encoded.
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 27, line 13 skipping to change at page 26, line 13
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[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)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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 12.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,
skipping to change at page 36, line 28 skipping to change at page 35, line 28
0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 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 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 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 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 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df
unsignedAttrs: unsignedAttrs:
<EMPTY> <EMPTY>
Appendix C. COSE examples Appendix C. COSE examples
These examples are from the https://minerva.sandelman.ca/ reference
code, using the unit test case key pairs, with a flow between pledge
("reach" code), JRC ("fountain") code, and MASA ("highway") code.
This example comes from the spec/files/product/00-D0-E5-F2-00-03
directory.
Thanks to Jim Schaad for verifying the COSE Sign1 objects: faults
were found and corrected.
C.1. Device, Registrar and MASA keys C.1. Device, 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. Device IDevID certificate C.1.1. Device IDevID certificate
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 787697345 (0x2ef34ec1) Serial Number: 787697345 (0x2ef34ec1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN
= highway-test.example.com CA
Validity
Not Before: Feb 14 17:05:09 2019 GMT
Not After : Dec 31 00:00:00 2999 GMT
Subject: serialNumber = 00-D0-E5-F2-00-03
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:82:c4:28:5b:7c:f0:37:18:c7:90:14:dc:c
b:f4:
4d:7e:b0:00:ed:c0:de:bd:4d:25:55:4e:35:f
9:d5:
6a:57:14:b4:94:af:ce:6d:53:c8:60:c2:ce:5
3:3f:
2c:1b:42:f1:c0:8b:5f:c1:7b:3d:f3:29:54:8
7:46:
86:a4:0c:8b:b7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
C8:A3:87:72:82:82:E6:EA:90:D0:E1:81:BC:C7:51
:08:78:0F:D7:52
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Alternative Name:
othername:<unsupported>
1.3.6.1.4.1.46930.2:
..highway-test.example.com:9443
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:65:02:31:00:b2:9a:7a:1a:74:20:8f:e9:e0:5d:fc:af: Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = h
d6: ighway-test.example.com CA
4a:80:1f:66:e3:bf:17:2e:3e:07:87:39:be:65:bd:94:57: Validity
71: Not Before: Feb 14 17:05:09 2019 GMT
1f:df:e5:fc:4d:ef:96:8a:3a:03:5b:d1:ca:a1:72:55:a3: Not After : Dec 31 00:00:00 2999 GMT
02: Subject: serialNumber = 00-D0-E5-F2-00-03
30:13:43:08:a4:af:c8:28:19:d2:a0:93:3d:ed:53:fa:09: Subject Public Key Info:
7d: Public Key Algorithm: id-ecPublicKey
76:9c:b7:0b:95:2b:8f:2f:b4:fa:87:02:ec:b4:2d:19:92: Public-Key: (256 bit)
5b: pub:
b2:bb:79:04:63:6e:17:0e:79:8a:65:f5:a3 04:82:c4:28:5b:7c:f0:37:18:c7:90:14:dc:cb:f4:
4d:7e:b0:00:ed:c0:de:bd:4d:25:55:4e:35:f9:d5:
6a:57:14:b4:94:af:ce:6d:53:c8:60:c2:ce:53:3f:
2c:1b:42:f1:c0:8b:5f:c1:7b:3d:f3:29:54:87:46:
86:a4:0c:8b:b7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
C8:A3:87:72:82:82:E6:EA:90:D0:E1:81:BC:C7:51:08:78:0
F:D7:52
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Alternative Name:
othername:<unsupported>
1.3.6.1.4.1.46930.2:
..highway-test.example.com:9443
Signature Algorithm: ecdsa-with-SHA256
30:65:02:31:00:b2:9a:7a:1a:74:20:8f:e9:e0:5d:fc:af:d6:
4a:80:1f:66:e3:bf:17:2e:3e:07:87:39:be:65:bd:94:57:71:
1f:df:e5:fc:4d:ef:96:8a:3a:03:5b:d1:ca:a1:72:55:a3:02:
30:13:43:08:a4:af:c8:28:19:d2:a0:93:3d:ed:53:fa:09:7d:
76:9c:b7:0b:95:2b:8f:2f:b4:fa:87:02:ec:b4:2d:19:92:5b:
b2:bb:79:04:63:6e:17:0e:79:8a:65:f5:a3
C.1.2. Device private key C.1.2. Device private key
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49 MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49
AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI
YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw== YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
C.1.3. Registrar Certificate C.1.3. Registrar Certificate
skipping to change at page 39, line 26 skipping to change at page 38, line 18
key given above, and has been sent to the JRC over CoAPS. This key given above, and has been sent to the JRC over CoAPS. This
example uses the proximity-registrar-cert mechanism to request a example uses the proximity-registrar-cert mechanism to request a
voucher that pins the certificate of the registrar. voucher that pins the certificate of the registrar.
This is the CBOR diagnostic format, folded to 60 characters: This is the CBOR diagnostic format, folded to 60 characters:
18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5
D1E49970A5130302D44302D45352D46322D30302D303307765F715674477 D1E49970A5130302D44302D45352D46322D30302D303307765F715674477
738565342626C65394D34557036354C770C5901D4308201D030820157A00 738565342626C65394D34557036354C770C5901D4308201D030820157A00
30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0 30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0
992268993F22C6401191602636131193017060A0992268993F22C6401191 ** KNOWN TO BE BAD, NOT YET VALIDATED **
60973616E64656C6D616E313D303B06035504030C34666F756E7461696E2
D746573742E6578616D706C652E636F6D0A20556E737472756E6720466F7
56E7461696E20526F6F74204341301E170D3139303431363138353431315
A170D3139303531373034353431315A305331123010060A0992268993F22
C6401191602636131193017060A0992268993F22C640119160973616E646
56C6D616E3122302006035504030C19666F756E7461696E2D746573742E6
578616D706C652E636F6D3059301306072A8648CE3D020106082A8648CE3
D030107034200049665507234BA9FE5DDE65FF6F0816FE9489E810C12073
B468F97642B63008D020F57C97C947F848CB20E61D6C9888D15B4421FD7F
26AB7E4CE05F8A74CD38B3A300A06082A8648CE3D0403020367003064023
0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3 0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3
A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59 A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59
0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756 0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756
B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F
ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36 ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36
777FD7DBAE22B8CEB07D51D8F55AD3']) 777FD7DBAE22B8CEB07D51D8F55AD3'])
This is the raw binary, encoded in base64: This is the raw binary, encoded in base64:
0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G 0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G
Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD
AgECAgQijs0nMAoGCCqGSM49BAMCMG4xEjAQBgoJkiaJk/IsZAEZFgJjYTEZ ** KNOWN TO BE BAD, NOT YET VALIDATED **
MBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE9MDsGA1UEAww0Zm91bnRhaW4t
dGVzdC5leGFtcGxlLmNvbQogVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe
Fw0xOTA0MTYxODU0MTFaFw0xOTA1MTcwNDU0MTFaMFMxEjAQBgoJkiaJk/Is
ZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZ
Zm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/
hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizowCgYIKoZIzj0EAwIDZwAwZAIw
NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph
9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr 9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr
Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et
Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM= Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM=
C.3. COSE signed parboiled requestvoucher C.3. COSE signed parboiled requestvoucher
This voucher request has been signed by the JRC using the private key This voucher request has been signed by the JRC using the private key
from Appendix C.1.4. Contained within this voucher request is the from Appendix C.1.4. Contained within this voucher request is the
pledge voucher request above. pledge voucher request above.
This is the CBOR diagnostic format, folded to 60 characters: This is the CBOR diagnostic format, folded to 60 characters:
18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5
9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477 9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477
738565342626C65394D34557036354C770B590266D28441A0A059021CA11 738565342626C65394D34557036354C770B590266D28441A0A059021CA11
A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443 A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443
02D45352D46322D30302D303307765F715674477738565342626C65394D3 ** KNOWN TO BE BAD, NOT YET VALIDATED **
4557036354C770C5901D4308201D030820157A0030201020204228ECD273
00A06082A8648CE3D040302306E31123010060A0992268993F22C6401191
602636131193017060A0992268993F22C640119160973616E64656C6D616
E313D303B06035504030C34666F756E7461696E2D746573742E6578616D7
06C652E636F6D0A20556E737472756E6720466F756E7461696E20526F6F7
4204341301E170D3139303431363138353431315A170D313930353137303
4353431315A305331123010060A0992268993F22C6401191602636131193
017060A0992268993F22C640119160973616E64656C6D616E31223020060
35504030C19666F756E7461696E2D746573742E6578616D706C652E636F6
D3059301306072A8648CE3D020106082A8648CE3D0301070342000496655
07234BA9FE5DDE65FF6F0816FE9489E810C12073B468F97642B63008D020
F57C97C947F848CB20E61D6C9888D15B4421FD7F26AB7E4CE05F8A74CD38
B3A300A06082A8648CE3D04030203670030640230340F4E6D0F9F702553F
A53BE572ACF0EED858275B6AC75994332FB25FB3A54411E9FA02E6F75FD1
AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5 AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5
E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584 E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584
096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62 096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62
733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5 733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5
1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551 1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551
CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D
0EDE18EB1008EF7E9A279C']) 0EDE18EB1008EF7E9A279C'])
This is the raw binary, encoded in base64: This is the raw binary, encoded in base64:
0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G 0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G
Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa
AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf
cVZ0R3c4VlNCYmxlOU00VXA2NUx3DFkB1DCCAdAwggFXoAMCAQICBCKOzScw ** KNOWN TO BE BAD, NOT YET VALIDATED **
CgYIKoZIzj0EAwIwbjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPy
LGQBGRYJc2FuZGVsbWFuMT0wOwYDVQQDDDRmb3VudGFpbi10ZXN0LmV4YW1w
bGUuY29tCiBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTE5MDQxNjE4
NTQxMVoXDTE5MDUxNzA0NTQxMVowUzESMBAGCgmSJomT8ixkARkWAmNhMRkw
FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYDVQQDDBlmb3VudGFpbi10
ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAElmVQ
cjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0V
tEIf1/Jqt+TOBfinTNOLOjAKBggqhkjOPQQDAgNnADBkAjA0D05tD59wJVP6
U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI
8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA 8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA
lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7 lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7
DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO
VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA== VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA==
C.4. COSE signed voucher C.4. COSE signed voucher
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.6 to the Pledge. It is signed by the MASA's private key Appendix C.1.6
 End of changes. 41 change blocks. 
211 lines changed or deleted 140 lines changed or added

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