draft-ietf-anima-constrained-voucher-00.txt   draft-ietf-anima-constrained-voucher-01.txt 
6tisch Working Group M. Richardson anima Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Informational P. van der Stok Intended status: Standards Track P. van der Stok
Expires: November 24, 2018 vanderstok consultancy Expires: March 1, 2019 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
May 23, 2018 August 28, 2018
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-00 draft-ietf-anima-constrained-voucher-01
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 35 skipping to change at page 1, line 35
transported in the [I-D.ietf-ace-coap-est] protocol. transported in 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 http://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 November 24, 2018. This Internet-Draft will expire on March 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 4 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 4
6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 6 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 6
6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 6 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 6
6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 7 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 7 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 7
6.1.4. Example voucher request artifacts . . . . . . . . . . 9 6.1.4. Example voucher request artifacts . . . . . . . . . . 10
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 9 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 11
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 9 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 11
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 10 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 11
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 12 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 13
6.3. Signing of voucher and voucher-request artifacts . . . . 12 6.3. CMS format voucher and voucher-request artifacts . . . . 14
6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 15
6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 13 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 16
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 14 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 14 8.3. Test Domain Certificate Validity when Signing . . . . . . 16
8.3. Test Domain Certificate Validity when Signing . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 16
9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 14 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 17
9.3. The SMI Security for S/MIME CMS Content Type Registry . . 15 9.4. The SMI Security for S/MIME CMS Content Type Registry . . 17
9.4. The SID registry . . . . . . . . . . . . . . . . . . . . 15 9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 17
9.5. Media-Type Registry . . . . . . . . . . . . . . . . . . . 15 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 18
9.5.1. application/voucher-cms+cbor . . . . . . . . . . . . 15 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 18
9.5.2. application/voucher-cose+cbor . . . . . . . . . . . . 16 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 18
9.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 17 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 20 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 22
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 20 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 22
A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 21 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 23
A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 22 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 23
A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 22 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 4, line 47 skipping to change at page 4, line 47
This document defines both a constrained voucher and a constrained This document defines both a constrained voucher and a constrained
voucher-request. They are presented in the order voucher-request, voucher-request. They are presented in the order voucher-request,
followed by voucher response as this is the time order that they followed by voucher response as this is the time order that they
occur. occur.
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. proxy and pledge over CoAP. The extensions are targeted to low-
resource networks with small packets. Saving header space is
The extension is targeted to low-resource networks with small important and the EST-coaps URI is shorter than the EST URI.
packets. Saving header space is important and the EST-coaps URI is
shorter than the EST URI.
The presence and location of (path to) the management data are The presence and location of (path to) the management data are
discovered by sending a GET request to "/.well-known/core" including discovered by sending a GET request to "/.well-known/core" including
a resource type (RT) parameter with the value "ace.est" [RFC6690]. a resource type (RT) parameter with the value "ace.est" [RFC6690].
Upon success, the return payload will contain the root resource of Upon success, the return payload will contain the root resource of
the EST resources. It is up to the implementation to choose its root the EST resources. It is up to the implementation to choose its root
resource; throughout this document the example root resource /est is resource; throughout this document the example root resource /est is
used. used. The example below shows the discovery of the presence and
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 5, line 42 skipping to change at page 5, line 45
+------------------+-----------+ +------------------+-----------+
Table 1: BRSKI path to EST-coaps path Table 1: BRSKI path to EST-coaps path
/requestvoucher and /enrollstatus are needed between pledge and /requestvoucher and /enrollstatus are needed between pledge and
Registrar. Registrar.
When discovering the root path for the EST resources, the server MAY When discovering the root path for the EST resources, the server MAY
return the full resource paths and the used content types. This is return the full resource paths and the used content types. This is
useful when multiple content types are specified for EST-coaps useful when multiple content types are specified for EST-coaps
server. The example below shows the discovery of the presence and server. For example, the following more complete response is
the location of voucher resources. 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>; ct=50 TBD2 TBD3 16 </est/rv>; rt="ace.est/rv";ct=50 60 TBD2 TBD3 16
</est/vs>; ct=50 </est/vs>; rt="ace.est/vs";ct=50 60
</est/es>; ct=50 </est/es>; rt="ace.est/es";ct=50 60
</est/ra>; ct=TBD2 TBD3 16 </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3 16
The first line MUST be returned in response to the GET, The following The first line MUST be returned in response to the GET, The following
four lines MAY be returned to show the supported Content-Formats. 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.
ct=50 stands for the Content-Format "application/json", ct=16 stands ct=16 stands for the Content-Format "application/cose", and ct=TBD2
for the Content-Format "application/cose; cose-type="cose-encrypt0", stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3
ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, stands for Content-Format "application/voucher-cose+cbor".
ct=TBD3 stands for Content-Format "application/voucher-cose+cbor;
cose-type="cose-sign1. The latter two are defined in this document. Content-Formats TBD2 and TBD3 are defined in this document. The
return of the content-formts allows the client to choose the most
appropriate one from multiple content formats.
The Content-Format ("application/json") 50 MAY be supported.
Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be
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-yang-cbor], with an allocation that
was made via the http://comi.space service. was made via the http://comi.space service.
((EDNOTE: it is unclear if there is further IANA work)) ((EDNOTE: it is unclear if there is further IANA work))
6.1. Voucher Request artifact 6.1. Voucher Request artifact
6.1.1. Tree Diagram 6.1.1. Tree Diagram
module: ietf-cwt-voucher-request The following diagram is largely a duplicate of the contents of
[RFC8366], with the addition of proximity-registrar-subject-public-
key-info, proximity-registrar-cert, and prior-signed-voucher-request.
grouping voucher-request-cwt-grouping prior-signed-voucher-request is only used between the Registrar and
the MASA. proximity-registrar-subject-public-key-info replaces
proximity-registrar-cert for the extremely constrained cases.
module: ietf-constrained-voucher-request
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 +---- assertion
| enumeration | enumeration
+---- serial-number string +---- serial-number string
+---- idevid-issuer? binary +---- idevid-issuer? binary
+---- pinned-domain-cert binary +---- pinned-domain-cert binary
+---- domain-cert-revocation-checks? boolean +---- domain-cert-revocation-checks? boolean
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? +---- last-renewal-date?
| yang:date-and-time | yang:date-and-time
+---- proximity-registrar-subject-public-key-info? binary +---- proximity-registrar-subject-public-key-info? binary
+---- proximity-registrar-cert? binary
+---- prior-signed-voucher-request? binary
6.1.2. SID values 6.1.2. SID values
SID Assigned to [[EDNOTE - to be fixed ]]
--------- --------------------------------------------------
1001150 module ietf-cwt-voucher-request
1001151 module ietf-restconf
1001152 module ietf-voucher
1001153 module ietf-yang-types
1001154 data .../ietf-cwt-voucher-request:voucher
1001155 data .../assertion
1001156 data .../created-on
1001157 data .../domain-cert-revocation-checks
1001158 data .../expires-on
1001159 data .../idevid-issuer
1001160 data .../last-renewal-date
1001161 data .../nonce
1001162 data .../pinned-domain-cert
1001163 data .../proximity-registrar-subject-public-key-info
1001164 data .../serial-number
6.1.3. YANG Module 6.1.3. YANG Module
In the cwt-voucher-request YANG module, the voucher is "used" and not In the constrained-voucher-request YANG module, the voucher is "used"
"augmented" such that one continuous set of SID values is generated and not "augmented" such that one continuous set of SID values is
for the cwt-voucher-request module name, all voucher attributes, and generated for the constrained-voucher-request module name, all
the cwt-voucher-request attribute. voucher attributes, and the constrained-voucher-request attribute.
<CODE BEGINS> file "ietf-cwt-voucher-request@2018-02-07.yang" <CODE BEGINS> file "ietf-constrained-voucher-request@2018-09-01.yang"
/* -*- c -*- */ module ietf-constrained-voucher-request {
module ietf-cwt-voucher-request { yang-version 1.1;
yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request";
prefix "vcwt"; prefix "constrained";
import ietf-voucher { import ietf-restconf {
prefix "v"; prefix rc;
} description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
organization import ietf-voucher {
"IETF 6tisch Working Group"; prefix "v";
}
contact organization
"WG Web: <http://tools.ietf.org/wg/6tisch/> "IETF ANIMA Working Group";
WG List: <mailto:6tisch@ietf.org>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
description contact
"This module defines the format for a voucher, which is produced by "WG Web: <http://tools.ietf.org/wg/anima/>
a pledge's manufacturer or delegate (MASA) to securely assign one WG List: <mailto:anima@ietf.org>
or more pledges to an 'owner', so that the pledges may establish a Author: Michael Richardson
secure connection to the owner's network infrastructure. <mailto:mcr+ietf@sandelman.ca>
Author: Peter van der Stok
<mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis
<mailto: pkampana@cisco.com>";
description
"This module defines the format for a voucher request,
which is produced by a pledge to request a voucher.
The voucher-request is sent to the potential owner's
Registrar, which in turn sends the voucher request to
the manufacturer or delegate (MASA).
This version provides a very restricted subset appropriate A voucher is then returned to the pledge, binding the
for very constrained devices. pledge to the owner. This is a constrained version of the
In particular, it assumes that nonce-ful operation is voucher-request present in
always required, that expiration dates are rather weak, as no draft-ietf-anima-bootstrap-keyinfra.txt.
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', This version provides a very restricted subset appropriate
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in for very constrained devices.
the module text are to be interpreted as described in RFC 2119."; In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
revision "2018-02-07" { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
"Initial version"; and 'OPTIONAL' in the module text are to be interpreted as
reference described in RFC 2119.";
"RFC XXXX: Voucher Profile for Constrained Devices";
}
// Grouping defined for future usage revision "2018-09-01" {
grouping voucher-request-cwt-grouping { description
description "Initial version";
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { reference
augment "voucher" { "RFC XXXX: Voucher Profile for Constrained Devices";
description "Base the CWT voucher-request upon the regular one"; }
leaf proximity-registrar-subject-public-key-info {
type binary;
description
"The proximity-registrar-subject-public-key-info replaces
the proximit-registrar-cert in constrained uses of
the voucher-request.
The proximity-registrar-subject-public-key-info 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.
Support for the RSA algorithm is a MAY.";
} rc:yang-data voucher-request-constrained-artifact {
} // YANG data template for a voucher.
} uses voucher-request-constrained-grouping;
} }
}
<CODE ENDS> // Grouping defined for future usage
grouping voucher-request-constrained-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping {
augment "voucher" {
description "Base the constrained voucher-request upon the
regular one";
leaf proximity-registrar-subject-public-key-info {
type binary;
description
"The proximity-registrar-subject-public-key-info replaces
the proximit-registrar-cert in constrained uses of
the voucher-request.
The proximity-registrar-subject-public-key-info 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.
Support for the RSA algorithm is a MAY.";
}
leaf proximity-registrar-cert {
type binary;
description
"An X.509 v3 certificate structure as specified by
RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690.
The first certificate in the Registrar TLS server
certificate_list sequence (see [RFC5246]) presented by
the Registrar to the Pledge. This MUST be populated in a
Pledge's voucher request if the proximity assertion is
populated.";
}
leaf prior-signed-voucher-request {
type binary;
description
"If it is necessary to change a voucher, or re-sign and
forward a voucher that was previously provided along a
protocol path, then the previously signed voucher
SHOULD be included in this field.
For example, a pledge might sign a proximity voucher,
which an intermediate registrar then re-signs to
make its own proximity assertion. This is a simple
mechanism for a chain of trusted parties to change a
voucher, while maintaining the prior signature
information.
The pledge MUST ignore all prior voucher information
when accepting a voucher for imprinting. Other
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
signing a voucher for imprinting so as to minimize the
final voucher size.";
}
}
}
}
}
<CODE ENDS>
6.1.4. Example voucher request artifacts 6.1.4. Example voucher request artifacts
TBD TBD
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
module: ietf-cwt-voucher The following diagram is largely a duplicate of the contents of
[RFC8366], with only the addition of pinned-domain-subject-public-
key-info.
grouping voucher-cwt-grouping module: ietf-constrained-voucher
grouping voucher-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 enumeration
+---- serial-number string +---- serial-number string
+---- idevid-issuer? binary +---- idevid-issuer? binary
+---- pinned-domain-cert binary +---- pinned-domain-cert binary
+---- domain-cert-revocation-checks? boolean +---- domain-cert-revocation-checks? boolean
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? +---- last-renewal-date?
| yang:date-and-time | yang:date-and-time
+---- pinned-domain-subject-public-key-info? binary +---- pinned-domain-subject-public-key-info? binary
6.2.2. SID values 6.2.2. SID values
SID Assigned to
--------- --------------------------------------------------
1001100 module ietf-cwt-voucher
1001101 module ietf-restconf
1001102 module ietf-voucher
1001103 module ietf-yang-types
1001104 data .../ietf-cwt-voucher:voucher
1001105 data .../assertion
1001106 data .../created-on
1001107 data .../domain-cert-revocation-checks
1001108 data .../expires-on
1001109 data .../idevid-issuer
1001110 data .../last-renewal-date
1001111 data .../nonce
1001112 data .../pinned-domain-cert
1001113 data .../pinned-domain-subject-public-key-info
1001114 data .../serial-number
6.2.3. YANG Module 6.2.3. YANG Module
In the cwt-voucher YANG module, the voucher is "used" and not In the constraine-voucher YANG module, the voucher is "used" and not
"augmented" such that one continuous set of SID values is generated "augmented" such that one continuous set of SID values is generated
for the cwt-voucher module name, all voucher attributes, and the cwt- for the constrained-voucher module name, all voucher attributes, and
voucher attribute. the constrained-voucher attribute.
<CODE BEGINS> file "ietf-cwt-voucher@2018-02-07.yang" <CODE BEGINS> file "ietf-constrained-voucher@2018-09-01.yang"
/* -*- c -*- */ module ietf-constrained-voucher {
module ietf-cwt-voucher { yang-version 1.1;
yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-cwt-voucher"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher";
prefix "vcwt"; prefix "constrained";
import ietf-voucher { import ietf-restconf {
prefix "v"; prefix rc;
} description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
organization }
"IETF 6tisch Working Group";
contact import ietf-voucher {
"WG Web: <http://tools.ietf.org/wg/6tisch/> prefix "v";
WG List: <mailto:6tisch@ietf.org> }
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
description organization
"This module defines the format for a voucher, which is produced by "IETF ANIMA Working Group";
a pledge's manufacturer or delegate (MASA) to securely assign one
or more pledges to an 'owner', so that the pledges may establish a
secure connection to the owner's network infrastructure.
This version provides a very restricted subset appropriate contact
for very constrained devices. "WG Web: <http://tools.ietf.org/wg/anima/>
In particular, it assumes that nonce-ful operation is WG List: <mailto:anima@ietf.org>
always required, that expiration dates are rather weak, as no Author: Michael Richardson
clocks can be assumed, and that the Registrar is identified <mailto:mcr+ietf@sandelman.ca>
by a pinned Raw Public Key. Author: Peter van der Stok
<mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis
<mailto: pkampana@cisco.com>";
description
"This module defines the format for a voucher, which is produced
by a pledge's manufacturer or delegate (MASA) to securely assign
one or more pledges to an 'owner', so that the pledges may
establis a secure connection to the owner's network
infrastructure.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', This version provides a very restricted subset appropriate
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in for very constrained devices.
the module text are to be interpreted as described in RFC 2119."; In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
revision "2018-02-07" { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
"Initial version"; and 'OPTIONAL' in the module text are to be interpreted as
reference described in RFC 2119.";
"RFC XXXX: Voucher Profile for Constrained Devices";
}
// Grouping defined for future usage revision "2018-09-01" {
grouping voucher-cwt-grouping { description
description "Initial version";
"Grouping to allow reuse/extensions in future work."; reference
"RFC XXXX: Voucher Profile for Constrained Devices";
}
uses v:voucher-artifact-grouping { rc:yang-data voucher-constrained-artifact {
augment "voucher" { // YANG data template for a voucher.
description "Base the CWT voucher upon the regular one"; uses voucher-constrained-grouping;
leaf pinned-domain-subject-public-key-info { }
type binary; // Grouping defined for future usage
description grouping voucher-constrained-grouping {
"The pinned-domain-subject replaces the description
pinned-domain-certificate in constrained uses of "Grouping to allow reuse/extensions in future work.";
the voucher. The pinned-domain-public-key-info 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.
Support for the RSA algorithm is a MAY.";
}
}
}
}
} uses v:voucher-artifact-grouping {
<CODE ENDS> augment "voucher" {
description "Base the constrained voucher upon the regular one";
leaf pinned-domain-subject-public-key-info {
type binary;
description
"The pinned-domain-subject replaces the
pinned-domain-certificate in constrained uses of
the voucher. The pinned-domain-subject-public-key-info
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.
Support for the RSA algorithm is a MAY.";
}
}
}
}
}
<CODE ENDS>
6.2.4. Example voucher artifacts 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the the cwt-voucher and cwt- Below a the CBOR serialization of the the constrained-voucher and
voucher-request are shown in diagnostic CBOR notation. constrained-voucher-request are shown in diagnostic CBOR notation.
6.2.4.1. CBOR serialization of cwt-voucher
{ 6.2.4.1. CBOR serialization of constrained-voucher
1001051: { {
+2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on / 1001051: {
+4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on /
+1 : "verified", / SID = 1001052, assertion / +4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on /
+11: "JADA123456789", / SID = 1001062, serial-number / +1 : "verified", / SID = 1001052, assertion /
+5 : h'01020D0F', / SID = 1001056, idevid-issuer / +11: "JADA123456789", / SID = 1001062, serial-number /
+8 : h'01020D0F', / SID = 1001059, pinned-domain-cert / +5 : h'01020D0F', / SID = 1001056, idevid-issuer /
+3 : true, / SID = 1001054, domain-cert-revocation-checks / +8 : h'01020D0F', / SID = 1001059, pinned-domain-cert/
+6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date / +3 : true, / SID = 1001054, domain-cert
+9 : h'01020D0F' / SID = 1001060, pinned-domain-subject-public-key-info / -revocation-checks/
} +6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date /
} +9 : h'01020D0F' / SID = 1001060, pinned-domain
-subject-public-key-info /
}
}
6.2.4.2. CBOR serialization of cwt-voucher-request 6.2.4.2. CBOR serialization of constrained-voucher-request
{ {
1001101: { 1001101: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on /
+1 : "verified", / SID = 1001102, assertion / +1 : "verified", / SID = 1001102, assertion /
+11: "JADA123456789", / SID = 1001112, serial-number / +11: "JADA123456789", / SID = 1001112, serial-number /
+5 : h'01020D0F', / SID = 1001106, idevid-issuer / +5 : h'01020D0F', / SID = 1001106, idevid-issuer /
+8 : h'01020D0F', / SID = 1001109, pinned-domain-cert / +8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/
+3 : true, / SID = 1001104, domain-cert-revocation-checks / +3 : true, / SID = 1001104, domain-cert
+6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date / -revocation-checks /
+10: h'01020D0F' / SID = 1001111, proximity-registrar-subject-public-key-info / +6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date /
} +10: h'01020D0F' / SID = 1001111, proximity
} -registrar-subject-public-key-info /
}
}
6.3. Signing of voucher and voucher-request artifacts 6.3. CMS format voucher and voucher-request artifacts
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
skipping to change at page 13, line 20 skipping to change at page 15, line 14
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 is not signed from the pledge
to the registrar. From the JRC to the MASA, the voucher-request to the registrar. From the JRC to the MASA, the voucher-request
artifact MUST be signed by the domain owner key which is requesting artifact MUST be signed by the domain owner key which is requesting
ownership. ownership.
6.3.1. CMS signing
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.2. COSE signing 6.3.1. COSE signing
The COSE-Sign1 structure discussed in section 4.2 of [RFC8152]. The The COSE-Sign1 structure discussed in section 4.2 of [RFC8152]. The
CBOR object that carries the body, the signature, and the information CBOR object that carries the body, the signature, and the information
about the body and signature is called the COSE_Sign1 structure. It 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 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. algorithm is ECSDA with three curves P-256, P-384, and P-512.
Support for EdDSA is encouraged Support for EdDSA is encouraged.
Unlike with the CMS structure, the COSE-Sign1 structure does not
provide a standard way for the signing keys to be included in the
structure. This will not, in general, be a problem for the Pledge,
as it the key needed to verify the signature MUST be included at
manufacturing time.
A problem arises for the Registrar, in order for it to verify the
voucher, it must have access to the MASA's public key. This document
does not specify how to transfer the relevant key.
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 14, line 30 skipping to change at page 16, line 30
8.2. Protect Voucher PKI in HSM 8.2. Protect Voucher PKI in HSM
TBD. TBD.
8.3. Test Domain Certificate Validity when Signing 8.3. Test Domain Certificate Validity when Signing
TBD. TBD.
9. IANA Considerations 9. IANA Considerations
9.1. The IETF XML Registry 9.1. Resource Type Registry
Additions to the sub-registry "CoAP Resource Type", within the "CoRE
parameters" registry are specified below. These can be registered
either in the Expert Review range (0-255) or IETF Review range
(256-9999).
ace.rt.rv needs registration with IANA
ace.rt.vs needs registration with IANA
ace.rt.es needs registration with IANA
ace.rt.ra needs registration with IANA
9.2. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in [RFC3688], the following registration is
requested: requested:
URI: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
9.2. The YANG Module Names Registry 9.3. The YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. Following the format defined in [RFC6020], the registry [RFC6020]. Following the format defined in [RFC6020], the
the following registration is requested: the following registration is requested:
name: ietf-cwt-voucher name: ietf-constrained-voucher
namespace: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
name: ietf-cwt-voucher-request name: ietf-constrained-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request namespace: urn:ietf:params:xml:ns:yang:ietf-constrained
-voucher-request
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
9.3. The SMI Security for S/MIME CMS Content Type Registry 9.4. 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.4. The SID registry 9.5. The SID registry
The SID range 1001100 was allocated by comi.space to the IETF-CWT- The SID range 1001100 was allocated by comi.space to the IETF-
VOUCHER yang module. CONSTRAINED-VOUCHER yang module.
The SID range 1001150 was allocated by comi.space to the IETF-CWT- The SID range 1001150 was allocated by comi.space to the IETF-
VOUCHER-REQUEST yang module. CONSTRAINED-VOUCHER-REQUEST yang module.
EDNOTE: it is unclear if there is further IANA work required. EDNOTE: it is unclear if there is further IANA work required.
9.5. 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.5.1. application/voucher-cms+cbor 9.6.1. application/voucher-cms+cbor
Type name: application Type name: application
Subtype name: voucher-cms+cbor Subtype name: voucher-cms+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: CMS-signed CBOR vouchers are CBOR Encoding considerations: CMS-signed CBOR vouchers are CBOR
encoded. encoded.
Security considerations: See Security Considerations, Section Security considerations: See Security Considerations, Section
Interoperability considerations: The format is designed to be Interoperability considerations: The format is designed to be
broadly interoperable. broadly interoperable.
Published specification: THIS RFC. Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch, and other Applications that use this media type: ANIMA, 6tisch, and other
zero-touch imprinting systems zero-touch imprinting systems
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .cbor File extension(s): .vch
Macintosh file type code(s): none Macintosh file type code(s): none
Person & email address to contact for further information: IETF Person & email address to contact for further information: IETF
ANIMA WG ANIMA WG
Intended usage: LIMITED Intended usage: LIMITED
Restrictions on usage: NONE Restrictions on usage: NONE
Author: ANIMA WG Author: ANIMA WG
Change controller: IETF Change controller: IETF
Provisional registration? (standards tree only): NO Provisional registration? (standards tree only): NO
9.5.2. application/voucher-cose+cbor 9.6.2. application/voucher-cose+cbor
Type name: application Type name: application
Subtype name: voucher-cose+cbor Subtype name: voucher-cose+cbor
Required parameters: none Required parameters: none
Optional parameters: cose-type Optional parameters: cose-type
Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects
signed with one signer. signed with one signer.
Security considerations: See Security Considerations, Section Security considerations: See Security Considerations, Section
Interoperability considerations: The format is designed to be Interoperability considerations: The format is designed to be
broadly interoperable. broadly interoperable.
Published specification: THIS RFC. Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch, and other Applications that use this media type: ANIMA, 6tisch, and other
zero-touch imprinting systems zero-touch imprinting systems
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .cbor File extension(s): .vch
Macintosh file type code(s): none Macintosh file type code(s): none
Person & email address to contact for further information: IETF Person & email address to contact for further information: IETF
ANIMA WG ANIMA WG
Intended usage: LIMITED Intended usage: LIMITED
Restrictions on usage: NONE Restrictions on usage: NONE
Author: ANIMA WG Author: ANIMA WG
Change controller: IETF Change controller: IETF
Provisional registration? (standards tree only): NO Provisional registration? (standards tree only): NO
9.6. CoAP Content-Format Registry 9.7. CoAP Content-Format Registry
Additions to the sub-registry "CoAP Content-Formats", within the Additions to the sub-registry "CoAP Content-Formats", within the
"CoRE Parameters" registry are needed for the below media types. "CoRE Parameters" registry are needed for two media types. These can
These can be registered either in the Expert Review range (0-255) or be registered either in the Expert Review range (0-255) or IETF
IETF Review range (256-9999). Review range (256-9999).
Addition1:
Type name: application
Subtype name: voucher-cms+cbor
ID: TBD2
Required parameters: None
Optional parameters: None
Encoding considerations: CBOR
Security considerations: As defined in this specification
Published specification: this document
Applications that use this media type: ANIMA bootstrap (BRSKI)
Addition2:
Type name: application Media type mime type Encoding ID References
Subtype name: voucher-cose+cbor ---------------------------- ----------- --------- ---- ----------
ID: TBD3 application/voucher-cms+cbor - - CBOR TBD2 [This RFC]
Required parameters: cose-type="COSE-Sign1" application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC]
Optional parameters: none
Encoding considerations: CBOR
Security considerations: As defined in this specification
Published specification: this document
Applications that use this media type: ANIMA bootstrap (BRSKI)
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.
Michel Veillette did extensive work on pyang to extend it to support
the SID allocation process, and this document was among the first
users.
We are grateful for the suggestions done by Esko Dijk.
11. Changelog 11. Changelog
-03 -01
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] [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., Kumar, S., Richardson, M., Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST- Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-ietf-ace-coap-est-00 (work in progress), coaps)", draft-ietf-ace-coap-est-05 (work in progress),
February 2018. July 2018.
[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-15 (work in progress), April 2018. keyinfra-16 (work in progress), June 2018.
[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-12 (work in (OSCORE)", draft-ietf-core-object-security-14 (work in
progress), March 2018. progress), July 2018.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M. and A. Pelov, "YANG Schema Item iDentifier Veillette, M. and A. Pelov, "YANG Schema Item iDentifier
(SID)", draft-ietf-core-sid-03 (work in progress), (SID)", draft-ietf-core-sid-04 (work in progress), June
December 2017. 2018.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG", Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-06 (work in progress), February draft-ietf-core-yang-cbor-06 (work in progress), February
2018. 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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[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., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
skipping to change at page 20, line 10 skipping to change at page 21, line 43
[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
[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/papers/1999-StajanoAnd- <https://www.cl.cam.ac.uk/~fms27/
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.
[pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015,
<http://dictionary.reference.com/browse/pledge>. <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, <https://www.rfc- DOI 10.17487/RFC7030, October 2013,
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
This section extends the examples from Appendix A of This section extends the examples from Appendix A of
[I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for
the enrollstatus example. the enrollstatus example.
A.1. enrollstatus A.1. enrollstatus
A coaps enrollstatus message can be : A coaps enrollstatus message can be :
skipping to change at page 21, line 49 skipping to change at page 23, line 23
Payload = Payload =
[EDNOTE: put here voucher payload ] [EDNOTE: put here voucher payload ]
A.2. voucher_status A.2. voucher_status
A coaps voucher_status message can be : A coaps voucher_status message can be :
GET coaps://[2001:db8::2:1]:61616]/est/vs GET coaps://[2001:db8::2:1]:61616]/est/vs
A 2.05 Content response with a non signed JSON voucher (ct=50) 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/json) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
[EDNOTE: put here voucher payload ] [EDNOTE: put here voucher payload ]
A.3. requestvoucher A.3. requestvoucher
A coaps requestvoucher message can be : A coaps requestvoucher message can be :
GET coaps://[2001:db8::2:1]:61616]/est/rv POST coaps://[2001:db8::2:1]:61616]/est/rv
A 2.05 Content 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.05 Content (Content-Format: application/voucher-cms+cbor) 2.05 Changed (Content-Format: application/voucher-cms+cbor)
Payload = Payload =
[EDNOTE: put here CMS signed voucher payload ] [EDNOTE: put here encrypted voucher payload ]
A.4. requestauditing A.4. requestauditing
A coaps requestauditing message can be : A coaps requestauditing message can be :
GET coaps://[2001:db8::2:1]:61616]/est/ra GET coaps://[2001:db8::2:1]:61616]/est/ra
A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will
then be: then be:
skipping to change at page 22, line 47 skipping to change at page 24, line 21
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Peter van der Stok Peter van der Stok
vanderstok consultancy vanderstok consultancy
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
Panos Kamapanakis Panos Kampanakis
Cisco Systems Cisco Systems
Email: pkampana@cisco.com Email: pkampana@cisco.com
 End of changes. 91 change blocks. 
335 lines changed or deleted 423 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/