idnits 2.17.1 draft-ietf-netconf-crypto-types-22.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 364 has weird spacing: '...-format ide...' == Line 414 has weird spacing: '...-format ide...' == Line 461 has weird spacing: '...-format ide...' == Line 491 has weird spacing: '...-format ide...' == Line 539 has weird spacing: '...-format ide...' == (20 more instances...) -- The document date (7 March 2022) is 771 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X680.2015' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 7093 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-21 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-08 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-23 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-24 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-24 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-26 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-11 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-26 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-16 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). 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 7 March 2022 5 Expires: 8 September 2022 7 YANG Data Types and Groupings for Cryptography 8 draft-ietf-netconf-crypto-types-22 10 Abstract 12 This document presents a YANG 1.1 (RFC 7950) module defining 13 identities, typedefs, and groupings useful to cryptographic 14 applications. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains placeholder values that need to be replaced with 19 finalized values at the time of publication. This note summarizes 20 all of the substitutions that are needed. No other RFC Editor 21 instructions are specified elsewhere in this document. 23 Artwork in this document contains shorthand references to drafts in 24 progress. Please apply the following replacements: 26 * AAAA --> the assigned RFC value for this draft 28 Artwork in this document contains placeholder values for the date of 29 publication of this draft. Please apply the following replacement: 31 * 2022-03-07 --> the publication date of this draft 33 The following Appendix section is to be removed prior to publication: 35 * Appendix A. Change Log 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 8 September 2022. 54 Copyright Notice 56 Copyright (c) 2022 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 72 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 73 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 74 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. The "ietf-crypto-types" Module . . . . . . . . . . . . . . . 5 76 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 77 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18 78 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 79 3. Security Considerations . . . . . . . . . . . . . . . . . . . 47 80 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 48 81 3.2. No Support for Key Generation . . . . . . . . . . . . . . 48 82 3.3. Unconstrained Public Key Usage . . . . . . . . . . . . . 48 83 3.4. Unconstrained Private Key Usage . . . . . . . . . . . . . 48 84 3.5. Strength of Keys Conveyed . . . . . . . . . . . . . . . . 49 85 3.6. Encrypting Passwords . . . . . . . . . . . . . . . . . . 49 86 3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 49 87 3.8. The "ietf-crypto-types" YANG Module . . . . . . . . . . . 50 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 89 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 51 90 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 52 91 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 92 5.1. Normative References . . . . . . . . . . . . . . . . . . 52 93 5.2. Informative References . . . . . . . . . . . . . . . . . 53 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 56 95 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 56 96 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 56 97 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 56 98 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 57 99 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 58 100 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 58 101 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 58 102 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 58 103 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 59 104 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 59 105 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 59 106 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 60 107 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 60 108 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 60 109 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 60 110 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 60 111 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 61 112 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 61 113 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 62 114 A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 62 115 A.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 62 116 A.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 62 117 A.23. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 62 118 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63 121 1. Introduction 123 This document presents a YANG 1.1 [RFC7950] module defining 124 identities, typedefs, and groupings useful to cryptographic 125 applications. 127 1.1. Relation to other RFCs 129 This document presents one or more YANG modules [RFC7950] that are 130 part of a collection of RFCs that work together to, ultimately, 131 enable the configuration of the clients and servers of both the 132 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 134 The modules have been defined in a modular fashion to enable their 135 use by other efforts, some of which are known to be in progress at 136 the time of this writing, with many more expected to be defined in 137 time. 139 The normative dependency relationship between the various RFCs in the 140 collection is presented in the below diagram. The labels in the 141 diagram represent the primary purpose provided by each RFC. 142 Hyperlinks to each RFC are provided below the diagram. 144 crypto-types 145 ^ ^ 146 / \ 147 / \ 148 truststore keystore 149 ^ ^ ^ ^ 150 | +---------+ | | 151 | | | | 152 | +------------+ | 153 tcp-client-server | / | | 154 ^ ^ ssh-client-server | | 155 | | ^ tls-client-server 156 | | | ^ ^ http-client-server 157 | | | | | ^ 158 | | | +-----+ +---------+ | 159 | | | | | | 160 | +-----------|--------|--------------+ | | 161 | | | | | | 162 +-----------+ | | | | | 163 | | | | | | 164 | | | | | | 165 netconf-client-server restconf-client-server 167 +=======================+===========================================+ 168 |Label in Diagram | Originating RFC | 169 +=======================+===========================================+ 170 |crypto-types | [I-D.ietf-netconf-crypto-types] | 171 +-----------------------+-------------------------------------------+ 172 |truststore | [I-D.ietf-netconf-trust-anchors] | 173 +-----------------------+-------------------------------------------+ 174 |keystore | [I-D.ietf-netconf-keystore] | 175 +-----------------------+-------------------------------------------+ 176 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 177 +-----------------------+-------------------------------------------+ 178 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 179 +-----------------------+-------------------------------------------+ 180 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 181 +-----------------------+-------------------------------------------+ 182 |http-client-server | [I-D.ietf-netconf-http-client-server] | 183 +-----------------------+-------------------------------------------+ 184 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 185 +-----------------------+-------------------------------------------+ 186 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 187 +-----------------------+-------------------------------------------+ 189 Table 1: Label to RFC Mapping 191 1.2. Specification Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 1.3. Adherence to the NMDA 201 This document is compliant with the Network Management Datastore 202 Architecture (NMDA) [RFC8342]. It does not define any protocol 203 accessible nodes that are "config false". 205 1.4. Conventions 207 Various examples used in this document use a placeholder value for 208 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 209 This placeholder value is used as real base64 encoded structures are 210 often many lines long and hence distracting to the example being 211 presented. 213 2. The "ietf-crypto-types" Module 215 This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- 216 types". A high-level overview of the module is provided in 217 Section 2.1. Examples illustrating the module's use are provided in 218 Examples (Section 2.2). The YANG module itself is defined in 219 Section 2.3. 221 2.1. Data Model Overview 223 This section provides an overview of the "ietf-crypto-types" module 224 in terms of its features, identities, typedefs, and groupings. 226 2.1.1. Features 228 The following diagram lists all the "feature" statements defined in 229 the "ietf-crypto-types" module: 231 Features: 232 +-- hidden-keys 233 +-- password-encryption 234 +-- private-key-encryption 235 +-- symmetric-key-encryption 236 +-- one-symmetric-key-format 237 +-- one-asymmetric-key-format 238 +-- cms-encrypted-data-format 239 +-- cms-enveloped-data-format 240 +-- certificate-expiration-notification 241 +-- symmetrically-encrypted-value-format 242 +-- asymmetrically-encrypted-value-format 243 +-- certificate-signing-request-generation 245 | The diagram above uses syntax that is similar to but not 246 | defined in [RFC8340]. 248 2.1.2. Identities 250 The following diagram illustrates the relationship amongst the 251 "identity" statements defined in the "ietf-crypto-types" module: 253 Identities: 254 +-- public-key-format 255 | +-- subject-public-key-info-format 256 | +-- ssh-public-key-format 257 +-- private-key-format 258 | +-- rsa-private-key-format 259 | +-- ec-private-key-format 260 | +-- one-asymmetric-key-format 261 | {one-asymmetric-key-format}? 262 +-- symmetric-key-format 263 | +-- octet-string-key-format 264 | +-- one-symmetric-key-format 265 | {one-symmetric-key-format}? 266 +-- encrypted-value-format 267 +-- symmetrically-encrypted-value-format 268 | | {symmetrically-encrypted-value-format}? 269 | +-- cms-encrypted-data-format 270 | {cms-encrypted-data-format}? 271 +-- asymmetrically-encrypted-value-format 272 | {asymmetrically-encrypted-value-format}? 273 +-- cms-enveloped-data-format 274 {cms-enveloped-data-format}? 276 | The diagram above uses syntax that is similar to but not 277 | defined in [RFC8340]. 279 Comments: 281 * The diagram shows that there are four base identities. The first 282 three identities are used to indicate the format that key data, 283 while the fourth identity is used to indicate the format for 284 encrypted values. The base identities are "abstract", in the 285 object oriented programming sense, in that they only define a 286 "class" of formats, rather than a specific format. 288 * The various "leaf" identities define specific encoding formats. 289 The derived identities defined in this document are sufficient for 290 the effort described in Section 1.1 but, by nature of them being 291 identities, additional derived identities MAY be defined by future 292 efforts. 294 * Identities used to specify uncommon formats are enabled by 295 "feature" statements, allowing applications to support them when 296 needed. 298 2.1.3. Typedefs 300 The following diagram illustrates the relationship amongst the 301 "typedef" statements defined in the "ietf-crypto-types" module: 303 Typedefs: 304 binary 305 +-- csr-info 306 +-- csr 307 +-- x509 308 | +-- trust-anchor-cert-x509 309 | +-- end-entity-cert-x509 310 +-- crl 311 +-- ocsp-request 312 +-- ocsp-response 313 +-- cms 314 +-- data-content-cms 315 +-- signed-data-cms 316 | +-- trust-anchor-cert-cms 317 | +-- end-entity-cert-cms 318 +-- enveloped-data-cms 319 +-- digested-data-cms 320 +-- encrypted-data-cms 321 +-- authenticated-data-cms 323 | The diagram above uses syntax that is similar to but not 324 | defined in [RFC8340]. 326 Comments: 328 * All the typedefs defined in the "ietf-crypto-types" module extend 329 the "binary" type defined in [RFC7950]. 331 * Additionally, all the typedefs define a type for encoding an ASN.1 332 [ITU.X680.2015] structure using DER [ITU.X690.2015]. 334 * The "trust-anchor-*" and "end-entity-*" typedefs are syntactically 335 identical to their base typedefs and only distinguish themselves 336 by the expected nature of their content. These typedefs are 337 defined to facilitate common modeling needs. 339 2.1.4. Groupings 341 The "ietf-crypto-types" module defines the following "grouping" 342 statements: 344 * encrypted-value-grouping 345 * password-grouping 346 * symmetric-key-grouping 347 * public-key-grouping 348 * asymmetric-key-pair-grouping 349 * trust-anchor-cert-grouping 350 * end-entity-cert-grouping 351 * generate-csr-grouping 352 * asymmetric-key-pair-with-cert-grouping 353 * asymmetric-key-pair-with-certs-grouping 355 Each of these groupings are presented in the following subsections. 357 2.1.4.1. The "encrypted-value-grouping" Grouping 359 The following tree diagram [RFC8340] illustrates the "encrypted- 360 value-grouping" grouping: 362 grouping encrypted-value-grouping 363 +-- encrypted-by 364 +-- encrypted-value-format identityref 365 +-- encrypted-value binary 367 Comments: 369 * The "encrypted-by" node is an empty container (difficult to see in 370 the diagram) that a consuming module MUST augment key references 371 into. The "ietf-crypto-types" module is unable to populate this 372 container as the module only defines groupings. Section 2.2.1 373 presents an example illustrating a consuming module populating the 374 "encrypted-by" container. 376 * The "encrypted-value" node is the value, encrypted by the key 377 referenced by the "encrypted-by" node, and encoded in the format 378 appropriate for the kind of key it was encrypted by. 380 - If the value is encrypted by a symmetric key, then the 381 encrypted value is encoded using the format associated with the 382 "symmetrically-encrypted-value-format" identity. 384 - If the value is encrypted by an asymmetric key, then the 385 encrypted value is encoded using the format associated with the 386 "asymmetrically-encrypted-value-format" identity. 388 See Section 2.1.2 for information about the "format" identities. 390 2.1.4.2. The "password-grouping" Grouping 392 This section presents two tree diagrams [RFC8340] illustrating the 393 "password-grouping" grouping. The first tree diagram does not expand 394 the internally used grouping statement(s): 396 grouping password-grouping 397 +-- (password-type) 398 +--:(cleartext-password) 399 | +-- cleartext-password? string 400 +--:(encrypted-password) {password-encryption}? 401 +-- encrypted-password 402 +---u encrypted-value-grouping 404 The following tree diagram expands the internally used grouping 405 statement(s), enabling the grouping's full structure to be seen: 407 grouping password-grouping 408 +-- (password-type) 409 +--:(cleartext-password) 410 | +-- cleartext-password? string 411 +--:(encrypted-password) {password-encryption}? 412 +-- encrypted-password 413 +-- encrypted-by 414 +-- encrypted-value-format identityref 415 +-- encrypted-value binary 417 Comments: 419 * For the referenced grouping statement(s): 421 - The "encrypted-value-grouping" grouping is discussed in 422 Section 2.1.4.1. 424 * The "choice" statement enables the password data to be cleartext 425 or encrypted, as follows: 427 - The "cleartext-password" node can encode any cleartext value. 428 - The "encrypted-password" node's structure is discussed in 429 Section 2.1.4.1. 431 2.1.4.3. The "symmetric-key-grouping" Grouping 433 This section presents two tree diagrams [RFC8340] illustrating the 434 "symmetric-key-grouping" grouping. The first tree diagram does not 435 expand the internally used grouping statement(s): 437 grouping symmetric-key-grouping 438 +-- key-format? identityref 439 +-- (key-type) 440 +--:(cleartext-key) 441 | +-- cleartext-key? binary 442 +--:(hidden-key) {hidden-keys}? 443 | +-- hidden-key? empty 444 +--:(encrypted-key) {symmetric-key-encryption}? 445 +-- encrypted-key 446 +---u encrypted-value-grouping 448 The following tree diagram expands the internally used grouping 449 statement(s), enabling the grouping's full structure to be seen: 451 grouping symmetric-key-grouping 452 +-- key-format? identityref 453 +-- (key-type) 454 +--:(cleartext-key) 455 | +-- cleartext-key? binary 456 +--:(hidden-key) {hidden-keys}? 457 | +-- hidden-key? empty 458 +--:(encrypted-key) {symmetric-key-encryption}? 459 +-- encrypted-key 460 +-- encrypted-by 461 +-- encrypted-value-format identityref 462 +-- encrypted-value binary 464 Comments: 466 * For the referenced grouping statement(s): 468 - The "encrypted-value-grouping" grouping is discussed in 469 Section 2.1.4.1. 471 * The "key-format" node is an identity-reference to the "symmetric- 472 key-format" abstract base identity discussed in Section 2.1.2, 473 enabling the symmetric key to be encoded using the format defined 474 by any of the derived identities. 476 * The "choice" statement enables the private key data to be 477 cleartext, encrypted, or hidden, as follows: 479 - The "cleartext-key" node can encode any cleartext key value. 480 - The "hidden-key" node is of type "empty" as the real value 481 cannot be presented via the management interface. 482 - The "encrypted-key" node's structure is discussed in 483 Section 2.1.4.1. 485 2.1.4.4. The "public-key-grouping" Grouping 487 The following tree diagram [RFC8340] illustrates the "public-key- 488 grouping" grouping: 490 grouping public-key-grouping 491 +-- public-key-format identityref 492 +-- public-key binary 494 Comments: 496 * The "public-key-format" node is an identity-reference to the 497 "public-key-format" abstract base identity discussed in 498 Section 2.1.2, enabling the public key to be encoded using the 499 format defined by any of the derived identities. 501 * The "public-key" node is the public key data in the selected 502 format. No "choice" statement is used to hide or encrypt the 503 public key data because it is unnecessary to do so for public 504 keys. 506 2.1.4.5. The "asymmetric-key-pair-grouping" Grouping 508 This section presents two tree diagrams [RFC8340] illustrating the 509 "asymmetric-key-pair-grouping" grouping. The first tree diagram does 510 not expand the internally used grouping statement(s): 512 grouping asymmetric-key-pair-grouping 513 +---u public-key-grouping 514 +-- private-key-format? identityref 515 +-- (private-key-type) 516 +--:(cleartext-private-key) 517 | +-- cleartext-private-key? binary 518 +--:(hidden-private-key) {hidden-keys}? 519 | +-- hidden-private-key? empty 520 +--:(encrypted-private-key) {private-key-encryption}? 521 +-- encrypted-private-key 522 +---u encrypted-value-grouping 524 The following tree diagram expands the internally used grouping 525 statement(s), enabling the grouping's full structure to be seen: 527 grouping asymmetric-key-pair-grouping 528 +-- public-key-format identityref 529 +-- public-key binary 530 +-- private-key-format? identityref 531 +-- (private-key-type) 532 +--:(cleartext-private-key) 533 | +-- cleartext-private-key? binary 534 +--:(hidden-private-key) {hidden-keys}? 535 | +-- hidden-private-key? empty 536 +--:(encrypted-private-key) {private-key-encryption}? 537 +-- encrypted-private-key 538 +-- encrypted-by 539 +-- encrypted-value-format identityref 540 +-- encrypted-value binary 542 Comments: 544 * For the referenced grouping statement(s): 546 - The "public-key-grouping" grouping is discussed in 547 Section 2.1.4.4. 548 - The "encrypted-value-grouping" grouping is discussed in 549 Section 2.1.4.1. 551 * The "private-key-format" node is an identity-reference to the 552 "private-key-format" abstract base identity discussed in 553 Section 2.1.2, enabling the private key to be encoded using the 554 format defined by any of the derived identities. 556 * The "choice" statement enables the private key data to be 557 cleartext, encrypted, or hidden, as follows: 559 - The "cleartext-private-key" node can encode any cleartext key 560 value. 561 - The "hidden-private-key" node is of type "empty" as the real 562 value cannot be presented via the management interface. 563 - The "encrypted-private-key" node's structure is discussed in 564 Section 2.1.4.1. 566 2.1.4.6. The "certificate-expiration-grouping" Grouping 568 The following tree diagram [RFC8340] illustrates the "certificate- 569 expiration-grouping" grouping: 571 grouping certificate-expiration-grouping 572 +---n certificate-expiration 573 {certificate-expiration-notification}? 574 +-- expiration-date yang:date-and-time 576 Comments: 578 * This grouping's only purpose is to define the "certificate- 579 expiration" notification statement, used by the groupings defined 580 in Section 2.1.4.7 and Section 2.1.4.8. 582 * The "certificate-expiration" notification enables servers to 583 notify clients when certificates are nearing expiration. 585 * The "expiration-date" node indicates when the designated 586 certificate will (or did) expire. 588 * Identification of the certificate that is expiring is built into 589 the notification itself. For an example, please see 590 Section 2.2.3. 592 2.1.4.7. The "trust-anchor-cert-grouping" Grouping 594 This section presents two tree diagrams [RFC8340] illustrating the 595 "trust-anchor-cert-grouping" grouping. The first tree diagram does 596 not expand the internally used grouping statement(s): 598 grouping trust-anchor-cert-grouping 599 +-- cert-data? trust-anchor-cert-cms 600 +---u certificate-expiration-grouping 602 The following tree diagram expands the internally used grouping 603 statement(s), enabling the grouping's full structure to be seen: 605 grouping trust-anchor-cert-grouping 606 +-- cert-data? trust-anchor-cert-cms 607 +---n certificate-expiration 608 {certificate-expiration-notification}? 609 +-- expiration-date yang:date-and-time 611 Comments: 613 * For the referenced grouping statement(s): 615 - The "certificate-expiration-grouping" grouping is discussed in 616 Section 2.1.4.6. 618 * The "cert-data" node contains a chain of one or more certificates 619 encoded using a "signed-data-cms" typedef discussed in 620 Section 2.1.3. 622 2.1.4.8. The "end-entity-cert-grouping" Grouping 624 This section presents two tree diagrams [RFC8340] illustrating the 625 "end-entity-cert-grouping" grouping. The first tree diagram does not 626 expand the internally used grouping statement(s): 628 grouping end-entity-cert-grouping 629 +-- cert-data? end-entity-cert-cms 630 +---u certificate-expiration-grouping 632 The following tree diagram expands the internally used grouping 633 statement(s), enabling the grouping's full structure to be seen: 635 grouping end-entity-cert-grouping 636 +-- cert-data? end-entity-cert-cms 637 +---n certificate-expiration 638 {certificate-expiration-notification}? 639 +-- expiration-date yang:date-and-time 641 Comments: 643 * For the referenced grouping statement(s): 645 - The "certificate-expiration-grouping" grouping is discussed in 646 Section 2.1.4.6. 648 * The "cert-data" node contains a chain of one or more certificates 649 encoded using a "signed-data-cms" typedef discussed in 650 Section 2.1.3. 652 2.1.4.9. The "generate-csr-grouping" Grouping 654 The following tree diagram [RFC8340] illustrates the "generate-csr- 655 grouping" grouping: 657 grouping generate-csr-grouping 658 +---x generate-certificate-signing-request 659 {certificate-signing-request-generation}? 660 +---w input 661 | +---w csr-info ct:csr-info 662 +--ro output 663 +--ro certificate-signing-request ct:csr 665 Comments: 667 * This grouping's only purpose is to define the "generate- 668 certificate-signing-request" action statement, used by the 669 groupings defined in Section 2.1.4.10 and Section 2.1.4.11. 671 * This action takes as input a "csr-info" type and returns a "csr" 672 type, both of which are discussed in Section 2.1.3. 674 * For an example, please see Section 2.2.2. 676 2.1.4.10. The "asymmetric-key-pair-with-cert-grouping" Grouping 678 This section presents two tree diagrams [RFC8340] illustrating the 679 "asymmetric-key-pair-with-cert-grouping" grouping. The first tree 680 diagram does not expand the internally used grouping statement(s): 682 grouping asymmetric-key-pair-with-cert-grouping 683 +---u asymmetric-key-pair-grouping 684 +---u end-entity-cert-grouping 685 +---u generate-csr-grouping 687 The following tree diagram expands the internally used grouping 688 statement(s), enabling the grouping's full structure to be seen: 690 grouping asymmetric-key-pair-with-cert-grouping 691 +-- public-key-format identityref 692 +-- public-key binary 693 +-- private-key-format? identityref 694 +-- (private-key-type) 695 | +--:(cleartext-private-key) 696 | | +-- cleartext-private-key? binary 697 | +--:(hidden-private-key) {hidden-keys}? 698 | | +-- hidden-private-key? empty 699 | +--:(encrypted-private-key) {private-key-encryption}? 700 | +-- encrypted-private-key 701 | +-- encrypted-by 702 | +-- encrypted-value-format identityref 703 | +-- encrypted-value binary 704 +-- cert-data? end-entity-cert-cms 705 +---n certificate-expiration 706 | {certificate-expiration-notification}? 707 | +-- expiration-date yang:date-and-time 708 +---x generate-certificate-signing-request 709 {certificate-signing-request-generation}? 710 +---w input 711 | +---w csr-info ct:csr-info 712 +--ro output 713 +--ro certificate-signing-request ct:csr 715 Comments: 717 * This grouping defines an asymmetric key with at most one 718 associated certificate, a commonly needed combination in protocol 719 models. 721 * For the referenced grouping statement(s): 723 - The "asymmetric-key-pair-grouping" grouping is discussed in 724 Section 2.1.4.5. 725 - The "end-entity-cert-grouping" grouping is discussed in 726 Section 2.1.4.8. 727 - The "generate-csr-grouping" grouping is discussed in 728 Section 2.1.4.9. 730 2.1.4.11. The "asymmetric-key-pair-with-certs-grouping" Grouping 732 This section presents two tree diagrams [RFC8340] illustrating the 733 "asymmetric-key-pair-with-certs-grouping" grouping. The first tree 734 diagram does not expand the internally used grouping statement(s): 736 grouping asymmetric-key-pair-with-certs-grouping 737 +---u asymmetric-key-pair-grouping 738 +-- certificates 739 | +-- certificate* [name] 740 | +-- name? string 741 | +---u end-entity-cert-grouping 742 +---u generate-csr-grouping 744 The following tree diagram expands the internally used grouping 745 statement(s), enabling the grouping's full structure to be seen: 747 grouping asymmetric-key-pair-with-certs-grouping 748 +-- public-key-format identityref 749 +-- public-key binary 750 +-- private-key-format? identityref 751 +-- (private-key-type) 752 | +--:(cleartext-private-key) 753 | | +-- cleartext-private-key? binary 754 | +--:(hidden-private-key) {hidden-keys}? 755 | | +-- hidden-private-key? empty 756 | +--:(encrypted-private-key) {private-key-encryption}? 757 | +-- encrypted-private-key 758 | +-- encrypted-by 759 | +-- encrypted-value-format identityref 760 | +-- encrypted-value binary 761 +-- certificates 762 | +-- certificate* [name] 763 | +-- name? string 764 | +-- cert-data end-entity-cert-cms 765 | +---n certificate-expiration 766 | {certificate-expiration-notification}? 767 | +-- expiration-date yang:date-and-time 768 +---x generate-certificate-signing-request 769 {certificate-signing-request-generation}? 770 +---w input 771 | +---w csr-info ct:csr-info 772 +--ro output 773 +--ro certificate-signing-request ct:csr 775 Comments: 777 * This grouping defines an asymmetric key with one or more 778 associated certificates, a commonly needed combination in 779 configuration models. 781 * For the referenced grouping statement(s): 783 - The "asymmetric-key-pair-grouping" grouping is discussed in 784 Section 2.1.4.5. 785 - The "end-entity-cert-grouping" grouping is discussed in 786 Section 2.1.4.8. 787 - The "generate-csr-grouping" grouping is discussed in 788 Section 2.1.4.9. 790 2.1.5. Protocol-accessible Nodes 792 The "ietf-crypto-types" module does not contain any protocol- 793 accessible nodes, but the module needs to be "implemented", as 794 described in Section 5.6.5 of [RFC7950], in order for the identities 795 in Section 2.1.2 to be defined. 797 2.2. Example Usage 799 2.2.1. The "symmetric-key-grouping" and "asymmetric-key-pair-with- 800 certs-grouping" Grouping 802 The following non-normative module is constructed in order to 803 illustrate the use of the "symmetric-key-grouping" (Section 2.1.4.3), 804 the "asymmetric-key-pair-with-certs-grouping" (Section 2.1.4.11), and 805 the "password-grouping" (Section 2.1.4.2) grouping statements. 807 Notably, this example illustrates a hidden asymmetric key (ex-hidden- 808 asymmetric-key) has been used to encrypt a symmetric key (ex- 809 encrypted-one-symmetric-based-symmetric-key) that has been used to 810 encrypt another asymmetric key (ex-encrypted-rsa-based-asymmetric- 811 key). Additionally, the symmetric key is also used to encrypt a 812 password (ex-encrypted-password). 814 module ex-crypto-types-usage { 815 yang-version 1.1; 816 namespace "http://example.com/ns/example-crypto-types-usage"; 817 prefix ectu; 819 import ietf-crypto-types { 820 prefix ct; 821 reference 822 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 823 } 825 organization 826 "Example Corporation"; 827 contact 828 "YANG Designer "; 830 description 831 "This module illustrates the 'symmetric-key-grouping' 832 and 'asymmetric-key-grouping' groupings defined in 833 the 'ietf-crypto-types' module defined in RFC AAAA."; 835 revision 2022-03-07 { 836 description 837 "Initial version"; 838 reference 839 "RFC AAAA: Common YANG Data Types for Cryptography"; 840 } 842 container symmetric-keys { 843 description 844 "A container of symmetric keys."; 845 list symmetric-key { 846 key "name"; 847 description 848 "A symmetric key"; 849 leaf name { 850 type string; 851 description 852 "An arbitrary name for this key."; 853 } 854 uses ct:symmetric-key-grouping { 855 augment "key-type/encrypted-key/encrypted-key/" 856 + "encrypted-by" { 857 description 858 "Augments in a choice statement enabling the 859 encrypting key to be any other symmetric or 860 asymmetric key."; 861 uses encrypted-by-choice-grouping; 862 } 863 } 864 } 865 } 866 container asymmetric-keys { 867 description 868 "A container of asymmetric keys."; 869 list asymmetric-key { 870 key "name"; 871 leaf name { 872 type string; 873 description 874 "An arbitrary name for this key."; 875 } 876 uses ct:asymmetric-key-pair-with-certs-grouping { 877 augment "private-key-type/encrypted-private-key/" 878 + "encrypted-private-key/encrypted-by" { 880 description 881 "Augments in a choice statement enabling the 882 encrypting key to be any other symmetric or 883 asymmetric key."; 884 uses encrypted-by-choice-grouping; 885 } 886 } 887 description 888 "An asymmetric key pair with associated certificates."; 889 } 890 } 891 container passwords { 892 description 893 "A container of passwords."; 894 list password { 895 key "name"; 896 leaf name { 897 type string; 898 description 899 "An arbitrary name for this password."; 900 } 901 uses ct:password-grouping { 902 augment "password-type/encrypted-password/" 903 + "encrypted-password/encrypted-by" { 904 description 905 "Augments in a choice statement enabling the 906 encrypting key to be any symmetric or 907 asymmetric key."; 908 uses encrypted-by-choice-grouping; 909 } 910 } 911 description 912 "A password."; 913 } 914 } 916 grouping encrypted-by-choice-grouping { 917 description 918 "A grouping that defines a choice enabling references 919 to other keys."; 920 choice encrypted-by-choice { 921 mandatory true; 922 description 923 "A choice amongst other symmetric or asymmetric keys."; 924 case symmetric-key-ref { 925 leaf symmetric-key-ref { 926 type leafref { 927 path "/ectu:symmetric-keys/ectu:symmetric-key/" 928 + "ectu:name"; 929 } 930 description 931 "Identifies the symmetric key that encrypts this key."; 932 } 933 } 934 case asymmetric-key-ref { 935 leaf asymmetric-key-ref { 936 type leafref { 937 path "/ectu:asymmetric-keys/ectu:asymmetric-key/" 938 + "ectu:name"; 939 } 940 description 941 "Identifies the asymmetric key that encrypts this key."; 942 } 943 } 944 } 945 } 946 } 948 The tree diagram [RFC8340] for this example module follows: 950 module: ex-crypto-types-usage 951 +--rw symmetric-keys 952 | +--rw symmetric-key* [name] 953 | +--rw name string 954 | +--rw key-format? identityref 955 | +--rw (key-type) 956 | +--:(cleartext-key) 957 | | +--rw cleartext-key? binary 958 | +--:(hidden-key) {hidden-keys}? 959 | | +--rw hidden-key? empty 960 | +--:(encrypted-key) {symmetric-key-encryption}? 961 | +--rw encrypted-key 962 | +--rw encrypted-by 963 | | +--rw (encrypted-by-choice) 964 | | +--:(symmetric-key-ref) 965 | | | +--rw symmetric-key-ref? leafref 966 | | +--:(asymmetric-key-ref) 967 | | +--rw asymmetric-key-ref? leafref 968 | +--rw encrypted-value-format identityref 969 | +--rw encrypted-value binary 970 +--rw asymmetric-keys 971 | +--rw asymmetric-key* [name] 972 | +--rw name string 973 | +--rw public-key-format identityref 974 | +--rw public-key binary 975 | +--rw private-key-format? identityref 976 | +--rw (private-key-type) 977 | | +--:(cleartext-private-key) 978 | | | +--rw cleartext-private-key? binary 979 | | +--:(hidden-private-key) {hidden-keys}? 980 | | | +--rw hidden-private-key? empty 981 | | +--:(encrypted-private-key) {private-key-encryption}? 982 | | +--rw encrypted-private-key 983 | | +--rw encrypted-by 984 | | | +--rw (encrypted-by-choice) 985 | | | +--:(symmetric-key-ref) 986 | | | | +--rw symmetric-key-ref? leafref 987 | | | +--:(asymmetric-key-ref) 988 | | | +--rw asymmetric-key-ref? leafref 989 | | +--rw encrypted-value-format identityref 990 | | +--rw encrypted-value binary 991 | +--rw certificates 992 | | +--rw certificate* [name] 993 | | +--rw name string 994 | | +--rw cert-data end-entity-cert-cms 995 | | +---n certificate-expiration 996 | | {certificate-expiration-notification}? 997 | | +-- expiration-date yang:date-and-time 998 | +---x generate-certificate-signing-request 999 | {certificate-signing-request-generation}? 1000 | +---w input 1001 | | +---w csr-info ct:csr-info 1002 | +--ro output 1003 | +--ro certificate-signing-request ct:csr 1004 +--rw passwords 1005 +--rw password* [name] 1006 +--rw name string 1007 +--rw (password-type) 1008 +--:(cleartext-password) 1009 | +--rw cleartext-password? string 1010 +--:(encrypted-password) {password-encryption}? 1011 +--rw encrypted-password 1012 +--rw encrypted-by 1013 | +--rw (encrypted-by-choice) 1014 | +--:(symmetric-key-ref) 1015 | | +--rw symmetric-key-ref? leafref 1016 | +--:(asymmetric-key-ref) 1017 | +--rw asymmetric-key-ref? leafref 1018 +--rw encrypted-value-format identityref 1019 +--rw encrypted-value binary 1021 Finally, the following example illustrates various symmetric and 1022 asymmetric keys as they might appear in configuration: 1024 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1026 1029 1030 ex-hidden-symmetric-key 1031 1032 1033 1034 ex-octet-string-based-symmetric-key 1035 ct:octet-string-key-format 1036 BASE64VALUE= 1037 1038 1039 ex-one-symmetric-based-symmetric-key 1040 ct:one-symmetric-key-format 1041 BASE64VALUE= 1042 1043 1044 ex-encrypted-one-symmetric-based-symmetric-key 1045 ct:one-symmetric-key-format 1046 1047 1048 ex-hidden-asymmetric-key 1050 1051 1052 ct:cms-enveloped-data-format 1053 1054 BASE64VALUE= 1055 1056 1057 1059 1062 1063 ex-hidden-asymmetric-key 1064 1065 ct:subject-public-key-info-format 1066 1067 BASE64VALUE= 1068 1069 1070 1071 ex-hidden-asymmetric-key-cert 1072 BASE64VALUE= 1073 1074 1075 1076 1077 ex-rsa-based-asymmetric-key 1078 1079 ct:subject-public-key-info-format 1080 1081 BASE64VALUE= 1082 1083 ct:rsa-private-key-format 1084 1085 BASE64VALUE= 1086 1087 1088 ex-cert 1089 BASE64VALUE= 1090 1091 1092 1093 1094 ex-one-asymmetric-based-asymmetric-key 1095 1096 ct:subject-public-key-info-format 1097 1098 BASE64VALUE= 1099 1100 ct:one-asymmetric-key-format 1101 1102 BASE64VALUE= 1103 1104 1105 ex-encrypted-rsa-based-asymmetric-key 1106 1107 ct:subject-public-key-info-format 1108 1109 BASE64VALUE= 1110 1111 ct:rsa-private-key-format 1112 1113 1114 1115 ex-encrypted-one-symmetric-based-symmetri\ 1116 c-key 1117 1118 1119 ct:cms-encrypted-data-format 1121 1122 BASE64VALUE= 1123 1124 1125 1127 1130 1131 ex-cleartext-password 1132 super-secret 1133 1134 1135 ex-encrypted-password 1136 1137 1138 ex-encrypted-one-symmetric-based-symmetri\ 1139 c-key 1140 1141 1142 ct:cms-encrypted-data-format 1143 1144 BASE64VALUE= 1145 1146 1147 1149 2.2.2. The "generate-certificate-signing-request" Action 1151 The following example illustrates the "generate-certificate-signing- 1152 request" action, discussed in Section 2.1.4.9, with the NETCONF 1153 protocol. 1155 REQUEST 1156 1158 1159 1161 1162 ex-key-sect571r1 1163 1164 BASE64VALUE= 1165 1166 1167 1168 1169 1171 RESPONSE 1173 1175 1177 BASE64VALUE= 1178 1179 1181 2.2.3. The "certificate-expiration" Notification 1183 The following example illustrates the "certificate-expiration" 1184 notification, discussed in Section 2.1.4.6, with the NETCONF 1185 protocol. 1187 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1189 1191 2018-05-25T00:01:00Z 1192 1194 1195 ex-hidden-asymmetric-key 1196 1197 1198 ex-hidden-asymmetric-key 1199 1200 2018-08-05T14:18:53-05:00 1202 1203 1204 1205 1206 1207 1209 2.3. YANG Module 1211 This module has normative references to [RFC2119], [RFC2986], 1212 [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], 1213 [RFC6031], [RFC6125], [RFC6991], [RFC7093], [RFC8174], [RFC8341], and 1214 [ITU.X690.2015]. 1216 file "ietf-crypto-types@2022-03-07.yang" 1218 module ietf-crypto-types { 1219 yang-version 1.1; 1220 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 1221 prefix ct; 1223 import ietf-yang-types { 1224 prefix yang; 1225 reference 1226 "RFC 6991: Common YANG Data Types"; 1227 } 1229 import ietf-netconf-acm { 1230 prefix nacm; 1231 reference 1232 "RFC 8341: Network Configuration Access Control Model"; 1233 } 1234 organization 1235 "IETF NETCONF (Network Configuration) Working Group"; 1237 contact 1238 "WG Web: https://datatracker.ietf.org/wg/netconf 1239 WG List: NETCONF WG list 1240 Author: Kent Watsen "; 1242 description 1243 "This module defines common YANG types for cryptographic 1244 applications. 1246 Copyright (c) 2021 IETF Trust and the persons identified 1247 as authors of the code. All rights reserved. 1249 Redistribution and use in source and binary forms, with 1250 or without modification, is permitted pursuant to, and 1251 subject to the license terms contained in, the Revised 1252 BSD License set forth in Section 4.c of the IETF Trust's 1253 Legal Provisions Relating to IETF Documents 1254 (https://trustee.ietf.org/license-info). 1256 This version of this YANG module is part of RFC AAAA 1257 (https://www.rfc-editor.org/info/rfcAAAA); see the RFC 1258 itself for full legal notices. 1260 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1261 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1262 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1263 are to be interpreted as described in BCP 14 (RFC 2119) 1264 (RFC 8174) when, and only when, they appear in all 1265 capitals, as shown here."; 1267 revision 2022-03-07 { 1268 description 1269 "Initial version"; 1270 reference 1271 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 1272 } 1274 /****************/ 1275 /* Features */ 1276 /****************/ 1278 feature one-symmetric-key-format { 1279 description 1280 "Indicates that the server supports the 1281 'one-symmetric-key-format' identity."; 1283 } 1285 feature one-asymmetric-key-format { 1286 description 1287 "Indicates that the server supports the 1288 'one-asymmetric-key-format' identity."; 1289 } 1291 feature symmetrically-encrypted-value-format { 1292 description 1293 "Indicates that the server supports the 1294 'symmetrically-encrypted-value-format' identity."; 1295 } 1297 feature asymmetrically-encrypted-value-format { 1298 description 1299 "Indicates that the server supports the 1300 'asymmetrically-encrypted-value-format' identity."; 1301 } 1303 feature cms-enveloped-data-format { 1304 description 1305 "Indicates that the server supports the 1306 'cms-enveloped-data-format' identity."; 1307 } 1309 feature cms-encrypted-data-format { 1310 description 1311 "Indicates that the server supports the 1312 'cms-encrypted-data-format' identity."; 1313 } 1315 feature certificate-signing-request-generation { 1316 description 1317 "Indicates that the server implements the 1318 'generate-certificate-signing-request' action."; 1319 } 1321 feature certificate-expiration-notification { 1322 description 1323 "Indicates that the server implements the 1324 'certificate-expiration' notification."; 1325 } 1327 feature hidden-keys { 1328 description 1329 "Indicates that the server supports hidden keys."; 1330 } 1331 feature password-encryption { 1332 description 1333 "Indicates that the server supports password 1334 encryption."; 1335 } 1337 feature symmetric-key-encryption { 1338 description 1339 "Indicates that the server supports encryption 1340 of symmetric keys."; 1341 } 1343 feature private-key-encryption { 1344 description 1345 "Indicates that the server supports encryption 1346 of private keys."; 1347 } 1349 /*************************************************/ 1350 /* Base Identities for Key Format Structures */ 1351 /*************************************************/ 1353 identity symmetric-key-format { 1354 description 1355 "Base key-format identity for symmetric keys."; 1356 } 1358 identity public-key-format { 1359 description 1360 "Base key-format identity for public keys."; 1361 } 1363 identity private-key-format { 1364 description 1365 "Base key-format identity for private keys."; 1366 } 1368 /****************************************************/ 1369 /* Identities for Private Key Format Structures */ 1370 /****************************************************/ 1372 identity rsa-private-key-format { 1373 base private-key-format; 1374 description 1375 "Indicates that the private key value is encoded 1376 as an RSAPrivateKey (from RFC 3447)."; 1377 reference 1378 "RFC 3447: PKCS #1: RSA Cryptography 1379 Specifications Version 2.2"; 1380 } 1382 identity ec-private-key-format { 1383 base private-key-format; 1384 description 1385 "Indicates that the private key value is encoded 1386 as an ECPrivateKey (from RFC 5915)"; 1387 reference 1388 "RFC 5915: Elliptic Curve Private Key Structure"; 1389 } 1391 identity one-asymmetric-key-format { 1392 if-feature "one-asymmetric-key-format"; 1393 base private-key-format; 1394 description 1395 "Indicates that the private key value is a CMS 1396 OneAsymmetricKey structure, as defined in RFC 5958, 1397 encoded using ASN.1 distinguished encoding rules 1398 (DER), as specified in ITU-T X.690."; 1399 reference 1400 "RFC 5958: Asymmetric Key Packages 1401 ITU-T X.690: 1402 Information technology - ASN.1 encoding rules: 1403 Specification of Basic Encoding Rules (BER), 1404 Canonical Encoding Rules (CER) and Distinguished 1405 Encoding Rules (DER)."; 1406 } 1408 /***************************************************/ 1409 /* Identities for Public Key Format Structures */ 1410 /***************************************************/ 1412 identity ssh-public-key-format { 1413 base public-key-format; 1414 description 1415 "Indicates that the public key value is an SSH public key, 1416 as specified by RFC 4253, Section 6.6, i.e.: 1418 string certificate or public key format 1419 identifier 1420 byte[n] key/certificate data."; 1421 reference 1422 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 1423 } 1425 identity subject-public-key-info-format { 1426 base public-key-format; 1427 description 1428 "Indicates that the public key value is a SubjectPublicKeyInfo 1429 structure, as described in RFC 5280 encoded using ASN.1 1430 distinguished encoding rules (DER), as specified in 1431 ITU-T X.690."; 1432 reference 1433 "RFC 5280: 1434 Internet X.509 Public Key Infrastructure Certificate 1435 and Certificate Revocation List (CRL) Profile 1436 ITU-T X.690: 1437 Information technology - ASN.1 encoding rules: 1438 Specification of Basic Encoding Rules (BER), 1439 Canonical Encoding Rules (CER) and Distinguished 1440 Encoding Rules (DER)."; 1441 } 1443 /******************************************************/ 1444 /* Identities for Symmetric Key Format Structures */ 1445 /******************************************************/ 1447 identity octet-string-key-format { 1448 base symmetric-key-format; 1449 description 1450 "Indicates that the key is encoded as a raw octet string. 1451 The length of the octet string MUST be appropriate for 1452 the associated algorithm's block size. 1454 How the associated algorithm is known is outside the 1455 scope of this module. This statement also applies when 1456 the octet string has been encrypted."; 1457 } 1459 identity one-symmetric-key-format { 1460 if-feature "one-symmetric-key-format"; 1461 base symmetric-key-format; 1462 description 1463 "Indicates that the private key value is a CMS 1464 OneSymmetricKey structure, as defined in RFC 6031, 1465 encoded using ASN.1 distinguished encoding rules 1466 (DER), as specified in ITU-T X.690."; 1467 reference 1468 "RFC 6031: Cryptographic Message Syntax (CMS) 1469 Symmetric Key Package Content Type 1470 ITU-T X.690: 1471 Information technology - ASN.1 encoding rules: 1472 Specification of Basic Encoding Rules (BER), 1473 Canonical Encoding Rules (CER) and Distinguished 1474 Encoding Rules (DER)."; 1476 } 1478 /*************************************************/ 1479 /* Identities for Encrypted Value Structures */ 1480 /*************************************************/ 1482 identity encrypted-value-format { 1483 description 1484 "Base format identity for encrypted values."; 1485 } 1487 identity symmetrically-encrypted-value-format { 1488 if-feature "symmetrically-encrypted-value-format"; 1489 base encrypted-value-format; 1490 description 1491 "Base format identity for symmetrically encrypted 1492 values."; 1493 } 1495 identity asymmetrically-encrypted-value-format { 1496 if-feature "asymmetrically-encrypted-value-format"; 1497 base encrypted-value-format; 1498 description 1499 "Base format identity for asymmetrically encrypted 1500 values."; 1501 } 1503 identity cms-encrypted-data-format { 1504 if-feature "cms-encrypted-data-format"; 1505 base symmetrically-encrypted-value-format; 1506 description 1507 "Indicates that the encrypted value conforms to 1508 the 'encrypted-data-cms' type with the constraint 1509 that the 'unprotectedAttrs' value is not set."; 1510 reference 1511 "RFC 5652: Cryptographic Message Syntax (CMS) 1512 ITU-T X.690: 1513 Information technology - ASN.1 encoding rules: 1514 Specification of Basic Encoding Rules (BER), 1515 Canonical Encoding Rules (CER) and Distinguished 1516 Encoding Rules (DER)."; 1517 } 1519 identity cms-enveloped-data-format { 1520 if-feature "cms-enveloped-data-format"; 1521 base asymmetrically-encrypted-value-format; 1522 description 1523 "Indicates that the encrypted value conforms to the 1524 'enveloped-data-cms' type with the following constraints: 1526 The EnvelopedData structure MUST have exactly one 1527 'RecipientInfo'. 1529 If the asymmetric key supports public key cryptography 1530 (e.g., RSA), then the 'RecipientInfo' must be a 1531 'KeyTransRecipientInfo' with the 'RecipientIdentifier' 1532 using a 'subjectKeyIdentifier' with the value set using 1533 'method 1' in RFC 7093 over the recipient's public key. 1535 Otherwise, if the asymmetric key supports key agreement 1536 (e.g., ECC), then the 'RecipientInfo' must be a 1537 'KeyAgreeRecipientInfo'. The 'OriginatorIdentifierOrKey' 1538 value must use the 'OriginatorPublicKey' alternative. 1539 The 'UserKeyingMaterial' value must not be present. 1540 There must be exactly one 'RecipientEncryptedKeys' value 1541 having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' 1542 with the value set using 'method 1' in RFC 7093 over the 1543 recipient's public key."; 1544 reference 1545 "RFC 5652: Cryptographic Message Syntax (CMS) 1546 RFC 7093: 1547 Additional Methods for Generating Key 1548 Identifiers Values 1549 ITU-T X.690: 1550 Information technology - ASN.1 encoding rules: 1551 Specification of Basic Encoding Rules (BER), 1552 Canonical Encoding Rules (CER) and Distinguished 1553 Encoding Rules (DER)."; 1554 } 1556 /***************************************************/ 1557 /* Typedefs for ASN.1 structures from RFC 2986 */ 1558 /***************************************************/ 1560 typedef csr-info { 1561 type binary; 1562 description 1563 "A CertificationRequestInfo structure, as defined in 1564 RFC 2986, encoded using ASN.1 distinguished encoding 1565 rules (DER), as specified in ITU-T X.690."; 1566 reference 1567 "RFC 2986: PKCS #10: Certification Request Syntax 1568 Specification Version 1.7 1569 ITU-T X.690: 1570 Information technology - ASN.1 encoding rules: 1571 Specification of Basic Encoding Rules (BER), 1572 Canonical Encoding Rules (CER) and Distinguished 1573 Encoding Rules (DER)."; 1574 } 1576 typedef csr { 1577 type binary; 1578 description 1579 "A CertificationRequest structure, as specified in 1580 RFC 2986, encoded using ASN.1 distinguished encoding 1581 rules (DER), as specified in ITU-T X.690."; 1582 reference 1583 "RFC 2986: 1584 PKCS #10: Certification Request Syntax Specification 1585 Version 1.7 1586 ITU-T X.690: 1587 Information technology - ASN.1 encoding rules: 1588 Specification of Basic Encoding Rules (BER), 1589 Canonical Encoding Rules (CER) and Distinguished 1590 Encoding Rules (DER)."; 1591 } 1593 /***************************************************/ 1594 /* Typedefs for ASN.1 structures from RFC 5280 */ 1595 /***************************************************/ 1597 typedef x509 { 1598 type binary; 1599 description 1600 "A Certificate structure, as specified in RFC 5280, 1601 encoded using ASN.1 distinguished encoding rules (DER), 1602 as specified in ITU-T X.690."; 1603 reference 1604 "RFC 5280: 1605 Internet X.509 Public Key Infrastructure Certificate 1606 and Certificate Revocation List (CRL) Profile 1607 ITU-T X.690: 1608 Information technology - ASN.1 encoding rules: 1609 Specification of Basic Encoding Rules (BER), 1610 Canonical Encoding Rules (CER) and Distinguished 1611 Encoding Rules (DER)."; 1612 } 1614 typedef crl { 1615 type binary; 1616 description 1617 "A CertificateList structure, as specified in RFC 5280, 1618 encoded using ASN.1 distinguished encoding rules (DER), 1619 as specified in ITU-T X.690."; 1621 reference 1622 "RFC 5280: 1623 Internet X.509 Public Key Infrastructure Certificate 1624 and Certificate Revocation List (CRL) Profile 1625 ITU-T X.690: 1626 Information technology - ASN.1 encoding rules: 1627 Specification of Basic Encoding Rules (BER), 1628 Canonical Encoding Rules (CER) and Distinguished 1629 Encoding Rules (DER)."; 1630 } 1632 /***************************************************/ 1633 /* Typedefs for ASN.1 structures from RFC 6960 */ 1634 /***************************************************/ 1636 typedef oscp-request { 1637 type binary; 1638 description 1639 "A OCSPRequest structure, as specified in RFC 6960, 1640 encoded using ASN.1 distinguished encoding rules 1641 (DER), as specified in ITU-T X.690."; 1642 reference 1643 "RFC 6960: 1644 X.509 Internet Public Key Infrastructure Online 1645 Certificate Status Protocol - OCSP 1646 ITU-T X.690: 1647 Information technology - ASN.1 encoding rules: 1648 Specification of Basic Encoding Rules (BER), 1649 Canonical Encoding Rules (CER) and Distinguished 1650 Encoding Rules (DER)."; 1651 } 1653 typedef oscp-response { 1654 type binary; 1655 description 1656 "A OCSPResponse structure, as specified in RFC 6960, 1657 encoded using ASN.1 distinguished encoding rules 1658 (DER), as specified in ITU-T X.690."; 1659 reference 1660 "RFC 6960: 1661 X.509 Internet Public Key Infrastructure Online 1662 Certificate Status Protocol - OCSP 1663 ITU-T X.690: 1664 Information technology - ASN.1 encoding rules: 1665 Specification of Basic Encoding Rules (BER), 1666 Canonical Encoding Rules (CER) and Distinguished 1667 Encoding Rules (DER)."; 1668 } 1669 /***********************************************/ 1670 /* Typedefs for ASN.1 structures from 5652 */ 1671 /***********************************************/ 1673 typedef cms { 1674 type binary; 1675 description 1676 "A ContentInfo structure, as specified in RFC 5652, 1677 encoded using ASN.1 distinguished encoding rules (DER), 1678 as specified in ITU-T X.690."; 1679 reference 1680 "RFC 5652: 1681 Cryptographic Message Syntax (CMS) 1682 ITU-T X.690: 1683 Information technology - ASN.1 encoding rules: 1684 Specification of Basic Encoding Rules (BER), 1685 Canonical Encoding Rules (CER) and Distinguished 1686 Encoding Rules (DER)."; 1687 } 1689 typedef data-content-cms { 1690 type cms; 1691 description 1692 "A CMS structure whose top-most content type MUST be the 1693 data content type, as described by Section 4 in RFC 5652."; 1694 reference 1695 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1696 } 1698 typedef signed-data-cms { 1699 type cms; 1700 description 1701 "A CMS structure whose top-most content type MUST be the 1702 signed-data content type, as described by Section 5 in 1703 RFC 5652."; 1704 reference 1705 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1706 } 1708 typedef enveloped-data-cms { 1709 type cms; 1710 description 1711 "A CMS structure whose top-most content type MUST be the 1712 enveloped-data content type, as described by Section 6 1713 in RFC 5652."; 1714 reference 1715 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1716 } 1717 typedef digested-data-cms { 1718 type cms; 1719 description 1720 "A CMS structure whose top-most content type MUST be the 1721 digested-data content type, as described by Section 7 1722 in RFC 5652."; 1723 reference 1724 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1725 } 1727 typedef encrypted-data-cms { 1728 type cms; 1729 description 1730 "A CMS structure whose top-most content type MUST be the 1731 encrypted-data content type, as described by Section 8 1732 in RFC 5652."; 1733 reference 1734 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1735 } 1737 typedef authenticated-data-cms { 1738 type cms; 1739 description 1740 "A CMS structure whose top-most content type MUST be the 1741 authenticated-data content type, as described by Section 9 1742 in RFC 5652."; 1743 reference 1744 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1745 } 1747 /*********************************************************/ 1748 /* Typedefs for ASN.1 structures related to RFC 5280 */ 1749 /*********************************************************/ 1751 typedef trust-anchor-cert-x509 { 1752 type x509; 1753 description 1754 "A Certificate structure that MUST encode a self-signed 1755 root certificate."; 1756 } 1758 typedef end-entity-cert-x509 { 1759 type x509; 1760 description 1761 "A Certificate structure that MUST encode a certificate 1762 that is neither self-signed nor having Basic constraint 1763 CA true."; 1764 } 1765 /*********************************************************/ 1766 /* Typedefs for ASN.1 structures related to RFC 5652 */ 1767 /*********************************************************/ 1769 typedef trust-anchor-cert-cms { 1770 type signed-data-cms; 1771 description 1772 "A CMS SignedData structure that MUST contain the chain of 1773 X.509 certificates needed to authenticate the certificate 1774 presented by a client or end-entity. 1776 The CMS MUST contain only a single chain of certificates. 1777 The client or end-entity certificate MUST only authenticate 1778 to last intermediate CA certificate listed in the chain. 1780 In all cases, the chain MUST include a self-signed root 1781 certificate. In the case where the root certificate is 1782 itself the issuer of the client or end-entity certificate, 1783 only one certificate is present. 1785 This CMS structure MAY (as applicable where this type is 1786 used) also contain suitably fresh (as defined by local 1787 policy) revocation objects with which the device can 1788 verify the revocation status of the certificates. 1790 This CMS encodes the degenerate form of the SignedData 1791 structure that is commonly used to disseminate X.509 1792 certificates and revocation objects (RFC 5280)."; 1793 reference 1794 "RFC 5280: 1795 Internet X.509 Public Key Infrastructure Certificate 1796 and Certificate Revocation List (CRL) Profile."; 1797 } 1799 typedef end-entity-cert-cms { 1800 type signed-data-cms; 1801 description 1802 "A CMS SignedData structure that MUST contain the end 1803 entity certificate itself, and MAY contain any number 1804 of intermediate certificates leading up to a trust 1805 anchor certificate. The trust anchor certificate 1806 MAY be included as well. 1808 The CMS MUST contain a single end entity certificate. 1809 The CMS MUST NOT contain any spurious certificates. 1811 This CMS structure MAY (as applicable where this type is 1812 used) also contain suitably fresh (as defined by local 1813 policy) revocation objects with which the device can 1814 verify the revocation status of the certificates. 1816 This CMS encodes the degenerate form of the SignedData 1817 structure that is commonly used to disseminate X.509 1818 certificates and revocation objects (RFC 5280)."; 1819 reference 1820 "RFC 5280: 1821 Internet X.509 Public Key Infrastructure Certificate 1822 and Certificate Revocation List (CRL) Profile."; 1823 } 1825 /*****************/ 1826 /* Groupings */ 1827 /*****************/ 1829 grouping encrypted-value-grouping { 1830 description 1831 "A reusable grouping for a value that has been encrypted by 1832 a referenced symmetric or asymmetric key."; 1833 container encrypted-by { 1834 nacm:default-deny-write; 1835 description 1836 "An empty container enabling a reference to the key that 1837 encrypted the value to be augmented in. The referenced 1838 key MUST be a symmetric key or an asymmetric key. 1840 A symmetric key MUST be referenced via a leaf node called 1841 'symmetric-key-ref'. An asymmetric key MUST be referenced 1842 via a leaf node called 'asymmetric-key-ref'. 1844 The leaf nodes MUST be direct descendants in the data tree, 1845 and MAY be direct descendants in the schema tree."; 1846 } 1847 leaf encrypted-value-format { 1848 type identityref { 1849 base encrypted-value-format; 1850 } 1851 mandatory true; 1852 description 1853 "Identifies the format of the 'encrypted-value' leaf. 1855 If 'encrypted-by' points to a symmetric key, then a 1856 'symmetrically-encrypted-value-format' based identity 1857 MUST by set (e.g., cms-encrypted-data-format). 1859 If 'encrypted-by' points to an asymmetric key, then an 1860 'asymmetrically-encrypted-value-format' based identity 1861 MUST by set (e.g., cms-enveloped-data-format)."; 1862 } 1863 leaf encrypted-value { 1864 nacm:default-deny-write; 1865 type binary; 1866 must '../encrypted-by'; 1867 mandatory true; 1868 description 1869 "The value, encrypted using the referenced symmetric 1870 or asymmetric key. The value MUST be encoded using 1871 the format associated with the 'encrypted-value-format' 1872 leaf."; 1873 } 1874 } 1876 grouping password-grouping { 1877 description 1878 "A password that MAY be encrypted."; 1879 choice password-type { 1880 nacm:default-deny-write; 1881 mandatory true; 1882 description 1883 "Choice between password types."; 1884 case cleartext-password { 1885 leaf cleartext-password { 1886 nacm:default-deny-all; 1887 type string; 1888 description 1889 "The cleartext value of the password."; 1890 } 1891 } 1892 case encrypted-password { 1893 if-feature "password-encryption"; 1894 container encrypted-password { 1895 description 1896 "A container for the encrypted password value."; 1897 uses encrypted-value-grouping; 1898 } 1899 } 1900 } 1901 } 1903 grouping symmetric-key-grouping { 1904 description 1905 "A symmetric key."; 1906 leaf key-format { 1907 nacm:default-deny-write; 1908 type identityref { 1909 base symmetric-key-format; 1910 } 1911 description 1912 "Identifies the symmetric key's format. Implementations 1913 SHOULD ensure that the incoming symmetric key value is 1914 encoded in the specified format. 1916 For encrypted keys, the value is the same as it would 1917 have been if the key were not encrypted."; 1918 } 1919 choice key-type { 1920 nacm:default-deny-write; 1921 mandatory true; 1922 description 1923 "Choice between key types."; 1924 case cleartext-key { 1925 leaf cleartext-key { 1926 nacm:default-deny-all; 1927 type binary; 1928 must '../key-format'; 1929 description 1930 "The binary value of the key. The interpretation of 1931 the value is defined by the 'key-format' field."; 1932 } 1933 } 1934 case hidden-key { 1935 if-feature "hidden-keys"; 1936 leaf hidden-key { 1937 type empty; 1938 must 'not(../key-format)'; 1939 description 1940 "A hidden key. How such keys are created is outside 1941 the scope of this module."; 1942 } 1943 } 1944 case encrypted-key { 1945 if-feature "symmetric-key-encryption"; 1946 container encrypted-key { 1947 must '../key-format'; 1948 description 1949 "A container for the encrypted symmetric key value. 1950 The interpretation of the 'encrypted-value' node 1951 is via the 'key-format' node"; 1952 uses encrypted-value-grouping; 1953 } 1954 } 1955 } 1956 } 1957 grouping public-key-grouping { 1958 description 1959 "A public key."; 1960 leaf public-key-format { 1961 nacm:default-deny-write; 1962 type identityref { 1963 base public-key-format; 1964 } 1965 mandatory true; 1966 description 1967 "Identifies the public key's format. Implementations SHOULD 1968 ensure that the incoming public key value is encoded in the 1969 specified format."; 1970 } 1971 leaf public-key { 1972 nacm:default-deny-write; 1973 type binary; 1974 mandatory true; 1975 description 1976 "The binary value of the public key. The interpretation 1977 of the value is defined by 'public-key-format' field."; 1978 } 1979 } 1981 grouping asymmetric-key-pair-grouping { 1982 description 1983 "A private key and its associated public key. Implementations 1984 SHOULD ensure that the two keys are a matching pair."; 1985 uses public-key-grouping; 1986 leaf private-key-format { 1987 nacm:default-deny-write; 1988 type identityref { 1989 base private-key-format; 1990 } 1991 description 1992 "Identifies the private key's format. Implementations SHOULD 1993 ensure that the incoming private key value is encoded in the 1994 specified format. 1996 For encrypted keys, the value is the same as it would have 1997 been if the key were not encrypted."; 1998 } 1999 choice private-key-type { 2000 nacm:default-deny-write; 2001 mandatory true; 2002 description 2003 "Choice between key types."; 2004 case cleartext-private-key { 2005 leaf cleartext-private-key { 2006 nacm:default-deny-all; 2007 type binary; 2008 must '../private-key-format'; 2009 description 2010 "The value of the binary key The key's value is 2011 interpreted by the 'private-key-format' field."; 2012 } 2013 } 2014 case hidden-private-key { 2015 if-feature "hidden-keys"; 2016 leaf hidden-private-key { 2017 type empty; 2018 must 'not(../private-key-format)'; 2019 description 2020 "A hidden key. How such keys are created is 2021 outside the scope of this module."; 2022 } 2023 } 2024 case encrypted-private-key { 2025 if-feature "private-key-encryption"; 2026 container encrypted-private-key { 2027 must '../private-key-format'; 2028 description 2029 "A container for the encrypted asymmetric private key 2030 value. The interpretation of the 'encrypted-value' 2031 node is via the 'private-key-format' node"; 2032 uses encrypted-value-grouping; 2033 } 2034 } 2035 } 2036 } 2038 grouping certificate-expiration-grouping { 2039 description 2040 "A notification for when a certificate is about to, or 2041 already has, expired."; 2042 notification certificate-expiration { 2043 if-feature "certificate-expiration-notification"; 2044 description 2045 "A notification indicating that the configured certificate 2046 is either about to expire or has already expired. When to 2047 send notifications is an implementation specific decision, 2048 but it is RECOMMENDED that a notification be sent once a 2049 month for 3 months, then once a week for four weeks, and 2050 then once a day thereafter until the issue is resolved."; 2051 leaf expiration-date { 2052 type yang:date-and-time; 2053 mandatory true; 2054 description 2055 "Identifies the expiration date on the certificate."; 2056 } 2057 } 2058 } 2060 grouping trust-anchor-cert-grouping { 2061 description 2062 "A trust anchor certificate, and a notification for when 2063 it is about to (or already has) expire."; 2064 leaf cert-data { 2065 nacm:default-deny-write; 2066 type trust-anchor-cert-cms; 2067 description 2068 "The binary certificate data for this certificate."; 2069 } 2070 uses certificate-expiration-grouping; 2071 } 2073 grouping end-entity-cert-grouping { 2074 description 2075 "An end entity certificate, and a notification for when 2076 it is about to (or already has) expire. Implementations 2077 SHOULD assert that, where used, the end entity certificate 2078 contains the expected public key."; 2079 leaf cert-data { 2080 nacm:default-deny-write; 2081 type end-entity-cert-cms; 2082 description 2083 "The binary certificate data for this certificate."; 2084 } 2085 uses certificate-expiration-grouping; 2086 } 2088 grouping generate-csr-grouping { 2089 description 2090 "Defines the 'generate-certificate-signing-request' action."; 2091 action generate-certificate-signing-request { 2092 if-feature "certificate-signing-request-generation"; 2093 nacm:default-deny-all; 2094 description 2095 "Generates a certificate signing request structure for 2096 the associated asymmetric key using the passed subject 2097 and attribute values. 2099 This action statement is only available when the 2100 associated 'public-key-format' node's value is 2101 'subject-public-key-info-format'."; 2102 reference 2103 "RFC 6125: 2104 Representation and Verification of Domain-Based 2105 Application Service Identity within Internet Public Key 2106 Infrastructure Using X.509 (PKIX) Certificates in the 2107 Context of Transport Layer Security (TLS)"; 2108 input { 2109 leaf csr-info { 2110 type ct:csr-info; 2111 mandatory true; 2112 description 2113 "A CertificationRequestInfo structure, as defined in 2114 RFC 2986. 2116 Enables the client to provide a fully-populated 2117 CertificationRequestInfo structure that the server 2118 only needs to sign in order to generate the complete 2119 'CertificationRequest' structure to return in the 2120 'output'. 2122 The 'AlgorithmIdentifier' field contained inside 2123 the 'SubjectPublicKeyInfo' field MUST be one known 2124 to be supported by the device."; 2125 reference 2126 "RFC 2986: 2127 PKCS #10: Certification Request Syntax Specification 2128 RFC AAAA: 2129 YANG Data Types and Groupings for Cryptography"; 2130 } 2131 } 2132 output { 2133 leaf certificate-signing-request { 2134 type ct:csr; 2135 mandatory true; 2136 description 2137 "A CertificationRequest structure, as defined in 2138 RFC 2986."; 2139 reference 2140 "RFC 2986: 2141 PKCS #10: Certification Request Syntax Specification 2142 RFC AAAA: 2143 YANG Data Types and Groupings for Cryptography"; 2144 } 2145 } 2146 } 2147 } // generate-csr-grouping 2148 grouping asymmetric-key-pair-with-cert-grouping { 2149 description 2150 "A private/public key pair and an associated certificate. 2151 Implementations SHOULD assert that certificates contain 2152 the matching public key."; 2153 uses asymmetric-key-pair-grouping; 2154 uses end-entity-cert-grouping; 2155 uses generate-csr-grouping; 2156 } // asymmetric-key-pair-with-cert-grouping 2158 grouping asymmetric-key-pair-with-certs-grouping { 2159 description 2160 "A private/public key pair and associated certificates. 2161 Implementations SHOULD assert that certificates contain 2162 the matching public key."; 2163 uses asymmetric-key-pair-grouping; 2164 container certificates { 2165 nacm:default-deny-write; 2166 description 2167 "Certificates associated with this asymmetric key."; 2168 list certificate { 2169 key "name"; 2170 description 2171 "A certificate for this asymmetric key."; 2172 leaf name { 2173 type string; 2174 description 2175 "An arbitrary name for the certificate."; 2176 } 2177 uses end-entity-cert-grouping { 2178 refine "cert-data" { 2179 mandatory true; 2180 } 2181 } 2182 } 2183 } 2184 uses generate-csr-grouping; 2185 } // asymmetric-key-pair-with-certs-grouping 2187 } 2189 2191 3. Security Considerations 2192 3.1. No Support for CRMF 2194 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 2195 signing-request" action. The use of Certificate Request Message 2196 Format (CRMF) [RFC4211] was considered, but it was unclear if there 2197 was market demand for it. If it is desired to support CRMF in the 2198 future, a backwards compatible solution can be defined at that time. 2200 3.2. No Support for Key Generation 2202 Early revisions of this document included "rpc" statements for 2203 generating symmetric and asymmetric keys. These statements were 2204 removed due to an inability to obtain consensus for how to identify 2205 the key-algorithm to use. Thusly, the solution presented in this 2206 document only supports keys to be configured via an external client, 2207 which does not support Security best practice. 2209 3.3. Unconstrained Public Key Usage 2211 This module defines the "public-key-grouping" grouping, which enables 2212 the configuration of public keys without constraints on their usage, 2213 e.g., what operations the key is allowed to be used for (encryption, 2214 verification, both). 2216 The "asymmetric-key-pair-grouping" grouping uses the aforementioned 2217 "public-key-grouping" grouping, and carries the same traits. 2219 The "asymmetric-key-pair-with-cert-grouping" grouping uses the 2220 aforementioned "asymmetric-key-pair-grouping" grouping, whereby each 2221 certificate may constrain the usage of the public key according to 2222 local policy. 2224 3.4. Unconstrained Private Key Usage 2226 This module defines the "asymmetric-key-pair-grouping" grouping, 2227 which enables the configuration of private keys without constraints 2228 on their usage, e.g., what operations the key is allowed to be used 2229 for (e.g., signature, decryption, both). 2231 The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned 2232 "asymmetric-key-pair-grouping" grouping, whereby configured 2233 certificates (e.g., identity certificates) may constrain the use of 2234 the public key according to local policy. 2236 3.5. Strength of Keys Conveyed 2238 When accessing key values, it is desireable that implementations 2239 ensure that the strength of the keys being accessed is not greater 2240 than the strength of the underlying secure transport connection over 2241 which the keys are conveyed. However, comparing key strengths can be 2242 complicated and difficult to implement in practice. 2244 That said, expert Security opinion suggests that already it is 2245 infeasible to break a 128-bit symmetric key using a classical 2246 computer, and thus the concern for conveying higher-strength keys 2247 begins to lose its allure. 2249 Implementations SHOULD only use secure transport protocols meeting 2250 local policy. A reasonable policy may, e.g., state that only 2251 ciphersuites listed as "recommended" by the IETF be used (e.g., 2252 [RFC7525] for TLS). 2254 3.6. Encrypting Passwords 2256 The module contained within this document enables passwords to be 2257 encrypted. Passwords may be encrypted via a symmetric key using the 2258 "cms-encrypted-data-format" format. This format uses the CMS 2259 EncryptedData structure, which allows any encryption algorithm to be 2260 used. 2262 In order to thwart rainbow attacks, algorithms that result in a 2263 unique output for the same input SHOULD NOT be used. For instance, 2264 AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas 2265 "CBC" mode is permissible since an unpredictable initialization 2266 vector (IV) MUST be used for each use. 2268 3.7. Deletion of Cleartext Key Values 2270 This module defines storage for cleartext key values that SHOULD be 2271 zeroized when deleted, so as to prevent the remnants of their 2272 persisted storage locations from being analyzed in any meaningful 2273 way. 2275 The cleartext key values are the "cleartext-key" node defined in the 2276 "symmetric-key-grouping" grouping (Section 2.1.4.3) and the 2277 "cleartext-private-key" node defined in the "asymmetric-key-pair- 2278 grouping" grouping ("Section 2.1.4.5). 2280 3.8. The "ietf-crypto-types" YANG Module 2282 The YANG module in this document defines "grouping" statements that 2283 are designed to be accessed via YANG based management protocols, such 2284 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2285 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2286 with mutual authentication. 2288 The NETCONF access control model (NACM) [RFC8341] provides the means 2289 to restrict access for particular users to a pre-configured subset of 2290 all available protocol operations and content. 2292 Since the module in this document only defines groupings, these 2293 considerations are primarily for the designers of other modules that 2294 use these groupings. 2296 Some of the readable data nodes defined in this YANG module may be 2297 considered sensitive or vulnerable in some network environments. It 2298 is thus important to control read access (e.g., via get, get-config, 2299 or notification) to these data nodes. These are the subtrees and 2300 data nodes and their sensitivity/vulnerability: 2302 * The "cleartext-key" node: 2304 The "cleartext-key" node defined in the "symmetric-key- 2305 grouping" grouping is additionally sensitive to read operations 2306 such that, in normal use cases, it should never be returned to 2307 a client. For this reason, the NACM extension "default-deny- 2308 all" has been applied to it. 2310 * The "cleartext-private-key" node: 2312 The "cleartext-private-key" node defined in the "asymmetric- 2313 key-pair-grouping" grouping is additionally sensitive to read 2314 operations such that, in normal use cases, it should never be 2315 returned to a client. For this reason, the NACM extension 2316 "default-deny-all" has been applied. 2318 * The "cert-data" node: 2320 The "cert-data" node, defined in both the "trust-anchor-cert- 2321 grouping" and "end-entity-cert-grouping" groupings, is 2322 additionally sensitive to read operations, as certificates 2323 sometimes convey personally identifying information (especially 2324 end-entity certificates). However, as it is commonly 2325 understood that certificates are "public", the NACM extension 2326 "nacm:default-deny-write" (not "default-deny-all") has been 2327 applied. It is RECOMMENDED that implementations adjust read- 2328 access to certificates to comply with local policy. 2330 All the writable data nodes defined by all the groupings defined in 2331 this module may be considered sensitive or vulnerable in some network 2332 environments. For instance, even the modification of a public key or 2333 a certificate can dramatically alter the implemented security policy. 2334 For this reason, the NACM extension "default-deny-write" has been 2335 applied to all the data nodes defined in the module. 2337 Some of the operations in this YANG module may be considered 2338 sensitive or vulnerable in some network environments. It is thus 2339 important to control access to these operations. These are the 2340 operations and their sensitivity/vulnerability: 2342 * generate-certificate-signing-request: 2344 This "action" statement SHOULD only be executed by authorized 2345 users. For this reason, the NACM extension "default-deny-all" 2346 has been applied. Note that NACM uses "default-deny-all" to 2347 protect "RPC" and "action" statements; it does not define, 2348 e.g., an extension called "default-deny-execute". 2350 For this action, it is RECOMMENDED that implementations assert 2351 channel binding [RFC5056], so as to ensure that the application 2352 layer that sent the request is the same as the device 2353 authenticated when the secure transport layer was established. 2355 4. IANA Considerations 2357 4.1. The "IETF XML" Registry 2359 This document registers one URI in the "ns" subregistry of the "IETF 2360 XML" registry [RFC3688]. Following the format in [RFC3688], the 2361 following registration is requested: 2363 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2364 Registrant Contact: The IESG 2365 XML: N/A, the requested URI is an XML namespace. 2367 4.2. The "YANG Module Names" Registry 2369 This document registers one YANG module in the "YANG Module Names" 2370 registry [RFC6020]. Following the format in [RFC6020], the following 2371 registration is requested: 2373 name: ietf-crypto-types 2374 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2375 prefix: ct 2376 reference: RFC AAAA 2378 5. References 2380 5.1. Normative References 2382 [ITU.X680.2015] 2383 International Telecommunication Union, "Information 2384 technology - Abstract Syntax Notation One (ASN.1): 2385 Specification of basic notation", ITU-T Recommendation 2386 X.680, ISO/IEC 8824-1:2015, August 2015, 2387 . 2389 [ITU.X690.2015] 2390 International Telecommunication Union, "Information 2391 Technology - ASN.1 encoding rules: Specification of Basic 2392 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2393 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2394 X.690, ISO/IEC 8825-1:2015, August 2015, 2395 . 2397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2398 Requirement Levels", BCP 14, RFC 2119, 2399 DOI 10.17487/RFC2119, March 1997, 2400 . 2402 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2403 Standards (PKCS) #1: RSA Cryptography Specifications 2404 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2405 2003, . 2407 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2408 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2409 January 2006, . 2411 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2412 Housley, R., and W. Polk, "Internet X.509 Public Key 2413 Infrastructure Certificate and Certificate Revocation List 2414 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2415 . 2417 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2418 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2419 . 2421 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 2422 DOI 10.17487/RFC5958, August 2010, 2423 . 2425 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2426 (CMS) Symmetric Key Package Content Type", RFC 6031, 2427 DOI 10.17487/RFC6031, December 2010, 2428 . 2430 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2431 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2432 . 2434 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 2435 for Generating Key Identifiers Values", RFC 7093, 2436 DOI 10.17487/RFC7093, December 2013, 2437 . 2439 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2440 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2441 . 2443 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2444 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2445 May 2017, . 2447 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2448 Access Control Model", STD 91, RFC 8341, 2449 DOI 10.17487/RFC8341, March 2018, 2450 . 2452 5.2. Informative References 2454 [I-D.ietf-netconf-crypto-types] 2455 Watsen, K., "YANG Data Types and Groupings for 2456 Cryptography", Work in Progress, Internet-Draft, draft- 2457 ietf-netconf-crypto-types-21, 14 September 2021, 2458 . 2461 [I-D.ietf-netconf-http-client-server] 2462 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 2463 Servers", Work in Progress, Internet-Draft, draft-ietf- 2464 netconf-http-client-server-08, 14 December 2021, 2465 . 2468 [I-D.ietf-netconf-keystore] 2469 Watsen, K., "A YANG Data Model for a Keystore", Work in 2470 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 2471 14 December 2021, . 2474 [I-D.ietf-netconf-netconf-client-server] 2475 Watsen, K., "NETCONF Client and Server Models", Work in 2476 Progress, Internet-Draft, draft-ietf-netconf-netconf- 2477 client-server-24, 14 December 2021, 2478 . 2481 [I-D.ietf-netconf-restconf-client-server] 2482 Watsen, K., "RESTCONF Client and Server Models", Work in 2483 Progress, Internet-Draft, draft-ietf-netconf-restconf- 2484 client-server-24, 14 December 2021, 2485 . 2488 [I-D.ietf-netconf-ssh-client-server] 2489 Watsen, K., "YANG Groupings for SSH Clients and SSH 2490 Servers", Work in Progress, Internet-Draft, draft-ietf- 2491 netconf-ssh-client-server-26, 14 December 2021, 2492 . 2495 [I-D.ietf-netconf-tcp-client-server] 2496 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 2497 and TCP Servers", Work in Progress, Internet-Draft, draft- 2498 ietf-netconf-tcp-client-server-11, 14 December 2021, 2499 . 2502 [I-D.ietf-netconf-tls-client-server] 2503 Watsen, K., "YANG Groupings for TLS Clients and TLS 2504 Servers", Work in Progress, Internet-Draft, draft-ietf- 2505 netconf-tls-client-server-26, 14 December 2021, 2506 . 2509 [I-D.ietf-netconf-trust-anchors] 2510 Watsen, K., "A YANG Data Model for a Truststore", Work in 2511 Progress, Internet-Draft, draft-ietf-netconf-trust- 2512 anchors-16, 14 December 2021, 2513 . 2516 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2517 Request Syntax Specification Version 1.7", RFC 2986, 2518 DOI 10.17487/RFC2986, November 2000, 2519 . 2521 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2522 DOI 10.17487/RFC3688, January 2004, 2523 . 2525 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2526 Certificate Request Message Format (CRMF)", RFC 4211, 2527 DOI 10.17487/RFC4211, September 2005, 2528 . 2530 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2531 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2532 . 2534 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2535 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2536 . 2538 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2539 the Network Configuration Protocol (NETCONF)", RFC 6020, 2540 DOI 10.17487/RFC6020, October 2010, 2541 . 2543 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2544 Verification of Domain-Based Application Service Identity 2545 within Internet Public Key Infrastructure Using X.509 2546 (PKIX) Certificates in the Context of Transport Layer 2547 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2548 2011, . 2550 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2551 and A. Bierman, Ed., "Network Configuration Protocol 2552 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2553 . 2555 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2556 "Recommendations for Secure Use of Transport Layer 2557 Security (TLS) and Datagram Transport Layer Security 2558 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2559 2015, . 2561 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2562 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2563 . 2565 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2566 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2567 . 2569 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2570 and R. Wilton, "Network Management Datastore Architecture 2571 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2572 . 2574 Appendix A. Change Log 2576 This section is to be removed before publishing as an RFC. 2578 A.1. I-D to 00 2580 * Removed groupings and notifications. 2582 * Added typedefs for identityrefs. 2584 * Added typedefs for other RFC 5280 structures. 2586 * Added typedefs for other RFC 5652 structures. 2588 * Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2590 A.2. 00 to 01 2592 * Moved groupings from the draft-ietf-netconf-keystore here. 2594 A.3. 01 to 02 2596 * Removed unwanted "mandatory" and "must" statements. 2598 * Added many new crypto algorithms (thanks Haiguang!) 2600 * Clarified in asymmetric-key-pair-with-certs-grouping, in 2601 certificates/certificate/name/description, that if the name MUST 2602 NOT match the name of a certificate that exists independently in 2603 , enabling certs installed by the manufacturer (e.g., 2604 an IDevID). 2606 A.4. 02 to 03 2608 * renamed base identity 'asymmetric-key-encryption-algorithm' to 2609 'asymmetric-key-algorithm'. 2611 * added new 'asymmetric-key-algorithm' identities for secp192r1, 2612 secp224r1, secp256r1, secp384r1, and secp521r1. 2614 * removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2615 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2616 aes-256-gcm, and mac-chacha20-poly1305. 2618 * for all -cbc and -ctr identities, renamed base identity 2619 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2621 * for all -ccm and -gcm identities, renamed base identity 2622 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2623 algorithm' and renamed the identity to remove the "enc-" prefix. 2625 * for all the 'signature-algorithm' based identities, renamed from 2626 'rsa-*' to 'rsassa-*'. 2628 * removed all of the "x509v3-" prefixed 'signature-algorithm' based 2629 identities. 2631 * added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2632 and 'rsaes-pkcs1-v1_5'. 2634 * renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2635 'symmetric-key-algorithm-ref'. 2637 * renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2638 'asymmetric-key-algorithm-ref'. 2640 * added typedef 'encryption-and-mac-algorithm-ref'. 2642 * Updated copyright date, boilerplate template, affiliation, and 2643 folding algorithm. 2645 A.5. 03 to 04 2647 * ran YANG module through formatter. 2649 A.6. 04 to 05 2651 * fixed broken symlink causing reformatted YANG module to not show. 2653 A.7. 05 to 06 2655 * Added NACM annotations. 2657 * Updated Security Considerations section. 2659 * Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2661 * Removed text from 'permanently-hidden' enum regarding such keys 2662 not being backed up or restored. 2664 * Updated the boilerplate text in module-level "description" 2665 statement to match copyeditor convention. 2667 * Added an explanation to the 'public-key-grouping' and 'asymmetric- 2668 key-pair-grouping' statements as for why the nodes are not 2669 mandatory (e.g., because they may exist only in . 2671 * Added 'must' expressions to the 'public-key-grouping' and 2672 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2673 are either all exist or do not all exist. 2675 * Added an explanation to the 'permanently-hidden' that the value 2676 cannot be configured directly by clients and servers MUST fail any 2677 attempt to do so. 2679 * Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2680 grouping' (the plural form of existing groupings). 2682 * Now states that keys created in by the *-hidden-key 2683 actions are bound to the lifetime of the parent 'config true' 2684 node, and that subsequent invocations of either action results in 2685 a failure. 2687 A.8. 06 to 07 2689 * Added clarifications that implementations SHOULD assert that 2690 configured certificates contain the matching public key. 2692 * Replaced the 'generate-hidden-key' and 'install-hidden-key' 2693 actions with special 'crypt-hash' -like input/output values. 2695 A.9. 07 to 08 2697 * Removed the 'generate-key and 'hidden-key' features. 2699 * Added grouping symmetric-key-grouping 2701 * Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2702 statement for the keystone module to augment into, as well as 2703 replacing the 'union' with leafs (having different NACM settings. 2705 A.10. 08 to 09 2707 * Converting algorithm from identities to enumerations. 2709 A.11. 09 to 10 2711 * All the below changes are to the algorithm enumerations defined in 2712 ietf-crypto-types. 2714 * Add in support for key exchange over x.25519 and x.448 based on 2715 RFC 8418. 2717 * Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2719 * Revise/add in enum of signature algorithm for x25519 and x448 2721 * Add in des3-cbc-sha1 for IPSec 2723 * Add in sha1-des3-kd for IPSec 2725 * Add in definit for rc4-hmac and rc4-hmac-exp. These two 2726 algorithms have been deprecated in RFC 8429. But some existing 2727 draft in i2nsf may still want to use them. 2729 * Add x25519 and x448 curve for asymmetric algorithms 2731 * Add signature algorithms ed25519, ed25519-cts, ed25519ph 2733 * add signature algorithms ed448, ed448ph 2735 * Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2737 A.12. 10 to 11 2739 * Added a "key-format" identity. 2741 * Added symmetric keys to the example in Section 2.2. 2743 A.13. 11 to 12 2745 * Removed all non-essential (to NC/RC) algorithm types. 2747 * Moved remaining algorithm types each into its own module. 2749 * Added a 'config false' "algorithms-supported" list to each of the 2750 algorithm-type modules. 2752 A.14. 12 to 13 2754 * Added the four features: "[encrypted-]one-[a]symmetric-key- 2755 format", each protecting a 'key-format' identity of the same name. 2757 * Added 'must' expressions asserting that the 'key-format' leaf 2758 exists whenever a non-hidden key is specified. 2760 * Improved the 'description' statements and added 'reference' 2761 statements for the 'key-format' identities. 2763 * Added a questionable forward reference to "encrypted-*" leafs in a 2764 couple 'when' expressions. 2766 * Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 2768 A.15. 13 to 14 2770 * Resolved the "FIXME: forward ref" issue by modulating 'must', 2771 'when', and 'mandatory' expressions. 2773 * Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' 2774 actions from ietf-keystore to ietf-crypto-types, now as RPCs. 2776 * Cleaned up various description statements and removed lingering 2777 FIXMEs. 2779 * Converted the "iana--algs" YANG modules to IANA 2780 registries with instructions for how to generate modules from the 2781 registries, whenever they may be updated. 2783 A.16. 14 to 15 2784 * Removed the IANA-maintained registries for symmetric, asymmetric, 2785 and hash algorithms. 2787 * Removed the "generate-symmetric-key" and "generate-asymmetric-key" 2788 RPCs. 2790 * Removed the "algorithm" node in the various symmetric and 2791 asymmetric key groupings. 2793 * Added 'typedef csr' and 'feature certificate-signing-request- 2794 generation'. 2796 * Refined a usage of "end-entity-cert-grouping" to make the "cert" 2797 node mandatory true. 2799 * Added a "Note to Reviewers" note to first page. 2801 A.17. 15 to 16 2803 * Updated draft title (refer to "Groupings" too). 2805 * Removed 'end-entity-certs-grouping' as it wasn't being used 2806 anywhere. 2808 * Removed 'trust-anchor-certs-grouping' as it was no longer being 2809 used after modifying 'local-or-truststore-certs-grouping' to use 2810 lists (not leaf-lists). 2812 * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. 2814 * Added "csr-info" typedef, to complement the existing "csr" 2815 typedef. 2817 * Added "ocsp-request" and "ocsp-response" typedefs, to complement 2818 the existing "crl" typedef. 2820 * Added "encrypted" cases to both symmetric-key-grouping and 2821 asymmetric-key-pair-grouping (Moved from Keystore draft). 2823 * Expanded "Data Model Overview section(s) [remove "wall" of tree 2824 diagrams]. 2826 * Updated the Security Considerations section. 2828 A.18. 16 to 17 2830 * [Re]-added a "Strength of Keys Configured" Security Consideration 2831 * Prefixed "cleartext-" in the "key" and "private-key" node names. 2833 A.19. 17 to 18 2835 * Fixed issues found by the SecDir review of the "keystore" draft. 2837 * Added "password-grouping", discussed during the IETF 108 session. 2839 A.20. 18 to 19 2841 * Added a "Unconstrained Public Key Usage" Security Consideration to 2842 address concern raised by SecDir of the 'truststore' draft. 2844 * Added a "Unconstrained Private Key Usage" Security Consideration 2845 to address concern raised by SecDir of the 'truststore' draft. 2847 * Changed the encryption strategy, after conferring with Russ 2848 Housley. 2850 * Added a "password-grouping" example to the "crypto-types-usage" 2851 example. 2853 * Added an "Encrypting Passwords" section to Security Consideration. 2855 * Addressed other comments raised by YANG Doctor. 2857 A.21. 19 to 20 2859 * Nits found via YANG Doctors reviews. 2861 * Aligned modules with `pyang -f` formatting. 2863 A.22. 20 to 21 2865 * Replaced "base64encodedvalue==" with "BASE64VALUE=". 2867 * Accommodated SecDir review by Valery Smyslov. 2869 A.23. 21 to 22 2871 * fixup the 'WG Web' and 'WG List' lines in YANG module(s) 2873 * fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s) 2875 * added 'hidden-keys' feature. 2877 Acknowledgements 2879 The authors would like to thank for following for lively discussions 2880 on list and in the halls (ordered by first name): Balazs Kovacs, Eric 2881 Voit, Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick 2882 Hancock, Rich Salz, Rob Wilton, Russ Housley, Sandra Murphy, Tom 2883 Petch, Valery Smyslov, and Wang Haiguang. 2885 Author's Address 2887 Kent Watsen 2888 Watsen Networks 2889 Email: kent+ietf@watsen.net