< draft-ietf-netconf-trust-anchors-15.txt   draft-ietf-netconf-trust-anchors-16.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 Truststore A YANG Data Model for a Truststore
draft-ietf-netconf-trust-anchors-15 draft-ietf-netconf-trust-anchors-16
Abstract Abstract
This document defines a YANG module for configuring bags of This document defines a YANG module for configuring bags of
certificates and bags of public keys that can be referenced by other certificates and bags of public keys that can be referenced by other
data models for trust. Notifications are sent when certificates are data models for trust. Notifications are sent when certificates are
about to expire. 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
* "BBBB" --> the assigned RFC value for this draft * BBBB --> 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 . . . . . . . . . . . . . . . . . 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
2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 5 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 6
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21
3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 29 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32
4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32 4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32
4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32 4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32
4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32 4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33
skipping to change at page 2, line 52 skipping to change at page 3, line 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32
4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32 4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32
4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32 4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32
4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32 4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33
5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 33 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References . . . . . . . . . . . . . . . . . . 33 6.1. Normative References . . . . . . . . . . . . . . . . . . 33
6.2. Informative References . . . . . . . . . . . . . . . . . 34 6.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 36 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 36 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 36 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 36 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 36 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 38 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 38
A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document defines a YANG 1.1 [RFC7950] module having the This document defines a YANG 1.1 [RFC7950] module having the
following characteristics: following characteristics:
Provide a central truststore for storing raw public keys and/or Provide a central truststore for storing raw public keys and/or
certificates. certificates.
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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]. For instance, trust anchors installed Architecture (NMDA) [RFC8342]. For instance, trust anchors installed
during manufacturing (e.g., for trusted well-known services), are during manufacturing (e.g., for trusted well-known services), are
expected to appear in <operational> (see Section 3). expected to appear in <operational> (see Section 3).
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-truststore" Module 2. The "ietf-truststore" Module
This section defines a YANG 1.1 [RFC7950] module that defines a This section defines a YANG 1.1 [RFC7950] module that defines a
"truststore" and groupings supporting downstream modules to reference "truststore" and groupings supporting downstream modules to reference
the truststore or have locally-defined definitions. the truststore or have locally-defined definitions.
This section defines a YANG 1.1 [RFC7950] module called "ietf- This section defines a YANG 1.1 [RFC7950] module called "ietf-
truststore". A high-level overview of the module is provided in truststore". 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
skipping to change at page 6, line 48 skipping to change at page 7, line 5
+-- certificate-bag-ref +-- certificate-bag-ref
+-- certificate-ref +-- certificate-ref
+-- public-key-bag-ref +-- public-key-bag-ref
+-- public-key-ref +-- public-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-truststore" module extend * All the typedefs defined in the "ietf-truststore" module extend
the base "leafref" type defined in [RFC7950]. the base "leafref" type defined in [RFC7950].
* The leafrefs refer to certificates, public keys, and bags in the * The leafrefs refer to certificates, public keys, and bags in the
central truststore, when this module is implemented. central truststore, 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-truststore" module. import the "ietf-truststore" module.
2.1.3. Groupings 2.1.3. Groupings
skipping to change at page 13, line 37 skipping to change at page 13, line 37
<certificate-bag> <certificate-bag>
<name>trusted-server-ca-certs</name> <name>trusted-server-ca-certs</name>
<description> <description>
Trust anchors (i.e. CA certs) used to authenticate server Trust anchors (i.e. CA certs) used to authenticate server
certificates. A server certificate is authenticated if its certificates. A server certificate is authenticated if its
end-entity certificate has a chain of trust to one of these end-entity certificate has a chain of trust to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>Server Cert Issuer #1</name> <name>Server Cert Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Server Cert Issuer #2</name> <name>Server Cert Issuer #2</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
<!-- End Entity Certs for Authenticating Servers --> <!-- End Entity Certs for Authenticating Servers -->
<certificate-bag> <certificate-bag>
<name>trusted-server-ee-certs</name> <name>trusted-server-ee-certs</name>
<description> <description>
Specific end-entity certificates used to authenticate server Specific end-entity certificates used to authenticate server
certificates. A server certificate is authenticated if its certificates. A server certificate is authenticated if its
end-entity certificate is an exact match to one of these end-entity certificate is an exact match to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>My Application #1</name> <name>My Application #1</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>My Application #2</name> <name>My Application #2</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
<!-- Trust Anchor Certs for Authenticating Clients --> <!-- Trust Anchor Certs for Authenticating Clients -->
<certificate-bag> <certificate-bag>
<name>trusted-client-ca-certs</name> <name>trusted-client-ca-certs</name>
<description> <description>
Trust anchors (i.e. CA certs) used to authenticate client Trust anchors (i.e. CA certs) used to authenticate client
certificates. A client certificate is authenticated if its certificates. A client certificate is authenticated if its
end-entity certificate has a chain of trust to one of these end-entity certificate has a chain of trust to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>Client Identity Issuer #1</name> <name>Client Identity Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Client Identity Issuer #2</name> <name>Client Identity Issuer #2</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
<!-- End Entity Certs for Authenticating Clients --> <!-- End Entity Certs for Authenticating Clients -->
<certificate-bag> <certificate-bag>
<name>trusted-client-ee-certs</name> <name>trusted-client-ee-certs</name>
<description> <description>
Specific end-entity certificates used to authenticate client Specific end-entity certificates used to authenticate client
certificates. A client certificate is authenticated if its certificates. A client certificate is authenticated if its
end-entity certificate is an exact match to one of these end-entity certificate is an exact match to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>George Jetson</name> <name>George Jetson</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Fred Flintstone</name> <name>Fred Flintstone</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
<!-- A List of Public Key Bags --> <!-- A List of Public Key Bags -->
<public-key-bags> <public-key-bags>
<!-- Public Keys for Authenticating SSH Servers --> <!-- Public Keys for Authenticating SSH Servers -->
<public-key-bag> <public-key-bag>
skipping to change at page 15, line 26 skipping to change at page 15, line 26
its public key is an exact match to one of these public keys. its public key is an exact match to one of these public keys.
This list of SSH public keys is analogous to OpenSSH's This list of SSH public keys is analogous to OpenSSH's
"/etc/ssh/ssh_known_hosts" file. "/etc/ssh/ssh_known_hosts" file.
</description> </description>
<public-key> <public-key>
<name>corp-fw1</name> <name>corp-fw1</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>
</public-key> </public-key>
<public-key> <public-key>
<name>corp-fw2</name> <name>corp-fw2</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>
</public-key> </public-key>
</public-key-bag> </public-key-bag>
<!-- SSH Public Keys for Authenticating Application A --> <!-- SSH Public Keys for Authenticating Application A -->
<public-key-bag> <public-key-bag>
<name>SSH Public Keys for Application A</name> <name>SSH Public Keys for Application A</name>
<description> <description>
SSH public keys used to authenticate application A's SSH SSH public keys used to authenticate application A's SSH
public keys. An SSH public key is authenticated if it public keys. An SSH public key is authenticated if it
is an exact match to one of these public keys. is an exact match to one of these public keys.
</description> </description>
<public-key> <public-key>
<name>Application Instance #1</name> <name>Application Instance #1</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>
</public-key> </public-key>
<public-key> <public-key>
<name>Application Instance #2</name> <name>Application Instance #2</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>
</public-key> </public-key>
</public-key-bag> </public-key-bag>
<!-- Raw Public Keys for TLS Servers --> <!-- Raw Public Keys for TLS Servers -->
<public-key-bag> <public-key-bag>
<name>Raw Public Keys for TLS Servers</name> <name>Raw Public Keys for TLS Servers</name>
<public-key> <public-key>
<name>Raw Public Key #1</name> <name>Raw Public Key #1</name>
<public-key-format> <public-key-format>
ct:subject-public-key-info-format</public-key-format> ct:subject-public-key-info-format</public-key-format>
<public-key>base64encodedvalue==</public-key> <public-key>BASE64VALUE=</public-key>
</public-key> </public-key>
<public-key> <public-key>
<name>Raw Public Key #2</name> <name>Raw Public Key #2</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>
</public-key> </public-key>
</public-key-bag> </public-key-bag>
<!-- Raw Public Keys for TLS Clients --> <!-- Raw Public Keys for TLS Clients -->
<public-key-bag> <public-key-bag>
<name>Raw Public Keys for TLS Clients</name> <name>Raw Public Keys for TLS Clients</name>
<public-key> <public-key>
<name>Raw Public Key #1</name> <name>Raw Public Key #1</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>
</public-key> </public-key>
<public-key> <public-key>
<name>Raw Public Key #2</name> <name>Raw Public Key #2</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>
</public-key> </public-key>
</public-key-bag> </public-key-bag>
</public-key-bags> </public-key-bags>
</truststore> </truststore>
2.2.2. A Certificate Expiration Notification 2.2.2. A Certificate Expiration Notification
The following example illustrates the "certificate-expiration" The following example illustrates the "certificate-expiration"
notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types]) notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types])
for a certificate configured in the truststore in Section 2.2.1. for a certificate configured in the truststore in Section 2.2.1.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
<truststore-reference>trusted-client-ca-certs</truststore-refere\ <truststore-reference>trusted-client-ca-certs</truststore-refere\
nce> nce>
</cert> </cert>
<cert> <cert>
<name>example 1b</name> <name>example 1b</name>
<local-definition> <local-definition>
<name>my-trusted-client-ca-certs</name> <name>my-trusted-client-ca-certs</name>
<certificate> <certificate>
<name>Client Identity Issuer #1</name> <name>Client Identity Issuer #1</name>
<cert>base64encodedvalue==</cert> <cert>BASE64VALUE=</cert>
</certificate> </certificate>
<certificate> <certificate>
<name>Client Identity Issuer #2</name> <name>Client Identity Issuer #2</name>
<cert>base64encodedvalue==</cert> <cert>BASE64VALUE=</cert>
</certificate> </certificate>
</local-definition> </local-definition>
</cert> </cert>
<!-- The following two equivalent examples illustrate the --> <!-- The following two equivalent examples illustrate the -->
<!-- "local-or-truststore-public-keys-grouping" grouping: --> <!-- "local-or-truststore-public-keys-grouping" grouping: -->
<public-key> <public-key>
<name>example 2a</name> <name>example 2a</name>
<truststore-reference>trusted-ssh-public-keys</truststore-refere\ <truststore-reference>trusted-ssh-public-keys</truststore-refere\
skipping to change at page 20, line 13 skipping to change at page 20, line 13
</public-key> </public-key>
<public-key> <public-key>
<name>example 2b</name> <name>example 2b</name>
<local-definition> <local-definition>
<name>trusted-ssh-public-keys</name> <name>trusted-ssh-public-keys</name>
<public-key> <public-key>
<name>corp-fw1</name> <name>corp-fw1</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>
</public-key> </public-key>
<public-key> <public-key>
<name>corp-fw2</name> <name>corp-fw2</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>
</public-key> </public-key>
</local-definition> </local-definition>
</public-key> </public-key>
</truststore-usage> </truststore-usage>
Following is the "ex-truststore-usage" module's YANG definition: Following is the "ex-truststore-usage" module's YANG definition:
module ex-truststore-usage { module ex-truststore-usage {
yang-version 1.1; yang-version 1.1;
skipping to change at page 20, line 50 skipping to change at page 20, line 50
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-truststore' module."; the 'ietf-truststore' module.";
revision 2021-05-18 { revision 2021-12-14 {
description description
"Initial version"; "Initial version";
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
} }
container truststore-usage { container truststore-usage {
description description
"An illustration of the various truststore groupings."; "An illustration of the various truststore groupings.";
list cert { list cert {
skipping to change at page 21, line 44 skipping to change at page 21, line 44
a reference to a public key in the truststore."; a reference to a public key in the truststore.";
} }
} }
} }
2.3. YANG Module 2.3. YANG Module
This YANG module imports modules from [RFC8341] and This YANG module imports modules from [RFC8341] and
[I-D.ietf-netconf-crypto-types]. [I-D.ietf-netconf-crypto-types].
<CODE BEGINS> file "ietf-truststore@2021-05-18.yang" <CODE BEGINS> file "ietf-truststore@2021-12-14.yang"
module ietf-truststore { module ietf-truststore {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; namespace "urn:ietf:params:xml:ns:yang:ietf-truststore";
prefix ts; prefix ts;
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 22, line 48 skipping to change at page 22, line 48
(https://www.rfc-editor.org/info/rfcBBBB); see the RFC (https://www.rfc-editor.org/info/rfcBBBB); 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 BBBB: A YANG Data Model for a Truststore"; "RFC BBBB: A YANG Data Model for a Truststore";
} }
/****************/ /****************/
/* Features */ /* Features */
/****************/ /****************/
skipping to change at page 29, line 18 skipping to change at page 29, line 18
anchors. For instance, there may be built-in trust anchors enabling anchors. For instance, there may be built-in trust anchors enabling
the server to securely connect to well-known services (e.g., an SZTP the server to securely connect to well-known services (e.g., an SZTP
[RFC8572] bootstrap server) or public CA certificates to connect to [RFC8572] bootstrap server) or public CA certificates to connect to
arbitrary services using public PKI. arbitrary services using public PKI.
Built-in trust anchors are expected to be set by a vendor-specific Built-in trust anchors are expected to be set by a vendor-specific
process. Any ability for operators to modify built-in trust anchors process. Any ability for operators to modify built-in trust anchors
is outside the scope of this document. is outside the scope of this document.
As built-in trust anchors are provided by the server, they are As built-in trust anchors are provided by the server, they are
present in <operational>. The example below illustrates what the present in <operational>, if used. The example below illustrates
truststore in <operational> might look like for a server in its what the truststore in <operational> might look like for a server in
factory default state. its factory default state.
<truststore <truststore
xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore" xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
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">
<certificate-bags> <certificate-bags>
<certificate-bag or:origin="or:system"> <certificate-bag or:origin="or:system">
<name>Built-In Manufacturer Trust Anchor Certificates</name> <name>Built-In Manufacturer Trust Anchor Certificates</name>
<description> <description>
Certificates built into the device for authenticating Certificates built into the device for authenticating
manufacturer-signed objects, such as TLS server certificates, manufacturer-signed objects, such as TLS server certificates,
vouchers, etc. vouchers, etc.
</description> </description>
<certificate> <certificate>
<name>Manufacturer Root CA Cert</name> <name>Manufacturer Root CA Cert</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
<certificate-bag or:origin="or:system"> <certificate-bag or:origin="or:system">
<name>Built-In Public Trust Anchor Certificates</name> <name>Built-In Public Trust Anchor Certificates</name>
<description> <description>
Certificates built into the device for authenticating Certificates built into the device for authenticating
certificates issued by public certificate authorities, certificates issued by public certificate authorities,
such as the end-entity certificate for web servers. such as the end-entity certificate for web servers.
</description> </description>
<certificate> <certificate>
<name>Public Root CA Cert 1</name> <name>Public Root CA Cert 1</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Public Root CA Cert 2</name> <name>Public Root CA Cert 2</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Public Root CA Cert 3</name> <name>Public Root CA Cert 3</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
</truststore> </truststore>
In order for the built-in bags of trust anchors and/or their trust In order for the built-in bags of trust anchors and/or their trust
anchors to be referenced by configuration, they MUST first be copied anchors to be referenced by configuration, they MUST first be copied
into <running>. into <running>.
skipping to change at page 31, line 45 skipping to change at page 31, line 45
Only the subset of the certificates that are referenced Only the subset of the certificates that are referenced
by other configuration nodes need to be copied. For by other configuration nodes need to be copied. For
instance, only "Public Root CA Cert 3" is present here. instance, only "Public Root CA Cert 3" is present here.
No new certificates can be added, nor existing certificate No new certificates can be added, nor existing certificate
values changed. Missing certificates have no effect on values changed. Missing certificates have no effect on
"operational" when the configuration is applied. "operational" when the configuration is applied.
</description> </description>
<certificate> <certificate>
<name>Public Root CA Cert 3</name> <name>Public Root CA Cert 3</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
</truststore> </truststore>
4. Security Considerations 4. Security Considerations
4.1. Security of Data at Rest 4.1. Security of Data at Rest
skipping to change at page 33, line 5 skipping to change at page 33, line 5
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.
None of the readable data nodes defined in this YANG module are None of the readable data nodes defined in this YANG module are
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.
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 "truststore" "grouping" statements as well as the protocol-accessible "truststore"
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 trust anchor or environments. For instance, any modification to a trust anchor or
reference to a trust anchor may dramatically alter the implemented reference to a trust anchor may dramatically alter the implemented
security policy. For this reason, the NACM extension "default-deny- security policy. For this reason, the NACM extension "default-deny-
write" has been set for all data nodes defined in this module. write" has been set for 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 33, line 46 skipping to change at page 33, line 46
prefix: ts prefix: ts
reference: RFC BBBB reference: RFC BBBB
6. References 6. References
6.1. Normative References 6.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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
skipping to change at page 34, line 28 skipping to change at page 34, line 28
[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>.
6.2. Informative References 6.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>.
[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 39, line 17 skipping to change at page 39, line 17
* Associated with above, generally moved text to refer to a * Associated with above, generally moved text to refer to a
"central" truststore. "central" truststore.
* Removed two unecessary/unwanted "min-elements 1" and associated * Removed two unecessary/unwanted "min-elements 1" and associated
"presence" statements. "presence" statements.
* 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.16. 15 to 16
* Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.
* Minor editorial nits
Acknowledgements Acknowledgements
The authors especially thank Henk Birkholz for contributing YANG to The authors especially thank Henk Birkholz for contributing YANG to
the ietf-truststore module supporting raw public keys and PSKs (pre- the ietf-truststore module supporting raw public keys and PSKs (pre-
shared or pairwise-symmetric keys). While these contributions were shared or pairwise-symmetric keys). While these contributions were
eventually replaced by reusing the existing support for asymmetric eventually replaced by reusing the existing support for asymmetric
and symmetric trust anchors, respectively, it was only thru Henk's and symmetric trust anchors, respectively, it was only thru Henk's
initiative that the WG was able to come to that result. initiative that the WG was able to come to that result.
The authors additionally thank the following for helping give shape The authors additionally thank the following for helping give shape
 End of changes. 52 change blocks. 
71 lines changed or deleted 88 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/