idnits 2.17.1 draft-ietf-netconf-keystore-09.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 167 has weird spacing: '...gorithm asy...' == Line 178 has weird spacing: '...on-date yan...' == Line 184 has weird spacing: '...request bin...' == Line 195 has weird spacing: '...gorithm asy...' == Line 213 has weird spacing: '...gorithm asy...' == (4 more instances...) -- The document date (April 29, 2019) is 1816 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-05 Summary: 0 errors (**), 0 flaws (~~), 8 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 April 29, 2019 5 Expires: October 31, 2019 7 YANG Data Model for a Centralized Keystore Mechanism 8 draft-ietf-netconf-keystore-09 10 Abstract 12 This document defines a YANG 1.1 module called "ietf-keystore" that 13 enables centralized configuration of asymmetric keys and their 14 associated certificates, and notification for when configured 15 certificates are about to expire. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains many placeholder values that need to be replaced 20 with finalized values at the time of publication. This note 21 summarizes all of the substitutions that are needed. No other RFC 22 Editor 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 o "VVVV" --> the assigned RFC value for this draft 29 Artwork in this document contains placeholder values for the date of 30 publication of this draft. Please apply the following replacement: 32 o "2019-04-29" --> the publication date of this draft 34 The following Appendix section is to be removed prior to publication: 36 o Appendix A. Change Log 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 31, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 3. The Keystore Model . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 77 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18 81 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 18 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 84 6.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 86 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 20 87 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 20 88 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 20 89 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 20 90 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 21 91 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 21 92 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 21 93 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 21 94 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 This document defines a YANG 1.1 [RFC7950] module called "ietf- 101 keystore" that enables centralized configuration of asymmetric keys 102 and their associated certificates, and notification for when 103 configured certificates are about to expire. 105 This module also defines Six groupings designed for maximum reuse. 106 These groupings include one for the public half of an asymmetric key, 107 one for both the public and private halves of an asymmetric key, one 108 for both halves of an asymmetric key and a list of associated 109 certificates, one for an asymmetric key that may be configured 110 locally or via a reference to an asymmetric key in the keystore, one 111 for a trust anchor certificate and, lastly, one for an end entity 112 certificate. 114 Special consideration has been given for systems that have 115 cryptographic hardware, such as a Trusted Protection Module (TPM). 116 These systems are unique in that the cryptographic hardware 117 completely hides the private keys and must perform all private key 118 operations. To support such hardware, the "private-key" can be the 119 special value "permanently-hidden" and the actions "generate-hidden- 120 key" and "generate-certificate-signing-request" can be used to direct 121 these operations to the hardware . 123 This document in compliant with Network Management Datastore 124 Architecture (NMDA) [RFC8342]. For instance, to support keys and 125 associated certificates installed during manufacturing (e.g., for a 126 IDevID [Std-802.1AR-2009] certificate), it is expected that such data 127 may appear only in . 129 While only asymmetric keys are currently supported, the module has 130 been designed to enable other key types to be introduced in the 131 future. 133 The module does not support protecting the contents of the keystore 134 (e.g., via encryption), though it could be extended to do so in the 135 future. 137 It is not required that a system has an operating system level 138 keystore utility to implement this module. 140 2. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. The Keystore Model 150 3.1. Tree Diagram 152 This section provides a tree diagrams [RFC8340] for the "ietf- 153 keystore" module that presents both the protocol-accessible 154 "keystore" as well the all the groupings intended for external usage. 156 module: ietf-keystore 157 +--rw keystore 158 +--rw asymmetric-keys 159 +--rw asymmetric-key* [name] 160 +--rw name string 161 +--rw algorithm? 162 | asymmetric-key-algorithm-ref 163 +--rw public-key? binary 164 +--rw private-key? union 165 +---x generate-hidden-key 166 | +---w input 167 | +---w algorithm asymmetric-key-algorithm-ref 168 +---x install-hidden-key 169 | +---w input 170 | +---w algorithm asymmetric-key-algorithm-ref 171 | +---w public-key? binary 172 | +---w private-key? binary 173 +--rw certificates 174 | +--rw certificate* [name] 175 | +--rw name string 176 | +--rw cert? end-entity-cert-cms 177 | +---n certificate-expiration 178 | +-- expiration-date yang:date-and-time 179 +---x generate-certificate-signing-request 180 +---w input 181 | +---w subject binary 182 | +---w attributes? binary 183 +--ro output 184 +--ro certificate-signing-request binary 186 grouping local-or-keystore-asymmetric-key-grouping 187 +-- (local-or-keystore) 188 +--:(local) {local-keys-supported}? 189 | +-- local-definition 190 | +-- algorithm? asymmetric-key-algorithm-ref 191 | +-- public-key? binary 192 | +-- private-key? union 193 | +---x generate-hidden-key 194 | | +---w input 195 | | +---w algorithm asymmetric-key-algorithm-ref 196 | +---x install-hidden-key 197 | +---w input 198 | +---w algorithm asymmetric-key-algorithm-ref 199 | +---w public-key? binary 200 | +---w private-key? binary 201 +--:(keystore) {keystore-supported}? 202 +-- keystore-reference? ks:asymmetric-key-ref 203 grouping local-or-keystore-asymmetric-key-with-certs-grouping 204 +-- (local-or-keystore) 205 +--:(local) {local-keys-supported}? 206 | +-- local-definition 207 | +-- algorithm? 208 | | asymmetric-key-algorithm-ref 209 | +-- public-key? binary 210 | +-- private-key? union 211 | +---x generate-hidden-key 212 | | +---w input 213 | | +---w algorithm asymmetric-key-algorithm-ref 214 | +---x install-hidden-key 215 | | +---w input 216 | | +---w algorithm asymmetric-key-algorithm-ref 217 | | +---w public-key? binary 218 | | +---w private-key? binary 219 | +-- certificates 220 | | +-- certificate* [name] 221 | | +-- name? string 222 | | +-- cert? end-entity-cert-cms 223 | | +---n certificate-expiration 224 | | +-- expiration-date yang:date-and-time 225 | +---x generate-certificate-signing-request 226 | +---w input 227 | | +---w subject binary 228 | | +---w attributes? binary 229 | +--ro output 230 | +--ro certificate-signing-request binary 231 +--:(keystore) {keystore-supported}? 232 +-- keystore-reference? ks:asymmetric-key-ref 233 grouping local-or-keystore-end-entity-cert-with-key-grouping 234 +-- (local-or-keystore) 235 +--:(local) {local-keys-supported}? 236 | +-- local-definition 237 | +-- algorithm? 238 | | asymmetric-key-algorithm-ref 239 | +-- public-key? binary 240 | +-- private-key? union 241 | +---x generate-hidden-key 242 | | +---w input 243 | | +---w algorithm asymmetric-key-algorithm-ref 244 | +---x install-hidden-key 245 | | +---w input 246 | | +---w algorithm asymmetric-key-algorithm-ref 247 | | +---w public-key? binary 248 | | +---w private-key? binary 249 | +-- cert? end-entity-cert-cms 250 | +---n certificate-expiration 251 | +-- expiration-date yang:date-and-time 252 +--:(keystore) {keystore-supported}? 253 +-- keystore-reference? ks:asymmetric-key-certificate-ref 255 3.2. Example Usage 257 The following example illustrates what a fully configured keystore 258 might look like in , as described by Section 5.3 in 259 [RFC8342]. This datastore view illustrates data set by the 260 manufacturing process alongside conventional configuration. This 261 keystore instance has four keys, two having one associated 262 certificate, one having two associated certificates, and one empty 263 key. 265 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 267 271 273 274 ex-rsa-key 275 ct:rsa2048 276 base64encodedvalue== 277 base64encodedvalue== 278 279 280 ex-rsa-cert 281 base64encodedvalue== 282 283 285 287 302 303 tpm-protected-key 304 ct:rsa2048 305 permanently-hidden 307 base64encodedvalue== 309 310 311 builtin-idevid-cert 312 base64encodedvalue== 313 314 315 my-ldevid-cert 316 base64encodedvalue== 317 318 319 321 322 tpm-protected-key2 323 324 325 builtin-idevid-cert2 326 327 328 my-ldevid-cert2 329 base64encodedvalue== 330 331 332 334 335 337 The following example module has been constructed to illustrate the 338 "local-or-keystore-asymmetric-key-grouping" grouping defined in the 339 "ietf-keystore" module. 341 module ex-keystore-usage { 342 yang-version 1.1; 344 namespace "http://example.com/ns/example-keystore-usage"; 345 prefix "eku"; 347 import ietf-keystore { 348 prefix ks; 349 reference 350 "RFC VVVV: YANG Data Model for a 'Keystore' Mechanism"; 351 } 353 organization 354 "Example Corporation"; 356 contact 357 "Author: YANG Designer "; 359 description 360 "This module illustrates the grouping in the keystore draft called 361 'local-or-keystore-asymmetric-key-with-certs-grouping'."; 363 revision "YYYY-MM-DD" { 364 description 365 "Initial version"; 366 reference 367 "RFC XXXX: YANG Data Model for a 'Keystore' Mechanism"; 368 } 370 container keystore-usage { 371 description 372 "An illustration of the various keystore groupings."; 374 list just-a-key { 375 key name; 376 leaf name { 377 type string; 378 description 379 "An arbitrary name for this key."; 380 } 381 uses ks:local-or-keystore-asymmetric-key-grouping; 382 description 383 "An asymmetric key, with no certs, that may be configured 384 locally or be a reference to an asymmetric key in the 385 keystore. The intent is to reference just the asymmetric 386 key, not any certificates that may also be associated 387 with the asymmetric key."; 388 } 390 list key-with-certs { 391 key name; 392 leaf name { 393 type string; 394 description 395 "An arbitrary name for this key."; 396 } 397 uses ks:local-or-keystore-asymmetric-key-with-certs-grouping; 398 description 399 "An asymmetric key and its associated certs, that may be 400 configured locally or be a reference to an asymmetric key 401 (and its associated certs) in the keystore."; 402 } 404 list end-entity-cert-with-key { 405 key name; 406 leaf name { 407 type string; 408 description 409 "An arbitrary name for this key."; 410 } 411 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 412 description 413 "An end-entity certificate, and its associated private key, 414 that may be configured locally or be a reference to a 415 specific certificate (and its associated private key) in 416 the keystore."; 417 } 418 } 420 } 422 The following example illustrates what two configured keys, one local 423 and the other remote, might look like. This example consistent with 424 other examples above (i.e., the referenced key is in an example 425 above). 427 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 428 430 432 433 a locally-defined key 434 435 437 ct:rsa2048 438 439 base64encodedvalue== 440 base64encodedvalue== 441 442 444 445 a keystore-defined key (and its associated certs) 446 ex-rsa-key 447 449 451 452 a locally-defined key with certs 453 454 456 ct:rsa2048 457 458 base64encodedvalue== 459 base64encodedvalue== 460 461 462 a locally-defined cert 463 base64encodedvalue== 464 465 466 467 469 470 a keystore-defined key (and its associated certs) 471 ex-rsa-key 472 474 475 476 a locally-defined end-entity cert with key 477 478 480 ct:rsa2048 481 482 base64encodedvalue== 483 base64encodedvalue== 484 base64encodedvalue== 485 486 488 489 a keystore-defined certificate (and its associated key) 491 ex-rsa-cert 492 494 496 3.3. YANG Module 498 This YANG module has normative references to [RFC8341] and 499 [I-D.ietf-netconf-crypto-types], and an informative reference to 500 [RFC8342]. 502 file "ietf-keystore@2019-04-29.yang" 503 module ietf-keystore { 504 yang-version 1.1; 505 namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; 506 prefix ks; 508 import ietf-crypto-types { 509 prefix ct; 510 reference 511 "RFC CCCC: Common YANG Data Types for Cryptography"; 512 } 514 import ietf-netconf-acm { 515 prefix nacm; 516 reference 517 "RFC 8341: Network Configuration Access Control Model"; 518 } 520 organization 521 "IETF NETCONF (Network Configuration) Working Group"; 523 contact 524 "WG Web: 525 WG List: 526 Author: Kent Watsen "; 528 description 529 "This module defines a keystore to centralize management 530 of security credentials. 532 Copyright (c) 2019 IETF Trust and the persons identified 533 as authors of the code. All rights reserved. 535 Redistribution and use in source and binary forms, with 536 or without modification, is permitted pursuant to, and 537 subject to the license terms contained in, the Simplified 538 BSD License set forth in Section 4.c of the IETF Trust's 539 Legal Provisions Relating to IETF Documents 540 (https://trustee.ietf.org/license-info). 542 This version of this YANG module is part of RFC XXXX 543 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 544 itself for full legal notices.; 546 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 547 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 548 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 549 are to be interpreted as described in BCP 14 (RFC 2119) 550 (RFC 8174) when, and only when, they appear in all 551 capitals, as shown here."; 553 revision 2019-04-29 { 554 description 555 "Initial version"; 556 reference 557 "RFC VVVV: 558 YANG Data Model for a Centralized Keystore Mechanism"; 559 } 561 /****************/ 562 /* Features */ 563 /****************/ 565 feature keystore-supported { 566 description 567 "The 'keystore-supported' feature indicates that the server 568 supports the keystore."; 569 } 570 feature local-keys-supported { 571 description 572 "The 'local-keys-supported' feature indicates that the 573 server supports locally-defined keys."; 574 } 576 /****************/ 577 /* Typedefs */ 578 /****************/ 580 typedef asymmetric-key-ref { 581 type leafref { 582 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 583 + "/ks:name"; 584 } 585 description 586 "This typedef enables modules to easily define a reference 587 to an asymmetric key stored in the keystore."; 588 reference 589 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 590 } 592 typedef asymmetric-key-certificate-ref { 593 type leafref { 594 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 595 + "/ks:certificates/ks:certificate/ks:name"; 596 } 597 description 598 "This typedef enables modules to easily define a reference 599 to a specific certificate associated with an asymmetric key 600 stored in the keystore."; 601 reference 602 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 603 } 605 /*****************/ 606 /* Groupings */ 607 /*****************/ 609 grouping local-or-keystore-asymmetric-key-grouping { 610 description 611 "A grouping that expands to allow the asymmetric key to be 612 either stored locally, within the using data model, or be 613 a reference to an asymmetric key stored in the keystore."; 614 choice local-or-keystore { 615 mandatory true; 616 case local { 617 if-feature "local-keys-supported"; 618 container local-definition { 619 must '(algorithm and public-key and private-key) 620 or not (algorithm or public-key or private-key)' { 621 description 622 "These descendent nodes are not mandatory because they 623 MAY be defined in . Implementations MUST 624 assert that these values are either configured or that 625 they exist in ."; 626 } 627 description 628 "Container to hold the local key definition."; 629 uses ct:asymmetric-key-pair-grouping; 630 } 631 } 632 case keystore { 633 if-feature "keystore-supported"; 634 leaf keystore-reference { 635 type ks:asymmetric-key-ref; 636 description 637 "A reference to an asymmetric key that exists in 638 the keystore. The intent is to reference just the 639 asymmetric key, not any certificates that may also 640 be associated with the asymmetric key."; 641 } 642 } 643 description 644 "A choice between an inlined definition and a definition 645 that exists in the keystore."; 646 } 647 } 649 grouping local-or-keystore-asymmetric-key-with-certs-grouping { 650 description 651 "A grouping that expands to allow an asymmetric key and its 652 associated certificates to be either stored locally, within 653 the using data model, or be a reference to an asymmetric key 654 (and its associated certificates) stored in the keystore."; 655 choice local-or-keystore { 656 mandatory true; 657 case local { 658 if-feature "local-keys-supported"; 659 container local-definition { 660 must '(algorithm and public-key and private-key) 661 or not (algorithm or public-key or private-key)' { 662 description 663 "These descendent nodes are not mandatory because they 664 MAY be defined in . Implementations MUST 665 assert that these values are either configured or that 666 they exist in ."; 667 } 668 description 669 "Container to hold the local key definition."; 670 uses ct:asymmetric-key-pair-with-certs-grouping; 671 } 672 } 673 case keystore { 674 if-feature "keystore-supported"; 675 leaf keystore-reference { 676 type ks:asymmetric-key-ref; 677 description 678 "A reference to a value that exists in the keystore."; 679 } 680 } 681 description 682 "A choice between an inlined definition and a definition 683 that exists in the keystore."; 684 } 685 } 687 grouping local-or-keystore-end-entity-cert-with-key-grouping { 688 description 689 "A grouping that expands to allow an end-entity certificate 690 (and its associated private key) to be either stored locally, 691 within the using data model, or be a reference to a specific 692 certificate in the keystore."; 693 choice local-or-keystore { 694 mandatory true; 695 case local { 696 if-feature "local-keys-supported"; 697 container local-definition { 698 must '(algorithm and public-key and private-key) 699 or not (algorithm or public-key or private-key)' { 700 description 701 "These descendent nodes are not mandatory because they 702 MAY be defined in . Implementations MUST 703 assert that these values are either configured or that 704 they exist in ."; 705 } 706 description 707 "Container to hold the local key definition."; 708 uses ct:asymmetric-key-pair-grouping; 709 uses ct:end-entity-cert-grouping; 710 } 711 } 712 case keystore { 713 if-feature "keystore-supported"; 714 leaf keystore-reference { 715 type ks:asymmetric-key-certificate-ref; 716 description 717 "A reference to a specific certificate, and its 718 associated private key, stored in the keystore."; 719 } 720 } 721 description 722 "A choice between an inlined definition and a definition 723 that exists in the keystore."; 724 } 725 } 727 /*********************************/ 728 /* Protocol accessible nodes */ 729 /*********************************/ 731 container keystore { 732 nacm:default-deny-write; 733 description 734 "The keystore contains a list of keys."; 735 container asymmetric-keys { 736 description 737 "A list of asymmetric keys."; 738 list asymmetric-key { 739 must '(algorithm and public-key and private-key) 740 or not (algorithm or public-key or private-key)' { 741 description 742 "These descendent nodes are not mandatory because they 743 MAY be defined in . Implementations MUST 744 assert that these values are either configured or that 745 they exist in ."; 746 } 747 key "name"; 748 description 749 "An asymmetric key."; 750 leaf name { 751 type string; 752 description 753 "An arbitrary name for the asymmetric key. If the name 754 matches the name of a key that exists independently in 755 (i.e., a 'permanently-hidden' key), then 756 the 'algorithm', 'public-key', and 'private-key' nodes 757 MUST NOT be configured."; 758 } 759 uses ct:asymmetric-key-pair-with-certs-grouping; 760 } 762 } 763 } 764 } 765 767 4. Security Considerations 769 The YANG module defined in this document is designed to be accessed 770 via YANG based management protocols, such as NETCONF [RFC6241] and 771 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 772 implement secure transport layers (e.g., SSH, TLS) with mutual 773 authentication. 775 The NETCONF access control model (NACM) [RFC8341] provides the means 776 to restrict access for particular users to a pre-configured subset of 777 all available protocol operations and content. 779 There are a number of data nodes defined in this YANG module that are 780 writable/creatable/deletable (i.e., config true, which is the 781 default). These data nodes may be considered sensitive or vulnerable 782 in some network environments. Write operations (e.g., edit-config) 783 to these data nodes without proper protection can have a negative 784 effect on network operations. These are the subtrees and data nodes 785 and their sensitivity/vulnerability: 787 /: The entire data tree defined by this module is sensitive to 788 write operations. For instance, the addition or removal of 789 keys, certificates, etc., can dramatically alter the 790 implemented security policy. For this reason, the NACM 791 extension "default-deny-write" has been set for the entire data 792 tree. 794 /keystore/asymmetric-keys/asymmetric-key/private-key: When 795 writing this node, implementations MUST ensure that the 796 strength of the key being configured is not greater than the 797 strength of the underlying secure transport connection over 798 which it is communicated. Implementations SHOULD fail the 799 write-request if ever the strength of the private key is 800 greater then the strength of the underlying transport, and 801 alert the client that the strength of the key may have been 802 compromised. Additionally, when deleting this node, 803 implementations SHOULD automatically (without explicit request) 804 zeroize these keys in the most secure manner available, so as 805 to prevent the remnants of their persisted storage locations 806 from being analyzed in any meaningful way. 808 Some of the readable data nodes in this YANG module may be considered 809 sensitive or vulnerable in some network environments. It is thus 810 important to control read access (e.g., via get, get-config, or 811 notification) to these data nodes. These are the subtrees and data 812 nodes and their sensitivity/vulnerability: 814 /keystore/asymmetric-keys/asymmetric-key/private-key: This node 815 is additionally sensitive to read operations such that, in 816 normal use cases, it should never be returned to a client. The 817 best reason for returning this node is to support backup/ 818 restore type workflows. For this reason, the NACM extension 819 "default-deny-all" has been set for this data node. 821 5. IANA Considerations 823 5.1. The IETF XML Registry 825 This document registers one URI in the "ns" subregistry of the IETF 826 XML Registry [RFC3688]. Following the format in [RFC3688], the 827 following registration is requested: 829 URI: urn:ietf:params:xml:ns:yang:ietf-keystore 830 Registrant Contact: The NETCONF WG of the IETF. 831 XML: N/A, the requested URI is an XML namespace. 833 5.2. The YANG Module Names Registry 835 This document registers one YANG module in the YANG Module Names 836 registry [RFC6020]. Following the format in [RFC6020], the the 837 following registration is requested: 839 name: ietf-keystore 840 namespace: urn:ietf:params:xml:ns:yang:ietf-keystore 841 prefix: ks 842 reference: RFC VVVV 844 6. References 846 6.1. Normative References 848 [I-D.ietf-netconf-crypto-types] 849 Watsen, K. and H. Wang, "Common YANG Data Types for 850 Cryptography", draft-ietf-netconf-crypto-types-05 (work in 851 progress), March 2019. 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, 855 DOI 10.17487/RFC2119, March 1997, 856 . 858 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 859 the Network Configuration Protocol (NETCONF)", RFC 6020, 860 DOI 10.17487/RFC6020, October 2010, 861 . 863 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 864 RFC 7950, DOI 10.17487/RFC7950, August 2016, 865 . 867 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 868 Access Control Model", STD 91, RFC 8341, 869 DOI 10.17487/RFC8341, March 2018, 870 . 872 6.2. Informative References 874 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 875 DOI 10.17487/RFC3688, January 2004, 876 . 878 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 879 and A. Bierman, Ed., "Network Configuration Protocol 880 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 881 . 883 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 884 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 885 . 887 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 888 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 889 May 2017, . 891 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 892 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 893 . 895 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 896 and R. Wilton, "Network Management Datastore Architecture 897 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 898 . 900 [Std-802.1AR-2009] 901 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 902 metropolitan area networks - Secure Device Identity", 903 December 2009, . 906 Appendix A. Change Log 908 A.1. 00 to 01 910 o Replaced the 'certificate-chain' structures with PKCS#7 911 structures. (Issue #1) 913 o Added 'private-key' as a configurable data node, and removed the 914 'generate-private-key' and 'load-private-key' actions. (Issue #2) 916 o Moved 'user-auth-credentials' to the ietf-ssh-client module. 917 (Issues #4 and #5) 919 A.2. 01 to 02 921 o Added back 'generate-private-key' action. 923 o Removed 'RESTRICTED' enum from the 'private-key' leaf type. 925 o Fixed up a few description statements. 927 A.3. 02 to 03 929 o Changed draft's title. 931 o Added missing references. 933 o Collapsed sections and levels. 935 o Added RFC 8174 to Requirements Language Section. 937 o Renamed 'trusted-certificates' to 'pinned-certificates'. 939 o Changed 'public-key' from config false to config true. 941 o Switched 'host-key' from OneAsymmetricKey to definition from RFC 942 4253. 944 A.4. 03 to 04 946 o Added typedefs around leafrefs to common keystore paths 948 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 950 o Removed Design Considerations section 952 o Moved key and certificate definitions from data tree to groupings 954 A.5. 04 to 05 956 o Removed trust anchors (now in their own draft) 958 o Added back global keystore structure 960 o Added groupings enabling keys to either be locally defined or a 961 reference to the keystore. 963 A.6. 05 to 06 965 o Added feature "local-keys-supported" 967 o Added nacm:default-deny-all and nacm:default-deny-write 969 o Renamed generate-asymmetric-key to generate-hidden-key 971 o Added an install-hidden-key action 973 o Moved actions inside fo the "asymmetric-key" container 975 o Moved some groupings to draft-ietf-netconf-crypto-types 977 A.7. 06 to 07 979 o Removed a "require-instance false" 981 o Clarified some description statements 983 o Improved the keystore-usage examples 985 A.8. 07 to 08 987 o Added "local-definition" containers to avoid posibility of the 988 action/notification statements being under a "case" statement. 990 o Updated copyright date, boilerplate template, affiliation, folding 991 algorithm, and reformatted the YANG module. 993 A.9. 08 to 09 995 o Added a 'description' statement to the 'must' in the /keystore/ 996 asymmetric-key node explaining that the descendent values may 997 exist in only, and that implementation MUST assert 998 that the values are either configured or that they exist in 999 . 1001 o Copied above 'must' statement (and description) into the local-or- 1002 keystore-asymmetric-key-grouping, local-or-keystore-asymmetric- 1003 key-with-certs-grouping, and local-or-keystore-end-entity-cert- 1004 with-key-grouping statements. 1006 Acknowledgements 1008 The authors would like to thank for following for lively discussions 1009 on list and in the halls (ordered by last name): Andy Bierman, Martin 1010 Bjorklund, Benoit Claise, Ramkumar Dhanapal, Mehmet Ersue, Balazs 1011 Kovacs, David Lamparter, Ladislav Lhotka, Alan Luchuk, Mahesh 1012 Jethanandani, Radek Krejci, Reshad Rahman, Tom Petch, Juergen 1013 Schoenwaelder, Phil Shafer, Sean Turner, Eric Voit, Bert Wijnen, and 1014 Liang Xia. 1016 Author's Address 1018 Kent Watsen 1019 Watsen Networks 1021 EMail: kent+ietf@watsen.net