< draft-ietf-anima-constrained-voucher-03.txt   draft-ietf-anima-constrained-voucher-04.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: September 26, 2019 vanderstok consultancy Expires: January 5, 2020 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
March 25, 2019 July 04, 2019
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-03 draft-ietf-anima-constrained-voucher-04
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.
Additionally, this document explains how constrained vouchers may be Additionally, this document explains how constrained vouchers may be
transported in the [I-D.ietf-ace-coap-est] protocol. transported as an extension to the [I-D.ietf-ace-coap-est] protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2019. This Internet-Draft will expire on January 5, 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 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5
6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 8
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 8 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 9
6.1.4. Example voucher request artifact . . . . . . . . . . 12 6.1.4. Example voucher request artifact . . . . . . . . . . 13
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 14
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 15
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 16 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 18
6.3. CMS format voucher and voucher-request artifacts . . . . 16 6.3. Signing voucher and voucher-request artifacts . . . . . . 19
6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17 6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 19
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 18 6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 21
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 18 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 21
8.3. Test Domain Certificate Validity when Signing . . . . . . 18 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.3. Test Domain Certificate Validity when Signing . . . . . . 21
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 21
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 19 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21
9.4. The SMI Security for S/MIME CMS Content Type Registry . . 19 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 22
9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 19 9.4. The RFC SID range assignment sub-registry . . . . . . . . 22
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 20 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 22
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 20 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 23
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 20 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 23
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 21 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 24
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 27
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 27
A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 25 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 28
A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 26 A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 29
A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 26 A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 30
A.3.2. unsigned requestvoucher . . . . . . . . . . . . . . . 26 A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 31
A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Signed voucher-request examples . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 B.1. CMS signed voucher-request example . . . . . . . . . . . 33
Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 36
C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 36
C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 36
C.1.2. Device private key . . . . . . . . . . . . . . . . . 38
C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 38
C.1.4. Registrar private key . . . . . . . . . . . . . . . . 38
C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 38
C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 39
C.2. COSE signed requestvoucher with registrar certificate
pinned . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 40
C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 50 skipping to change at page 4, line 17
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:
1. One is CMS [RFC5652]. 1. One is CMS [RFC5652].
2. The other is COSE [RFC8152] signatures. 2. The other is COSE_Sign1 [RFC8152] objects.
2. Terminology 2. Terminology
The following terms are defined in [RFC8366], and are used The following terms are defined in [RFC8366], and are used
identically as in that document: artifact, imprint, domain, Join identically as in that document: artifact, 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
skipping to change at page 4, line 49 skipping to change at page 5, line 16
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 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 use of COSE signatures permits the use of both PKIX format The constrained voucher and constrained voucher request MUST be
signed.
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 also raw public keys (RPK). When RPKs are used,
the voucher produced by the MASA pins the raw public key of the 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
important and the EST-coaps URI is shorter than the EST URI. important and the EST-coaps URI is shorter than the EST URI.
The presence and location of (path to) the management data are The presence and location of (path to) the management data are
discovered by sending a GET request to "/.well-known/core" including discovered by sending a GET request to "/.well-known/core" including
a resource type (RT) parameter with the value "ace.est" [RFC6690]. a resource type (RT) parameter with the value "ace.est" [RFC6690].
Upon success, the return payload will contain the root resource of Upon success, the return payload will contain the root resource of
the EST resources. It is up to the implementation to choose its root the EST resources. It is up to the implementation to choose its root
resource; throughout this document the example root resource /est is resource; throughout this document the example root resource /est is
used. The example below shows the discovery of the presence and used.
location of voucher resources.
REQ: GET /.well-known/core?rt=ace.est
RES: 2.05 Content
</est>; rt="ace.est"
The EST-coaps server URIs differ from the EST URI by replacing the The EST-coaps server URIs differ from the EST URI by replacing the
scheme https by coaps and by specifying shorter resource path names: scheme https by coaps and by specifying shorter resource path names:
coaps://www.example.com/est/short-name coaps://www.example.com/est/short-name
Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and
corresponding paths which are supported by EST. Table 1 provides the corresponding paths which are supported by EST. Table 1 provides the
mapping from the BRSKI extension URI path to the EST-coaps URI path. mapping from the BRSKI extension URI path to the EST-coaps URI path.
skipping to change at page 6, line 18 skipping to change at page 6, line 32
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=50 60 TBD2 TBD3 16 </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 16 </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3
The first line MUST be returned in response to the GET, The following
four lines MAY be returned to show the supported Content-Formats.
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 Port numbers, not returned in the example, are assumed to be the
default numbers 5683 and 5684 for coap and coaps respectively default numbers 5683 and 5684 for coap and coaps respectively
(sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY (sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY
be returned in the <href> of the payload. be returned in the <href> of the payload.
ct=16 stands for the Content-Format "application/cose", and ct=TBD2 ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and
stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3 ct=TBD3 stands for Content-Format "application/voucher-cose+cbor".
stands for Content-Format "application/voucher-cose+cbor".
Content-Formats TBD2 and TBD3 are defined in this document. The Content-Formats TBD2 and TBD3 are defined in this document.
return of the content-formats allows the client to choose the most
appropriate one from multiple content formats.
The Content-Format ("application/json") 50 MAY be supported. The Content-Format ("application/json") 50 MAY be supported.
Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be
supported. supported.
6. Artifacts 6. Artifacts
This section describes the abstract (tree) definition as explained in This section describes the abstract (tree) definition as explained in
[I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high-
level view of the contents of each artifact. level view of the contents of each artifact.
Then the assigned SID values are presented. These have been assigned Then the assigned SID values are presented. These have been assigned
using the rules in [I-D.ietf-core-yang-cbor], with an allocation that using the rules in [I-D.ietf-core-sid], with an allocation that was
was made via the http://comi.space service. made via the http://comi.space service.
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
skipping to change at page 7, line 29 skipping to change at page 8, line 13
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
+-- assertion enumeration +-- assertion
+-- serial-number string | enumeration
+-- idevid-issuer? binary +-- serial-number
+-- pinned-domain-cert? binary | string
+-- domain-cert-revocation-checks? boolean +-- idevid-issuer?
+-- nonce? binary | binary
+-- pinned-domain-cert?
| binary
+-- domain-cert-revocation-checks?
| boolean
+-- nonce?
| binary
+-- last-renewal-date? +-- last-renewal-date?
| yang:date-and-time | yang:date-and-time
+-- proximity-registrar-subject-public-key-info? binary +-- proximity-registrar-subject-public-key-info?
+-- proximity-registrar-cert? binary | binary
+-- prior-signed-voucher-request? binary +-- proximity-registrar-sha256-of-subject-public-key-info?
| binary
+-- proximity-registrar-cert?
| binary
+-- prior-signed-voucher-request?
binary
6.1.2. SID values 6.1.2. SID values
Base SID value for voucher request: 1001150. Base SID value for voucher request: 1001150.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001167 module ietf-constrained-voucher-request 1001167 module ietf-constrained-voucher-request
1001168 module ietf-restconf 1001168 module ietf-restconf
1001169 module ietf-voucher 1001169 module ietf-voucher
1001170 module ietf-yang-types 1001170 module ietf-yang-types
skipping to change at page 9, line 8 skipping to change at page 10, line 8
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@2018-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
"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";
} }
import ietf-voucher { import ietf-voucher {
prefix "v"; prefix "v";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/anima/> "WG Web: <http://tools.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca> <mailto:mcr+ietf@sandelman.ca>
Author: Peter van der Stok Author: Peter van der Stok
<mailto: consultancy@vanderstok.org> <mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis Author: Panos Kampanakis
<mailto: pkampana@cisco.com>"; <mailto: pkampana@cisco.com>";
description description
"This module defines the format for a voucher request, "This module defines the format for a voucher request,
which is produced by a pledge to request a voucher. which is produced by a pledge to request a voucher.
The voucher-request is sent to the potential owner's The voucher-request is sent to the potential owner's
Registrar, which in turn sends the voucher request to Registrar, which in turn sends the voucher request to
the manufacturer or delegate (MASA). the manufacturer or delegate (MASA).
A voucher is then returned to the pledge, binding the A voucher is then returned to the pledge, binding the
pledge to the owner. This is a constrained version of the pledge to the owner. This is a constrained version of the
voucher-request present in voucher-request present in
draft-ietf-anima-bootstrap-keyinfra.txt. draft-ietf-anima-bootstrap-keyinfra.txt.
This version provides a very restricted subset appropriate This version provides a very restricted subset appropriate
for very constrained devices. for very constrained devices.
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 "2018-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;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-request-constrained-grouping { grouping voucher-request-constrained-grouping {
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { uses v:voucher-artifact-grouping {
refine voucher/created-on { refine voucher/created-on {
mandatory false; mandatory false;
} }
refine voucher/pinned-domain-cert { refine voucher/pinned-domain-cert {
mandatory false; mandatory false;
} }
augment "voucher" { augment "voucher" {
description "Base the constrained voucher-request upon the description "Base the constrained voucher-request upon the
regular one"; regular one";
leaf proximity-registrar-subject-public-key-info { leaf proximity-registrar-subject-public-key-info {
type binary; type binary;
description description
"The proximity-registrar-subject-public-key-info replaces "The proximity-registrar-subject-public-key-info replaces
the proximit-registrar-cert in constrained uses of the proximit-registrar-cert in constrained uses of
the voucher-request. the voucher-request.
The proximity-registrar-subject-public-key-info is the The proximity-registrar-subject-public-key-info is the
Raw Public Key of the Registrar. This field is encoded Raw Public Key of the Registrar. This field is encoded
as specified in RFC7250, section 3. as specified in RFC7250, section 3.
The ECDSA algorithm MUST be supported. The ECDSA algorithm MUST be supported.
The EdDSA algorithm as specified in The EdDSA algorithm as specified in
draft-ietf-tls-rfc4492bis-17 SHOULD be supported. draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
Support for the DSA algorithm is not recommended. Support for the DSA algorithm is not recommended.
Support for the RSA algorithm is a MAY."; Support for the RSA algorithm is MAY, but due to
} size is discouraged.";
}
leaf proximity-registrar-cert { leaf proximity-registrar-sha256-of-subject-public-key-info {
type binary; type binary;
description description
"An X.509 v3 certificate structure as specified by "The proximity-registrar-sha256-of-subject-public-key-info
RFC 5280, is an alternative to
Section 4 encoded using the ASN.1 distinguished encoding proximity-registrar-subject-public-key-info.
rules (DER), as specified in ITU-T X.690. and pinned-domain-cert. In many cases the
public key of the domain has already been transmitted
during the key agreement protocol, and it is wasteful
to transmit the public key another two times.
The use of a hash of public key info, at 32-bytes for
sha256 is a significant savings compared to an RSA
public key, but is only a minor savings compared to
a 256-bit ECDSA public-key.
Algorithm agility is provided by extensions to this
specifications which define new leaf for other hash
types.";
}
The first certificate in the Registrar TLS server leaf proximity-registrar-cert {
certificate_list sequence (see [RFC5246]) presented by type binary;
the Registrar to the Pledge. This MUST be populated in a description
Pledge's voucher request if the proximity assertion is "An X.509 v3 certificate structure as specified by
populated."; RFC 5280,
} Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690.
leaf prior-signed-voucher-request { The first certificate in the Registrar TLS server
type binary; certificate_list sequence (see [RFC5246]) presented by
description the Registrar to the Pledge. This MUST be populated in a
"If it is necessary to change a voucher, or re-sign and Pledge's voucher request if the proximity assertion is
forward a voucher that was previously provided along a populated.";
protocol path, then the previously signed voucher }
SHOULD be included in this field.
For example, a pledge might sign a proximity voucher, leaf prior-signed-voucher-request {
which an intermediate registrar then re-signs to type binary;
make its own proximity assertion. This is a simple description
mechanism for a chain of trusted parties to change a "If it is necessary to change a voucher, or re-sign and
voucher, while maintaining the prior signature forward a voucher that was previously provided along a
information. protocol path, then the previously signed voucher
SHOULD be included in this field.
The pledge MUST ignore all prior voucher information For example, a pledge might sign a proximity voucher,
when accepting a voucher for imprinting. Other which an intermediate registrar then re-signs to
parties MAY examine the prior signed voucher make its own proximity assertion. This is a simple
information for the purposes of policy decisions. mechanism for a chain of trusted parties to change a
For example this information could be useful to a voucher, while maintaining the prior signature
MASA to determine that both pledge and registrar information.
agree on proximity assertions. The MASA SHOULD
remove all prior-signed-voucher-request information when The pledge MUST ignore all prior voucher information
signing a voucher for imprinting so as to minimize the when accepting a voucher for imprinting. Other
final voucher size."; parties MAY examine the prior signed voucher
} information for the purposes of policy decisions.
} For example this information could be useful to a
} MASA to determine that both pledge and registrar
} agree on proximity assertions. The MASA SHOULD
} remove all prior-signed-voucher-request information when
<CODE ENDS> signing a voucher for imprinting so as to minimize the
final voucher size.";
}
}
}
}
}
<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 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].
{ {
1001051: { 1001154: {
+2 : "2016-10-07T19:31:42Z", / SID= 1001053, created-on / +2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on /
+4 : "2016-10-21T19:31:42Z", / SID= 1001055, expires-on / +4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on /
+1 : 0, / SID= 1001052, assertion / +1 : 2, / SID= 1001155, assertion /
/ "verified" / / "proximity" /
+10: "JADA123456789", / SID= 1001061, serial-number / +13: "JADA123456789", / SID= 1001167, serial-number /
+5 : h'01020D0F', / SID= 1001056, idevid-issuer / +5 : h'01020D0F', / SID= 1001159, idevid-issuer /
+15: h'01020D0F', / SID=1001066, proximity-registrar-cert/ +10: h'01020D0F', / SID=1001064, proximity-registrar-cert/
+3 : true, / SID= 1001054, domain-cert +3 : true, / SID= 1001157, domain-cert
-revocation-checks/ -revocation-checks/
+6 : "2017-10-07T19:31:42Z", / SID= 1001057, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID= 1001160, last-renewal-date /
+9 : h'01020D0F' / SID= 1001060, pinned-domain +12: h'01020D0F' / SID= 1001166, 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.
6.2.1. Tree Diagram 6.2.1. Tree Diagram
The following diagram is largely a duplicate of the contents of The following diagram is largely a duplicate of the contents of
[RFC8366], with only the addition of pinned-domain-subject-public- [RFC8366], with only the addition of pinned-domain-subject-public-
key-info. key-info.
module: ietf-constrained-voucher module: ietf-constrained-voucher
grouping voucher-constrained-grouping grouping voucher-constrained-grouping
+-- voucher +-- voucher
+-- created-on? yang:date-and-time +-- created-on?
+-- expires-on? yang:date-and-time | yang:date-and-time
+-- assertion enumeration +-- expires-on?
+-- serial-number string | yang:date-and-time
+-- idevid-issuer? binary +-- assertion enumeration
+-- pinned-domain-cert? binary +-- serial-number string
+-- domain-cert-revocation-checks? boolean +-- idevid-issuer? binary
+-- nonce? binary +-- pinned-domain-cert? binary
+-- last-renewal-date? yang:date-and-time +-- domain-cert-revocation-checks? boolean
+-- pinned-domain-subject-public-key-info? binary +-- nonce? binary
+-- last-renewal-date?
| yang:date-and-time
+-- pinned-domain-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. Base SID value for voucher request: 1001101.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001115 module ietf-constrained-voucher 1001115 module ietf-constrained-voucher
1001116 module ietf-restconf 1001116 module ietf-restconf
1001117 module ietf-voucher 1001117 module ietf-voucher
skipping to change at page 14, line 13 skipping to change at page 16, line 7
1001114 data .../serial-number 1001114 data .../serial-number
6.2.3. YANG Module 6.2.3. YANG Module
In the constraine-voucher YANG module, the voucher is "augmented" In the constraine-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";
} }
import ietf-voucher { import ietf-voucher {
prefix "v"; prefix "v";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/anima/> "WG Web: <http://tools.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca> <mailto:mcr+ietf@sandelman.ca>
Author: Peter van der Stok Author: Peter van der Stok
<mailto: consultancy@vanderstok.org> <mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis Author: Panos Kampanakis
<mailto: pkampana@cisco.com>"; <mailto: pkampana@cisco.com>";
description description
"This module defines the format for a voucher, which is produced "This module defines the format for a voucher, which is produced
by a pledge's manufacturer or delegate (MASA) to securely assign by a pledge's manufacturer or delegate (MASA) to securely assign
one or more pledges to an 'owner', so that the pledges may one or more pledges to an 'owner', so that the pledges may
establis a secure connection to the owner's network establis a secure connection to the owner's network
infrastructure. infrastructure.
This version provides a very restricted subset appropriate This version provides a very restricted subset appropriate
for very constrained devices. for very constrained devices.
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 "2018-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;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-constrained-grouping { grouping voucher-constrained-grouping {
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { uses v:voucher-artifact-grouping {
refine voucher/created-on { refine voucher/created-on {
mandatory false; mandatory false;
} }
refine voucher/pinned-domain-cert { refine voucher/pinned-domain-cert {
mandatory false; mandatory false;
} }
augment "voucher" { augment "voucher" {
description "Base the constrained voucher description "Base the constrained voucher
upon the regular one"; upon the regular one";
leaf pinned-domain-subject-public-key-info { leaf pinned-domain-subject-public-key-info {
type binary; type binary;
description description
"The pinned-domain-subject-public-key-info replaces the "The pinned-domain-subject-public-key-info replaces the
pinned-domain-cert in constrained uses of pinned-domain-cert in constrained uses of
the voucher. The pinned-domain-subject-public-key-info the voucher. The pinned-domain-subject-public-key-info
is the Raw Public Key of the Registrar. is the Raw Public Key of the Registrar.
This field is encoded as specified in RFC7250,
section 3.
The ECDSA algorithm MUST be supported.
The EdDSA algorithm as specified in
draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
Support for the DSA algorithm is not recommended.
This field is encoded as specified in RFC7250, Support for the RSA algorithm is a MAY.";
section 3. }
The ECDSA algorithm MUST be supported.
The EdDSA algorithm as specified in leaf pinned-sha256-of-subject-public-key-info {
draft-ietf-tls-rfc4492bis-17 SHOULD be supported. type binary;
Support for the DSA algorithm is not recommended. description
Support for the RSA algorithm is a MAY."; "The pinned-hash-subject-public-key-info is a second
} alternative to pinned-domain-cert. In many cases the
} public key of the domain has already been transmitted
} during the key agreement process, and it is wasteful
} to transmit the public key another two times.
} The use of a hash of public key info, at 32-bytes for
<CODE ENDS> sha256 is a significant savings compared to an RSA
public key, but is only a minor savings compared to
a 256-bit ECDSA public-key.
Algorithm agility is provided by extensions to this
specifications which define new leaf for other hash types";
}
}
}
}
}
<CODE ENDS>
6.2.4. Example voucher artifacts 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the the constrained-voucher and Below a the CBOR serialization of the the constrained-voucher is
constrained-voucher-request are shown in diagnostic CBOR notation. shown in diagnostic CBOR notation. The enum value of the assertion
The enum value of the assertion field is calculated to be zero by field is calculated to be zero by following the algorithm described
following the algorithm described in section 9.6.4.2 of [RFC7950]. in section 9.6.4.2 of [RFC7950].
{ {
1001101: { 1001104: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on /
+1 : 0, / SID = 1001102, assertion / +1 : 0, / SID = 1001105, assertion /
/ "verified" / / "verified" /
+12: "JADA123456789", / SID = 1001113, serial-number / +11: "JADA123456789", / SID = 1001115, serial-number /
+5 : h'01020D0F', / SID = 1001106, idevid-issuer / +5 : h'01020D0F', / SID = 1001109, idevid-issuer /
+8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/ +8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/
+3 : true, / SID = 1001104, domain-cert +3 : true, / SID = 1001107, domain-cert
-revocation-checks / -revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID = 1001110, last-renewal-date /
+11: h'01020D0F' / SID = 1001112, proximity +9 : h'01020D0F' / SID = 1001113, pinned-domain
-registrar-subject-public-key-info / -subject-public-key-info /
} }
} }
6.3. CMS format voucher and voucher-request artifacts The signing of the example is shown in Appendix B.1.
6.3. Signing voucher and voucher-request artifacts
6.3.1. CMS signing
The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 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 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
unsigned voucher requests from the pledge to the JRC. In this unsigned voucher requests from the pledge to the JRC. In this
specification, voucher-request artifact is not signed from the pledge specification, voucher-request artifact MUST be signed from the
to the registrar. From the JRC to the MASA, the voucher-request pledge to the registrar. From the JRC to the MASA, the voucher-
artifact MUST be signed by the domain owner key which is requesting request artifact MUST be signed by the domain owner key which is
ownership. requesting ownership.
The considerations of [RFC5652] section 5.1, concerning validating The considerations of [RFC5652] section 5.1, concerning validating
CMS objects which are really PKCS7 objects (cmsVersion=1) applies. CMS objects which are really PKCS7 objects (cmsVersion=1) applies.
The CMS structure SHOULD also contain all the certificates leading up The CMS structure SHOULD also contain all the certificates leading up
to and including the signer's trust anchor certificate known to the to and including the signer's trust anchor certificate known to the
recipient. The inclusion of the trust anchor is unusual in many recipient. The inclusion of the trust anchor is unusual in many
applications, but without it third parties can not accurately audit applications, but without it third parties can not accurately audit
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.
6.3.1. COSE signing [EDnote: compulsory signing algorithms are ....]
The COSE-Sign1 structure discussed in section 4.2 of [RFC8152]. The In Appendix B.1 an example for the CMS signing of the voucher-request
CBOR object that carries the body, the signature, and the information is shown.
about the body and signature is called the COSE_Sign1 structure. It
is used when only one signature is used on the body. The signature
algorithm is ECSDA with three curves P-256, P-384, and P-512.
Support for EdDSA is encouraged. 6.3.2. COSE signing
Unlike with the CMS structure, the COSE-Sign1 structure does not The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152].
provide a standard way for the signing keys to be included in the The CBOR object that carries the body, the signature, and the
structure. This will not, in general, be a problem for the Pledge, information about the body and signature is called the COSE_Sign1
as the key needed to verify the signature MUST be included at structure. It is used when only one signature is used on the body.
manufacturing time. Support for EDdsa 256 with Ed25519 is compulsory.
A problem arises for the Registrar: to verify the voucher, the The supported COSE-sign1 object stucture is shown in Figure 1.
Registrar must have access to the MASA's public key. This document
does not specify how to transfer the relevant key. COSE_Sign1(
[
h'a10126', #{ "alg": EDdsa 256 }
{
"crv": Ed25519,
"kty": OKP,
"key_ops": "verify"
},
h'123', #voucher-request binary content
h'456', #voucher-request binary public signature
]
)
Figure 1: The cose-sign1 structure.
The [COSE-registry] specifies the integers that replace the strings
and the mnemonics in Figure 1. 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 19, line 30 skipping to change at page 22, line 30
namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
name: ietf-constrained-voucher-request name: ietf-constrained-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-constrained namespace: urn:ietf:params:xml:ns:yang:ietf-constrained
-voucher-request -voucher-request
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
9.4. The SMI Security for S/MIME CMS Content Type Registry 9.4. The RFC SID range assignment sub-registry
------------ ------ --------------------------- ------------
Entry-point | Size | Module name | RFC Number
------------ ------ --------------------------- ------------
1001100 50 ietf-constrained-voucher [ThisRFC]
1001150 50 ietf-constrained-voucher [ThisRFC}
-request
----------- ------ --------------------------- ------------
Warning: These SID values will change when they transfer to the range
1000 - 59,999 allocated for SIDs in YANG modules defined in RFCs.
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]
EDNOTE: should a separate value be used for Voucher Requests? EDNOTE: should a separate value be used for Voucher Requests?
9.5. The SID registry
The SID range 1001100 was allocated by comi.space to the IETF-
CONSTRAINED-VOUCHER yang module.
The SID range 1001150 was allocated by comi.space to the IETF-
CONSTRAINED-VOUCHER-REQUEST yang module.
EDNOTE: it is unclear if there is further IANA work required.
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" registry.
These media types are used to indicate that the content is a CBOR These media types are used to indicate that the content is a CBOR
voucher either signed with a cms structure or a COSE_Sign1 structure voucher either signed with a cms structure or a COSE_Sign1 structure
[RFC8152]. [RFC8152].
9.6.1. application/voucher-cms+cbor 9.6.1. application/voucher-cms+cbor
skipping to change at page 22, line 7 skipping to change at page 25, line 7
choices. choices.
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
-04 voucher and request-voucher MUST be signed examples for signed
request are added in appendix IANA SID registration is updated SID
values in examples are aligned signed cms examples aligned with new
SIDs
-03
Examples are inverted.
-02 -02
Example of requestvoucher with unsigned appllication/cbor is added Example of requestvoucher with unsigned appllication/cbor is added
attributes of voucher "refined" to optional attributes of voucher "refined" to optional
CBOR serialization of vouchers improved CBOR serialization of vouchers improved
Discovery port numbers are specified Discovery port numbers are specified
-01 -01
application/json is optional, application/cbor is compulsory application/json is optional, application/cbor is compulsory
skipping to change at page 22, line 31 skipping to change at page 25, line 40
12.1. Normative References 12.1. Normative References
[I-D.ietf-ace-cbor-web-token] [I-D.ietf-ace-cbor-web-token]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
(work in progress), March 2018. (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-10 (work in progress), March 2019. est-12 (work in progress), June 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-19 (work in progress), March 2019. keyinfra-22 (work in progress), June 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. 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-05 (work in iDentifier (SID)", draft-ietf-core-sid-06 (work in
progress), December 2018. progress), March 2019.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
Minaburo, "CBOR Encoding of Data Modeled with YANG", Data Modeled with YANG", draft-ietf-core-yang-cbor-10
draft-ietf-core-yang-cbor-07 (work in progress), September (work in progress), April 2019.
2018.
[ieee802-1AR] [ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/ 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. 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>.
skipping to change at page 24, line 16 skipping to change at page 27, line 20
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>.
[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]
IANA, ., "CBOR Object Signing and Encryption (COSE)
registry", 2017,
<https://www.iana.org/assignments/cose/cose.xhtml>.
[duckling] [duckling]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/ <https://www.cl.cam.ac.uk/~fms27/
papers/1999-StajanoAnd-duckling.pdf>. 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.
skipping to change at page 25, line 9 skipping to change at page 28, line 17
A coaps enrollstatus message can be : A coaps enrollstatus message can be :
GET coaps://[192.0.2.1:8085]/est/es GET coaps://[192.0.2.1:8085]/est/es
The corresponding coap header fields are shown below. The corresponding coap header fields are shown below.
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.01 is GET) Code = 0x01 (0.01 is GET)
Options Options
Option1 (Uri-Host) Option (Uri-Path)
Option Delta = 0x3 (option nr = 3) Option Delta = 0xb (option nr = 11)
Option Length = 0x9 Option Length = 0x3
Option Value = 192.0.2.1 Option Value = "est"
Option2 (Uri-Port) Option (Uri-Path)
Option Delta = 0x4 (option nr = 4+3=7) Option Delta = 0x0 (option nr = 11)
Option Length = 0x4 Option Length = 0x2
Option Value = 8085 Option Value = "es"
Option3 (Uri-Path)
Option Delta = 0x4 (option nr = 7+4= 11)
Option Length = 0x7
Option Value = /est/es
Payload = [Empty] Payload = [Empty]
A 2.05 Content response with an unsigned JSON voucher (ct=50) will The Uri-Host and Uri-Port Options are omitted because they coincide
with the transport protocol destination address and port
respectively.
A 2.05 Content response with an unsigned voucher status (ct=60) will
then be: then be:
2.05 Content (Content-Format: application/json) 2.05 Content (Content-Format: application/cbor)
{payload}
With CoAP fields and payload: With CoAP fields and payload:
Ver=1 Ver=1
T=2 (ACK) T=2 (ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Options Options
Option1 (Content-Format) Option1 (Content-Format)
Option Delta = 0xC (option nr 12) Option Delta = 0xC (option nr 12)
Option Length = 0x2 Option Length = 0x2
Option Value = 0x32 (application/json) Option Value = 60 (application/cbor)
Payload = Payload (CBOR diagnostic) =
[EDNOTE: put here voucher payload ] {
"version":"1",
"Status": 1, / 1 = Success, 0 = Fail /
"Reason":"Informative human readable message",
"reason-context": "Additional information"
}
A.2. voucher_status Payload (binary) =
A46776657273696F6E6131665374617475730166526561736F6E7822
496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E
~~~
##voucher_status
A coaps voucher_status message can be : A coaps voucher_status message can be :
GET coaps://[2001:db8::2:1]:61616]/est/vs GET coaps://[2001:db8::2:1]:61616]/est/vs ~~~~
A 2.05 Content response with a non signed CBOR voucher (ct=60) will A 2.05 Content response with a non signed CBOR voucher (ct=60) will
then be: then be:
2.05 Content (Content-Format: application/cbor) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
[EDNOTE: put here voucher payload ] A46776657273696F6E6131665374617475730166526561736F6E7822
496E666F726D61746976652068756D616E207265616461626C65206D
6573736167656e726561736F6E2D636F6E74657874
764164646974696F6E616C20696E666F726D6174696F6E
A.3. requestvoucher A.2. requestvoucher
Two request-voucher request payloads are possible from pledge to Signed request-voucher-request payloads are sent from pledge to
Registrar, a signed one and an unsigned one, as explained in Registrar, as explained in Section 5.2 of
Section 5.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
A.3.1. signed requestvoucher A.2.1. signed requestvoucher
A coaps signed requestvoucher message from RA to MASA can be : A CMS signed requestvoucher message from JRC to MASA is shown below.
It would be CoAP POSTED to /est/rv.
POST coaps://[2001:db8::2:1]:61616]/est/rv POST coaps://[2001:db8::2:1]:61616]/est/rv
(Content-Format: application/voucher-cms+cbor)
The payload would be in binary, but is presented in base64 in this
document.
MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ
KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49
BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh
bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw
Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx
CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV
BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz
NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ
TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl
n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3
rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P
AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7
CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9
ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK
3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD
QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp
b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC
AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ
XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/
n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh
MEgF10vqXv02gL1jLw==
A 2.04 Changed response returning CBOR voucher signed with a cms A 2.04 Changed response returning CBOR voucher signed with a cms
structure(ct=TBD2) will then be: structure(ct=TBD2) will then be:
2.04 Changed (Content-Format: application/voucher-cms+cbor) 2.04 Changed (Content-Format: application/voucher-cms+cbor)
Payload =
[EDNOTE: put here encrypted voucher payload ]
A.3.2. unsigned requestvoucher MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ
KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49
BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh
bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw
Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx
CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV
BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz
NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ
TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl
n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3
rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P
AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7
CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9
ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK
3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD
QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp
b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC
AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he
uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG
kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX
hlG/g+OgTUftYMJ32so=
A coaps unsigned requestvoucher message from pledge to Registrar can A.3. requestauditing
be :
POST coaps://[2001:db8::2:1]:61616]/est/rv A coaps requestauditing message contains the signed CBOR voucher :
A 2.04 Changed response returning CBOR voucher (ct=60) will then be: POST coaps://[2001:db8::2:1]:61616]/est/ra
(Content-Format: application/voucher-cms+cbor)
Payload =
308203ba06092a864886f70d010702a08203ab308203a7020101310d300b
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
2.04 Changed (Content-Format: application/cbor) A 2.05 Content response returning a log of the voucher (ct=60) will
then be:
2.05 Content (Content-Format: application/cbor)
Payload = Payload =
[EDNOTE: put here encrypted voucher payload ] {
"version":"1",
"events":[
{
"date":"<date/time of the entry>",
"domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>"
"truncated":"<the number of domainID entries truncated>"
},
{
"date":"<date/time of the entry>",
"domainID":"<anotherDomainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>"
}
],
"truncation": {
"nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": "<total number of entries truncated>",
"arbitrary": "<number of domainID entries removed entirely>"
}
}
A.4. requestauditing [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary]
A coaps requestauditing message can be : Appendix B. Signed voucher-request examples
GET coaps://[2001:db8::2:1]:61616]/est/ra B.1. CMS signed voucher-request example
A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will The voucher-request example, visualized in CBOR diagnostic notation
then be: in Section 6.1.4 is shown as a hexadecimal dump of the binary file.
2.05 Content (Content-Format: application/voucher-cose+cbor) A11A000F46C2A90274323031362D31302D30375431393A33313A34325A0
Payload = 474323031362D31302D32315431393A33313A34325A01020d6d4A414441
[EDNOTE: put here COSE_Sign1 voucher payload ] 313233343536373839054401020D0F0A4401020D0F03F50674323031372
D31302D30375431393A33313A34325A0c4401020D0F
The voucher-request example has been signed by using the WT1234
certificate and key pair shown in Appendix C of
[I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher-
request leads to a binary signed voucher-request, shown with a
hexadecimal representation shown in the payload of the request part
of Appendix A.2.1 and Appendix A.3.
The breakdown of the CMS signed binary voucher-request file is
visualized below:
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent: <ABSENT>
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 9112578475118446130
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA
validity:
notBefore: Jan 31 11:29:16 2019 GMT
notAfter: Dec 31 23:59:59 9999 GMT
subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf
000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15
001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df
002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8
0038 - 16 a2 b2 3b 56 38 e5 9f-d9
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Basic Constraints (2.5.29.19)
critical: BOOL ABSENT
value:
0000 - 30
0002 - <SPACES/NULS>
object: X509v3 Subject Key Identifier (2.5.29.14)
critical: BOOL ABSENT
value:
0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0
000d - ac 76 07 77 ad 66 5d 02-a0
object: X509v3 Authority Key Identifier (2.5.29.35)
critical: BOOL ABSENT
value:
0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a
000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60
object: X509v3 Key Usage (2.5.29.15)
critical: TRUE
value:
0000 - 03 02 05 a0
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: BOOL ABSENT
value:
0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08
000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4
001a - 3b 0a 01 04 04 01 02 03-04
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c
000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17
001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c
002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20
003c - f1 50 64 21 18 8a 0a de-6d 34 92 36
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: C=US, ST=CA, O=Example Inc, OU=certification,
CN=802.1AR CA
serialNumber: 9112578475118446130
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Jul 3 08:53:30 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d
000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f
001a - 0b 4f 44 9e 25
0020 - <SPACES/NULS>
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64
000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf
001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4
002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af
003c - 2b 59 16 cc 36 63 e7 91-89 39 df df
unsignedAttrs:
<EMPTY>
Appendix C. COSE examples
C.1. Device, Registrar and MASA keys
This first section documents the public and private keys used in the
subsequent test vectors below. These keys come from test code and
are not used in any production system, and should only be used only
to validate implementations.
C.1.1. Device IDevID certificate
Certificate:
Data:
Version: 3 (0x2)
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
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
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49
AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI
YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw==
-----END EC PRIVATE KEY-----
C.1.3. Registrar Certificate
-----BEGIN CERTIFICATE-----
MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xQDA+BgNVBAMMNyM8U3lzdGVt
VmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4gVW5zdHJ1bmcgRm91bnRhaW4gQ0Ew
HhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQB
GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2Fs
aG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lI
noEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqj
DTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQ
XHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKi
IiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ==
-----END CERTIFICATE-----
C.1.4. Registrar private key
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49
AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E
jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg==
-----END EC PRIVATE KEY-----
C.1.5. MASA Certificate
-----BEGIN CERTIFICATE-----
MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX
DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh
cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l
eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5
4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf
WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA
vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6
AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP
D0jJ
-----END CERTIFICATE-----
C.1.6. MASA private key
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49
AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+
gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ==
-----END EC PRIVATE KEY-----
C.2. COSE signed requestvoucher with registrar certificate pinned
This voucher request has been signed by the pledge, using the private
key given above, and has been sent 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:
18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5
D1E49970A5130302D44302D45352D46322D30302D303307765F715674477
738565342626C65394D34557036354C770C5901D4308201D030820157A00
30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0
992268993F22C6401191602636131193017060A0992268993F22C6401191
60973616E64656C6D616E313D303B06035504030C34666F756E7461696E2
D746573742E6578616D706C652E636F6D0A20556E737472756E6720466F7
56E7461696E20526F6F74204341301E170D3139303431363138353431315
A170D3139303531373034353431315A305331123010060A0992268993F22
C6401191602636131193017060A0992268993F22C640119160973616E646
56C6D616E3122302006035504030C19666F756E7461696E2D746573742E6
578616D706C652E636F6D3059301306072A8648CE3D020106082A8648CE3
D030107034200049665507234BA9FE5DDE65FF6F0816FE9489E810C12073
B468F97642B63008D020F57C97C947F848CB20E61D6C9888D15B4421FD7F
26AB7E4CE05F8A74CD38B3A300A06082A8648CE3D0403020367003064023
0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3
A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59
0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756
B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F
ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36
777FD7DBAE22B8CEB07D51D8F55AD3'])
This is the raw binary, encoded in base64:
0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G
Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD
AgECAgQijs0nMAoGCCqGSM49BAMCMG4xEjAQBgoJkiaJk/IsZAEZFgJjYTEZ
MBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE9MDsGA1UEAww0Zm91bnRhaW4t
dGVzdC5leGFtcGxlLmNvbQogVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe
Fw0xOTA0MTYxODU0MTFaFw0xOTA1MTcwNDU0MTFaMFMxEjAQBgoJkiaJk/Is
ZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZ
Zm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/
hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizowCgYIKoZIzj0EAwIDZwAwZAIw
NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph
9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr
Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et
Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM=
C.3. COSE signed parboiled requestvoucher
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
pledge voucher request above.
This is the CBOR diagnostic format, folded to 60 characters:
18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5
9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477
738565342626C65394D34557036354C770B590266D28441A0A059021CA11
A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443
02D45352D46322D30302D303307765F715674477738565342626C65394D3
4557036354C770C5901D4308201D030820157A0030201020204228ECD273
00A06082A8648CE3D040302306E31123010060A0992268993F22C6401191
602636131193017060A0992268993F22C640119160973616E64656C6D616
E313D303B06035504030C34666F756E7461696E2D746573742E6578616D7
06C652E636F6D0A20556E737472756E6720466F756E7461696E20526F6F7
4204341301E170D3139303431363138353431315A170D313930353137303
4353431315A305331123010060A0992268993F22C6401191602636131193
017060A0992268993F22C640119160973616E64656C6D616E31223020060
35504030C19666F756E7461696E2D746573742E6578616D706C652E636F6
D3059301306072A8648CE3D020106082A8648CE3D0301070342000496655
07234BA9FE5DDE65FF6F0816FE9489E810C12073B468F97642B63008D020
F57C97C947F848CB20E61D6C9888D15B4421FD7F26AB7E4CE05F8A74CD38
B3A300A06082A8648CE3D04030203670030640230340F4E6D0F9F702553F
A53BE572ACF0EED858275B6AC75994332FB25FB3A54411E9FA02E6F75FD1
AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5
E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584
096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62
733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5
1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551
CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D
0EDE18EB1008EF7E9A279C'])
This is the raw binary, encoded in base64:
0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G
Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa
AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf
cVZ0R3c4VlNCYmxlOU00VXA2NUx3DFkB1DCCAdAwggFXoAMCAQICBCKOzScw
CgYIKoZIzj0EAwIwbjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPy
LGQBGRYJc2FuZGVsbWFuMT0wOwYDVQQDDDRmb3VudGFpbi10ZXN0LmV4YW1w
bGUuY29tCiBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTE5MDQxNjE4
NTQxMVoXDTE5MDUxNzA0NTQxMVowUzESMBAGCgmSJomT8ixkARkWAmNhMRkw
FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYDVQQDDBlmb3VudGFpbi10
ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAElmVQ
cjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0V
tEIf1/Jqt+TOBfinTNOLOjAKBggqhkjOPQQDAgNnADBkAjA0D05tD59wJVP6
U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI
8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA
lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7
DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO
VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA==
C.4. COSE signed voucher
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
and can be verified by the pledge using the MASA's publie key.
This is the CBOR diagnostic format, folded to 60 characters:
18([h'A0', {}, h'A11A000F468CA505666C6F6767656406C11A5D1E499
A0E7130302D44302D45352D46322D30302D30330B765F715674477738565
342626C65394D34557036354C770C7902744D49494230544343415661674
177494241674942416A414B42676771686B6A4F50515144417A42784D524
9774541594B435A496D695A50794C4751424752594359324578475441584
2676F4A6B69614A6B2F49735A41455A46676C7A5957356B5A57787459573
4785144412B42674E5642414D4D4E794D3855336C7A64475674566D46796
1574669624755364D4867774D4441774D4441774E4759354D5446684D443
4675657357A64484A31626D6367526D3931626E526861573467513045774
868634E4D5463784D5441334D6A4D304E5449345768634E4D546B784D544
1334D6A4D304E544934576A42444D5249774541594B435A496D695A50794
C47514247525943593245784754415842676F4A6B69614A6B2F49735A414
55A46676C7A5957356B5A57787459573478456A415142674E5642414D4D4
3577876593246736147397A6444425A4D424D4742797147534D343941674
54743437147534D34394177454841304941424A5A6C5548493075702F6C3
3655A6639764342622B6C496E6F454D45676337526F2B585A43746A41493
0434431664A664A522F68497979446D48577959694E46625243483966796
172666B7A67583470307A54697A716A4454414C4D416B474131556445775
1434D414177436759494B6F5A497A6A304541774D44615141775A6749784
14C514D4E75726638747635306C524F443544515848454F4A4A4E5733515
632673951456444536B324D592B416F537242536D47534E6A68346F6C454
F6845754C674978414A346E57664E772B426A625A6D4B694969554563547
7484D68475658614D48592F46376E333977774B634242534F6E644E50714
3704F454C6C36627133435A71513D3D', h'7468FB16A4035FDAF510DBF5
A88F67B6FB849CFBA8B094B77AD5248900E4BCD6E892FE74B39AB787637B
121944BED4D1CB4B8DC8F59212EAC2AD20469C71C1F6'])
This is the raw binary, encoded in base64:
0oRBoKBZArmhGgAPRoylBWZsb2dnZWQGwRpdHkmaDnEwMC1EMC1FNS1GMi0w
MC0wMwt2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwx5AnRNSUlCMFRDQ0FWYWdB
d0lCQWdJQkFqQUtCZ2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxH
UUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0
eFFEQStCZ05WQkFNTU55TThVM2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3
TURBd05HWTVNVEZoTUQ0Z1ZXNXpkSEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdI
aGNOTVRjeE1UQTNNak0wTlRJNFdoY05NVGt4TVRBM01qTTBOVEk0V2pCRE1S
SXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFF
WkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREJa
TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz
ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt
SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR
Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP
RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP
aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z
OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo
j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt
IEacccH2
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. 105 change blocks. 
412 lines changed or deleted 1021 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/