idnits 2.17.1 draft-ietf-netconf-crypto-types-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 177 has weird spacing: '...on-date yan...' == Line 181 has weird spacing: '...on-date yan...' == Line 185 has weird spacing: '...on-date yan...' == Line 189 has weird spacing: '...on-date yan...' == Line 204 has weird spacing: '...on-date yan...' == (8 more instances...) -- The document date (November 1, 2019) is 1636 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 informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: May 4, 2020 Huawei 6 November 1, 2019 8 Common YANG Data Types for Cryptography 9 draft-ietf-netconf-crypto-types-12 11 Abstract 13 This document defines four YANG modules for types useful to 14 cryptographic applications. The modules defined include: 16 o ietf-crypto-types 18 o iana-symmetric-algs 20 o iana-asymmetric-algs 22 o iana-hash-algs 24 Editorial Note (To be removed by RFC Editor) 26 This draft contains many placeholder values that need to be replaced 27 with finalized values at the time of publication. This note 28 summarizes all of the substitutions that are needed. No other RFC 29 Editor instructions are specified elsewhere in this document. 31 Artwork in this document contains shorthand references to drafts in 32 progress. Please apply the following replacements: 34 o "XXXX" --> the assigned RFC value for this draft 36 Artwork in this document contains placeholder values for the date of 37 publication of this draft. Please apply the following replacement: 39 o "2019-11-02" --> the publication date of this draft 41 The following Appendix section is to be removed prior to publication: 43 o Appendix B. Change Log 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on May 4, 2020. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. The Crypto Types Module . . . . . . . . . . . . . . . . . . . 4 81 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 82 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 84 3. The Symmetric Algorithms Module . . . . . . . . . . . . . . . 27 85 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 86 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 87 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 31 88 4. The Asymmetric Algorithms Module . . . . . . . . . . . . . . 31 89 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 31 90 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 32 91 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 36 92 5. The Hash Algorithms Module . . . . . . . . . . . . . . . . . 36 93 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 36 94 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 36 95 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 97 6.1. Support for Algorithms . . . . . . . . . . . . . . . . . 40 98 6.2. No Support for CRMF . . . . . . . . . . . . . . . . . . . 41 99 6.3. Access to Data Nodes . . . . . . . . . . . . . . . . . . 41 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 101 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 42 102 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 43 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 43 105 8.2. Informative References . . . . . . . . . . . . . . . . . 46 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 49 107 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 49 108 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 49 109 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 49 110 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 49 111 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 50 112 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 50 113 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 50 114 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 51 115 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 51 116 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 51 117 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 51 118 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 52 119 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 52 120 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 52 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 123 1. Introduction 125 This document defines four YANG 1.1 [RFC7950] modules for types 126 useful to cryptographic applications. The modules defined include: 128 o ietf-crypto-types 130 o iana-symmetric-algs 132 o iana-asymmetric-algs 134 o iana-hash-algs 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. The Crypto Types Module 144 2.1. Tree Diagram 146 This section provides a tree diagram [RFC8340] for the "ietf-crypto- 147 types" module. Only "grouping" statements are represented, as tree 148 diagrams have no means to represent identities or typedefs. 150 module: ietf-crypto-types 152 grouping symmetric-key-grouping 153 +-- algorithm isa:symmetric-algorithm-type 154 +-- key-format? identityref 155 +-- (key-type) 156 +--:(key) 157 | +-- key? binary 158 +--:(hidden-key) 159 +-- hidden-key? empty 160 grouping public-key-grouping 161 +-- algorithm iasa:asymmetric-algorithm-type 162 +-- public-key-format? identityref 163 +-- public-key binary 164 grouping asymmetric-key-pair-grouping 165 +-- algorithm iasa:asymmetric-algorithm-type 166 +-- public-key-format? identityref 167 +-- public-key binary 168 +-- private-key-format? identityref 169 +-- (private-key-type) 170 +--:(private-key) 171 | +-- private-key? binary 172 +--:(hidden-private-key) 173 +-- hidden-private-key? empty 174 grouping trust-anchor-cert-grouping 175 +-- cert? trust-anchor-cert-cms 176 +---n certificate-expiration 177 +-- expiration-date yang:date-and-time 178 grouping trust-anchor-certs-grouping 179 +-- cert* trust-anchor-cert-cms 180 +---n certificate-expiration 181 +-- expiration-date yang:date-and-time 182 grouping end-entity-cert-grouping 183 +-- cert? end-entity-cert-cms 184 +---n certificate-expiration 185 +-- expiration-date yang:date-and-time 186 grouping end-entity-certs-grouping 187 +-- cert* end-entity-cert-cms 188 +---n certificate-expiration 189 +-- expiration-date yang:date-and-time 191 grouping asymmetric-key-pair-with-cert-grouping 192 +-- algorithm 193 | iasa:asymmetric-algorithm-type 194 +-- public-key-format? identityref 195 +-- public-key binary 196 +-- private-key-format? identityref 197 +-- (private-key-type) 198 | +--:(private-key) 199 | | +-- private-key? binary 200 | +--:(hidden-private-key) 201 | +-- hidden-private-key? empty 202 +-- cert? end-entity-cert-cms 203 +---n certificate-expiration 204 | +-- expiration-date yang:date-and-time 205 +---x generate-certificate-signing-request 206 +---w input 207 | +---w subject binary 208 | +---w attributes? binary 209 +--ro output 210 +--ro certificate-signing-request binary 211 grouping asymmetric-key-pair-with-certs-grouping 212 +-- algorithm 213 | iasa:asymmetric-algorithm-type 214 +-- public-key-format? identityref 215 +-- public-key binary 216 +-- private-key-format? identityref 217 +-- (private-key-type) 218 | +--:(private-key) 219 | | +-- private-key? binary 220 | +--:(hidden-private-key) 221 | +-- hidden-private-key? empty 222 +-- certificates 223 | +-- certificate* [name] 224 | +-- name? string 225 | +-- cert? end-entity-cert-cms 226 | +---n certificate-expiration 227 | +-- expiration-date yang:date-and-time 228 +---x generate-certificate-signing-request 229 +---w input 230 | +---w subject binary 231 | +---w attributes? binary 232 +--ro output 233 +--ro certificate-signing-request binary 235 2.2. YANG Module 237 This module has normative references to [RFC2404], [RFC3565], 238 [RFC3686], [RFC4106], [RFC4253], [RFC4279], [RFC4309], [RFC4494], 239 [RFC4543], [RFC4868], [RFC5280], [RFC5652], [RFC5656], [RFC6187], 240 [RFC6991], [RFC7919], [RFC8268], [RFC8332], [RFC8341], [RFC8422], 241 [RFC8446], and [ITU.X690.2015]. 243 This module has an informational reference to [RFC2986], [RFC3174], 244 [RFC4493], [RFC5915], [RFC6125], [RFC6234], [RFC6239], [RFC6507], 245 [RFC8017], [RFC8032], [RFC8439]. 247 file "ietf-crypto-types@2019-11-02.yang" 249 module ietf-crypto-types { 250 yang-version 1.1; 251 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 252 prefix ct; 254 import ietf-yang-types { 255 prefix yang; 256 reference 257 "RFC 6991: Common YANG Data Types"; 258 } 260 import ietf-netconf-acm { 261 prefix nacm; 262 reference 263 "RFC 8341: Network Configuration Access Control Model"; 264 } 266 //import iana-hash-algs { 267 // prefix iha; 268 // reference 269 // "RFC XXXX: Common YANG Data Types for Cryptography"; 270 //} 272 import iana-symmetric-algs { 273 prefix isa; 274 reference 275 "RFC XXXX: Common YANG Data Types for Cryptography"; 276 } 278 import iana-asymmetric-algs { 279 prefix iasa; 280 reference 281 "RFC XXXX: Common YANG Data Types for Cryptography"; 282 } 283 organization 284 "IETF NETCONF (Network Configuration) Working Group"; 286 contact 287 "WG Web: 288 WG List: 289 Author: Kent Watsen 290 Author: Wang Haiguang "; 292 description 293 "This module defines common YANG types for cryptographic 294 applications. 296 Copyright (c) 2019 IETF Trust and the persons identified 297 as authors of the code. All rights reserved. 299 Redistribution and use in source and binary forms, with 300 or without modification, is permitted pursuant to, and 301 subject to the license terms contained in, the Simplified 302 BSD License set forth in Section 4.c of the IETF Trust's 303 Legal Provisions Relating to IETF Documents 304 (https://trustee.ietf.org/license-info). 306 This version of this YANG module is part of RFC XXXX 307 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 308 itself for full legal notices.; 310 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 311 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 312 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 313 are to be interpreted as described in BCP 14 (RFC 2119) 314 (RFC 8174) when, and only when, they appear in all 315 capitals, as shown here."; 317 revision 2019-11-02 { 318 description 319 "Initial version"; 320 reference 321 "RFC XXXX: Common YANG Data Types for Cryptography"; 322 } 324 /********************************************/ 325 /* Identities for Key Format Structures */ 326 /********************************************/ 328 /*** all key format types ****/ 330 identity key-format-base { 331 description "Base key-format identity for all keys."; 332 } 334 identity public-key-format { 335 base "key-format-base"; 336 description "Base key-format identity for public keys."; 337 } 339 identity private-key-format { 340 base "key-format-base"; 341 description "Base key-format identity for private keys."; 342 } 344 identity symmetric-key-format { 345 base "key-format-base"; 346 description "Base key-format identity for symmetric keys."; 347 } 349 /**** for private keys ****/ 351 identity rsa-private-key-format { 352 base "private-key-format"; 353 description "An RSAPrivateKey (from RFC 3447)."; 354 } 356 identity ec-private-key-format { 357 base "private-key-format"; 358 description "An ECPrivateKey (from RFC 5915)"; 359 } 361 identity one-asymmetric-key-format { 362 base "private-key-format"; 363 description "A OneAsymmetricKey (from RFC 5958)."; 364 } 366 identity encrypted-private-key-format { 367 base "private-key-format"; 368 description 369 "A CMS EncryptedData structure (RFC 5652) 370 containing a OneAsymmetricKey (RFC 5958)."; 371 } 373 /**** for public keys ****/ 375 identity ssh-public-key-format { 376 base "public-key-format"; 377 description 378 "The public key format described by RFC 4716."; 379 } 381 identity subject-public-key-info-format { 382 base "public-key-format"; 383 description 384 "A SubjectPublicKeyInfo (from RFC 5280)."; 385 } 387 /**** for symmetric keys ****/ 389 identity octet-string-key-format { 390 base "symmetric-key-format"; 391 description "An OctetString from ASN.1."; 392 /* 393 // Knowing that it is an "OctetString" isn't really helpful. 394 // Knowing the length of the octet string would be helpful, 395 // as it relates to the algorithm's block size. We may want 396 // to only (for now) use "one-symmetric-key-format" for 397 // symmetric keys...were the usability issues Juergen 398 // mentioned before only apply to asymmetric keys? 399 */ 400 } 402 identity one-symmetric-key-format { 403 base "symmetric-key-format"; 404 description "A OneSymmetricKey (from RFC6031)."; 405 } 407 identity encrypted-symmetric-key-format { 408 base "symmetric-key-format"; 409 description 410 "A CMS EncryptedData structure (RFC 5652) 411 containing a OneSymmetricKey (RFC 6031)."; 412 } 414 /***************************************************/ 415 /* Typedefs for ASN.1 structures from RFC 5280 */ 416 /***************************************************/ 418 typedef x509 { 419 type binary; 420 description 421 "A Certificate structure, as specified in RFC 5280, 422 encoded using ASN.1 distinguished encoding rules (DER), 423 as specified in ITU-T X.690."; 424 reference 425 "RFC 5280: 426 Internet X.509 Public Key Infrastructure Certificate 427 and Certificate Revocation List (CRL) Profile 428 ITU-T X.690: 429 Information technology - ASN.1 encoding rules: 430 Specification of Basic Encoding Rules (BER), 431 Canonical Encoding Rules (CER) and Distinguished 432 Encoding Rules (DER)."; 433 } 435 typedef crl { 436 type binary; 437 description 438 "A CertificateList structure, as specified in RFC 5280, 439 encoded using ASN.1 distinguished encoding rules (DER), 440 as specified in ITU-T X.690."; 441 reference 442 "RFC 5280: 443 Internet X.509 Public Key Infrastructure Certificate 444 and Certificate Revocation List (CRL) Profile 445 ITU-T X.690: 446 Information technology - ASN.1 encoding rules: 447 Specification of Basic Encoding Rules (BER), 448 Canonical Encoding Rules (CER) and Distinguished 449 Encoding Rules (DER)."; 450 } 452 /***********************************************/ 453 /* Typedefs for ASN.1 structures from 5652 */ 454 /***********************************************/ 456 typedef cms { 457 type binary; 458 description 459 "A ContentInfo structure, as specified in RFC 5652, 460 encoded using ASN.1 distinguished encoding rules (DER), 461 as specified in ITU-T X.690."; 462 reference 463 "RFC 5652: 464 Cryptographic Message Syntax (CMS) 465 ITU-T X.690: 466 Information technology - ASN.1 encoding rules: 467 Specification of Basic Encoding Rules (BER), 468 Canonical Encoding Rules (CER) and Distinguished 469 Encoding Rules (DER)."; 471 } 473 typedef data-content-cms { 474 type cms; 475 description 476 "A CMS structure whose top-most content type MUST be the 477 data content type, as described by Section 4 in RFC 5652."; 478 reference 479 "RFC 5652: Cryptographic Message Syntax (CMS)"; 480 } 482 typedef signed-data-cms { 483 type cms; 484 description 485 "A CMS structure whose top-most content type MUST be the 486 signed-data content type, as described by Section 5 in 487 RFC 5652."; 488 reference 489 "RFC 5652: Cryptographic Message Syntax (CMS)"; 490 } 492 typedef enveloped-data-cms { 493 type cms; 494 description 495 "A CMS structure whose top-most content type MUST be the 496 enveloped-data content type, as described by Section 6 497 in RFC 5652."; 498 reference 499 "RFC 5652: Cryptographic Message Syntax (CMS)"; 500 } 502 typedef digested-data-cms { 503 type cms; 504 description 505 "A CMS structure whose top-most content type MUST be the 506 digested-data content type, as described by Section 7 507 in RFC 5652."; 508 reference 509 "RFC 5652: Cryptographic Message Syntax (CMS)"; 510 } 512 typedef encrypted-data-cms { 513 type cms; 514 description 515 "A CMS structure whose top-most content type MUST be the 516 encrypted-data content type, as described by Section 8 517 in RFC 5652."; 518 reference 519 "RFC 5652: Cryptographic Message Syntax (CMS)"; 520 } 522 typedef authenticated-data-cms { 523 type cms; 524 description 525 "A CMS structure whose top-most content type MUST be the 526 authenticated-data content type, as described by Section 9 527 in RFC 5652."; 528 reference 529 "RFC 5652: Cryptographic Message Syntax (CMS)"; 530 } 532 /***************************************************/ 533 /* Typedefs for structures related to !!FIXME!! */ 534 /***************************************************/ 536 typedef psk { 537 type binary; 538 description 539 "The binary key data for a PSK (pairwise-symmetric or 540 pre-shared key). FIXME: specify how it is formmated."; 541 } 543 typedef raw-public-key { 544 type binary; 545 description 546 "The binary key data for a raw public key. 547 FIXME: specify how it is formmated."; 548 } 550 /***************************************************/ 551 /* Typedefs for structures related to RFC 4253 */ 552 /***************************************************/ 554 typedef ssh-host-key { 555 type binary; 556 description 557 "The binary public key data for an SSH key, as 558 specified by RFC 4253, Section 6.6, i.e.: 560 string certificate or public key format 561 identifier 562 byte[n] key/certificate data."; 563 reference 564 "RFC 4253: The Secure Shell (SSH) Transport Layer 565 Protocol"; 566 } 567 /*********************************************************/ 568 /* Typedefs for ASN.1 structures related to RFC 5280 */ 569 /*********************************************************/ 571 typedef trust-anchor-cert-x509 { 572 type x509; 573 description 574 "A Certificate structure that MUST encode a self-signed 575 root certificate."; 576 } 578 typedef end-entity-cert-x509 { 579 type x509; 580 description 581 "A Certificate structure that MUST encode a certificate 582 that is neither self-signed nor having Basic constraint 583 CA true."; 584 } 586 /*********************************************************/ 587 /* Typedefs for ASN.1 structures related to RFC 5652 */ 588 /*********************************************************/ 590 typedef trust-anchor-cert-cms { 591 type signed-data-cms; 592 description 593 "A CMS SignedData structure that MUST contain the chain of 594 X.509 certificates needed to authenticate the certificate 595 presented by a client or end-entity. 597 The CMS MUST contain only a single chain of certificates. 598 The client or end-entity certificate MUST only authenticate 599 to last intermediate CA certificate listed in the chain. 601 In all cases, the chain MUST include a self-signed root 602 certificate. In the case where the root certificate is 603 itself the issuer of the client or end-entity certificate, 604 only one certificate is present. 606 This CMS structure MAY (as applicable where this type is 607 used) also contain suitably fresh (as defined by local 608 policy) revocation objects with which the device can 609 verify the revocation status of the certificates. 611 This CMS encodes the degenerate form of the SignedData 612 structure that is commonly used to disseminate X.509 613 certificates and revocation objects (RFC 5280)."; 614 reference 615 "RFC 5280: 616 Internet X.509 Public Key Infrastructure Certificate 617 and Certificate Revocation List (CRL) Profile."; 618 } 620 typedef end-entity-cert-cms { 621 type signed-data-cms; 622 description 623 "A CMS SignedData structure that MUST contain the end 624 entity certificate itself, and MAY contain any number 625 of intermediate certificates leading up to a trust 626 anchor certificate. The trust anchor certificate 627 MAY be included as well. 629 The CMS MUST contain a single end entity certificate. 630 The CMS MUST NOT contain any spurious certificates. 632 This CMS structure MAY (as applicable where this type is 633 used) also contain suitably fresh (as defined by local 634 policy) revocation objects with which the device can 635 verify the revocation status of the certificates. 637 This CMS encodes the degenerate form of the SignedData 638 structure that is commonly used to disseminate X.509 639 certificates and revocation objects (RFC 5280)."; 640 reference 641 "RFC 5280: 642 Internet X.509 Public Key Infrastructure Certificate 643 and Certificate Revocation List (CRL) Profile."; 644 } 646 typedef ssh-public-key-type { // DELETE? 647 type binary; 648 description 649 "The binary public key data for this SSH key, as 650 specified by RFC 4253, Section 6.6, i.e.: 652 string certificate or public key format 653 identifier 654 byte[n] key/certificate data."; 655 reference 656 "RFC 4253: The Secure Shell (SSH) Transport 657 Layer Protocol"; 658 } 660 /**********************************************/ 661 /* Groupings for keys and/or certificates */ 662 /**********************************************/ 663 grouping symmetric-key-grouping { 664 description 665 "A symmetric key and algorithm."; 666 leaf algorithm { 667 type isa:symmetric-algorithm-type; 668 mandatory true; 669 description 670 "The algorithm to be used when generating the key."; 671 reference 672 "RFC CCCC: Common YANG Data Types for Cryptography"; 673 } 674 leaf key-format { 675 nacm:default-deny-write; 676 when "../key"; 677 type identityref { 678 base symmetric-key-format; 679 } 680 description "Identifies the symmetric key's format."; 681 } 682 choice key-type { 683 mandatory true; 684 description 685 "Choice between key types."; 686 leaf key { 687 nacm:default-deny-all; 688 type binary; 689 //must "../key-format"; FIXME: remove comment if approach ok 690 description 691 "The binary value of the key. The interpretation of 692 the value is defined by 'key-format'. For example, 693 FIXME."; 694 reference 695 "RFC XXXX: FIXME"; 696 } 697 leaf hidden-key { 698 nacm:default-deny-write; 699 type empty; 700 description 701 "A permanently hidden key. How such keys are created 702 is outside the scope of this module."; 703 } 704 } 705 } 707 grouping public-key-grouping { 708 description 709 "A public key and its associated algorithm."; 710 leaf algorithm { 711 nacm:default-deny-write; 712 type iasa:asymmetric-algorithm-type; 713 mandatory true; 714 description 715 "Identifies the key's algorithm."; 716 reference 717 "RFC CCCC: Common YANG Data Types for Cryptography"; 718 } 719 leaf public-key-format { 720 nacm:default-deny-write; 721 when "../public-key"; 722 type identityref { 723 base public-key-format; 724 } 725 description "Identifies the key's format."; 726 } 727 leaf public-key { 728 nacm:default-deny-write; 729 type binary; 730 //must "../public-key-format"; FIXME: rm comment if approach ok 731 mandatory true; 732 description 733 "The binary value of the public key. The interpretation 734 of the value is defined by 'public-key-format' field."; 735 } 736 } 738 grouping asymmetric-key-pair-grouping { 739 description 740 "A private key and its associated public key and algorithm."; 741 uses public-key-grouping; 742 leaf private-key-format { 743 nacm:default-deny-write; 744 when "../private-key"; 745 type identityref { 746 base private-key-format; 747 } 748 description "Identifies the key's format."; 749 } 750 choice private-key-type { 751 mandatory true; 752 description 753 "Choice between key types."; 754 leaf private-key { 755 nacm:default-deny-all; 756 type binary; 757 //must "../private-key-format"; FIXME: rm comment if ok 758 description 759 "The value of the binary key. The key's value is 760 interpreted by the 'private-key-format' field."; 761 } 762 leaf hidden-private-key { 763 nacm:default-deny-write; 764 type empty; 765 description 766 "A permanently hidden key. How such keys are created 767 is outside the scope of this module."; 768 } 769 } 770 } 772 grouping trust-anchor-cert-grouping { 773 description 774 "A trust anchor certificate, and a notification for when 775 it is about to (or already has) expire."; 776 leaf cert { 777 nacm:default-deny-write; 778 type trust-anchor-cert-cms; 779 description 780 "The binary certificate data for this certificate."; 781 reference 782 "RFC YYYY: Common YANG Data Types for Cryptography"; 783 } 784 notification certificate-expiration { 785 description 786 "A notification indicating that the configured certificate 787 is either about to expire or has already expired. When to 788 send notifications is an implementation specific decision, 789 but it is RECOMMENDED that a notification be sent once a 790 month for 3 months, then once a week for four weeks, and 791 then once a day thereafter until the issue is resolved."; 792 leaf expiration-date { 793 type yang:date-and-time; 794 mandatory true; 795 description 796 "Identifies the expiration date on the certificate."; 797 } 798 } 799 } 801 grouping trust-anchor-certs-grouping { 802 description 803 "A list of trust anchor certificates, and a notification 804 for when one is about to (or already has) expire."; 805 leaf-list cert { 806 nacm:default-deny-write; 807 type trust-anchor-cert-cms; 808 description 809 "The binary certificate data for this certificate."; 810 reference 811 "RFC YYYY: Common YANG Data Types for Cryptography"; 812 } 813 notification certificate-expiration { 814 description 815 "A notification indicating that the configured certificate 816 is either about to expire or has already expired. When to 817 send notifications is an implementation specific decision, 818 but it is RECOMMENDED that a notification be sent once a 819 month for 3 months, then once a week for four weeks, and 820 then once a day thereafter until the issue is resolved."; 821 leaf expiration-date { 822 type yang:date-and-time; 823 mandatory true; 824 description 825 "Identifies the expiration date on the certificate."; 826 } 827 } 828 } 830 grouping end-entity-cert-grouping { 831 description 832 "An end entity certificate, and a notification for when 833 it is about to (or already has) expire. Implementations 834 SHOULD assert that, where used, the end entity certificate 835 contains the expected public key."; 836 leaf cert { 837 nacm:default-deny-write; 838 type end-entity-cert-cms; 839 description 840 "The binary certificate data for this certificate."; 841 reference 842 "RFC YYYY: Common YANG Data Types for Cryptography"; 843 } 844 notification certificate-expiration { 845 description 846 "A notification indicating that the configured certificate 847 is either about to expire or has already expired. When to 848 send notifications is an implementation specific decision, 849 but it is RECOMMENDED that a notification be sent once a 850 month for 3 months, then once a week for four weeks, and 851 then once a day thereafter until the issue is resolved."; 852 leaf expiration-date { 853 type yang:date-and-time; 854 mandatory true; 855 description 856 "Identifies the expiration date on the certificate."; 857 } 858 } 859 } 861 grouping end-entity-certs-grouping { 862 description 863 "A list of end entity certificates, and a notification for 864 when one is about to (or already has) expire."; 865 leaf-list cert { 866 nacm:default-deny-write; 867 type end-entity-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 asymmetric-key-pair-with-cert-grouping { 891 description 892 "A private/public key pair and an associated certificate. 893 Implementations SHOULD assert that certificates contain 894 the matching public key."; 895 uses asymmetric-key-pair-grouping; 896 uses end-entity-cert-grouping; 897 action generate-certificate-signing-request { 898 nacm:default-deny-all; 899 description 900 "Generates a certificate signing request structure for 901 the associated asymmetric key using the passed subject 902 and attribute values. The specified assertions need 903 to be appropriate for the certificate's use. For 904 example, an entity certificate for a TLS server 905 SHOULD have values that enable clients to satisfy 906 RFC 6125 processing."; 907 input { 908 leaf subject { 909 type binary; 910 mandatory true; 911 description 912 "The 'subject' field per the CertificationRequestInfo 913 structure as specified by RFC 2986, Section 4.1 914 encoded using the ASN.1 distinguished encoding 915 rules (DER), as specified in ITU-T X.690."; 916 reference 917 "RFC 2986: 918 PKCS #10: Certification Request Syntax 919 Specification Version 1.7. 920 ITU-T X.690: 921 Information technology - ASN.1 encoding rules: 922 Specification of Basic Encoding Rules (BER), 923 Canonical Encoding Rules (CER) and Distinguished 924 Encoding Rules (DER)."; 925 } 926 leaf attributes { 927 type binary; // FIXME: does this need to be mandatory? 928 description 929 "The 'attributes' field from the structure 930 CertificationRequestInfo as specified by RFC 2986, 931 Section 4.1 encoded using the ASN.1 distinguished 932 encoding rules (DER), as specified in ITU-T X.690."; 933 reference 934 "RFC 2986: 935 PKCS #10: Certification Request Syntax 936 Specification Version 1.7. 937 ITU-T X.690: 938 Information technology - ASN.1 encoding rules: 939 Specification of Basic Encoding Rules (BER), 940 Canonical Encoding Rules (CER) and Distinguished 941 Encoding Rules (DER)."; 942 } 943 } 944 output { 945 leaf certificate-signing-request { 946 type binary; 947 mandatory true; 948 description 949 "A CertificationRequest structure as specified by 950 RFC 2986, Section 4.2 encoded using the ASN.1 951 distinguished encoding rules (DER), as specified 952 in ITU-T X.690."; 953 reference 954 "RFC 2986: 955 PKCS #10: Certification Request Syntax 956 Specification Version 1.7. 957 ITU-T X.690: 958 Information technology - ASN.1 encoding rules: 959 Specification of Basic Encoding Rules (BER), 960 Canonical Encoding Rules (CER) and Distinguished 961 Encoding Rules (DER)."; 962 } 963 } 964 } // generate-certificate-signing-request 965 } // asymmetric-key-pair-with-cert-grouping 967 grouping asymmetric-key-pair-with-certs-grouping { 968 description 969 "A private/public key pair and associated certificates. 970 Implementations SHOULD assert that certificates contain 971 the matching public key."; 972 uses asymmetric-key-pair-grouping; 973 container certificates { 974 nacm:default-deny-write; 975 description 976 "Certificates associated with this asymmetric key. 977 More than one certificate supports, for instance, 978 a TPM-protected asymmetric key that has both IDevID 979 and LDevID certificates associated."; 980 list certificate { 981 key "name"; 982 description 983 "A certificate for this asymmetric key."; 984 leaf name { 985 type string; 986 description 987 "An arbitrary name for the certificate. If the name 988 matches the name of a certificate that exists 989 independently in (i.e., an IDevID), 990 then the 'cert' node MUST NOT be configured."; 991 } 992 uses end-entity-cert-grouping; 993 } 994 } // certificates 995 action generate-certificate-signing-request { 996 nacm:default-deny-all; 997 description 998 "Generates a certificate signing request structure for 999 the associated asymmetric key using the passed subject 1000 and attribute values. The specified assertions need 1001 to be appropriate for the certificate's use. For 1002 example, an entity certificate for a TLS server 1003 SHOULD have values that enable clients to satisfy 1004 RFC 6125 processing."; 1005 input { 1006 leaf subject { 1007 type binary; 1008 mandatory true; 1009 description 1010 "The 'subject' field per the CertificationRequestInfo 1011 structure as specified by RFC 2986, Section 4.1 1012 encoded using the ASN.1 distinguished encoding 1013 rules (DER), as specified in ITU-T X.690."; 1014 reference 1015 "RFC 2986: 1016 PKCS #10: Certification Request Syntax 1017 Specification Version 1.7. 1018 ITU-T X.690: 1019 Information technology - ASN.1 encoding rules: 1020 Specification of Basic Encoding Rules (BER), 1021 Canonical Encoding Rules (CER) and Distinguished 1022 Encoding Rules (DER)."; 1023 } 1024 leaf attributes { 1025 type binary; // FIXME: does this need to be mandatory? 1026 description 1027 "The 'attributes' field from the structure 1028 CertificationRequestInfo as specified by RFC 2986, 1029 Section 4.1 encoded using the ASN.1 distinguished 1030 encoding rules (DER), as specified in ITU-T X.690."; 1031 reference 1032 "RFC 2986: 1033 PKCS #10: Certification Request Syntax 1034 Specification Version 1.7. 1035 ITU-T X.690: 1036 Information technology - ASN.1 encoding rules: 1037 Specification of Basic Encoding Rules (BER), 1038 Canonical Encoding Rules (CER) and Distinguished 1039 Encoding Rules (DER)."; 1040 } 1041 } 1042 output { 1043 leaf certificate-signing-request { 1044 type binary; 1045 mandatory true; 1046 description 1047 "A CertificationRequest structure as specified by 1048 RFC 2986, Section 4.2 encoded using the ASN.1 1049 distinguished encoding rules (DER), as specified 1050 in ITU-T X.690."; 1051 reference 1052 "RFC 2986: 1053 PKCS #10: Certification Request Syntax 1054 Specification Version 1.7. 1055 ITU-T X.690: 1056 Information technology - ASN.1 encoding rules: 1057 Specification of Basic Encoding Rules (BER), 1058 Canonical Encoding Rules (CER) and Distinguished 1059 Encoding Rules (DER)."; 1060 } 1061 } 1062 } // generate-certificate-signing-request 1063 } // asymmetric-key-pair-with-certs-grouping 1064 } 1066 1068 2.3. Examples 1070 2.3.1. The "asymmetric-key-pair-with-certs-grouping" Grouping 1072 The following example module illustrates the use of both the 1073 "symmetric-key-grouping" and the "asymmetric-key-pair-with-certs- 1074 grouping" groupings defined in the "ietf-crypto-types" module. 1076 module ex-crypto-types-usage { 1077 yang-version 1.1; 1079 namespace "http://example.com/ns/example-crypto-types-usage"; 1080 prefix "ectu"; 1082 import ietf-crypto-types { 1083 prefix ct; 1084 reference 1085 "RFC XXXX: Common YANG Data Types for Cryptography"; 1086 } 1088 organization 1089 "Example Corporation"; 1091 contact 1092 "Author: YANG Designer "; 1094 description 1095 "This module illustrates the grouping 1096 defined in the crypto-types draft called 1097 'asymmetric-key-pair-with-certs-grouping'."; 1099 revision "1001-01-01" { 1100 description 1101 "Initial version"; 1102 reference 1103 "RFC ????: Usage Example for RFC XXXX"; 1104 } 1106 container symmetric-keys { 1107 description 1108 "A container of symmetric keys."; 1109 list symmetric-key { 1110 key name; 1111 description 1112 "A symmetric key"; 1113 leaf name { 1114 type string; 1115 description 1116 "An arbitrary name for this key."; 1117 } 1118 uses ct:symmetric-key-grouping; 1119 } 1120 } 1121 container asymmetric-keys { 1122 description 1123 "A container of asymmetric keys."; 1124 list asymmetric-key { 1125 key name; 1126 leaf name { 1127 type string; 1128 description 1129 "An arbitrary name for this key."; 1130 } 1131 uses ct:asymmetric-key-pair-with-certs-grouping; 1132 description 1133 "An asymmetric key pair with associated certificates."; 1134 } 1135 } 1136 } 1138 Given the above example usage module, the following example 1139 illustrates some configured keys. 1141 1144 1145 ex-symmetric-key 1146 aes-256-cbc 1147 ct:octet-string-key-format 1148 base64encodedvalue== 1149 1150 1151 ex-hidden-symmetric-key 1152 aes-256-cbc 1153 1154 1155 1157 1160 1161 ex-asymmetric-key 1162 rsa2048 1163 1164 ct:subject-public-key-info-format 1165 1166 base64encodedvalue== 1167 1168 ct:rsa-private-key-format 1169 1170 base64encodedvalue== 1171 1172 1173 ex-cert 1174 base64encodedvalue== 1175 1176 1177 1178 1179 ex-hidden-asymmetric-key 1180 rsa2048 1181 1182 ct:subject-public-key-info-format 1183 1184 base64encodedvalue== 1185 1186 1187 1188 ex-hidden-key-cert 1189 base64encodedvalue== 1190 1192 1193 1194 1196 2.3.2. The "generate-certificate-signing-request" Action 1198 The following example illustrates the "generate-certificate-signing- 1199 request" action with the NETCONF protocol. 1201 REQUEST 1203 1205 1206 1208 1209 ex-key-sect571r1 1210 1211 base64encodedvalue== 1212 base64encodedvalue== 1213 1214 1215 1216 1217 1219 RESPONSE 1221 1223 1225 base64encodedvalue== 1226 1227 1229 2.3.3. The "certificate-expiration" Notification 1231 The following example illustrates the "certificate-expiration" 1232 notification with the NETCONF protocol. 1234 1236 2018-05-25T00:01:00Z 1237 1238 1239 locally-defined key 1240 1241 1242 my-cert 1243 1244 1245 2018-08-05T14:18:53-05:00 1246 1247 1248 1249 1250 1251 1252 1254 3. The Symmetric Algorithms Module 1256 3.1. Tree Diagram 1258 This section provides a tree diagram [RFC8340] for the "iana- 1259 symmetric-algs" module. Only the "container" statement is 1260 represented, as tree diagrams have no means to represent "typedef" 1261 statements. 1263 module: iana-symmetric-algs 1264 +--ro supported-symmetric-algorithms 1265 +--ro supported-symmetric-algorithm* [algorithm] 1266 +--ro algorithm symmetric-algorithm-type 1268 3.2. YANG Module 1270 This module has normative references to FIXME... 1272 file "iana-symmetric-algs@2019-11-02.yang" 1274 module iana-symmetric-algs { 1275 yang-version 1.1; 1276 namespace "urn:ietf:params:xml:ns:yang:iana-symmetric-algs"; 1277 prefix isa; 1279 organization 1280 "IETF NETCONF (Network Configuration) Working Group"; 1282 contact 1283 "WG Web: 1284 WG List: 1285 Author: Kent Watsen 1286 Author: Wang Haiguang "; 1288 description 1289 "This module defines a typedef for symmetric algorithms, and 1290 a container for a list of symmetric algorithms supported by 1291 the server. 1293 Copyright (c) 2019 IETF Trust and the persons identified 1294 as authors of the code. All rights reserved. 1295 Redistribution and use in source and binary forms, with 1296 or without modification, is permitted pursuant to, and 1297 subject to the license terms contained in, the Simplified 1298 BSD License set forth in Section 4.c of the IETF Trust's 1299 Legal Provisions Relating to IETF Documents 1300 (https://trustee.ietf.org/license-info). 1302 This version of this YANG module is part of RFC XXXX 1303 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1304 itself for full legal notices.; 1306 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1307 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1308 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1309 are to be interpreted as described in BCP 14 (RFC 2119) 1310 (RFC 8174) when, and only when, they appear in all 1311 capitals, as shown here."; 1313 revision 2019-11-02 { 1314 description 1315 "Initial version"; 1316 reference 1317 "RFC XXXX: Common YANG Data Types for Cryptography"; 1318 } 1320 // Typedefs 1322 typedef symmetric-algorithm-type { 1323 type enumeration { 1324 enum aes-128-cbc { 1325 value 1; 1326 description 1327 "Encrypt message with AES algorithm in CBC mode with 1328 a key length of 128 bits."; 1329 reference 1330 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1331 Encryption Algorithm in Cryptographic Message Syntax 1332 (CMS)"; 1333 } 1334 enum aes-192-cbc { 1335 value 2; 1336 description 1337 "Encrypt message with AES algorithm in CBC mode with 1338 a key length of 192 bits"; 1339 reference 1340 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1341 Encryption Algorithm in Cryptographic Message Syntax 1342 (CMS)"; 1343 } 1344 enum aes-256-cbc { 1345 value 3; 1346 description 1347 "Encrypt message with AES algorithm in CBC mode with 1348 a key length of 256 bits"; 1349 reference 1350 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1351 Encryption Algorithm in Cryptographic Message Syntax 1352 (CMS)"; 1353 } 1354 enum aes-128-ctr { 1355 value 4; 1356 description 1357 "Encrypt message with AES algorithm in CTR mode with 1358 a key length of 128 bits"; 1359 reference 1360 "RFC 3686: 1361 Using Advanced Encryption Standard (AES) Counter 1362 Mode with IPsec Encapsulating Security Payload 1363 (ESP)"; 1364 } 1365 enum aes-192-ctr { 1366 value 5; 1367 description 1368 "Encrypt message with AES algorithm in CTR mode with 1369 a key length of 192 bits"; 1370 reference 1371 "RFC 3686: 1372 Using Advanced Encryption Standard (AES) Counter 1373 Mode with IPsec Encapsulating Security Payload 1374 (ESP)"; 1375 } 1376 enum aes-256-ctr { 1377 value 6; 1378 description 1379 "Encrypt message with AES algorithm in CTR mode with 1380 a key length of 256 bits"; 1381 reference 1382 "RFC 3686: 1383 Using Advanced Encryption Standard (AES) Counter 1384 Mode with IPsec Encapsulating Security Payload 1385 (ESP)"; 1386 } 1387 enum des3-cbc-sha1-kd { 1388 value 7; 1389 description 1390 "Encrypt message with 3DES algorithm in CBC mode 1391 with sha1 function for key derivation"; 1392 reference 1393 "RFC 3961: 1394 Encryption and Checksum Specifications for 1395 Kerberos 5"; 1396 } 1397 enum rc4-hmac { 1398 value 8; 1399 description 1400 "Encrypt message with rc4 algorithm"; 1401 reference 1402 "RFC 4757: 1403 The RC4-HMAC Kerberos Encryption Types Used by 1404 Microsoft Windows"; 1405 } 1406 enum rc4-hmac-exp { 1407 value 9; 1408 description 1409 "Encrypt message with rc4 algorithm that is exportable"; 1410 reference 1411 "RFC 4757: 1412 The RC4-HMAC Kerberos Encryption Types Used by 1413 Microsoft Windows"; 1414 } 1415 } 1416 description 1417 "A typedef enumerating various symmetric key algorithms."; 1418 } 1420 // Protocol-accessible Nodes 1422 container supported-symmetric-algorithms { 1423 config false; 1424 description 1425 "A container for a list of supported symmetric algorithms. 1427 How algorithms come to be supported is outside the scope 1428 of this module."; 1429 list supported-symmetric-algorithm { 1430 key algorithm; 1431 description 1432 "A lists of symmetric algorithms supported by the server."; 1433 leaf algorithm { 1434 type symmetric-algorithm-type; 1435 description 1436 "An symmetric algorithms supported by the server."; 1437 } 1438 } 1439 } 1441 } 1443 1445 3.3. Examples 1447 The following example illustrates the "supported-symmetric- 1448 algorithms" "container" statement with the NETCONF protocol. 1450 1452 1453 aes-128-cbc 1454 1455 1456 aes-256-cbc 1457 1458 1460 4. The Asymmetric Algorithms Module 1462 4.1. Tree Diagram 1464 This section provides a tree diagram [RFC8340] for the "iana- 1465 asymmetric-algs" module. Only the "container" statement is 1466 represented, as tree diagrams have no means to represent "typedef" 1467 statements. 1469 module: iana-asymmetric-algs 1470 +--ro supported-asymmetric-algorithms 1471 +--ro supported-asymmetric-algorithm* [algorithm] 1472 +--ro algorithm asymmetric-algorithm-type 1474 4.2. YANG Module 1476 This module has normative references to FIXME... 1478 file "iana-asymmetric-algs@2019-11-02.yang" 1480 module iana-asymmetric-algs { 1481 yang-version 1.1; 1482 namespace "urn:ietf:params:xml:ns:yang:iana-asymmetric-algs"; 1483 prefix iasa; 1485 organization 1486 "IETF NETCONF (Network Configuration) Working Group"; 1488 contact 1489 "WG Web: 1490 WG List: 1491 Author: Kent Watsen 1492 Author: Wang Haiguang "; 1494 description 1495 "This module defines a typedef for asymmetric algorithms, and 1496 a container for a list of asymmetric algorithms supported by 1497 the server. 1499 Copyright (c) 2019 IETF Trust and the persons identified 1500 as authors of the code. All rights reserved. 1501 Redistribution and use in source and binary forms, with 1502 or without modification, is permitted pursuant to, and 1503 subject to the license terms contained in, the Simplified 1504 BSD License set forth in Section 4.c of the IETF Trust's 1505 Legal Provisions Relating to IETF Documents 1506 (https://trustee.ietf.org/license-info). 1508 This version of this YANG module is part of RFC XXXX 1509 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1510 itself for full legal notices.; 1512 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1513 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1514 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1515 are to be interpreted as described in BCP 14 (RFC 2119) 1516 (RFC 8174) when, and only when, they appear in all 1517 capitals, as shown here."; 1519 revision 2019-11-02 { 1520 description 1521 "Initial version"; 1523 reference 1524 "RFC XXXX: Common YANG Data Types for Cryptography"; 1525 } 1527 // Typedefs 1529 typedef asymmetric-algorithm-type { 1530 type enumeration { 1531 enum rsa1024 { 1532 value 1; 1533 description 1534 "The RSA algorithm using a 1024-bit key."; 1535 reference 1536 "RFC 8017: PKCS #1: RSA Cryptography 1537 Specifications Version 2.2."; 1538 } 1539 enum rsa2048 { 1540 value 2; 1541 description 1542 "The RSA algorithm using a 2048-bit key."; 1543 reference 1544 "RFC 8017: 1545 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1546 } 1547 enum rsa3072 { 1548 value 3; 1549 description 1550 "The RSA algorithm using a 3072-bit key."; 1551 reference 1552 "RFC 8017: 1553 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1554 } 1555 enum rsa4096 { 1556 value 4; 1557 description 1558 "The RSA algorithm using a 4096-bit key."; 1559 reference 1560 "RFC 8017: 1561 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1562 } 1563 enum rsa7680 { 1564 value 5; 1565 description 1566 "The RSA algorithm using a 7680-bit key."; 1567 reference 1568 "RFC 8017: 1569 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1570 } 1571 enum rsa15360 { 1572 value 6; 1573 description 1574 "The RSA algorithm using a 15360-bit key."; 1575 reference 1576 "RFC 8017: 1577 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1578 } 1579 enum secp192r1 { 1580 value 7; 1581 description 1582 "The asymmetric algorithm using a NIST P192 Curve."; 1583 reference 1584 "RFC 6090: 1585 Fundamental Elliptic Curve Cryptography Algorithms. 1586 RFC 5480: 1587 Elliptic Curve Cryptography Subject Public Key 1588 Information."; 1589 } 1590 enum secp224r1 { 1591 value 8; 1592 description 1593 "The asymmetric algorithm using a NIST P224 Curve."; 1594 reference 1595 "RFC 6090: 1596 Fundamental Elliptic Curve Cryptography Algorithms. 1597 RFC 5480: 1598 Elliptic Curve Cryptography Subject Public Key 1599 Information."; 1600 } 1601 enum secp256r1 { 1602 value 9; 1603 description 1604 "The asymmetric algorithm using a NIST P256 Curve."; 1605 reference 1606 "RFC 6090: 1607 Fundamental Elliptic Curve Cryptography Algorithms. 1608 RFC 5480: 1609 Elliptic Curve Cryptography Subject Public Key 1610 Information."; 1611 } 1612 enum secp384r1 { 1613 value 10; 1614 description 1615 "The asymmetric algorithm using a NIST P384 Curve."; 1616 reference 1617 "RFC 6090: 1618 Fundamental Elliptic Curve Cryptography Algorithms. 1620 RFC 5480: 1621 Elliptic Curve Cryptography Subject Public Key 1622 Information."; 1623 } 1624 enum secp521r1 { 1625 value 11; 1626 description 1627 "The asymmetric algorithm using a NIST P521 Curve."; 1628 reference 1629 "RFC 6090: 1630 Fundamental Elliptic Curve Cryptography Algorithms. 1631 RFC 5480: 1632 Elliptic Curve Cryptography Subject Public Key 1633 Information."; 1634 } 1635 enum x25519 { 1636 value 12; 1637 description 1638 "The asymmetric algorithm using a x.25519 Curve."; 1639 reference 1640 "RFC 7748: 1641 Elliptic Curves for Security."; 1642 } 1643 enum x448 { 1644 value 13; 1645 description 1646 "The asymmetric algorithm using a x.448 Curve."; 1647 reference 1648 "RFC 7748: 1649 Elliptic Curves for Security."; 1650 } 1651 } 1652 description 1653 "A typedef enumerating various asymmetric key algorithms."; 1654 } 1656 // Protocol-accessible Nodes 1658 container supported-asymmetric-algorithms { 1659 config false; 1660 description 1661 "A container for a list of supported asymmetric algorithms. 1662 How algorithms come to be supported is outside the scope 1663 of this module."; 1664 list supported-asymmetric-algorithm { 1665 key algorithm; 1666 description 1667 "A lists of asymmetric algorithms supported by the server."; 1669 leaf algorithm { 1670 type asymmetric-algorithm-type; 1671 description 1672 "An asymmetric algorithms supported by the server."; 1673 } 1674 } 1675 } 1677 } 1679 1681 4.3. Examples 1683 The following example illustrates the "supported-asymmetric- 1684 algorithms" "container" statement with the NETCONF protocol. 1686 1688 1689 rsa2048 1690 1691 1692 secp256r1 1693 1694 1696 5. The Hash Algorithms Module 1698 5.1. Tree Diagram 1700 This section provides a tree diagram [RFC8340] for the "iana-hash- 1701 algs" module. Only the "container" statement is represented, as tree 1702 diagrams have no means to represent "typedef" statements. 1704 module: iana-hash-algs 1705 +--ro supported-hash-algorithms 1706 +--ro supported-hash-algorithm* [algorithm] 1707 +--ro algorithm hash-algorithm-type 1709 5.2. YANG Module 1711 This module has normative references to FIXME... 1713 file "iana-hash-algs@2019-11-02.yang" 1715 module iana-hash-algs { 1716 yang-version 1.1; 1717 namespace "urn:ietf:params:xml:ns:yang:iana-hash-algs"; 1718 prefix iha; 1720 organization 1721 "IETF NETCONF (Network Configuration) Working Group"; 1723 contact 1724 "WG Web: 1725 WG List: 1726 Author: Kent Watsen 1727 Author: Wang Haiguang "; 1729 description 1730 "This module defines a typedef for hash algorithms, and 1731 a container for a list of hash algorithms supported by 1732 the server. 1734 Copyright (c) 2019 IETF Trust and the persons identified 1735 as authors of the code. All rights reserved. 1736 Redistribution and use in source and binary forms, with 1737 or without modification, is permitted pursuant to, and 1738 subject to the license terms contained in, the Simplified 1739 BSD License set forth in Section 4.c of the IETF Trust's 1740 Legal Provisions Relating to IETF Documents 1741 (https://trustee.ietf.org/license-info). 1743 This version of this YANG module is part of RFC XXXX 1744 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1745 itself for full legal notices.; 1747 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1748 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1749 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1750 are to be interpreted as described in BCP 14 (RFC 2119) 1751 (RFC 8174) when, and only when, they appear in all 1752 capitals, as shown here."; 1754 revision 2019-11-02 { 1755 description 1756 "Initial version"; 1757 reference 1758 "RFC XXXX: Common YANG Data Types for Cryptography"; 1759 } 1761 // Typedefs 1763 typedef hash-algorithm-type { 1764 type enumeration { 1765 enum sha1 { 1766 value 1; 1767 status obsolete; 1768 description 1769 "The SHA1 algorithm."; 1770 reference 1771 "RFC 3174: US Secure Hash Algorithms 1 (SHA1)."; 1772 } 1773 enum sha-224 { 1774 value 2; 1775 description 1776 "The SHA-224 algorithm."; 1777 reference 1778 "RFC 6234: US Secure Hash Algorithms."; 1779 } 1780 enum sha-256 { 1781 value 3; 1782 description 1783 "The SHA-256 algorithm."; 1784 reference 1785 "RFC 6234: US Secure Hash Algorithms."; 1786 } 1787 enum sha-384 { 1788 value 4; 1789 description 1790 "The SHA-384 algorithm."; 1791 reference 1792 "RFC 6234: US Secure Hash Algorithms."; 1793 } 1794 enum sha-512 { 1795 value 5; 1796 description 1797 "The SHA-512 algorithm."; 1798 reference 1799 "RFC 6234: US Secure Hash Algorithms."; 1800 } 1801 enum shake-128 { 1802 value 6; 1803 description 1804 "The SHA3 algorithm with 128-bits output."; 1805 reference 1806 "National Institute of Standards and Technology, 1807 SHA-3 Standard: Permutation-Based Hash and 1808 Extendable-Output Functions, FIPS PUB 202, DOI 1809 10.6028/NIST.FIPS.202, August 2015."; 1810 } 1811 enum shake-224 { 1812 value 7; 1813 description 1814 "The SHA3 algorithm with 224-bits output."; 1815 reference 1816 "National Institute of Standards and Technology, 1817 SHA-3 Standard: Permutation-Based Hash and 1818 Extendable-Output Functions, FIPS PUB 202, DOI 1819 10.6028/NIST.FIPS.202, August 2015."; 1820 } 1821 enum shake-256 { 1822 value 8; 1823 description 1824 "The SHA3 algorithm with 256-bits output."; 1825 reference 1826 "National Institute of Standards and Technology, 1827 SHA-3 Standard: Permutation-Based Hash and 1828 Extendable-Output Functions, FIPS PUB 202, DOI 1829 10.6028/NIST.FIPS.202, August 2015."; 1830 } 1831 enum shake-384 { 1832 value 9; 1833 description 1834 "The SHA3 algorithm with 384-bits output."; 1835 reference 1836 "National Institute of Standards and Technology, 1837 SHA-3 Standard: Permutation-Based Hash and 1838 Extendable-Output Functions, FIPS PUB 202, DOI 1839 10.6028/NIST.FIPS.202, August 2015."; 1840 } 1841 enum shake-512 { 1842 value 10; 1843 description 1844 "The SHA3 algorithm with 384-bits output."; 1845 reference 1846 "National Institute of Standards and Technology, 1847 SHA-3 Standard: Permutation-Based Hash and 1848 Extendable-Output Functions, FIPS PUB 202, DOI 1849 10.6028/NIST.FIPS.202, August 2015."; 1850 } 1851 } 1852 description 1853 "A typedef enumerating various hash key algorithms."; 1854 } 1856 // Protocol-accessible Nodes 1858 container supported-hash-algorithms { 1859 config false; 1860 description 1861 "A container for a list of supported hash algorithms. 1862 How algorithms come to be supported is outside the 1863 scope of this module."; 1864 list supported-hash-algorithm { 1865 key algorithm; 1866 description 1867 "A lists of hash algorithms supported by the server."; 1868 leaf algorithm { 1869 type hash-algorithm-type; 1870 description 1871 "An hash algorithms supported by the server."; 1872 } 1873 } 1874 } 1876 } 1878 1880 5.3. Examples 1882 The following example illustrates the "supported-hash-algorithms" 1883 "container" statement with the NETCONF protocol. 1885 1887 1888 sha-256 1889 1890 1891 sha-512 1892 1893 1895 6. Security Considerations 1897 6.1. Support for Algorithms 1899 In order to use YANG identities for algorithm identifiers, only the 1900 most commonly used RSA key lengths are supported for the RSA 1901 algorithm. Additional key lengths can be defined in another module 1902 or added into a future version of this document. 1904 This document limits the number of elliptical curves supported. This 1905 was done to match industry trends and IETF best practice (e.g., 1906 matching work being done in TLS 1.3). If additional algorithms are 1907 needed, they can be defined by another module or added into a future 1908 version of this document. 1910 6.2. No Support for CRMF 1912 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1913 signing-request" action. The use of Certificate Request Message 1914 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1915 was market demand for it. If it is desired to support CRMF in the 1916 future, a backwards compatible solution can be defined at that time. 1918 6.3. Access to Data Nodes 1920 The YANG module in this document defines "grouping" statements that 1921 are designed to be accessed via YANG based management protocols, such 1922 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1923 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1924 with mutual authentication. 1926 The NETCONF access control model (NACM) [RFC8341] provides the means 1927 to restrict access for particular users to a pre-configured subset of 1928 all available protocol operations and content. 1930 Since the module in this document only define groupings, these 1931 considerations are primarily for the designers of other modules that 1932 use these groupings. 1934 There are a number of data nodes defined by the grouping statements 1935 that are writable/creatable/deletable (i.e., config true, which is 1936 the default). Some of these data nodes may be considered sensitive 1937 or vulnerable in some network environments. Write operations (e.g., 1938 edit-config) to these data nodes without proper protection can have a 1939 negative effect on network operations. These are the subtrees and 1940 data nodes and their sensitivity/vulnerability: 1942 *: All of the data nodes defined by all the groupings are 1943 considered sensitive to write operations. For instance, the 1944 modification of a public key or a certificate can dramatically 1945 alter the implemented security policy. For this reason, the 1946 NACM extension "default-deny-write" has been applied to all the 1947 data nodes defined by all the groupings. 1949 Some of the readable data nodes in the YANG module may be considered 1950 sensitive or vulnerable in some network environments. It is thus 1951 important to control read access (e.g., via get, get-config, or 1952 notification) to these data nodes. These are the subtrees and data 1953 nodes and their sensitivity/vulnerability: 1955 /private-key: The "private-key" node defined in the "asymmetric- 1956 key-pair-grouping" grouping is additionally sensitive to read 1957 operations such that, in normal use cases, it should never be 1958 returned to a client. For this reason, the NACM extension 1959 "default-deny-all" has been applied to it here. 1961 Some of the operations in this YANG module may be considered 1962 sensitive or vulnerable in some network environments. It is thus 1963 important to control access to these operations. These are the 1964 operations and their sensitivity/vulnerability: 1966 *: All of the "action" statements defined by groupings SHOULD only 1967 be executed by authorized users. For this reason, the NACM 1968 extension "default-deny-all" has been applied to all of them. 1969 Note that NACM uses "default-deny-all" to protect "RPC" and 1970 "action" statements; it does not define, e.g., an extension 1971 called "default-deny-execute". 1973 generate-certificate-signing-request: For this action, it is 1974 RECOMMENDED that implementations assert channel binding 1975 [RFC5056], so as to ensure that the application layer that sent 1976 the request is the same as the device authenticated when the 1977 secure transport layer was established. 1979 7. IANA Considerations 1981 7.1. The IETF XML Registry 1983 This document registers four URIs in the "ns" subregistry of the IETF 1984 XML Registry [RFC3688]. Following the format in [RFC3688], the 1985 following registrations are requested: 1987 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 1988 Registrant Contact: The NETCONF WG of the IETF. 1989 XML: N/A, the requested URI is an XML namespace. 1991 URI: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 1992 Registrant Contact: The NETCONF WG of the IETF. 1993 XML: N/A, the requested URI is an XML namespace. 1995 URI: urn:ietf:params:xml:ns:yang:iana-ssymmetric-algs 1996 Registrant Contact: The NETCONF WG of the IETF. 1997 XML: N/A, the requested URI is an XML namespace. 1999 URI: urn:ietf:params:xml:ns:yang:iana-hash-algs 2000 Registrant Contact: The NETCONF WG of the IETF. 2001 XML: N/A, the requested URI is an XML namespace. 2003 7.2. The YANG Module Names Registry 2005 This document registers four YANG modules in the YANG Module Names 2006 registry [RFC6020]. Following the format in [RFC6020], the the 2007 following registrations are requested: 2009 name: ietf-crypto-types 2010 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2011 prefix: ct 2012 reference: RFC XXXX 2014 name: iana-symmetric-algs 2015 namespace: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 2016 prefix: isa 2017 reference: RFC XXXX 2019 name: iana-asymmetric-algs 2020 namespace: urn:ietf:params:xml:ns:yang:iana-asymmetric-algs 2021 prefix: iasa 2022 reference: RFC XXXX 2024 name: iana-hash-algs 2025 namespace: urn:ietf:params:xml:ns:yang:iana-hash-algs 2026 prefix: iha 2027 reference: RFC XXXX 2029 8. References 2031 8.1. Normative References 2033 [ITU.X690.2015] 2034 International Telecommunication Union, "Information 2035 Technology - ASN.1 encoding rules: Specification of Basic 2036 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2037 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2038 X.690, ISO/IEC 8825-1, August 2015, 2039 . 2041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2042 Requirement Levels", BCP 14, RFC 2119, 2043 DOI 10.17487/RFC2119, March 1997, 2044 . 2046 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2047 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 2048 1998, . 2050 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 2051 Encryption Algorithm in Cryptographic Message Syntax 2052 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 2053 . 2055 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2056 Counter Mode With IPsec Encapsulating Security Payload 2057 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2058 . 2060 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2061 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2062 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2063 . 2065 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2066 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2067 January 2006, . 2069 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 2070 Ciphersuites for Transport Layer Security (TLS)", 2071 RFC 4279, DOI 10.17487/RFC4279, December 2005, 2072 . 2074 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2075 Mode with IPsec Encapsulating Security Payload (ESP)", 2076 RFC 4309, DOI 10.17487/RFC4309, December 2005, 2077 . 2079 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 2080 Algorithm and Its Use with IPsec", RFC 4494, 2081 DOI 10.17487/RFC4494, June 2006, 2082 . 2084 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2085 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2086 DOI 10.17487/RFC4543, May 2006, 2087 . 2089 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 2090 384, and HMAC-SHA-512 with IPsec", RFC 4868, 2091 DOI 10.17487/RFC4868, May 2007, 2092 . 2094 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2095 Housley, R., and W. Polk, "Internet X.509 Public Key 2096 Infrastructure Certificate and Certificate Revocation List 2097 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2098 . 2100 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2101 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2102 . 2104 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 2105 Integration in the Secure Shell Transport Layer", 2106 RFC 5656, DOI 10.17487/RFC5656, December 2009, 2107 . 2109 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 2110 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 2111 March 2011, . 2113 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2114 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2115 . 2117 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 2118 Ephemeral Parameters for Transport Layer Security (TLS)", 2119 RFC 7919, DOI 10.17487/RFC7919, August 2016, 2120 . 2122 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2123 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2124 . 2126 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2127 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2128 May 2017, . 2130 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 2131 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 2132 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 2133 . 2135 [RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in 2136 the Secure Shell (SSH) Protocol", RFC 8332, 2137 DOI 10.17487/RFC8332, March 2018, 2138 . 2140 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2141 Access Control Model", STD 91, RFC 8341, 2142 DOI 10.17487/RFC8341, March 2018, 2143 . 2145 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 2146 Curve Cryptography (ECC) Cipher Suites for Transport Layer 2147 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 2148 DOI 10.17487/RFC8422, August 2018, 2149 . 2151 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2152 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2153 . 2155 8.2. Informative References 2157 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2158 Request Syntax Specification Version 1.7", RFC 2986, 2159 DOI 10.17487/RFC2986, November 2000, 2160 . 2162 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 2163 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 2164 . 2166 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2167 DOI 10.17487/RFC3688, January 2004, 2168 . 2170 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2171 Certificate Request Message Format (CRMF)", RFC 4211, 2172 DOI 10.17487/RFC4211, September 2005, 2173 . 2175 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2176 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2177 2006, . 2179 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2180 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2181 . 2183 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2184 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2185 . 2187 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2188 the Network Configuration Protocol (NETCONF)", RFC 6020, 2189 DOI 10.17487/RFC6020, October 2010, 2190 . 2192 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2193 Verification of Domain-Based Application Service Identity 2194 within Internet Public Key Infrastructure Using X.509 2195 (PKIX) Certificates in the Context of Transport Layer 2196 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2197 2011, . 2199 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2200 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2201 DOI 10.17487/RFC6234, May 2011, 2202 . 2204 [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell 2205 (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011, 2206 . 2208 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2209 and A. Bierman, Ed., "Network Configuration Protocol 2210 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2211 . 2213 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 2214 Signatures for Identity-Based Encryption (ECCSI)", 2215 RFC 6507, DOI 10.17487/RFC6507, February 2012, 2216 . 2218 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2219 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2220 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2221 . 2223 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2224 Signature Algorithm (EdDSA)", RFC 8032, 2225 DOI 10.17487/RFC8032, January 2017, 2226 . 2228 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2229 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2230 . 2232 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2233 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2234 . 2236 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2237 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2238 . 2240 Appendix A. Change Log 2242 A.1. I-D to 00 2244 o Removed groupings and notifications. 2246 o Added typedefs for identityrefs. 2248 o Added typedefs for other RFC 5280 structures. 2250 o Added typedefs for other RFC 5652 structures. 2252 o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2254 A.2. 00 to 01 2256 o Moved groupings from the draft-ietf-netconf-keystore here. 2258 A.3. 01 to 02 2260 o Removed unwanted "mandatory" and "must" statements. 2262 o Added many new crypto algorithms (thanks Haiguang!) 2264 o Clarified in asymmetric-key-pair-with-certs-grouping, in 2265 certificates/certificate/name/description, that if the name MUST 2266 NOT match the name of a certificate that exists independently in 2267 , enabling certs installed by the manufacturer (e.g., 2268 an IDevID). 2270 A.4. 02 to 03 2272 o renamed base identity 'asymmetric-key-encryption-algorithm' to 2273 'asymmetric-key-algorithm'. 2275 o added new 'asymmetric-key-algorithm' identities for secp192r1, 2276 secp224r1, secp256r1, secp384r1, and secp521r1. 2278 o removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2279 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2280 aes-256-gcm, and mac-chacha20-poly1305. 2282 o for all -cbc and -ctr identities, renamed base identity 2283 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2285 o for all -ccm and -gcm identities, renamed base identity 2286 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2287 algorithm' and renamed the identity to remove the "enc-" prefix. 2289 o for all the 'signature-algorithm' based identities, renamed from 2290 'rsa-*' to 'rsassa-*'. 2292 o removed all of the "x509v3-" prefixed 'signature-algorithm' based 2293 identities. 2295 o added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2296 and 'rsaes-pkcs1-v1_5'. 2298 o renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2299 'symmetric-key-algorithm-ref'. 2301 o renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2302 'asymmetric-key-algorithm-ref'. 2304 o added typedef 'encryption-and-mac-algorithm-ref'. 2306 o Updated copyright date, boilerplate template, affiliation, and 2307 folding algorithm. 2309 A.5. 03 to 04 2311 o ran YANG module through formatter. 2313 A.6. 04 to 05 2315 o fixed broken symlink causing reformatted YANG module to not show. 2317 A.7. 05 to 06 2319 o Added NACM annotations. 2321 o Updated Security Considerations section. 2323 o Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2325 o Removed text from 'permanently-hidden' enum regarding such keys 2326 not being backed up or restored. 2328 o Updated the boilerplate text in module-level "description" 2329 statement to match copyeditor convention. 2331 o Added an explanation to the 'public-key-grouping' and 'asymmetric- 2332 key-pair-grouping' statements as for why the nodes are not 2333 mandatory (e.g., because they may exist only in . 2335 o Added 'must' expressions to the 'public-key-grouping' and 2336 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2337 are either all exist or do not all exist. 2339 o Added an explanation to the 'permanently-hidden' that the value 2340 cannot be configured directly by clients and servers MUST fail any 2341 attempt to do so. 2343 o Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2344 grouping' (the plural form of existing groupings). 2346 o Now states that keys created in by the *-hidden-key 2347 actions are bound to the lifetime of the parent 'config true' 2348 node, and that subsequent invocations of either action results in 2349 a failure. 2351 A.8. 06 to 07 2353 o Added clarifications that implementations SHOULD assert that 2354 configured certificates contain the matching public key. 2356 o Replaced the 'generate-hidden-key' and 'install-hidden-key' 2357 actions with special 'crypt-hash' -like input/output values. 2359 A.9. 07 to 08 2361 o Removed the 'generate-key and 'hidden-key' features. 2363 o Added grouping symmetric-key-grouping 2365 o Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2366 statement for the keystone module to augment into, as well as 2367 replacing the 'union' with leafs (having different NACM settings. 2369 A.10. 08 to 09 2371 o Converting algorithm from identities to enumerations. 2373 A.11. 09 to 10 2375 o All of the below changes are to the algorithm enumerations defined 2376 in ietf-crypto-types. 2378 o Add in support for key exchange over x.25519 and x.448 based on 2379 RFC 8418. 2381 o Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2382 o Revise/add in enum of signature algorithm for x25519 and x448 2384 o Add in des3-cbc-sha1 for IPSec 2386 o Add in sha1-des3-kd for IPSec 2388 o Add in definit for rc4-hmac and rc4-hmac-exp. These two 2389 algorithms have been deprecated in RFC 8429. But some existing 2390 draft in i2nsf may still want to use them. 2392 o Add x25519 and x448 curve for asymmetric algorithms 2394 o Add signature algorithms ed25519, ed25519-cts, ed25519ph 2396 o add signature algorithms ed448, ed448ph 2398 o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2400 A.12. 10 to 11 2402 o Added a "key-format" identity. 2404 o Added symmetric keys to the example in Section 2.3. 2406 A.13. 11 to 12 2408 o Removed all non-essential (to NC/RC) algorithm types. 2410 o Moved remaining algorithm types each into its own module. 2412 o Added a 'config false' "algorithms-supported" list to each of the 2413 algorithm-type modules. 2415 Acknowledgements 2417 The authors would like to thank for following for lively discussions 2418 on list and in the halls (ordered by last name): Martin Bjorklund, 2419 Nick Hancock, Balazs Kovacs, Juergen Schoenwaelder, Eric Voit, and 2420 Liang Xia. 2422 Authors' Addresses 2424 Kent Watsen 2425 Watsen Networks 2427 EMail: kent+ietf@watsen.net 2428 Wang Haiguang 2429 Huawei 2431 EMail: wang.haiguang.shieldlab@huawei.com