< draft-ietf-netconf-keystore-22.txt   draft-ietf-netconf-keystore-23.txt >
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Watsen Networks Internet-Draft Watsen Networks
Intended status: Standards Track 18 May 2021 Intended status: Standards Track 14 December 2021
Expires: 19 November 2021 Expires: 17 June 2022
A YANG Data Model for a Keystore A YANG Data Model for a Keystore
draft-ietf-netconf-keystore-22 draft-ietf-netconf-keystore-23
Abstract Abstract
This document defines a YANG module called "ietf-keystore" that This document defines a YANG module called "ietf-keystore" that
enables centralized configuration of both symmetric and asymmetric enables centralized configuration of both symmetric and asymmetric
keys. The secret value for both key types may be encrypted or keys. The secret value for both key types may be encrypted or
hidden. Asymmetric keys may be associated with certificates. hidden. Asymmetric keys may be associated with certificates.
Notifications are sent when certificates are about to expire. Notifications are sent when certificates are about to expire.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains placeholder values that need to be replaced with This draft contains placeholder values that need to be replaced with
finalized values at the time of publication. This note summarizes finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document. instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
* "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-
types types
* "CCCC" --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
* "2021-05-18" --> the publication date of this draft * 2021-12-14 --> the publication date of this draft
The following Appendix section is to be removed prior to publication: The following Appendix section is to be removed prior to publication:
* Appendix A. Change Log * Appendix A. Change Log
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 19 November 2021. This Internet-Draft will expire on 17 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4
1.2. Specification Language . . . . . . . . . . . . . . . . . 6 1.2. Specification Language . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 6 1.4. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 6
1.5. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. The "ietf-keystore" Module . . . . . . . . . . . . . . . . . 6 2. The "ietf-keystore" Module . . . . . . . . . . . . . . . . . 6
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 7
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 14
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26
3. Support for Built-in Keys . . . . . . . . . . . . . . . . . . 34 3. Support for Built-in Keys . . . . . . . . . . . . . . . . . . 34
4. Encrypting Keys in Configuration . . . . . . . . . . . . . . 37 4. Encrypting Keys in Configuration . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Security of Data at Rest . . . . . . . . . . . . . . . . 41 5.1. Security of Data at Rest . . . . . . . . . . . . . . . . 40
5.2. Unconstrained Private Key Usage . . . . . . . . . . . . . 41 5.2. Unconstrained Private Key Usage . . . . . . . . . . . . . 40
5.3. The "ietf-keystore" YANG Module . . . . . . . . . . . . . 41 5.3. The "ietf-keystore" YANG Module . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 42 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 41
6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 42 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 41
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 43 7.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 45 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 44
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 45
A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 46
A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 48
A.21. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 50 A.21. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 49
A.22. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 50 A.22. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 A.23. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This document defines a YANG 1.1 [RFC7950] module called "ietf- This document defines a YANG 1.1 [RFC7950] module called "ietf-
keystore" that enables centralized configuration of both symmetric keystore" that enables centralized configuration of both symmetric
and asymmetric keys. The secret value for both key types may be and asymmetric keys. The secret value for both key types may be
encrypted or hidden (see [I-D.ietf-netconf-crypto-types]. Asymmetric encrypted or hidden (see [I-D.ietf-netconf-crypto-types]. Asymmetric
keys may be associated with certificates. Notifications are sent keys may be associated with certificates. Notifications are sent
when certificates are about to expire. when certificates are about to expire.
skipping to change at page 4, line 11 skipping to change at page 4, line 6
there are groupings that define enabling a key to be either there are groupings that define enabling a key to be either
configured locally (within the defining data model) or be a reference configured locally (within the defining data model) or be a reference
to a key in the keystore. to a key in the keystore.
Special consideration has been given for systems that have Special consideration has been given for systems that have
cryptographic hardware, such as a Trusted Platform Module (TPM). cryptographic hardware, such as a Trusted Platform Module (TPM).
These systems are unique in that the cryptographic hardware hides the These systems are unique in that the cryptographic hardware hides the
secret key values. Additionally, such hardware is commonly secret key values. Additionally, such hardware is commonly
initialized when manufactured to protect a "built-in" asymmetric key initialized when manufactured to protect a "built-in" asymmetric key
for which the public half is conveyed in an identity certificate for which the public half is conveyed in an identity certificate
(e.g., an IDevID [Std-802.1AR-2009] certificate). Please see (e.g., an IDevID [Std-802.1AR-2018] certificate). Please see
Section 3 to see how built-in keys are supported. Section 3 to see how built-in keys are supported.
This document intends to support existing practices; it does not This document intends to support existing practices; it does not
intend to define new behavior for systems to implement. To simplify intend to define new behavior for systems to implement. To simplify
implementation, advanced key formats may be selectively implemented. implementation, advanced key formats may be selectively implemented.
Implementations may utilize zero or more operating system level Implementations may utilize zero or more operating system level
keystore utilities and/or hardware security modules (HSMs). keystore utilities and/or hardware security modules (HSMs).
1.1. Relation to other RFCs 1.1. Relation to other RFCs
skipping to change at page 6, line 35 skipping to change at page 6, line 35
as the past tense verbified form of the "augment" statement defined as the past tense verbified form of the "augment" statement defined
in Section 7.17 of [RFC7950]. in Section 7.17 of [RFC7950].
1.4. Adherence to the NMDA 1.4. Adherence to the NMDA
This document is compliant with Network Management Datastore This document is compliant with Network Management Datastore
Architecture (NMDA) [RFC8342]. For instance, keys and associated Architecture (NMDA) [RFC8342]. For instance, keys and associated
certificates installed during manufacturing (e.g., for an IDevID certificates installed during manufacturing (e.g., for an IDevID
certificate) are expected to appear in <operational> (see Section 3). certificate) are expected to appear in <operational> (see Section 3).
1.5. Conventions
Various examples used in this document use a placeholder value for
binary data that has been base64 encoded (e.g., "BASE64VALUE=").
This placeholder value is used as real base64 encoded structures are
often many lines long and hence distracting to the example being
presented.
2. The "ietf-keystore" Module 2. The "ietf-keystore" Module
This section defines a YANG 1.1 [RFC7950] module called "ietf- This section defines a YANG 1.1 [RFC7950] module called "ietf-
keystore". A high-level overview of the module is provided in keystore". A high-level overview of the module is provided in
Section 2.1. Examples illustrating the module's use are provided in Section 2.1. Examples illustrating the module's use are provided in
Section 2.2. The YANG module itself is defined in Section 2.3. Section 2.2. The YANG module itself is defined in Section 2.3.
2.1. Data Model Overview 2.1. Data Model Overview
This section provides an overview of the "ietf-keystore" module in This section provides an overview of the "ietf-keystore" module in
skipping to change at page 7, line 27 skipping to change at page 7, line 38
Typedefs: Typedefs:
leafref leafref
+-- symmetric-key-ref +-- symmetric-key-ref
+-- asymmetric-key-ref +-- asymmetric-key-ref
| The diagram above uses syntax that is similar to but not | The diagram above uses syntax that is similar to but not
| defined in [RFC8340]. | defined in [RFC8340].
Comments: Comments:
* All of the typedefs defined in the "ietf-keystore" module extend * All the typedefs defined in the "ietf-keystore" module extend the
the base "leafref" type defined in [RFC7950]. base "leafref" type defined in [RFC7950].
* The leafrefs refer to symmetric and asymmetric keys in the central * The leafrefs refer to symmetric and asymmetric keys in the central
keystore, when this module is implemented. keystore, when this module is implemented.
* These typedefs are provided as an aid to downstream modules that * These typedefs are provided as an aid to downstream modules that
import the "ietf-keystore" module. import the "ietf-keystore" module.
2.1.3. Groupings 2.1.3. Groupings
The "ietf-keystore" module defines the following "grouping" The "ietf-keystore" module defines the following "grouping"
skipping to change at page 14, line 44 skipping to change at page 15, line 4
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<symmetric-keys> <symmetric-keys>
<symmetric-key> <symmetric-key>
<name>cleartext-symmetric-key</name> <name>cleartext-symmetric-key</name>
<key-format>ct:octet-string-key-format</key-format> <key-format>ct:octet-string-key-format</key-format>
<cleartext-key>base64encodedvalue==</cleartext-key> <cleartext-key>BASE64VALUE=</cleartext-key>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
<name>hidden-symmetric-key</name> <name>hidden-symmetric-key</name>
<hidden-key/> <hidden-key/>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
<name>encrypted-symmetric-key</name> <name>encrypted-symmetric-key</name>
<key-format>ct:one-symmetric-key-format</key-format> <key-format>ct:one-symmetric-key-format</key-format>
<encrypted-key> <encrypted-key>
<encrypted-by> <encrypted-by>
<asymmetric-key-ref>hidden-asymmetric-key</asymmetric-k\ <asymmetric-key-ref>hidden-asymmetric-key</asymmetric-k\
ey-ref> ey-ref>
</encrypted-by> </encrypted-by>
<encrypted-value-format> <encrypted-value-format>
ct:cms-enveloped-data-format ct:cms-enveloped-data-format
</encrypted-value-format> </encrypted-value-format>
<encrypted-value>base64encodedvalue==</encrypted-value> <encrypted-value>BASE64VALUE=</encrypted-value>
</encrypted-key> </encrypted-key>
</symmetric-key> </symmetric-key>
</symmetric-keys> </symmetric-keys>
<asymmetric-keys> <asymmetric-keys>
<asymmetric-key> <asymmetric-key>
<name>ssh-rsa-key</name> <name>ssh-rsa-key</name>
<public-key-format> <public-key-format>
ct:ssh-public-key-format ct:ssh-public-key-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-priv\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ate-key>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>ssh-rsa-key-with-cert</name> <name>ssh-rsa-key-with-cert</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-priv\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ate-key>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-rsa-cert2</name> <name>ex-rsa-cert2</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>raw-private-key</name> <name>raw-private-key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-priv\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ate-key>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>rsa-asymmetric-key</name> <name>rsa-asymmetric-key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-priv\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ate-key>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-rsa-cert</name> <name>ex-rsa-cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>ec-asymmetric-key</name> <name>ec-asymmetric-key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:ec-private-key-format ct:ec-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-priv\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ate-key>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-ec-cert</name> <name>ex-ec-cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>hidden-asymmetric-key</name> <name>hidden-asymmetric-key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<hidden-private-key/> <hidden-private-key/>
<certificates> <certificates>
<certificate> <certificate>
<name>builtin-idevid-cert</name> <name>builtin-idevid-cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>my-ldevid-cert</name> <name>my-ldevid-cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>encrypted-asymmetric-key</name> <name>encrypted-asymmetric-key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:one-asymmetric-key-format ct:one-asymmetric-key-format
</private-key-format> </private-key-format>
<encrypted-private-key> <encrypted-private-key>
<encrypted-by> <encrypted-by>
<symmetric-key-ref>encrypted-symmetric-key</symmetric-k\ <symmetric-key-ref>encrypted-symmetric-key</symmetric-k\
ey-ref> ey-ref>
</encrypted-by> </encrypted-by>
<encrypted-value-format> <encrypted-value-format>
ct:cms-encrypted-data-format ct:cms-encrypted-data-format
</encrypted-value-format> </encrypted-value-format>
<encrypted-value>base64encodedvalue==</encrypted-value> <encrypted-value>BASE64VALUE=</encrypted-value>
</encrypted-private-key> </encrypted-private-key>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</keystore> </keystore>
2.2.2. A Certificate Expiration Notification 2.2.2. A Certificate Expiration Notification
The following example illustrates a "certificate-expiration" The following example illustrates a "certificate-expiration"
notification for a certificate associated with a key configured in notification for a certificate associated with a key configured in
the keystore. the keystore.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
+--rw certificate? leafref +--rw certificate? leafref
The following example provides two equivalent instances of each The following example provides two equivalent instances of each
grouping, the first being a reference to a keystore and the second grouping, the first being a reference to a keystore and the second
being locally-defined. The instance having a reference to a keystore being locally-defined. The instance having a reference to a keystore
is consistent with the keystore defined in Section 2.2.1. The two is consistent with the keystore defined in Section 2.2.1. The two
instances are equivalent, as the locally-defined instance example instances are equivalent, as the locally-defined instance example
contains the same values defined by the keystore instance referenced contains the same values defined by the keystore instance referenced
by its sibling example. by its sibling example.
=============== NOTE: '\' line wrapping per RFC 8792 ================
<keystore-usage <keystore-usage
xmlns="http://example.com/ns/example-keystore-usage" xmlns="http://example.com/ns/example-keystore-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<!-- The following two equivalent examples illustrate the --> <!-- The following two equivalent examples illustrate the -->
<!-- "local-or-keystore-symmetric-key-grouping" grouping: --> <!-- "local-or-keystore-symmetric-key-grouping" grouping: -->
<symmetric-key> <symmetric-key>
<name>example 1a</name> <name>example 1a</name>
<keystore-reference>cleartext-symmetric-key</keystore-reference> <keystore-reference>cleartext-symmetric-key</keystore-reference>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
<name>example 1b</name> <name>example 1b</name>
<local-definition> <local-definition>
<key-format>ct:octet-string-key-format</key-format> <key-format>ct:octet-string-key-format</key-format>
<cleartext-key>base64encodedvalue==</cleartext-key> <cleartext-key>BASE64VALUE=</cleartext-key>
</local-definition> </local-definition>
</symmetric-key> </symmetric-key>
<!-- The following two equivalent examples illustrate the --> <!-- The following two equivalent examples illustrate the -->
<!-- "local-or-keystore-asymmetric-key-grouping" grouping: --> <!-- "local-or-keystore-asymmetric-key-grouping" grouping: -->
<asymmetric-key> <asymmetric-key>
<name>example 2a</name> <name>example 2a</name>
<keystore-reference>rsa-asymmetric-key</keystore-reference> <keystore-reference>rsa-asymmetric-key</keystore-reference>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>example 2b</name> <name>example 2b</name>
<local-definition> <local-definition>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-private\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
-key>
</local-definition> </local-definition>
</asymmetric-key> </asymmetric-key>
<!-- the following two equivalent examples illustrate --> <!-- the following two equivalent examples illustrate -->
<!-- "local-or-keystore-asymmetric-key-with-certs-grouping": --> <!-- "local-or-keystore-asymmetric-key-with-certs-grouping": -->
<asymmetric-key-with-certs> <asymmetric-key-with-certs>
<name>example 3a</name> <name>example 3a</name>
<keystore-reference>rsa-asymmetric-key</keystore-reference> <keystore-reference>rsa-asymmetric-key</keystore-reference>
</asymmetric-key-with-certs> </asymmetric-key-with-certs>
<asymmetric-key-with-certs> <asymmetric-key-with-certs>
<name>example 3b</name> <name>example 3b</name>
<local-definition> <local-definition>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-private\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
-key>
<certificates> <certificates>
<certificate> <certificate>
<name>a locally-defined cert</name> <name>a locally-defined cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</local-definition> </local-definition>
</asymmetric-key-with-certs> </asymmetric-key-with-certs>
<!-- The following two equivalent examples illustrate --> <!-- The following two equivalent examples illustrate -->
<!-- "local-or-keystore-end-entity-cert-with-key-grouping": --> <!-- "local-or-keystore-end-entity-cert-with-key-grouping": -->
<end-entity-cert-with-key> <end-entity-cert-with-key>
<name>example 4a</name> <name>example 4a</name>
skipping to change at page 23, line 49 skipping to change at page 23, line 45
<certificate>ex-rsa-cert</certificate> <certificate>ex-rsa-cert</certificate>
</keystore-reference> </keystore-reference>
</end-entity-cert-with-key> </end-entity-cert-with-key>
<end-entity-cert-with-key> <end-entity-cert-with-key>
<name>example 4b</name> <name>example 4b</name>
<local-definition> <local-definition>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<cleartext-private-key>base64encodedvalue==</cleartext-private\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
-key> <cert-data>BASE64VALUE=</cert-data>
<cert-data>base64encodedvalue==</cert-data>
</local-definition> </local-definition>
</end-entity-cert-with-key> </end-entity-cert-with-key>
</keystore-usage> </keystore-usage>
Following is the "ex-keystore-usage" module's YANG definition: Following is the "ex-keystore-usage" module's YANG definition:
module ex-keystore-usage { module ex-keystore-usage {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/ns/example-keystore-usage"; namespace "http://example.com/ns/example-keystore-usage";
skipping to change at page 24, line 37 skipping to change at page 24, line 33
organization organization
"Example Corporation"; "Example Corporation";
contact contact
"Author: YANG Designer <mailto:yang.designer@example.com>"; "Author: YANG Designer <mailto:yang.designer@example.com>";
description description
"This module illustrates notable groupings defined in "This module illustrates notable groupings defined in
the 'ietf-keystore' module."; the 'ietf-keystore' module.";
revision 2021-05-18 { revision 2021-12-14 {
description description
"Initial version"; "Initial version";
reference reference
"RFC CCCC: A YANG Data Model for a Keystore"; "RFC CCCC: A YANG Data Model for a Keystore";
} }
container keystore-usage { container keystore-usage {
description description
"An illustration of the various keystore groupings."; "An illustration of the various keystore groupings.";
list symmetric-key { list symmetric-key {
skipping to change at page 26, line 4 skipping to change at page 25, line 47
type string; type string;
description description
"An arbitrary name for this key."; "An arbitrary name for this key.";
} }
uses ks:local-or-keystore-end-entity-cert-with-key-grouping; uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
description description
"An end-entity certificate and its associated asymmetric "An end-entity certificate and its associated asymmetric
key, that may be configured locally or be a reference key, that may be configured locally or be a reference
to another certificate (and its associated asymmetric to another certificate (and its associated asymmetric
key) in the keystore."; key) in the keystore.";
} }
} }
} }
2.3. YANG Module 2.3. YANG Module
This YANG module has normative references to [RFC8341] and This YANG module has normative references to [RFC8341] and
[I-D.ietf-netconf-crypto-types]. [I-D.ietf-netconf-crypto-types].
<CODE BEGINS> file "ietf-keystore@2021-05-18.yang" <CODE BEGINS> file "ietf-keystore@2021-12-14.yang"
module ietf-keystore { module ietf-keystore {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; namespace "urn:ietf:params:xml:ns:yang:ietf-keystore";
prefix ks; prefix ks;
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC 8341: Network Configuration Access Control Model";
skipping to change at page 27, line 17 skipping to change at page 27, line 13
(https://www.rfc-editor.org/info/rfcCCCC); see the RFC (https://www.rfc-editor.org/info/rfcCCCC); see the RFC
itself for full legal notices. itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision 2021-05-18 { revision 2021-12-14 {
description description
"Initial version"; "Initial version";
reference reference
"RFC CCCC: A YANG Data Model for a Keystore"; "RFC CCCC: A YANG Data Model for a Keystore";
} }
/****************/ /****************/
/* Features */ /* Features */
/****************/ /****************/
skipping to change at page 34, line 40 skipping to change at page 34, line 37
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types" xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended"> or:origin="or:intended">
<asymmetric-keys> <asymmetric-keys>
<asymmetric-key or:origin="or:system"> <asymmetric-key or:origin="or:system">
<name>Manufacturer-Generated Hidden Key</name> <name>Manufacturer-Generated Hidden Key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<hidden-private-key/> <hidden-private-key/>
<certificates> <certificates>
<certificate> <certificate>
<name>Manufacturer-Generated IDevID Cert</name> <name>Manufacturer-Generated IDevID Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</keystore> </keystore>
In order for the built-in keys (and their associated built-in In order for the built-in keys (and their associated built-in
certificates) to be referenced by configuration, the referenced keys certificates) to be referenced by configuration, the referenced keys
and associated certificates MUST first be copied into <running>. and associated certificates MUST first be copied into <running>.
Built-in keys that are "hidden" MUST be copied into <running> using Built-in keys that are "hidden" MUST be copied into <running> using
the same key values, so that the server can bind them to the built-in the same key values, so that the server can bind them to the built-in
entries. entries.
Built-in keys that are "encrypted" MAY be copied into other parts of Built-in keys that are "encrypted" MAY be copied into other parts of
the configuration so long as they are otherwise unmodified (e.g., the the configuration so long as they are otherwise unmodified (e.g., the
skipping to change at page 36, line 13 skipping to change at page 35, line 36
<running>: <running>:
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<asymmetric-keys> <asymmetric-keys>
<asymmetric-key> <asymmetric-key>
<name>Manufacturer-Generated Hidden Key</name> <name>Manufacturer-Generated Hidden Key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<hidden-private-key/> <hidden-private-key/>
<certificates> <certificates>
<certificate> <certificate>
<name>Manufacturer-Generated IDevID Cert</name> <name>Manufacturer-Generated IDevID Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Deployment-Specific LDevID Cert</name> <name>Deployment-Specific LDevID Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</keystore> </keystore>
After the above configuration is applied, <operational> should appear After the above configuration is applied, <operational> should appear
as follows: as follows:
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types" xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended"> or:origin="or:intended">
<asymmetric-keys> <asymmetric-keys>
<asymmetric-key or:origin="or:system"> <asymmetric-key or:origin="or:system">
<name>Manufacturer-Generated Hidden Key</name> <name>Manufacturer-Generated Hidden Key</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format ct:subject-public-key-info-format
</public-key-format> </public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
<hidden-private-key/> <hidden-private-key/>
<certificates> <certificates>
<certificate> <certificate>
<name>Manufacturer-Generated IDevID Cert</name> <name>Manufacturer-Generated IDevID Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate or:origin="or:intended"> <certificate or:origin="or:intended">
<name>Deployment-Specific LDevID Cert</name> <name>Deployment-Specific LDevID Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</keystore> </keystore>
4. Encrypting Keys in Configuration 4. Encrypting Keys in Configuration
This section describes an approach that enables both the symmetric This section describes an approach that enables both the symmetric
and asymmetric keys on a server to be encrypted, such that and asymmetric keys on a server to be encrypted, such that
skipping to change at page 39, line 10 skipping to change at page 38, line 10
may be used to migrate a KEK from one server to another. That said, may be used to migrate a KEK from one server to another. That said,
beware that the ability to do so typically entails having access to beware that the ability to do so typically entails having access to
the first server but, in many scenarios, the first server may no the first server but, in many scenarios, the first server may no
longer be operational. longer be operational.
In other deployments, an organization's crypto officer, possessing a In other deployments, an organization's crypto officer, possessing a
KEK's cleartext value, configures the same KEK on the second server, KEK's cleartext value, configures the same KEK on the second server,
presumably as a hidden key or a key protected by access-control presumably as a hidden key or a key protected by access-control
(e.g., NACM's "default-deny-all"), so that the cleartext value is not (e.g., NACM's "default-deny-all"), so that the cleartext value is not
disclosed to regular administrators. However, this approach creates disclosed to regular administrators. However, this approach creates
high-coupling to and dependency on the crypto officers that doesn't high-coupling to and dependency on the crypto officers that does not
scale in production environments. scale in production environments.
In order to decouple the crypto officers from the regular In order to decouple the crypto officers from the regular
administrators, a special KEK, called the "master key" (MK), may be administrators, a special KEK, called the "master key" (MK), may be
used. used.
A MK is commonly a globally-unique built-in (see Section 3) A MK is commonly a globally-unique built-in (see Section 3)
asymmetric key. The private key, due to its long lifetime, is hidden asymmetric key. The private key, due to its long lifetime, is hidden
(i.e., "hidden-private-key" in Section 2.1.4.5. of (i.e., "hidden-private-key" in Section 2.1.4.5. of
[I-D.ietf-netconf-crypto-types]). The public key is often contained [I-D.ietf-netconf-crypto-types]). The public key is often contained
skipping to change at page 42, line 11 skipping to change at page 41, line 11
considered sensitive or vulnerable in network environments. The NACM considered sensitive or vulnerable in network environments. The NACM
"default-deny-all" extension has not been set for any data nodes "default-deny-all" extension has not been set for any data nodes
defined in this module. defined in this module.
| Please be aware that this module uses the "cleartext-key" and | Please be aware that this module uses the "cleartext-key" and
| "cleartext-private-key" nodes from the "ietf-crypto-types" | "cleartext-private-key" nodes from the "ietf-crypto-types"
| module [I-D.ietf-netconf-crypto-types], where said nodes have | module [I-D.ietf-netconf-crypto-types], where said nodes have
| the NACM extension "default-deny-all" set, thus preventing | the NACM extension "default-deny-all" set, thus preventing
| uncontrolled read-access to the cleartext key values. | uncontrolled read-access to the cleartext key values.
All of the writable data nodes defined by this module, both in the All the writable data nodes defined by this module, both in the
"grouping" statements as well as the protocol-accessible "keystore" "grouping" statements as well as the protocol-accessible "keystore"
instance, may be considered sensitive or vulnerable in some network instance, may be considered sensitive or vulnerable in some network
environments.. For instance, any modification to a key or reference environments.. For instance, any modification to a key or reference
to a key may dramatically alter the implemented security policy. For to a key may dramatically alter the implemented security policy. For
this reason, the NACM extension "default-deny-write" has been set for this reason, the NACM extension "default-deny-write" has been set for
all data nodes defined in this module. all data nodes defined in this module.
This module does not define any "rpc" or "action" statements, and This module does not define any "rpc" or "action" statements, and
thus the security considerations for such is not provided here. thus the security considerations for such is not provided here.
skipping to change at page 43, line 8 skipping to change at page 42, line 8
prefix: ks prefix: ks
reference: RFC CCCC reference: RFC CCCC
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netconf-crypto-types] [I-D.ietf-netconf-crypto-types]
Watsen, K., "YANG Data Types and Groupings for Watsen, K., "YANG Data Types and Groupings for
Cryptography", Work in Progress, Internet-Draft, draft- Cryptography", Work in Progress, Internet-Draft, draft-
ietf-netconf-crypto-types-19, 10 February 2021, ietf-netconf-crypto-types-21, 14 September 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-crypto- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
types-19>. crypto-types-21>.
[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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
skipping to change at page 43, line 36 skipping to change at page 42, line 36
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-netconf-http-client-server] [I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP Watsen, K., "YANG Groupings for HTTP Clients and HTTP
Servers", Work in Progress, Internet-Draft, draft-ietf- Servers", Work in Progress, Internet-Draft, draft-ietf-
netconf-http-client-server-06, 10 February 2021, netconf-http-client-server-07, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-http- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-06>. http-client-server-07>.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", Work in Watsen, K., "A YANG Data Model for a Keystore", Work in
Progress, Internet-Draft, draft-ietf-netconf-keystore-21, Progress, Internet-Draft, draft-ietf-netconf-keystore-22,
10 February 2021, <https://tools.ietf.org/html/draft-ietf- 18 May 2021, <https://datatracker.ietf.org/doc/html/draft-
netconf-keystore-21>. ietf-netconf-keystore-22>.
[I-D.ietf-netconf-netconf-client-server] [I-D.ietf-netconf-netconf-client-server]
Watsen, K., "NETCONF Client and Server Models", Work in Watsen, K., "NETCONF Client and Server Models", Work in
Progress, Internet-Draft, draft-ietf-netconf-netconf- Progress, Internet-Draft, draft-ietf-netconf-netconf-
client-server-22, 10 February 2021, client-server-23, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-netconf- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-22>. netconf-client-server-23>.
[I-D.ietf-netconf-restconf-client-server] [I-D.ietf-netconf-restconf-client-server]
Watsen, K., "RESTCONF Client and Server Models", Work in Watsen, K., "RESTCONF Client and Server Models", Work in
Progress, Internet-Draft, draft-ietf-netconf-restconf- Progress, Internet-Draft, draft-ietf-netconf-restconf-
client-server-22, 10 February 2021, client-server-23, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-restconf- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-22>. restconf-client-server-23>.
[I-D.ietf-netconf-ssh-client-server] [I-D.ietf-netconf-ssh-client-server]
Watsen, K., "YANG Groupings for SSH Clients and SSH Watsen, K., "YANG Groupings for SSH Clients and SSH
Servers", Work in Progress, Internet-Draft, draft-ietf- Servers", Work in Progress, Internet-Draft, draft-ietf-
netconf-ssh-client-server-23, 10 February 2021, netconf-ssh-client-server-25, 18 June 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-ssh- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-23>. ssh-client-server-25>.
[I-D.ietf-netconf-tcp-client-server] [I-D.ietf-netconf-tcp-client-server]
Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients
and TCP Servers", Work in Progress, Internet-Draft, draft- and TCP Servers", Work in Progress, Internet-Draft, draft-
ietf-netconf-tcp-client-server-09, 10 February 2021, ietf-netconf-tcp-client-server-10, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-tcp- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-09>. tcp-client-server-10>.
[I-D.ietf-netconf-tls-client-server] [I-D.ietf-netconf-tls-client-server]
Watsen, K., "YANG Groupings for TLS Clients and TLS Watsen, K., "YANG Groupings for TLS Clients and TLS
Servers", Work in Progress, Internet-Draft, draft-ietf- Servers", Work in Progress, Internet-Draft, draft-ietf-
netconf-tls-client-server-23, 10 February 2021, netconf-tls-client-server-25, 18 June 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
client-server-23>. tls-client-server-25>.
[I-D.ietf-netconf-trust-anchors] [I-D.ietf-netconf-trust-anchors]
Watsen, K., "A YANG Data Model for a Truststore", Work in Watsen, K., "A YANG Data Model for a Truststore", Work in
Progress, Internet-Draft, draft-ietf-netconf-trust- Progress, Internet-Draft, draft-ietf-netconf-trust-
anchors-14, 10 February 2021, anchors-15, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-trust- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
anchors-14>. trust-anchors-15>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 45, line 18 skipping to change at page 44, line 18
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[Std-802.1AR-2009] [Std-802.1AR-2018]
Group, W. -. H. L. L. P. W., "IEEE Standard for Local and IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ August 2018,
standard/802.1AR-2009.html>. <https://standards.ieee.org/standard/802_1AR-2018.html>.
Appendix A. Change Log Appendix A. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
A.1. 00 to 01 A.1. 00 to 01
* Replaced the 'certificate-chain' structures with PKCS#7 * Replaced the 'certificate-chain' structures with PKCS#7
structures. (Issue #1) structures. (Issue #1)
skipping to change at page 47, line 19 skipping to change at page 46, line 19
* Added "local-definition" containers to avoid posibility of the * Added "local-definition" containers to avoid posibility of the
action/notification statements being under a "case" statement. action/notification statements being under a "case" statement.
* Updated copyright date, boilerplate template, affiliation, folding * Updated copyright date, boilerplate template, affiliation, folding
algorithm, and reformatted the YANG module. algorithm, and reformatted the YANG module.
A.9. 08 to 09 A.9. 08 to 09
* Added a 'description' statement to the 'must' in the /keystore/ * Added a 'description' statement to the 'must' in the /keystore/
asymmetric-key node explaining that the descendent values may asymmetric-key node explaining that the descendant values may
exist in <operational> only, and that implementation MUST assert exist in <operational> only, and that implementation MUST assert
that the values are either configured or that they exist in that the values are either configured or that they exist in
<operational>. <operational>.
* Copied above 'must' statement (and description) into the local-or- * Copied above 'must' statement (and description) into the local-or-
keystore-asymmetric-key-grouping, local-or-keystore-asymmetric- keystore-asymmetric-key-grouping, local-or-keystore-asymmetric-
key-with-certs-grouping, and local-or-keystore-end-entity-cert- key-with-certs-grouping, and local-or-keystore-end-entity-cert-
with-key-grouping statements. with-key-grouping statements.
A.10. 09 to 10 A.10. 09 to 10
skipping to change at page 50, line 31 skipping to change at page 49, line 31
* Renamed feature "keystore-supported" to "central-keystore- * Renamed feature "keystore-supported" to "central-keystore-
supported". supported".
* Associated with above, generally moved text to refer to a * Associated with above, generally moved text to refer to a
"central" keystore. "central" keystore.
* Aligned modules with `pyang -f` formatting. * Aligned modules with `pyang -f` formatting.
* Fixed nits found by YANG Doctor reviews. * Fixed nits found by YANG Doctor reviews.
A.23. 22 to 23
* Updated 802.1AR ref to latest version
* Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.
* Minor editorial nits
Acknowledgements Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by first name): Alan Luchuk, Andy on list and in the halls (ordered by first name): Alan Luchuk, Andy
Bierman, Benoit Claise, Bert Wijnen, Balazs Kovacs, David Lamparter, Bierman, Benoit Claise, Bert Wijnen, Balazs Kovacs, David Lamparter,
Eric Voit, Ladislav Lhotka, Liang Xia, Juergen Schoenwaelder, Mahesh Eric Voit, Ladislav Lhotka, Liang Xia, Juergen Schoenwaelder, Mahesh
Jethanandani, Magnus Nystroem, Martin Bjoerklund, Mehmet Ersue, Phil Jethanandani, Magnus Nystroem, Martin Bjoerklund, Mehmet Ersue, Phil
Shafer, Radek Krejci, Ramkumar Dhanapal, Reshad Rahman, Sandra Shafer, Radek Krejci, Ramkumar Dhanapal, Reshad Rahman, Sandra
Murphy, Sean Turner, and Tom Petch. Murphy, Sean Turner, and Tom Petch.
 End of changes. 71 change blocks. 
136 lines changed or deleted 145 lines changed or added

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