idnits 2.17.1 draft-ietf-netconf-keystore-12.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 182 has weird spacing: '...on-date yan...' == Line 188 has weird spacing: '...request bin...' == Line 347 has weird spacing: '...on-date yan...' == Line 353 has weird spacing: '...request bin...' == Line 378 has weird spacing: '...on-date yan...' == (7 more instances...) -- The document date (July 2, 2019) is 1758 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-09 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 July 2, 2019 5 Expires: January 3, 2020 7 A YANG Data Model for a Keystore 8 draft-ietf-netconf-keystore-12 10 Abstract 12 This document defines a YANG 1.1 module called "ietf-keystore" that 13 enables centralized configuration of both symmetric and asymmetric 14 keys. The secret value for both key types may be encrypted. 15 Asymmetric keys may be associated with certificates. Notifications 16 are sent when certificates are about to expire. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 Artwork in this document contains shorthand references to drafts in 26 progress. Please apply the following replacements: 28 o "VVVV" --> the assigned RFC value for this draft 30 Artwork in this document contains placeholder values for the date of 31 publication of this draft. Please apply the following replacement: 33 o "2019-07-02" --> the publication date of this draft 35 The following Appendix section is to be removed prior to publication: 37 o Appendix A. Change Log 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 3, 2020. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 75 3. The Keystore Model . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 78 3.2.1. A Keystore Instance . . . . . . . . . . . . . . . . . 12 79 3.2.2. The "generate-symmetric-key" RPC . . . . . . . . . . 14 80 3.2.3. Notable Keystore Groupings . . . . . . . . . . . . . 14 81 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 29 85 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 29 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 6.1. Normative References . . . . . . . . . . . . . . . . . . 29 88 6.2. Informative References . . . . . . . . . . . . . . . . . 30 89 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 90 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 31 91 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 31 92 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 31 93 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 31 94 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 32 95 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 32 96 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 32 97 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 32 98 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 32 99 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 33 100 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 33 101 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 33 102 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 105 1. Introduction 107 This document defines a YANG 1.1 [RFC7950] module called "ietf- 108 keystore" that enables centralized configuration of both symmetric 109 and asymmetric keys. The secret value for both key types may be 110 encrypted. Asymmetric keys may be associated with certificates. 111 Notifications are sent when certificates are about to expire. 113 The "ietf-keystore" module defines many "grouping" statements 114 intended for use by other modules that may import it. For instance, 115 there are groupings that defined enabling a key to be either 116 configured locally (within the defining data model) or be a reference 117 to a key in the keystore. 119 Special consideration has been given for systems that have 120 cryptographic hardware, such as a Trusted Protection Module (TPM). 121 These systems are unique in that the cryptographic hardware hides the 122 secret key values. To support such hardware, symmetric keys may have 123 the value "hidden-key" and asymmetric keys may have the value 124 "hidden-private-key". While how such keys are created or destroyed 125 is outside the scope of this document, the keystore can contain 126 entries for such keys, enabling them to be reference by other 127 configuration elements. 129 This document in compliant with Network Management Datastore 130 Architecture (NMDA) [RFC8342]. For instance, keys and associated 131 certificates installed during manufacturing (e.g., for a IDevID 132 [Std-802.1AR-2009] certificate), it is expected that such data may 133 appear only in . 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-algorithm-t 161 | +--rw public-key binary 162 | +--rw (private-key-type) 163 | | +--:(private-key) 164 | | | +--rw private-key? binary 165 | | +--:(hidden-private-key) 166 | | | +--rw hidden-private-key? empty 167 | | +--:(encrypted-private-key) 168 | | +--rw encrypted-private-key 169 | | +--rw (key-type) 170 | | | +--:(symmetric-key-ref) 171 | | | | +--rw symmetric-key-ref? leafref 172 | | | | {keystore-supported}? 173 | | | +--:(asymmetric-key-ref) 174 | | | +--rw asymmetric-key-ref? leafref 175 | | | {keystore-supported}? 176 | | +--rw value? binary 177 | +--rw certificates 178 | | +--rw certificate* [name] 179 | | +--rw name string 180 | | +--rw cert? end-entity-cert-cms 181 | | +---n certificate-expiration 182 | | +-- expiration-date yang:date-and-time 183 | +---x generate-certificate-signing-request 184 | +---w input 185 | | +---w subject binary 186 | | +---w attributes? binary 187 | +--ro output 188 | +--ro certificate-signing-request binary 189 +--rw symmetric-keys 190 +--rw symmetric-key* [name] 191 +--rw name string 192 +--rw algorithm encryption-algorithm-t 193 +--rw (key-type) 194 +--:(key) 195 | +--rw key? binary 196 +--:(hidden-key) 197 | +--rw hidden-key? empty 198 +--:(encrypted-key) 199 +--rw encrypted-key 200 +--rw (key-type) 201 | +--:(symmetric-key-ref) 202 | | +--rw symmetric-key-ref? leafref 203 | | {keystore-supported}? 204 | +--:(asymmetric-key-ref) 205 | +--rw asymmetric-key-ref? leafref 206 | {keystore-supported}? 207 +--rw value? binary 209 rpcs: 210 +---x generate-symmetric-key 211 | +---w input 212 | | +---w algorithm ct:encryption-algorithm-t 213 | | +---w encrypt-with! 214 | | +---w (key-type) 215 | | +--:(symmetric-key-ref) 216 | | | +---w symmetric-key-ref? leafref 217 | | | {keystore-supported}? 218 | | +--:(asymmetric-key-ref) 219 | | +---w asymmetric-key-ref? leafref 220 | | {keystore-supported}? 221 | +--ro output 222 | +--ro algorithm encryption-algorithm-t 223 | +--ro (key-type) 224 | +--:(key) 225 | | +--ro key? binary 226 | +--:(hidden-key) 227 | | +--ro hidden-key? empty 228 | +--:(encrypted-key) 229 | +--ro encrypted-key 230 | +--ro (key-type) 231 | | +--:(symmetric-key-ref) 232 | | | +--ro symmetric-key-ref? leafref 233 | | | {keystore-supported}? 234 | | +--:(asymmetric-key-ref) 235 | | +--ro asymmetric-key-ref? leafref 236 | | {keystore-supported}? 237 | +--ro value? binary 238 +---x generate-asymmetric-key 239 +---w input 240 | +---w algorithm ct:asymmetric-key-algorithm-t 241 | +---w encrypt-with! 242 | +---w (key-type) 243 | +--:(symmetric-key-ref) 244 | | +---w symmetric-key-ref? leafref 245 | | {keystore-supported}? 246 | +--:(asymmetric-key-ref) 247 | +---w asymmetric-key-ref? leafref 248 | {keystore-supported}? 249 +--ro output 250 +--ro algorithm 251 | asymmetric-key-algorithm-t 252 +--ro public-key binary 253 +--ro (private-key-type) 254 +--:(private-key) 255 | +--ro private-key? binary 256 +--:(hidden-private-key) 257 | +--ro hidden-private-key? empty 258 +--:(encrypted-private-key) 259 +--ro encrypted-private-key 260 +--ro (key-type) 261 | +--:(symmetric-key-ref) 262 | | +--ro symmetric-key-ref? leafref 263 | | {keystore-supported}? 264 | +--:(asymmetric-key-ref) 265 | +--ro asymmetric-key-ref? leafref 266 | {keystore-supported}? 267 +--ro value? binary 269 grouping key-reference-type-grouping 270 +-- (key-type) 271 +--:(symmetric-key-ref) 272 | +-- symmetric-key-ref? 273 | -> /keystore/symmetric-keys/symmetric-key/name 274 | {keystore-supported}? 275 +--:(asymmetric-key-ref) 276 +-- asymmetric-key-ref? 277 -> /keystore/asymmetric-keys/asymmetric-key/name 278 {keystore-supported}? 279 grouping encrypted-value-grouping 280 +-- (key-type) 281 | +--:(symmetric-key-ref) 282 | | +-- symmetric-key-ref? 283 | | -> /keystore/symmetric-keys/symmetric-key/name 284 | | {keystore-supported}? 285 | +--:(asymmetric-key-ref) 286 | +-- asymmetric-key-ref? 287 | -> /keystore/asymmetric-keys/asymmetric-key/name 288 | {keystore-supported}? 289 +-- value? binary 291 grouping symmetric-key-grouping 292 +-- algorithm encryption-algorithm-t 293 +-- (key-type) 294 +--:(key) 295 | +-- key? binary 296 +--:(hidden-key) 297 | +-- hidden-key? empty 298 +--:(encrypted-key) 299 +-- encrypted-key 300 +-- (key-type) 301 | +--:(symmetric-key-ref) 302 | | +-- symmetric-key-ref? leafref 303 | | {keystore-supported}? 304 | +--:(asymmetric-key-ref) 305 | +-- asymmetric-key-ref? leafref 306 | {keystore-supported}? 307 +-- value? binary 308 grouping asymmetric-key-pair-grouping 309 +-- algorithm asymmetric-key-algorithm-t 310 +-- public-key binary 311 +-- (private-key-type) 312 +--:(private-key) 313 | +-- private-key? binary 314 +--:(hidden-private-key) 315 | +-- hidden-private-key? empty 316 +--:(encrypted-private-key) 317 +-- encrypted-private-key 318 +-- (key-type) 319 | +--:(symmetric-key-ref) 320 | | +-- symmetric-key-ref? leafref 321 | | {keystore-supported}? 322 | +--:(asymmetric-key-ref) 323 | +-- asymmetric-key-ref? leafref 324 | {keystore-supported}? 325 +-- value? binary 326 grouping asymmetric-key-pair-with-cert-grouping 327 +-- algorithm 328 | asymmetric-key-algorithm-t 329 +-- public-key binary 330 +-- (private-key-type) 331 | +--:(private-key) 332 | | +-- private-key? binary 333 | +--:(hidden-private-key) 334 | | +-- hidden-private-key? empty 335 | +--:(encrypted-private-key) 336 | +-- encrypted-private-key 337 | +-- (key-type) 338 | | +--:(symmetric-key-ref) 339 | | | +-- symmetric-key-ref? leafref 340 | | | {keystore-supported}? 341 | | +--:(asymmetric-key-ref) 342 | | +-- asymmetric-key-ref? leafref 343 | | {keystore-supported}? 344 | +-- value? binary 345 +-- cert? end-entity-cert-cms 346 +---n certificate-expiration 347 | +-- expiration-date yang:date-and-time 348 +---x generate-certificate-signing-request 349 +---w input 350 | +---w subject binary 351 | +---w attributes? binary 352 +--ro output 353 +--ro certificate-signing-request binary 354 grouping asymmetric-key-pair-with-certs-grouping 355 +-- algorithm 356 | asymmetric-key-algorithm-t 357 +-- public-key binary 358 +-- (private-key-type) 359 | +--:(private-key) 360 | | +-- private-key? binary 361 | +--:(hidden-private-key) 362 | | +-- hidden-private-key? empty 363 | +--:(encrypted-private-key) 364 | +-- encrypted-private-key 365 | +-- (key-type) 366 | | +--:(symmetric-key-ref) 367 | | | +-- symmetric-key-ref? leafref 368 | | | {keystore-supported}? 369 | | +--:(asymmetric-key-ref) 370 | | +-- asymmetric-key-ref? leafref 371 | | {keystore-supported}? 372 | +-- value? binary 373 +-- certificates 374 | +-- certificate* [name] 375 | +-- name? string 376 | +-- cert? end-entity-cert-cms 377 | +---n certificate-expiration 378 | +-- expiration-date yang:date-and-time 379 +---x generate-certificate-signing-request 380 +---w input 381 | +---w subject binary 382 | +---w attributes? binary 383 +--ro output 384 +--ro certificate-signing-request binary 385 grouping asymmetric-key-certificate-ref-grouping 386 +-- asymmetric-key? ks:asymmetric-key-ref 387 +-- certificate? leafref 388 grouping local-or-keystore-asymmetric-key-grouping 389 +-- (local-or-keystore) 390 +--:(local) {local-definitions-supported}? 391 | +-- local-definition 392 | +-- algorithm 393 | | asymmetric-key-algorithm-t 394 | +-- public-key binary 395 | +-- (private-key-type) 396 | +--:(private-key) 397 | | +-- private-key? binary 398 | +--:(hidden-private-key) 399 | | +-- hidden-private-key? empty 400 | +--:(encrypted-private-key) 401 | +-- encrypted-private-key 402 | +-- (key-type) 403 | | +--:(symmetric-key-ref) 404 | | | +-- symmetric-key-ref? leafref 405 | | | {keystore-supported}? 406 | | +--:(asymmetric-key-ref) 407 | | +-- asymmetric-key-ref? leafref 408 | | {keystore-supported}? 409 | +-- value? binary 410 +--:(keystore) {keystore-supported}? 411 +-- keystore-reference? ks:asymmetric-key-ref 412 grouping local-or-keystore-asymmetric-key-with-certs-grouping 413 +-- (local-or-keystore) 414 +--:(local) {local-definitions-supported}? 415 | +-- local-definition 416 | +-- algorithm 417 | | asymmetric-key-algorithm-t 418 | +-- public-key binary 419 | +-- (private-key-type) 420 | | +--:(private-key) 421 | | | +-- private-key? binary 422 | | +--:(hidden-private-key) 423 | | | +-- hidden-private-key? empty 424 | | +--:(encrypted-private-key) 425 | | +-- encrypted-private-key 426 | | +-- (key-type) 427 | | | +--:(symmetric-key-ref) 428 | | | | +-- symmetric-key-ref? leafref 429 | | | | {keystore-supported}? 430 | | | +--:(asymmetric-key-ref) 431 | | | +-- asymmetric-key-ref? leafref 432 | | | {keystore-supported}? 433 | | +-- value? binary 434 | +-- certificates 435 | | +-- certificate* [name] 436 | | +-- name? string 437 | | +-- cert? end-entity-cert-cms 438 | | +---n certificate-expiration 439 | | +-- expiration-date yang:date-and-time 440 | +---x generate-certificate-signing-request 441 | +---w input 442 | | +---w subject binary 443 | | +---w attributes? binary 444 | +--ro output 445 | +--ro certificate-signing-request binary 446 +--:(keystore) {keystore-supported}? 447 +-- keystore-reference? ks:asymmetric-key-ref 448 grouping local-or-keystore-end-entity-cert-with-key-grouping 449 +-- (local-or-keystore) 450 +--:(local) {local-definitions-supported}? 451 | +-- local-definition 452 | +-- algorithm 453 | | asymmetric-key-algorithm-t 454 | +-- public-key binary 455 | +-- (private-key-type) 456 | | +--:(private-key) 457 | | | +-- private-key? binary 458 | | +--:(hidden-private-key) 459 | | | +-- hidden-private-key? empty 460 | | +--:(encrypted-private-key) 461 | | +-- encrypted-private-key 462 | | +-- (key-type) 463 | | | +--:(symmetric-key-ref) 464 | | | | +-- symmetric-key-ref? leafref 465 | | | | {keystore-supported}? 466 | | | +--:(asymmetric-key-ref) 467 | | | +-- asymmetric-key-ref? leafref 468 | | | {keystore-supported}? 469 | | +-- value? binary 470 | +-- cert? 471 | | end-entity-cert-cms 472 | +---n certificate-expiration 473 | | +-- expiration-date yang:date-and-time 474 | +---x generate-certificate-signing-request 475 | +---w input 476 | | +---w subject binary 477 | | +---w attributes? binary 478 | +--ro output 479 | +--ro certificate-signing-request binary 480 +--:(keystore) {keystore-supported}? 481 +-- keystore-reference 482 +-- asymmetric-key? ks:asymmetric-key-ref 483 +-- certificate? leafref 484 grouping keystore-grouping 485 +-- asymmetric-keys 486 | +-- asymmetric-key* [name] 487 | +-- name? string 488 | +-- algorithm 489 | | asymmetric-key-algorithm-t 490 | +-- public-key binary 491 | +-- (private-key-type) 492 | | +--:(private-key) 493 | | | +-- private-key? binary 494 | | +--:(hidden-private-key) 495 | | | +-- hidden-private-key? empty 496 | | +--:(encrypted-private-key) 497 | | +-- encrypted-private-key 498 | | +-- (key-type) 499 | | | +--:(symmetric-key-ref) 500 | | | | +-- symmetric-key-ref? leafref 501 | | | | {keystore-supported}? 502 | | | +--:(asymmetric-key-ref) 503 | | | +-- asymmetric-key-ref? leafref 504 | | | {keystore-supported}? 505 | | +-- value? binary 506 | +-- certificates 507 | | +-- certificate* [name] 508 | | +-- name? string 509 | | +-- cert? end-entity-cert-cms 510 | | +---n certificate-expiration 511 | | +-- expiration-date yang:date-and-time 512 | +---x generate-certificate-signing-request 513 | +---w input 514 | | +---w subject binary 515 | | +---w attributes? binary 516 | +--ro output 517 | +--ro certificate-signing-request binary 518 +-- symmetric-keys 519 +-- symmetric-key* [name] 520 +-- name? string 521 +-- algorithm encryption-algorithm-t 522 +-- (key-type) 523 +--:(key) 524 | +-- key? binary 525 +--:(hidden-key) 526 | +-- hidden-key? empty 527 +--:(encrypted-key) 528 +-- encrypted-key 529 +-- (key-type) 530 | +--:(symmetric-key-ref) 531 | | +-- symmetric-key-ref? leafref 532 | | {keystore-supported}? 533 | +--:(asymmetric-key-ref) 534 | +-- asymmetric-key-ref? leafref 535 | {keystore-supported}? 536 +-- value? binary 538 3.2. Example Usage 540 3.2.1. A Keystore Instance 542 The following example illustrates what a fully configured keystore 543 might look like in , as described by Section 5.3 in 544 [RFC8342]. This datastore view illustrates data set by the 545 manufacturing process alongside conventional configuration. This 546 keystore instance has four keys, two having one associated 547 certificate, one having two associated certificates, and one empty 548 key. 550 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 552 556 557 559 560 ex-rsa-key 561 rsa2048 562 base64encodedvalue== 563 base64encodedvalue== 564 565 566 ex-rsa-cert 567 base64encodedvalue== 568 569 570 572 573 tls-ec-key 574 secp256r1 575 base64encodedvalue== 576 base64encodedvalue== 577 578 579 tls-ec-cert 580 base64encodedvalue== 581 582 583 585 586 tpm-protected-key 587 rsa2048 588 base64encodedvalue== 589 590 591 592 builtin-idevid-cert 593 594 595 my-ldevid-cert 596 base64encodedvalue== 597 598 599 601 602 encrypted-key 603 secp256r1 604 base64encodedvalue== 605 606 operators-encrypted-key 608 base64encodedvalue== 609 610 612 614 615 617 618 operators-encrypted-key 619 aes-256-cbc 620 621 tpm-protected-key 622 base64encodedvalue== 623 624 626 628 630 3.2.2. The "generate-symmetric-key" RPC 632 The following example illustrates the "generate-symmetric-key" RPC. 633 The key being referenced is defined in the keystore example above. 635 637 639 aes-256-cbc 640 641 tpm-protected-key 642 643 644 646 Following is the complimentary RPC-reply. 648 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 650 653 654 aes-256-cbc 655 656 tpm-protected-key 658 base64encodedvalue== 659 660 661 663 3.2.3. Notable Keystore Groupings 665 The following non-normative module is used by subsequent examples to 666 illustrate groupings defined in the ietf-crypto-types module. 668 module ex-keystore-usage { 669 yang-version 1.1; 671 namespace "http://example.com/ns/example-keystore-usage"; 672 prefix "eku"; 674 import ietf-keystore { 675 prefix ks; 676 reference 677 "RFC VVVV: YANG Data Model for a 'Keystore' Mechanism"; 678 } 680 organization 681 "Example Corporation"; 683 contact 684 "Author: YANG Designer "; 686 description 687 "This module illustrates the grouping in the keystore draft called 688 'local-or-keystore-asymmetric-key-with-certs-grouping'."; 690 revision "YYYY-MM-DD" { 691 description 692 "Initial version"; 693 reference 694 "RFC XXXX: YANG Data Model for a 'Keystore' Mechanism"; 695 } 697 container keystore-usage { 698 description 699 "An illustration of the various keystore groupings."; 701 list just-a-key { 702 key name; 703 leaf name { 704 type string; 705 description 706 "An arbitrary name for this key."; 707 } 708 uses ks:local-or-keystore-asymmetric-key-grouping; 709 description 710 "An asymmetric key, with no certs, that may be configured 711 locally or be a reference to an asymmetric key in the 712 keystore. The intent is to reference just the asymmetric 713 key, not any certificates that may also be associated 714 with the asymmetric key."; 715 } 717 list key-with-certs { 718 key name; 719 leaf name { 720 type string; 721 description 722 "An arbitrary name for this key."; 724 } 725 uses ks:local-or-keystore-asymmetric-key-with-certs-grouping; 726 description 727 "An asymmetric key and its associated certs, that may be 728 configured locally or be a reference to an asymmetric key 729 (and its associated certs) in the keystore."; 730 } 732 list end-entity-cert-with-key { 733 key name; 734 leaf name { 735 type string; 736 description 737 "An arbitrary name for this key."; 738 } 739 uses ks:local-or-keystore-end-entity-cert-with-key-grouping; 740 description 741 "An end-entity certificate, and its associated private key, 742 that may be configured locally or be a reference to a 743 specific certificate (and its associated private key) in 744 the keystore."; 745 } 746 } 748 } 750 The following example illustrates what two configured keys, one local 751 and the other remote, might look like. This example consistent with 752 other examples above (i.e., the referenced key is in an example 753 above). 755 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 757 759 761 762 a locally-defined key 763 764 rsa2048 765 base64encodedvalue== 766 base64encodedvalue== 767 768 770 771 a keystore-defined key (and its associated certs) 772 ex-rsa-key 773 775 777 778 a locally-defined key with certs 779 780 rsa2048 781 base64encodedvalue== 782 base64encodedvalue== 783 784 785 a locally-defined cert 786 base64encodedvalue== 787 788 789 790 792 793 a keystore-defined key (and its associated certs) 794 ex-rsa-key 795 797 799 800 a locally-defined end-entity cert with key 801 802 rsa2048 803 base64encodedvalue== 804 base64encodedvalue== 805 base64encodedvalue== 806 807 809 810 a keystore-defined certificate (and its associated key) 812 813 ex-rsa-key 814 ex-rsa-cert 815 816 818 820 3.3. YANG Module 822 This YANG module has normative references to [RFC8341] and 823 [I-D.ietf-netconf-crypto-types], and an informative reference to 824 [RFC8342]. 826 file "ietf-keystore@2019-07-02.yang" 828 module ietf-keystore { 829 yang-version 1.1; 830 namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; 831 prefix ks; 833 import ietf-crypto-types { 834 prefix ct; 835 reference 836 "RFC CCCC: Common YANG Data Types for Cryptography"; 837 } 839 import ietf-netconf-acm { 840 prefix nacm; 841 reference 842 "RFC 8341: Network Configuration Access Control Model"; 843 } 845 organization 846 "IETF NETCONF (Network Configuration) Working Group"; 848 contact 849 "WG Web: 850 WG List: 851 Author: Kent Watsen "; 853 description 854 "This module defines a keystore to centralize management 855 of security credentials. 857 Copyright (c) 2019 IETF Trust and the persons identified 858 as authors of the code. All rights reserved. 860 Redistribution and use in source and binary forms, with 861 or without modification, is permitted pursuant to, and 862 subject to the license terms contained in, the Simplified 863 BSD License set forth in Section 4.c of the IETF Trust's 864 Legal Provisions Relating to IETF Documents 865 (https://trustee.ietf.org/license-info). 867 This version of this YANG module is part of RFC XXXX 868 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 869 itself for full legal notices.; 871 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 872 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 873 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 874 are to be interpreted as described in BCP 14 (RFC 2119) 875 (RFC 8174) when, and only when, they appear in all 876 capitals, as shown here."; 878 revision 2019-07-02 { 879 description 880 "Initial version"; 881 reference 882 "RFC VVVV: A YANG Data Model for a Keystore"; 883 } 885 /****************/ 886 /* Features */ 887 /****************/ 889 feature keystore-supported { 890 description 891 "The 'keystore-supported' feature indicates that the server 892 supports the keystore."; 893 } 895 feature local-definitions-supported { 896 description 897 "The 'local-definitions-supported' feature indicates that the 898 server supports locally-defined keys."; 899 } 901 feature key-generation { 902 description 903 "Indicates that the server supports the actions related to 904 the life cycling keys in . To be used by 905 configuration, keys in must be copied to 906 ."; 907 } 909 /****************/ 910 /* Typedefs */ 911 /****************/ 913 typedef asymmetric-key-ref { 914 type leafref { 915 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" 916 + "/ks:name"; 917 } 918 description 919 "This typedef enables modules to easily define a reference 920 to an asymmetric key stored in the keystore."; 921 } 923 /*****************/ 924 /* Groupings */ 925 /*****************/ 927 grouping key-reference-type-grouping { 928 description 929 "A reusable grouping for a choice for the type of key 930 referenced in the keystore."; 931 choice key-type { 932 mandatory true; 933 description 934 "A choice between a reference to a symmetric or asymmetric 935 key in the keystore."; 936 leaf symmetric-key-ref { 937 if-feature "keystore-supported"; 938 type leafref { 939 path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key/" 940 + "ks:name"; 941 } 942 description 943 "Identifies a symmetric key used to encrypt this key."; 944 } 945 leaf asymmetric-key-ref { 946 if-feature "keystore-supported"; 947 type leafref { 948 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/" 949 + "ks:name"; 950 } 951 description 952 "Identifies an asymmetric key used to encrypt this key."; 953 } 954 } 955 } 957 grouping encrypted-value-grouping { 958 description 959 "A reusable grouping for a value that has been encrypted by 960 a symmetric or asymmetric key in the keystore."; 961 uses "key-reference-type-grouping"; 962 leaf value { 963 type binary; 964 description 965 "The private key, encrypted using the specified symmetric 966 or asymmetric key."; 967 } 968 } 970 grouping symmetric-key-grouping { 971 description 972 "This grouping is identical to the one in ietf-crypt-types 973 except that it adds a couple case statements enabling the 974 key value to be encrypted by a symmetric or an asymmetric 975 key known to the keystore."; 976 uses ct:symmetric-key-grouping { 977 augment "key-type" { 978 description 979 "Augments a new 'case' statement into the 'choice' 980 statement defined by the ietf-crypto-types module."; 981 container encrypted-key { 982 description 983 "A container for the encrypted symmetric key value."; 984 uses encrypted-value-grouping; 985 } 986 } 987 } 988 } 990 grouping asymmetric-key-pair-grouping { 991 description 992 "This grouping is identical to the one in ietf-crypt-types 993 except that it adds a couple case statements enabling the 994 key value to be encrypted by a symmetric or an asymmetric 995 key known to the keystore."; 996 uses ct:asymmetric-key-pair-grouping { 997 augment "private-key-type" { 998 description 999 "Augments a new 'case' statement into the 'choice' 1000 statement defined by the ietf-crypto-types module."; 1001 container encrypted-private-key { 1002 description 1003 "A container for the encrypted asymmetric private 1004 key value."; 1005 uses encrypted-value-grouping; 1006 } 1007 } 1008 } 1009 } 1010 grouping asymmetric-key-pair-with-cert-grouping { 1011 description 1012 "This grouping is identical to the one in ietf-crypt-types 1013 except that it adds a couple case statements enabling the 1014 key value to be encrypted by a symmetric or an asymmetric 1015 key known to the keystore."; 1016 uses ct:asymmetric-key-pair-with-cert-grouping { 1017 augment "private-key-type" { 1018 description 1019 "Augments a new 'case' statement into the 'choice' 1020 statement defined by the ietf-crypto-types module."; 1021 container encrypted-private-key { 1022 description 1023 "A container for the encrypted asymmetric private 1024 key value."; 1025 uses encrypted-value-grouping; 1026 } 1027 } 1028 } 1029 } 1031 grouping asymmetric-key-pair-with-certs-grouping { 1032 description 1033 "This grouping is identical to the one in ietf-crypt-types 1034 except that it adds a couple case statements enabling the 1035 key value to be encrypted by a symmetric or an asymmetric 1036 key known to the keystore."; 1037 uses ct:asymmetric-key-pair-with-certs-grouping { 1038 augment "private-key-type" { 1039 description 1040 "Augments a new 'case' statement into the 'choice' 1041 statement defined by the ietf-crypto-types module."; 1042 container encrypted-private-key { 1043 description 1044 "A container for the encrypted asymmetric private 1045 key value."; 1046 uses encrypted-value-grouping; 1047 } 1048 } 1049 } 1050 } 1052 grouping asymmetric-key-certificate-ref-grouping { 1053 leaf asymmetric-key { 1054 type ks:asymmetric-key-ref; 1055 must '../certificate'; 1056 description 1057 "A reference to an asymmetric key in the keystore."; 1059 } 1060 leaf certificate { 1061 type leafref { 1062 path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key[ks:" 1063 + "name = current()/../asymmetric-key]/ks:certificates" 1064 + "/ks:certificate/ks:name"; 1065 } 1066 must '../asymmetric-key'; 1067 description 1068 "A reference to a specific certificate of the 1069 asymmetric key in the keystore."; 1070 } 1071 description 1072 "This grouping defines a reference to a specific certificate 1073 associated with an asymmetric key stored in the keystore."; 1074 } 1076 grouping local-or-keystore-asymmetric-key-grouping { 1077 description 1078 "A grouping that expands to allow the asymmetric key to be 1079 either stored locally, within the using data model, or be 1080 a reference to an asymmetric key stored in the keystore."; 1081 choice local-or-keystore { 1082 mandatory true; 1083 case local { 1084 if-feature "local-definitions-supported"; 1085 container local-definition { 1086 description 1087 "Container to hold the local key definition."; 1088 uses asymmetric-key-pair-grouping; 1089 } 1090 } 1091 case keystore { 1092 if-feature "keystore-supported"; 1093 leaf keystore-reference { 1094 type ks:asymmetric-key-ref; 1095 description 1096 "A reference to an asymmetric key that exists in 1097 the keystore. The intent is to reference just the 1098 asymmetric key, not any certificates that may also 1099 be associated with the asymmetric key."; 1100 } 1101 } 1102 description 1103 "A choice between an inlined definition and a definition 1104 that exists in the keystore."; 1105 } 1106 } 1107 grouping local-or-keystore-asymmetric-key-with-certs-grouping { 1108 description 1109 "A grouping that expands to allow an asymmetric key and its 1110 associated certificates to be either stored locally, within 1111 the using data model, or be a reference to an asymmetric key 1112 (and its associated certificates) stored in the keystore."; 1113 choice local-or-keystore { 1114 mandatory true; 1115 case local { 1116 if-feature "local-definitions-supported"; 1117 container local-definition { 1118 description 1119 "Container to hold the local key definition."; 1120 uses asymmetric-key-pair-with-certs-grouping; 1121 } 1122 } 1123 case keystore { 1124 if-feature "keystore-supported"; 1125 leaf keystore-reference { 1126 type ks:asymmetric-key-ref; 1127 description 1128 "A reference to an asymmetric-key (and all of its 1129 associated certificates) in the keystore."; 1130 } 1131 } 1132 description 1133 "A choice between an inlined definition and a definition 1134 that exists in the keystore."; 1135 } 1136 } 1138 grouping local-or-keystore-end-entity-cert-with-key-grouping { 1139 description 1140 "A grouping that expands to allow an end-entity certificate 1141 (and its associated private key) to be either stored locally, 1142 within the using data model, or be a reference to a specific 1143 certificate in the keystore."; 1144 choice local-or-keystore { 1145 mandatory true; 1146 case local { 1147 if-feature "local-definitions-supported"; 1148 container local-definition { 1149 description 1150 "Container to hold the local key definition."; 1151 uses asymmetric-key-pair-with-cert-grouping; 1152 } 1153 } 1154 case keystore { 1155 if-feature "keystore-supported"; 1156 container keystore-reference { 1157 uses asymmetric-key-certificate-ref-grouping; 1158 description 1159 "A reference to a specific certificate (and its 1160 associated private key) in the keystore."; 1161 } 1162 } 1163 description 1164 "A choice between an inlined definition and a definition 1165 that exists in the keystore."; 1166 } 1167 } 1169 grouping keystore-grouping { 1170 description 1171 "Grouping definition enables use in other contexts. If ever 1172 done, implementations SHOULD augment new 'case' statements 1173 into local-or-keystore 'choice' statements to supply leafrefs 1174 to the new location."; 1175 container asymmetric-keys { 1176 description 1177 "A list of asymmetric keys."; 1178 list asymmetric-key { 1179 key "name"; 1180 description 1181 "An asymmetric key."; 1182 leaf name { 1183 type string; 1184 description 1185 "An arbitrary name for the asymmetric key."; 1186 } 1187 uses ks:asymmetric-key-pair-with-certs-grouping; 1188 } 1189 } 1190 container symmetric-keys { 1191 description 1192 "A list of symmetric keys."; 1193 list symmetric-key { 1194 key "name"; 1195 description 1196 "A symmetric key."; 1197 leaf name { 1198 type string; 1199 description 1200 "An arbitrary name for the symmetric key."; 1201 } 1202 uses ks:symmetric-key-grouping; 1204 } 1205 } 1206 } // grouping keystore-grouping 1208 /*********************************/ 1209 /* Protocol accessible nodes */ 1210 /*********************************/ 1212 container keystore { 1213 nacm:default-deny-write; 1214 description 1215 "The keystore contains a list of keys."; 1216 uses keystore-grouping; 1217 } 1219 rpc generate-symmetric-key { 1220 //nacm:default-deny-all; 1221 description 1222 "Requests the device to generate an symmetric key using 1223 the specified key algorithm, optionally encrypted using 1224 a key in the keystore. The output is this RPC can be 1225 used as input to a subsequent configuration request."; 1226 input { 1227 leaf algorithm { 1228 type ct:encryption-algorithm-t; 1229 mandatory true; 1230 description 1231 "The algorithm to be used when generating the key."; 1232 reference 1233 "RFC CCCC: Common YANG Data Types for Cryptography"; 1234 } 1235 container encrypt-with { 1236 presence 1237 "Indicates that the key should be encrypted using 1238 the specified symmetric or asymmetric key. If not 1239 specified, then the private key is not encrypted 1240 when returned."; 1241 description 1242 "A container for the 'key-type' choice."; 1243 uses key-reference-type-grouping; 1244 } 1245 } 1246 output { 1247 uses ks:symmetric-key-grouping; 1248 } 1249 } // end generate-symmetric-key 1250 rpc generate-asymmetric-key { 1251 //nacm:default-deny-all; 1252 description 1253 "Requests the device to generate an asymmetric key using 1254 the specified key algorithm, optionally encrypted using 1255 a key in the keystore. The output is this RPC can be 1256 used as input to a subsequent configuration request."; 1257 input { 1258 leaf algorithm { 1259 type ct:asymmetric-key-algorithm-t; 1260 mandatory true; 1261 description 1262 "The algorithm to be used when generating the key."; 1263 reference 1264 "RFC CCCC: Common YANG Data Types for Cryptography"; 1265 } 1266 container encrypt-with { 1267 presence 1268 "Indicates that the key should be encrypted using 1269 the specified symmetric or asymmetric key. If not 1270 specified, then the private key is not encrypted 1271 when returned."; 1272 description 1273 "A container for the 'key-type' choice."; 1274 uses key-reference-type-grouping; 1275 } 1276 } 1277 output { 1278 uses ks:asymmetric-key-pair-grouping; 1279 } 1280 } // end generate-asymmetric-key 1282 } 1284 1286 4. Security Considerations 1288 The YANG module defined in this document is designed to be accessed 1289 via YANG based management protocols, such as NETCONF [RFC6241] and 1290 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 1291 implement secure transport layers (e.g., SSH, TLS) with mutual 1292 authentication. 1294 The NETCONF access control model (NACM) [RFC8341] provides the means 1295 to restrict access for particular users to a pre-configured subset of 1296 all available protocol operations and content. 1298 There are a number of data nodes defined in this YANG module that are 1299 writable/creatable/deletable (i.e., config true, which is the 1300 default). These data nodes may be considered sensitive or vulnerable 1301 in some network environments. Write operations (e.g., edit-config) 1302 to these data nodes without proper protection can have a negative 1303 effect on network operations. These are the subtrees and data nodes 1304 and their sensitivity/vulnerability: 1306 /: The entire data tree defined by this module is sensitive to 1307 write operations. For instance, the addition or removal of 1308 keys, certificates, etc., can dramatically alter the 1309 implemented security policy. For this reason, the NACM 1310 extension "default-deny-write" has been set for the entire data 1311 tree. 1313 /keystore/asymmetric-keys/asymmetric-key/private-key: When 1314 writing this node, implementations MUST ensure that the 1315 strength of the key being configured is not greater than the 1316 strength of the underlying secure transport connection over 1317 which it is communicated. Implementations SHOULD fail the 1318 write-request if ever the strength of the private key is 1319 greater then the strength of the underlying transport, and 1320 alert the client that the strength of the key may have been 1321 compromised. Additionally, when deleting this node, 1322 implementations SHOULD automatically (without explicit request) 1323 zeroize these keys in the most secure manner available, so as 1324 to prevent the remnants of their persisted storage locations 1325 from being analyzed in any meaningful way. 1327 Some of the readable data nodes in this YANG module may be considered 1328 sensitive or vulnerable in some network environments. It is thus 1329 important to control read access (e.g., via get, get-config, or 1330 notification) to these data nodes. These are the subtrees and data 1331 nodes and their sensitivity/vulnerability: 1333 /keystore/asymmetric-keys/asymmetric-key/private-key: This node 1334 is additionally sensitive to read operations such that, in 1335 normal use cases, it should never be returned to a client. The 1336 best reason for returning this node is to support backup/ 1337 restore type workflows. For this reason, the NACM extension 1338 "default-deny-all" has been set for this data node. 1340 5. IANA Considerations 1341 5.1. The IETF XML Registry 1343 This document registers one URI in the "ns" subregistry of the IETF 1344 XML Registry [RFC3688]. Following the format in [RFC3688], the 1345 following registration is requested: 1347 URI: urn:ietf:params:xml:ns:yang:ietf-keystore 1348 Registrant Contact: The NETCONF WG of the IETF. 1349 XML: N/A, the requested URI is an XML namespace. 1351 5.2. The YANG Module Names Registry 1353 This document registers one YANG module in the YANG Module Names 1354 registry [RFC6020]. Following the format in [RFC6020], the the 1355 following registration is requested: 1357 name: ietf-keystore 1358 namespace: urn:ietf:params:xml:ns:yang:ietf-keystore 1359 prefix: ks 1360 reference: RFC VVVV 1362 6. References 1364 6.1. Normative References 1366 [I-D.ietf-netconf-crypto-types] 1367 Watsen, K. and H. Wang, "Common YANG Data Types for 1368 Cryptography", draft-ietf-netconf-crypto-types-09 (work in 1369 progress), June 2019. 1371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1372 Requirement Levels", BCP 14, RFC 2119, 1373 DOI 10.17487/RFC2119, March 1997, 1374 . 1376 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1377 the Network Configuration Protocol (NETCONF)", RFC 6020, 1378 DOI 10.17487/RFC6020, October 2010, 1379 . 1381 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1382 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1383 . 1385 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1386 Access Control Model", STD 91, RFC 8341, 1387 DOI 10.17487/RFC8341, March 2018, 1388 . 1390 6.2. Informative References 1392 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1393 DOI 10.17487/RFC3688, January 2004, 1394 . 1396 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1397 and A. Bierman, Ed., "Network Configuration Protocol 1398 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1399 . 1401 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1402 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1403 . 1405 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1406 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1407 May 2017, . 1409 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1410 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1411 . 1413 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1414 and R. Wilton, "Network Management Datastore Architecture 1415 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1416 . 1418 [Std-802.1AR-2009] 1419 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1420 metropolitan area networks - Secure Device Identity", 1421 December 2009, . 1424 Appendix A. Change Log 1426 A.1. 00 to 01 1428 o Replaced the 'certificate-chain' structures with PKCS#7 1429 structures. (Issue #1) 1431 o Added 'private-key' as a configurable data node, and removed the 1432 'generate-private-key' and 'load-private-key' actions. (Issue #2) 1434 o Moved 'user-auth-credentials' to the ietf-ssh-client module. 1435 (Issues #4 and #5) 1437 A.2. 01 to 02 1439 o Added back 'generate-private-key' action. 1441 o Removed 'RESTRICTED' enum from the 'private-key' leaf type. 1443 o Fixed up a few description statements. 1445 A.3. 02 to 03 1447 o Changed draft's title. 1449 o Added missing references. 1451 o Collapsed sections and levels. 1453 o Added RFC 8174 to Requirements Language Section. 1455 o Renamed 'trusted-certificates' to 'pinned-certificates'. 1457 o Changed 'public-key' from config false to config true. 1459 o Switched 'host-key' from OneAsymmetricKey to definition from RFC 1460 4253. 1462 A.4. 03 to 04 1464 o Added typedefs around leafrefs to common keystore paths 1466 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams 1468 o Removed Design Considerations section 1470 o Moved key and certificate definitions from data tree to groupings 1472 A.5. 04 to 05 1474 o Removed trust anchors (now in their own draft) 1476 o Added back global keystore structure 1478 o Added groupings enabling keys to either be locally defined or a 1479 reference to the keystore. 1481 A.6. 05 to 06 1483 o Added feature "local-keys-supported" 1485 o Added nacm:default-deny-all and nacm:default-deny-write 1487 o Renamed generate-asymmetric-key to generate-hidden-key 1489 o Added an install-hidden-key action 1491 o Moved actions inside fo the "asymmetric-key" container 1493 o Moved some groupings to draft-ietf-netconf-crypto-types 1495 A.7. 06 to 07 1497 o Removed a "require-instance false" 1499 o Clarified some description statements 1501 o Improved the keystore-usage examples 1503 A.8. 07 to 08 1505 o Added "local-definition" containers to avoid posibility of the 1506 action/notification statements being under a "case" statement. 1508 o Updated copyright date, boilerplate template, affiliation, folding 1509 algorithm, and reformatted the YANG module. 1511 A.9. 08 to 09 1513 o Added a 'description' statement to the 'must' in the /keystore/ 1514 asymmetric-key node explaining that the descendent values may 1515 exist in only, and that implementation MUST assert 1516 that the values are either configured or that they exist in 1517 . 1519 o Copied above 'must' statement (and description) into the local-or- 1520 keystore-asymmetric-key-grouping, local-or-keystore-asymmetric- 1521 key-with-certs-grouping, and local-or-keystore-end-entity-cert- 1522 with-key-grouping statements. 1524 A.10. 09 to 10 1526 o Updated draft title to match new truststore draft title 1528 o Moved everything under a top-level 'grouping' to enable use in 1529 other contexts. 1531 o Renamed feature from 'local-keys-supported' to 'local-definitions- 1532 supported' (same name used in truststore) 1534 o Removed the either-all-or-none 'must' expressions for the key's 1535 3-tuple values (since the values are now 'mandatory true' in 1536 crypto-types) 1538 o Example updated to reflect 'mandatory true' change in crypto-types 1539 draft 1541 A.11. 10 to 11 1543 o Replaced typedef asymmetric-key-certificate-ref with grouping 1544 asymmetric-key-certificate-ref-grouping. 1546 o Added feature feature 'key-generation'. 1548 o Cloned groupings symmetric-key-grouping, asymmetric-key-pair- 1549 grouping, asymmetric-key-pair-with-cert-grouping, and asymmetric- 1550 key-pair-with-certs-grouping from crypto-keys, augmenting into 1551 each new case statements for values that have been encrypted by 1552 other keys in the keystore. Refactored keystore model to use 1553 these groupings. 1555 o Added new 'symmetric-keys' lists, as a sibling to the existing 1556 'asymmetric-keys' list. 1558 o Added RPCs (not actions) 'generate-symmetric-key' and 'generate- 1559 asymmetric-key' to *return* a (potentially encrypted) key. 1561 A.12. 11 to 12 1563 o Updated to reflect crypto-type's draft using enumerations over 1564 identities. 1566 o Added examples for the 'generate-symmetric-key' and 'generate- 1567 asymmetric-key' RPCs. 1569 o Updated the Introduction section. 1571 Acknowledgements 1573 The authors would like to thank for following for lively discussions 1574 on list and in the halls (ordered by first name): Alan Luchuk, Andy 1575 Bierman, Benoit Claise, Bert Wijnen, Balazs Kovacs, David Lamparter, 1576 Eric Voit, Ladislav Lhotka, Liang Xia, Juergen Schoenwaelder, Mahesh 1577 Jethanandani, Martin Bjorklund, Mehmet Ersue, Phil Shafer, Radek 1578 Krejci, Ramkumar Dhanapal, Reshad Rahman, Sean Turner, and Tom Petch. 1580 Author's Address 1582 Kent Watsen 1583 Watsen Networks 1585 EMail: kent+ietf@watsen.net