idnits 2.17.1 draft-ietf-netconf-crypto-types-14.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 164 has weird spacing: '...gorithm ias...' == Line 178 has weird spacing: '...gorithm isa...' == Line 198 has weird spacing: '...-format ide...' == Line 213 has weird spacing: '...on-date yan...' == Line 217 has weird spacing: '...on-date yan...' == (7 more instances...) -- The document date (March 8, 2020) is 1503 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.X690.2015' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 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 H. Wang 5 Expires: September 9, 2020 Huawei 6 March 8, 2020 8 Common YANG Data Types for Cryptography 9 draft-ietf-netconf-crypto-types-14 11 Abstract 13 This document primarily defines a YANG module for identities, 14 typedefs, groupings, and RPCs useful to cryptographic applications. 15 This draft additionally defines a new IANA registry for cryptographic 16 primitives, modifies existing SSH and TLS registries, and defines a 17 process enabling IANA to automatically generate three new YANG 18 modules from the new cryptographic primitives registry. 20 Editorial Note (To be removed by RFC Editor) 22 This draft contains many placeholder values that need to be replaced 23 with finalized values at the time of publication. This note 24 summarizes all of the substitutions that are needed. No other RFC 25 Editor instructions are specified elsewhere in this document. 27 Artwork in this document contains shorthand references to drafts in 28 progress. Please apply the following replacements: 30 o "AAAA" --> the assigned RFC value for this draft 32 Artwork in this document contains placeholder values for the date of 33 publication of this draft. Please apply the following replacement: 35 o "2020-03-08" --> the publication date of this draft 37 The following Appendix section is to be removed prior to publication: 39 o Appendix B. Change Log 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 9, 2020. 58 Copyright Notice 60 Copyright (c) 2020 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. The Crypto Types Module . . . . . . . . . . . . . . . . . . . 4 77 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 78 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 79 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26 80 3. Security Considerations . . . . . . . . . . . . . . . . . . . 31 81 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 31 82 3.2. Access to Data Nodes . . . . . . . . . . . . . . . . . . 32 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 84 4.1. Create the "Cryptographic Primitives" Registry . . . . . 33 85 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 33 86 4.1.2. The "Symmetric Key Algorithms" Sub-Registry . . . . . 35 87 4.1.3. The "Asymmetric Key Algorithms" Sub-Registry . . . . 36 88 4.1.4. The "Hash Algorithms" Sub-Registry . . . . . . . . . 38 89 4.2. IANA-maintained YANG Modules . . . . . . . . . . . . . . 40 90 4.3. Update the "Secure Shell (SSH) Protocol Parameters" 91 Registry . . . . . . . . . . . . . . . . . . . . . . . . 40 92 4.3.1. Common Update to Specified Sub-Registries . . . . . . 40 93 4.3.2. The "Public Key Algorithm Names" Sub-Registry . . . . 41 94 4.4. Update the "Transport Layer Security (TLS) Parameters" 95 Registry . . . . . . . . . . . . . . . . . . . . . . . . 41 97 4.4.1. Common Update to Specified Sub-Registries . . . . . . 42 98 4.4.2. The "TLS Supported Groups" Sub-Registry . . . . . . . 42 99 4.4.3. The "TLS SignatureAlgorithm" Sub-Registry . . . . . . 43 100 4.4.4. The "TLS SignatureScheme" Sub-Registry . . . . . . . 44 101 4.5. Update the "IETF XML" Registry . . . . . . . . . . . . . 44 102 4.6. Update the "YANG Module Names" Registry . . . . . . . . . 45 103 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 104 5.1. Normative References . . . . . . . . . . . . . . . . . . 46 105 5.2. Informative References . . . . . . . . . . . . . . . . . 47 106 Appendix A. Sample IANA Modules . . . . . . . . . . . . . . . . 49 107 A.1. The Symmetric Algorithms Module . . . . . . . . . . . . . 49 108 A.2. The Asymmetric Algorithms Module . . . . . . . . . . . . 52 109 A.3. The Hash Algorithms Module . . . . . . . . . . . . . . . 57 110 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 60 111 B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 60 112 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 60 113 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 60 114 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 61 115 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 62 116 B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 62 117 B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 62 118 B.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 62 119 B.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 63 120 B.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 63 121 B.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 63 122 B.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 64 123 B.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 64 124 B.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 64 125 B.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 64 126 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 65 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 129 1. Introduction 131 This document primarily defines a YANG 1.1 [RFC7950] module for 132 identities, typedefs, groupings, and RPCs useful to cryptographic 133 applications. 135 This draft additionally defines a new IANA registry called 136 "Cryptographic Primitives", and defines a process enabling IANA to 137 automatically generate three new YANG modules ("iana-hash-algs", 138 "iana-symmetric-key-algs", and "iana-asymmetric-key-algs") from the 139 new cryptographic primitives registry. 141 Lastly, the draft also modifies existing SSH and TLS registries, 142 adding a new column called "Primitives" to specific sub-registries 143 identifying which primitives are used by that registration. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. The Crypto Types Module 153 2.1. Tree Diagram 155 This section provides a tree diagram [RFC8340] for the "ietf-crypto- 156 types" module. Only "grouping" statements are represented, as tree 157 diagrams have no means to represent identities or typedefs. 159 module: ietf-crypto-types 161 rpcs: 162 +---x generate-asymmetric-key {asymmetric-key-generation}? 163 | +---w input 164 | | +---w algorithm iasa:asymmetric-algorithm-type 165 | +--ro output 166 | +--ro algorithm 167 | | iasa:asymmetric-algorithm-type 168 | +--ro public-key-format identityref 169 | +--ro public-key binary 170 | +--ro private-key-format? identityref 171 | +--ro (private-key-type) 172 | +--:(private-key) 173 | | +--ro private-key? binary 174 | +--:(hidden-private-key) 175 | +--ro hidden-private-key? empty 176 +---x generate-symmetric-key {symmetric-key-generation}? 177 +---w input 178 | +---w algorithm isa:symmetric-algorithm-type 179 +--ro output 180 +--ro algorithm isa:symmetric-algorithm-type 181 +--ro key-format? identityref 182 +--ro (key-type) 183 +--:(key) 184 | +--ro key? binary 185 +--:(hidden-key) 186 +--ro hidden-key? empty 188 grouping symmetric-key-grouping 189 +-- algorithm isa:symmetric-algorithm-type 190 +-- key-format? identityref 191 +-- (key-type) 192 +--:(key) 193 | +-- key? binary 194 +--:(hidden-key) 195 +-- hidden-key? empty 196 grouping public-key-grouping 197 +-- algorithm iasa:asymmetric-algorithm-type 198 +-- public-key-format identityref 199 +-- public-key binary 200 grouping asymmetric-key-pair-grouping 201 +-- algorithm iasa:asymmetric-algorithm-type 202 +-- public-key-format identityref 203 +-- public-key binary 204 +-- private-key-format? identityref 205 +-- (private-key-type) 206 +--:(private-key) 207 | +-- private-key? binary 208 +--:(hidden-private-key) 209 +-- hidden-private-key? empty 210 grouping trust-anchor-cert-grouping 211 +-- cert? trust-anchor-cert-cms 212 +---n certificate-expiration 213 +-- expiration-date yang:date-and-time 214 grouping trust-anchor-certs-grouping 215 +-- cert* trust-anchor-cert-cms 216 +---n certificate-expiration 217 +-- expiration-date yang:date-and-time 218 grouping end-entity-cert-grouping 219 +-- cert? end-entity-cert-cms 220 +---n certificate-expiration 221 +-- expiration-date yang:date-and-time 222 grouping end-entity-certs-grouping 223 +-- cert* end-entity-cert-cms 224 +---n certificate-expiration 225 +-- expiration-date yang:date-and-time 226 grouping asymmetric-key-pair-with-cert-grouping 227 +-- algorithm 228 | iasa:asymmetric-algorithm-type 229 +-- public-key-format identityref 230 +-- public-key binary 231 +-- private-key-format? identityref 232 +-- (private-key-type) 233 | +--:(private-key) 234 | | +-- private-key? binary 235 | +--:(hidden-private-key) 236 | +-- hidden-private-key? empty 237 +-- cert? end-entity-cert-cms 238 +---n certificate-expiration 239 | +-- expiration-date yang:date-and-time 240 +---x generate-certificate-signing-request 241 +---w input 242 | +---w subject binary 243 | +---w attributes? binary 244 +--ro output 245 +--ro certificate-signing-request binary 246 grouping asymmetric-key-pair-with-certs-grouping 247 +-- algorithm 248 | iasa:asymmetric-algorithm-type 249 +-- public-key-format identityref 250 +-- public-key binary 251 +-- private-key-format? identityref 252 +-- (private-key-type) 253 | +--:(private-key) 254 | | +-- private-key? binary 255 | +--:(hidden-private-key) 256 | +-- hidden-private-key? empty 257 +-- certificates 258 | +-- certificate* [name] 259 | +-- name? string 260 | +-- cert? end-entity-cert-cms 261 | +---n certificate-expiration 262 | +-- expiration-date yang:date-and-time 263 +---x generate-certificate-signing-request 264 +---w input 265 | +---w subject binary 266 | +---w attributes? binary 267 +--ro output 268 +--ro certificate-signing-request binary 270 2.2. YANG Module 272 This module has normative references to [RFC2119], [RFC2986], 273 [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], 274 [RFC6031], [RFC6125], [RFC6991], [RFC8174], [RFC8341], and 275 [ITU.X690.2015]. 277 file "ietf-crypto-types@2020-03-08.yang" 279 module ietf-crypto-types { 280 yang-version 1.1; 281 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 282 prefix ct; 284 import ietf-yang-types { 285 prefix yang; 286 reference 287 "RFC 6991: Common YANG Data Types"; 288 } 289 import ietf-netconf-acm { 290 prefix nacm; 291 reference 292 "RFC 8341: Network Configuration Access Control Model"; 293 } 295 //import iana-hash-algs { 296 // prefix iha; 297 // reference 298 // "RFC AAAA: Common YANG Data Types for Cryptography"; 299 //} 301 import iana-symmetric-algs { 302 prefix isa; 303 reference 304 "RFC AAAA: Common YANG Data Types for Cryptography"; 305 } 307 import iana-asymmetric-algs { 308 prefix iasa; 309 reference 310 "RFC AAAA: Common YANG Data Types for Cryptography"; 311 } 313 organization 314 "IETF NETCONF (Network Configuration) Working Group"; 316 contact 317 "WG Web: 318 WG List: 319 Author: Kent Watsen 320 Author: Wang Haiguang "; 322 description 323 "This module defines common YANG types for cryptographic 324 applications. 326 Copyright (c) 2019 IETF Trust and the persons identified 327 as authors of the code. All rights reserved. 329 Redistribution and use in source and binary forms, with 330 or without modification, is permitted pursuant to, and 331 subject to the license terms contained in, the Simplified 332 BSD License set forth in Section 4.c of the IETF Trust's 333 Legal Provisions Relating to IETF Documents 334 (https://trustee.ietf.org/license-info). 336 This version of this YANG module is part of RFC AAAA 337 (https://www.rfc-editor.org/info/rfcAAAA); see the RFC 338 itself for full legal notices. 340 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 341 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 342 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 343 are to be interpreted as described in BCP 14 (RFC 2119) 344 (RFC 8174) when, and only when, they appear in all 345 capitals, as shown here."; 347 revision 2020-03-08 { 348 description 349 "Initial version"; 350 reference 351 "RFC AAAA: Common YANG Data Types for Cryptography"; 352 } 354 /****************/ 355 /* Features */ 356 /****************/ 358 feature one-asymmetric-key-format { 359 description 360 "Indicates that the server supports the 361 'one-asymmetric-key-format' identity."; 362 } 364 feature one-symmetric-key-format { 365 description 366 "Indicates that the server supports the 367 'one-symmetric-key-format' identity."; 368 } 370 feature encrypted-one-symmetric-key-format { 371 description 372 "Indicates that the server supports the 373 'encrypted-one-symmetric-key-format' identity."; 374 } 376 feature encrypted-one-asymmetric-key-format { 377 description 378 "Indicates that the server supports the 379 'encrypted-one-asymmetric-key-format' identity."; 380 } 382 feature symmetric-key-generation { 383 description 384 "Indicates that the server implements the 'generate- 385 symmetric-key' RPC."; 386 } 388 feature asymmetric-key-generation { 389 description 390 "Indicates that the server implements the 'generate- 391 asymmetric-key' RPC."; 392 } 394 /*************************************************/ 395 /* Base Identities for Key Format Structures */ 396 /*************************************************/ 398 identity public-key-format { 399 description "Base key-format identity for public keys."; 400 } 402 identity private-key-format { 403 description "Base key-format identity for private keys."; 404 } 406 identity symmetric-key-format { 407 description "Base key-format identity for symmetric keys."; 408 } 410 /****************************************************/ 411 /* Identities for Private Key Format Structures */ 412 /****************************************************/ 414 identity rsa-private-key-format { 415 base "private-key-format"; 416 description 417 "Indicates that the private key value is encoded 418 as an RSAPrivateKey (from RFC 3447)."; 419 reference 420 "RFC 3447: PKCS #1: RSA Cryptography 421 Specifications Version 2.2"; 422 } 424 identity ec-private-key-format { 425 base "private-key-format"; 426 description 427 "Indicates that the private key value is encoded 428 as an ECPrivateKey (from RFC 5915)"; 429 reference 430 "RFC 5915: Elliptic Curve Private Key Structure"; 431 } 433 identity one-asymmetric-key-format { 434 if-feature "one-asymmetric-key-format"; 435 base "private-key-format"; 436 description 437 "Indicates that the private key value is a CMS 438 OneAsymmetricKey structure, as defined in RFC 5958, 439 encoded using ASN.1 distinguished encoding rules 440 (DER), as specified in ITU-T X.690."; 441 reference 442 "RFC 5958: Asymmetric Key Packages 443 ITU-T X.690: 444 Information technology - ASN.1 encoding rules: 445 Specification of Basic Encoding Rules (BER), 446 Canonical Encoding Rules (CER) and Distinguished 447 Encoding Rules (DER)."; 448 } 450 identity encrypted-one-asymmetric-key-format { 451 if-feature "encrypted-one-asymmetric-key-format"; 452 base "private-key-format"; 453 description 454 "Indicates that the private key value is a CMS EnvelopedData 455 structure, per Section 8 in RFC 5652, containing a 456 OneAsymmetricKey structure, as defined in RFC 5958, 457 encoded using ASN.1 distinguished encoding rules (DER), 458 as specified in ITU-T X.690."; 459 reference 460 "RFC 5652: Cryptographic Message Syntax (CMS) 461 RFC 5958: Asymmetric Key Packages 462 ITU-T X.690: 463 Information technology - ASN.1 encoding rules: 464 Specification of Basic Encoding Rules (BER), 465 Canonical Encoding Rules (CER) and Distinguished 466 Encoding Rules (DER)."; 467 } 469 /***************************************************/ 470 /* Identities for Public Key Format Structures */ 471 /***************************************************/ 473 identity ssh-public-key-format { 474 base "public-key-format"; 475 description 476 "Indicates that the public key value is an SSH public key, 477 as specified by RFC 4253, Section 6.6, i.e.: 479 string certificate or public key format 480 identifier 481 byte[n] key/certificate data."; 482 reference 483 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 484 } 486 identity subject-public-key-info-format { 487 base "public-key-format"; 488 description 489 "Indicates that the public key value is a SubjectPublicKeyInfo 490 structure, as described in RFC 5280 encoded using ASN.1 491 distinguished encoding rules (DER), as specified in 492 ITU-T X.690."; 493 reference 494 "RFC 5280: 495 Internet X.509 Public Key Infrastructure Certificate 496 and Certificate Revocation List (CRL) Profile 497 ITU-T X.690: 498 Information technology - ASN.1 encoding rules: 499 Specification of Basic Encoding Rules (BER), 500 Canonical Encoding Rules (CER) and Distinguished 501 Encoding Rules (DER)."; 502 } 504 /******************************************************/ 505 /* Identities for Symmetric Key Format Structures */ 506 /******************************************************/ 508 identity octet-string-key-format { 509 base "symmetric-key-format"; 510 description 511 "Indicates that the key is encoded as a raw octet string. 512 The length of the octet string MUST be appropriate for 513 the associated algorithm's block size."; 514 } 516 identity one-symmetric-key-format { 517 if-feature "one-symmetric-key-format"; 518 base "symmetric-key-format"; 519 description 520 "Indicates that the private key value is a CMS 521 OneSymmetricKey structure, as defined in RFC 6031, 522 encoded using ASN.1 distinguished encoding rules 523 (DER), as specified in ITU-T X.690."; 525 reference 526 "RFC 6031: Cryptographic Message Syntax (CMS) 527 Symmetric Key Package Content Type 528 ITU-T X.690: 529 Information technology - ASN.1 encoding rules: 530 Specification of Basic Encoding Rules (BER), 531 Canonical Encoding Rules (CER) and Distinguished 532 Encoding Rules (DER)."; 533 } 535 identity encrypted-one-symmetric-key-format { 536 if-feature "encrypted-one-symmetric-key-format"; 537 base "symmetric-key-format"; 538 description 539 "Indicates that the private key value is a CMS 540 EnvelopedData structure, per Section 8 in RFC 5652, 541 containing a OneSymmetricKey structure, as defined 542 in RFC 6031, encoded using ASN.1 distinguished 543 encoding rules (DER), as specified in ITU-T X.690."; 544 reference 545 "RFC 5652: Cryptographic Message Syntax (CMS) 546 RFC 6031: Cryptographic Message Syntax (CMS) 547 Symmetric Key Package Content Type 548 ITU-T X.690: 549 Information technology - ASN.1 encoding rules: 550 Specification of Basic Encoding Rules (BER), 551 Canonical Encoding Rules (CER) and Distinguished 552 Encoding Rules (DER)."; 553 } 555 /***************************************************/ 556 /* Typedefs for ASN.1 structures from RFC 5280 */ 557 /***************************************************/ 559 typedef x509 { 560 type binary; 561 description 562 "A Certificate structure, as specified in RFC 5280, 563 encoded using ASN.1 distinguished encoding rules (DER), 564 as specified in ITU-T X.690."; 565 reference 566 "RFC 5280: 567 Internet X.509 Public Key Infrastructure Certificate 568 and Certificate Revocation List (CRL) Profile 569 ITU-T X.690: 570 Information technology - ASN.1 encoding rules: 571 Specification of Basic Encoding Rules (BER), 572 Canonical Encoding Rules (CER) and Distinguished 573 Encoding Rules (DER)."; 574 } 576 typedef crl { 577 type binary; 578 description 579 "A CertificateList structure, as specified in RFC 5280, 580 encoded using ASN.1 distinguished encoding rules (DER), 581 as specified in ITU-T X.690."; 582 reference 583 "RFC 5280: 584 Internet X.509 Public Key Infrastructure Certificate 585 and Certificate Revocation List (CRL) Profile 586 ITU-T X.690: 587 Information technology - ASN.1 encoding rules: 588 Specification of Basic Encoding Rules (BER), 589 Canonical Encoding Rules (CER) and Distinguished 590 Encoding Rules (DER)."; 591 } 593 /***********************************************/ 594 /* Typedefs for ASN.1 structures from 5652 */ 595 /***********************************************/ 597 typedef cms { 598 type binary; 599 description 600 "A ContentInfo structure, as specified in RFC 5652, 601 encoded using ASN.1 distinguished encoding rules (DER), 602 as specified in ITU-T X.690."; 603 reference 604 "RFC 5652: 605 Cryptographic Message Syntax (CMS) 606 ITU-T X.690: 607 Information technology - ASN.1 encoding rules: 608 Specification of Basic Encoding Rules (BER), 609 Canonical Encoding Rules (CER) and Distinguished 610 Encoding Rules (DER)."; 611 } 613 typedef data-content-cms { 614 type cms; 615 description 616 "A CMS structure whose top-most content type MUST be the 617 data content type, as described by Section 4 in RFC 5652."; 618 reference 619 "RFC 5652: Cryptographic Message Syntax (CMS)"; 620 } 622 typedef signed-data-cms { 623 type cms; 624 description 625 "A CMS structure whose top-most content type MUST be the 626 signed-data content type, as described by Section 5 in 627 RFC 5652."; 628 reference 629 "RFC 5652: Cryptographic Message Syntax (CMS)"; 630 } 632 typedef enveloped-data-cms { 633 type cms; 634 description 635 "A CMS structure whose top-most content type MUST be the 636 enveloped-data content type, as described by Section 6 637 in RFC 5652."; 638 reference 639 "RFC 5652: Cryptographic Message Syntax (CMS)"; 640 } 642 typedef digested-data-cms { 643 type cms; 644 description 645 "A CMS structure whose top-most content type MUST be the 646 digested-data content type, as described by Section 7 647 in RFC 5652."; 648 reference 649 "RFC 5652: Cryptographic Message Syntax (CMS)"; 650 } 652 typedef encrypted-data-cms { 653 type cms; 654 description 655 "A CMS structure whose top-most content type MUST be the 656 encrypted-data content type, as described by Section 8 657 in RFC 5652."; 658 reference 659 "RFC 5652: Cryptographic Message Syntax (CMS)"; 660 } 662 typedef authenticated-data-cms { 663 type cms; 664 description 665 "A CMS structure whose top-most content type MUST be the 666 authenticated-data content type, as described by Section 9 667 in RFC 5652."; 668 reference 669 "RFC 5652: Cryptographic Message Syntax (CMS)"; 670 } 672 /*********************************************************/ 673 /* Typedefs for ASN.1 structures related to RFC 5280 */ 674 /*********************************************************/ 676 typedef trust-anchor-cert-x509 { 677 type x509; 678 description 679 "A Certificate structure that MUST encode a self-signed 680 root certificate."; 681 } 683 typedef end-entity-cert-x509 { 684 type x509; 685 description 686 "A Certificate structure that MUST encode a certificate 687 that is neither self-signed nor having Basic constraint 688 CA true."; 689 } 691 /*********************************************************/ 692 /* Typedefs for ASN.1 structures related to RFC 5652 */ 693 /*********************************************************/ 695 typedef trust-anchor-cert-cms { 696 type signed-data-cms; 697 description 698 "A CMS SignedData structure that MUST contain the chain of 699 X.509 certificates needed to authenticate the certificate 700 presented by a client or end-entity. 702 The CMS MUST contain only a single chain of certificates. 703 The client or end-entity certificate MUST only authenticate 704 to last intermediate CA certificate listed in the chain. 706 In all cases, the chain MUST include a self-signed root 707 certificate. In the case where the root certificate is 708 itself the issuer of the client or end-entity certificate, 709 only one certificate is present. 711 This CMS structure MAY (as applicable where this type is 712 used) also contain suitably fresh (as defined by local 713 policy) revocation objects with which the device can 714 verify the revocation status of the certificates. 716 This CMS encodes the degenerate form of the SignedData 717 structure that is commonly used to disseminate X.509 718 certificates and revocation objects (RFC 5280)."; 719 reference 720 "RFC 5280: 721 Internet X.509 Public Key Infrastructure Certificate 722 and Certificate Revocation List (CRL) Profile."; 723 } 725 typedef end-entity-cert-cms { 726 type signed-data-cms; 727 description 728 "A CMS SignedData structure that MUST contain the end 729 entity certificate itself, and MAY contain any number 730 of intermediate certificates leading up to a trust 731 anchor certificate. The trust anchor certificate 732 MAY be included as well. 734 The CMS MUST contain a single end entity certificate. 735 The CMS MUST NOT contain any spurious certificates. 737 This CMS structure MAY (as applicable where this type is 738 used) also contain suitably fresh (as defined by local 739 policy) revocation objects with which the device can 740 verify the revocation status of the certificates. 742 This CMS encodes the degenerate form of the SignedData 743 structure that is commonly used to disseminate X.509 744 certificates and revocation objects (RFC 5280)."; 745 reference 746 "RFC 5280: 747 Internet X.509 Public Key Infrastructure Certificate 748 and Certificate Revocation List (CRL) Profile."; 749 } 751 /**********************************************/ 752 /* Groupings for keys and/or certificates */ 753 /**********************************************/ 755 grouping symmetric-key-grouping { 756 description 757 "A symmetric key and algorithm."; 758 leaf algorithm { 759 type isa:symmetric-algorithm-type; 760 mandatory true; 761 description 762 "The algorithm to be used when generating the key."; 763 reference 764 "RFC AAAA: Common YANG Data Types for Cryptography"; 765 } 766 leaf key-format { 767 nacm:default-deny-write; 768 type identityref { 769 base symmetric-key-format; 770 } 771 description "Identifies the symmetric key's format."; 772 } 773 choice key-type { 774 mandatory true; 775 description 776 "Choice between key types."; 777 leaf key { 778 nacm:default-deny-all; 779 type binary; 780 must "../key-format"; 781 description 782 "The binary value of the key. The interpretation of 783 the value is defined by the 'key-format' field."; 784 } 785 leaf hidden-key { 786 nacm:default-deny-write; 787 type empty; 788 must "not(../key-format)"; 789 description 790 "A permanently hidden key. How such keys are created 791 is outside the scope of this module."; 792 } 793 } 794 } 796 grouping public-key-grouping { 797 description 798 "A public key and its associated algorithm."; 799 leaf algorithm { 800 nacm:default-deny-write; 801 type iasa:asymmetric-algorithm-type; 802 mandatory true; 803 description 804 "Identifies the key's algorithm."; 805 reference 806 "RFC AAAA: Common YANG Data Types for Cryptography"; 807 } 808 leaf public-key-format { 809 nacm:default-deny-write; 810 type identityref { 811 base public-key-format; 812 } 813 mandatory true; 814 description "Identifies the key's format."; 815 } 816 leaf public-key { 817 nacm:default-deny-write; 818 type binary; 819 mandatory true; 820 description 821 "The binary value of the public key. The interpretation 822 of the value is defined by 'public-key-format' field."; 823 } 824 } 826 grouping asymmetric-key-pair-grouping { 827 description 828 "A private key and its associated public key and algorithm."; 829 uses public-key-grouping; 830 leaf private-key-format { 831 nacm:default-deny-write; 832 type identityref { 833 base private-key-format; 834 } 835 description "Identifies the key's format."; 836 } 837 choice private-key-type { 838 mandatory true; 839 description 840 "Choice between key types."; 841 leaf private-key { 842 nacm:default-deny-all; 843 type binary; 844 must "../private-key-format"; 845 description 846 "The value of the binary key The key's value is 847 interpreted by the 'private-key-format' field."; 848 } 849 leaf hidden-private-key { 850 nacm:default-deny-write; 851 type empty; 852 must "not(../private-key-format)"; 853 description 854 "A permanently hidden key. How such keys are created 855 is outside the scope of this module."; 857 } 858 } 859 } 861 grouping trust-anchor-cert-grouping { 862 description 863 "A trust anchor certificate, and a notification for when 864 it is about to (or already has) expire."; 865 leaf cert { 866 nacm:default-deny-write; 867 type trust-anchor-cert-cms; 868 description 869 "The binary certificate data for this certificate."; 870 reference 871 "RFC YYYY: Common YANG Data Types for Cryptography"; 872 } 873 notification certificate-expiration { 874 description 875 "A notification indicating that the configured certificate 876 is either about to expire or has already expired. When to 877 send notifications is an implementation specific decision, 878 but it is RECOMMENDED that a notification be sent once a 879 month for 3 months, then once a week for four weeks, and 880 then once a day thereafter until the issue is resolved."; 881 leaf expiration-date { 882 type yang:date-and-time; 883 mandatory true; 884 description 885 "Identifies the expiration date on the certificate."; 886 } 887 } 888 } 890 grouping trust-anchor-certs-grouping { 891 description 892 "A list of trust anchor certificates, and a notification 893 for when one is about to (or already has) expire."; 894 leaf-list cert { 895 nacm:default-deny-write; 896 type trust-anchor-cert-cms; 897 description 898 "The binary certificate data for this certificate."; 899 reference 900 "RFC YYYY: Common YANG Data Types for Cryptography"; 901 } 902 notification certificate-expiration { 903 description 904 "A notification indicating that the configured certificate 905 is either about to expire or has already expired. When to 906 send notifications is an implementation specific decision, 907 but it is RECOMMENDED that a notification be sent once a 908 month for 3 months, then once a week for four weeks, and 909 then once a day thereafter until the issue is resolved."; 910 leaf expiration-date { 911 type yang:date-and-time; 912 mandatory true; 913 description 914 "Identifies the expiration date on the certificate."; 915 } 916 } 917 } 919 grouping end-entity-cert-grouping { 920 description 921 "An end entity certificate, and a notification for when 922 it is about to (or already has) expire. Implementations 923 SHOULD assert that, where used, the end entity certificate 924 contains the expected public key."; 925 leaf cert { 926 nacm:default-deny-write; 927 type end-entity-cert-cms; 928 description 929 "The binary certificate data for this certificate."; 930 reference 931 "RFC YYYY: Common YANG Data Types for Cryptography"; 932 } 933 notification certificate-expiration { 934 description 935 "A notification indicating that the configured certificate 936 is either about to expire or has already expired. When to 937 send notifications is an implementation specific decision, 938 but it is RECOMMENDED that a notification be sent once a 939 month for 3 months, then once a week for four weeks, and 940 then once a day thereafter until the issue is resolved."; 941 leaf expiration-date { 942 type yang:date-and-time; 943 mandatory true; 944 description 945 "Identifies the expiration date on the certificate."; 946 } 947 } 948 } 950 grouping end-entity-certs-grouping { 951 description 952 "A list of end entity certificates, and a notification for 953 when one is about to (or already has) expire."; 954 leaf-list cert { 955 nacm:default-deny-write; 956 type end-entity-cert-cms; 957 description 958 "The binary certificate data for this certificate."; 959 reference 960 "RFC YYYY: Common YANG Data Types for Cryptography"; 961 } 962 notification certificate-expiration { 963 description 964 "A notification indicating that the configured certificate 965 is either about to expire or has already expired. When to 966 send notifications is an implementation specific decision, 967 but it is RECOMMENDED that a notification be sent once a 968 month for 3 months, then once a week for four weeks, and 969 then once a day thereafter until the issue is resolved."; 970 leaf expiration-date { 971 type yang:date-and-time; 972 mandatory true; 973 description 974 "Identifies the expiration date on the certificate."; 975 } 976 } 977 } 979 grouping asymmetric-key-pair-with-cert-grouping { 980 description 981 "A private/public key pair and an associated certificate. 982 Implementations SHOULD assert that certificates contain 983 the matching public key."; 984 uses asymmetric-key-pair-grouping; 985 uses end-entity-cert-grouping; 986 action generate-certificate-signing-request { 987 nacm:default-deny-all; 988 description 989 "Generates a certificate signing request structure for 990 the associated asymmetric key using the passed subject 991 and attribute values. The specified assertions need 992 to be appropriate for the certificate's use. For 993 example, an entity certificate for a TLS server 994 SHOULD have values that enable clients to satisfy 995 RFC 6125 processing."; 996 reference 997 "RFC 6125: 998 Representation and Verification of Domain-Based 999 Application Service Identity within Internet Public Key 1000 Infrastructure Using X.509 (PKIX) Certificates in the 1001 Context of Transport Layer Security (TLS)"; 1002 input { 1003 leaf subject { 1004 type binary; 1005 mandatory true; 1006 description 1007 "The 'subject' field per the CertificationRequestInfo 1008 structure as specified by RFC 2986, Section 4.1 1009 encoded using the ASN.1 distinguished encoding 1010 rules (DER), as specified in ITU-T X.690."; 1011 reference 1012 "RFC 2986: PKCS #10: Certification Request Syntax 1013 Specification Version 1.7. 1014 ITU-T X.690: 1015 Information technology - ASN.1 encoding rules: 1016 Specification of Basic Encoding Rules (BER), 1017 Canonical Encoding Rules (CER) and Distinguished 1018 Encoding Rules (DER)."; 1019 } 1020 leaf attributes { 1021 type binary; 1022 description 1023 "The 'attributes' field from the structure 1024 CertificationRequestInfo as specified by RFC 2986, 1025 Section 4.1 encoded using the ASN.1 distinguished 1026 encoding rules (DER), as specified in ITU-T X.690."; 1027 reference 1028 "RFC 2986: PKCS #10: Certification Request Syntax 1029 Specification Version 1.7. 1030 ITU-T X.690: 1031 Information technology - ASN.1 encoding rules: 1032 Specification of Basic Encoding Rules (BER), 1033 Canonical Encoding Rules (CER) and Distinguished 1034 Encoding Rules (DER)."; 1035 } 1036 } 1037 output { 1038 leaf certificate-signing-request { 1039 type binary; 1040 mandatory true; 1041 description 1042 "A CertificationRequest structure as specified by 1043 RFC 2986, Section 4.2 encoded using the ASN.1 1044 distinguished encoding rules (DER), as specified 1045 in ITU-T X.690."; 1046 reference 1047 "RFC 2986: PKCS #10: Certification Request Syntax 1048 Specification Version 1.7. 1050 ITU-T X.690: 1051 Information technology - ASN.1 encoding rules: 1052 Specification of Basic Encoding Rules (BER), 1053 Canonical Encoding Rules (CER) and Distinguished 1054 Encoding Rules (DER)."; 1055 } 1056 } 1057 } // generate-certificate-signing-request 1058 } // asymmetric-key-pair-with-cert-grouping 1060 grouping asymmetric-key-pair-with-certs-grouping { 1061 description 1062 "A private/public key pair and associated certificates. 1063 Implementations SHOULD assert that certificates contain 1064 the matching public key."; 1065 uses asymmetric-key-pair-grouping; 1066 container certificates { 1067 nacm:default-deny-write; 1068 description 1069 "Certificates associated with this asymmetric key. 1070 More than one certificate supports, for instance, 1071 a TPM-protected asymmetric key that has both IDevID 1072 and LDevID certificates associated."; 1073 list certificate { 1074 key "name"; 1075 description 1076 "A certificate for this asymmetric key."; 1077 leaf name { 1078 type string; 1079 description 1080 "An arbitrary name for the certificate. If the name 1081 matches the name of a certificate that exists 1082 independently in (i.e., an IDevID), 1083 then the 'cert' node MUST NOT be configured."; 1084 } 1085 uses end-entity-cert-grouping; 1086 } 1087 } // certificates 1088 action generate-certificate-signing-request { 1089 nacm:default-deny-all; 1090 description 1091 "Generates a certificate signing request structure for 1092 the associated asymmetric key using the passed subject 1093 and attribute values. The specified assertions need 1094 to be appropriate for the certificate's use. For 1095 example, an entity certificate for a TLS server 1096 SHOULD have values that enable clients to satisfy 1097 RFC 6125 processing."; 1099 reference 1100 "RFC 6125: 1101 Representation and Verification of Domain-Based 1102 Application Service Identity within Internet Public Key 1103 Infrastructure Using X.509 (PKIX) Certificates in the 1104 Context of Transport Layer Security (TLS)"; 1105 input { 1106 leaf subject { 1107 type binary; 1108 mandatory true; 1109 description 1110 "The 'subject' field per the CertificationRequestInfo 1111 structure as specified by RFC 2986, Section 4.1 1112 encoded using the ASN.1 distinguished encoding 1113 rules (DER), as specified in ITU-T X.690."; 1114 reference 1115 "RFC 2986: PKCS #10: Certification Request Syntax 1116 Specification Version 1.7. 1117 ITU-T X.690: 1118 Information technology - ASN.1 encoding rules: 1119 Specification of Basic Encoding Rules (BER), 1120 Canonical Encoding Rules (CER) and Distinguished 1121 Encoding Rules (DER)."; 1122 } 1123 leaf attributes { 1124 type binary; 1125 description 1126 "The 'attributes' field from the structure 1127 CertificationRequestInfo as specified by RFC 2986, 1128 Section 4.1 encoded using the ASN.1 distinguished 1129 encoding rules (DER), as specified in ITU-T X.690."; 1130 reference 1131 "RFC 2986: PKCS #10: Certification Request Syntax 1132 Specification Version 1.7. 1133 ITU-T X.690: 1134 Information technology - ASN.1 encoding rules: 1135 Specification of Basic Encoding Rules (BER), 1136 Canonical Encoding Rules (CER) and Distinguished 1137 Encoding Rules (DER)."; 1138 } 1139 } 1140 output { 1141 leaf certificate-signing-request { 1142 type binary; 1143 mandatory true; 1144 description 1145 "A CertificationRequest structure as specified by 1146 RFC 2986, Section 4.2 encoded using the ASN.1 1147 distinguished encoding rules (DER), as specified 1148 in ITU-T X.690."; 1149 reference 1150 "RFC 2986: PKCS #10: Certification Request Syntax 1151 Specification Version 1.7. 1152 ITU-T X.690: 1153 Information technology - ASN.1 encoding rules: 1154 Specification of Basic Encoding Rules (BER), 1155 Canonical Encoding Rules (CER) and Distinguished 1156 Encoding Rules (DER)."; 1157 } 1158 } 1159 } // generate-certificate-signing-request 1160 } // asymmetric-key-pair-with-certs-grouping 1162 /*********************************/ 1163 /* Protocol-Accessible Nodes */ 1164 /*********************************/ 1166 rpc generate-asymmetric-key { 1167 if-feature "asymmetric-key-generation"; 1168 description 1169 "Requests the device to generate an asymmetric key using 1170 the specified key algorithm."; 1171 input { 1172 leaf algorithm { 1173 type iasa:asymmetric-algorithm-type; 1174 mandatory true; 1175 description 1176 "The algorithm to be used when generating the key."; 1177 reference 1178 "RFC AAAA: Common YANG Data Types for Cryptography"; 1179 } 1180 } 1181 output { 1182 uses ct:asymmetric-key-pair-grouping; 1183 } 1184 } // end generate-asymmetric-key 1186 rpc generate-symmetric-key { 1187 if-feature "symmetric-key-generation"; 1188 description 1189 "Requests the device to generate an symmetric key using 1190 the specified key algorithm."; 1191 input { 1192 leaf algorithm { 1193 type isa:symmetric-algorithm-type; 1194 mandatory true; 1195 description 1196 "The algorithm to be used when generating the key."; 1197 reference 1198 "RFC AAAA: Common YANG Data Types for Cryptography"; 1199 } 1200 } 1201 output { 1202 uses ct:symmetric-key-grouping; 1203 } 1204 } // end generate-symmetric-key 1206 } 1208 1210 2.3. Examples 1212 2.3.1. The "asymmetric-key-pair-with-certs-grouping" Grouping 1214 The following example module illustrates the use of both the 1215 "symmetric-key-grouping" and the "asymmetric-key-pair-with-certs- 1216 grouping" groupings defined in the "ietf-crypto-types" module. 1218 module ex-crypto-types-usage { 1219 yang-version 1.1; 1221 namespace "http://example.com/ns/example-crypto-types-usage"; 1222 prefix "ectu"; 1224 import ietf-crypto-types { 1225 prefix ct; 1226 reference 1227 "RFC XXXX: Common YANG Data Types for Cryptography"; 1228 } 1230 organization 1231 "Example Corporation"; 1233 contact 1234 "Author: YANG Designer "; 1236 description 1237 "This module illustrates the grouping 1238 defined in the crypto-types draft called 1239 'asymmetric-key-pair-with-certs-grouping'."; 1241 revision "1001-01-01" { 1242 description 1243 "Initial version"; 1244 reference 1245 "RFC ????: Usage Example for RFC XXXX"; 1246 } 1248 container symmetric-keys { 1249 description 1250 "A container of symmetric keys."; 1251 list symmetric-key { 1252 key name; 1253 description 1254 "A symmetric key"; 1255 leaf name { 1256 type string; 1257 description 1258 "An arbitrary name for this key."; 1259 } 1260 uses ct:symmetric-key-grouping; 1261 } 1262 } 1263 container asymmetric-keys { 1264 description 1265 "A container of asymmetric keys."; 1266 list asymmetric-key { 1267 key name; 1268 leaf name { 1269 type string; 1270 description 1271 "An arbitrary name for this key."; 1272 } 1273 uses ct:asymmetric-key-pair-with-certs-grouping; 1274 description 1275 "An asymmetric key pair with associated certificates."; 1276 } 1277 } 1278 } 1280 Given the above example usage module, the following example 1281 illustrates some configured keys. 1283 1286 1287 ex-symmetric-key 1288 aes-256-cbc 1289 ct:octet-string-key-format 1290 base64encodedvalue== 1291 1292 1293 ex-hidden-symmetric-key 1294 aes-256-cbc 1295 1296 1297 1299 1302 1303 ex-asymmetric-key 1304 rsa2048 1305 1306 ct:subject-public-key-info-format 1307 1308 base64encodedvalue== 1309 1310 ct:rsa-private-key-format 1311 1312 base64encodedvalue== 1313 1314 1315 ex-cert 1316 base64encodedvalue== 1317 1318 1319 1320 1321 ex-hidden-asymmetric-key 1322 rsa2048 1323 1324 ct:subject-public-key-info-format 1325 1326 base64encodedvalue== 1327 1328 1329 1330 ex-hidden-key-cert 1331 base64encodedvalue== 1332 1333 1334 1335 1337 2.3.2. The "generate-symmetric-key" RPC 1339 The following example illustrates the "generate-symmetric-key" RPC 1340 with the NETCONF protocol. 1342 REQUEST 1344 1346 1348 aes-256-cbc 1349 1350 1352 RESPONSE 1354 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 1356 1359 1360 aes-256-cbc 1361 ct:encrypted-one-symmetric-key-format 1363 base64encodedvalue== 1364 1365 1367 2.3.3. The "generate-asymmetric-key" RPC 1369 The following example illustrates the "generate-asymmetric-key" RPC 1370 with the NETCONF protocol. 1372 REQUEST 1374 1376 1378 secp256r1 1379 1380 1381 RESPONSE 1383 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 1385 1388 1389 secp256r1 1390 ct:subject-public-key-info-format 1392 base64encodedvalue== 1393 ct:encrypted-one-asymmetric-key-format 1395 base64encodedvalue== 1396 1397 1399 2.3.4. The "generate-certificate-signing-request" Action 1401 The following example illustrates the "generate-certificate-signing- 1402 request" action with the NETCONF protocol. 1404 REQUEST 1406 1408 1409 1411 1412 ex-key-sect571r1 1413 1414 base64encodedvalue== 1415 base64encodedvalue== 1416 1417 1418 1419 1420 1421 RESPONSE 1423 1425 1427 base64encodedvalue== 1428 1429 1431 2.3.5. The "certificate-expiration" Notification 1433 The following example illustrates the "certificate-expiration" 1434 notification with the NETCONF protocol. 1436 1438 2018-05-25T00:01:00Z 1439 1440 1441 locally-defined key 1442 1443 1444 my-cert 1445 1446 1447 2018-08-05T14:18:53-05:00 1448 1449 1450 1451 1452 1453 1454 1456 3. Security Considerations 1458 3.1. No Support for CRMF 1460 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1461 signing-request" action. The use of Certificate Request Message 1462 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1463 was market demand for it. If it is desired to support CRMF in the 1464 future, a backwards compatible solution can be defined at that time. 1466 3.2. Access to Data Nodes 1468 The YANG module in this document defines "grouping" statements that 1469 are designed to be accessed via YANG based management protocols, such 1470 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1471 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1472 with mutual authentication. 1474 The NETCONF access control model (NACM) [RFC8341] provides the means 1475 to restrict access for particular users to a pre-configured subset of 1476 all available protocol operations and content. 1478 Since the module in this document only define groupings, these 1479 considerations are primarily for the designers of other modules that 1480 use these groupings. 1482 There are a number of data nodes defined by the grouping statements 1483 that are writable/creatable/deletable (i.e., config true, which is 1484 the default). Some of these data nodes may be considered sensitive 1485 or vulnerable in some network environments. Write operations (e.g., 1486 edit-config) to these data nodes without proper protection can have a 1487 negative effect on network operations. These are the subtrees and 1488 data nodes and their sensitivity/vulnerability: 1490 *: All of the data nodes defined by all the groupings are 1491 considered sensitive to write operations. For instance, the 1492 modification of a public key or a certificate can dramatically 1493 alter the implemented security policy. For this reason, the 1494 NACM extension "default-deny-write" has been applied to all the 1495 data nodes defined by all the groupings. 1497 Some of the readable data nodes in the YANG module may be considered 1498 sensitive or vulnerable in some network environments. It is thus 1499 important to control read access (e.g., via get, get-config, or 1500 notification) to these data nodes. These are the subtrees and data 1501 nodes and their sensitivity/vulnerability: 1503 /private-key: The "private-key" node defined in the "asymmetric- 1504 key-pair-grouping" grouping is additionally sensitive to read 1505 operations such that, in normal use cases, it should never be 1506 returned to a client. For this reason, the NACM extension 1507 "default-deny-all" has been applied to it here. 1509 Some of the operations in this YANG module may be considered 1510 sensitive or vulnerable in some network environments. It is thus 1511 important to control access to these operations. These are the 1512 operations and their sensitivity/vulnerability: 1514 *: All of the "action" statements defined by groupings SHOULD only 1515 be executed by authorized users. For this reason, the NACM 1516 extension "default-deny-all" has been applied to all of them. 1517 Note that NACM uses "default-deny-all" to protect "RPC" and 1518 "action" statements; it does not define, e.g., an extension 1519 called "default-deny-execute". 1521 generate-certificate-signing-request: For this action, it is 1522 RECOMMENDED that implementations assert channel binding 1523 [RFC5056], so as to ensure that the application layer that sent 1524 the request is the same as the device authenticated when the 1525 secure transport layer was established. 1527 generate-symmetric-key: FIXME 1529 generate-asymmetric-key: FIXME 1531 4. IANA Considerations 1533 4.1. Create the "Cryptographic Primitives" Registry 1535 This section defines a new registry called "Cryptographic 1536 Primitives", following the guidelines described in Section 4 of 1537 [RFC5226]. 1539 This registery enumerates various primitive algorithms that are used 1540 by various cryptographic ciphers and protocols. 1542 The following note shall be at the top of the registry: 1544 This registry enumerates cryptographic primitives that are or have 1545 been used by various cryptographic ciphers and protocols. 1547 4.1.1. Introduction 1549 The Cryptographic Primitives registry is composed of a number of sub- 1550 registries, one for each kind of primitive algorithm. 1552 Each sub-registry has the same number of fields and update policy. 1554 The fields for each sub-registry are: 1556 o Name 1558 * The name of the algorithm (required). 1560 * The name must be the common "enumerated" value for the 1561 algorithm. 1563 * The name must be unique within the sub-registry. 1565 * The name must be a single word composed of one or more ASCII 1566 characters. 1568 * Each character must be either an uppercase or lowercase letter, 1569 a digit, a hyphen, or an underscore. 1571 * While not bounded, the name is expected to be relatively short; 1572 unlikely ever exceeding a couple dozen characters. 1574 o Description 1576 * An arbitrary description of the algorithm (optional). 1578 * The discription may be used to provide a human-facing name and/ 1579 or alternate names for the algorithm. 1581 * The description, when present, is expected to be no more than a 1582 few sentences. 1584 * The description is to be in English, but may contain UTF-8 1585 characters as may be needed in some cases. 1587 o Status 1589 * An enumerated value stating the current status of the algorithm 1590 (optional). 1592 * The value, when present, must be "Recommended", "Deprecated" or 1593 "Obsolete". 1595 * An algorithm having no "status" specified (i.e., not marked as 1596 "Recommended") does not necessarily mean that it is flawed; 1597 rather, it indicates that the item either has not been through 1598 the IETF consensus process, has limited applicability, or is 1599 intended only for specific use cases. 1601 * When requesting a registration for an algorithm having no 1602 status, the request should use an empty string value (i.e., 1603 "Status: ") to clearly indicate no status, as opposed to the 1604 value having been forgotten. 1606 o References 1608 * One or more normative references for the algorithm (required). 1610 * Each reference must declare its "type" as as either "text" or 1611 "rfc" and, if "rfc", must also declare an "data" value 1612 containing the RFC's number in the form "rfcxxxx" (or 1613 "rfcxxxxx"). In either case, the xref's content must contain a 1614 suitable textual citation, e.g., containing both a tracking 1615 number (e.g., RFC 2119) as well the document's title (e.g., Key 1616 words for use in RFCs to Indicate Requirement Levels). 1617 Rendering software (e.g., stylesheets) may choose to present 1618 the reference in any suitable manner. 1620 * There must be at least one reference to a document that defines 1621 the algorithm. 1623 * There must be a reference to the document that originated the 1624 algorithm's registration. 1626 * The document that defines the algorithm and the document that 1627 defines originated the registration may be the same. 1629 * While not bounded, the total number of references is unlikely 1630 to ever exceed a few. 1632 The update policy is either "RFC Required" or "IETF Review", and 1633 maybe also "IESG Approval". In any case, it is always requires an 1634 "Expert Review" (a.k.a. "Designated Expert). 1636 Whenever a sub-registry is updated, IANA must automatically update 1637 and re-published the corresponding YANG module, as described in IANA- 1638 maintained YANG Modules (Section 4.2). 1640 4.1.2. The "Symmetric Key Algorithms" Sub-Registry 1642 The "Symmetric Key Algorithms" sub-registry enumerates symmetric key 1643 algorithms used by cryptographic ciphers and protocols. 1645 The format of this registry is described in the Introduction 1646 (Section 4.1.1) section above. 1648 Following is the initial assignment for this sub-registry: 1650 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 1652 Record: 1653 Name: des 1654 Description: The Data Encryption Algorithm 1655 Status: 1656 Reference (type="text"): National Institute of Standards and Techn\ 1657 ology. FIPS Pub 46: Data Encryption Standard. 15 January 1977. 1659 Record: 1660 Name: 3des 1661 Description: The Data Encryption Algorithm 1662 Status: 1663 Reference (type="rfc" data="1851"): RFC 3961: The ESP Triple DES T\ 1664 ransform 1666 Record: 1667 Name: aes 1668 Description: The AES algorithm. 1669 Status: 1670 Reference (type="text"): National Institute of Standards. FIPS Pu\ 1671 b 197: Advanced Encryption Standard (AES). 26 November 2001. 1673 4.1.3. The "Asymmetric Key Algorithms" Sub-Registry 1675 The "Asymmetric Key Algorithms" sub-registry enumerates asymmetric 1676 key algorithms used by cryptographic ciphers and protocols. 1678 The format of this registry is described in the Introduction 1679 (Section 4.1.1) section above. 1681 Following is the initial assignment for this sub-registry: 1683 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 1685 Record: 1686 Name: rsa 1687 Description: The RSA algorithm 1688 Status: 1689 Reference (type="rfc" data="rfc8017"): RFC 8017: PKCS #1: RSA Cryp\ 1690 tography Specifications Version 2.2 1692 Record: 1693 Name: secp192r1 1694 Description: The asymmetric algorithm using a NIST P192 Curve 1695 Status: 1696 Reference (type="rfc" data="rfc6090"): RFC 6090: Fundamental Ellip\ 1698 tic Curve Cryptography Algorithms 1699 Reference (type="rfc" data="rfc5480"): RFC 5480: Elliptic Curve Cr\ 1700 yptography Subject Public Key Information 1702 Record: 1703 Name: secp224r1 1704 Description: The asymmetric algorithm using a NIST P224 Curve 1705 Status: 1706 Reference (type="rfc" data="rfc6090"): RFC 6090: Fundamental Ellip\ 1707 tic Curve Cryptography Algorithms 1708 Reference (type="rfc" data="rfc5480"): RFC 5480: Elliptic Curve Cr\ 1709 yptography Subject Public Key Information 1711 Record: 1712 Name: secp256r1 1713 Description: The asymmetric algorithm using a NIST P256 Curve 1714 Status: 1715 Reference (type="rfc" data="rfc6090"): RFC 6090: Fundamental Ellip\ 1716 tic Curve Cryptography Algorithms 1717 Reference (type="rfc" data="rfc5480"): RFC 5480: Elliptic Curve Cr\ 1718 yptography Subject Public Key Information 1720 Record: 1721 Name: secp384r1 1722 Description: The asymmetric algorithm using a NIST P384 Curve 1723 Status: 1724 Reference (type="rfc" data="rfc6090"): RFC 6090: Fundamental Ellip\ 1725 tic Curve Cryptography Algorithms 1726 Reference (type="rfc" data="rfc5480"): RFC 5480: Elliptic Curve Cr\ 1727 yptography Subject Public Key Information 1729 Record: 1730 Name: secp521r1 1731 Description: The asymmetric algorithm using a NIST P521 Curve 1732 Status: 1733 Reference (type="rfc" data="rfc6090"): RFC 6090: Fundamental Ellip\ 1734 tic Curve Cryptography Algorithms 1735 Reference (type="rfc" data="rfc5480"): RFC 5480: Elliptic Curve Cr\ 1736 yptography Subject Public Key Information 1738 Record: 1739 Name: x25519 1740 Description: The asymmetric algorithm using a x.25519 Curve 1741 Status: 1742 Reference (type="rfc" data="rfc7748"): RFC 7748: Elliptic Curves f\ 1743 or Security 1745 Record: 1747 Name: x448 1748 Description: The asymmetric algorithm using a x.448 Curve 1749 Status: 1750 Reference (type="rfc" data="rfc7748"): RFC 7748: Elliptic Curves f\ 1751 or Security 1753 4.1.4. The "Hash Algorithms" Sub-Registry 1755 The "Hash Algorithms" sub-registry enumerates hashing algorithms used 1756 by cryptographic ciphers and protocols. 1758 The format of this registry is described in the Introduction 1759 (Section 4.1.1) section above. 1761 Following is the initial assignment for this sub-registry: 1763 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 1765 Record: 1766 Name: sha1 1767 Description: The SHA1 algorithm 1768 Status: Obsolete 1769 Reference (type="rfc" data="rfc3174"): RFC 3174: US Secure Hash Al\ 1770 gorithms 1 (SHA1) 1772 Record: 1773 Name: sha-224 1774 Description: The SHA-224 algorithm 1775 Status: 1776 Reference (type="rfc" data="rfc6234"): RFC 6234: US Secure Hash Al\ 1777 gorithms 1779 Record: 1780 Name: sha-256 1781 Description: The SHA-256 algorithm 1782 Status: 1783 Reference (type="rfc" data="rfc6234"): RFC 6234: US Secure Hash Al\ 1784 gorithms 1786 Record: 1787 Name: sha-384 1788 Description: The SHA-384 algorithm 1789 Status: 1790 Reference (type="rfc" data="rfc6234"): RFC 6234: US Secure Hash Al\ 1791 gorithms 1793 Record: 1795 Name: sha-512 1796 Description: The SHA-512 algorithm 1797 Status: 1798 Reference (type="rfc" data="rfc6234"): RFC 6234: US Secure Hash Al\ 1799 gorithms 1801 Record: 1802 Name: shake-128 1803 Description: The SHA3 algorithm with 128-bits output 1804 Status: 1805 Reference (type="text"): National Institute of Standards and Techn\ 1806 ology, SHA-3 Standard: Permutation-Based Hash and Extendable-Output \ 1807 Functions, FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015 1809 Record: 1810 Name: shake-224 1811 Description: The SHA3 algorithm with 224-bits output 1812 Status: 1813 Reference (type="text"): National Institute of Standards and Techn\ 1814 ology, SHA-3 Standard: Permutation-Based Hash and Extendable-Output \ 1815 Functions, FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015 1817 Record: 1818 Name: shake-256 1819 Description: The SHA3 algorithm with 256-bits output 1820 Status: 1821 Reference (type="text"): National Institute of Standards and Techn\ 1822 ology, SHA-3 Standard: Permutation-Based Hash and Extendable-Output \ 1823 Functions, FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015 1825 Record: 1826 Name: shake-384 1827 Description: The SHA3 algorithm with 384-bits output 1828 Status: 1829 Reference (type="text"): National Institute of Standards and Techn\ 1830 ology, SHA-3 Standard: Permutation-Based Hash and Extendable-Output \ 1831 Functions, FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015 1833 Record: 1834 Name: shake-512 1835 Description: The SHA3 algorithm with 512-bits output 1836 Status: 1837 Reference (type="text"): National Institute of Standards and Techn\ 1838 ology, SHA-3 Standard: Permutation-Based Hash and Extendable-Output \ 1839 Functions, FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015 1841 4.2. IANA-maintained YANG Modules 1843 FIXME: this section needs elaboration! 1845 Any time one of the "Primitive" registries defined in Section 4.1 1846 is modified, IANA must: 1848 Run the TBD script defined in TBD to generate the corresponding 1849 YANG module. 1851 Publish the corresponding YANG module using the TBD process. 1853 Sample resulting YANG modules are provided in Appendix A. 1855 4.3. Update the "Secure Shell (SSH) Protocol Parameters" Registry 1857 This section updates the "Secure Shell (SSH) Protocol Parameters" 1858 registry located at https://www.iana.org/assignments/ssh-parameters/ 1859 ssh-parameters.xhtml, following the guidelines specified in 1860 Section 5.2 in [RFC5226]. 1862 The Secure Shell (SSH) Protocol Parameters registry is composed of a 1863 number of sub-registries. The update described in this section 1864 modifies only a subset of the sub-registries, as described in the 1865 subsections contained herein. 1867 The modification includes both adding a new column to the sub- 1868 registry and initialing the new column's values for existing 1869 registrations. 1871 The process to add the new column is the same for each subregistry 1872 and hence described only once here below. 1874 How to initialize the new column's values for existing registrations 1875 is specific to each subregistry and hence specified in the 1876 subsections. 1878 4.3.1. Common Update to Specified Sub-Registries 1880 Add a new column called "Primitives" placed at the left-most position 1881 in the table. 1883 This column must contain one or more primitive algorithms used by the 1884 given registration. 1886 Each primitive algorithm must be listed in the "Cryptographic 1887 Primitives" registry defined in Section 4.1. 1889 While unbounded, the number of primitive algorithms listed is never 1890 expected to be more than a few. 1892 4.3.2. The "Public Key Algorithm Names" Sub-Registry 1894 Public Key Algorithm Name Primitives 1895 ========================= ========== 1896 ssh-dss dss, sha1 1897 ssh-rsa rsa, sha1 1898 rsa-sha2-256 rsa, sha-256 1899 rsa-sha2-512 rsa, 1900 spki-sign-rsa rsa 1901 spki-sign-dss dss 1902 pgp-sign-rsa rsa 1903 pgp-sign-dss dss 1904 null N/A 1905 ecdsa-sha2-* 1906 x509v3-ssh-dss dss 1907 x509v3-ssh-rsa rsa 1908 x509v3-rsa2048-sha256 rsa 1909 x509v3-ecdsa-sha2-* 1910 ssh-ed25519 x25519 1911 ssh-ed448 x448 1913 4.4. Update the "Transport Layer Security (TLS) Parameters" Registry 1915 This section updates the "Update the "Transport Layer Security (TLS) 1916 Parameters" registry located at https://www.iana.org/assignments/tls- 1917 parameters/tls-parameters.xhtml, following the guidelines specified 1918 in Section 5.2 in [RFC5226]. 1920 The Update the "Transport Layer Security (TLS) Parameters registry is 1921 composed of a number of sub-registries. The update described in this 1922 section modifies only a subset of the sub-registries, as described in 1923 the subsections contained herein. 1925 The modification includes both adding a new column to the sub- 1926 registry and initialing the new column's values for existing 1927 registrations. 1929 The process to add the new column is the same for each subregistry 1930 and hence described only once here below. 1932 How to initialize the new column's values for existing registrations 1933 is specific to each subregistry and hence specified in the 1934 subsections. 1936 4.4.1. Common Update to Specified Sub-Registries 1938 Add a new column called "Primitives" placed at the left-most position 1939 in the table. 1941 This column must contain one or more primitive algorithms used by the 1942 given registration. 1944 Each primitive algorithm must be listed in the "Cryptographic 1945 Primitives" registry defined in Section 4.1. 1947 While unbounded, the number of primitive algorithms listed is never 1948 expected to be more than a few. 1950 4.4.2. The "TLS Supported Groups" Sub-Registry 1952 Any unspecified row should have the Primitive value "N/A". 1954 Value Description Primitives 1955 ===== =========== ========== 1956 1 sect163k1 FIXME 1957 2 sect163r1 FIXME? 1958 3 sect163r2 FIXME? 1959 4 sect193r1 FIXME? 1960 5 sect193r2 FIXME? 1961 6 sect233k1 FIXME? 1962 7 sect233r1 FIXME? 1963 8 sect239k1 FIXME? 1964 9 sect283k1 FIXME? 1965 10 sect283r1 FIXME? 1966 11 sect409k1 FIXME? 1967 12 sect409r1 FIXME? 1968 13 sect571k1 FIXME? 1969 14 sect571r1 FIXME? 1970 15 secp160k1 FIXME? 1971 16 secp160r1 FIXME? 1972 17 secp160r2 FIXME? 1973 18 secp192k1 FIXME? 1974 19 secp192r1 secp192r1 1975 20 secp224k1 FIXME? 1976 21 secp224r1 secp224r1 1977 22 secp256k1 FIXME? 1978 23 secp256r1 secp256r1 1979 24 secp384r1 secp384r1 1980 25 secp521r1 secp521r1 1981 26 brainpoolP256r1 FIXME? 1982 27 brainpoolP384r1 FIXME? 1983 28 brainpoolP512r1 FIXME? 1984 29 x25519 x25519 1985 30 x448 x448 1986 31 brainpoolP256r1tls13 FIXME? 1987 32 brainpoolP384r1tls13 FIXME? 1988 33 brainpoolP512r1tls13 FIXME? 1989 256 ffdhe2048 FIXME? 1990 257 ffdhe3072 FIXME? 1991 258 ffdhe4096 FIXME? 1992 259 ffdhe6144 FIXME? 1993 260 ffdhe8192 FIXME? 1995 4.4.3. The "TLS SignatureAlgorithm" Sub-Registry 1997 Any unspecified row should have the Primitive value "N/A". 1999 Value Description Primitives 2000 ===== =========== ========== 2001 0 anonymous FIXME? 2002 1 rsa rsa 2003 2 dsa dsa 2004 3 ecdsa FIXME? 2005 7 ed25519 x25519 2006 8 ed448 x448 2008 4.4.4. The "TLS SignatureScheme" Sub-Registry 2010 Any unspecified row should have the Primitive value "N/A". 2012 Value Description Primitives 2013 ===== =========== ========== 2014 0x0201 rsa_pkcs1_sha1 rsa 2015 0x0203 ecdsa_sha1 dsa 2016 0x0401 rsa_pkcs1_sha256 rsa 2017 0x0403 ecdsa_secp256r1_sha256 secp256r1 2018 0x0501 rsa_pkcs1_sha384 rsa 2019 0x0503 ecdsa_secp384r1_sha384 secp384r1 2020 0x0601 rsa_pkcs1_sha512 rsa 2021 0x0603 ecdsa_secp521r1_sha512 secp521r1 2022 0x0804 rsa_pss_rsae_sha256 rsa 2023 0x0805 rsa_pss_rsae_sha384 rsa 2024 0x0806 rsa_pss_rsae_sha512 rsa 2025 0x0807 ed25519 x25519 2026 0x0808 ed448 x448 2027 0x0809 rsa_pss_pss_sha256 rsa 2028 0x080A rsa_pss_pss_sha384 rsa 2029 0x080B rsa_pss_pss_sha512 rsa 2030 0x081A ecdsa_brainpoolP256r1tls13_sha256 dsa 2031 0x081B ecdsa_brainpoolP384r1tls13_sha384 dsa 2032 0x081C ecdsa_brainpoolP512r1tls13_sha512 dsa 2034 4.5. Update the "IETF XML" Registry 2036 This document registers four URIs in the "ns" subregistry of the 2037 "IETF XML" registry [RFC3688]. Following the format in [RFC3688], 2038 the following registrations are requested: 2040 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2041 Registrant Contact: The NETCONF WG of the IETF. 2042 XML: N/A, the requested URI is an XML namespace. 2044 URI: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 2045 Registrant Contact: The NETCONF WG of the IETF. 2046 XML: N/A, the requested URI is an XML namespace. 2048 URI: urn:ietf:params:xml:ns:yang:iana-ssymmetric-algs 2049 Registrant Contact: The NETCONF WG of the IETF. 2050 XML: N/A, the requested URI is an XML namespace. 2052 URI: urn:ietf:params:xml:ns:yang:iana-hash-algs 2053 Registrant Contact: The NETCONF WG of the IETF. 2054 XML: N/A, the requested URI is an XML namespace. 2056 4.6. Update the "YANG Module Names" Registry 2058 This document registers four YANG modules in the "YANG Module Names" 2059 registry [RFC6020]. Following the format in [RFC6020], the the 2060 following registrations are requested: 2062 name: ietf-crypto-types 2063 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2064 prefix: ct 2065 reference: RFC XXXX 2067 name: iana-symmetric-algs 2068 namespace: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 2069 prefix: isa 2070 reference: RFC XXXX 2072 name: iana-asymmetric-algs 2073 namespace: urn:ietf:params:xml:ns:yang:iana-asymmetric-algs 2074 prefix: iasa 2075 reference: RFC XXXX 2077 name: iana-hash-algs 2078 namespace: urn:ietf:params:xml:ns:yang:iana-hash-algs 2079 prefix: iha 2080 reference: RFC XXXX 2082 5. References 2083 5.1. Normative References 2085 [ITU.X690.2015] 2086 International Telecommunication Union, "Information 2087 Technology - ASN.1 encoding rules: Specification of Basic 2088 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2089 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2090 X.690, ISO/IEC 8825-1, August 2015, 2091 . 2093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2094 Requirement Levels", BCP 14, RFC 2119, 2095 DOI 10.17487/RFC2119, March 1997, 2096 . 2098 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2099 Standards (PKCS) #1: RSA Cryptography Specifications 2100 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2101 2003, . 2103 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2104 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2105 January 2006, . 2107 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2108 Housley, R., and W. Polk, "Internet X.509 Public Key 2109 Infrastructure Certificate and Certificate Revocation List 2110 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2111 . 2113 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2114 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2115 . 2117 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 2118 DOI 10.17487/RFC5958, August 2010, 2119 . 2121 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2122 (CMS) Symmetric Key Package Content Type", RFC 6031, 2123 DOI 10.17487/RFC6031, December 2010, 2124 . 2126 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2127 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2128 . 2130 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2131 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2132 . 2134 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2135 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2136 May 2017, . 2138 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2139 Access Control Model", STD 91, RFC 8341, 2140 DOI 10.17487/RFC8341, March 2018, 2141 . 2143 5.2. Informative References 2145 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2146 Request Syntax Specification Version 1.7", RFC 2986, 2147 DOI 10.17487/RFC2986, November 2000, 2148 . 2150 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2151 DOI 10.17487/RFC3688, January 2004, 2152 . 2154 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2155 Certificate Request Message Format (CRMF)", RFC 4211, 2156 DOI 10.17487/RFC4211, September 2005, 2157 . 2159 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2160 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2161 . 2163 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2164 IANA Considerations Section in RFCs", RFC 5226, 2165 DOI 10.17487/RFC5226, May 2008, 2166 . 2168 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2169 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2170 . 2172 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2173 the Network Configuration Protocol (NETCONF)", RFC 6020, 2174 DOI 10.17487/RFC6020, October 2010, 2175 . 2177 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2178 Verification of Domain-Based Application Service Identity 2179 within Internet Public Key Infrastructure Using X.509 2180 (PKIX) Certificates in the Context of Transport Layer 2181 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2182 2011, . 2184 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2185 and A. Bierman, Ed., "Network Configuration Protocol 2186 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2187 . 2189 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2190 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2191 . 2193 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2194 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2195 . 2197 Appendix A. Sample IANA Modules 2199 This non-normative section presents the YANG modules produced by 2200 running the TBD script presented in Section 4.2 over the registries 2201 defined in Section 4.1. 2203 A.1. The Symmetric Algorithms Module 2205 file "iana-symmetric-algs@2020-03-08.yang" 2207 module iana-symmetric-algs { 2208 yang-version 1.1; 2209 namespace "urn:ietf:params:xml:ns:yang:iana-symmetric-algs"; 2210 prefix isa; 2212 organization 2213 "IETF NETCONF (Network Configuration) Working Group"; 2215 contact 2216 "WG Web: 2217 WG List: 2218 Author: Kent Watsen 2219 Author: Wang Haiguang "; 2221 description 2222 "This module defines a typedef for symmetric algorithms, and 2223 a container for a list of symmetric algorithms supported by 2224 the server. 2226 Copyright (c) 2019 IETF Trust and the persons identified 2227 as authors of the code. All rights reserved. 2228 Redistribution and use in source and binary forms, with 2229 or without modification, is permitted pursuant to, and 2230 subject to the license terms contained in, the Simplified 2231 BSD License set forth in Section 4.c of the IETF Trust's 2232 Legal Provisions Relating to IETF Documents 2233 (https://trustee.ietf.org/license-info). 2235 This version of this YANG module is part of RFC XXXX 2236 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 2237 itself for full legal notices. 2239 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2240 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2241 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 2242 are to be interpreted as described in BCP 14 (RFC 2119) 2243 (RFC 8174) when, and only when, they appear in all 2244 capitals, as shown here."; 2246 revision 2020-03-08 { 2247 description 2248 "Initial version"; 2249 reference 2250 "RFC XXXX: Common YANG Data Types for Cryptography"; 2251 } 2253 // Typedefs 2255 typedef symmetric-algorithm-type { 2256 type enumeration { 2257 enum aes-128-cbc { 2258 value 1; 2259 description 2260 "Encrypt message with AES algorithm in CBC mode with 2261 a key length of 128 bits."; 2262 reference 2263 "RFC 3565: Use of the Advanced Encryption Standard (AES) 2264 Encryption Algorithm in Cryptographic Message Syntax 2265 (CMS)"; 2266 } 2267 enum aes-192-cbc { 2268 value 2; 2269 description 2270 "Encrypt message with AES algorithm in CBC mode with 2271 a key length of 192 bits"; 2272 reference 2273 "RFC 3565: Use of the Advanced Encryption Standard (AES) 2274 Encryption Algorithm in Cryptographic Message Syntax 2275 (CMS)"; 2276 } 2277 enum aes-256-cbc { 2278 value 3; 2279 description 2280 "Encrypt message with AES algorithm in CBC mode with 2281 a key length of 256 bits"; 2282 reference 2283 "RFC 3565: Use of the Advanced Encryption Standard (AES) 2284 Encryption Algorithm in Cryptographic Message Syntax 2285 (CMS)"; 2286 } 2287 enum aes-128-ctr { 2288 value 4; 2289 description 2290 "Encrypt message with AES algorithm in CTR mode with 2291 a key length of 128 bits"; 2292 reference 2293 "RFC 3686: 2295 Using Advanced Encryption Standard (AES) Counter 2296 Mode with IPsec Encapsulating Security Payload 2297 (ESP)"; 2298 } 2299 enum aes-192-ctr { 2300 value 5; 2301 description 2302 "Encrypt message with AES algorithm in CTR mode with 2303 a key length of 192 bits"; 2304 reference 2305 "RFC 3686: 2306 Using Advanced Encryption Standard (AES) Counter 2307 Mode with IPsec Encapsulating Security Payload 2308 (ESP)"; 2309 } 2310 enum aes-256-ctr { 2311 value 6; 2312 description 2313 "Encrypt message with AES algorithm in CTR mode with 2314 a key length of 256 bits"; 2315 reference 2316 "RFC 3686: 2317 Using Advanced Encryption Standard (AES) Counter 2318 Mode with IPsec Encapsulating Security Payload 2319 (ESP)"; 2320 } 2321 enum des3-cbc-sha1-kd { 2322 value 7; 2323 description 2324 "Encrypt message with 3DES algorithm in CBC mode 2325 with sha1 function for key derivation"; 2326 reference 2327 "RFC 3961: 2328 Encryption and Checksum Specifications for 2329 Kerberos 5"; 2330 } 2331 enum rc4-hmac { 2332 value 8; 2333 description 2334 "Encrypt message with rc4 algorithm"; 2335 reference 2336 "RFC 4757: 2337 The RC4-HMAC Kerberos Encryption Types Used by 2338 Microsoft Windows"; 2339 } 2340 enum rc4-hmac-exp { 2341 value 9; 2342 description 2343 "Encrypt message with rc4 algorithm that is exportable"; 2344 reference 2345 "RFC 4757: 2346 The RC4-HMAC Kerberos Encryption Types Used by 2347 Microsoft Windows"; 2348 } 2349 } 2350 description 2351 "A typedef enumerating various symmetric key algorithms."; 2352 } 2354 // Protocol-accessible Nodes 2356 container supported-symmetric-algorithms { 2357 config false; 2358 description 2359 "A container for a list of supported symmetric algorithms. 2360 How algorithms come to be supported is outside the scope 2361 of this module."; 2362 list supported-symmetric-algorithm { 2363 key algorithm; 2364 description 2365 "A lists of symmetric algorithms supported by the server."; 2366 leaf algorithm { 2367 type symmetric-algorithm-type; 2368 description 2369 "An symmetric algorithms supported by the server."; 2370 } 2371 } 2372 } 2374 } 2376 2378 A.2. The Asymmetric Algorithms Module 2380 file "iana-asymmetric-algs@2020-03-08.yang" 2382 module iana-asymmetric-algs { 2383 yang-version 1.1; 2384 namespace "urn:ietf:params:xml:ns:yang:iana-asymmetric-algs"; 2385 prefix iasa; 2387 organization 2388 "IETF NETCONF (Network Configuration) Working Group"; 2390 contact 2391 "WG Web: 2392 WG List: 2393 Author: Kent Watsen 2394 Author: Wang Haiguang "; 2396 description 2397 "This module defines a typedef for asymmetric algorithms, and 2398 a container for a list of asymmetric algorithms supported by 2399 the server. 2401 Copyright (c) 2019 IETF Trust and the persons identified 2402 as authors of the code. All rights reserved. 2403 Redistribution and use in source and binary forms, with 2404 or without modification, is permitted pursuant to, and 2405 subject to the license terms contained in, the Simplified 2406 BSD License set forth in Section 4.c of the IETF Trust's 2407 Legal Provisions Relating to IETF Documents 2408 (https://trustee.ietf.org/license-info). 2410 This version of this YANG module is part of RFC XXXX 2411 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 2412 itself for full legal notices. 2414 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2415 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2416 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 2417 are to be interpreted as described in BCP 14 (RFC 2119) 2418 (RFC 8174) when, and only when, they appear in all 2419 capitals, as shown here."; 2421 revision 2020-03-08 { 2422 description 2423 "Initial version"; 2424 reference 2425 "RFC XXXX: Common YANG Data Types for Cryptography"; 2426 } 2428 // Typedefs 2430 typedef asymmetric-algorithm-type { 2431 type enumeration { 2432 enum rsa1024 { 2433 value 1; 2434 description 2435 "The RSA algorithm using a 1024-bit key."; 2436 reference 2437 "RFC 8017: PKCS #1: RSA Cryptography 2438 Specifications Version 2.2."; 2440 } 2441 enum rsa2048 { 2442 value 2; 2443 description 2444 "The RSA algorithm using a 2048-bit key."; 2445 reference 2446 "RFC 8017: 2447 PKCS #1: RSA Cryptography Specifications Version 2.2."; 2448 } 2449 enum rsa3072 { 2450 value 3; 2451 description 2452 "The RSA algorithm using a 3072-bit key."; 2453 reference 2454 "RFC 8017: 2455 PKCS #1: RSA Cryptography Specifications Version 2.2."; 2456 } 2457 enum rsa4096 { 2458 value 4; 2459 description 2460 "The RSA algorithm using a 4096-bit key."; 2461 reference 2462 "RFC 8017: 2463 PKCS #1: RSA Cryptography Specifications Version 2.2."; 2464 } 2465 enum rsa7680 { 2466 value 5; 2467 description 2468 "The RSA algorithm using a 7680-bit key."; 2469 reference 2470 "RFC 8017: 2471 PKCS #1: RSA Cryptography Specifications Version 2.2."; 2472 } 2473 enum rsa15360 { 2474 value 6; 2475 description 2476 "The RSA algorithm using a 15360-bit key."; 2477 reference 2478 "RFC 8017: 2479 PKCS #1: RSA Cryptography Specifications Version 2.2."; 2480 } 2481 enum secp192r1 { 2482 value 7; 2483 description 2484 "The asymmetric algorithm using a NIST P192 Curve."; 2485 reference 2486 "RFC 6090: 2487 Fundamental Elliptic Curve Cryptography Algorithms. 2489 RFC 5480: 2490 Elliptic Curve Cryptography Subject Public Key 2491 Information."; 2492 } 2493 enum secp224r1 { 2494 value 8; 2495 description 2496 "The asymmetric algorithm using a NIST P224 Curve."; 2497 reference 2498 "RFC 6090: 2499 Fundamental Elliptic Curve Cryptography Algorithms. 2500 RFC 5480: 2501 Elliptic Curve Cryptography Subject Public Key 2502 Information."; 2503 } 2504 enum secp256r1 { 2505 value 9; 2506 description 2507 "The asymmetric algorithm using a NIST P256 Curve."; 2508 reference 2509 "RFC 6090: 2510 Fundamental Elliptic Curve Cryptography Algorithms. 2511 RFC 5480: 2512 Elliptic Curve Cryptography Subject Public Key 2513 Information."; 2514 } 2515 enum secp384r1 { 2516 value 10; 2517 description 2518 "The asymmetric algorithm using a NIST P384 Curve."; 2519 reference 2520 "RFC 6090: 2521 Fundamental Elliptic Curve Cryptography Algorithms. 2522 RFC 5480: 2523 Elliptic Curve Cryptography Subject Public Key 2524 Information."; 2525 } 2526 enum secp521r1 { 2527 value 11; 2528 description 2529 "The asymmetric algorithm using a NIST P521 Curve."; 2530 reference 2531 "RFC 6090: 2532 Fundamental Elliptic Curve Cryptography Algorithms. 2533 RFC 5480: 2534 Elliptic Curve Cryptography Subject Public Key 2535 Information."; 2536 } 2537 enum x25519 { 2538 value 12; 2539 description 2540 "The asymmetric algorithm using a x.25519 Curve."; 2541 reference 2542 "RFC 7748: 2543 Elliptic Curves for Security."; 2544 } 2545 enum x448 { 2546 value 13; 2547 description 2548 "The asymmetric algorithm using a x.448 Curve."; 2549 reference 2550 "RFC 7748: 2551 Elliptic Curves for Security."; 2552 } 2553 } 2554 description 2555 "A typedef enumerating various asymmetric key algorithms."; 2556 } 2558 // Protocol-accessible Nodes 2560 container supported-asymmetric-algorithms { 2561 config false; 2562 description 2563 "A container for a list of supported asymmetric algorithms. 2564 How algorithms come to be supported is outside the scope 2565 of this module."; 2566 list supported-asymmetric-algorithm { 2567 key algorithm; 2568 description 2569 "A lists of asymmetric algorithms supported by the server."; 2570 leaf algorithm { 2571 type asymmetric-algorithm-type; 2572 description 2573 "An asymmetric algorithms supported by the server."; 2574 } 2575 } 2576 } 2578 } 2580 2582 A.3. The Hash Algorithms Module 2584 file "iana-hash-algs@2020-03-08.yang" 2586 module iana-hash-algs { 2587 yang-version 1.1; 2588 namespace "urn:ietf:params:xml:ns:yang:iana-hash-algs"; 2589 prefix iha; 2591 organization 2592 "IETF NETCONF (Network Configuration) Working Group"; 2594 contact 2595 "WG Web: 2596 WG List: 2597 Author: Kent Watsen 2598 Author: Wang Haiguang "; 2600 description 2601 "This module defines a typedef for hash algorithms, and 2602 a container for a list of hash algorithms supported by 2603 the server. 2605 Copyright (c) 2019 IETF Trust and the persons identified 2606 as authors of the code. All rights reserved. 2607 Redistribution and use in source and binary forms, with 2608 or without modification, is permitted pursuant to, and 2609 subject to the license terms contained in, the Simplified 2610 BSD License set forth in Section 4.c of the IETF Trust's 2611 Legal Provisions Relating to IETF Documents 2612 (https://trustee.ietf.org/license-info). 2614 This version of this YANG module is part of RFC XXXX 2615 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 2616 itself for full legal notices. 2618 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2619 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2620 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 2621 are to be interpreted as described in BCP 14 (RFC 2119) 2622 (RFC 8174) when, and only when, they appear in all 2623 capitals, as shown here."; 2625 revision 2020-03-08 { 2626 description 2627 "Initial version"; 2628 reference 2629 "RFC XXXX: Common YANG Data Types for Cryptography"; 2631 } 2633 // Typedefs 2635 typedef hash-algorithm-type { 2636 type enumeration { 2637 enum sha1 { 2638 value 1; 2639 status obsolete; 2640 description 2641 "The SHA1 algorithm."; 2642 reference 2643 "RFC 3174: US Secure Hash Algorithms 1 (SHA1)."; 2644 } 2645 enum sha-224 { 2646 value 2; 2647 description 2648 "The SHA-224 algorithm."; 2649 reference 2650 "RFC 6234: US Secure Hash Algorithms."; 2651 } 2652 enum sha-256 { 2653 value 3; 2654 description 2655 "The SHA-256 algorithm."; 2656 reference 2657 "RFC 6234: US Secure Hash Algorithms."; 2658 } 2659 enum sha-384 { 2660 value 4; 2661 description 2662 "The SHA-384 algorithm."; 2663 reference 2664 "RFC 6234: US Secure Hash Algorithms."; 2665 } 2666 enum sha-512 { 2667 value 5; 2668 description 2669 "The SHA-512 algorithm."; 2670 reference 2671 "RFC 6234: US Secure Hash Algorithms."; 2672 } 2673 enum shake-128 { 2674 value 6; 2675 description 2676 "The SHA3 algorithm with 128-bits output."; 2677 reference 2678 "National Institute of Standards and Technology, 2679 SHA-3 Standard: Permutation-Based Hash and 2680 Extendable-Output Functions, FIPS PUB 202, DOI 2681 10.6028/NIST.FIPS.202, August 2015."; 2682 } 2683 enum shake-224 { 2684 value 7; 2685 description 2686 "The SHA3 algorithm with 224-bits output."; 2687 reference 2688 "National Institute of Standards and Technology, 2689 SHA-3 Standard: Permutation-Based Hash and 2690 Extendable-Output Functions, FIPS PUB 202, DOI 2691 10.6028/NIST.FIPS.202, August 2015."; 2692 } 2693 enum shake-256 { 2694 value 8; 2695 description 2696 "The SHA3 algorithm with 256-bits output."; 2697 reference 2698 "National Institute of Standards and Technology, 2699 SHA-3 Standard: Permutation-Based Hash and 2700 Extendable-Output Functions, FIPS PUB 202, DOI 2701 10.6028/NIST.FIPS.202, August 2015."; 2702 } 2703 enum shake-384 { 2704 value 9; 2705 description 2706 "The SHA3 algorithm with 384-bits output."; 2707 reference 2708 "National Institute of Standards and Technology, 2709 SHA-3 Standard: Permutation-Based Hash and 2710 Extendable-Output Functions, FIPS PUB 202, DOI 2711 10.6028/NIST.FIPS.202, August 2015."; 2712 } 2713 enum shake-512 { 2714 value 10; 2715 description 2716 "The SHA3 algorithm with 384-bits output."; 2717 reference 2718 "National Institute of Standards and Technology, 2719 SHA-3 Standard: Permutation-Based Hash and 2720 Extendable-Output Functions, FIPS PUB 202, DOI 2721 10.6028/NIST.FIPS.202, August 2015."; 2722 } 2723 } 2724 description 2725 "A typedef enumerating various hash key algorithms."; 2726 } 2727 // Protocol-accessible Nodes 2729 container supported-hash-algorithms { 2730 config false; 2731 description 2732 "A container for a list of supported hash algorithms. 2733 How algorithms come to be supported is outside the 2734 scope of this module."; 2735 list supported-hash-algorithm { 2736 key algorithm; 2737 description 2738 "A lists of hash algorithms supported by the server."; 2739 leaf algorithm { 2740 type hash-algorithm-type; 2741 description 2742 "An hash algorithms supported by the server."; 2743 } 2744 } 2745 } 2747 } 2749 2751 Appendix B. Change Log 2753 B.1. I-D to 00 2755 o Removed groupings and notifications. 2757 o Added typedefs for identityrefs. 2759 o Added typedefs for other RFC 5280 structures. 2761 o Added typedefs for other RFC 5652 structures. 2763 o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2765 B.2. 00 to 01 2767 o Moved groupings from the draft-ietf-netconf-keystore here. 2769 B.3. 01 to 02 2771 o Removed unwanted "mandatory" and "must" statements. 2773 o Added many new crypto algorithms (thanks Haiguang!) 2774 o Clarified in asymmetric-key-pair-with-certs-grouping, in 2775 certificates/certificate/name/description, that if the name MUST 2776 NOT match the name of a certificate that exists independently in 2777 , enabling certs installed by the manufacturer (e.g., 2778 an IDevID). 2780 B.4. 02 to 03 2782 o renamed base identity 'asymmetric-key-encryption-algorithm' to 2783 'asymmetric-key-algorithm'. 2785 o added new 'asymmetric-key-algorithm' identities for secp192r1, 2786 secp224r1, secp256r1, secp384r1, and secp521r1. 2788 o removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2789 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2790 aes-256-gcm, and mac-chacha20-poly1305. 2792 o for all -cbc and -ctr identities, renamed base identity 2793 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2795 o for all -ccm and -gcm identities, renamed base identity 2796 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2797 algorithm' and renamed the identity to remove the "enc-" prefix. 2799 o for all the 'signature-algorithm' based identities, renamed from 2800 'rsa-*' to 'rsassa-*'. 2802 o removed all of the "x509v3-" prefixed 'signature-algorithm' based 2803 identities. 2805 o added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2806 and 'rsaes-pkcs1-v1_5'. 2808 o renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2809 'symmetric-key-algorithm-ref'. 2811 o renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2812 'asymmetric-key-algorithm-ref'. 2814 o added typedef 'encryption-and-mac-algorithm-ref'. 2816 o Updated copyright date, boilerplate template, affiliation, and 2817 folding algorithm. 2819 B.5. 03 to 04 2821 o ran YANG module through formatter. 2823 B.6. 04 to 05 2825 o fixed broken symlink causing reformatted YANG module to not show. 2827 B.7. 05 to 06 2829 o Added NACM annotations. 2831 o Updated Security Considerations section. 2833 o Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2835 o Removed text from 'permanently-hidden' enum regarding such keys 2836 not being backed up or restored. 2838 o Updated the boilerplate text in module-level "description" 2839 statement to match copyeditor convention. 2841 o Added an explanation to the 'public-key-grouping' and 'asymmetric- 2842 key-pair-grouping' statements as for why the nodes are not 2843 mandatory (e.g., because they may exist only in . 2845 o Added 'must' expressions to the 'public-key-grouping' and 2846 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2847 are either all exist or do not all exist. 2849 o Added an explanation to the 'permanently-hidden' that the value 2850 cannot be configured directly by clients and servers MUST fail any 2851 attempt to do so. 2853 o Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2854 grouping' (the plural form of existing groupings). 2856 o Now states that keys created in by the *-hidden-key 2857 actions are bound to the lifetime of the parent 'config true' 2858 node, and that subsequent invocations of either action results in 2859 a failure. 2861 B.8. 06 to 07 2863 o Added clarifications that implementations SHOULD assert that 2864 configured certificates contain the matching public key. 2866 o Replaced the 'generate-hidden-key' and 'install-hidden-key' 2867 actions with special 'crypt-hash' -like input/output values. 2869 B.9. 07 to 08 2871 o Removed the 'generate-key and 'hidden-key' features. 2873 o Added grouping symmetric-key-grouping 2875 o Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2876 statement for the keystone module to augment into, as well as 2877 replacing the 'union' with leafs (having different NACM settings. 2879 B.10. 08 to 09 2881 o Converting algorithm from identities to enumerations. 2883 B.11. 09 to 10 2885 o All of the below changes are to the algorithm enumerations defined 2886 in ietf-crypto-types. 2888 o Add in support for key exchange over x.25519 and x.448 based on 2889 RFC 8418. 2891 o Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2893 o Revise/add in enum of signature algorithm for x25519 and x448 2895 o Add in des3-cbc-sha1 for IPSec 2897 o Add in sha1-des3-kd for IPSec 2899 o Add in definit for rc4-hmac and rc4-hmac-exp. These two 2900 algorithms have been deprecated in RFC 8429. But some existing 2901 draft in i2nsf may still want to use them. 2903 o Add x25519 and x448 curve for asymmetric algorithms 2905 o Add signature algorithms ed25519, ed25519-cts, ed25519ph 2907 o add signature algorithms ed448, ed448ph 2909 o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2911 B.12. 10 to 11 2913 o Added a "key-format" identity. 2915 o Added symmetric keys to the example in Section 2.3. 2917 B.13. 11 to 12 2919 o Removed all non-essential (to NC/RC) algorithm types. 2921 o Moved remaining algorithm types each into its own module. 2923 o Added a 'config false' "algorithms-supported" list to each of the 2924 algorithm-type modules. 2926 B.14. 12 to 13 2928 o Added the four features: "[encrypted-]one-[a]symmetric-key- 2929 format", each protecting a 'key-format' identity of the same name. 2931 o Added 'must' expressions asserting that the 'key-format' leaf 2932 exists whenever a non-hidden key is specified. 2934 o Improved the 'description' statements and added 'reference' 2935 statements for the 'key-format' identities. 2937 o Added a questionable forward reference to "encrypted-*" leafs in a 2938 couple 'when' expressions. 2940 o Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 2942 B.15. 13 to 14 2944 o Resolved the "FIXME: forward ref" issue by modulating 'must', 2945 'when', and 'mandatory' expressions. 2947 o Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' 2948 actions from ietf-keystore to ietf-crypto-types, now as RPCs. 2950 o Cleaned up various description statements and removed lingering 2951 FIXMEs. 2953 o Converted the "iana--algs" YANG modules to IANA 2954 registries with instructions for how to generate modules from the 2955 registries, whenever they may be updated. 2957 Acknowledgements 2959 The authors would like to thank for following for lively discussions 2960 on list and in the halls (ordered by last name): Martin Bjorklund, 2961 Nick Hancock, Balazs Kovacs, Juergen Schoenwaelder, Eric Voit, and 2962 Liang Xia. 2964 Authors' Addresses 2966 Kent Watsen 2967 Watsen Networks 2969 EMail: kent+ietf@watsen.net 2971 Wang Haiguang 2972 Huawei 2974 EMail: wang.haiguang.shieldlab@huawei.com