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