idnits 2.17.1 draft-ietf-netconf-trust-anchors-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 452 has weird spacing: '...on-date yan...' == Line 459 has weird spacing: '...-format ide...' == Line 471 has weird spacing: '...on-date yan...' == Line 480 has weird spacing: '...-format ide...' == Line 494 has weird spacing: '...on-date yan...' == (3 more instances...) -- The document date (10 February 2021) is 1171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-20 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-21 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-22 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-08 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-22 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-13 Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track 10 February 2021 5 Expires: 14 August 2021 7 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-14 10 Abstract 12 This document defines a YANG module for configuring bags of 13 certificates and bags of public keys that can be referenced by other 14 data models for trust. Notifications are sent when certificates are 15 about to expire. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains placeholder values that need to be replaced with 20 finalized values at the time of publication. This note summarizes 21 all of the substitutions that are needed. No other RFC Editor 22 instructions are specified elsewhere in this document. 24 Artwork in this document contains shorthand references to drafts in 25 progress. Please apply the following replacements: 27 * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 28 types 30 * "BBBB" --> the assigned RFC value for this draft 32 Artwork in this document contains placeholder values for the date of 33 publication of this draft. Please apply the following replacement: 35 * "2021-02-10" --> the publication date of this draft 37 The following Appendix section is to be removed prior to publication: 39 * Appendix A. Change Log 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 14 August 2021. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 76 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 77 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 78 2. The "ietf-truststore" Module . . . . . . . . . . . . . . . . 5 79 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 80 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 81 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 82 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 29 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 84 4.1. Security of Data at Rest . . . . . . . . . . . . . . . . 32 85 4.2. Unconstrained Public Key Usage . . . . . . . . . . . . . 32 86 4.3. The "ietf-truststore" YANG Module . . . . . . . . . . . . 32 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 33 89 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 33 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 6.1. Normative References . . . . . . . . . . . . . . . . . . 33 92 6.2. Informative References . . . . . . . . . . . . . . . . . 34 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 94 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 36 95 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 36 96 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 36 97 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 36 98 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 36 99 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 37 100 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 37 101 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 37 102 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 37 103 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 37 104 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 38 105 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 38 106 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 38 107 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38 108 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 111 1. Introduction 113 This document defines a YANG 1.1 [RFC7950] module having the 114 following characteristics: 116 Provide a central truststore for storing raw public keys and/or 117 certificates. 119 Provide support for storing named bags of raw public keys and/or 120 named bags of certificates. 122 Provide types that can be used to reference raw public keys or 123 certificates stored in the central truststore. 125 Provide groupings that enable raw public keys and certificates to 126 be configured locally or as references truststore instances. 128 Enable the truststore to be instantiated in other data models, in 129 addition to or in lieu of the central trusttore instance. 131 1.1. Relation to other RFCs 133 This document presents one or more YANG modules [RFC7950] that are 134 part of a collection of RFCs that work together to, ultimately, 135 enable the configuration of the clients and servers of both the 136 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 138 The modules have been defined in a modular fashion to enable their 139 use by other efforts, some of which are known to be in progress at 140 the time of this writing, with many more expected to be defined in 141 time. 143 The normative dependency relationship between the various RFCs in the 144 collection is presented in the below diagram. The labels in the 145 diagram represent the primary purpose provided by each RFC. 146 Hyperlinks to each RFC are provided below the diagram. 148 crypto-types 149 ^ ^ 150 / \ 151 / \ 152 truststore keystore 153 ^ ^ ^ ^ 154 | +---------+ | | 155 | | | | 156 | +------------+ | 157 tcp-client-server | / | | 158 ^ ^ ssh-client-server | | 159 | | ^ tls-client-server 160 | | | ^ ^ http-client-server 161 | | | | | ^ 162 | | | +-----+ +---------+ | 163 | | | | | | 164 | +-----------|--------|--------------+ | | 165 | | | | | | 166 +-----------+ | | | | | 167 | | | | | | 168 | | | | | | 169 netconf-client-server restconf-client-server 171 +=======================+===========================================+ 172 |Label in Diagram | Originating RFC | 173 +=======================+===========================================+ 174 |crypto-types | [I-D.ietf-netconf-crypto-types] | 175 +-----------------------+-------------------------------------------+ 176 |truststore | [I-D.ietf-netconf-trust-anchors] | 177 +-----------------------+-------------------------------------------+ 178 |keystore | [I-D.ietf-netconf-keystore] | 179 +-----------------------+-------------------------------------------+ 180 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 181 +-----------------------+-------------------------------------------+ 182 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 183 +-----------------------+-------------------------------------------+ 184 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 185 +-----------------------+-------------------------------------------+ 186 |http-client-server | [I-D.ietf-netconf-http-client-server] | 187 +-----------------------+-------------------------------------------+ 188 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 189 +-----------------------+-------------------------------------------+ 190 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 191 +-----------------------+-------------------------------------------+ 193 Table 1: Label to RFC Mapping 195 1.2. Specification Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 1.3. Adherence to the NMDA 205 This document in compliant with the Network Management Datastore 206 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 207 during manufacturing (e.g., for trusted well-known services), are 208 expected to appear in (see Section 3). 210 2. The "ietf-truststore" Module 212 This section defines a YANG 1.1 [RFC7950] module that defines a 213 "truststore" and groupings supporting downstream modules to reference 214 the truststore or have locally-defined definitions. 216 This section defines a YANG 1.1 [RFC7950] module called "ietf- 217 truststore". A high-level overview of the module is provided in 218 Section 2.1. Examples illustatrating the module's use are provided 219 in Examples (Section 2.2). The YANG module itself is defined in 220 Section 2.3. 222 2.1. Data Model Overview 224 This section provides an overview of the "ietf-truststore" module in 225 terms of its features, typedefs, groupings, and protocol-accessible 226 nodes. 228 2.1.1. Features 230 The following diagram lists all the "feature" statements defined in 231 the "ietf-truststore" module: 233 Features: 234 +-- truststore-supported 235 +-- local-definitions-supported 236 +-- certificates 237 +-- public-keys 239 | The diagram above uses syntax that is similar to but not 240 | defined in [RFC8340]. 242 2.1.2. Typedefs 244 The following diagram lists the "typedef" statements defined in the 245 "ietf-truststore" module: 247 Typedefs: 248 leafref 249 +-- certificate-bag-ref 250 +-- certificate-ref 251 +-- public-key-bag-ref 252 +-- public-key-ref 254 | The diagram above uses syntax that is similar to but not 255 | defined in [RFC8340]. 257 Comments: 259 * All of the typedefs defined in the "ietf-truststore" module extend 260 the base "leafref" type defined in [RFC7950]. 262 * The leafrefs refer to certificates, public keys, and bags in the 263 truststore, when the truststore module is implemented. 265 * These typedefs are provided as an aid to downstream modules that 266 import the "ietf-truststore" module. 268 2.1.3. Groupings 270 The "ietf-truststore" module defines the following "grouping" 271 statements: 273 * local-or-truststore-certs-grouping 274 * local-or-truststore-public-keys-grouping 275 * truststore-grouping 277 Each of these groupings are presented in the following subsections. 279 2.1.3.1. The "local-or-truststore-certs-grouping" Grouping 281 The following tree diagram [RFC8340] illustrates the "local-or- 282 truststore-certs-grouping" grouping: 284 grouping local-or-truststore-certs-grouping 285 +-- (local-or-truststore) 286 +--:(local) {local-definitions-supported}? 287 | +-- local-definition 288 | +-- certificate* [name] 289 | +-- name? string 290 | +---u ct:trust-anchor-cert-grouping 291 +--:(truststore) {truststore-supported,certificates}? 292 +-- truststore-reference? ts:certificate-bag-ref 294 Comments: 296 * The "local-or-truststore-certs-grouping" grouping is provided 297 soley as convenience to downstream modules that wish to offer an 298 option whether a bag of certificates can be defined locally or as 299 a reference to a bag in the truststore. 301 * A "choice" statement is used to expose the various options. Each 302 option is enabled by a "feature" statement. Additional "case" 303 statements MAY be augmented in if, e.g., there is a need to 304 reference a bag in an alternate location. 306 * For the "local-definition" option, the "certificate" node uses the 307 "trust-anchor-cert-grouping" grouping discussed in Section 2.1.4.7 308 of [I-D.ietf-netconf-crypto-types]. 310 * For the "truststore" option, the "truststore-reference" is an 311 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 313 2.1.3.2. The "local-or-truststore-public-keys-grouping" Grouping 315 The following tree diagram [RFC8340] illustrates the "local-or- 316 truststore-public-keys-grouping" grouping: 318 grouping local-or-truststore-public-keys-grouping 319 +-- (local-or-truststore) 320 +--:(local) {local-definitions-supported}? 321 | +-- local-definition 322 | +-- public-key* [name] 323 | +-- name? string 324 | +---u ct:public-key-grouping 325 +--:(truststore) {truststore-supported,public-keys}? 326 +-- truststore-reference? ts:public-key-bag-ref 328 Comments: 330 * The "local-or-truststore-public-keys-grouping" grouping is 331 provided soley as convenience to downstream modules that wish to 332 offer an option whether a bag of public keys can be defined 333 locally or as a reference to a bag in the truststore. 335 * A "choice" statement is used to expose the various options. Each 336 option is enabled by a "feature" statement. Additional "case" 337 statements MAY be augmented in if, e.g., there is a need to 338 reference a bag in an alternate location. 340 * For the "local-definition" option, the "public-key" node uses the 341 "public-key-grouping" grouping discussed in Section 2.1.4.4 of 342 [I-D.ietf-netconf-crypto-types]. 344 * For the "truststore" option, the "truststore-reference" is an 345 instance of the "certificate-bag-ref" discussed in Section 2.1.2. 347 2.1.3.3. The "truststore-grouping" Grouping 349 The following tree diagram [RFC8340] illustrates the "truststore- 350 grouping" grouping: 352 grouping truststore-grouping 353 +-- certificate-bags! {certificates}? 354 | +-- certificate-bag* [name] 355 | +-- name? string 356 | +-- description? string 357 | +-- certificate* [name] 358 | +-- name? string 359 | +---u ct:trust-anchor-cert-grouping 360 +-- public-key-bags! {public-keys}? 361 +-- public-key-bag* [name] 362 +-- name? string 363 +-- description? string 364 +-- public-key* [name] 365 +-- name? string 366 +---u ct:public-key-grouping 368 Comments: 370 * The "truststore-grouping" grouping defines a truststore instance 371 as being composed of certificates and/or public keys, both of 372 which are enabled by "feature" statements. The stucture 373 supporting certificates and public keys is essentially the same, 374 having an outer list of "bags" containing in inner list of objects 375 (certificates or public keys). The bags enable trust anchors 376 serving a common purpose to be grouped and referenced together. 378 * For certificates, each certificate is defined by the "trust- 379 anchor-cert-grouping" grouping Section 2.1.4.7 of 380 [I-D.ietf-netconf-crypto-types]. Thus the "cert-data" node is a 381 CMS structure that can be composed of a chain of one or more 382 certificates. Additionally, the "certificate-expiration" 383 notification enables the server to alert clients when certificates 384 are nearing or have already expired. 386 * For public keys, each public key is defined by the "public-key- 387 grouping" grouping Section 2.1.4.4 of 388 [I-D.ietf-netconf-crypto-types]. Thus the "public-key" node can 389 be one of any number of structures specified by the "public-key- 390 format" identity node. 392 2.1.4. Protocol-accessible Nodes 394 The following tree diagram [RFC8340] lists all the protocol- 395 accessible nodes defined in the "ietf-truststore" module, without 396 expanding the "grouping" statements: 398 module: ietf-truststore 399 +--rw truststore 400 +---u truststore-grouping 402 grouping local-or-truststore-certs-grouping 403 +-- (local-or-truststore) 404 +--:(local) {local-definitions-supported}? 405 | +-- local-definition 406 | +-- certificate* [name] 407 | +-- name? string 408 | +---u ct:trust-anchor-cert-grouping 409 +--:(truststore) {truststore-supported,certificates}? 410 +-- truststore-reference? ts:certificate-bag-ref 411 grouping local-or-truststore-public-keys-grouping 412 +-- (local-or-truststore) 413 +--:(local) {local-definitions-supported}? 414 | +-- local-definition 415 | +-- public-key* [name] 416 | +-- name? string 417 | +---u ct:public-key-grouping 418 +--:(truststore) {truststore-supported,public-keys}? 419 +-- truststore-reference? ts:public-key-bag-ref 420 grouping truststore-grouping 421 +-- certificate-bags! {certificates}? 422 | +-- certificate-bag* [name] 423 | +-- name? string 424 | +-- description? string 425 | +-- certificate* [name] 426 | +-- name? string 427 | +---u ct:trust-anchor-cert-grouping 428 +-- public-key-bags! {public-keys}? 429 +-- public-key-bag* [name] 430 +-- name? string 431 +-- description? string 432 +-- public-key* [name] 433 +-- name? string 434 +---u ct:public-key-grouping 436 The following tree diagram [RFC8340] lists all the protocol- 437 accessible nodes defined in the "ietf-truststore" module, with all 438 "grouping" statements expanded, enabling the truststore's full 439 structure to be seen: 441 module: ietf-truststore 442 +--rw truststore 443 +--rw certificate-bags! {certificates}? 444 | +--rw certificate-bag* [name] 445 | +--rw name string 446 | +--rw description? string 447 | +--rw certificate* [name] 448 | +--rw name string 449 | +--rw cert-data trust-anchor-cert-cms 450 | +---n certificate-expiration 451 | {certificate-expiration-notification}? 452 | +-- expiration-date yang:date-and-time 453 +--rw public-key-bags! {public-keys}? 454 +--rw public-key-bag* [name] 455 +--rw name string 456 +--rw description? string 457 +--rw public-key* [name] 458 +--rw name string 459 +--rw public-key-format identityref 460 +--rw public-key binary 462 grouping local-or-truststore-certs-grouping 463 +-- (local-or-truststore) 464 +--:(local) {local-definitions-supported}? 465 | +-- local-definition 466 | +-- certificate* [name] 467 | +-- name? string 468 | +-- cert-data trust-anchor-cert-cms 469 | +---n certificate-expiration 470 | {certificate-expiration-notification}? 471 | +-- expiration-date yang:date-and-time 472 +--:(truststore) {truststore-supported,certificates}? 473 +-- truststore-reference? ts:certificate-bag-ref 474 grouping local-or-truststore-public-keys-grouping 475 +-- (local-or-truststore) 476 +--:(local) {local-definitions-supported}? 477 | +-- local-definition 478 | +-- public-key* [name] 479 | +-- name? string 480 | +-- public-key-format identityref 481 | +-- public-key binary 482 +--:(truststore) {truststore-supported,public-keys}? 483 +-- truststore-reference? ts:public-key-bag-ref 484 grouping truststore-grouping 485 +-- certificate-bags! {certificates}? 486 | +-- certificate-bag* [name] 487 | +-- name? string 488 | +-- description? string 489 | +-- certificate* [name] 490 | +-- name? string 491 | +-- cert-data trust-anchor-cert-cms 492 | +---n certificate-expiration 493 | {certificate-expiration-notification}? 494 | +-- expiration-date yang:date-and-time 495 +-- public-key-bags! {public-keys}? 496 +-- public-key-bag* [name] 497 +-- name? string 498 +-- description? string 499 +-- public-key* [name] 500 +-- name? string 501 +-- public-key-format identityref 502 +-- public-key binary 504 Comments: 506 * Protocol-accessible nodes are those nodes that are accessible when 507 the module is "implemented", as described in Section 5.6.5 of 508 [RFC7950]. 510 * The protcol-accessible nodes for the "ietf-truststore" module are 511 an instance of the "truststore-grouping" grouping discussed in 512 Section 2.1.3.3. 514 * The reason for why the "truststore-grouping" exists separate from 515 the protocol-accessible nodes definition is to enable instances of 516 the truststore to be instantiated in other locations, as may be 517 needed or desired by some modules. 519 2.2. Example Usage 521 The examples in this section are encoded using XML, such as might be 522 the case when using the NETCONF protocol. Other encodings MAY be 523 used, such as JSON when using the RESTCONF protocol. 525 2.2.1. A Truststore Instance 527 This section presents an example illustrating trust anchors in 528 , as per Section 2.1.4. Please see Section 3 for an 529 example illustrating built-in values in . 531 The example contained in this secton defines eight bags of trust 532 anchors. There are four certificate-based bags and four public key 533 based bags. The following diagram provides an overview of the 534 contents in the example: 536 Certificate Bags 537 +-- Trust anchor certs for authenticating a set of remote servers 538 +-- End entity certs for authenticating a set of remote servers 539 +-- Trust anchor certs for authenticating a set of remote clients 540 +-- End entity certs for authenticating a set of remote clients 542 Public Key Bags 543 +-- SSH keys to authenticate a set of remote SSH server 544 +-- SSH keys to authenticate a set of remote SSH clients 545 +-- Raw public keys to authenticate a set of remote SSH server 546 +-- Raw public keys to authenticate a set of remote SSH clients 548 Following is the full example: 550 554 555 557 558 559 trusted-server-ca-certs 560 561 Trust anchors (i.e. CA certs) used to authenticate server 562 certificates. A server certificate is authenticated if its 563 end-entity certificate has a chain of trust to one of these 564 certificates. 565 566 567 Server Cert Issuer #1 568 base64encodedvalue== 569 570 571 Server Cert Issuer #2 572 base64encodedvalue== 573 574 576 577 578 trusted-server-ee-certs 579 580 Specific end-entity certificates used to authenticate server 581 certificates. A server certificate is authenticated if its 582 end-entity certificate is an exact match to one of these 583 certificates. 585 586 587 My Application #1 588 base64encodedvalue== 589 590 591 My Application #2 592 base64encodedvalue== 593 594 596 597 598 trusted-client-ca-certs 599 600 Trust anchors (i.e. CA certs) used to authenticate client 601 certificates. A client certificate is authenticated if its 602 end-entity certificate has a chain of trust to one of these 603 certificates. 604 605 606 Client Identity Issuer #1 607 base64encodedvalue== 608 609 610 Client Identity Issuer #2 611 base64encodedvalue== 612 613 615 616 617 trusted-client-ee-certs 618 619 Specific end-entity certificates used to authenticate client 620 certificates. A client certificate is authenticated if its 621 end-entity certificate is an exact match to one of these 622 certificates. 623 624 625 George Jetson 626 base64encodedvalue== 627 628 629 Fred Flintstone 630 base64encodedvalue== 631 632 634 636 637 639 640 641 trusted-ssh-public-keys 642 643 Specific SSH public keys used to authenticate SSH server 644 public keys. An SSH server public key is authenticated if 645 its public key is an exact match to one of these public keys. 647 This list of SSH public keys is analogous to OpenSSH's 648 "/etc/ssh/ssh_known_hosts" file. 649 650 651 corp-fw1 652 653 ct:ssh-public-key-format 654 655 base64encodedvalue== 656 657 658 corp-fw2 659 660 ct:ssh-public-key-format 661 662 base64encodedvalue== 663 664 666 667 668 SSH Public Keys for Application A 669 670 SSH public keys used to authenticate application A's SSH 671 public keys. An SSH public key is authenticated if it 672 is an exact match to one of these public keys. 673 674 675 Application Instance #1 676 677 ct:ssh-public-key-format 678 679 base64encodedvalue== 680 681 682 Application Instance #2 683 684 ct:ssh-public-key-format 685 686 base64encodedvalue== 687 688 690 691 692 Raw Public Keys for TLS Servers 693 694 Raw Public Key #1 695 696 ct:subject-public-key-info-format 697 base64encodedvalue== 698 699 700 Raw Public Key #2 701 702 ct:subject-public-key-info-format 703 704 base64encodedvalue== 705 706 708 709 710 Raw Public Keys for TLS Clients 711 712 Raw Public Key #1 713 714 ct:subject-public-key-info-format 715 716 base64encodedvalue== 717 718 719 Raw Public Key #2 720 721 ct:subject-public-key-info-format 722 723 base64encodedvalue== 724 725 726 727 729 2.2.2. A Certificate Expiration Notification 731 The following example illustrates the "certificate-expiration" 732 notification (per Section 2.1.4.6 of [I-D.ietf-netconf-crypto-types]) 733 for a certificate configured in the truststore in Section 2.2.1. 735 =============== NOTE: '\' line wrapping per RFC 8792 ================ 737 739 2018-05-25T00:01:00Z 740 741 742 743 trusted-client-ee-certs 744 745 George Jetson 746 747 2018-08-05T14:18:53-05:00 749 750 751 752 753 754 756 2.2.3. The "Local or Truststore" Groupings 758 This section illustrates the various "local-or-truststore" groupings 759 defined in the "ietf-truststore" module, specifically the "local-or- 760 truststore-certs-grouping" (Section 2.1.3.1) and "local-or- 761 truststore-public-keys-grouping" (Section 2.1.3.2) groupings. 763 These examples assume the existence of an example module called "ex- 764 truststore-usage" having the namespace "http://example.com/ns/ 765 example-truststore-usage". 767 The ex-truststore-usage module is first presented using tree diagrams 768 [RFC8340], followed by an instance example illustrating all the 769 "local-or-truststore" groupings in use, followed by the YANG module 770 itself. 772 The following tree diagram illustrates "ex-truststore-usage" without 773 expanding the "grouping" statements: 775 module: ex-truststore-usage 776 +--rw truststore-usage 777 +--rw cert* [name] 778 | +--rw name string 779 | +---u ts:local-or-truststore-certs-grouping 780 +--rw public-key* [name] 781 +--rw name string 782 +---u ts:local-or-truststore-public-keys-grouping 784 The following tree diagram illustrates the "ex-truststore-usage" 785 module, with all "grouping" statements expanded, enabling the 786 truststore's full structure to be seen: 788 module: ex-truststore-usage 789 +--rw truststore-usage 790 +--rw cert* [name] 791 | +--rw name string 792 | +--rw (local-or-truststore) 793 | +--:(local) {local-definitions-supported}? 794 | | +--rw local-definition 795 | | +--rw certificate* [name] 796 | | +--rw name string 797 | | +--rw cert-data 798 | | | trust-anchor-cert-cms 799 | | +---n certificate-expiration 800 | | {certificate-expiration-notification}? 801 | | +-- expiration-date yang:date-and-time 802 | +--:(truststore) {truststore-supported,certificates}? 803 | +--rw truststore-reference? ts:certificate-bag-ref 804 +--rw public-key* [name] 805 +--rw name string 806 +--rw (local-or-truststore) 807 +--:(local) {local-definitions-supported}? 808 | +--rw local-definition 809 | +--rw public-key* [name] 810 | +--rw name string 811 | +--rw public-key-format identityref 812 | +--rw public-key binary 813 +--:(truststore) {truststore-supported,public-keys}? 814 +--rw truststore-reference? ts:public-key-bag-ref 816 The following example provides two equivalent instances of each 817 grouping, the first being a reference to a truststore and the second 818 being locally-defined. The instance having a reference to a 819 truststore is consistent with the truststore defined in 820 Section 2.2.1. The two instances are equivalent, as the locally- 821 defined instance example contains the same values defined by the 822 truststore instance referenced by its sibling example. 824 =============== NOTE: '\' line wrapping per RFC 8792 ================ 826 830 831 833 834 example 1a 835 trusted-client-ca-certs 837 839 840 example 1b 841 842 my-trusted-client-ca-certs 843 844 Client Identity Issuer #1 845 base64encodedvalue== 846 847 848 Client Identity Issuer #2 849 base64encodedvalue== 850 851 852 854 855 857 858 example 2a 859 trusted-ssh-public-keys 861 863 864 example 2b 865 866 trusted-ssh-public-keys 867 868 corp-fw1 869 870 ct:ssh-public-key-format 872 873 base64encodedvalue== 874 875 876 corp-fw2 877 878 ct:ssh-public-key-format 879 880 base64encodedvalue== 881 882 883 885 887 Following is the "ex-truststore-usage" module's YANG definition: 889 module ex-truststore-usage { 890 yang-version 1.1; 892 namespace "http://example.com/ns/example-truststore-usage"; 893 prefix "etu"; 895 import ietf-truststore { 896 prefix ts; 897 reference 898 "RFC BBBB: A YANG Data Model for a Truststore"; 899 } 901 organization 902 "Example Corporation"; 904 contact 905 "Author: YANG Designer "; 907 description 908 "This module illustrates notable groupings defined in 909 the 'ietf-truststore' module."; 911 revision "2021-02-10" { 912 description 913 "Initial version"; 914 reference 915 "RFC BBBB: A YANG Data Model for a Truststore"; 916 } 918 container truststore-usage { 919 description 920 "An illustration of the various truststore groupings."; 922 list cert { 923 key name; 924 leaf name { 925 type string; 926 description 927 "An arbitrary name for this cert."; 928 } 929 uses ts:local-or-truststore-certs-grouping; 930 description 931 "An cert that may be configured locally or be 932 a reference to a cert in the truststore."; 933 } 935 list public-key { 936 key name; 937 leaf name { 938 type string; 939 description 940 "An arbitrary name for this cert."; 941 } 942 uses ts:local-or-truststore-public-keys-grouping; 943 description 944 "An public key that may be configured locally or be 945 a reference to a public key in the truststore."; 946 } 947 } 948 } 950 2.3. YANG Module 952 This YANG module imports modules from [RFC8341] and 953 [I-D.ietf-netconf-crypto-types]. 955 file "ietf-truststore@2021-02-10.yang" 957 module ietf-truststore { 958 yang-version 1.1; 959 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 960 prefix ts; 962 import ietf-netconf-acm { 963 prefix nacm; 964 reference 965 "RFC 8341: Network Configuration Access Control Model"; 966 } 967 import ietf-crypto-types { 968 prefix ct; 969 reference 970 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 971 } 973 organization 974 "IETF NETCONF (Network Configuration) Working Group"; 976 contact 977 "WG Web : 978 WG List : 979 Author : Kent Watsen "; 981 description 982 "This module defines a 'truststore' to centralize management 983 of trust anchors including certificates and public keys. 985 Copyright (c) 2020 IETF Trust and the persons identified 986 as authors of the code. All rights reserved. 988 Redistribution and use in source and binary forms, with 989 or without modification, is permitted pursuant to, and 990 subject to the license terms contained in, the Simplified 991 BSD License set forth in Section 4.c of the IETF Trust's 992 Legal Provisions Relating to IETF Documents 993 (https://trustee.ietf.org/license-info). 995 This version of this YANG module is part of RFC BBBB 996 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 997 itself for full legal notices. 999 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1000 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1001 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1002 are to be interpreted as described in BCP 14 (RFC 2119) 1003 (RFC 8174) when, and only when, they appear in all 1004 capitals, as shown here."; 1006 revision 2021-02-10 { 1007 description 1008 "Initial version"; 1009 reference 1010 "RFC BBBB: A YANG Data Model for a Truststore"; 1011 } 1013 /****************/ 1014 /* Features */ 1015 /****************/ 1017 feature truststore-supported { 1018 description 1019 "The 'truststore-supported' feature indicates that the 1020 server supports the truststore (i.e., implements the 1021 'ietf-truststore' module)."; 1022 } 1024 feature local-definitions-supported { 1025 description 1026 "The 'local-definitions-supported' feature indicates that 1027 the server supports locally-defined trust anchors."; 1028 } 1030 feature certificates { 1031 description 1032 "The 'certificates' feature indicates that the server 1033 implements the /truststore/certificate-bags subtree."; 1034 } 1036 feature public-keys { 1037 description 1038 "The 'public-keys' feature indicates that the server 1039 implements the /truststore/public-key-bags subtree."; 1040 } 1042 /****************/ 1043 /* Typedefs */ 1044 /****************/ 1046 typedef certificate-bag-ref { 1047 type leafref { 1048 path "/ts:truststore/ts:certificate-bags/" 1049 + "ts:certificate-bag/ts:name"; 1050 } 1051 description 1052 "This typedef defines a reference to a certificate bag 1053 in the truststore, when this module is implemented."; 1054 } 1056 typedef certificate-ref { 1057 type leafref { 1058 path "/ts:truststore/certificate-bags/certificate-bag" + 1059 "[name = current()/../certificate-bag]/certificate/name"; 1060 } 1061 description 1062 "This typedef defines a reference to a specific certificate 1063 in a certificate bag in the truststore, when this module 1064 is implemented. This typedef requires that there exist a 1065 sibling 'leaf' node called 'certificate-bag' that SHOULD 1066 have the typedef 'certificate-bag-ref'."; 1067 } 1069 typedef public-key-bag-ref { 1070 type leafref { 1071 path "/ts:truststore/ts:public-key-bags/" 1072 + "ts:public-key-bag/ts:name"; 1073 } 1074 description 1075 "This typedef defines a reference to a public key bag 1076 in the truststore, when this module is implemented."; 1077 } 1079 typedef public-key-ref { 1080 type leafref { 1081 path "/ts:truststore/public-key-bags/public-key-bag" + 1082 "[name = current()/../public-key-bag]/" + 1083 "public-key/name"; 1084 } 1085 description 1086 "This typedef defines a reference to a specific public key 1087 in a public key bag in the truststore, when this module is 1088 implemented. This typedef requires that there exist a 1089 sibling 'leaf' node called 'public-key-bag' that SHOULD 1090 have the typedef 'public-key-bag-ref'."; 1091 } 1093 /*****************/ 1094 /* Groupings */ 1095 /*****************/ 1097 grouping local-or-truststore-certs-grouping { 1098 description 1099 "A grouping that allows the certificates to be either 1100 configured locally, within the using data model, or be a 1101 reference to a certificate bag stored in the truststore. 1103 Servers that do not 'implement' this module, and hence 1104 'truststore-supported' is not defined, SHOULD augment 1105 in custom 'case' statements enabling references to the 1106 alternate truststore locations."; 1107 choice local-or-truststore { 1108 nacm:default-deny-write; 1109 mandatory true; 1110 description 1111 "A choice between an inlined definition and a definition 1112 that exists in the truststore."; 1113 case local { 1114 if-feature "local-definitions-supported"; 1115 container local-definition { 1116 description 1117 "A container for locally configured trust anchor 1118 certificates."; 1119 list certificate { 1120 key "name"; 1121 min-elements 1; 1122 description 1123 "A trust anchor certificate."; 1124 leaf name { 1125 type string; 1126 description 1127 "An arbitrary name for this certificate."; 1128 } 1129 uses ct:trust-anchor-cert-grouping { 1130 refine "cert-data" { 1131 mandatory true; 1132 } 1133 } 1134 } 1135 } 1136 } 1137 case truststore { 1138 if-feature "truststore-supported"; 1139 if-feature "certificates"; 1140 leaf truststore-reference { 1141 type ts:certificate-bag-ref; 1142 description 1143 "A reference to a certificate bag that exists in the 1144 truststore, when this module is implemented."; 1145 } 1146 } 1147 } 1148 } 1150 grouping local-or-truststore-public-keys-grouping { 1151 description 1152 "A grouping that allows the public keys to be either 1153 configured locally, within the using data model, or be a 1154 reference to a public key bag stored in the truststore. 1156 Servers that do not 'implement' this module, and hence 1157 'truststore-supported' is not defined, SHOULD augment 1158 in custom 'case' statements enabling references to the 1159 alternate truststore locations."; 1160 choice local-or-truststore { 1161 nacm:default-deny-write; 1162 mandatory true; 1163 description 1164 "A choice between an inlined definition and a definition 1165 that exists in the truststore."; 1166 case local { 1167 if-feature "local-definitions-supported"; 1168 container local-definition { 1169 description 1170 "A container to hold local public key definitions."; 1171 list public-key { 1172 key name; 1173 description 1174 "A public key definition."; 1175 leaf name { 1176 type string; 1177 description 1178 "An arbitrary name for this public key."; 1179 } 1180 uses ct:public-key-grouping; 1181 } 1182 } 1183 } 1184 case truststore { 1185 if-feature "truststore-supported"; 1186 if-feature "public-keys"; 1187 leaf truststore-reference { 1188 type ts:public-key-bag-ref; 1189 description 1190 "A reference to a bag of public keys that exists 1191 in the truststore, when this module is implemented."; 1192 } 1193 } 1194 } 1195 } 1197 grouping truststore-grouping { 1198 description 1199 "A grouping definition that enables use in other contexts. 1200 Where used, implementations MUST augment new 'case' 1201 statements into the various local-or-truststore 'choice' 1202 statements to supply leafrefs to the model-specific 1203 location(s)."; 1204 container certificate-bags { 1205 nacm:default-deny-write; 1206 if-feature "certificates"; 1207 presence 1208 "Indicates that certificate bags have been configured."; 1209 description 1210 "A collection of certificate bags."; 1211 list certificate-bag { 1212 key "name"; 1213 min-elements 1; 1214 description 1215 "A bag of certificates. Each bag of certificates SHOULD 1216 be for a specific purpose. For instance, one bag could 1217 be used to authenticate a specific set of servers, while 1218 another could be used to authenticate a specific set of 1219 clients."; 1220 leaf name { 1221 type string; 1222 description 1223 "An arbitrary name for this bag of certificates."; 1224 } 1225 leaf description { 1226 type string; 1227 description 1228 "A description for this bag of certificates. The 1229 intended purpose for the bag SHOULD be described."; 1230 } 1231 list certificate { 1232 key "name"; 1233 min-elements 1; 1234 description 1235 "A trust anchor certificate."; 1236 leaf name { 1237 type string; 1238 description 1239 "An arbitrary name for this certificate."; 1240 } 1241 uses ct:trust-anchor-cert-grouping { 1242 refine "cert-data" { 1243 mandatory true; 1244 } 1245 } 1246 } 1247 } 1248 } 1249 container public-key-bags { 1250 nacm:default-deny-write; 1251 if-feature "public-keys"; 1252 presence 1253 "Indicates that public keys have been configured."; 1254 description 1255 "A collection of public key bags."; 1256 list public-key-bag { 1257 key "name"; 1258 min-elements 1; 1259 description 1260 "A bag of public keys. Each bag of keys SHOULD be for 1261 a specific purpose. For instance, one bag could be used 1262 authenticate a specific set of servers, while another 1263 could be used to authenticate a specific set of clients."; 1264 leaf name { 1265 type string; 1266 description 1267 "An arbitrary name for this bag of public keys."; 1268 } 1269 leaf description { 1270 type string; 1271 description 1272 "A description for this bag public keys. The 1273 intended purpose for the bag SHOULD be described."; 1274 } 1275 list public-key { 1276 key "name"; 1277 min-elements 1; 1278 description 1279 "A public key."; 1280 leaf name { 1281 type string; 1282 description 1283 "An arbitrary name for this public key."; 1284 } 1285 uses ct:public-key-grouping; 1286 } 1287 } 1288 } 1289 } 1291 /*********************************/ 1292 /* Protocol accessible nodes */ 1293 /*********************************/ 1295 container truststore { 1296 nacm:default-deny-write; 1297 description 1298 "The truststore contains bags of certificates and 1299 public keys."; 1300 uses truststore-grouping; 1302 } 1303 } 1305 1307 3. Support for Built-in Trust Anchors 1309 In some implementations, a server may define some built-in trust 1310 anchors. For instance, there may be built-in trust anchors enabling 1311 the server to securely connect to well-known services (e.g., an SZTP 1312 [RFC8572] bootstrap server) or public CA certificates to connect to 1313 arbitrary services using public PKI. 1315 Built-in trust anchors are expected to be set by a vendor-specific 1316 process. Any ability for operators to modify built-in trust anchors 1317 is outside the scope of this document. 1319 As built-in trust anchors are provided by the server, they are 1320 present in . The example below illustrates what the 1321 truststore in might look like for a server in its 1322 factory default state. 1324 1329 1331 1332 Built-In Manufacturer Trust Anchor Certificates 1333 1334 Certificates built into the device for authenticating 1335 manufacturer-signed objects, such as TLS server certificates, 1336 vouchers, etc. 1337 1338 1339 Manufacturer Root CA Cert 1340 base64encodedvalue== 1341 1342 1344 1345 Built-In Public Trust Anchor Certificates 1346 1347 Certificates built into the device for authenticating 1348 certificates issued by public certificate authorities, 1349 such as the end-entity certificate for web servers. 1350 1351 1352 Public Root CA Cert 1 1353 base64encodedvalue== 1354 1355 1356 Public Root CA Cert 2 1357 base64encodedvalue== 1358 1359 1360 Public Root CA Cert 3 1361 base64encodedvalue== 1362 1363 1365 1366 1368 In order for the built-in bags of trust anchors and/or their trust 1369 anchors to be referenced by configuration, they MUST first be copied 1370 into . 1372 The built-in bags and/or their trust anchors MUST be copied into 1373 using the same "key" values if it is desired for the server 1374 to maintain/update them (e.g., a software update may update a bag of 1375 trusted public CA certificates used for TLS-client connections). 1377 Built-in bags and/or their trust anchors MAY be copied into other 1378 parts of the configuration but, by doing so, they lose their 1379 association to the built-in entries and any assurances afforded by 1380 knowing they are/were built-in. 1382 The built-in bags and/or their trust anchors are immutable by 1383 configuration operations. Servers MUST ignore attempts to modify any 1384 aspect of built-in bags and/or their trust anchors from . 1386 The following example illustrates how a single built-in public CA 1387 certificate from the previous example has been propagated to 1388 : 1390 1393 1395 1396 Built-In Public Trust Anchor Certificates 1397 1398 Certificates built into the device for authenticating 1399 certificates issued by public certificate authorities, 1400 such as the end-entity certificate for web servers. 1402 Only the subset of the certificates that are referenced 1403 by other configuration nodes need to be copied. For 1404 instance, only "Public Root CA Cert 3" is present here. 1406 No new certificates can be added, nor existing certificate 1407 values changed. Missing certificates have no effect on 1408 "operational" when the configuration is applied. 1409 1410 1411 Public Root CA Cert 3 1412 base64encodedvalue== 1413 1414 1416 1417 1419 4. Security Considerations 1421 4.1. Security of Data at Rest 1423 The YANG module defined in this document defines a mechanism called a 1424 "truststore" that, by its name, suggests that its contents are 1425 protected from unauthorized modification. 1427 Security controls for the API (i.e., data in motion) are discussed in 1428 Section 4.3, but controls for the data at rest cannot be specified by 1429 the YANG module. 1431 In order to satisfy the expectations of a "truststore", it is 1432 RECOMMENDED that implementations ensure that the truststore contents 1433 are protected from unauthorized modifications when at rest. 1435 4.2. Unconstrained Public Key Usage 1437 This module enables the configuration of public keys without 1438 constraints on their usage, e.g., what operations the key is allowed 1439 to be used for (encryption, verification, both). 1441 This module also enables the configuration of certificates, where 1442 each certificate may constrain the usage of the public key according 1443 to local policy. 1445 4.3. The "ietf-truststore" YANG Module 1447 The YANG module defined in this document is designed to be accessed 1448 via YANG based management protocols, such as NETCONF [RFC6241] and 1449 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1450 implement secure transport layers (e.g., SSH, TLS) with mutual 1451 authentication. 1453 The NETCONF access control model (NACM) [RFC8341] provides the means 1454 to restrict access for particular users to a pre-configured subset of 1455 all available protocol operations and content. 1457 None of the readable data nodes defined in this YANG module are 1458 considered sensitive or vulnerable in network environments. The NACM 1459 "default-deny-all" extension has not been set for any data nodes 1460 defined in this module. 1462 All of the writable data nodes defined by this module, both in the 1463 "grouping" statements as well as the protocol-accessible "truststore" 1464 instance, may be considered sensitive or vulnerable in some network 1465 environments. For instance, any modification to a trust anchor or 1466 reference to a trust anchor may dramatically alter the implemented 1467 security policy. For this reason, the NACM extension "default-deny- 1468 write" has been set for all data nodes defined in this module. 1470 This module does not define any "rpc" or "action" statements, and 1471 thus the security considerations for such is not provided here. 1473 5. IANA Considerations 1475 5.1. The "IETF XML" Registry 1477 This document registers one URI in the "ns" subregistry of the IETF 1478 XML Registry [RFC3688]. Following the format in [RFC3688], the 1479 following registration is requested: 1481 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 1482 Registrant Contact: The IESG 1483 XML: N/A, the requested URI is an XML namespace. 1485 5.2. The "YANG Module Names" Registry 1487 This document registers one YANG module in the YANG Module Names 1488 registry [RFC6020]. Following the format in [RFC6020], the following 1489 registration is requested: 1491 name: ietf-truststore 1492 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 1493 prefix: ts 1494 reference: RFC BBBB 1496 6. References 1498 6.1. Normative References 1500 [I-D.ietf-netconf-crypto-types] 1501 Watsen, K., "YANG Data Types and Groupings for 1502 Cryptography", Work in Progress, Internet-Draft, draft- 1503 ietf-netconf-crypto-types-18, 20 August 2020, 1504 . 1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1508 Requirement Levels", BCP 14, RFC 2119, 1509 DOI 10.17487/RFC2119, March 1997, 1510 . 1512 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1513 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1514 . 1516 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1517 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1518 May 2017, . 1520 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1521 Access Control Model", STD 91, RFC 8341, 1522 DOI 10.17487/RFC8341, March 2018, 1523 . 1525 6.2. Informative References 1527 [I-D.ietf-netconf-http-client-server] 1528 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1529 Servers", Work in Progress, Internet-Draft, draft-ietf- 1530 netconf-http-client-server-05, 20 August 2020, 1531 . 1534 [I-D.ietf-netconf-keystore] 1535 Watsen, K., "A YANG Data Model for a Keystore", Work in 1536 Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 1537 20 August 2020, . 1540 [I-D.ietf-netconf-netconf-client-server] 1541 Watsen, K., "NETCONF Client and Server Models", Work in 1542 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1543 client-server-21, 20 August 2020, 1544 . 1547 [I-D.ietf-netconf-restconf-client-server] 1548 Watsen, K., "RESTCONF Client and Server Models", Work in 1549 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1550 client-server-21, 20 August 2020, 1551 . 1554 [I-D.ietf-netconf-ssh-client-server] 1555 Watsen, K., "YANG Groupings for SSH Clients and SSH 1556 Servers", Work in Progress, Internet-Draft, draft-ietf- 1557 netconf-ssh-client-server-22, 20 August 2020, 1558 . 1561 [I-D.ietf-netconf-tcp-client-server] 1562 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1563 and TCP Servers", Work in Progress, Internet-Draft, draft- 1564 ietf-netconf-tcp-client-server-08, 20 August 2020, 1565 . 1568 [I-D.ietf-netconf-tls-client-server] 1569 Watsen, K., "YANG Groupings for TLS Clients and TLS 1570 Servers", Work in Progress, Internet-Draft, draft-ietf- 1571 netconf-tls-client-server-22, 20 August 2020, 1572 . 1575 [I-D.ietf-netconf-trust-anchors] 1576 Watsen, K., "A YANG Data Model for a Truststore", Work in 1577 Progress, Internet-Draft, draft-ietf-netconf-trust- 1578 anchors-13, 20 August 2020, . 1581 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1582 DOI 10.17487/RFC3688, January 2004, 1583 . 1585 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1586 the Network Configuration Protocol (NETCONF)", RFC 6020, 1587 DOI 10.17487/RFC6020, October 2010, 1588 . 1590 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1591 and A. Bierman, Ed., "Network Configuration Protocol 1592 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1593 . 1595 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1596 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1597 . 1599 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1600 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1601 . 1603 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1604 and R. Wilton, "Network Management Datastore Architecture 1605 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1606 . 1608 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1609 Touch Provisioning (SZTP)", RFC 8572, 1610 DOI 10.17487/RFC8572, April 2019, 1611 . 1613 Appendix A. Change Log 1615 This section is to be removed before publishing as an RFC. 1617 A.1. 00 to 01 1619 * Added features "x509-certificates" and "ssh-host-keys". 1621 * Added nacm:default-deny-write to "trust-anchors" container. 1623 A.2. 01 to 02 1625 * Switched "list pinned-certificate" to use the "trust-anchor-cert- 1626 grouping" from crypto-types. Effectively the same definition as 1627 before. 1629 A.3. 02 to 03 1631 * Updated copyright date, boilerplate template, affiliation, folding 1632 algorithm, and reformatted the YANG module. 1634 A.4. 03 to 04 1636 * Added groupings 'local-or-truststore-certs-grouping' and 'local- 1637 or-truststore-host-keys-grouping', matching similar definitions in 1638 the keystore draft. Note new (and incomplete) "truststore" usage! 1640 * Related to above, also added features 'truststore-supported' and 1641 'local-trust-anchors-supported'. 1643 A.5. 04 to 05 1645 * Renamed "trust-anchors" to "truststore" 1647 * Removed "pinned." prefix everywhere, to match truststore rename 1649 * Moved everything under a top-level 'grouping' to enable use in 1650 other contexts. 1652 * Renamed feature from 'local-trust-anchors-supported' to 'local- 1653 definitions-supported' (same name used in keystore) 1655 * Removed the "require-instance false" statement from the "*-ref" 1656 typedefs. 1658 * Added missing "ssh-host-keys" and "x509-certificates" if-feature 1659 statements 1661 A.6. 05 to 06 1663 * Editorial changes only. 1665 A.7. 06 to 07 1667 * Added Henk Birkholz as a co-author (thanks Henk!) 1669 * Added PSKs and raw public keys to truststore. 1671 A.8. 07 to 08 1673 * Added new "Support for Built-in Trust Anchors" section. 1675 * Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1677 * Removed PSK from model. 1679 A.9. 08 to 09 1681 * Removed remaining PSK references from text. 1683 * Wrapped each top-level list with a container. 1685 * Introduced "bag" term. 1687 * Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1688 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1689 [client/server]) refine the "public-key-format" to be either SSH 1690 or TLS specific as needed. 1692 A.10. 09 to 10 1694 * Removed "algorithm" node from examples. 1696 * Removed the no longer used statements supporting the old "ssh- 1697 public-key" and "raw-public-key" nodes. 1699 * Added a "Note to Reviewers" note to first page. 1701 A.11. 10 to 11 1703 * Corrected module prefix registered in the IANA Considerations 1704 section. 1706 * Modified 'local-or-truststore-certs-grouping' to use a list (not a 1707 leaf-list). 1709 * Added new example section "The Local or Truststore Groupings". 1711 * Clarified expected behavior for "built-in" certificates in 1712 1714 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1715 diagrams]. 1717 * Updated the Security Considerations section. 1719 A.12. 11 to 12 1721 * Fixed a copy/paste issue in the "Data at Rest" Security 1722 Considerations section. 1724 A.13. 12 to 13 1726 * Fixed issues found by the SecDir review of the "keystore" draft. 1728 A.14. 13 to 14 1730 * Added an "Unconstrained Public Key Usage" Security Consideration 1731 to address concern raised by SecDir. 1733 * Addressed comments raised by YANG Doctor. 1735 Acknowledgements 1737 The authors especially thank Henk Birkholz for contributing YANG to 1738 the ietf-truststore module supporting raw public keys and PSKs (pre- 1739 shared or pairwise-symmetric keys). While these contributions were 1740 eventually replaced by reusing the existing support for asymmetric 1741 and symmetric trust anchors, respectively, it was only thru Henk's 1742 initiative that the WG was able to come to that result. 1744 The authors additionally thank the following for helping give shape 1745 to this work (ordered by first name): Balazs Kovacs, Eric Voit, 1746 Juergen Schoenwaelder, Liang Xia, Martin Bjorklund, Nick Hancock, and 1747 Yoav Nir. 1749 Author's Address 1751 Kent Watsen 1752 Watsen Networks 1754 Email: kent+ietf@watsen.net