draft-ietf-anima-constrained-voucher-02.txt   draft-ietf-anima-constrained-voucher-03.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: March 15, 2019 vanderstok consultancy Expires: September 26, 2019 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
September 11, 2018 March 25, 2019
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-02 draft-ietf-anima-constrained-voucher-03
Abstract Abstract
This document defines a strategy to securely assign a pledge to an This document defines a strategy to securely assign a pledge to an
owner, using an artifact signed, directly or indirectly, by the owner, using an artifact signed, directly or indirectly, by the
pledge's manufacturer. This artifact is known as a "voucher". pledge's manufacturer. This artifact is known as a "voucher".
This document builds upon the work in [RFC8366], encoding the This document builds upon the work in [RFC8366], encoding the
resulting artifact in CBOR. Use with two signature technologies are resulting artifact in CBOR. Use with two signature technologies are
described. described.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2019. This Internet-Draft will expire on September 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 8 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 8
6.1.4. Example voucher request artifact . . . . . . . . . . 11 6.1.4. Example voucher request artifact . . . . . . . . . . 12
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 13 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 15 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 16
6.3. CMS format voucher and voucher-request artifacts . . . . 16 6.3. CMS format voucher and voucher-request artifacts . . . . 16
6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17 6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 17 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 17 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 18
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 17 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 18
8.3. Test Domain Certificate Validity when Signing . . . . . . 18 8.3. Test Domain Certificate Validity when Signing . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 18 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 18
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 18 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 19
9.4. The SMI Security for S/MIME CMS Content Type Registry . . 19 9.4. The SMI Security for S/MIME CMS Content Type Registry . . 19
9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 19 9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 19
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 19 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 20
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 19 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 20
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 20 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 20
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 21 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 24 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 24
A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 25 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 25
A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 26 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 26
A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 26 A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 26
A.3.2. unsigned requestvoucher . . . . . . . . . . . . . . . 26 A.3.2. unsigned requestvoucher . . . . . . . . . . . . . . . 26
A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 26 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
skipping to change at page 6, line 28 skipping to change at page 6, line 28
</est/rv>; rt="ace.est/rv";ct=50 60 TBD2 TBD3 16 </est/rv>; rt="ace.est/rv";ct=50 60 TBD2 TBD3 16
</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 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.
Port numbers, not returned in the example, are assumed to be the
default numbers 5683 and 5684 for coap and coaps respectively
(sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY
be returned in the <href> of the payload.
ct=16 stands for the Content-Format "application/cose", and ct=TBD2 ct=16 stands for the Content-Format "application/cose", and ct=TBD2
stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3 stands for Content-Format "application/voucher-cms+cbor, and 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. The
return of the content-formats allows the client to choose the most return of the content-formats allows the client to choose the most
appropriate one from multiple content formats. 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, TBD3, and 16 MUST be
skipping to change at page 8, line 4 skipping to change at page 8, line 4
+-- 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 +-- proximity-registrar-cert? binary
+-- prior-signed-voucher-request? binary +-- prior-signed-voucher-request? binary
6.1.2. SID values 6.1.2. SID values
Base SID value for voucher request: 1001150.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001154 data /ietf-constrained-voucher-request:voucher 1001167 module ietf-constrained-voucher-request
1001168 module ietf-restconf
1001169 module ietf-voucher
1001170 module ietf-yang-types
1001171 data /ietf-constrained-voucher-request:voucher
1001154 data .../ietf-constrained-voucher-request:voucher
1001155 data .../assertion 1001155 data .../assertion
1001156 data .../created-on 1001156 data .../created-on
1001157 data .../domain-cert-revocation-checks 1001157 data .../domain-cert-revocation-checks
1001158 data .../expires-on 1001158 data .../expires-on
1001159 data .../idevid-issuer 1001159 data .../idevid-issuer
1001160 data .../last-renewal-date 1001160 data .../last-renewal-date
1001161 data /ietf-constrained-voucher-request:voucher/nonce 1001161 data .../nonce
1001162 data .../pinned-domain-cert 1001162 data .../pinned-domain-cert
1001163 data .../prior-signed-voucher-request 1001165 data .../prior-signed-voucher-request
1001164 data .../proximity-registrar-cert 1001166 data .../proximity-registrar-cert
1001165 data .../proximity-registrar-subject-public-key-info 1001163 data .../proximity-registrar-subject-public-key-info
1001166 data .../serial-number 1001164 data .../serial-number
1001172 data .../assertion
1001173 data .../created-on
1001174 data .../domain-cert-revocation-checks
1001175 data .../expires-on
1001176 data .../idevid-issuer
1001177 data .../last-renewal-date
1001178 data /ietf-constrained-voucher-request:voucher/nonce
1001179 data .../pinned-domain-cert
1001180 data .../prior-signed-voucher-request
1001181 data .../proximity-registrar-cert
1001182 data .../proximity-registrar-subject-public-key-info
1001183 data .../serial-number
1001150 data ietf-constrained-voucher-request
1001151 data ietf-restconf
1001152 data ietf-voucher
1001153 data ietf-yang-types
WARNING, obsolete definitions
6.1.3. YANG Module 6.1.3. YANG Module
In the constrained-voucher-request YANG module, the voucher is In the constrained-voucher-request YANG module, the voucher is
"augmented" within the "used" grouping statement such that one "augmented" within the "used" grouping statement such that one
continuous set of SID values is generated for the constrained- continuous set of SID values is generated for the constrained-
voucher-request module name, all voucher attributes, and the voucher-request module name, all voucher attributes, and the
constrained-voucher-request attribute. Two attributes of the voucher constrained-voucher-request attribute. Two attributes of the voucher
are "refined" to be optional. are "refined" to be optional.
skipping to change at page 12, line 6 skipping to change at page 12, line 23
<CODE ENDS> <CODE ENDS>
6.1.4. Example voucher request artifact 6.1.4. Example voucher request artifact
Below a CBOR serialization of the constrained-voucher-request is Below 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].
{ {
1001101: { 1001051: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on / +2 : "2016-10-07T19:31:42Z", / SID= 1001053, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on / +4 : "2016-10-21T19:31:42Z", / SID= 1001055, expires-on /
+1 : 0, / SID = 1001102, assertion / +1 : 0, / SID= 1001052, assertion /
/ "verified" / / "verified" /
+12: "JADA123456789", / SID = 1001113, serial-number / +10: "JADA123456789", / SID= 1001061, serial-number /
+5 : h'01020D0F', / SID = 1001106, idevid-issuer / +5 : h'01020D0F', / SID= 1001056, idevid-issuer /
+8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/ +15: h'01020D0F', / SID=1001066, proximity-registrar-cert/
+3 : true, / SID = 1001104, domain-cert +3 : true, / SID= 1001054, domain-cert
-revocation-checks / -revocation-checks/
+6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID= 1001057, last-renewal-date /
+11: h'01020D0F' / SID = 1001112, proximity +9 : h'01020D0F' / SID= 1001060, pinned-domain
-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
skipping to change at page 13, line 7 skipping to change at page 13, line 28
+-- 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? yang:date-and-time +-- last-renewal-date? 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
Base SID value for voucher request: 1001101.
SID Assigned to SID Assigned to
--------- -------------------------------------------------- --------- --------------------------------------------------
1001104 data .../voucher 1001115 module ietf-constrained-voucher
1001116 module ietf-restconf
1001117 module ietf-voucher
1001118 module ietf-yang-types
1001119 data /ietf-constrained-voucher:voucher
1001104 data .../ietf-constrained-voucher:voucher
1001105 data .../assertion 1001105 data .../assertion
1001106 data .../created-on 1001106 data .../created-on
1001107 data .../domain-cert-revocation-checks 1001107 data .../domain-cert-revocation-checks
1001108 data .../expires-on 1001108 data .../expires-on
1001109 data .../idevid-issuer 1001109 data .../idevid-issuer
1001110 data .../last-renewal-date 1001110 data .../last-renewal-date
1001111 data .../nonce 1001111 data .../nonce
1001112 data .../pinned-domain-cert 1001112 data .../pinned-domain-cert
1001113 data .../pinned-domain-subject-public-key-info 1001113 data .../pinned-domain-subject-public-key-info
1001114 data .../serial-number 1001114 data .../serial-number
skipping to change at page 16, line 6 skipping to change at page 16, line 27
<CODE ENDS> <CODE ENDS>
6.2.4. Example voucher artifacts 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the the constrained-voucher and Below a the CBOR serialization of the the constrained-voucher and
constrained-voucher-request are shown in diagnostic CBOR notation. constrained-voucher-request are shown in diagnostic CBOR notation.
The enum value of the assertion field is calculated to be zero by The enum value of the assertion field is calculated to be zero by
following the algorithm described in section 9.6.4.2 of [RFC7950]. following the algorithm described in section 9.6.4.2 of [RFC7950].
{ {
1001051: { 1001101: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on /
+1 : 0, / SID = 1001052, assertion / +1 : 0, / SID = 1001102, assertion /
/ "verified" / / "verified" /
+10: "JADA123456789", / SID = 1001061, serial-number / +12: "JADA123456789", / SID = 1001113, serial-number /
+5 : h'01020D0F', / SID = 1001056, idevid-issuer / +5 : h'01020D0F', / SID = 1001106, idevid-issuer /
+8 : h'01020D0F', / SID = 1001059, pinned-domain-cert/ +8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/
+3 : true, / SID = 1001054, domain-cert +3 : true, / SID = 1001104, domain-cert
-revocation-checks/ -revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date /
+9 : h'01020D0F' / SID = 1001060, pinned-domain +11: h'01020D0F' / SID = 1001112, proximity
-subject-public-key-info / -registrar-subject-public-key-info /
} }
} }
6.3. CMS format 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].
skipping to change at page 22, line 12 skipping to change at page 22, line 12
We are grateful for the suggestions done by Esko Dijk. We are grateful for the suggestions done by Esko Dijk.
11. Changelog 11. Changelog
-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
-01 -01
application/json is optional, application/cbor is compulsory application/json is optional, application/cbor is compulsory
Cms and cose mediatypes are introduced Cms and cose mediatypes are introduced
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-ace-cbor-web-token] [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., Richardson, M., and S. Raza,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
coaps)", draft-ietf-ace-coap-est-05 (work in progress), est-10 (work in progress), March 2019.
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-16 (work in progress), June 2018. keyinfra-19 (work in progress), March 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-14 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), July 2018. progress), March 2019.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M. and A. Pelov, "YANG Schema Item iDentifier Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item
(SID)", draft-ietf-core-sid-04 (work in progress), June iDentifier (SID)", draft-ietf-core-sid-05 (work in
2018. progress), December 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-07 (work in progress), September
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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[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",
 End of changes. 32 change blocks. 
59 lines changed or deleted 110 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/