idnits 2.17.1 draft-ietf-netconf-crypto-types-21.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 359 has weird spacing: '...-format ide...' == Line 409 has weird spacing: '...-format ide...' == Line 456 has weird spacing: '...-format ide...' == Line 486 has weird spacing: '...-format ide...' == Line 534 has weird spacing: '...-format ide...' == (20 more instances...) -- The document date (14 September 2021) is 953 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-20 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-07 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-22 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-23 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-23 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-25 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-10 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-25 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-15 -- 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 14 September 2021 5 Expires: 18 March 2022 7 YANG Data Types and Groupings for Cryptography 8 draft-ietf-netconf-crypto-types-21 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 * "2021-09-14" --> 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 18 March 2022. 54 Copyright Notice 56 Copyright (c) 2021 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 Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . 48 85 3.6. Encrypting Passwords . . . . . . . . . . . . . . . . . . 49 86 3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 49 87 3.8. The "ietf-crypto-types" YANG Module . . . . . . . . . . . 49 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 89 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 51 90 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 51 91 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 92 5.1. Normative References . . . . . . . . . . . . . . . . . . 51 93 5.2. Informative References . . . . . . . . . . . . . . . . . 53 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55 95 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 55 96 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 56 97 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 56 98 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 56 99 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 57 100 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 57 101 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 57 102 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 58 103 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 58 104 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 58 105 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 58 106 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 59 107 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 59 108 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 59 109 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 59 110 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 60 111 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 60 112 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 61 113 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 61 114 A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 61 115 A.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 61 116 A.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 61 117 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 120 1. Introduction 122 This document presents a YANG 1.1 [RFC7950] module defining 123 identities, typedefs, and groupings useful to cryptographic 124 applications. 126 1.1. Relation to other RFCs 128 This document presents one or more YANG modules [RFC7950] that are 129 part of a collection of RFCs that work together to, ultimately, 130 enable the configuration of the clients and servers of both the 131 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 133 The modules have been defined in a modular fashion to enable their 134 use by other efforts, some of which are known to be in progress at 135 the time of this writing, with many more expected to be defined in 136 time. 138 The normative dependency relationship between the various RFCs in the 139 collection is presented in the below diagram. The labels in the 140 diagram represent the primary purpose provided by each RFC. 141 Hyperlinks to each RFC are provided below the diagram. 143 crypto-types 144 ^ ^ 145 / \ 146 / \ 147 truststore keystore 148 ^ ^ ^ ^ 149 | +---------+ | | 150 | | | | 151 | +------------+ | 152 tcp-client-server | / | | 153 ^ ^ ssh-client-server | | 154 | | ^ tls-client-server 155 | | | ^ ^ http-client-server 156 | | | | | ^ 157 | | | +-----+ +---------+ | 158 | | | | | | 159 | +-----------|--------|--------------+ | | 160 | | | | | | 161 +-----------+ | | | | | 162 | | | | | | 163 | | | | | | 164 netconf-client-server restconf-client-server 166 +=======================+===========================================+ 167 |Label in Diagram | Originating RFC | 168 +=======================+===========================================+ 169 |crypto-types | [I-D.ietf-netconf-crypto-types] | 170 +-----------------------+-------------------------------------------+ 171 |truststore | [I-D.ietf-netconf-trust-anchors] | 172 +-----------------------+-------------------------------------------+ 173 |keystore | [I-D.ietf-netconf-keystore] | 174 +-----------------------+-------------------------------------------+ 175 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 176 +-----------------------+-------------------------------------------+ 177 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 178 +-----------------------+-------------------------------------------+ 179 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 180 +-----------------------+-------------------------------------------+ 181 |http-client-server | [I-D.ietf-netconf-http-client-server] | 182 +-----------------------+-------------------------------------------+ 183 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 184 +-----------------------+-------------------------------------------+ 185 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 186 +-----------------------+-------------------------------------------+ 188 Table 1: Label to RFC Mapping 190 1.2. Specification Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 1.3. Adherence to the NMDA 200 This document is compliant with the Network Management Datastore 201 Architecture (NMDA) [RFC8342]. It does not define any protocol 202 accessible nodes that are "config false". 204 1.4. Conventions 206 Various examples used in this document use a placeholder value for 207 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 208 This placeholder value is used as real base64 encoded structures are 209 often many lines long and hence distracting to the example being 210 presented. 212 2. The "ietf-crypto-types" Module 214 This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- 215 types". A high-level overview of the module is provided in 216 Section 2.1. Examples illustrating the module's use are provided in 217 Examples (Section 2.2). The YANG module itself is defined in 218 Section 2.3. 220 2.1. Data Model Overview 222 This section provides an overview of the "ietf-crypto-types" module 223 in terms of its features, identities, typedefs, and groupings. 225 2.1.1. Features 227 The following diagram lists all the "feature" statements defined in 228 the "ietf-crypto-types" module: 230 Features: 231 +-- one-symmetric-key-format 232 +-- one-asymmetric-key-format 233 +-- certificate-signing-request-generation 234 +-- certificate-expiration-notification 235 +-- symmetrically-encrypted-value-format 236 +-- asymmetrically-encrypted-value-format 237 +-- cms-encrypted-data-format 238 +-- cms-enveloped-data-format 240 | The diagram above uses syntax that is similar to but not 241 | defined in [RFC8340]. 243 2.1.2. Identities 245 The following diagram illustrates the relationship amongst the 246 "identity" statements defined in the "ietf-crypto-types" module: 248 Identities: 249 +-- public-key-format 250 | +-- subject-public-key-info-format 251 | +-- ssh-public-key-format 252 +-- private-key-format 253 | +-- rsa-private-key-format 254 | +-- ec-private-key-format 255 | +-- one-asymmetric-key-format 256 | {one-asymmetric-key-format}? 257 +-- symmetric-key-format 258 | +-- octet-string-key-format 259 | +-- one-symmetric-key-format 260 | {one-symmetric-key-format}? 261 +-- encrypted-value-format 262 +-- symmetrically-encrypted-value-format 263 | | {symmetrically-encrypted-value-format}? 264 | +-- cms-encrypted-data-format 265 | {cms-encrypted-data-format}? 266 +-- asymmetrically-encrypted-value-format 267 | {asymmetrically-encrypted-value-format}? 268 +-- cms-enveloped-data-format 269 {cms-enveloped-data-format}? 271 | The diagram above uses syntax that is similar to but not 272 | defined in [RFC8340]. 274 Comments: 276 * The diagram shows that there are four base identities. The first 277 three identities are used to indicate the format that key data, 278 while the fourth identity is used to indicate the format for 279 encrypted values. The base identities are "abstract", in the 280 object oriented programming sense, in that they only define a 281 "class" of formats, rather than a specific format. 283 * The various "leaf" identities define specific encoding formats. 284 The derived identities defined in this document are sufficient for 285 the effort described in Section 1.1 but, by nature of them being 286 identities, additional derived identities MAY be defined by future 287 efforts. 289 * Identities used to specify uncommon formats are enabled by 290 "feature" statements, allowing applications to support them when 291 needed. 293 2.1.3. Typedefs 295 The following diagram illustrates the relationship amongst the 296 "typedef" statements defined in the "ietf-crypto-types" module: 298 Typedefs: 299 binary 300 +-- csr-info 301 +-- csr 302 +-- x509 303 | +-- trust-anchor-cert-x509 304 | +-- end-entity-cert-x509 305 +-- crl 306 +-- ocsp-request 307 +-- ocsp-response 308 +-- cms 309 +-- data-content-cms 310 +-- signed-data-cms 311 | +-- trust-anchor-cert-cms 312 | +-- end-entity-cert-cms 313 +-- enveloped-data-cms 314 +-- digested-data-cms 315 +-- encrypted-data-cms 316 +-- authenticated-data-cms 318 | The diagram above uses syntax that is similar to but not 319 | defined in [RFC8340]. 321 Comments: 323 * All the typedefs defined in the "ietf-crypto-types" module extend 324 the "binary" type defined in [RFC7950]. 326 * Additionally, all the typedefs define a type for encoding an ASN.1 327 [ITU.X680.2015] structure using DER [ITU.X690.2015]. 329 * The "trust-anchor-*" and "end-entity-*" typedefs are syntactically 330 identical to their base typedefs and only distinguish themselves 331 by the expected nature of their content. These typedefs are 332 defined to facilitate common modeling needs. 334 2.1.4. Groupings 336 The "ietf-crypto-types" module defines the following "grouping" 337 statements: 339 * encrypted-value-grouping 340 * password-grouping 341 * symmetric-key-grouping 342 * public-key-grouping 343 * asymmetric-key-pair-grouping 344 * trust-anchor-cert-grouping 345 * end-entity-cert-grouping 346 * generate-csr-grouping 347 * asymmetric-key-pair-with-cert-grouping 348 * asymmetric-key-pair-with-certs-grouping 350 Each of these groupings are presented in the following subsections. 352 2.1.4.1. The "encrypted-value-grouping" Grouping 354 The following tree diagram [RFC8340] illustrates the "encrypted- 355 value-grouping" grouping: 357 grouping encrypted-value-grouping 358 +-- encrypted-by 359 +-- encrypted-value-format identityref 360 +-- encrypted-value binary 362 Comments: 364 * The "encrypted-by" node is an empty container (difficult to see in 365 the diagram) that a consuming module MUST augment key references 366 into. The "ietf-crypto-types" module is unable to populate this 367 container as the module only defines groupings. Section 2.2.1 368 presents an example illustrating a consuming module populating the 369 "encrypted-by" container. 371 * The "encrypted-value" node is the value, encrypted by the key 372 referenced by the "encrypted-by" node, and encoded in the format 373 appropriate for the kind of key it was encrypted by. 375 - If the value is encrypted by a symmetric key, then the 376 encrypted value is encoded using the format associated with the 377 "symmetrically-encrypted-value-format" identity. 379 - If the value is encrypted by an asymmetric key, then the 380 encrypted value is encoded using the format associated with the 381 "asymmetrically-encrypted-value-format" identity. 383 See Section 2.1.2 for information about the "format" identities. 385 2.1.4.2. The "password-grouping" Grouping 387 This section presents two tree diagrams [RFC8340] illustrating the 388 "password-grouping" grouping. The first tree diagram does not expand 389 the internally used grouping statement(s): 391 grouping password-grouping 392 +-- (password-type) 393 +--:(cleartext-password) 394 | +-- cleartext-password? string 395 +--:(encrypted-password) {password-encryption}? 396 +-- encrypted-password 397 +---u encrypted-value-grouping 399 The following tree diagram expands the internally used grouping 400 statement(s), enabling the grouping's full structure to be seen: 402 grouping password-grouping 403 +-- (password-type) 404 +--:(cleartext-password) 405 | +-- cleartext-password? string 406 +--:(encrypted-password) {password-encryption}? 407 +-- encrypted-password 408 +-- encrypted-by 409 +-- encrypted-value-format identityref 410 +-- encrypted-value binary 412 Comments: 414 * For the referenced grouping statement(s): 416 - The "encrypted-value-grouping" grouping is discussed in 417 Section 2.1.4.1. 419 * The "choice" statement enables the password data to be cleartext 420 or encrypted, as follows: 422 - The "cleartext-password" node can encode any cleartext value. 423 - The "encrypted-password" node's structure is discussed in 424 Section 2.1.4.1. 426 2.1.4.3. The "symmetric-key-grouping" Grouping 428 This section presents two tree diagrams [RFC8340] illustrating the 429 "symmetric-key-grouping" grouping. The first tree diagram does not 430 expand the internally used grouping statement(s): 432 grouping symmetric-key-grouping 433 +-- key-format? identityref 434 +-- (key-type) 435 +--:(cleartext-key) 436 | +-- cleartext-key? binary 437 +--:(hidden-key) 438 | +-- hidden-key? empty 439 +--:(encrypted-key) {symmetric-key-encryption}? 440 +-- encrypted-key 441 +---u encrypted-value-grouping 443 The following tree diagram expands the internally used grouping 444 statement(s), enabling the grouping's full structure to be seen: 446 grouping symmetric-key-grouping 447 +-- key-format? identityref 448 +-- (key-type) 449 +--:(cleartext-key) 450 | +-- cleartext-key? binary 451 +--:(hidden-key) 452 | +-- hidden-key? empty 453 +--:(encrypted-key) {symmetric-key-encryption}? 454 +-- encrypted-key 455 +-- encrypted-by 456 +-- encrypted-value-format identityref 457 +-- encrypted-value binary 459 Comments: 461 * For the referenced grouping statement(s): 463 - The "encrypted-value-grouping" grouping is discussed in 464 Section 2.1.4.1. 466 * The "key-format" node is an identity-reference to the "symmetric- 467 key-format" abstract base identity discussed in Section 2.1.2, 468 enabling the symmetric key to be encoded using the format defined 469 by any of the derived identities. 471 * The "choice" statement enables the private key data to be 472 cleartext, encrypted, or hidden, as follows: 474 - The "cleartext-key" node can encode any cleartext key value. 475 - The "hidden-key" node is of type "empty" as the real value 476 cannot be presented via the management interface. 477 - The "encrypted-key" node's structure is discussed in 478 Section 2.1.4.1. 480 2.1.4.4. The "public-key-grouping" Grouping 482 The following tree diagram [RFC8340] illustrates the "public-key- 483 grouping" grouping: 485 grouping public-key-grouping 486 +-- public-key-format identityref 487 +-- public-key binary 489 Comments: 491 * The "public-key-format" node is an identity-reference to the 492 "public-key-format" abstract base identity discussed in 493 Section 2.1.2, enabling the public key to be encoded using the 494 format defined by any of the derived identities. 496 * The "public-key" node is the public key data in the selected 497 format. No "choice" statement is used to hide or encrypt the 498 public key data because it is unnecessary to do so for public 499 keys. 501 2.1.4.5. The "asymmetric-key-pair-grouping" Grouping 503 This section presents two tree diagrams [RFC8340] illustrating the 504 "asymmetric-key-pair-grouping" grouping. The first tree diagram does 505 not expand the internally used grouping statement(s): 507 grouping asymmetric-key-pair-grouping 508 +---u public-key-grouping 509 +-- private-key-format? identityref 510 +-- (private-key-type) 511 +--:(cleartext-private-key) 512 | +-- cleartext-private-key? binary 513 +--:(hidden-private-key) 514 | +-- hidden-private-key? empty 515 +--:(encrypted-private-key) {private-key-encryption}? 516 +-- encrypted-private-key 517 +---u encrypted-value-grouping 519 The following tree diagram expands the internally used grouping 520 statement(s), enabling the grouping's full structure to be seen: 522 grouping asymmetric-key-pair-grouping 523 +-- public-key-format identityref 524 +-- public-key binary 525 +-- private-key-format? identityref 526 +-- (private-key-type) 527 +--:(cleartext-private-key) 528 | +-- cleartext-private-key? binary 529 +--:(hidden-private-key) 530 | +-- hidden-private-key? empty 531 +--:(encrypted-private-key) {private-key-encryption}? 532 +-- encrypted-private-key 533 +-- encrypted-by 534 +-- encrypted-value-format identityref 535 +-- encrypted-value binary 537 Comments: 539 * For the referenced grouping statement(s): 541 - The "public-key-grouping" grouping is discussed in 542 Section 2.1.4.4. 543 - The "encrypted-value-grouping" grouping is discussed in 544 Section 2.1.4.1. 546 * The "private-key-format" node is an identity-reference to the 547 "private-key-format" abstract base identity discussed in 548 Section 2.1.2, enabling the private key to be encoded using the 549 format defined by any of the derived identities. 551 * The "choice" statement enables the private key data to be 552 cleartext, encrypted, or hidden, as follows: 554 - The "cleartext-private-key" node can encode any cleartext key 555 value. 556 - The "hidden-private-key" node is of type "empty" as the real 557 value cannot be presented via the management interface. 558 - The "encrypted-private-key" node's structure is discussed in 559 Section 2.1.4.1. 561 2.1.4.6. The "certificate-expiration-grouping" Grouping 563 The following tree diagram [RFC8340] illustrates the "certificate- 564 expiration-grouping" grouping: 566 grouping certificate-expiration-grouping 567 +---n certificate-expiration 568 {certificate-expiration-notification}? 569 +-- expiration-date yang:date-and-time 571 Comments: 573 * This grouping's only purpose is to define the "certificate- 574 expiration" notification statement, used by the groupings defined 575 in Section 2.1.4.7 and Section 2.1.4.8. 577 * The "certificate-expiration" notification enables servers to 578 notify clients when certificates are nearing expiration. 580 * The "expiration-date" node indicates when the designated 581 certificate will (or did) expire. 583 * Identification of the certificate that is expiring is built into 584 the notification itself. For an example, please see 585 Section 2.2.3. 587 2.1.4.7. The "trust-anchor-cert-grouping" Grouping 589 This section presents two tree diagrams [RFC8340] illustrating the 590 "trust-anchor-cert-grouping" grouping. The first tree diagram does 591 not expand the internally used grouping statement(s): 593 grouping trust-anchor-cert-grouping 594 +-- cert-data? trust-anchor-cert-cms 595 +---u certificate-expiration-grouping 597 The following tree diagram expands the internally used grouping 598 statement(s), enabling the grouping's full structure to be seen: 600 grouping trust-anchor-cert-grouping 601 +-- cert-data? trust-anchor-cert-cms 602 +---n certificate-expiration 603 {certificate-expiration-notification}? 604 +-- expiration-date yang:date-and-time 606 Comments: 608 * For the referenced grouping statement(s): 610 - The "certificate-expiration-grouping" grouping is discussed in 611 Section 2.1.4.6. 613 * The "cert-data" node contains a chain of one or more certificates 614 encoded using a "signed-data-cms" typedef discussed in 615 Section 2.1.3. 617 2.1.4.8. The "end-entity-cert-grouping" Grouping 619 This section presents two tree diagrams [RFC8340] illustrating the 620 "end-entity-cert-grouping" grouping. The first tree diagram does not 621 expand the internally used grouping statement(s): 623 grouping end-entity-cert-grouping 624 +-- cert-data? end-entity-cert-cms 625 +---u certificate-expiration-grouping 627 The following tree diagram expands the internally used grouping 628 statement(s), enabling the grouping's full structure to be seen: 630 grouping end-entity-cert-grouping 631 +-- cert-data? end-entity-cert-cms 632 +---n certificate-expiration 633 {certificate-expiration-notification}? 634 +-- expiration-date yang:date-and-time 636 Comments: 638 * For the referenced grouping statement(s): 640 - The "certificate-expiration-grouping" grouping is discussed in 641 Section 2.1.4.6. 643 * The "cert-data" node contains a chain of one or more certificates 644 encoded using a "signed-data-cms" typedef discussed in 645 Section 2.1.3. 647 2.1.4.9. The "generate-csr-grouping" Grouping 649 The following tree diagram [RFC8340] illustrates the "generate-csr- 650 grouping" grouping: 652 grouping generate-csr-grouping 653 +---x generate-certificate-signing-request 654 {certificate-signing-request-generation}? 655 +---w input 656 | +---w csr-info ct:csr-info 657 +--ro output 658 +--ro certificate-signing-request ct:csr 660 Comments: 662 * This grouping's only purpose is to define the "generate- 663 certificate-signing-request" action statement, used by the 664 groupings defined in Section 2.1.4.10 and Section 2.1.4.11. 666 * This action takes as input a "csr-info" type and returns a "csr" 667 type, both of which are discussed in Section 2.1.3. 669 * For an example, please see Section 2.2.2. 671 2.1.4.10. The "asymmetric-key-pair-with-cert-grouping" Grouping 673 This section presents two tree diagrams [RFC8340] illustrating the 674 "asymmetric-key-pair-with-cert-grouping" grouping. The first tree 675 diagram does not expand the internally used grouping statement(s): 677 grouping asymmetric-key-pair-with-cert-grouping 678 +---u asymmetric-key-pair-grouping 679 +---u end-entity-cert-grouping 680 +---u generate-csr-grouping 682 The following tree diagram expands the internally used grouping 683 statement(s), enabling the grouping's full structure to be seen: 685 grouping asymmetric-key-pair-with-cert-grouping 686 +-- public-key-format identityref 687 +-- public-key binary 688 +-- private-key-format? identityref 689 +-- (private-key-type) 690 | +--:(cleartext-private-key) 691 | | +-- cleartext-private-key? binary 692 | +--:(hidden-private-key) 693 | | +-- hidden-private-key? empty 694 | +--:(encrypted-private-key) {private-key-encryption}? 695 | +-- encrypted-private-key 696 | +-- encrypted-by 697 | +-- encrypted-value-format identityref 698 | +-- encrypted-value binary 699 +-- cert-data? end-entity-cert-cms 700 +---n certificate-expiration 701 | {certificate-expiration-notification}? 702 | +-- expiration-date yang:date-and-time 703 +---x generate-certificate-signing-request 704 {certificate-signing-request-generation}? 705 +---w input 706 | +---w csr-info ct:csr-info 707 +--ro output 708 +--ro certificate-signing-request ct:csr 710 Comments: 712 * This grouping defines an asymmetric key with at most one 713 associated certificate, a commonly needed combination in protocol 714 models. 716 * For the referenced grouping statement(s): 718 - The "asymmetric-key-pair-grouping" grouping is discussed in 719 Section 2.1.4.5. 720 - The "end-entity-cert-grouping" grouping is discussed in 721 Section 2.1.4.8. 722 - The "generate-csr-grouping" grouping is discussed in 723 Section 2.1.4.9. 725 2.1.4.11. The "asymmetric-key-pair-with-certs-grouping" Grouping 727 This section presents two tree diagrams [RFC8340] illustrating the 728 "asymmetric-key-pair-with-certs-grouping" grouping. The first tree 729 diagram does not expand the internally used grouping statement(s): 731 grouping asymmetric-key-pair-with-certs-grouping 732 +---u asymmetric-key-pair-grouping 733 +-- certificates 734 | +-- certificate* [name] 735 | +-- name? string 736 | +---u end-entity-cert-grouping 737 +---u generate-csr-grouping 739 The following tree diagram expands the internally used grouping 740 statement(s), enabling the grouping's full structure to be seen: 742 grouping asymmetric-key-pair-with-certs-grouping 743 +-- public-key-format identityref 744 +-- public-key binary 745 +-- private-key-format? identityref 746 +-- (private-key-type) 747 | +--:(cleartext-private-key) 748 | | +-- cleartext-private-key? binary 749 | +--:(hidden-private-key) 750 | | +-- hidden-private-key? empty 751 | +--:(encrypted-private-key) {private-key-encryption}? 752 | +-- encrypted-private-key 753 | +-- encrypted-by 754 | +-- encrypted-value-format identityref 755 | +-- encrypted-value binary 756 +-- certificates 757 | +-- certificate* [name] 758 | +-- name? string 759 | +-- cert-data end-entity-cert-cms 760 | +---n certificate-expiration 761 | {certificate-expiration-notification}? 762 | +-- expiration-date yang:date-and-time 763 +---x generate-certificate-signing-request 764 {certificate-signing-request-generation}? 765 +---w input 766 | +---w csr-info ct:csr-info 767 +--ro output 768 +--ro certificate-signing-request ct:csr 770 Comments: 772 * This grouping defines an asymmetric key with one or more 773 associated certificates, a commonly needed combination in 774 configuration models. 776 * For the referenced grouping statement(s): 778 - The "asymmetric-key-pair-grouping" grouping is discussed in 779 Section 2.1.4.5. 780 - The "end-entity-cert-grouping" grouping is discussed in 781 Section 2.1.4.8. 782 - The "generate-csr-grouping" grouping is discussed in 783 Section 2.1.4.9. 785 2.1.5. Protocol-accessible Nodes 787 The "ietf-crypto-types" module does not contain any protocol- 788 accessible nodes, but the module needs to be "implemented", as 789 described in Section 5.6.5 of [RFC7950], in order for the identities 790 in Section 2.1.2 to be defined. 792 2.2. Example Usage 794 2.2.1. The "symmetric-key-grouping" and "asymmetric-key-pair-with- 795 certs-grouping" Grouping 797 The following non-normative module is constructed in order to 798 illustrate the use of the "symmetric-key-grouping" (Section 2.1.4.3), 799 the "asymmetric-key-pair-with-certs-grouping" (Section 2.1.4.11), and 800 the "password-grouping" (Section 2.1.4.2) grouping statements. 802 Notably, this example illustrates a hidden asymmetric key (ex-hidden- 803 asymmetric-key) has been used to encrypt a symmetric key (ex- 804 encrypted-one-symmetric-based-symmetric-key) that has been used to 805 encrypt another asymmetric key (ex-encrypted-rsa-based-asymmetric- 806 key). Additionally, the symmetric key is also used to encrypt a 807 password (ex-encrypted-password). 809 module ex-crypto-types-usage { 810 yang-version 1.1; 811 namespace "http://example.com/ns/example-crypto-types-usage"; 812 prefix ectu; 814 import ietf-crypto-types { 815 prefix ct; 816 reference 817 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 818 } 820 organization 821 "Example Corporation"; 822 contact 823 "YANG Designer "; 825 description 826 "This module illustrates the 'symmetric-key-grouping' 827 and 'asymmetric-key-grouping' groupings defined in 828 the 'ietf-crypto-types' module defined in RFC AAAA."; 830 revision 2021-09-14 { 831 description 832 "Initial version"; 833 reference 834 "RFC AAAA: Common YANG Data Types for Cryptography"; 835 } 837 container symmetric-keys { 838 description 839 "A container of symmetric keys."; 840 list symmetric-key { 841 key "name"; 842 description 843 "A symmetric key"; 844 leaf name { 845 type string; 846 description 847 "An arbitrary name for this key."; 848 } 849 uses ct:symmetric-key-grouping { 850 augment "key-type/encrypted-key/encrypted-key/" 851 + "encrypted-by" { 852 description 853 "Augments in a choice statement enabling the 854 encrypting key to be any other symmetric or 855 asymmetric key."; 856 uses encrypted-by-choice-grouping; 857 } 858 } 859 } 860 } 861 container asymmetric-keys { 862 description 863 "A container of asymmetric keys."; 864 list asymmetric-key { 865 key "name"; 866 leaf name { 867 type string; 868 description 869 "An arbitrary name for this key."; 870 } 871 uses ct:asymmetric-key-pair-with-certs-grouping { 872 augment "private-key-type/encrypted-private-key/" 873 + "encrypted-private-key/encrypted-by" { 875 description 876 "Augments in a choice statement enabling the 877 encrypting key to be any other symmetric or 878 asymmetric key."; 879 uses encrypted-by-choice-grouping; 880 } 881 } 882 description 883 "An asymmetric key pair with associated certificates."; 884 } 885 } 886 container passwords { 887 description 888 "A container of passwords."; 889 list password { 890 key "name"; 891 leaf name { 892 type string; 893 description 894 "An arbitrary name for this password."; 895 } 896 uses ct:password-grouping { 897 augment "password-type/encrypted-password/" 898 + "encrypted-password/encrypted-by" { 899 description 900 "Augments in a choice statement enabling the 901 encrypting key to be any symmetric or 902 asymmetric key."; 903 uses encrypted-by-choice-grouping; 904 } 905 } 906 description 907 "A password."; 908 } 909 } 911 grouping encrypted-by-choice-grouping { 912 description 913 "A grouping that defines a choice enabling references 914 to other keys."; 915 choice encrypted-by-choice { 916 mandatory true; 917 description 918 "A choice amongst other symmetric or asymmetric keys."; 919 case symmetric-key-ref { 920 leaf symmetric-key-ref { 921 type leafref { 922 path "/ectu:symmetric-keys/ectu:symmetric-key/" 923 + "ectu:name"; 924 } 925 description 926 "Identifies the symmetric key that encrypts this key."; 927 } 928 } 929 case asymmetric-key-ref { 930 leaf asymmetric-key-ref { 931 type leafref { 932 path "/ectu:asymmetric-keys/ectu:asymmetric-key/" 933 + "ectu:name"; 934 } 935 description 936 "Identifies the asymmetric key that encrypts this key."; 937 } 938 } 939 } 940 } 941 } 943 The tree diagram [RFC8340] for this example module follows: 945 module: ex-crypto-types-usage 946 +--rw symmetric-keys 947 | +--rw symmetric-key* [name] 948 | +--rw name string 949 | +--rw key-format? identityref 950 | +--rw (key-type) 951 | +--:(cleartext-key) 952 | | +--rw cleartext-key? binary 953 | +--:(hidden-key) 954 | | +--rw hidden-key? empty 955 | +--:(encrypted-key) {symmetric-key-encryption}? 956 | +--rw encrypted-key 957 | +--rw encrypted-by 958 | | +--rw (encrypted-by-choice) 959 | | +--:(symmetric-key-ref) 960 | | | +--rw symmetric-key-ref? leafref 961 | | +--:(asymmetric-key-ref) 962 | | +--rw asymmetric-key-ref? leafref 963 | +--rw encrypted-value-format identityref 964 | +--rw encrypted-value binary 965 +--rw asymmetric-keys 966 | +--rw asymmetric-key* [name] 967 | +--rw name string 968 | +--rw public-key-format identityref 969 | +--rw public-key binary 970 | +--rw private-key-format? identityref 971 | +--rw (private-key-type) 972 | | +--:(cleartext-private-key) 973 | | | +--rw cleartext-private-key? binary 974 | | +--:(hidden-private-key) 975 | | | +--rw hidden-private-key? empty 976 | | +--:(encrypted-private-key) {private-key-encryption}? 977 | | +--rw encrypted-private-key 978 | | +--rw encrypted-by 979 | | | +--rw (encrypted-by-choice) 980 | | | +--:(symmetric-key-ref) 981 | | | | +--rw symmetric-key-ref? leafref 982 | | | +--:(asymmetric-key-ref) 983 | | | +--rw asymmetric-key-ref? leafref 984 | | +--rw encrypted-value-format identityref 985 | | +--rw encrypted-value binary 986 | +--rw certificates 987 | | +--rw certificate* [name] 988 | | +--rw name string 989 | | +--rw cert-data end-entity-cert-cms 990 | | +---n certificate-expiration 991 | | {certificate-expiration-notification}? 992 | | +-- expiration-date yang:date-and-time 993 | +---x generate-certificate-signing-request 994 | {certificate-signing-request-generation}? 995 | +---w input 996 | | +---w csr-info ct:csr-info 997 | +--ro output 998 | +--ro certificate-signing-request ct:csr 999 +--rw passwords 1000 +--rw password* [name] 1001 +--rw name string 1002 +--rw (password-type) 1003 +--:(cleartext-password) 1004 | +--rw cleartext-password? string 1005 +--:(encrypted-password) {password-encryption}? 1006 +--rw encrypted-password 1007 +--rw encrypted-by 1008 | +--rw (encrypted-by-choice) 1009 | +--:(symmetric-key-ref) 1010 | | +--rw symmetric-key-ref? leafref 1011 | +--:(asymmetric-key-ref) 1012 | +--rw asymmetric-key-ref? leafref 1013 +--rw encrypted-value-format identityref 1014 +--rw encrypted-value binary 1016 Finally, the following example illustrates various symmetric and 1017 asymmetric keys as they might appear in configuration: 1019 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1021 1024 1025 ex-hidden-symmetric-key 1026 1027 1028 1029 ex-octet-string-based-symmetric-key 1030 ct:octet-string-key-format 1031 BASE64VALUE= 1032 1033 1034 ex-one-symmetric-based-symmetric-key 1035 ct:one-symmetric-key-format 1036 BASE64VALUE= 1037 1038 1039 ex-encrypted-one-symmetric-based-symmetric-key 1040 ct:one-symmetric-key-format 1041 1042 1043 ex-hidden-asymmetric-key 1045 1046 1047 ct:cms-enveloped-data-format 1048 1049 BASE64VALUE= 1050 1051 1052 1054 1057 1058 ex-hidden-asymmetric-key 1059 1060 ct:subject-public-key-info-format 1061 1062 BASE64VALUE= 1063 1064 1065 1066 ex-hidden-asymmetric-key-cert 1067 BASE64VALUE= 1068 1069 1070 1071 1072 ex-rsa-based-asymmetric-key 1073 1074 ct:subject-public-key-info-format 1075 1076 BASE64VALUE= 1077 1078 ct:rsa-private-key-format 1079 1080 BASE64VALUE= 1081 1082 1083 ex-cert 1084 BASE64VALUE= 1085 1086 1087 1088 1089 ex-one-asymmetric-based-asymmetric-key 1090 1091 ct:subject-public-key-info-format 1092 1093 BASE64VALUE= 1094 1095 ct:one-asymmetric-key-format 1096 1097 BASE64VALUE= 1098 1099 1100 ex-encrypted-rsa-based-asymmetric-key 1101 1102 ct:subject-public-key-info-format 1103 1104 BASE64VALUE= 1105 1106 ct:rsa-private-key-format 1107 1108 1109 1110 ex-encrypted-one-symmetric-based-symmetri\ 1111 c-key 1112 1113 1114 ct:cms-encrypted-data-format 1116 1117 BASE64VALUE= 1118 1119 1120 1122 1125 1126 ex-cleartext-password 1127 super-secret 1128 1129 1130 ex-encrypted-password 1131 1132 1133 ex-encrypted-one-symmetric-based-symmetri\ 1134 c-key 1135 1136 1137 ct:cms-encrypted-data-format 1138 1139 BASE64VALUE= 1140 1141 1142 1144 2.2.2. The "generate-certificate-signing-request" Action 1146 The following example illustrates the "generate-certificate-signing- 1147 request" action, discussed in Section 2.1.4.9, with the NETCONF 1148 protocol. 1150 REQUEST 1151 1153 1154 1156 1157 ex-key-sect571r1 1158 1159 BASE64VALUE= 1160 1161 1162 1163 1164 1166 RESPONSE 1168 1170 1172 BASE64VALUE= 1173 1174 1176 2.2.3. The "certificate-expiration" Notification 1178 The following example illustrates the "certificate-expiration" 1179 notification, discussed in Section 2.1.4.6, with the NETCONF 1180 protocol. 1182 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1184 1186 2018-05-25T00:01:00Z 1187 1189 1190 ex-hidden-asymmetric-key 1191 1192 1193 ex-hidden-asymmetric-key 1194 1195 2018-08-05T14:18:53-05:00 1197 1198 1199 1200 1201 1202 1204 2.3. YANG Module 1206 This module has normative references to [RFC2119], [RFC2986], 1207 [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], 1208 [RFC6031], [RFC6125], [RFC6991], [RFC7093], [RFC8174], [RFC8341], and 1209 [ITU.X690.2015]. 1211 file "ietf-crypto-types@2021-09-14.yang" 1213 module ietf-crypto-types { 1214 yang-version 1.1; 1215 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 1216 prefix ct; 1218 import ietf-yang-types { 1219 prefix yang; 1220 reference 1221 "RFC 6991: Common YANG Data Types"; 1222 } 1224 import ietf-netconf-acm { 1225 prefix nacm; 1226 reference 1227 "RFC 8341: Network Configuration Access Control Model"; 1228 } 1229 organization 1230 "IETF NETCONF (Network Configuration) Working Group"; 1232 contact 1233 "WG Web: 1234 WG List: 1235 Author: Kent Watsen "; 1237 description 1238 "This module defines common YANG types for cryptographic 1239 applications. 1241 Copyright (c) 2021 IETF Trust and the persons identified 1242 as authors of the code. All rights reserved. 1244 Redistribution and use in source and binary forms, with 1245 or without modification, is permitted pursuant to, and 1246 subject to the license terms contained in, the Simplified 1247 BSD License set forth in Section 4.c of the IETF Trust's 1248 Legal Provisions Relating to IETF Documents 1249 (https://trustee.ietf.org/license-info). 1251 This version of this YANG module is part of RFC AAAA 1252 (https://www.rfc-editor.org/info/rfcAAAA); see the RFC 1253 itself for full legal notices. 1255 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1256 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1257 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1258 are to be interpreted as described in BCP 14 (RFC 2119) 1259 (RFC 8174) when, and only when, they appear in all 1260 capitals, as shown here."; 1262 revision 2021-09-14 { 1263 description 1264 "Initial version"; 1265 reference 1266 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 1267 } 1269 /****************/ 1270 /* Features */ 1271 /****************/ 1273 feature one-symmetric-key-format { 1274 description 1275 "Indicates that the server supports the 1276 'one-symmetric-key-format' identity."; 1278 } 1280 feature one-asymmetric-key-format { 1281 description 1282 "Indicates that the server supports the 1283 'one-asymmetric-key-format' identity."; 1284 } 1286 feature symmetrically-encrypted-value-format { 1287 description 1288 "Indicates that the server supports the 1289 'symmetrically-encrypted-value-format' identity."; 1290 } 1292 feature asymmetrically-encrypted-value-format { 1293 description 1294 "Indicates that the server supports the 1295 'asymmetrically-encrypted-value-format' identity."; 1296 } 1298 feature cms-enveloped-data-format { 1299 description 1300 "Indicates that the server supports the 1301 'cms-enveloped-data-format' identity."; 1302 } 1304 feature cms-encrypted-data-format { 1305 description 1306 "Indicates that the server supports the 1307 'cms-encrypted-data-format' identity."; 1308 } 1310 feature certificate-signing-request-generation { 1311 description 1312 "Indicates that the server implements the 1313 'generate-certificate-signing-request' action."; 1314 } 1316 feature certificate-expiration-notification { 1317 description 1318 "Indicates that the server implements the 1319 'certificate-expiration' notification."; 1320 } 1322 feature password-encryption { 1323 description 1324 "Indicates that the server supports password 1325 encryption."; 1327 } 1329 feature symmetric-key-encryption { 1330 description 1331 "Indicates that the server supports encryption 1332 of symmetric keys."; 1333 } 1335 feature private-key-encryption { 1336 description 1337 "Indicates that the server supports encryption 1338 of private keys."; 1339 } 1341 /*************************************************/ 1342 /* Base Identities for Key Format Structures */ 1343 /*************************************************/ 1345 identity symmetric-key-format { 1346 description 1347 "Base key-format identity for symmetric keys."; 1348 } 1350 identity public-key-format { 1351 description 1352 "Base key-format identity for public keys."; 1353 } 1355 identity private-key-format { 1356 description 1357 "Base key-format identity for private keys."; 1358 } 1360 /****************************************************/ 1361 /* Identities for Private Key Format Structures */ 1362 /****************************************************/ 1364 identity rsa-private-key-format { 1365 base private-key-format; 1366 description 1367 "Indicates that the private key value is encoded 1368 as an RSAPrivateKey (from RFC 3447)."; 1369 reference 1370 "RFC 3447: PKCS #1: RSA Cryptography 1371 Specifications Version 2.2"; 1372 } 1374 identity ec-private-key-format { 1375 base private-key-format; 1376 description 1377 "Indicates that the private key value is encoded 1378 as an ECPrivateKey (from RFC 5915)"; 1379 reference 1380 "RFC 5915: Elliptic Curve Private Key Structure"; 1381 } 1383 identity one-asymmetric-key-format { 1384 if-feature "one-asymmetric-key-format"; 1385 base private-key-format; 1386 description 1387 "Indicates that the private key value is a CMS 1388 OneAsymmetricKey structure, as defined in RFC 5958, 1389 encoded using ASN.1 distinguished encoding rules 1390 (DER), as specified in ITU-T X.690."; 1391 reference 1392 "RFC 5958: Asymmetric Key Packages 1393 ITU-T X.690: 1394 Information technology - ASN.1 encoding rules: 1395 Specification of Basic Encoding Rules (BER), 1396 Canonical Encoding Rules (CER) and Distinguished 1397 Encoding Rules (DER)."; 1398 } 1400 /***************************************************/ 1401 /* Identities for Public Key Format Structures */ 1402 /***************************************************/ 1404 identity ssh-public-key-format { 1405 base public-key-format; 1406 description 1407 "Indicates that the public key value is an SSH public key, 1408 as specified by RFC 4253, Section 6.6, i.e.: 1410 string certificate or public key format 1411 identifier 1412 byte[n] key/certificate data."; 1413 reference 1414 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 1415 } 1417 identity subject-public-key-info-format { 1418 base public-key-format; 1419 description 1420 "Indicates that the public key value is a SubjectPublicKeyInfo 1421 structure, as described in RFC 5280 encoded using ASN.1 1422 distinguished encoding rules (DER), as specified in 1423 ITU-T X.690."; 1424 reference 1425 "RFC 5280: 1426 Internet X.509 Public Key Infrastructure Certificate 1427 and Certificate Revocation List (CRL) Profile 1428 ITU-T X.690: 1429 Information technology - ASN.1 encoding rules: 1430 Specification of Basic Encoding Rules (BER), 1431 Canonical Encoding Rules (CER) and Distinguished 1432 Encoding Rules (DER)."; 1433 } 1435 /******************************************************/ 1436 /* Identities for Symmetric Key Format Structures */ 1437 /******************************************************/ 1439 identity octet-string-key-format { 1440 base symmetric-key-format; 1441 description 1442 "Indicates that the key is encoded as a raw octet string. 1443 The length of the octet string MUST be appropriate for 1444 the associated algorithm's block size. 1446 How the associated algorithm is known is outside the 1447 scope of this module. This statement also applies when 1448 the octet string has been encrypted."; 1449 } 1451 identity one-symmetric-key-format { 1452 if-feature "one-symmetric-key-format"; 1453 base symmetric-key-format; 1454 description 1455 "Indicates that the private key value is a CMS 1456 OneSymmetricKey structure, as defined in RFC 6031, 1457 encoded using ASN.1 distinguished encoding rules 1458 (DER), as specified in ITU-T X.690."; 1459 reference 1460 "RFC 6031: Cryptographic Message Syntax (CMS) 1461 Symmetric Key Package Content Type 1462 ITU-T X.690: 1463 Information technology - ASN.1 encoding rules: 1464 Specification of Basic Encoding Rules (BER), 1465 Canonical Encoding Rules (CER) and Distinguished 1466 Encoding Rules (DER)."; 1467 } 1469 /*************************************************/ 1470 /* Identities for Encrypted Value Structures */ 1471 /*************************************************/ 1473 identity encrypted-value-format { 1474 description 1475 "Base format identity for encrypted values."; 1476 } 1478 identity symmetrically-encrypted-value-format { 1479 if-feature "symmetrically-encrypted-value-format"; 1480 base encrypted-value-format; 1481 description 1482 "Base format identity for symmetrically encrypted 1483 values."; 1484 } 1486 identity asymmetrically-encrypted-value-format { 1487 if-feature "asymmetrically-encrypted-value-format"; 1488 base encrypted-value-format; 1489 description 1490 "Base format identity for asymmetrically encrypted 1491 values."; 1492 } 1494 identity cms-encrypted-data-format { 1495 if-feature "cms-encrypted-data-format"; 1496 base symmetrically-encrypted-value-format; 1497 description 1498 "Indicates that the encrypted value conforms to 1499 the 'encrypted-data-cms' type with the constraint 1500 that the 'unprotectedAttrs' value is not set."; 1501 reference 1502 "RFC 5652: Cryptographic Message Syntax (CMS) 1503 ITU-T X.690: 1504 Information technology - ASN.1 encoding rules: 1505 Specification of Basic Encoding Rules (BER), 1506 Canonical Encoding Rules (CER) and Distinguished 1507 Encoding Rules (DER)."; 1508 } 1510 identity cms-enveloped-data-format { 1511 if-feature "cms-enveloped-data-format"; 1512 base asymmetrically-encrypted-value-format; 1513 description 1514 "Indicates that the encrypted value conforms to the 1515 'enveloped-data-cms' type with the following constraints: 1517 The EnvelopedData structure MUST have exactly one 1518 'RecipientInfo'. 1520 If the asymmetric key supports public key cryptography 1521 (e.g., RSA), then the 'RecipientInfo' must be a 1522 'KeyTransRecipientInfo' with the 'RecipientIdentifier' 1523 using a 'subjectKeyIdentifier' with the value set using 1524 'method 1' in RFC 7093 over the recipient's public key. 1526 Otherwise, if the asymmetric key supports key agreement 1527 (e.g., ECC), then the 'RecipientInfo' must be a 1528 'KeyAgreeRecipientInfo'. The 'OriginatorIdentifierOrKey' 1529 value must use the 'OriginatorPublicKey' alternative. 1530 The 'UserKeyingMaterial' value must not be present. 1531 There must be exactly one 'RecipientEncryptedKeys' value 1532 having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' 1533 with the value set using 'method 1' in RFC 7093 over the 1534 recipient's public key."; 1535 reference 1536 "RFC 5652: Cryptographic Message Syntax (CMS) 1537 RFC 7093: 1538 Additional Methods for Generating Key 1539 Identifiers Values 1540 ITU-T X.690: 1541 Information technology - ASN.1 encoding rules: 1542 Specification of Basic Encoding Rules (BER), 1543 Canonical Encoding Rules (CER) and Distinguished 1544 Encoding Rules (DER)."; 1545 } 1547 /***************************************************/ 1548 /* Typedefs for ASN.1 structures from RFC 2986 */ 1549 /***************************************************/ 1551 typedef csr-info { 1552 type binary; 1553 description 1554 "A CertificationRequestInfo structure, as defined in 1555 RFC 2986, encoded using ASN.1 distinguished encoding 1556 rules (DER), as specified in ITU-T X.690."; 1557 reference 1558 "RFC 2986: PKCS #10: Certification Request Syntax 1559 Specification Version 1.7 1560 ITU-T X.690: 1561 Information technology - ASN.1 encoding rules: 1562 Specification of Basic Encoding Rules (BER), 1563 Canonical Encoding Rules (CER) and Distinguished 1564 Encoding Rules (DER)."; 1565 } 1567 typedef csr { 1568 type binary; 1569 description 1570 "A CertificationRequest structure, as specified in 1571 RFC 2986, encoded using ASN.1 distinguished encoding 1572 rules (DER), as specified in ITU-T X.690."; 1573 reference 1574 "RFC 2986: 1575 PKCS #10: Certification Request Syntax Specification 1576 Version 1.7 1577 ITU-T X.690: 1578 Information technology - ASN.1 encoding rules: 1579 Specification of Basic Encoding Rules (BER), 1580 Canonical Encoding Rules (CER) and Distinguished 1581 Encoding Rules (DER)."; 1582 } 1584 /***************************************************/ 1585 /* Typedefs for ASN.1 structures from RFC 5280 */ 1586 /***************************************************/ 1588 typedef x509 { 1589 type binary; 1590 description 1591 "A Certificate structure, as specified in RFC 5280, 1592 encoded using ASN.1 distinguished encoding rules (DER), 1593 as specified in ITU-T X.690."; 1594 reference 1595 "RFC 5280: 1596 Internet X.509 Public Key Infrastructure Certificate 1597 and Certificate Revocation List (CRL) Profile 1598 ITU-T X.690: 1599 Information technology - ASN.1 encoding rules: 1600 Specification of Basic Encoding Rules (BER), 1601 Canonical Encoding Rules (CER) and Distinguished 1602 Encoding Rules (DER)."; 1603 } 1605 typedef crl { 1606 type binary; 1607 description 1608 "A CertificateList structure, as specified in RFC 5280, 1609 encoded using ASN.1 distinguished encoding rules (DER), 1610 as specified in ITU-T X.690."; 1611 reference 1612 "RFC 5280: 1613 Internet X.509 Public Key Infrastructure Certificate 1614 and Certificate Revocation List (CRL) Profile 1615 ITU-T X.690: 1617 Information technology - ASN.1 encoding rules: 1618 Specification of Basic Encoding Rules (BER), 1619 Canonical Encoding Rules (CER) and Distinguished 1620 Encoding Rules (DER)."; 1621 } 1623 /***************************************************/ 1624 /* Typedefs for ASN.1 structures from RFC 6960 */ 1625 /***************************************************/ 1627 typedef oscp-request { 1628 type binary; 1629 description 1630 "A OCSPRequest structure, as specified in RFC 6960, 1631 encoded using ASN.1 distinguished encoding rules 1632 (DER), as specified in ITU-T X.690."; 1633 reference 1634 "RFC 6960: 1635 X.509 Internet Public Key Infrastructure Online 1636 Certificate Status Protocol - OCSP 1637 ITU-T X.690: 1638 Information technology - ASN.1 encoding rules: 1639 Specification of Basic Encoding Rules (BER), 1640 Canonical Encoding Rules (CER) and Distinguished 1641 Encoding Rules (DER)."; 1642 } 1644 typedef oscp-response { 1645 type binary; 1646 description 1647 "A OCSPResponse structure, as specified in RFC 6960, 1648 encoded using ASN.1 distinguished encoding rules 1649 (DER), as specified in ITU-T X.690."; 1650 reference 1651 "RFC 6960: 1652 X.509 Internet Public Key Infrastructure Online 1653 Certificate Status Protocol - OCSP 1654 ITU-T X.690: 1655 Information technology - ASN.1 encoding rules: 1656 Specification of Basic Encoding Rules (BER), 1657 Canonical Encoding Rules (CER) and Distinguished 1658 Encoding Rules (DER)."; 1659 } 1661 /***********************************************/ 1662 /* Typedefs for ASN.1 structures from 5652 */ 1663 /***********************************************/ 1664 typedef cms { 1665 type binary; 1666 description 1667 "A ContentInfo structure, as specified in RFC 5652, 1668 encoded using ASN.1 distinguished encoding rules (DER), 1669 as specified in ITU-T X.690."; 1670 reference 1671 "RFC 5652: 1672 Cryptographic Message Syntax (CMS) 1673 ITU-T X.690: 1674 Information technology - ASN.1 encoding rules: 1675 Specification of Basic Encoding Rules (BER), 1676 Canonical Encoding Rules (CER) and Distinguished 1677 Encoding Rules (DER)."; 1678 } 1680 typedef data-content-cms { 1681 type cms; 1682 description 1683 "A CMS structure whose top-most content type MUST be the 1684 data content type, as described by Section 4 in RFC 5652."; 1685 reference 1686 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1687 } 1689 typedef signed-data-cms { 1690 type cms; 1691 description 1692 "A CMS structure whose top-most content type MUST be the 1693 signed-data content type, as described by Section 5 in 1694 RFC 5652."; 1695 reference 1696 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1697 } 1699 typedef enveloped-data-cms { 1700 type cms; 1701 description 1702 "A CMS structure whose top-most content type MUST be the 1703 enveloped-data content type, as described by Section 6 1704 in RFC 5652."; 1705 reference 1706 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1707 } 1709 typedef digested-data-cms { 1710 type cms; 1711 description 1712 "A CMS structure whose top-most content type MUST be the 1713 digested-data content type, as described by Section 7 1714 in RFC 5652."; 1715 reference 1716 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1717 } 1719 typedef encrypted-data-cms { 1720 type cms; 1721 description 1722 "A CMS structure whose top-most content type MUST be the 1723 encrypted-data content type, as described by Section 8 1724 in RFC 5652."; 1725 reference 1726 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1727 } 1729 typedef authenticated-data-cms { 1730 type cms; 1731 description 1732 "A CMS structure whose top-most content type MUST be the 1733 authenticated-data content type, as described by Section 9 1734 in RFC 5652."; 1735 reference 1736 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1737 } 1739 /*********************************************************/ 1740 /* Typedefs for ASN.1 structures related to RFC 5280 */ 1741 /*********************************************************/ 1743 typedef trust-anchor-cert-x509 { 1744 type x509; 1745 description 1746 "A Certificate structure that MUST encode a self-signed 1747 root certificate."; 1748 } 1750 typedef end-entity-cert-x509 { 1751 type x509; 1752 description 1753 "A Certificate structure that MUST encode a certificate 1754 that is neither self-signed nor having Basic constraint 1755 CA true."; 1756 } 1758 /*********************************************************/ 1759 /* Typedefs for ASN.1 structures related to RFC 5652 */ 1760 /*********************************************************/ 1762 typedef trust-anchor-cert-cms { 1763 type signed-data-cms; 1764 description 1765 "A CMS SignedData structure that MUST contain the chain of 1766 X.509 certificates needed to authenticate the certificate 1767 presented by a client or end-entity. 1769 The CMS MUST contain only a single chain of certificates. 1770 The client or end-entity certificate MUST only authenticate 1771 to last intermediate CA certificate listed in the chain. 1773 In all cases, the chain MUST include a self-signed root 1774 certificate. In the case where the root certificate is 1775 itself the issuer of the client or end-entity certificate, 1776 only one certificate is present. 1778 This CMS structure MAY (as applicable where this type is 1779 used) also contain suitably fresh (as defined by local 1780 policy) revocation objects with which the device can 1781 verify the revocation status of the certificates. 1783 This CMS encodes the degenerate form of the SignedData 1784 structure that is commonly used to disseminate X.509 1785 certificates and revocation objects (RFC 5280)."; 1786 reference 1787 "RFC 5280: 1788 Internet X.509 Public Key Infrastructure Certificate 1789 and Certificate Revocation List (CRL) Profile."; 1790 } 1792 typedef end-entity-cert-cms { 1793 type signed-data-cms; 1794 description 1795 "A CMS SignedData structure that MUST contain the end 1796 entity certificate itself, and MAY contain any number 1797 of intermediate certificates leading up to a trust 1798 anchor certificate. The trust anchor certificate 1799 MAY be included as well. 1801 The CMS MUST contain a single end entity certificate. 1802 The CMS MUST NOT contain any spurious certificates. 1804 This CMS structure MAY (as applicable where this type is 1805 used) also contain suitably fresh (as defined by local 1806 policy) revocation objects with which the device can 1807 verify the revocation status of the certificates. 1809 This CMS encodes the degenerate form of the SignedData 1810 structure that is commonly used to disseminate X.509 1811 certificates and revocation objects (RFC 5280)."; 1812 reference 1813 "RFC 5280: 1814 Internet X.509 Public Key Infrastructure Certificate 1815 and Certificate Revocation List (CRL) Profile."; 1816 } 1818 /*****************/ 1819 /* Groupings */ 1820 /*****************/ 1822 grouping encrypted-value-grouping { 1823 description 1824 "A reusable grouping for a value that has been encrypted by 1825 a referenced symmetric or asymmetric key."; 1826 container encrypted-by { 1827 nacm:default-deny-write; 1828 description 1829 "An empty container enabling a reference to the key that 1830 encrypted the value to be augmented in. The referenced 1831 key MUST be a symmetric key or an asymmetric key. 1833 A symmetric key MUST be referenced via a leaf node called 1834 'symmetric-key-ref'. An asymmetric key MUST be referenced 1835 via a leaf node called 'asymmetric-key-ref'. 1837 The leaf nodes MUST be direct descendants in the data tree, 1838 and MAY be direct descendants in the schema tree."; 1839 } 1840 leaf encrypted-value-format { 1841 type identityref { 1842 base encrypted-value-format; 1843 } 1844 mandatory true; 1845 description 1846 "Identifies the format of the 'encrypted-value' leaf. 1848 If 'encrypted-by' points to a symmetric key, then a 1849 'symmetrically-encrypted-value-format' based identity 1850 MUST by set (e.g., cms-encrypted-data-format). 1852 If 'encrypted-by' points to an asymmetric key, then an 1853 'asymmetrically-encrypted-value-format' based identity 1854 MUST by set (e.g., cms-enveloped-data-format)."; 1855 } 1856 leaf encrypted-value { 1857 nacm:default-deny-write; 1858 type binary; 1859 must '../encrypted-by'; 1860 mandatory true; 1861 description 1862 "The value, encrypted using the referenced symmetric 1863 or asymmetric key. The value MUST be encoded using 1864 the format associated with the 'encrypted-value-format' 1865 leaf."; 1866 } 1867 } 1869 grouping password-grouping { 1870 description 1871 "A password that MAY be encrypted."; 1872 choice password-type { 1873 nacm:default-deny-write; 1874 mandatory true; 1875 description 1876 "Choice between password types."; 1877 case cleartext-password { 1878 leaf cleartext-password { 1879 nacm:default-deny-all; 1880 type string; 1881 description 1882 "The cleartext value of the password."; 1883 } 1884 } 1885 case encrypted-password { 1886 if-feature "password-encryption"; 1887 container encrypted-password { 1888 description 1889 "A container for the encrypted password value."; 1890 uses encrypted-value-grouping; 1891 } 1892 } 1893 } 1894 } 1896 grouping symmetric-key-grouping { 1897 description 1898 "A symmetric key."; 1899 leaf key-format { 1900 nacm:default-deny-write; 1901 type identityref { 1902 base symmetric-key-format; 1903 } 1904 description 1905 "Identifies the symmetric key's format. Implementations 1906 SHOULD ensure that the incoming symmetric key value is 1907 encoded in the specified format. 1909 For encrypted keys, the value is the same as it would 1910 have been if the key were not encrypted."; 1911 } 1912 choice key-type { 1913 nacm:default-deny-write; 1914 mandatory true; 1915 description 1916 "Choice between key types."; 1917 case cleartext-key { 1918 leaf cleartext-key { 1919 nacm:default-deny-all; 1920 type binary; 1921 must '../key-format'; 1922 description 1923 "The binary value of the key. The interpretation of 1924 the value is defined by the 'key-format' field."; 1925 } 1926 } 1927 case hidden-key { 1928 leaf hidden-key { 1929 type empty; 1930 must 'not(../key-format)'; 1931 description 1932 "A hidden key. How such keys are created is outside 1933 the scope of this module."; 1934 } 1935 } 1936 case encrypted-key { 1937 if-feature "symmetric-key-encryption"; 1938 container encrypted-key { 1939 must '../key-format'; 1940 description 1941 "A container for the encrypted symmetric key value. 1942 The interpretation of the 'encrypted-value' node 1943 is via the 'key-format' node"; 1944 uses encrypted-value-grouping; 1945 } 1946 } 1947 } 1948 } 1950 grouping public-key-grouping { 1951 description 1952 "A public key."; 1954 leaf public-key-format { 1955 nacm:default-deny-write; 1956 type identityref { 1957 base public-key-format; 1958 } 1959 mandatory true; 1960 description 1961 "Identifies the public key's format. Implementations SHOULD 1962 ensure that the incoming public key value is encoded in the 1963 specified format."; 1964 } 1965 leaf public-key { 1966 nacm:default-deny-write; 1967 type binary; 1968 mandatory true; 1969 description 1970 "The binary value of the public key. The interpretation 1971 of the value is defined by 'public-key-format' field."; 1972 } 1973 } 1975 grouping asymmetric-key-pair-grouping { 1976 description 1977 "A private key and its associated public key. Implementations 1978 SHOULD ensure that the two keys are a matching pair."; 1979 uses public-key-grouping; 1980 leaf private-key-format { 1981 nacm:default-deny-write; 1982 type identityref { 1983 base private-key-format; 1984 } 1985 description 1986 "Identifies the private key's format. Implementations SHOULD 1987 ensure that the incoming private key value is encoded in the 1988 specified format. 1990 For encrypted keys, the value is the same as it would have 1991 been if the key were not encrypted."; 1992 } 1993 choice private-key-type { 1994 nacm:default-deny-write; 1995 mandatory true; 1996 description 1997 "Choice between key types."; 1998 case cleartext-private-key { 1999 leaf cleartext-private-key { 2000 nacm:default-deny-all; 2001 type binary; 2002 must '../private-key-format'; 2003 description 2004 "The value of the binary key The key's value is 2005 interpreted by the 'private-key-format' field."; 2006 } 2007 } 2008 case hidden-private-key { 2009 leaf hidden-private-key { 2010 type empty; 2011 must 'not(../private-key-format)'; 2012 description 2013 "A hidden key. How such keys are created is 2014 outside the scope of this module."; 2015 } 2016 } 2017 case encrypted-private-key { 2018 if-feature "private-key-encryption"; 2019 container encrypted-private-key { 2020 must '../private-key-format'; 2021 description 2022 "A container for the encrypted asymmetric private key 2023 value. The interpretation of the 'encrypted-value' 2024 node is via the 'private-key-format' node"; 2025 uses encrypted-value-grouping; 2026 } 2027 } 2028 } 2029 } 2031 grouping certificate-expiration-grouping { 2032 description 2033 "A notification for when a certificate is about to, or 2034 already has, expired."; 2035 notification certificate-expiration { 2036 if-feature "certificate-expiration-notification"; 2037 description 2038 "A notification indicating that the configured certificate 2039 is either about to expire or has already expired. When to 2040 send notifications is an implementation specific decision, 2041 but it is RECOMMENDED that a notification be sent once a 2042 month for 3 months, then once a week for four weeks, and 2043 then once a day thereafter until the issue is resolved."; 2044 leaf expiration-date { 2045 type yang:date-and-time; 2046 mandatory true; 2047 description 2048 "Identifies the expiration date on the certificate."; 2049 } 2051 } 2052 } 2054 grouping trust-anchor-cert-grouping { 2055 description 2056 "A trust anchor certificate, and a notification for when 2057 it is about to (or already has) expire."; 2058 leaf cert-data { 2059 nacm:default-deny-write; 2060 type trust-anchor-cert-cms; 2061 description 2062 "The binary certificate data for this certificate."; 2063 } 2064 uses certificate-expiration-grouping; 2065 } 2067 grouping end-entity-cert-grouping { 2068 description 2069 "An end entity certificate, and a notification for when 2070 it is about to (or already has) expire. Implementations 2071 SHOULD assert that, where used, the end entity certificate 2072 contains the expected public key."; 2073 leaf cert-data { 2074 nacm:default-deny-write; 2075 type end-entity-cert-cms; 2076 description 2077 "The binary certificate data for this certificate."; 2078 } 2079 uses certificate-expiration-grouping; 2080 } 2082 grouping generate-csr-grouping { 2083 description 2084 "Defines the 'generate-certificate-signing-request' action."; 2085 action generate-certificate-signing-request { 2086 if-feature "certificate-signing-request-generation"; 2087 nacm:default-deny-all; 2088 description 2089 "Generates a certificate signing request structure for 2090 the associated asymmetric key using the passed subject 2091 and attribute values. 2093 This action statement is only available when the 2094 associated 'public-key-format' node's value is 2095 'subject-public-key-info-format'."; 2096 reference 2097 "RFC 6125: 2098 Representation and Verification of Domain-Based 2099 Application Service Identity within Internet Public Key 2100 Infrastructure Using X.509 (PKIX) Certificates in the 2101 Context of Transport Layer Security (TLS)"; 2102 input { 2103 leaf csr-info { 2104 type ct:csr-info; 2105 mandatory true; 2106 description 2107 "A CertificationRequestInfo structure, as defined in 2108 RFC 2986. 2110 Enables the client to provide a fully-populated 2111 CertificationRequestInfo structure that the server 2112 only needs to sign in order to generate the complete 2113 'CertificationRequest' structure to return in the 2114 'output'. 2116 The 'AlgorithmIdentifier' field contained inside 2117 the 'SubjectPublicKeyInfo' field MUST be one known 2118 to be supported by the device."; 2119 reference 2120 "RFC 2986: 2121 PKCS #10: Certification Request Syntax Specification 2122 RFC AAAA: 2123 YANG Data Types and Groupings for Cryptography"; 2124 } 2125 } 2126 output { 2127 leaf certificate-signing-request { 2128 type ct:csr; 2129 mandatory true; 2130 description 2131 "A CertificationRequest structure, as defined in 2132 RFC 2986."; 2133 reference 2134 "RFC 2986: 2135 PKCS #10: Certification Request Syntax Specification 2136 RFC AAAA: 2137 YANG Data Types and Groupings for Cryptography"; 2138 } 2139 } 2140 } 2141 } // generate-csr-grouping 2143 grouping asymmetric-key-pair-with-cert-grouping { 2144 description 2145 "A private/public key pair and an associated certificate. 2146 Implementations SHOULD assert that certificates contain 2147 the matching public key."; 2148 uses asymmetric-key-pair-grouping; 2149 uses end-entity-cert-grouping; 2150 uses generate-csr-grouping; 2151 } // asymmetric-key-pair-with-cert-grouping 2153 grouping asymmetric-key-pair-with-certs-grouping { 2154 description 2155 "A private/public key pair and associated certificates. 2156 Implementations SHOULD assert that certificates contain 2157 the matching public key."; 2158 uses asymmetric-key-pair-grouping; 2159 container certificates { 2160 nacm:default-deny-write; 2161 description 2162 "Certificates associated with this asymmetric key."; 2163 list certificate { 2164 key "name"; 2165 description 2166 "A certificate for this asymmetric key."; 2167 leaf name { 2168 type string; 2169 description 2170 "An arbitrary name for the certificate."; 2171 } 2172 uses end-entity-cert-grouping { 2173 refine "cert-data" { 2174 mandatory true; 2175 } 2176 } 2177 } 2178 } 2179 uses generate-csr-grouping; 2180 } // asymmetric-key-pair-with-certs-grouping 2182 } 2184 2186 3. Security Considerations 2188 3.1. No Support for CRMF 2190 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 2191 signing-request" action. The use of Certificate Request Message 2192 Format (CRMF) [RFC4211] was considered, but it was unclear if there 2193 was market demand for it. If it is desired to support CRMF in the 2194 future, a backwards compatible solution can be defined at that time. 2196 3.2. No Support for Key Generation 2198 Early revisions of this document included "rpc" statements for 2199 generating symmetric and asymmetric keys. These statements were 2200 removed due to an inability to obtain consensus for how to identify 2201 the key-algorithm to use. Thusly, the solution presented in this 2202 document only supports keys to be configured via an external client, 2203 which does not support Security best practice. 2205 3.3. Unconstrained Public Key Usage 2207 This module defines the "public-key-grouping" grouping, which enables 2208 the configuration of public keys without constraints on their usage, 2209 e.g., what operations the key is allowed to be used for (encryption, 2210 verification, both). 2212 The "asymmetric-key-pair-grouping" grouping uses the aforementioned 2213 "public-key-grouping" grouping, and carries the same traits. 2215 The "asymmetric-key-pair-with-cert-grouping" grouping uses the 2216 aforementioned "asymmetric-key-pair-grouping" grouping, whereby each 2217 certificate may constrain the usage of the public key according to 2218 local policy. 2220 3.4. Unconstrained Private Key Usage 2222 This module defines the "asymmetric-key-pair-grouping" grouping, 2223 which enables the configuration of private keys without constraints 2224 on their usage, e.g., what operations the key is allowed to be used 2225 for (e.g., signature, decryption, both). 2227 The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned 2228 "asymmetric-key-pair-grouping" grouping, whereby configured 2229 certificates (e.g., identity certificates) may constrain the use of 2230 the public key according to local policy. 2232 3.5. Strength of Keys Conveyed 2234 When accessing key values, it is desireable that implementations 2235 ensure that the strength of the keys being accessed is not greater 2236 than the strength of the underlying secure transport connection over 2237 which the keys are conveyed. However, comparing key strengths can be 2238 complicated and difficult to implement in practice. 2240 That said, expert Security opinion suggests that already it is 2241 infeasible to break a 128-bit symmetric key using a classical 2242 computer, and thus the concern for conveying higher-strength keys 2243 begins to lose its allure. 2245 Implementations SHOULD only use secure transport protocols meeting 2246 local policy. A reasonable policy may, e.g., state that only 2247 ciphersuites listed as "recommended" by the IETF be used (e.g., 2248 [RFC7525] for TLS). 2250 3.6. Encrypting Passwords 2252 The module contained within this document enables passwords to be 2253 encrypted. Passwords may be encrypted via a symmetric key using the 2254 "cms-encrypted-data-format" format. This format uses the CMS 2255 EncryptedData structure, which allows any encryption algorithm to be 2256 used. 2258 In order to thwart rainbow attacks, algorithms that result in a 2259 unique output for the same input SHOULD NOT be used. For instance, 2260 AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas 2261 "CBC" mode is permissible since an unpredictable initialization 2262 vector (IV) MUST be used for each use. 2264 3.7. Deletion of Cleartext Key Values 2266 This module defines storage for cleartext key values that SHOULD be 2267 zeroized when deleted, so as to prevent the remnants of their 2268 persisted storage locations from being analyzed in any meaningful 2269 way. 2271 The cleartext key values are the "cleartext-key" node defined in the 2272 "symmetric-key-grouping" grouping (Section 2.1.4.3) and the 2273 "cleartext-private-key" node defined in the "asymmetric-key-pair- 2274 grouping" grouping ("Section 2.1.4.5). 2276 3.8. The "ietf-crypto-types" YANG Module 2278 The YANG module in this document defines "grouping" statements that 2279 are designed to be accessed via YANG based management protocols, such 2280 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2281 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2282 with mutual authentication. 2284 The NETCONF access control model (NACM) [RFC8341] provides the means 2285 to restrict access for particular users to a pre-configured subset of 2286 all available protocol operations and content. 2288 Since the module in this document only defines groupings, these 2289 considerations are primarily for the designers of other modules that 2290 use these groupings. 2292 Some of the readable data nodes defined in this YANG module may be 2293 considered sensitive or vulnerable in some network environments. It 2294 is thus important to control read access (e.g., via get, get-config, 2295 or notification) to these data nodes. These are the subtrees and 2296 data nodes and their sensitivity/vulnerability: 2298 * The "cleartext-key" node: 2300 The "cleartext-key" node defined in the "symmetric-key- 2301 grouping" grouping is additionally sensitive to read operations 2302 such that, in normal use cases, it should never be returned to 2303 a client. For this reason, the NACM extension "default-deny- 2304 all" has been applied to it. 2306 * The "cleartext-private-key" node: 2308 The "cleartext-private-key" node defined in the "asymmetric- 2309 key-pair-grouping" grouping is additionally sensitive to read 2310 operations such that, in normal use cases, it should never be 2311 returned to a client. For this reason, the NACM extension 2312 "default-deny-all" has been applied. 2314 * The "cert-data" node: 2316 The "cert-data" node, defined in both the "trust-anchor-cert- 2317 grouping" and "end-entity-cert-grouping" groupings, is 2318 additionally sensitive to read operations, as certificates 2319 sometimes convey personally identifying information (especially 2320 end-entity certificates). However, as it is commonly 2321 understood that certificates are "public", the NACM extension 2322 "nacm:default-deny-write" (not "default-deny-all") has been 2323 applied. It is RECOMMENDED that implementations adjust read- 2324 access to certificates to comply with local policy. 2326 All the writable data nodes defined by all the groupings defined in 2327 this module may be considered sensitive or vulnerable in some network 2328 environments. For instance, even the modification of a public key or 2329 a certificate can dramatically alter the implemented security policy. 2330 For this reason, the NACM extension "default-deny-write" has been 2331 applied to all the data nodes defined in the module. 2333 Some of the operations in this YANG module may be considered 2334 sensitive or vulnerable in some network environments. It is thus 2335 important to control access to these operations. These are the 2336 operations and their sensitivity/vulnerability: 2338 * generate-certificate-signing-request: 2340 This "action" statement SHOULD only be executed by authorized 2341 users. For this reason, the NACM extension "default-deny-all" 2342 has been applied. Note that NACM uses "default-deny-all" to 2343 protect "RPC" and "action" statements; it does not define, 2344 e.g., an extension called "default-deny-execute". 2346 For this action, it is RECOMMENDED that implementations assert 2347 channel binding [RFC5056], so as to ensure that the application 2348 layer that sent the request is the same as the device 2349 authenticated when the secure transport layer was established. 2351 4. IANA Considerations 2353 4.1. The "IETF XML" Registry 2355 This document registers one URI in the "ns" subregistry of the "IETF 2356 XML" registry [RFC3688]. Following the format in [RFC3688], the 2357 following registration is requested: 2359 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2360 Registrant Contact: The IESG 2361 XML: N/A, the requested URI is an XML namespace. 2363 4.2. The "YANG Module Names" Registry 2365 This document registers one YANG module in the "YANG Module Names" 2366 registry [RFC6020]. Following the format in [RFC6020], the following 2367 registration is requested: 2369 name: ietf-crypto-types 2370 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2371 prefix: ct 2372 reference: RFC AAAA 2374 5. References 2376 5.1. Normative References 2378 [ITU.X680.2015] 2379 International Telecommunication Union, "Information 2380 technology - Abstract Syntax Notation One (ASN.1): 2381 Specification of basic notation", ITU-T Recommendation 2382 X.680, ISO/IEC 8824-1:2015, August 2015, 2383 . 2385 [ITU.X690.2015] 2386 International Telecommunication Union, "Information 2387 Technology - ASN.1 encoding rules: Specification of Basic 2388 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2389 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2390 X.690, ISO/IEC 8825-1:2015, August 2015, 2391 . 2393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2394 Requirement Levels", BCP 14, RFC 2119, 2395 DOI 10.17487/RFC2119, March 1997, 2396 . 2398 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2399 Standards (PKCS) #1: RSA Cryptography Specifications 2400 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2401 2003, . 2403 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2404 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2405 January 2006, . 2407 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2408 Housley, R., and W. Polk, "Internet X.509 Public Key 2409 Infrastructure Certificate and Certificate Revocation List 2410 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2411 . 2413 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2414 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2415 . 2417 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 2418 DOI 10.17487/RFC5958, August 2010, 2419 . 2421 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2422 (CMS) Symmetric Key Package Content Type", RFC 6031, 2423 DOI 10.17487/RFC6031, December 2010, 2424 . 2426 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2427 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2428 . 2430 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 2431 for Generating Key Identifiers Values", RFC 7093, 2432 DOI 10.17487/RFC7093, December 2013, 2433 . 2435 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2436 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2437 . 2439 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2440 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2441 May 2017, . 2443 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2444 Access Control Model", STD 91, RFC 8341, 2445 DOI 10.17487/RFC8341, March 2018, 2446 . 2448 5.2. Informative References 2450 [I-D.ietf-netconf-crypto-types] 2451 Watsen, K., "YANG Data Types and Groupings for 2452 Cryptography", Work in Progress, Internet-Draft, draft- 2453 ietf-netconf-crypto-types-20, 18 May 2021, 2454 . 2457 [I-D.ietf-netconf-http-client-server] 2458 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 2459 Servers", Work in Progress, Internet-Draft, draft-ietf- 2460 netconf-http-client-server-07, 18 May 2021, 2461 . 2464 [I-D.ietf-netconf-keystore] 2465 Watsen, K., "A YANG Data Model for a Keystore", Work in 2466 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 2467 18 May 2021, . 2470 [I-D.ietf-netconf-netconf-client-server] 2471 Watsen, K., "NETCONF Client and Server Models", Work in 2472 Progress, Internet-Draft, draft-ietf-netconf-netconf- 2473 client-server-23, 18 May 2021, 2474 . 2477 [I-D.ietf-netconf-restconf-client-server] 2478 Watsen, K., "RESTCONF Client and Server Models", Work in 2479 Progress, Internet-Draft, draft-ietf-netconf-restconf- 2480 client-server-23, 18 May 2021, 2481 . 2484 [I-D.ietf-netconf-ssh-client-server] 2485 Watsen, K., "YANG Groupings for SSH Clients and SSH 2486 Servers", Work in Progress, Internet-Draft, draft-ietf- 2487 netconf-ssh-client-server-25, 18 June 2021, 2488 . 2491 [I-D.ietf-netconf-tcp-client-server] 2492 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 2493 and TCP Servers", Work in Progress, Internet-Draft, draft- 2494 ietf-netconf-tcp-client-server-10, 18 May 2021, 2495 . 2498 [I-D.ietf-netconf-tls-client-server] 2499 Watsen, K., "YANG Groupings for TLS Clients and TLS 2500 Servers", Work in Progress, Internet-Draft, draft-ietf- 2501 netconf-tls-client-server-25, 18 June 2021, 2502 . 2505 [I-D.ietf-netconf-trust-anchors] 2506 Watsen, K., "A YANG Data Model for a Truststore", Work in 2507 Progress, Internet-Draft, draft-ietf-netconf-trust- 2508 anchors-15, 18 May 2021, 2509 . 2512 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2513 Request Syntax Specification Version 1.7", RFC 2986, 2514 DOI 10.17487/RFC2986, November 2000, 2515 . 2517 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2518 DOI 10.17487/RFC3688, January 2004, 2519 . 2521 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2522 Certificate Request Message Format (CRMF)", RFC 4211, 2523 DOI 10.17487/RFC4211, September 2005, 2524 . 2526 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2527 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2528 . 2530 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2531 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2532 . 2534 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2535 the Network Configuration Protocol (NETCONF)", RFC 6020, 2536 DOI 10.17487/RFC6020, October 2010, 2537 . 2539 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2540 Verification of Domain-Based Application Service Identity 2541 within Internet Public Key Infrastructure Using X.509 2542 (PKIX) Certificates in the Context of Transport Layer 2543 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2544 2011, . 2546 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2547 and A. Bierman, Ed., "Network Configuration Protocol 2548 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2549 . 2551 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2552 "Recommendations for Secure Use of Transport Layer 2553 Security (TLS) and Datagram Transport Layer Security 2554 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2555 2015, . 2557 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2558 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2559 . 2561 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2562 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2563 . 2565 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2566 and R. Wilton, "Network Management Datastore Architecture 2567 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2568 . 2570 Appendix A. Change Log 2572 This section is to be removed before publishing as an RFC. 2574 A.1. I-D to 00 2576 * Removed groupings and notifications. 2578 * Added typedefs for identityrefs. 2580 * Added typedefs for other RFC 5280 structures. 2582 * Added typedefs for other RFC 5652 structures. 2584 * Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2586 A.2. 00 to 01 2588 * Moved groupings from the draft-ietf-netconf-keystore here. 2590 A.3. 01 to 02 2592 * Removed unwanted "mandatory" and "must" statements. 2594 * Added many new crypto algorithms (thanks Haiguang!) 2596 * Clarified in asymmetric-key-pair-with-certs-grouping, in 2597 certificates/certificate/name/description, that if the name MUST 2598 NOT match the name of a certificate that exists independently in 2599 , enabling certs installed by the manufacturer (e.g., 2600 an IDevID). 2602 A.4. 02 to 03 2604 * renamed base identity 'asymmetric-key-encryption-algorithm' to 2605 'asymmetric-key-algorithm'. 2607 * added new 'asymmetric-key-algorithm' identities for secp192r1, 2608 secp224r1, secp256r1, secp384r1, and secp521r1. 2610 * removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2611 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2612 aes-256-gcm, and mac-chacha20-poly1305. 2614 * for all -cbc and -ctr identities, renamed base identity 2615 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2617 * for all -ccm and -gcm identities, renamed base identity 2618 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2619 algorithm' and renamed the identity to remove the "enc-" prefix. 2621 * for all the 'signature-algorithm' based identities, renamed from 2622 'rsa-*' to 'rsassa-*'. 2624 * removed all of the "x509v3-" prefixed 'signature-algorithm' based 2625 identities. 2627 * added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2628 and 'rsaes-pkcs1-v1_5'. 2630 * renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2631 'symmetric-key-algorithm-ref'. 2633 * renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2634 'asymmetric-key-algorithm-ref'. 2636 * added typedef 'encryption-and-mac-algorithm-ref'. 2638 * Updated copyright date, boilerplate template, affiliation, and 2639 folding algorithm. 2641 A.5. 03 to 04 2643 * ran YANG module through formatter. 2645 A.6. 04 to 05 2647 * fixed broken symlink causing reformatted YANG module to not show. 2649 A.7. 05 to 06 2651 * Added NACM annotations. 2653 * Updated Security Considerations section. 2655 * Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2657 * Removed text from 'permanently-hidden' enum regarding such keys 2658 not being backed up or restored. 2660 * Updated the boilerplate text in module-level "description" 2661 statement to match copyeditor convention. 2663 * Added an explanation to the 'public-key-grouping' and 'asymmetric- 2664 key-pair-grouping' statements as for why the nodes are not 2665 mandatory (e.g., because they may exist only in . 2667 * Added 'must' expressions to the 'public-key-grouping' and 2668 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2669 are either all exist or do not all exist. 2671 * Added an explanation to the 'permanently-hidden' that the value 2672 cannot be configured directly by clients and servers MUST fail any 2673 attempt to do so. 2675 * Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2676 grouping' (the plural form of existing groupings). 2678 * Now states that keys created in by the *-hidden-key 2679 actions are bound to the lifetime of the parent 'config true' 2680 node, and that subsequent invocations of either action results in 2681 a failure. 2683 A.8. 06 to 07 2685 * Added clarifications that implementations SHOULD assert that 2686 configured certificates contain the matching public key. 2688 * Replaced the 'generate-hidden-key' and 'install-hidden-key' 2689 actions with special 'crypt-hash' -like input/output values. 2691 A.9. 07 to 08 2693 * Removed the 'generate-key and 'hidden-key' features. 2695 * Added grouping symmetric-key-grouping 2697 * Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2698 statement for the keystone module to augment into, as well as 2699 replacing the 'union' with leafs (having different NACM settings. 2701 A.10. 08 to 09 2703 * Converting algorithm from identities to enumerations. 2705 A.11. 09 to 10 2707 * All the below changes are to the algorithm enumerations defined in 2708 ietf-crypto-types. 2710 * Add in support for key exchange over x.25519 and x.448 based on 2711 RFC 8418. 2713 * Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2715 * Revise/add in enum of signature algorithm for x25519 and x448 2717 * Add in des3-cbc-sha1 for IPSec 2719 * Add in sha1-des3-kd for IPSec 2720 * Add in definit for rc4-hmac and rc4-hmac-exp. These two 2721 algorithms have been deprecated in RFC 8429. But some existing 2722 draft in i2nsf may still want to use them. 2724 * Add x25519 and x448 curve for asymmetric algorithms 2726 * Add signature algorithms ed25519, ed25519-cts, ed25519ph 2728 * add signature algorithms ed448, ed448ph 2730 * Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2732 A.12. 10 to 11 2734 * Added a "key-format" identity. 2736 * Added symmetric keys to the example in Section 2.2. 2738 A.13. 11 to 12 2740 * Removed all non-essential (to NC/RC) algorithm types. 2742 * Moved remaining algorithm types each into its own module. 2744 * Added a 'config false' "algorithms-supported" list to each of the 2745 algorithm-type modules. 2747 A.14. 12 to 13 2749 * Added the four features: "[encrypted-]one-[a]symmetric-key- 2750 format", each protecting a 'key-format' identity of the same name. 2752 * Added 'must' expressions asserting that the 'key-format' leaf 2753 exists whenever a non-hidden key is specified. 2755 * Improved the 'description' statements and added 'reference' 2756 statements for the 'key-format' identities. 2758 * Added a questionable forward reference to "encrypted-*" leafs in a 2759 couple 'when' expressions. 2761 * Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 2763 A.15. 13 to 14 2765 * Resolved the "FIXME: forward ref" issue by modulating 'must', 2766 'when', and 'mandatory' expressions. 2768 * Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' 2769 actions from ietf-keystore to ietf-crypto-types, now as RPCs. 2771 * Cleaned up various description statements and removed lingering 2772 FIXMEs. 2774 * Converted the "iana--algs" YANG modules to IANA 2775 registries with instructions for how to generate modules from the 2776 registries, whenever they may be updated. 2778 A.16. 14 to 15 2780 * Removed the IANA-maintained registries for symmetric, asymmetric, 2781 and hash algorithms. 2783 * Removed the "generate-symmetric-key" and "generate-asymmetric-key" 2784 RPCs. 2786 * Removed the "algorithm" node in the various symmetric and 2787 asymmetric key groupings. 2789 * Added 'typedef csr' and 'feature certificate-signing-request- 2790 generation'. 2792 * Refined a usage of "end-entity-cert-grouping" to make the "cert" 2793 node mandatory true. 2795 * Added a "Note to Reviewers" note to first page. 2797 A.17. 15 to 16 2799 * Updated draft title (refer to "Groupings" too). 2801 * Removed 'end-entity-certs-grouping' as it wasn't being used 2802 anywhere. 2804 * Removed 'trust-anchor-certs-grouping' as it was no longer being 2805 used after modifying 'local-or-truststore-certs-grouping' to use 2806 lists (not leaf-lists). 2808 * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. 2810 * Added "csr-info" typedef, to complement the existing "csr" 2811 typedef. 2813 * Added "ocsp-request" and "ocsp-response" typedefs, to complement 2814 the existing "crl" typedef. 2816 * Added "encrypted" cases to both symmetric-key-grouping and 2817 asymmetric-key-pair-grouping (Moved from Keystore draft). 2819 * Expanded "Data Model Overview section(s) [remove "wall" of tree 2820 diagrams]. 2822 * Updated the Security Considerations section. 2824 A.18. 16 to 17 2826 * [Re]-added a "Strength of Keys Configured" Security Consideration 2828 * Prefixed "cleartext-" in the "key" and "private-key" node names. 2830 A.19. 17 to 18 2832 * Fixed issues found by the SecDir review of the "keystore" draft. 2834 * Added "password-grouping", discussed during the IETF 108 session. 2836 A.20. 18 to 19 2838 * Added a "Unconstrained Public Key Usage" Security Consideration to 2839 address concern raised by SecDir of the 'truststore' draft. 2841 * Added a "Unconstrained Private Key Usage" Security Consideration 2842 to address concern raised by SecDir of the 'truststore' draft. 2844 * Changed the encryption strategy, after conferring with Russ 2845 Housley. 2847 * Added a "password-grouping" example to the "crypto-types-usage" 2848 example. 2850 * Added an "Encrypting Passwords" section to Security Consideration. 2852 * Addressed other comments raised by YANG Doctor. 2854 A.21. 19 to 20 2856 * Nits found via YANG Doctors reviews. 2858 * Aligned modules with `pyang -f` formatting. 2860 A.22. 20 to 21 2862 * Replaced "base64encodedvalue==" with "BASE64VALUE=". 2864 * Accommodated SecDir review by Valery Smyslov. 2866 Acknowledgements 2868 The authors would like to thank for following for lively discussions 2869 on list and in the halls (ordered by first name): Balazs Kovacs, Eric 2870 Voit, Juergen Schoenwaelder, Liang Xia, Martin Bjoerklund, Nick 2871 Hancock, Rich Salz, Rob Wilton, Russ Housley, Sandra Murphy, Tom 2872 Petch, Valery Smyslov, and Wang Haiguang. 2874 Author's Address 2876 Kent Watsen 2877 Watsen Networks 2879 Email: kent+ietf@watsen.net