idnits 2.17.1 draft-ietf-netconf-keystore-07.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 178 has weird spacing: '...on-date yan...' == Line 184 has weird spacing: '...request bin...' == Line 205 has weird spacing: '...on-date yan...' == Line 250 has weird spacing: '...on-date yan...' == Line 256 has weird spacing: '...request bin...' -- The document date (October 22, 2018) is 2010 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-01 Summary: 0 errors (**), 0 flaws (~~), 7 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 Juniper Networks 4 Intended status: Standards Track October 22, 2018 5 Expires: April 25, 2019 7 YANG Data Model for a Centralized Keystore Mechanism 8 draft-ietf-netconf-keystore-07 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 "2018-10-22" --> 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 April 25, 2019. 55 Copyright Notice 57 Copyright (c) 2018 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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 This document defines a YANG 1.1 [RFC7950] module called "ietf- 99 keystore" that enables centralized configuration of asymmetric keys 100 and their associated certificates, and notification for when 101 configured certificates are about to expire. 103 This module also defines Six groupings designed for maximum reuse. 104 These groupings include one for the public half of an asymmetric key, 105 one for both the public and private halves of an asymmetric key, one 106 for both halves of an asymmetric key and a list of associated 107 certificates, one for an asymmetric key that may be configured 108 locally or via a reference to an asymmetric key in the keystore, one 109 for a trust anchor certificate and, lastly, one for an end entity 110 certificate. 112 Special consideration has been given for systems that have 113 cryptographic hardware, such as a Trusted Protection Module (TPM). 114 These systems are unique in that the cryptographic hardware 115 completely hides the private keys and must perform all private key 116 operations. To support such hardware, the "private-key" can be the 117 special value "permanently-hidden" and the actions "generate-hidden- 118 key" and "generate-certificate-signing-request" can be used to direct 119 these operations to the hardware . 121 This document in compliant with Network Management Datastore 122 Architecture (NMDA) [RFC8342]. For instance, to support keys and 123 associated certificates installed during manufacturing (e.g., for a 124 IDevID [Std-802.1AR-2009] certificate), it is expected that such data 125 may appear only in . 127 While only asymmetric keys are currently supported, the module has 128 been designed to enable other key types to be introduced in the 129 future. 131 The module does not support protecting the contents of the keystore 132 (e.g., via encryption), though it could be extended to do so in the 133 future. 135 It is not required that a system has an operating system level 136 keystore utility to implement this module. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. The Keystore Model 148 3.1. Tree Diagram 150 This section provides a tree diagrams [RFC8340] for the "ietf- 151 keystore" module that presents both the protocol-accessible 152 "keystore" as well the all the groupings intended for external usage. 154 module: ietf-keystore 155 +--rw keystore 156 +--rw asymmetric-keys 157 +--rw asymmetric-key* [name] 158 +--rw name string 159 +--rw algorithm? 160 | asymmetric-key-encryption-algorithm-ref 161 +--rw public-key? binary 162 +--rw private-key? union 163 +---x generate-hidden-key 164 | +---w input 165 | +---w algorithm 166 | asymmetric-key-encryption-algorithm-ref 167 +---x install-hidden-key 168 | +---w input 169 | +---w algorithm 170 | | asymmetric-key-encryption-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-end-entity-cert-with-key-grouping 187 +-- (local-or-keystore) 188 +--:(local) {local-keys-supported}? 189 | +-- algorithm? 190 | | asymmetric-key-encryption-algorithm-ref 191 | +-- public-key? binary 192 | +-- private-key? union 193 | +---x generate-hidden-key 194 | | +---w input 195 | | +---w algorithm 196 | | asymmetric-key-encryption-algorithm-ref 197 | +---x install-hidden-key 198 | | +---w input 199 | | +---w algorithm 200 | | | asymmetric-key-encryption-algorithm-ref 201 | | +---w public-key? binary 202 | | +---w private-key? binary 203 | +-- cert? end-entity-cert-cms 204 | +---n certificate-expiration 205 | +-- expiration-date yang:date-and-time 206 +--:(keystore) {keystore-supported}? 207 +-- reference? 208 ks:asymmetric-key-certificate-ref 209 grouping local-or-keystore-asymmetric-key-grouping 210 +-- (local-or-keystore) 211 +--:(local) {local-keys-supported}? 212 | +-- algorithm? 213 | | asymmetric-key-encryption-algorithm-ref 214 | +-- public-key? binary 215 | +-- private-key? union 216 | +---x generate-hidden-key 217 | | +---w input 218 | | +---w algorithm 219 | | asymmetric-key-encryption-algorithm-ref 220 | +---x install-hidden-key 221 | +---w input 222 | +---w algorithm 223 | | asymmetric-key-encryption-algorithm-ref 224 | +---w public-key? binary 225 | +---w private-key? binary 226 +--:(keystore) {keystore-supported}? 227 +-- reference? ks:asymmetric-key-ref 228 grouping local-or-keystore-asymmetric-key-with-certs-grouping 229 +-- (local-or-keystore) 230 +--:(local) {local-keys-supported}? 231 | +-- algorithm? 232 | | asymmetric-key-encryption-algorithm-ref 233 | +-- public-key? binary 234 | +-- private-key? union 235 | +---x generate-hidden-key 236 | | +---w input 237 | | +---w algorithm 238 | | asymmetric-key-encryption-algorithm-ref 239 | +---x install-hidden-key 240 | | +---w input 241 | | +---w algorithm 242 | | | asymmetric-key-encryption-algorithm-ref 243 | | +---w public-key? binary 244 | | +---w private-key? binary 245 | +-- certificates 246 | | +-- certificate* [name] 247 | | +-- name? string 248 | | +-- cert? end-entity-cert-cms 249 | | +---n certificate-expiration 250 | | +-- expiration-date yang:date-and-time 251 | +---x generate-certificate-signing-request 252 | +---w input 253 | | +---w subject binary 254 | | +---w attributes? binary 255 | +--ro output 256 | +--ro certificate-signing-request binary 257 +--:(keystore) {keystore-supported}? 258 +-- reference? 259 ks:asymmetric-key-ref 261 3.2. Example Usage 263 The following example illustrates what a fully configured keystore 264 might look like in , as described by Section 5.3 in 265 [RFC8342]. This datastore view illustrates data set by the 266 manufacturing process alongside conventional configuration. This 267 keystore instance has four keys, two having one associated 268 certificate, one having two associated certificates, and one empty 269 key. 271 [Note: '\' line wrapping for formatting only] 273 277 279 280 ex-rsa-key 281 ct:rsa2048 282 base64encodedvalue== 283 base64encodedvalue== 284 285 286 ex-rsa-cert 287 base64encodedvalue== 288 289 290 292 307 308 tpm-protected-key 309 ct:rsa2048 310 permanently-hidden 312 base64encodedvalue== 314 315 316 builtin-idevid-cert 317 base64encodedvalue== 318 319 320 my-ldevid-cert 321 base64encodedvalue== 322 323 324 326 327 tpm-protected-key2 328 329 330 builtin-idevid-cert2 331 332 333 my-ldevid-cert2 334 base64encodedvalue== 335 336 337 339 340 342 The following example module has been constructed to illustrate the 343 "local-or-keystore-asymmetric-key-grouping" grouping defined in the 344 "ietf-keystore" module. 346 module ex-keystore-usage { 347 yang-version 1.1; 349 namespace "http://example.com/ns/example-keystore-usage"; 350 prefix "eku"; 352 import ietf-keystore { 353 prefix ks; 354 reference 355 "RFC VVVV: YANG Data Model for a 'Keystore' Mechanism"; 356 } 358 organization 359 "Example Corporation"; 361 contact 362 "Author: YANG Designer "; 364 description 365 "This module illustrates the grouping in the keystore draft called 366 'local-or-keystore-asymmetric-key-with-certs-grouping'."; 368 revision "YYYY-MM-DD" { 369 description 370 "Initial version"; 371 reference 372 "RFC XXXX: YANG Data Model for a 'Keystore' Mechanism"; 373 } 375 container keystore-usage { 376 description 377 "An illustration of the various keystore groupings."; 379 list just-a-key { 380 key name; 381 leaf name { 382 type string; 383 description 384 "An arbitrary name for this key."; 385 } 386 uses ks:local-or-keystore-asymmetric-key-grouping; 387 description 388 "An asymmetric key, with no certs, that may be configured 389 locally or be a reference to an asymmetric key in the 390 keystore. The intent is to reference just the asymmetric 391 key, not any certificates that may also be associated 392 with the asymmetric key."; 393 } 395 list key-with-certs { 396 key name; 397 leaf name { 398 type string; 399 description 400 "An arbitrary name for this key."; 401 } 402 uses ks:local-or-keystore-asymmetric-key-with-certs-grouping; 403 description 404 "An asymmetric key and its associated certs, that may be 405 configured locally or be a reference to an asymmetric key 406 (and its associated certs) in the keystore."; 407 } 409 list end-entity-cert-with-key { 410 key name; 411 leaf name { 412 type string; 413 description 414 "An arbitrary name for this key."; 415 } 416 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 417 description 418 "An end-entity certificate, and its associated private key, 419 that may be configured locally or be a reference to a 420 specific certificate (and its associated private key) in 421 the keystore."; 422 } 423 } 425 } 427 The following example illustrates what two configured keys, one local 428 and the other remote, might look like. This example consistent with 429 other examples above (i.e., the referenced key is in an example 430 above). 432 [Note: '\' line wrapping for formatting only] 434 436 438 439 a locally-defined key 440 442 ct:rsa2048 443 444 base64encodedvalue== 445 base64encodedvalue== 446 448 449 a keystore-defined key (and its associated certs) 450 ex-rsa-key 451 453 455 456 a locally-defined key with certs 457 459 ct:rsa2048 460 461 base64encodedvalue== 462 base64encodedvalue== 463 464 465 a locally-defined cert 466 base64encodedvalue== 467 468 469 471 472 a keystore-defined key (and its associated certs) 473 ex-rsa-key 474 475 477 478 a locally-defined end-entity cert with key 479 481 ct:rsa2048 482 483 base64encodedvalue== 484 base64encodedvalue== 485 base64encodedvalue== 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@2018-10-22.yang" 503 module ietf-keystore { 504 yang-version 1.1; 506 namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; 507 prefix "ks"; 509 import ietf-crypto-types { 510 prefix ct; 511 reference 512 "RFC CCCC: Common YANG Data Types for Cryptography"; 513 } 515 import ietf-netconf-acm { 516 prefix nacm; 517 reference 518 "RFC 8341: Network Configuration Access Control Model"; 519 } 521 organization 522 "IETF NETCONF (Network Configuration) Working Group"; 524 contact 525 "WG Web: 526 WG List: 528 Author: Kent Watsen 529 "; 531 description 532 "This module defines a keystore to centralize management 533 of security credentials. 535 Copyright (c) 2018 IETF Trust and the persons identified 536 as authors of the code. All rights reserved. 538 Redistribution and use in source and binary forms, with 539 or without modification, is permitted pursuant to, and 540 subject to the license terms contained in, the Simplified 541 BSD License set forth in Section 4.c of the IETF Trust's 542 Legal Provisions Relating to IETF Documents 543 (http://trustee.ietf.org/license-info). 545 This version of this YANG module is part of RFC VVVV; see 546 the RFC itself for full legal notices."; 548 revision "2018-10-22" { 549 description 550 "Initial version"; 551 reference 552 "RFC VVVV: 553 YANG Data Model for a Centralized Keystore Mechanism"; 554 } 556 // Features 558 feature keystore-supported { 559 description 560 "The 'keystore-supported' feature indicates that the server 561 supports the keystore."; 562 } 564 feature local-keys-supported { 565 description 566 "The 'local-keys-supported' feature indocates that the 567 server supports locally-defined keys."; 568 } 570 // Typedefs 571 typedef asymmetric-key-ref { 572 type leafref { 573 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 574 + "/ks:name"; 575 } 576 description 577 "This typedef enables modules to easily define a reference 578 to an asymmetric key stored in the keystore."; 579 reference 580 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 581 } 583 typedef asymmetric-key-certificate-ref { 584 type leafref { 585 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 586 + "/ks:certificates/ks:certificate/ks:name"; 587 } 588 description 589 "This typedef enables modules to easily define a reference 590 to a specific certificate associated with an asymmetric key 591 stored in the keystore."; 592 reference 593 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 594 } 596 // Groupings 598 grouping local-or-keystore-asymmetric-key-grouping { 599 description 600 "A grouping that expands to allow the asymmetric key to be 601 either stored locally, within the using data model, or be 602 a reference to an asymmetric key stored in the keystore."; 603 choice local-or-keystore { 604 mandatory true; 605 case local { 606 if-feature "local-keys-supported"; 607 uses ct:asymmetric-key-pair-grouping; 608 } 609 case keystore { 610 if-feature "keystore-supported"; 611 leaf reference { 612 type ks:asymmetric-key-ref; 613 description 614 "A reference to an asymmetric key that exists in 615 the keystore. The intent is to reference just the 616 asymmetric key, not any certificates that may also 617 be associated with the asymmetric key."; 619 } 620 } 621 description 622 "A choice between an inlined definition and a definition 623 that exists in the keystore."; 624 } 625 } 627 grouping local-or-keystore-asymmetric-key-with-certs-grouping { 628 description 629 "A grouping that expands to allow an asymmetric key and its 630 associated certificates to be either stored locally, within 631 the using data model, or be a reference to an asymmetric key 632 (and its associated certificates) stored in the keystore."; 633 choice local-or-keystore { 634 mandatory true; 635 case local { 636 if-feature "local-keys-supported"; 637 uses ct:asymmetric-key-pair-with-certs-grouping; 638 } 639 case keystore { 640 if-feature "keystore-supported"; 641 leaf reference { 642 type ks:asymmetric-key-ref; 643 description 644 "A reference to a value that exists in the keystore."; 645 } 646 } 647 description 648 "A choice between an inlined definition and a definition 649 that exists in the keystore."; 650 } 651 } 653 grouping local-or-keystore-end-entity-cert-with-key-grouping { 654 description 655 "A grouping that expands to allow an end-entity certificate 656 (and its associated private key) to be either stored locally, 657 within the using data model, or be a reference to a specific 658 certificate in the keystore."; 659 choice local-or-keystore { 660 mandatory true; 661 case local { 662 if-feature "local-keys-supported"; 663 uses ct:asymmetric-key-pair-grouping; 664 uses ct:end-entity-cert-grouping; 665 } 666 case keystore { 667 if-feature "keystore-supported"; 668 leaf reference { 669 type ks:asymmetric-key-certificate-ref; 670 description 671 "A reference to a specific certificate, and its 672 associated private key, stored in the keystore."; 673 } 674 } 675 description 676 "A choice between an inlined definition and a definition 677 that exists in the keystore."; 678 } 679 } 681 // protocol accessible nodes 683 container keystore { 684 nacm:default-deny-write; 686 description 687 "The keystore contains a list of keys."; 689 container asymmetric-keys { 690 description 691 "A list of asymmetric keys."; 692 list asymmetric-key { 693 must "(algorithm and public-key and private-key) 694 or not (algorithm or public-key or private-key)"; 695 key name; 696 description 697 "An asymmetric key."; 698 leaf name { 699 type string; 700 description 701 "An arbitrary name for the asymmetric key. If the name 702 matches the name of a key that exists independently in 703 (i.e., a 'permanently-hidden' key), then 704 the 'algorithm', 'public-key', and 'private-key' nodes 705 MUST NOT be configured."; 706 } 707 uses ct:asymmetric-key-pair-with-certs-grouping; 708 } // end asymmetric-key 710 } // end asymmetric-keys 711 } // end keystore 713 } 714 716 4. Security Considerations 718 The YANG module defined in this document is designed to be accessed 719 via YANG based management protocols, such as NETCONF [RFC6241] and 720 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 721 implement secure transport layers (e.g., SSH, TLS) with mutual 722 authentication. 724 The NETCONF access control model (NACM) [RFC8341] provides the means 725 to restrict access for particular users to a pre-configured subset of 726 all available protocol operations and content. 728 There are a number of data nodes defined in this YANG module that are 729 writable/creatable/deletable (i.e., config true, which is the 730 default). These data nodes may be considered sensitive or vulnerable 731 in some network environments. Write operations (e.g., edit-config) 732 to these data nodes without proper protection can have a negative 733 effect on network operations. These are the subtrees and data nodes 734 and their sensitivity/vulnerability: 736 /: The entire data tree defined by this module is sensitive to 737 write operations. For instance, the addition or removal of 738 keys, certificates, etc., can dramatically alter the 739 implemented security policy. For this reason, the NACM 740 extension "default-deny-write" has been set for the entire data 741 tree. 743 /keystore/asymmetric-keys/asymmetric-key/private-key: When 744 writing this node, implementations MUST ensure that the 745 strength of the key being configured is not greater than the 746 strength of the underlying secure transport connection over 747 which it is communicated. Implementations SHOULD fail the 748 write-request if ever the strength of the private key is 749 greater then the strength of the underlying transport, and 750 alert the client that the strength of the key may have been 751 compromised. Additionally, when deleting this node, 752 implementations SHOULD automatically (without explicit request) 753 zeroize these keys in the most secure manner available, so as 754 to prevent the remnants of their persisted storage locations 755 from being analyzed in any meaningful way. 757 Some of the readable data nodes in this YANG module may be considered 758 sensitive or vulnerable in some network environments. It is thus 759 important to control read access (e.g., via get, get-config, or 760 notification) to these data nodes. These are the subtrees and data 761 nodes and their sensitivity/vulnerability: 763 /keystore/asymmetric-keys/asymmetric-key/private-key: This node 764 is additionally sensitive to read operations such that, in 765 normal use cases, it should never be returned to a client. The 766 best reason for returning this node is to support backup/ 767 restore type workflows. For this reason, the NACM extension 768 "default-deny-all" has been set for this data node. Note that 769 this extension is inherited from the grouping in the 770 [I-D.ietf-netconf-crypto-types] module. 772 5. IANA Considerations 774 5.1. The IETF XML Registry 776 This document registers one URI in the "ns" subregistry of the IETF 777 XML Registry [RFC3688]. Following the format in [RFC3688], the 778 following registration is requested: 780 URI: urn:ietf:params:xml:ns:yang:ietf-keystore 781 Registrant Contact: The NETCONF WG of the IETF. 782 XML: N/A, the requested URI is an XML namespace. 784 5.2. The YANG Module Names Registry 786 This document registers one YANG module in the YANG Module Names 787 registry [RFC6020]. Following the format in [RFC6020], the the 788 following registration is requested: 790 name: ietf-keystore 791 namespace: urn:ietf:params:xml:ns:yang:ietf-keystore 792 prefix: ks 793 reference: RFC VVVV 795 6. References 797 6.1. Normative References 799 [I-D.ietf-netconf-crypto-types] 800 Watsen, K., "Common YANG Data Types for Cryptography", 801 draft-ietf-netconf-crypto-types-01 (work in progress), 802 September 2018. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, 806 DOI 10.17487/RFC2119, March 1997, 807 . 809 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 810 the Network Configuration Protocol (NETCONF)", RFC 6020, 811 DOI 10.17487/RFC6020, October 2010, 812 . 814 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 815 RFC 7950, DOI 10.17487/RFC7950, August 2016, 816 . 818 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 819 Access Control Model", STD 91, RFC 8341, 820 DOI 10.17487/RFC8341, March 2018, 821 . 823 6.2. Informative References 825 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 826 DOI 10.17487/RFC3688, January 2004, 827 . 829 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 830 and A. Bierman, Ed., "Network Configuration Protocol 831 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 832 . 834 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 835 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 836 . 838 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 839 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 840 May 2017, . 842 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 843 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 844 . 846 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 847 and R. Wilton, "Network Management Datastore Architecture 848 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 849 . 851 [Std-802.1AR-2009] 852 IEEE SA-Standards Board, "IEEE Standard for Local and 853 metropolitan area networks - Secure Device Identity", 854 December 2009, . 857 Appendix A. Change Log 859 A.1. 00 to 01 861 o Replaced the 'certificate-chain' structures with PKCS#7 862 structures. (Issue #1) 864 o Added 'private-key' as a configurable data node, and removed the 865 'generate-private-key' and 'load-private-key' actions. (Issue #2) 867 o Moved 'user-auth-credentials' to the ietf-ssh-client module. 868 (Issues #4 and #5) 870 A.2. 01 to 02 872 o Added back 'generate-private-key' action. 874 o Removed 'RESTRICTED' enum from the 'private-key' leaf type. 876 o Fixed up a few description statements. 878 A.3. 02 to 03 880 o Changed draft's title. 882 o Added missing references. 884 o Collapsed sections and levels. 886 o Added RFC 8174 to Requirements Language Section. 888 o Renamed 'trusted-certificates' to 'pinned-certificates'. 890 o Changed 'public-key' from config false to config true. 892 o Switched 'host-key' from OneAsymmetricKey to definition from RFC 893 4253. 895 A.4. 03 to 04 897 o Added typedefs around leafrefs to common keystore paths 899 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 901 o Removed Design Considerations section 903 o Moved key and certificate definitions from data tree to groupings 905 A.5. 04 to 05 907 o Removed trust anchors (now in their own draft) 909 o Added back global keystore structure 911 o Added groupings enabling keys to either be locally defined or a 912 reference to the keystore. 914 A.6. 05 to 06 916 o Added feature "local-keys-supported" 918 o Added nacm:default-deny-all and nacm:default-deny-write 920 o Renamed generate-asymmetric-key to generate-hidden-key 922 o Added an install-hidden-key action 924 o Moved actions inside fo the "asymmetric-key" container 926 o Moved some groupings to draft-ietf-netconf-crypto-types 928 A.7. 06 to 07 930 o Removed a "require-instance false" 932 o Clarified some description statements 934 o Improved the keystore-usage examples 936 Acknowledgements 938 The authors would like to thank for following for lively discussions 939 on list and in the halls (ordered by last name): Andy Bierman, Martin 940 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David 941 Lamparter, Alan Luchuk, Ladislav Lhotka, Mahesh Jethanandani, Radek 942 Krejci, Reshad Rahman, Tom Petch, Juergen Schoenwaelder, Phil Shafer, 943 Sean Turner, Eric Voit, Bert Wijnen, and Liang Xia. 945 Author's Address 947 Kent Watsen 948 Juniper Networks 950 EMail: kwatsen@juniper.net