idnits 2.17.1 draft-ietf-netconf-keystore-08.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 166 has weird spacing: '...gorithm asy...' == Line 177 has weird spacing: '...on-date yan...' == Line 183 has weird spacing: '...request bin...' == Line 194 has weird spacing: '...gorithm asy...' == Line 212 has weird spacing: '...gorithm asy...' == (4 more instances...) -- The document date (March 9, 2019) is 1847 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-02 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 March 9, 2019 5 Expires: September 10, 2019 7 YANG Data Model for a Centralized Keystore Mechanism 8 draft-ietf-netconf-keystore-08 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-03-09" --> 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 16 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 81 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 6.2. Informative References . . . . . . . . . . . . . . . . . 18 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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 This document defines a YANG 1.1 [RFC7950] module called "ietf- 100 keystore" that enables centralized configuration of asymmetric keys 101 and their associated certificates, and notification for when 102 configured certificates are about to expire. 104 This module also defines Six groupings designed for maximum reuse. 105 These groupings include one for the public half of an asymmetric key, 106 one for both the public and private halves of an asymmetric key, one 107 for both halves of an asymmetric key and a list of associated 108 certificates, one for an asymmetric key that may be configured 109 locally or via a reference to an asymmetric key in the keystore, one 110 for a trust anchor certificate and, lastly, one for an end entity 111 certificate. 113 Special consideration has been given for systems that have 114 cryptographic hardware, such as a Trusted Protection Module (TPM). 115 These systems are unique in that the cryptographic hardware 116 completely hides the private keys and must perform all private key 117 operations. To support such hardware, the "private-key" can be the 118 special value "permanently-hidden" and the actions "generate-hidden- 119 key" and "generate-certificate-signing-request" can be used to direct 120 these operations to the hardware . 122 This document in compliant with Network Management Datastore 123 Architecture (NMDA) [RFC8342]. For instance, to support keys and 124 associated certificates installed during manufacturing (e.g., for a 125 IDevID [Std-802.1AR-2009] certificate), it is expected that such data 126 may appear only in . 128 While only asymmetric keys are currently supported, the module has 129 been designed to enable other key types to be introduced in the 130 future. 132 The module does not support protecting the contents of the keystore 133 (e.g., via encryption), though it could be extended to do so in the 134 future. 136 It is not required that a system has an operating system level 137 keystore utility to implement this module. 139 2. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. The Keystore Model 149 3.1. Tree Diagram 151 This section provides a tree diagrams [RFC8340] for the "ietf- 152 keystore" module that presents both the protocol-accessible 153 "keystore" as well the all the groupings intended for external usage. 155 module: ietf-keystore 156 +--rw keystore 157 +--rw asymmetric-keys 158 +--rw asymmetric-key* [name] 159 +--rw name string 160 +--rw algorithm? 161 | asymmetric-key-algorithm-ref 162 +--rw public-key? binary 163 +--rw private-key? union 164 +---x generate-hidden-key 165 | +---w input 166 | +---w algorithm asymmetric-key-algorithm-ref 167 +---x install-hidden-key 168 | +---w input 169 | +---w algorithm asymmetric-key-algorithm-ref 170 | +---w public-key? binary 171 | +---w private-key? binary 172 +--rw certificates 173 | +--rw certificate* [name] 174 | +--rw name string 175 | +--rw cert? end-entity-cert-cms 176 | +---n certificate-expiration 177 | +-- expiration-date yang:date-and-time 178 +---x generate-certificate-signing-request 179 +---w input 180 | +---w subject binary 181 | +---w attributes? binary 182 +--ro output 183 +--ro certificate-signing-request binary 185 grouping local-or-keystore-asymmetric-key-grouping 186 +-- (local-or-keystore) 187 +--:(local) {local-keys-supported}? 188 | +-- local-definition 189 | +-- algorithm? asymmetric-key-algorithm-ref 190 | +-- public-key? binary 191 | +-- private-key? union 192 | +---x generate-hidden-key 193 | | +---w input 194 | | +---w algorithm asymmetric-key-algorithm-ref 195 | +---x install-hidden-key 196 | +---w input 197 | +---w algorithm asymmetric-key-algorithm-ref 198 | +---w public-key? binary 199 | +---w private-key? binary 200 +--:(keystore) {keystore-supported}? 201 +-- keystore-reference? ks:asymmetric-key-ref 202 grouping local-or-keystore-asymmetric-key-with-certs-grouping 203 +-- (local-or-keystore) 204 +--:(local) {local-keys-supported}? 205 | +-- local-definition 206 | +-- algorithm? 207 | | asymmetric-key-algorithm-ref 208 | +-- public-key? binary 209 | +-- private-key? union 210 | +---x generate-hidden-key 211 | | +---w input 212 | | +---w algorithm asymmetric-key-algorithm-ref 213 | +---x install-hidden-key 214 | | +---w input 215 | | +---w algorithm asymmetric-key-algorithm-ref 216 | | +---w public-key? binary 217 | | +---w private-key? binary 218 | +-- certificates 219 | | +-- certificate* [name] 220 | | +-- name? string 221 | | +-- cert? end-entity-cert-cms 222 | | +---n certificate-expiration 223 | | +-- expiration-date yang:date-and-time 224 | +---x generate-certificate-signing-request 225 | +---w input 226 | | +---w subject binary 227 | | +---w attributes? binary 228 | +--ro output 229 | +--ro certificate-signing-request binary 230 +--:(keystore) {keystore-supported}? 231 +-- keystore-reference? ks:asymmetric-key-ref 232 grouping local-or-keystore-end-entity-cert-with-key-grouping 233 +-- (local-or-keystore) 234 +--:(local) {local-keys-supported}? 235 | +-- local-definition 236 | +-- algorithm? 237 | | asymmetric-key-algorithm-ref 238 | +-- public-key? binary 239 | +-- private-key? union 240 | +---x generate-hidden-key 241 | | +---w input 242 | | +---w algorithm asymmetric-key-algorithm-ref 243 | +---x install-hidden-key 244 | | +---w input 245 | | +---w algorithm asymmetric-key-algorithm-ref 246 | | +---w public-key? binary 247 | | +---w private-key? binary 248 | +-- cert? end-entity-cert-cms 249 | +---n certificate-expiration 250 | +-- expiration-date yang:date-and-time 251 +--:(keystore) {keystore-supported}? 252 +-- keystore-reference? ks:asymmetric-key-certificate-ref 254 3.2. Example Usage 256 The following example illustrates what a fully configured keystore 257 might look like in , as described by Section 5.3 in 258 [RFC8342]. This datastore view illustrates data set by the 259 manufacturing process alongside conventional configuration. This 260 keystore instance has four keys, two having one associated 261 certificate, one having two associated certificates, and one empty 262 key. 264 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 266 270 272 273 ex-rsa-key 274 ct:rsa2048 275 base64encodedvalue== 276 base64encodedvalue== 277 278 279 ex-rsa-cert 280 base64encodedvalue== 281 282 283 285 300 301 tpm-protected-key 302 ct:rsa2048 303 permanently-hidden 305 base64encodedvalue== 307 308 309 builtin-idevid-cert 310 base64encodedvalue== 311 312 313 my-ldevid-cert 314 base64encodedvalue== 315 316 317 319 320 tpm-protected-key2 321 322 323 builtin-idevid-cert2 324 325 326 my-ldevid-cert2 327 base64encodedvalue== 328 329 330 332 333 334 The following example module has been constructed to illustrate the 335 "local-or-keystore-asymmetric-key-grouping" grouping defined in the 336 "ietf-keystore" module. 338 module ex-keystore-usage { 339 yang-version 1.1; 341 namespace "http://example.com/ns/example-keystore-usage"; 342 prefix "eku"; 344 import ietf-keystore { 345 prefix ks; 346 reference 347 "RFC VVVV: YANG Data Model for a 'Keystore' Mechanism"; 348 } 350 organization 351 "Example Corporation"; 353 contact 354 "Author: YANG Designer "; 356 description 357 "This module illustrates the grouping in the keystore draft called 358 'local-or-keystore-asymmetric-key-with-certs-grouping'."; 360 revision "YYYY-MM-DD" { 361 description 362 "Initial version"; 363 reference 364 "RFC XXXX: YANG Data Model for a 'Keystore' Mechanism"; 365 } 367 container keystore-usage { 368 description 369 "An illustration of the various keystore groupings."; 371 list just-a-key { 372 key name; 373 leaf name { 374 type string; 375 description 376 "An arbitrary name for this key."; 377 } 378 uses ks:local-or-keystore-asymmetric-key-grouping; 379 description 380 "An asymmetric key, with no certs, that may be configured 381 locally or be a reference to an asymmetric key in the 382 keystore. The intent is to reference just the asymmetric 383 key, not any certificates that may also be associated 384 with the asymmetric key."; 385 } 387 list key-with-certs { 388 key name; 389 leaf name { 390 type string; 391 description 392 "An arbitrary name for this key."; 393 } 394 uses ks:local-or-keystore-asymmetric-key-with-certs-grouping; 395 description 396 "An asymmetric key and its associated certs, that may be 397 configured locally or be a reference to an asymmetric key 398 (and its associated certs) in the keystore."; 399 } 401 list end-entity-cert-with-key { 402 key name; 403 leaf name { 404 type string; 405 description 406 "An arbitrary name for this key."; 407 } 408 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 409 description 410 "An end-entity certificate, and its associated private key, 411 that may be configured locally or be a reference to a 412 specific certificate (and its associated private key) in 413 the keystore."; 414 } 415 } 417 } 419 The following example illustrates what two configured keys, one local 420 and the other remote, might look like. This example consistent with 421 other examples above (i.e., the referenced key is in an example 422 above). 424 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 426 428 429 430 a locally-defined key 431 432 434 ct:rsa2048 435 436 base64encodedvalue== 437 base64encodedvalue== 438 439 441 442 a keystore-defined key (and its associated certs) 443 ex-rsa-key 444 446 448 449 a locally-defined key with certs 450 451 453 ct:rsa2048 454 455 base64encodedvalue== 456 base64encodedvalue== 457 458 459 a locally-defined cert 460 base64encodedvalue== 461 462 463 464 466 467 a keystore-defined key (and its associated certs) 468 ex-rsa-key 469 471 473 474 a locally-defined end-entity cert with key 475 476 478 ct:rsa2048 479 480 base64encodedvalue== 481 base64encodedvalue== 482 base64encodedvalue== 483 484 486 487 a keystore-defined certificate (and its associated key) 489 ex-rsa-cert 490 492 494 3.3. YANG Module 496 This YANG module has normative references to [RFC8341] and 497 [I-D.ietf-netconf-crypto-types], and an informative reference to 498 [RFC8342]. 500 file "ietf-keystore@2019-03-09.yang" 501 module ietf-keystore { 502 yang-version 1.1; 503 namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; 504 prefix ks; 506 import ietf-crypto-types { 507 prefix ct; 508 reference 509 "RFC CCCC: Common YANG Data Types for Cryptography"; 510 } 512 import ietf-netconf-acm { 513 prefix nacm; 514 reference 515 "RFC 8341: Network Configuration Access Control Model"; 516 } 518 organization 519 "IETF NETCONF (Network Configuration) Working Group"; 521 contact 522 "WG Web: 523 WG List: 524 Author: Kent Watsen "; 526 description 527 "This module defines a keystore to centralize management 528 of security credentials. 530 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 531 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 532 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 533 are to be interpreted as described in BCP 14 [RFC2119] 534 [RFC8174] when, and only when, they appear in all 535 capitals, as shown here. 537 Copyright (c) 2019 IETF Trust and the persons identified 538 as authors of the code. All rights reserved. 540 Redistribution and use in source and binary forms, with 541 or without modification, is permitted pursuant to, and 542 subject to the license terms contained in, the Simplified 543 BSD License set forth in Section 4.c of the IETF Trust's 544 Legal Provisions Relating to IETF Documents 545 (http://trustee.ietf.org/license-info). 547 This version of this YANG module is part of RFC VVVV; see 548 the RFC itself for full legal notices."; 550 revision 2019-03-09 { 551 description 552 "Initial version"; 553 reference 554 "RFC VVVV: 555 YANG Data Model for a Centralized Keystore Mechanism"; 556 } 558 // Features 560 feature keystore-supported { 561 description 562 "The 'keystore-supported' feature indicates that the server 563 supports the keystore."; 564 } 566 feature local-keys-supported { 567 description 568 "The 'local-keys-supported' feature indicates that the 569 server supports locally-defined keys."; 570 } 572 // Typedefs 573 typedef asymmetric-key-ref { 574 type leafref { 575 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 576 + "/ks:name"; 577 } 578 description 579 "This typedef enables modules to easily define a reference 580 to an asymmetric key stored in the keystore."; 581 reference 582 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 583 } 585 typedef asymmetric-key-certificate-ref { 586 type leafref { 587 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 588 + "/ks:certificates/ks:certificate/ks:name"; 589 } 590 description 591 "This typedef enables modules to easily define a reference 592 to a specific certificate associated with an asymmetric key 593 stored in the keystore."; 594 reference 595 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 596 } 598 // Groupings 600 grouping local-or-keystore-asymmetric-key-grouping { 601 description 602 "A grouping that expands to allow the asymmetric key to be 603 either stored locally, within the using data model, or be 604 a reference to an asymmetric key stored in the keystore."; 605 choice local-or-keystore { 606 mandatory true; 607 case local { 608 if-feature "local-keys-supported"; 609 container local-definition { 610 description 611 "Container to hold the local key definition."; 612 uses ct:asymmetric-key-pair-grouping; 613 } 614 } 615 case keystore { 616 if-feature "keystore-supported"; 617 leaf keystore-reference { 618 type ks:asymmetric-key-ref; 619 description 620 "A reference to an asymmetric key that exists in 621 the keystore. The intent is to reference just the 622 asymmetric key, not any certificates that may also 623 be associated with the asymmetric key."; 624 } 625 } 626 description 627 "A choice between an inlined definition and a definition 628 that exists in the keystore."; 629 } 630 } 632 grouping local-or-keystore-asymmetric-key-with-certs-grouping { 633 description 634 "A grouping that expands to allow an asymmetric key and its 635 associated certificates to be either stored locally, within 636 the using data model, or be a reference to an asymmetric key 637 (and its associated certificates) stored in the keystore."; 638 choice local-or-keystore { 639 mandatory true; 640 case local { 641 if-feature "local-keys-supported"; 642 container local-definition { 643 description 644 "Container to hold the local key definition."; 645 uses ct:asymmetric-key-pair-with-certs-grouping; 646 } 647 } 648 case keystore { 649 if-feature "keystore-supported"; 650 leaf keystore-reference { 651 type ks:asymmetric-key-ref; 652 description 653 "A reference to a value that exists in the keystore."; 654 } 655 } 656 description 657 "A choice between an inlined definition and a definition 658 that exists in the keystore."; 659 } 660 } 662 grouping local-or-keystore-end-entity-cert-with-key-grouping { 663 description 664 "A grouping that expands to allow an end-entity certificate 665 (and its associated private key) to be either stored locally, 666 within the using data model, or be a reference to a specific 667 certificate in the keystore."; 668 choice local-or-keystore { 669 mandatory true; 670 case local { 671 if-feature "local-keys-supported"; 672 container local-definition { 673 description 674 "Container to hold the local key definition."; 675 uses ct:asymmetric-key-pair-grouping; 676 uses ct:end-entity-cert-grouping; 677 } 678 } 679 case keystore { 680 if-feature "keystore-supported"; 681 leaf keystore-reference { 682 type ks:asymmetric-key-certificate-ref; 683 description 684 "A reference to a specific certificate, and its 685 associated private key, stored in the keystore."; 686 } 687 } 688 description 689 "A choice between an inlined definition and a definition 690 that exists in the keystore."; 691 } 692 } 694 // protocol accessible nodes 696 container keystore { 697 nacm:default-deny-write; 698 description 699 "The keystore contains a list of keys."; 700 container asymmetric-keys { 701 description 702 "A list of asymmetric keys."; 703 list asymmetric-key { 704 must '(algorithm and public-key and private-key) 705 or not (algorithm or public-key or private-key)'; 706 key "name"; 707 description 708 "An asymmetric key."; 709 leaf name { 710 type string; 711 description 712 "An arbitrary name for the asymmetric key. If the name 713 matches the name of a key that exists independently in 714 (i.e., a 'permanently-hidden' key), then 715 the 'algorithm', 'public-key', and 'private-key' nodes 716 MUST NOT be configured."; 718 } 719 uses ct:asymmetric-key-pair-with-certs-grouping; 720 } 721 } 722 } 723 } 724 726 4. Security Considerations 728 The YANG module defined in this document is designed to be accessed 729 via YANG based management protocols, such as NETCONF [RFC6241] and 730 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 731 implement secure transport layers (e.g., SSH, TLS) with mutual 732 authentication. 734 The NETCONF access control model (NACM) [RFC8341] provides the means 735 to restrict access for particular users to a pre-configured subset of 736 all available protocol operations and content. 738 There are a number of data nodes defined in this YANG module that are 739 writable/creatable/deletable (i.e., config true, which is the 740 default). These data nodes may be considered sensitive or vulnerable 741 in some network environments. Write operations (e.g., edit-config) 742 to these data nodes without proper protection can have a negative 743 effect on network operations. These are the subtrees and data nodes 744 and their sensitivity/vulnerability: 746 /: The entire data tree defined by this module is sensitive to 747 write operations. For instance, the addition or removal of 748 keys, certificates, etc., can dramatically alter the 749 implemented security policy. For this reason, the NACM 750 extension "default-deny-write" has been set for the entire data 751 tree. 753 /keystore/asymmetric-keys/asymmetric-key/private-key: When 754 writing this node, implementations MUST ensure that the 755 strength of the key being configured is not greater than the 756 strength of the underlying secure transport connection over 757 which it is communicated. Implementations SHOULD fail the 758 write-request if ever the strength of the private key is 759 greater then the strength of the underlying transport, and 760 alert the client that the strength of the key may have been 761 compromised. Additionally, when deleting this node, 762 implementations SHOULD automatically (without explicit request) 763 zeroize these keys in the most secure manner available, so as 764 to prevent the remnants of their persisted storage locations 765 from being analyzed in any meaningful way. 767 Some of the readable data nodes in this YANG module may be considered 768 sensitive or vulnerable in some network environments. It is thus 769 important to control read access (e.g., via get, get-config, or 770 notification) to these data nodes. These are the subtrees and data 771 nodes and their sensitivity/vulnerability: 773 /keystore/asymmetric-keys/asymmetric-key/private-key: This node 774 is additionally sensitive to read operations such that, in 775 normal use cases, it should never be returned to a client. The 776 best reason for returning this node is to support backup/ 777 restore type workflows. For this reason, the NACM extension 778 "default-deny-all" has been set for this data node. Note that 779 this extension is inherited from the grouping in the 780 [I-D.ietf-netconf-crypto-types] module. 782 5. IANA Considerations 784 5.1. The IETF XML Registry 786 This document registers one URI in the "ns" subregistry of the IETF 787 XML Registry [RFC3688]. Following the format in [RFC3688], the 788 following registration is requested: 790 URI: urn:ietf:params:xml:ns:yang:ietf-keystore 791 Registrant Contact: The NETCONF WG of the IETF. 792 XML: N/A, the requested URI is an XML namespace. 794 5.2. The YANG Module Names Registry 796 This document registers one YANG module in the YANG Module Names 797 registry [RFC6020]. Following the format in [RFC6020], the the 798 following registration is requested: 800 name: ietf-keystore 801 namespace: urn:ietf:params:xml:ns:yang:ietf-keystore 802 prefix: ks 803 reference: RFC VVVV 805 6. References 807 6.1. Normative References 809 [I-D.ietf-netconf-crypto-types] 810 Watsen, K. and H. Wang, "Common YANG Data Types for 811 Cryptography", draft-ietf-netconf-crypto-types-02 (work in 812 progress), October 2018. 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, 816 DOI 10.17487/RFC2119, March 1997, 817 . 819 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 820 the Network Configuration Protocol (NETCONF)", RFC 6020, 821 DOI 10.17487/RFC6020, October 2010, 822 . 824 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 825 RFC 7950, DOI 10.17487/RFC7950, August 2016, 826 . 828 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 829 Access Control Model", STD 91, RFC 8341, 830 DOI 10.17487/RFC8341, March 2018, 831 . 833 6.2. Informative References 835 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 836 DOI 10.17487/RFC3688, January 2004, 837 . 839 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 840 and A. Bierman, Ed., "Network Configuration Protocol 841 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 842 . 844 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 845 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 846 . 848 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 849 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 850 May 2017, . 852 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 853 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 854 . 856 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 857 and R. Wilton, "Network Management Datastore Architecture 858 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 859 . 861 [Std-802.1AR-2009] 862 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 863 metropolitan area networks - Secure Device Identity", 864 December 2009, . 867 Appendix A. Change Log 869 A.1. 00 to 01 871 o Replaced the 'certificate-chain' structures with PKCS#7 872 structures. (Issue #1) 874 o Added 'private-key' as a configurable data node, and removed the 875 'generate-private-key' and 'load-private-key' actions. (Issue #2) 877 o Moved 'user-auth-credentials' to the ietf-ssh-client module. 878 (Issues #4 and #5) 880 A.2. 01 to 02 882 o Added back 'generate-private-key' action. 884 o Removed 'RESTRICTED' enum from the 'private-key' leaf type. 886 o Fixed up a few description statements. 888 A.3. 02 to 03 890 o Changed draft's title. 892 o Added missing references. 894 o Collapsed sections and levels. 896 o Added RFC 8174 to Requirements Language Section. 898 o Renamed 'trusted-certificates' to 'pinned-certificates'. 900 o Changed 'public-key' from config false to config true. 902 o Switched 'host-key' from OneAsymmetricKey to definition from RFC 903 4253. 905 A.4. 03 to 04 907 o Added typedefs around leafrefs to common keystore paths 909 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 911 o Removed Design Considerations section 913 o Moved key and certificate definitions from data tree to groupings 915 A.5. 04 to 05 917 o Removed trust anchors (now in their own draft) 919 o Added back global keystore structure 921 o Added groupings enabling keys to either be locally defined or a 922 reference to the keystore. 924 A.6. 05 to 06 926 o Added feature "local-keys-supported" 928 o Added nacm:default-deny-all and nacm:default-deny-write 930 o Renamed generate-asymmetric-key to generate-hidden-key 932 o Added an install-hidden-key action 934 o Moved actions inside fo the "asymmetric-key" container 936 o Moved some groupings to draft-ietf-netconf-crypto-types 938 A.7. 06 to 07 940 o Removed a "require-instance false" 942 o Clarified some description statements 944 o Improved the keystore-usage examples 946 A.8. 07 to 08 948 o Added "local-definition" containers to avoid posibility of the 949 action/notification statements being under a "case" statement. 951 o Updated copyright date, boilerplate template, affiliation, folding 952 algorithm, and reformatted the YANG module. 954 Acknowledgements 956 The authors would like to thank for following for lively discussions 957 on list and in the halls (ordered by last name): Andy Bierman, Martin 958 Bjorklund, Benoit Claise, Ramkumar Dhanapal, Mehmet Ersue, Balazs 959 Kovacs, David Lamparter, Alan Luchuk, Ladislav Lhotka, Mahesh 960 Jethanandani, Radek Krejci, Reshad Rahman, Tom Petch, Juergen 961 Schoenwaelder, Phil Shafer, Sean Turner, Eric Voit, Bert Wijnen, and 962 Liang Xia. 964 Author's Address 966 Kent Watsen 967 Watsen Networks 969 EMail: kent+ietf@watsen.net