< draft-ietf-netconf-crypto-types-20.txt   draft-ietf-netconf-crypto-types-21.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 September 2021
Expires: 19 November 2021 Expires: 18 March 2022
YANG Data Types and Groupings for Cryptography YANG Data Types and Groupings for Cryptography
draft-ietf-netconf-crypto-types-20 draft-ietf-netconf-crypto-types-21
Abstract Abstract
This document presents a YANG 1.1 (RFC 7950) module defining This document presents a YANG 1.1 (RFC 7950) module defining
identities, typedefs, and groupings useful to cryptographic identities, typedefs, and groupings useful to cryptographic
applications. applications.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 this draft * "AAAA" --> 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-09-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 18 March 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3
1.2. Specification Language . . . . . . . . . . . . . . . . . 5 1.2. Specification Language . . . . . . . . . . . . . . . . . 5
1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. The "ietf-crypto-types" Module . . . . . . . . . . . . . . . 5 2. The "ietf-crypto-types" Module . . . . . . . . . . . . . . . 5
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
3. Security Considerations . . . . . . . . . . . . . . . . . . . 47 3. Security Considerations . . . . . . . . . . . . . . . . . . . 47
3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 47 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 47
3.2. No Support for Key Generation . . . . . . . . . . . . . . 47 3.2. No Support for Key Generation . . . . . . . . . . . . . . 48
3.3. Unconstrained Public Key Usage . . . . . . . . . . . . . 47 3.3. Unconstrained Public Key Usage . . . . . . . . . . . . . 48
3.4. Unconstrained Private Key Usage . . . . . . . . . . . . . 47 3.4. Unconstrained Private Key Usage . . . . . . . . . . . . . 48
3.5. Strength of Keys Configured . . . . . . . . . . . . . . . 48 3.5. Strength of Keys Conveyed . . . . . . . . . . . . . . . . 48
3.6. Encrypting Passwords . . . . . . . . . . . . . . . . . . 48 3.6. Encrypting Passwords . . . . . . . . . . . . . . . . . . 49
3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 48 3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 49
3.8. The "ietf-crypto-types" YANG Module . . . . . . . . . . . 48 3.8. The "ietf-crypto-types" YANG Module . . . . . . . . . . . 49
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 50 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 51
4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 50 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 51
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1. Normative References . . . . . . . . . . . . . . . . . . 50 5.1. Normative References . . . . . . . . . . . . . . . . . . 51
5.2. Informative References . . . . . . . . . . . . . . . . . 52 5.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 54 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55
A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 54 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 55 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 56
A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 55 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 56
A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 55 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 56
A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 56 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 57
A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 56 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 57
A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 56 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 57
A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 57 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 58
A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 57 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 58
A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 57 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 58
A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 57 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 58
A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 58 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 59
A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 58 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 59
A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 58 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 59
A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 58 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 59
A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 59 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 60
A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 59 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 60
A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 60 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 61
A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 60 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 61
A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 60 A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 61
A.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 60 A.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 A.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
This document presents a YANG 1.1 [RFC7950] module defining This document presents a YANG 1.1 [RFC7950] module defining
identities, typedefs, and groupings useful to cryptographic identities, typedefs, and groupings useful to cryptographic
applications. applications.
1.1. Relation to other RFCs 1.1. Relation to other RFCs
This document presents one or more YANG modules [RFC7950] that are This document presents one or more YANG modules [RFC7950] that are
skipping to change at page 5, line 19 skipping to change at page 5, line 19
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Adherence to the NMDA 1.3. Adherence to the NMDA
This document is compliant with the Network Management Datastore This document is compliant with the Network Management Datastore
Architecture (NMDA) [RFC8342]. It does not define any protocol Architecture (NMDA) [RFC8342]. It does not define any protocol
accessible nodes that are "config false". accessible nodes that are "config false".
1.4. 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-crypto-types" Module 2. The "ietf-crypto-types" Module
This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto-
types". A high-level overview of the module is provided in types". 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
Examples (Section 2.2). The YANG module itself is defined in Examples (Section 2.2). The YANG module itself is defined in
Section 2.3. Section 2.3.
2.1. Data Model Overview 2.1. Data Model Overview
skipping to change at page 7, line 39 skipping to change at page 8, line 5
+-- enveloped-data-cms +-- enveloped-data-cms
+-- digested-data-cms +-- digested-data-cms
+-- encrypted-data-cms +-- encrypted-data-cms
+-- authenticated-data-cms +-- authenticated-data-cms
| 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-crypto-types" module * All the typedefs defined in the "ietf-crypto-types" module extend
extend the "binary" type defined in [RFC7950]. the "binary" type defined in [RFC7950].
* Additionally, all the typedefs define a type for encoding an ASN.1 * Additionally, all the typedefs define a type for encoding an ASN.1
[ITU.X680.2015] structure using DER [ITU.X690.2015]. [ITU.X680.2015] structure using DER [ITU.X690.2015].
* The "trust-anchor-*" and "end-entity-*" typedefs are syntactically * The "trust-anchor-*" and "end-entity-*" typedefs are syntactically
identical to their base typedefs and only distinguish themselves identical to their base typedefs and only distinguish themselves
by the expected nature of their content. These typedefs are by the expected nature of their content. These typedefs are
defined to facilitate common modeling needs. defined to facilitate common modeling needs.
2.1.4. Groupings 2.1.4. Groupings
skipping to change at page 18, line 50 skipping to change at page 19, line 8
organization organization
"Example Corporation"; "Example Corporation";
contact contact
"YANG Designer <mailto:yang.designer@example.com>"; "YANG Designer <mailto:yang.designer@example.com>";
description description
"This module illustrates the 'symmetric-key-grouping' "This module illustrates the 'symmetric-key-grouping'
and 'asymmetric-key-grouping' groupings defined in and 'asymmetric-key-grouping' groupings defined in
the 'ietf-crypto-types' module defined in RFC AAAA."; the 'ietf-crypto-types' module defined in RFC AAAA.";
revision 2021-05-18 { revision 2021-09-14 {
description description
"Initial version"; "Initial version";
reference reference
"RFC AAAA: Common YANG Data Types for Cryptography"; "RFC AAAA: Common YANG Data Types for Cryptography";
} }
container symmetric-keys { container symmetric-keys {
description description
"A container of symmetric keys."; "A container of symmetric keys.";
list symmetric-key { list symmetric-key {
key "name"; key "name";
description description
skipping to change at page 23, line 9 skipping to change at page 23, line 17
<symmetric-keys <symmetric-keys
xmlns="http://example.com/ns/example-crypto-types-usage" xmlns="http://example.com/ns/example-crypto-types-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<symmetric-key> <symmetric-key>
<name>ex-hidden-symmetric-key</name> <name>ex-hidden-symmetric-key</name>
<hidden-key/> <hidden-key/>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
<name>ex-octet-string-based-symmetric-key</name> <name>ex-octet-string-based-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>ex-one-symmetric-based-symmetric-key</name> <name>ex-one-symmetric-based-symmetric-key</name>
<key-format>ct:one-symmetric-key-format</key-format> <key-format>ct:one-symmetric-key-format</key-format>
<cleartext-key>base64encodedvalue==</cleartext-key> <cleartext-key>BASE64VALUE=</cleartext-key>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
<name>ex-encrypted-one-symmetric-based-symmetric-key</name> <name>ex-encrypted-one-symmetric-based-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>ex-hidden-asymmetric-key</asymmetric-key\ <asymmetric-key-ref>ex-hidden-asymmetric-key</asymmetric-key\
-ref> -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
xmlns="http://example.com/ns/example-crypto-types-usage" xmlns="http://example.com/ns/example-crypto-types-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<asymmetric-key> <asymmetric-key>
<name>ex-hidden-asymmetric-key</name> <name>ex-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>ex-hidden-asymmetric-key-cert</name> <name>ex-hidden-asymmetric-key-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>ex-rsa-based-asymmetric-key</name> <name>ex-rsa-based-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-private-k\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ey>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-cert</name> <name>ex-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>ex-one-asymmetric-based-asymmetric-key</name> <name>ex-one-asymmetric-based-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>
<cleartext-private-key>base64encodedvalue==</cleartext-private-k\ <cleartext-private-key>BASE64VALUE=</cleartext-private-key>
ey>
</asymmetric-key> </asymmetric-key>
<asymmetric-key> <asymmetric-key>
<name>ex-encrypted-rsa-based-asymmetric-key</name> <name>ex-encrypted-rsa-based-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>
<encrypted-private-key> <encrypted-private-key>
<encrypted-by> <encrypted-by>
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key</symmetric-key-ref>
</encrypted-by> </encrypted-by>
<encrypted-value-format> <encrypted-value-format>
ct:cms-encrypted-data-format ct:cms-encrypted-data-format
skipping to change at page 24, line 47 skipping to change at page 25, line 4
<private-key-format> <private-key-format>
ct:rsa-private-key-format ct:rsa-private-key-format
</private-key-format> </private-key-format>
<encrypted-private-key> <encrypted-private-key>
<encrypted-by> <encrypted-by>
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key</symmetric-key-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>
<passwords <passwords
xmlns="http://example.com/ns/example-crypto-types-usage" xmlns="http://example.com/ns/example-crypto-types-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<password> <password>
<name>ex-cleartext-password</name> <name>ex-cleartext-password</name>
<cleartext-password>super-secret</cleartext-password> <cleartext-password>super-secret</cleartext-password>
</password> </password>
<password> <password>
<name>ex-encrypted-password</name> <name>ex-encrypted-password</name>
<encrypted-password> <encrypted-password>
<encrypted-by> <encrypted-by>
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key</symmetric-key-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-password> </encrypted-password>
</password> </password>
</passwords> </passwords>
2.2.2. The "generate-certificate-signing-request" Action 2.2.2. The "generate-certificate-signing-request" Action
The following example illustrates the "generate-certificate-signing- The following example illustrates the "generate-certificate-signing-
request" action, discussed in Section 2.1.4.9, with the NETCONF request" action, discussed in Section 2.1.4.9, with the NETCONF
protocol. protocol.
skipping to change at page 25, line 33 skipping to change at page 26, line 4
</password> </password>
</passwords> </passwords>
2.2.2. The "generate-certificate-signing-request" Action 2.2.2. The "generate-certificate-signing-request" Action
The following example illustrates the "generate-certificate-signing- The following example illustrates the "generate-certificate-signing-
request" action, discussed in Section 2.1.4.9, with the NETCONF request" action, discussed in Section 2.1.4.9, with the NETCONF
protocol. protocol.
REQUEST REQUEST
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<asymmetric-keys <asymmetric-keys
xmlns="http://example.com/ns/example-crypto-types-usage"> xmlns="http://example.com/ns/example-crypto-types-usage">
<asymmetric-key> <asymmetric-key>
<name>ex-key-sect571r1</name> <name>ex-key-sect571r1</name>
<generate-certificate-signing-request> <generate-certificate-signing-request>
<csr-info>base64encodedvalue==</csr-info> <csr-info>BASE64VALUE=</csr-info>
</generate-certificate-signing-request> </generate-certificate-signing-request>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</action> </action>
</rpc> </rpc>
RESPONSE RESPONSE
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<certificate-signing-request <certificate-signing-request
xmlns="http://example.com/ns/example-crypto-types-usage"> xmlns="http://example.com/ns/example-crypto-types-usage">
base64encodedvalue== BASE64VALUE=
</certificate-signing-request> </certificate-signing-request>
</rpc-reply> </rpc-reply>
2.2.3. The "certificate-expiration" Notification 2.2.3. The "certificate-expiration" Notification
The following example illustrates the "certificate-expiration" The following example illustrates the "certificate-expiration"
notification, discussed in Section 2.1.4.6, with the NETCONF notification, discussed in Section 2.1.4.6, with the NETCONF
protocol. protocol.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
skipping to change at page 26, line 47 skipping to change at page 27, line 34
</asymmetric-keys> </asymmetric-keys>
</notification> </notification>
2.3. YANG Module 2.3. YANG Module
This module has normative references to [RFC2119], [RFC2986], This module has normative references to [RFC2119], [RFC2986],
[RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958],
[RFC6031], [RFC6125], [RFC6991], [RFC7093], [RFC8174], [RFC8341], and [RFC6031], [RFC6125], [RFC6991], [RFC7093], [RFC8174], [RFC8341], and
[ITU.X690.2015]. [ITU.X690.2015].
<CODE BEGINS> file "ietf-crypto-types@2021-05-18.yang" <CODE BEGINS> file "ietf-crypto-types@2021-09-14.yang"
module ietf-crypto-types { module ietf-crypto-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types";
prefix ct; prefix ct;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
skipping to change at page 28, line 6 skipping to change at page 28, line 37
(https://www.rfc-editor.org/info/rfcAAAA); see the RFC (https://www.rfc-editor.org/info/rfcAAAA); 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-09-14 {
description description
"Initial version"; "Initial version";
reference reference
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; "RFC AAAA: YANG Data Types and Groupings for Cryptography";
} }
/****************/ /****************/
/* Features */ /* Features */
/****************/ /****************/
skipping to change at page 47, line 26 skipping to change at page 48, line 8
This document uses PKCS #10 [RFC2986] for the "generate-certificate- This document uses PKCS #10 [RFC2986] for the "generate-certificate-
signing-request" action. The use of Certificate Request Message signing-request" action. The use of Certificate Request Message
Format (CRMF) [RFC4211] was considered, but it was unclear if there Format (CRMF) [RFC4211] was considered, but it was unclear if there
was market demand for it. If it is desired to support CRMF in the was market demand for it. If it is desired to support CRMF in the
future, a backwards compatible solution can be defined at that time. future, a backwards compatible solution can be defined at that time.
3.2. No Support for Key Generation 3.2. No Support for Key Generation
Early revisions of this document included "rpc" statements for Early revisions of this document included "rpc" statements for
generating symmetric and asymmetric keys. There statements were generating symmetric and asymmetric keys. These statements were
removed due to an inability to obtain consensus for how to identify removed due to an inability to obtain consensus for how to identify
the key-algorithm to use. Thusly, the solution presented in this the key-algorithm to use. Thusly, the solution presented in this
document only supports keys to be configured via an external client, document only supports keys to be configured via an external client,
which does not support Security best practice. which does not support Security best practice.
3.3. Unconstrained Public Key Usage 3.3. Unconstrained Public Key Usage
This module defines the "public-key-grouping" grouping, which enables This module defines the "public-key-grouping" grouping, which enables
the configuration of public keys without constraints on their usage, the configuration of public keys without constraints on their usage,
e.g., what operations the key is allowed to be used for (encryption, e.g., what operations the key is allowed to be used for (encryption,
skipping to change at page 48, line 10 skipping to change at page 48, line 41
This module defines the "asymmetric-key-pair-grouping" grouping, This module defines the "asymmetric-key-pair-grouping" grouping,
which enables the configuration of private keys without constraints which enables the configuration of private keys without constraints
on their usage, e.g., what operations the key is allowed to be used on their usage, e.g., what operations the key is allowed to be used
for (e.g., signature, decryption, both). for (e.g., signature, decryption, both).
The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned
"asymmetric-key-pair-grouping" grouping, whereby configured "asymmetric-key-pair-grouping" grouping, whereby configured
certificates (e.g., identity certificates) may constrain the use of certificates (e.g., identity certificates) may constrain the use of
the public key according to local policy. the public key according to local policy.
3.5. Strength of Keys Configured 3.5. Strength of Keys Conveyed
When configuring key values, implementations SHOULD ensure that the When accessing key values, it is desireable that implementations
strength of the key being configured is not greater than the strength ensure that the strength of the keys being accessed is not greater
of the underlying secure transport connection over which it is than the strength of the underlying secure transport connection over
communicated. Implementations SHOULD fail the write-request if ever which the keys are conveyed. However, comparing key strengths can be
the strength of the private key is greater then the strength of the complicated and difficult to implement in practice.
underlying transport.
That said, expert Security opinion suggests that already it is
infeasible to break a 128-bit symmetric key using a classical
computer, and thus the concern for conveying higher-strength keys
begins to lose its allure.
Implementations SHOULD only use secure transport protocols meeting
local policy. A reasonable policy may, e.g., state that only
ciphersuites listed as "recommended" by the IETF be used (e.g.,
[RFC7525] for TLS).
3.6. Encrypting Passwords 3.6. Encrypting Passwords
The module contained within this document enables passwords to be The module contained within this document enables passwords to be
encrypted. Passwords may be encrypted via a symmetric key using the encrypted. Passwords may be encrypted via a symmetric key using the
"cms-encrypted-data-format" format. This format uses the CMS "cms-encrypted-data-format" format. This format uses the CMS
EncryptedData structure, which allows any encryption algorithm to be EncryptedData structure, which allows any encryption algorithm to be
used. used.
In order to thwart rainbow attacks, algorithms that result in a In order to thwart rainbow attacks, algorithms that result in a
unique output for the same input SHOULD be used. For instance, AES unique output for the same input SHOULD NOT be used. For instance,
using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas
mode is okay since it a unique initialization vector (IV) should be "CBC" mode is permissible since an unpredictable initialization
used for each run. vector (IV) MUST be used for each use.
3.7. Deletion of Cleartext Key Values 3.7. Deletion of Cleartext Key Values
This module defines storage for cleartext key values that SHOULD be This module defines storage for cleartext key values that SHOULD be
zeroized when deleted, so as to prevent the remnants of their zeroized when deleted, so as to prevent the remnants of their
persisted storage locations from being analyzed in any meaningful persisted storage locations from being analyzed in any meaningful
way. way.
The cleartext key values are the "cleartext-key" node defined in the The cleartext key values are the "cleartext-key" node defined in the
"symmetric-key-grouping" grouping (Section 2.1.4.3) and the "symmetric-key-grouping" grouping (Section 2.1.4.3) and the
skipping to change at page 49, line 9 skipping to change at page 49, line 48
The YANG module in this document defines "grouping" statements that The YANG module in this document defines "grouping" statements that
are designed to be accessed via YANG based management protocols, such are designed to be accessed via YANG based management protocols, such
as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
have mandatory-to-implement secure transport layers (e.g., SSH, TLS) have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication. with mutual authentication.
The NETCONF access control model (NACM) [RFC8341] provides the means The NETCONF access control model (NACM) [RFC8341] provides the means
to restrict access for particular users to a pre-configured subset of to restrict access for particular users to a pre-configured subset of
all available protocol operations and content. all available protocol operations and content.
Since the module in this document only define groupings, these Since the module in this document only defines groupings, these
considerations are primarily for the designers of other modules that considerations are primarily for the designers of other modules that
use these groupings. use these groupings.
Some of the readable data nodes defined in this YANG module may be Some of the readable data nodes defined in this YANG module may be
considered sensitive or vulnerable in some network environments. It considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and or notification) to these data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability: data nodes and their sensitivity/vulnerability:
* The "cleartext-key" node: * The "cleartext-key" node:
skipping to change at page 49, line 35 skipping to change at page 50, line 27
all" has been applied to it. all" has been applied to it.
* The "cleartext-private-key" node: * The "cleartext-private-key" node:
The "cleartext-private-key" node defined in the "asymmetric- The "cleartext-private-key" node defined in the "asymmetric-
key-pair-grouping" grouping is additionally sensitive to read key-pair-grouping" grouping is additionally sensitive to read
operations such that, in normal use cases, it should never be operations such that, in normal use cases, it should never be
returned to a client. For this reason, the NACM extension returned to a client. For this reason, the NACM extension
"default-deny-all" has been applied. "default-deny-all" has been applied.
All of the writable data nodes defined by all the groupings defined * The "cert-data" node:
in this module may be considered sensitive or vulnerable in some
network environments. For instance, even the modification of a The "cert-data" node, defined in both the "trust-anchor-cert-
public key or a certificate can dramatically alter the implemented grouping" and "end-entity-cert-grouping" groupings, is
security policy. For this reason, the NACM extension "default-deny- additionally sensitive to read operations, as certificates
write" has been applied to all the data nodes defined in the module. sometimes convey personally identifying information (especially
end-entity certificates). However, as it is commonly
understood that certificates are "public", the NACM extension
"nacm:default-deny-write" (not "default-deny-all") has been
applied. It is RECOMMENDED that implementations adjust read-
access to certificates to comply with local policy.
All the writable data nodes defined by all the groupings defined in
this module may be considered sensitive or vulnerable in some network
environments. For instance, even the modification of a public key or
a certificate can dramatically alter the implemented security policy.
For this reason, the NACM extension "default-deny-write" has been
applied to all the data nodes defined in the module.
Some of the operations in this YANG module may be considered Some of the operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
* generate-certificate-signing-request: * generate-certificate-signing-request:
This "action" statement SHOULD only be executed by authorized This "action" statement SHOULD only be executed by authorized
users. For this reason, the NACM extension "default-deny-all" users. For this reason, the NACM extension "default-deny-all"
skipping to change at page 52, line 23 skipping to change at page 53, line 23
[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>.
5.2. Informative References 5.2. Informative 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-20, 18 May 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-crypto- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
types-19>. crypto-types-20>.
[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>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 54, line 26 skipping to change at page 55, line 26
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[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
skipping to change at page 57, line 34 skipping to change at page 58, line 37
* Modified 'asymmetric-key-pair-grouping' to have a 'choice' * Modified 'asymmetric-key-pair-grouping' to have a 'choice'
statement for the keystone module to augment into, as well as statement for the keystone module to augment into, as well as
replacing the 'union' with leafs (having different NACM settings. replacing the 'union' with leafs (having different NACM settings.
A.10. 08 to 09 A.10. 08 to 09
* Converting algorithm from identities to enumerations. * Converting algorithm from identities to enumerations.
A.11. 09 to 10 A.11. 09 to 10
* All of the below changes are to the algorithm enumerations defined * All the below changes are to the algorithm enumerations defined in
in ietf-crypto-types. ietf-crypto-types.
* Add in support for key exchange over x.25519 and x.448 based on * Add in support for key exchange over x.25519 and x.448 based on
RFC 8418. RFC 8418.
* Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 * Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512
* Revise/add in enum of signature algorithm for x25519 and x448 * Revise/add in enum of signature algorithm for x25519 and x448
* Add in des3-cbc-sha1 for IPSec * Add in des3-cbc-sha1 for IPSec
skipping to change at page 60, line 43 skipping to change at page 61, line 49
* Added an "Encrypting Passwords" section to Security Consideration. * Added an "Encrypting Passwords" section to Security Consideration.
* Addressed other comments raised by YANG Doctor. * Addressed other comments raised by YANG Doctor.
A.21. 19 to 20 A.21. 19 to 20
* Nits found via YANG Doctors reviews. * Nits found via YANG Doctors reviews.
* Aligned modules with `pyang -f` formatting. * Aligned modules with `pyang -f` formatting.
A.22. 20 to 21
* Replaced "base64encodedvalue==" with "BASE64VALUE=".
* Accommodated SecDir review by Valery Smyslov.
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): Balazs Kovacs, Eric on list and in the halls (ordered by first name): Balazs Kovacs, Eric
Voit, Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick Voit, Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick
Hancock, Rich Salz, Rob Wilton, Russ Housley, Sandra Murphy, Tom Hancock, Rich Salz, Rob Wilton, Russ Housley, Sandra Murphy, Tom
Petch, and Wang Haiguang. Petch, Valery Smyslov, and Wang Haiguang.
Author's Address Author's Address
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
Email: kent+ietf@watsen.net Email: kent+ietf@watsen.net
 End of changes. 52 change blocks. 
116 lines changed or deleted 160 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/