draft-ietf-anima-constrained-voucher-05.txt   draft-ietf-anima-constrained-voucher-06.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 9, 2020 vanderstok consultancy Expires: July 17, 2020 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
July 08, 2019 January 14, 2020
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-05 draft-ietf-anima-constrained-voucher-06
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 9, 2020. This Internet-Draft will expire on July 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6.1.4. Example voucher request artifact . . . . . . . . . . 13 6.1.4. Example voucher request artifact . . . . . . . . . . 13
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 13 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 17 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 17
6.3. Signing voucher and voucher-request artifacts . . . . . . 18 6.3. Signing voucher and voucher-request artifacts . . . . . . 18
6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 18 6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 19 6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 19
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 19 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 19 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 20
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 20 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 20
8.3. Test Domain Certificate Validity when Signing . . . . . . 20 8.3. Test Domain Certificate Validity when Signing . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 20 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 20
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 20 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 20
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 20 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 20
9.4. The RFC SID range assignment sub-registry . . . . . . . . 21 9.4. The RFC SID range assignment sub-registry . . . . . . . . 21
9.5. The SMI Security for S/MIME CMS Content Type Registry . . 21 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 21
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 21 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 21
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 21 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 21
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 22 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 22
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 23 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 27 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 26
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 27 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 26
A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 28 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 27
A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 29 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 28
A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 30 A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 28
Appendix B. Signed voucher-request examples . . . . . . . . . . 32 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 29
B.1. CMS signed voucher-request example . . . . . . . . . . . 32 Appendix B. Signed voucher-request examples . . . . . . . . . . 30
Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 35 B.1. CMS signed voucher-request example . . . . . . . . . . . 30
C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 35 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 33
C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 35 C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 33
C.1.2. Device private key . . . . . . . . . . . . . . . . . 36 C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 33
C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 37 C.1.2. Device private key . . . . . . . . . . . . . . . . . 34
C.1.4. Registrar private key . . . . . . . . . . . . . . . . 37 C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 35
C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 37 C.1.4. Registrar private key . . . . . . . . . . . . . . . . 35
C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 37 C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 35
C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 35
C.2. COSE signed requestvoucher with registrar certificate C.2. COSE signed requestvoucher with registrar certificate
pinned . . . . . . . . . . . . . . . . . . . . . . . . . 38 pinned . . . . . . . . . . . . . . . . . . . . . . . . . 36
C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 38 C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 36
C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 39 C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 C.5. COSE signed request voucher . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 7, line 24 skipping to change at page 7, line 24
6.1. Voucher Request artifact 6.1. Voucher Request artifact
6.1.1. Tree Diagram 6.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
grouping voucher-request-constrained-grouping grouping voucher-request-constrained-grouping
+-- voucher +-- voucher
+-- created-on? +-- created-on?
| yang:date-and-time | yang:date-and-time
+-- expires-on? +-- expires-on?
| yang:date-and-time | yang:date-and-time
skipping to change at page 9, line 6 skipping to change at page 9, line 6
+-- 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
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001154 data /ietf-constrained-voucher-request:voucher 2501 data /ietf-constrained-voucher-request:voucher
1001155 data .../assertion 2502 data .../assertion
1001156 data .../created-on 2503 data .../created-on
1001157 data .../domain-cert-revocation-checks 2504 data .../domain-cert-revocation-checks
1001158 data .../expires-on 2505 data .../expires-on
1001159 data .../idevid-issuer 2506 data .../idevid-issuer
1001160 data .../last-renewal-date 2507 data .../last-renewal-date
1001161 data /ietf-constrained-voucher-request:voucher/nonce 2508 data /ietf-constrained-voucher-request:voucher/nonce
1001162 data .../pinned-domain-cert 2509 data .../pinned-domain-cert
1001165 data .../prior-signed-voucher-request 2510 data .../prior-signed-voucher-request
1001166 data .../proximity-registrar-cert 2511 data .../proximity-registrar-cert
1001167 data mity-registrar-sha256-of-subject-public-key-info 2512 data mity-registrar-sha256-of-subject-public-key-info
1001163 data .../proximity-registrar-subject-public-key-info 2513 data .../proximity-registrar-subject-public-key-info
1001164 data .../serial-number 2514 data .../serial-number
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.
<CODE BEGINS> file "ietf-constrained-voucher-request@2018-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher-request@2019-09-01.yang"
module ietf-constrained-voucher-request { module ietf-constrained-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request";
prefix "constrained"; prefix "constrained";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description description
skipping to change at page 10, line 38 skipping to change at page 10, line 39
In particular, it assumes that nonce-ful operation is In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key. by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' in the module text are to be interpreted as and 'OPTIONAL' in the module text are to be interpreted as
described in RFC 2119."; described in RFC 2119.";
revision "2018-09-01" { revision "2019-09-01" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Constrained Devices"; "RFC XXXX: Voucher Profile for Constrained Devices";
} }
rc:yang-data voucher-request-constrained-artifact { rc:yang-data voucher-request-constrained-artifact {
// YANG data template for a voucher. // YANG data template for a voucher.
uses voucher-request-constrained-grouping; uses voucher-request-constrained-grouping;
} }
skipping to change at page 13, line 16 skipping to change at page 13, line 18
} }
<CODE ENDS> <CODE ENDS>
6.1.4. Example voucher request artifact 6.1.4. Example voucher request artifact
Below is 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: { 2501: {
+2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on / +2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on /
+4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on / +4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on /
+1 : 2, / SID= 1001155, assertion / +1 : 2, / SID= 2502, assertion /
/ "proximity" / / "proximity" /
+13: "JADA123456789", / SID= 1001167, serial-number / +13: "JADA123456789", / SID= 2514, serial-number /
+5 : h'01020D0F', / SID= 1001159, idevid-issuer / +5 : h'01020D0F', / SID= 2506, idevid-issuer /
+10: h'01020D0F', / SID=1001064, proximity-registrar-cert/ +10: h'01020D0F', / SID=2511, proximity-registrar-cert/
+3 : true, / SID= 1001157, domain-cert +3 : true, / SID= 2504, domain-cert
-revocation-checks/ -revocation-checks/
+6 : "2017-10-07T19:31:42Z", / SID= 1001160, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date /
+12: h'01020D0F' / SID= 1001166, proximity-registrar +12: h'01020D0F' / SID= 2513, proximity-registrar
-subject-public-key-info / -subject-public-key-info /
} }
} }
6.2. Voucher artifact 6.2. Voucher artifact
The voucher's primary purpose is to securely assign a pledge to an The voucher's primary purpose is to securely assign a pledge to an
owner. The voucher informs the pledge which entity it should owner. The voucher informs the pledge which entity it should
consider to be its owner. consider to be its owner.
This document defines a voucher that is a CBOR encoded instance of This document defines a voucher that is a CBOR encoded instance of
the YANG module defined in Section 5.3 that has been signed with CMS the YANG module defined in Section 5.3 that has been signed with CMS
or with COSE. or with COSE.
skipping to change at page 14, line 28 skipping to change at page 14, line 28
+-- 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
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001104 data /ietf-constrained-voucher:voucher 2451 data /ietf-constrained-voucher:voucher
1001105 data /ietf-constrained-voucher:voucher/assertion 2452 data /ietf-constrained-voucher:voucher/assertion
1001106 data /ietf-constrained-voucher:voucher/created-on 2453 data /ietf-constrained-voucher:voucher/created-on
1001107 data .../domain-cert-revocation-checks 2454 data .../domain-cert-revocation-checks
1001108 data /ietf-constrained-voucher:voucher/expires-on 2455 data /ietf-constrained-voucher:voucher/expires-on
1001109 data /ietf-constrained-voucher:voucher/idevid-issuer 2456 data /ietf-constrained-voucher:voucher/idevid-issuer
1001110 data .../last-renewal-date 2457 data .../last-renewal-date
1001111 data /ietf-constrained-voucher:voucher/nonce 2458 data /ietf-constrained-voucher:voucher/nonce
1001112 data .../pinned-domain-cert 2459 data .../pinned-domain-cert
1001113 data .../pinned-domain-subject-public-key-info 2460 data .../pinned-domain-subject-public-key-info
1001115 data .../pinned-sha256-of-subject-public-key-info 2461 data .../pinned-sha256-of-subject-public-key-info
1001114 data /ietf-constrained-voucher:voucher/serial-number 2462 data /ietf-constrained-voucher:voucher/serial-number
6.2.3. YANG Module 6.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@2018-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;
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 15, line 51 skipping to change at page 16, line 5
In particular, it assumes that nonce-ful operation is In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key. by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' in the module text are to be interpreted as and 'OPTIONAL' in the module text are to be interpreted as
described in RFC 2119."; described in RFC 2119.";
revision "2018-09-01" { revision "2019-09-01" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Constrained Devices"; "RFC XXXX: Voucher Profile for Constrained Devices";
} }
rc:yang-data voucher-constrained-artifact { rc:yang-data voucher-constrained-artifact {
// YANG data template for a voucher. // YANG data template for a voucher.
uses voucher-constrained-grouping; uses voucher-constrained-grouping;
} }
skipping to change at page 17, line 30 skipping to change at page 17, line 31
<CODE ENDS> <CODE ENDS>
6.2.4. Example voucher artifacts 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the constrained-voucher is shown in Below a the CBOR serialization of the constrained-voucher is shown in
diagnostic CBOR notation. The enum value of the assertion field is diagnostic CBOR notation. The enum value of the assertion field is
calculated to be zero by following the algorithm described in section calculated to be zero by following the algorithm described in section
9.6.4.2 of [RFC7950]. 9.6.4.2 of [RFC7950].
{ {
1001104: { 2451: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on /
+1 : 0, / SID = 1001105, assertion / +1 : 0, / SID = 2452, assertion /
/ "verified" / / "verified" /
+11: "JADA123456789", / SID = 1001115, serial-number / +11: "JADA123456789", / SID = 2462, serial-number /
+5 : h'01020D0F', / SID = 1001109, idevid-issuer / +5 : h'01020D0F', / SID = 2456, idevid-issuer /
+8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/ +8 : h'01020D0F', / SID = 2459, pinned-domain-cert/
+3 : true, / SID = 1001107, domain-cert +3 : true, / SID = 2454, domain-cert
-revocation-checks / -revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 1001110, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID = 2457, last-renewal-date /
+9 : h'01020D0F' / SID = 1001113, pinned-domain +9 : h'01020D0F' / SID = 2460, pinned-domain
-subject-public-key-info / -subject-public-key-info /
} }
} }
The signing of the example is shown in Appendix B.1. The signing of the example is shown in Appendix B.1.
6.3. Signing voucher and voucher-request artifacts 6.3. Signing voucher and voucher-request artifacts
6.3.1. CMS signing 6.3.1. CMS signing
The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed
voucher is much like the equivalent voucher defined in [RFC8366]. voucher is much like the equivalent voucher defined in [RFC8366].
A different eContentType of TBD1 is used to indicate that the A different eContentType of TBD1 is used to indicate that the
contents are in a different format than in [RFC8366]. 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 The ContentInfo structure contains a payload consisting of the CBOR
encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding
creates a canonical ordering for the keys on the wire. This creates a canonical ordering for the keys on the wire. This
canonical ordering is not important as there is no expectation that canonical ordering is not important as there is no expectation that
the content will be reproduced during the validation process. the content will be reproduced during the validation process.
Normally the recipient is the pledge and the signer is the MASA. Normally the recipient is the pledge and the signer is the MASA.
[I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and
skipping to change at page 18, line 47 skipping to change at page 18, line 50
the transaction. the transaction.
The CMS structure MAY also contain revocation objects for any The CMS structure MAY also contain revocation objects for any
intermediate certificate authorities (CAs) between the voucher-issuer intermediate certificate authorities (CAs) between the voucher-issuer
and the trust anchor known to the recipient. However, the use of and the trust anchor known to the recipient. However, the use of
CRLs and other validity mechanisms is discouraged, as the pledge is CRLs and other validity mechanisms is discouraged, as the pledge is
unlikely to be able to perform online checks, and is unlikely to have 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 a trusted clock source. As described below, the use of short-lived
vouchers and/or pledge provided nonce provides a freshness guarantee. vouchers and/or pledge provided nonce provides a freshness guarantee.
[EDnote: compulsory signing algorithms are ....] [EDnote: compulsory signing algorithms are ......]
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 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'a10127', # { "alg": EDdsa }
{ {
"crv": Ed25519, "kid" : h'789' # hash(pblic key)
"kty": OKP, },
"key_ops": "verify" h'123', #voucher-request binary content
}, h'456', #voucher-request binary public signature
h'123', #voucher-request binary content ]
h'456', #voucher-request binary public signature
]
) )
Figure 1: The cose-sign1 structure. Figure 1: 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. In Appendix C a binary cose-sign1 and the mnemonics in Figure 1. The value of the "kid" parameter is
object is shown based on the voucher-request example of an example value. Usually a hash of the public key is used to
Section 6.1.4. idientify the public key. The distribution of the public key and its
hash is done out of band.
In Appendix C a binary cose-sign1 object is shown based on the
voucher-request example of Section 6.1.4.
7. Design Considerations 7. 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.
skipping to change at page 21, line 21 skipping to change at page 21, line 21
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 9.4. The RFC SID range assignment sub-registry
------------ ------ --------------------------- ------------ ------------ ------ --------------------------- ------------
Entry-point | Size | Module name | RFC Number Entry-point | Size | Module name | RFC Number
------------ ------ --------------------------- ------------ ------------ ------ --------------------------- ------------
1001100 50 ietf-constrained-voucher [ThisRFC] 2450 50 ietf-constrained-voucher [ThisRFC]
1001150 50 ietf-constrained-voucher [ThisRFC} 2500 50 ietf-constrained-voucher [ThisRFC}
-request -request
----------- ------ --------------------------- ------------ ----------- ------ --------------------------- ------------
Warning: These SID values will change when they transfer to the range Warning: These SID values are defined in [I-D.ietf-core-sid].
1000 - 59,999 allocated for SIDs in YANG modules defined in RFCs.
9.5. The SMI Security for S/MIME CMS Content Type Registry 9.5. The SMI Security for S/MIME CMS Content Type Registry
This document registers an OID in the "SMI Security for S/MIME CMS 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: Content Type" registry (1.2.840.113549.1.9.16.1), with the value:
Decimal Description References Decimal Description References
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
TBD1 id-ct-animaCBORVoucher [ThisRFC] TBD1 id-ct-animaCBORVoucher [ThisRFC]
skipping to change at page 23, line 43 skipping to change at page 23, line 43
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-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 10. 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. choices. Also thanks to Jim Schaad for correctinging earlier version
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. We are grateful for the suggestions done by Esko Dijk.
11. Changelog 11. Changelog
-06 New SID values assigned; regenerated examples
-04 voucher and request-voucher MUST be signed examples for signed -04 voucher and request-voucher MUST be signed examples for signed
request are added in appendix IANA SID registration is updated SID request are added in appendix IANA SID registration is updated SID
values in examples are aligned signed cms examples aligned with new values in examples are aligned signed cms examples aligned with new
SIDs SIDs
-03 -03
Examples are inverted. Examples are inverted.
-02 -02
skipping to change at page 24, line 32 skipping to change at page 24, line 34
-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 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-ace-cbor-web-token]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
(work in progress), March 2018.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
est-12 (work in progress), June 2019. est-18 (work in progress), January 2020.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
S., and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-22 (work in progress), June 2019. keyinfra-34 (work in progress), January 2020.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[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 (SID)", draft-ietf-core-sid-06 (work in iDentifier (SID)", draft-ietf-core-sid-08 (work in
progress), March 2019. progress), January 2020.
[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-10 Data Modeled with YANG", draft-ietf-core-yang-cbor-11
(work in progress), April 2019. (work in progress), September 2019.
[ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[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 25, line 32
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<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 [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,
skipping to change at page 26, line 29 skipping to change at page 26, line 12
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,
<https://www.iana.org/assignments/cose/cose.xhtml>. <https://www.iana.org/assignments/cose/cose.xhtml>.
[duckling]
Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/
papers/1999-StajanoAnd-duckling.pdf>.
[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.
[pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015,
<http://dictionary.reference.com/browse/pledge>.
[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.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
Appendix A. EST messages to EST-coaps Appendix A. EST messages to EST-coaps
skipping to change at page 28, line 22 skipping to change at page 27, line 33
Option Value = 60 (application/cbor) Option Value = 60 (application/cbor)
Payload (CBOR diagnostic) = Payload (CBOR diagnostic) =
{ {
"version":"1", "version":"1",
"Status": 1, / 1 = Success, 0 = Fail / "Status": 1, / 1 = Success, 0 = Fail /
"Reason":"Informative human readable message", "Reason":"Informative human readable message",
"reason-context": "Additional information" "reason-context": "Additional information"
} }
Payload (binary) = The binary payload is:
A46776657273696F6E6131665374617475730166526561736F6E7822 A46776657273696F6E6131665374617475730166526561736F6E7822
496E666F726D61746976652068756D616E207265616461626C65206D 496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874 6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E 764164646974696F6E616C20696E666F726D6174696F6E
~~~
##voucher_status The binary payload disassembles to the above CBOR diagnostic code.
A coaps voucher_status message can be : A.2. voucher_status
GET coaps://[2001:db8::2:1]:61616]/est/vs ~~~~ A coaps voucher_status message can be:
A 2.05 Content response with a non signed CBOR voucher (ct=60) will GET coaps://[2001:db8::2:1]:61616]/est/vs
then be:
A 2.05 Content response with a non signed CBOR voucher status (ct=60)
will then be:
2.05 Content (Content-Format: application/cbor) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
A46776657273696F6E6131665374617475730166526561736F6E7822 A46776657273696F6E6131665374617475730166526561736F6E7822
496E666F726D61746976652068756D616E207265616461626C65206D 496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874 6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E 764164646974696F6E616C20696E666F726D6174696F6E
A.2. requestvoucher A.3. requestvoucher
Signed request-voucher-request payloads are sent from pledge to Signed request-voucher-request payloads are sent from pledge to
Registrar, as explained in Section 5.2 of Registrar, as explained in Section 5.2 of
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
A.2.1. signed requestvoucher A.3.1. signed requestvoucher
A CMS signed requestvoucher message from JRC to MASA is shown below. A CMS signed requestvoucher message from JRC to MASA is shown below.
It would be CoAP POSTED to /est/rv. It would be CoAP POSTED to /est/rv.
POST coaps://[2001:db8::2:1]:61616]/est/rv POST coaps://[2001:db8::2:1]:61616]/est/rv
(Content-Format: application/voucher-cms+cbor) (Content-Format: application/voucher-cms+cbor)
The payload would be in binary, but is presented in base64 in this The payload would be in binary, but is presented in base64 in this
document. document.
skipping to change at page 30, line 28 skipping to change at page 29, line 32
ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK
3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD
QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp
b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC
AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he
uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG
kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX
hlG/g+OgTUftYMJ32so= hlG/g+OgTUftYMJ32so=
A.3. requestauditing A.4. requestauditing
A coaps requestauditing message contains the signed CBOR voucher : A coaps requestauditing message contains the signed CBOR voucher :
POST coaps://[2001:db8::2:1]:61616]/est/ra POST coaps://[2001:db8::2:1]:61616]/est/ra
(Content-Format: application/voucher-cms+cbor) (Content-Format: application/voucher-cms+cbor)
Payload = Payload =
308203ba06092a864886f70d010702a08203ab308203a7020101310d300b TO BE FILLED
0609608648016503040201300b06092a864886f70d010701a08202413082
023d308201e2a00302010202087e7661d7b54e4632300a06082a8648ce3d
040302305d310b3009060355040613025553310b300906035504080c0243
4131143012060355040a0c0b4578616d706c6520496e6331163014060355
040b0c0d63657274696669636174696f6e3113301106035504030c0a3830
322e3141522043413020170d3139303133313131323931365a180f393939
39313233313233353935395a305c310b3009060355040613025553310b30
0906035504080c024341310b300906035504070c024c4131143012060355
040a0c0b6578616d706c6520496e63310c300a060355040b0c03496f5431
0f300d060355040513065774313233343059301306072a8648ce3d020106
082a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc49
4f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf
75f602f9152618f816a2b23b5638e59fd9a3818a30818730090603551d13
04023000301d0603551d0e0416041496600d8716bf7fd0e752d0ac760777
ad665d02a0301f0603551d2304183016801468d16551f951bfc82a431d0d
9f08bc2d205b1160300e0603551d0f0101ff0404030205a0302a0603551d
1104233021a01f06082b06010505070804a013301106092b06010401b43b
0a01040401020304300a06082a8648ce3d0403020349003046022100c0d8
1996d2507d693f3c48eaa5ee9491bda6db214099d98117c63b361374cd86
022100a774989f4c321a5cf25d832a4d336a08ad67df20f1506421188a0a
de6d3492363182013f3082013b0201013069305d310b3009060355040613
025553310b300906035504080c02434131143012060355040a0c0b457861
6d706c6520496e6331163014060355040b0c0d6365727469666963617469
6f6e3113301106035504030c0a3830322e31415220434102087e7661d7b5
4e4632300b0609608648016503040201a069301806092a864886f70d0109
03310b06092a864886f70d010701301c06092a864886f70d010905310f17
0d3139303430383130343833365a302f06092a864886f70d010904312204
20b11d09338bb36672ef0dcb82f4995d911a773dcb6f39e8141b3a14c14d
f7545a300a06082a8648ce3d0403020447304502200128c3b08a6bd2d5bf
9fa7511eabefaacaa06651dbb459c4ad46d67e14b4283e022100c3504a9c
e704e64467f469d110550cea988821304805d74bea5efd3680bd632f
A 2.05 Content response returning a log of the voucher (ct=60) will A 2.05 Content response returning a log of the voucher (ct=60) will
then be: then be:
2.05 Content (Content-Format: application/cbor) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
skipping to change at page 32, line 40 skipping to change at page 30, line 40
[EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary]
Appendix B. Signed voucher-request examples Appendix B. Signed voucher-request examples
B.1. CMS signed voucher-request example B.1. CMS signed voucher-request example
The voucher-request example, visualized in CBOR diagnostic notation The voucher-request example, visualized in CBOR diagnostic notation
in Section 6.1.4 is shown as a hexadecimal dump of the binary file. in Section 6.1.4 is shown as a hexadecimal dump of the binary file.
A11A000F46C2A90274323031362D31302D30375431393A33313A34325A0 a11909c5a90274323031362d31302d30375431393a33313a34325a0474323031
474323031362D31302D32315431393A33313A34325A01020d6d4A414441 362d31302d32315431393a33313a34325a01020d6d4a414441313233343536
313233343536373839054401020D0F0A4401020D0F03F50674323031372 373839054401020d0f0a4401020d0f03f50674323031372d31302d30375431
D31302D30375431393A33313A34325A0c4401020D0F 393a33313a34325a0c4401020d0f
The voucher-request example has been signed by using the WT1234 The voucher-request example has been signed by using the WT1234
certificate and key pair shown in Appendix C of certificate and key pair shown in Appendix C of
[I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher- [I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher-
request leads to a binary signed voucher-request, shown with a request leads to a binary signed voucher-request, shown with a
hexadecimal representation shown in the payload of the request part hexadecimal representation shown in the payload of the request part
of Appendix A.2.1 and Appendix A.3. of Appendix A.3.1 and Appendix A.4.
The breakdown of the CMS signed binary voucher-request file is The breakdown of the CMS signed binary voucher-request file is
visualized below: visualized below:
CMS_ContentInfo: CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2) contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData: d.signedData:
version: 1 version: 1
digestAlgorithms: digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1) algorithm: sha256 (2.16.840.1.101.3.4.2.1)
skipping to change at page 33, line 27 skipping to change at page 31, line 27
eContent: <ABSENT> eContent: <ABSENT>
certificates: certificates:
d.certificate: d.certificate:
cert_info: cert_info:
version: 2 version: 2
serialNumber: 9112578475118446130 serialNumber: 9112578475118446130
signature: signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT> parameter: <ABSENT>
issuer: C=US, ST=CA, O=Example Inc, OU=certification, issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA CN=802.1AR CA
validity: validity:
notBefore: Jan 31 11:29:16 2019 GMT notBefore: Jan 31 11:29:16 2019 GMT
notAfter: Dec 31 23:59:59 9999 GMT notAfter: Dec 31 23:59:59 9999 GMT
subject: C=US, ST=CA, L=LA, O=example Inc, subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234 OU=IoT/serialNumber=Wt1234
key: key:
algor: algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1) algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits) public_key: (0 unused bits)
0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 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 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 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 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 0038 - 16 a2 b2 3b 56 38 e5 9f-d9
skipping to change at page 34, line 41 skipping to change at page 32, line 41
000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 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 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 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 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36
crls: crls:
<EMPTY> <EMPTY>
signerInfos: signerInfos:
version: 1 version: 1
d.issuerAndSerialNumber: d.issuerAndSerialNumber:
issuer: C=US, ST=CA, O=Example Inc, OU=certification, issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA CN=802.1AR CA
serialNumber: 9112578475118446130 serialNumber: 9112578475118446130
digestAlgorithm: digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1) algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT> parameter: <ABSENT>
signedAttrs: signedAttrs:
object: contentType (1.2.840.113549.1.9.3) object: contentType (1.2.840.113549.1.9.3)
value.set: value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1) OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5) object: signingTime (1.2.840.113549.1.9.5)
skipping to change at page 35, line 34 skipping to change at page 33, line 34
<EMPTY> <EMPTY>
Appendix C. COSE examples Appendix C. COSE examples
These examples are from the https://minerva.sandelman.ca/ reference These examples are from the https://minerva.sandelman.ca/ reference
code, using the unit test case key pairs, with a flow between pledge code, using the unit test case key pairs, with a flow between pledge
("reach" code), JRC ("fountain") code, and MASA ("highway") code. ("reach" code), JRC ("fountain") code, and MASA ("highway") code.
This example comes from the spec/files/product/00-D0-E5-F2-00-03 This example comes from the spec/files/product/00-D0-E5-F2-00-03
directory. 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:
skipping to change at page 38, line 7 skipping to change at page 36, line 7
C.1.6. MASA private key C.1.6. MASA private key
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49
AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+
gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
C.2. COSE signed requestvoucher with registrar certificate pinned C.2. COSE signed requestvoucher with registrar certificate pinned
This voucher request has been signed by the pledge, using the private EDNote: These examples do not parse
key given above, and has been sent to the JRC over CoAPS. This
example uses the proximity-registrar-cert mechanism to request a This voucher request has been signed by the pledge, and has been sent
voucher that pins the certificate of the registrar. to the JRC over CoAPS. This example uses the proximity-registrar-
cert mechanism to request a 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
** KNOWN TO BE BAD, NOT YET VALIDATED ** ** KNOWN TO BE BAD, NOT YET VALIDATED **
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, shown as hex dump:
0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G 0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G
Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD
** KNOWN TO BE BAD, NOT YET VALIDATED ** ** KNOWN TO BE BAD, NOT YET VALIDATED **
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
These example do not parse
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
skipping to change at page 41, line 5 skipping to change at page 39, line 5
TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz
ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt
SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR
Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP
RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP
aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z
OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo
j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt
IEacccH2 IEacccH2
C.5. COSE signed request voucher
The headecimal dump of request-voucher shown in Appendix B.1 is used
for this example. The cose sign1 object of Figure 1 provides the
structure of the cose sign1 example. To identify the public key a
hash of the public key is made using murmur3 with seed 42.
public key:
84 44 de 3a b7 b5 a0 2f 20 ed e7 80 1a f0 76 d6 52 0a e5 c8 a1
04 41 61 b2 64 57 fe 0e ae 08 4d
murmur3 hash of public key: 0x4727e669 or 1193797225
Using the values "kid" = 4, EDdsa = -8, "alg" = 2, COSE_Sign1 = 18,
and using the murmur3 hash value for the "kid" parameter, the CBOR
object is:
18([h'A10127', {4: 1193797225},
h'A11909C5A90274323031362D31302D30375431393A33313A34325A04743
23031362D31302D32315431393A33313A34325A01020D6D4A414441313233
343536373839054401020D0F0A4401020D0F03F50674323031372D31302D3
0375431393A33313A34325A0C4401020D0F',
h'955D82A26B7C0869EE8FE5A09EE3D68DDFFE8FE39E3BCADFA80F2F9A6E13F
F0349A2CA131C8F6A9AAF7780BAB671F63CBB158EC17322323C1AB82B1CDC
B62A06'])
The corresponding hexadecimal dump is:
d28443a10127a1041a4727e669586ca11909c5a90274323031362d31302d
30375431393a33313a34325a0474323031362d31302d32315431393a3331
3a34325a01020d6d4a414441313233343536373839054401020d0f0a4401
020d0f03f50674323031372d31302d30375431393a33313a34325a0c4401
020d0f5840955d82a26b7c0869ee8fe5a09ee3d68ddffe8fe39e3bcadfa8
0f2f9a6e13ff0349a2ca131c8f6a9aaf7780bab671f63cbb158ec1732232
3c1ab82b1cdcb62a06
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
 End of changes. 59 change blocks. 
208 lines changed or deleted 189 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/