idnits 2.17.1 draft-ietf-netconf-crypto-types-13.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 178 has weird spacing: '...on-date yan...' == Line 182 has weird spacing: '...on-date yan...' == Line 186 has weird spacing: '...on-date yan...' == Line 190 has weird spacing: '...on-date yan...' == Line 204 has weird spacing: '...on-date yan...' == (8 more instances...) -- The document date (November 20, 2019) is 1617 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 23, 2020 Huawei 6 November 20, 2019 8 Common YANG Data Types for Cryptography 9 draft-ietf-netconf-crypto-types-13 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-20" --> 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 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 24 84 3. The Symmetric Algorithms Module . . . . . . . . . . . . . . . 28 85 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 28 86 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 87 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 32 88 4. The Asymmetric Algorithms Module . . . . . . . . . . . . . . 32 89 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 32 90 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 33 91 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 37 92 5. The Hash Algorithms Module . . . . . . . . . . . . . . . . . 37 93 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 37 94 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 38 95 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 41 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 97 6.1. Support for Algorithms . . . . . . . . . . . . . . . . . 42 98 6.2. No Support for CRMF . . . . . . . . . . . . . . . . . . . 42 99 6.3. Access to Data Nodes . . . . . . . . . . . . . . . . . . 42 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 101 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 43 102 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 44 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 105 8.2. Informative References . . . . . . . . . . . . . . . . . 47 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 50 107 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 50 108 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 50 109 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 50 110 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 50 111 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 51 112 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 51 113 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 51 114 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 52 115 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 52 116 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 52 117 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 52 118 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 53 119 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 53 120 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 53 121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 124 1. Introduction 126 This document defines four YANG 1.1 [RFC7950] modules for types 127 useful to cryptographic applications. The modules defined include: 129 o ietf-crypto-types 131 o iana-symmetric-algs 133 o iana-asymmetric-algs 135 o iana-hash-algs 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. The Crypto Types Module 145 2.1. Tree Diagram 147 This section provides a tree diagram [RFC8340] for the "ietf-crypto- 148 types" module. Only "grouping" statements are represented, as tree 149 diagrams have no means to represent identities or typedefs. 151 module: ietf-crypto-types 153 grouping symmetric-key-grouping 154 +-- algorithm isa:symmetric-algorithm-type 155 +-- key-format? identityref 156 +-- (key-type) 157 +--:(key) 158 | +-- key? binary 159 +--:(hidden-key) 160 +-- hidden-key? empty 161 grouping public-key-grouping 162 +-- algorithm iasa:asymmetric-algorithm-type 163 +-- public-key-format? identityref 164 +-- public-key binary 165 grouping asymmetric-key-pair-grouping 166 +-- algorithm iasa:asymmetric-algorithm-type 167 +-- public-key-format? identityref 168 +-- public-key binary 169 +-- private-key-format? identityref 170 +-- (private-key-type) 171 +--:(private-key) 172 | +-- private-key? binary 173 +--:(hidden-private-key) 174 +-- hidden-private-key? empty 175 grouping trust-anchor-cert-grouping 176 +-- cert? trust-anchor-cert-cms 177 +---n certificate-expiration 178 +-- expiration-date yang:date-and-time 179 grouping trust-anchor-certs-grouping 180 +-- cert* trust-anchor-cert-cms 181 +---n certificate-expiration 182 +-- expiration-date yang:date-and-time 183 grouping end-entity-cert-grouping 184 +-- cert? end-entity-cert-cms 185 +---n certificate-expiration 186 +-- expiration-date yang:date-and-time 187 grouping end-entity-certs-grouping 188 +-- cert* end-entity-cert-cms 189 +---n certificate-expiration 190 +-- 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-20.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-20 { 318 description 319 "Initial version"; 320 reference 321 "RFC XXXX: Common YANG Data Types for Cryptography"; 322 } 324 /****************/ 325 /* Features */ 326 /****************/ 328 feature "one-asymmetric-key-format" { 329 description 330 "Indicates that the server supports the 331 'one-asymmetric-key-format' identity."; 332 } 334 feature "one-symmetric-key-format" { 335 description 336 "Indicates that the server supports the 337 'one-symmetric-key-format' identity."; 338 } 340 feature "encrypted-one-symmetric-key-format" { 341 description 342 "Indicates that the server supports the 343 'encrypted-one-symmetric-key-format' identity."; 344 } 346 feature "encrypted-one-asymmetric-key-format" { 347 description 348 "Indicates that the server supports the 349 'encrypted-one-asymmetric-key-format' identity."; 350 } 352 /********************************************/ 353 /* Identities for Key Format Structures */ 354 /********************************************/ 356 /*** base key formats ****/ 358 identity key-format-base { 359 description "Base key-format identity for all keys."; 360 } 362 identity public-key-format { 363 base "key-format-base"; 364 description "Base key-format identity for public keys."; 365 } 367 identity private-key-format { 368 base "key-format-base"; 369 description "Base key-format identity for private keys."; 370 } 372 identity symmetric-key-format { 373 base "key-format-base"; 374 description "Base key-format identity for symmetric keys."; 375 } 377 /**** for private keys ****/ 378 identity rsa-private-key-format { 379 base "private-key-format"; 380 description 381 "Indicates that the private key value is encoded 382 as an RSAPrivateKey (from RFC 3447)."; 383 reference 384 "RFC 3447: PKCS #1: RSA Cryptography 385 Specifications Version 2.2"; 386 } 388 identity ec-private-key-format { 389 base "private-key-format"; 390 description 391 "Indicates that the private key value is encoded 392 as an ECPrivateKey (from RFC 5915)"; 393 reference 394 "RFC 5915: Elliptic Curve Private Key Structure"; 395 } 397 identity one-asymmetric-key-format { 398 if-feature "one-asymmetric-key-format"; 399 base "private-key-format"; 400 description 401 "Indicates that the private key value is encoded 402 as a OneAsymmetricKey structure (RFC 6031)."; 403 // FIXME: DER encoded ASN.1, etc...or flex PEM? 404 reference 405 "RFC 5958: Asymmetric Key Packages"; 406 } 408 identity encrypted-one-asymmetric-key-format { 409 if-feature "encrypted-one-asymmetric-key-format"; 410 base "private-key-format"; 411 description 412 "Indicates that the private key value is encoded 413 as a OneAsymmetricKey structure (RFC 5958)."; 414 // FIXME: DER encoded ASN.1, etc...or flex PEM? 415 reference 416 "RFC 5652: Cryptographic Message Syntax (CMS) 417 RFC 5958: Asymmetric Key Packages"; 418 } 420 /**** for public keys ****/ 422 identity ssh-public-key-format { 423 base "public-key-format"; 424 description 425 "Indicates that the public key value is encoded 426 an SSH public key, as described by RFC 4716."; 427 reference 428 "RFC 4716: The Secure Shell (SSH) Public Key 429 File Format"; 430 } 432 identity subject-public-key-info-format { 433 base "public-key-format"; 434 description 435 "Indicates that the public key value is encoded as 436 a SubjectPublicKeyInfo structure, as described in 437 RFC 5280."; 438 // FIXME: DER encoded ASN.1, etc... 439 reference 440 "RFC 5280: 441 Internet X.509 Public Key Infrastructure Certificate 442 and Certificate Revocation List (CRL) Profile"; 443 } 445 /**** for symmetric keys ****/ 447 identity octet-string-key-format { 448 base "symmetric-key-format"; 449 description 450 "Indicates that the key is encoded as a raw octet string."; 451 // FIXME 452 // Knowing that it is an "OctetString" isn't really helpful. 453 // Knowing the length of the octet string would be helpful, 454 // as it relates to the algorithm's block size. We may want 455 // to only (for now) use "one-symmetric-key-format" for 456 // symmetric keys...were the usability issues Juergen 457 // mentioned before only apply to asymmetric keys? 458 } 460 identity one-symmetric-key-format { 461 if-feature "one-symmetric-key-format"; 462 base "symmetric-key-format"; 463 description 464 "Indicates that the symmetric key value is encoded 465 as a OneSymmetricKey (from RFC 6031)."; 466 // FIXME: DER encoded ASN.1, etc...or flex PEM? 467 reference 468 "RFC 6031: Cryptographic Message Syntax (CMS) 469 Symmetric Key Package Content Type"; 470 } 471 identity encrypted-one-symmetric-key-format { 472 if-feature "encrypted-one-symmetric-key-format"; 473 base "symmetric-key-format"; 474 description 475 "Indicates that the symmetric key value is encoded 476 as an EncryptedData structure (RFC 5652) containing 477 OneSymmetricKey (RFC 6031)."; 478 // FIXME: DER encoded ASN.1, etc...or flex PEM? 479 reference 480 "RFC 5652: Cryptographic Message Syntax (CMS) 481 RFC 6031: Cryptographic Message Syntax (CMS) 482 Symmetric Key Package Content Type"; 483 } 485 /***************************************************/ 486 /* Typedefs for ASN.1 structures from RFC 5280 */ 487 /***************************************************/ 489 typedef x509 { 490 type binary; 491 description 492 "A Certificate structure, as specified in RFC 5280, 493 encoded using ASN.1 distinguished encoding rules (DER), 494 as specified in ITU-T X.690."; 495 reference 496 "RFC 5280: 497 Internet X.509 Public Key Infrastructure Certificate 498 and Certificate Revocation List (CRL) Profile 499 ITU-T X.690: 500 Information technology - ASN.1 encoding rules: 501 Specification of Basic Encoding Rules (BER), 502 Canonical Encoding Rules (CER) and Distinguished 503 Encoding Rules (DER)."; 504 } 506 typedef crl { 507 type binary; 508 description 509 "A CertificateList structure, as specified in RFC 5280, 510 encoded using ASN.1 distinguished encoding rules (DER), 511 as specified in ITU-T X.690."; 512 reference 513 "RFC 5280: 514 Internet X.509 Public Key Infrastructure Certificate 515 and Certificate Revocation List (CRL) Profile 516 ITU-T X.690: 518 Information technology - ASN.1 encoding rules: 519 Specification of Basic Encoding Rules (BER), 520 Canonical Encoding Rules (CER) and Distinguished 521 Encoding Rules (DER)."; 522 } 524 /***********************************************/ 525 /* Typedefs for ASN.1 structures from 5652 */ 526 /***********************************************/ 528 typedef cms { 529 type binary; 530 description 531 "A ContentInfo structure, as specified in RFC 5652, 532 encoded using ASN.1 distinguished encoding rules (DER), 533 as specified in ITU-T X.690."; 534 reference 535 "RFC 5652: 536 Cryptographic Message Syntax (CMS) 537 ITU-T X.690: 538 Information technology - ASN.1 encoding rules: 539 Specification of Basic Encoding Rules (BER), 540 Canonical Encoding Rules (CER) and Distinguished 541 Encoding Rules (DER)."; 542 } 544 typedef data-content-cms { 545 type cms; 546 description 547 "A CMS structure whose top-most content type MUST be the 548 data content type, as described by Section 4 in RFC 5652."; 549 reference 550 "RFC 5652: Cryptographic Message Syntax (CMS)"; 551 } 553 typedef signed-data-cms { 554 type cms; 555 description 556 "A CMS structure whose top-most content type MUST be the 557 signed-data content type, as described by Section 5 in 558 RFC 5652."; 559 reference 560 "RFC 5652: Cryptographic Message Syntax (CMS)"; 561 } 563 typedef enveloped-data-cms { 564 type cms; 565 description 566 "A CMS structure whose top-most content type MUST be the 567 enveloped-data content type, as described by Section 6 568 in RFC 5652."; 569 reference 570 "RFC 5652: Cryptographic Message Syntax (CMS)"; 571 } 573 typedef digested-data-cms { 574 type cms; 575 description 576 "A CMS structure whose top-most content type MUST be the 577 digested-data content type, as described by Section 7 578 in RFC 5652."; 579 reference 580 "RFC 5652: Cryptographic Message Syntax (CMS)"; 581 } 583 typedef encrypted-data-cms { 584 type cms; 585 description 586 "A CMS structure whose top-most content type MUST be the 587 encrypted-data content type, as described by Section 8 588 in RFC 5652."; 589 reference 590 "RFC 5652: Cryptographic Message Syntax (CMS)"; 591 } 593 typedef authenticated-data-cms { 594 type cms; 595 description 596 "A CMS structure whose top-most content type MUST be the 597 authenticated-data content type, as described by Section 9 598 in RFC 5652."; 599 reference 600 "RFC 5652: Cryptographic Message Syntax (CMS)"; 601 } 603 /***************************************************/ 604 /* Typedefs for structures related to RFC 4253 */ 605 /***************************************************/ 607 typedef ssh-host-key { 608 type binary; 609 description 610 "The binary public key data for an SSH key, as 611 specified by RFC 4253, Section 6.6, i.e.: 613 string certificate or public key format 614 identifier 615 byte[n] key/certificate data."; 616 reference 617 "RFC 4253: The Secure Shell (SSH) Transport Layer 618 Protocol"; 619 } 621 /*********************************************************/ 622 /* Typedefs for ASN.1 structures related to RFC 5280 */ 623 /*********************************************************/ 625 typedef trust-anchor-cert-x509 { 626 type x509; 627 description 628 "A Certificate structure that MUST encode a self-signed 629 root certificate."; 630 } 632 typedef end-entity-cert-x509 { 633 type x509; 634 description 635 "A Certificate structure that MUST encode a certificate 636 that is neither self-signed nor having Basic constraint 637 CA true."; 638 } 640 /*********************************************************/ 641 /* Typedefs for ASN.1 structures related to RFC 5652 */ 642 /*********************************************************/ 644 typedef trust-anchor-cert-cms { 645 type signed-data-cms; 646 description 647 "A CMS SignedData structure that MUST contain the chain of 648 X.509 certificates needed to authenticate the certificate 649 presented by a client or end-entity. 651 The CMS MUST contain only a single chain of certificates. 652 The client or end-entity certificate MUST only authenticate 653 to last intermediate CA certificate listed in the chain. 655 In all cases, the chain MUST include a self-signed root 656 certificate. In the case where the root certificate is 657 itself the issuer of the client or end-entity certificate, 658 only one certificate is present. 660 This CMS structure MAY (as applicable where this type is 661 used) also contain suitably fresh (as defined by local 662 policy) revocation objects with which the device can 663 verify the revocation status of the certificates. 665 This CMS encodes the degenerate form of the SignedData 666 structure that is commonly used to disseminate X.509 667 certificates and revocation objects (RFC 5280)."; 668 reference 669 "RFC 5280: 670 Internet X.509 Public Key Infrastructure Certificate 671 and Certificate Revocation List (CRL) Profile."; 672 } 674 typedef end-entity-cert-cms { 675 type signed-data-cms; 676 description 677 "A CMS SignedData structure that MUST contain the end 678 entity certificate itself, and MAY contain any number 679 of intermediate certificates leading up to a trust 680 anchor certificate. The trust anchor certificate 681 MAY be included as well. 683 The CMS MUST contain a single end entity certificate. 684 The CMS MUST NOT contain any spurious certificates. 686 This CMS structure MAY (as applicable where this type is 687 used) also contain suitably fresh (as defined by local 688 policy) revocation objects with which the device can 689 verify the revocation status of the certificates. 691 This CMS encodes the degenerate form of the SignedData 692 structure that is commonly used to disseminate X.509 693 certificates and revocation objects (RFC 5280)."; 694 reference 695 "RFC 5280: 696 Internet X.509 Public Key Infrastructure Certificate 697 and Certificate Revocation List (CRL) Profile."; 698 } 700 typedef ssh-public-key-type { // DELETE? 701 type binary; 702 description 703 "The binary public key data for this SSH key, as 704 specified by RFC 4253, Section 6.6, i.e.: 706 string certificate or public key format 707 identifier 708 byte[n] key/certificate data."; 710 reference 711 "RFC 4253: The Secure Shell (SSH) Transport 712 Layer Protocol"; 713 } 715 /**********************************************/ 716 /* Groupings for keys and/or certificates */ 717 /**********************************************/ 719 grouping symmetric-key-grouping { 720 description 721 "A symmetric key and algorithm."; 722 leaf algorithm { 723 type isa:symmetric-algorithm-type; 724 mandatory true; 725 description 726 "The algorithm to be used when generating the key."; 727 reference 728 "RFC CCCC: Common YANG Data Types for Cryptography"; 729 } 730 leaf key-format { 731 nacm:default-deny-write; 732 when "../key or ../encrypted-key"; // FIXME: forward ref?! 733 type identityref { 734 base symmetric-key-format; 735 } 736 description "Identifies the symmetric key's format."; 737 } 738 choice key-type { 739 mandatory true; 740 description 741 "Choice between key types."; 742 leaf key { 743 nacm:default-deny-all; 744 type binary; 745 must "../key-format"; 746 description 747 "The binary value of the key. The interpretation of 748 the value is defined by 'key-format'. For example, 749 FIXME."; 750 reference 751 "RFC XXXX: FIXME"; 752 } 753 leaf hidden-key { 754 nacm:default-deny-write; 755 type empty; 756 description 757 "A permanently hidden key. How such keys are created 758 is outside the scope of this module."; 759 } 760 } 761 } 763 grouping public-key-grouping { 764 description 765 "A public key and its associated algorithm."; 766 leaf algorithm { 767 nacm:default-deny-write; 768 type iasa:asymmetric-algorithm-type; 769 mandatory true; 770 description 771 "Identifies the key's algorithm."; 772 reference 773 "RFC CCCC: Common YANG Data Types for Cryptography"; 774 } 775 leaf public-key-format { 776 nacm:default-deny-write; 777 when "../public-key"; 778 type identityref { 779 base public-key-format; 780 } 781 description "Identifies the key's format."; 782 } 783 leaf public-key { 784 nacm:default-deny-write; 785 type binary; 786 must "../public-key-format"; 787 mandatory true; 788 description 789 "The binary value of the public key. The interpretation 790 of the value is defined by 'public-key-format' field."; 791 } 792 } 794 grouping asymmetric-key-pair-grouping { 795 description 796 "A private key and its associated public key and algorithm."; 797 uses public-key-grouping; 798 leaf private-key-format { 799 nacm:default-deny-write; 800 when "../private-key or ../encrypted-private-key"; 801 // FIXME: forward ref?! 802 type identityref { 803 base private-key-format; 804 } 805 description "Identifies the key's format."; 807 } 808 choice private-key-type { 809 mandatory true; 810 description 811 "Choice between key types."; 812 leaf private-key { 813 nacm:default-deny-all; 814 type binary; 815 must "../private-key-format"; 816 description 817 "The value of the binary key The key's value is 818 interpreted by the 'private-key-format' field."; 819 } 820 leaf hidden-private-key { 821 nacm:default-deny-write; 822 type empty; 823 description 824 "A permanently hidden key. How such keys are created 825 is outside the scope of this module."; 826 } 827 } 828 } 830 grouping trust-anchor-cert-grouping { 831 description 832 "A trust anchor certificate, and a notification for when 833 it is about to (or already has) expire."; 834 leaf cert { 835 nacm:default-deny-write; 836 type trust-anchor-cert-cms; 837 description 838 "The binary certificate data for this certificate."; 839 reference 840 "RFC YYYY: Common YANG Data Types for Cryptography"; 841 } 842 notification certificate-expiration { 843 description 844 "A notification indicating that the configured certificate 845 is either about to expire or has already expired. When to 846 send notifications is an implementation specific decision, 847 but it is RECOMMENDED that a notification be sent once a 848 month for 3 months, then once a week for four weeks, and 849 then once a day thereafter until the issue is resolved."; 850 leaf expiration-date { 851 type yang:date-and-time; 852 mandatory true; 853 description 854 "Identifies the expiration date on the certificate."; 856 } 857 } 858 } 860 grouping trust-anchor-certs-grouping { 861 description 862 "A list of trust anchor certificates, and a notification 863 for when one is about to (or already has) expire."; 864 leaf-list cert { 865 nacm:default-deny-write; 866 type trust-anchor-cert-cms; 867 description 868 "The binary certificate data for this certificate."; 869 reference 870 "RFC YYYY: Common YANG Data Types for Cryptography"; 871 } 872 notification certificate-expiration { 873 description 874 "A notification indicating that the configured certificate 875 is either about to expire or has already expired. When to 876 send notifications is an implementation specific decision, 877 but it is RECOMMENDED that a notification be sent once a 878 month for 3 months, then once a week for four weeks, and 879 then once a day thereafter until the issue is resolved."; 880 leaf expiration-date { 881 type yang:date-and-time; 882 mandatory true; 883 description 884 "Identifies the expiration date on the certificate."; 885 } 886 } 887 } 889 grouping end-entity-cert-grouping { 890 description 891 "An end entity certificate, and a notification for when 892 it is about to (or already has) expire. Implementations 893 SHOULD assert that, where used, the end entity certificate 894 contains the expected public key."; 895 leaf cert { 896 nacm:default-deny-write; 897 type end-entity-cert-cms; 898 description 899 "The binary certificate data for this certificate."; 900 reference 901 "RFC YYYY: Common YANG Data Types for Cryptography"; 902 } 903 notification certificate-expiration { 904 description 905 "A notification indicating that the configured certificate 906 is either about to expire or has already expired. When to 907 send notifications is an implementation specific decision, 908 but it is RECOMMENDED that a notification be sent once a 909 month for 3 months, then once a week for four weeks, and 910 then once a day thereafter until the issue is resolved."; 911 leaf expiration-date { 912 type yang:date-and-time; 913 mandatory true; 914 description 915 "Identifies the expiration date on the certificate."; 916 } 917 } 918 } 920 grouping end-entity-certs-grouping { 921 description 922 "A list of end entity certificates, and a notification for 923 when one is about to (or already has) expire."; 924 leaf-list cert { 925 nacm:default-deny-write; 926 type end-entity-cert-cms; 927 description 928 "The binary certificate data for this certificate."; 929 reference 930 "RFC YYYY: Common YANG Data Types for Cryptography"; 931 } 932 notification certificate-expiration { 933 description 934 "A notification indicating that the configured certificate 935 is either about to expire or has already expired. When to 936 send notifications is an implementation specific decision, 937 but it is RECOMMENDED that a notification be sent once a 938 month for 3 months, then once a week for four weeks, and 939 then once a day thereafter until the issue is resolved."; 940 leaf expiration-date { 941 type yang:date-and-time; 942 mandatory true; 943 description 944 "Identifies the expiration date on the certificate."; 945 } 946 } 947 } 949 grouping asymmetric-key-pair-with-cert-grouping { 950 description 951 "A private/public key pair and an associated certificate. 953 Implementations SHOULD assert that certificates contain 954 the matching public key."; 955 uses asymmetric-key-pair-grouping; 956 uses end-entity-cert-grouping; 957 action generate-certificate-signing-request { 958 nacm:default-deny-all; 959 description 960 "Generates a certificate signing request structure for 961 the associated asymmetric key using the passed subject 962 and attribute values. The specified assertions need 963 to be appropriate for the certificate's use. For 964 example, an entity certificate for a TLS server 965 SHOULD have values that enable clients to satisfy 966 RFC 6125 processing."; 967 input { 968 leaf subject { 969 type binary; 970 mandatory true; 971 description 972 "The 'subject' field per the CertificationRequestInfo 973 structure as specified by RFC 2986, Section 4.1 974 encoded using the ASN.1 distinguished encoding 975 rules (DER), as specified in ITU-T X.690."; 976 reference 977 "RFC 2986: 978 PKCS #10: Certification Request Syntax 979 Specification Version 1.7. 980 ITU-T X.690: 981 Information technology - ASN.1 encoding rules: 982 Specification of Basic Encoding Rules (BER), 983 Canonical Encoding Rules (CER) and Distinguished 984 Encoding Rules (DER)."; 985 } 986 leaf attributes { 987 type binary; 988 description 989 "The 'attributes' field from the structure 990 CertificationRequestInfo as specified by RFC 2986, 991 Section 4.1 encoded using the ASN.1 distinguished 992 encoding rules (DER), as specified in ITU-T X.690."; 993 reference 994 "RFC 2986: 995 PKCS #10: Certification Request Syntax 996 Specification Version 1.7. 997 ITU-T X.690: 998 Information technology - ASN.1 encoding rules: 999 Specification of Basic Encoding Rules (BER), 1000 Canonical Encoding Rules (CER) and Distinguished 1001 Encoding Rules (DER)."; 1002 } 1003 } 1004 output { 1005 leaf certificate-signing-request { 1006 type binary; 1007 mandatory true; 1008 description 1009 "A CertificationRequest structure as specified by 1010 RFC 2986, Section 4.2 encoded using the ASN.1 1011 distinguished encoding rules (DER), as specified 1012 in ITU-T X.690."; 1013 reference 1014 "RFC 2986: 1015 PKCS #10: Certification Request Syntax 1016 Specification Version 1.7. 1017 ITU-T X.690: 1018 Information technology - ASN.1 encoding rules: 1019 Specification of Basic Encoding Rules (BER), 1020 Canonical Encoding Rules (CER) and Distinguished 1021 Encoding Rules (DER)."; 1022 } 1023 } 1024 } // generate-certificate-signing-request 1025 } // asymmetric-key-pair-with-cert-grouping 1027 grouping asymmetric-key-pair-with-certs-grouping { 1028 description 1029 "A private/public key pair and associated certificates. 1030 Implementations SHOULD assert that certificates contain 1031 the matching public key."; 1032 uses asymmetric-key-pair-grouping; 1033 container certificates { 1034 nacm:default-deny-write; 1035 description 1036 "Certificates associated with this asymmetric key. 1037 More than one certificate supports, for instance, 1038 a TPM-protected asymmetric key that has both IDevID 1039 and LDevID certificates associated."; 1040 list certificate { 1041 key "name"; 1042 description 1043 "A certificate for this asymmetric key."; 1044 leaf name { 1045 type string; 1046 description 1047 "An arbitrary name for the certificate. If the name 1048 matches the name of a certificate that exists 1049 independently in (i.e., an IDevID), 1050 then the 'cert' node MUST NOT be configured."; 1051 } 1052 uses end-entity-cert-grouping; 1053 } 1054 } // certificates 1055 action generate-certificate-signing-request { 1056 nacm:default-deny-all; 1057 description 1058 "Generates a certificate signing request structure for 1059 the associated asymmetric key using the passed subject 1060 and attribute values. The specified assertions need 1061 to be appropriate for the certificate's use. For 1062 example, an entity certificate for a TLS server 1063 SHOULD have values that enable clients to satisfy 1064 RFC 6125 processing."; 1065 input { 1066 leaf subject { 1067 type binary; 1068 mandatory true; 1069 description 1070 "The 'subject' field per the CertificationRequestInfo 1071 structure as specified by RFC 2986, Section 4.1 1072 encoded using the ASN.1 distinguished encoding 1073 rules (DER), as specified in ITU-T X.690."; 1074 reference 1075 "RFC 2986: 1076 PKCS #10: Certification Request Syntax 1077 Specification Version 1.7. 1078 ITU-T X.690: 1079 Information technology - ASN.1 encoding rules: 1080 Specification of Basic Encoding Rules (BER), 1081 Canonical Encoding Rules (CER) and Distinguished 1082 Encoding Rules (DER)."; 1083 } 1084 leaf attributes { 1085 type binary; 1086 description 1087 "The 'attributes' field from the structure 1088 CertificationRequestInfo as specified by RFC 2986, 1089 Section 4.1 encoded using the ASN.1 distinguished 1090 encoding rules (DER), as specified in ITU-T X.690."; 1091 reference 1092 "RFC 2986: 1093 PKCS #10: Certification Request Syntax 1094 Specification Version 1.7. 1095 ITU-T X.690: 1096 Information technology - ASN.1 encoding rules: 1098 Specification of Basic Encoding Rules (BER), 1099 Canonical Encoding Rules (CER) and Distinguished 1100 Encoding Rules (DER)."; 1101 } 1102 } 1103 output { 1104 leaf certificate-signing-request { 1105 type binary; 1106 mandatory true; 1107 description 1108 "A CertificationRequest structure as specified by 1109 RFC 2986, Section 4.2 encoded using the ASN.1 1110 distinguished encoding rules (DER), as specified 1111 in ITU-T X.690."; 1112 reference 1113 "RFC 2986: 1114 PKCS #10: Certification Request Syntax 1115 Specification Version 1.7. 1116 ITU-T X.690: 1117 Information technology - ASN.1 encoding rules: 1118 Specification of Basic Encoding Rules (BER), 1119 Canonical Encoding Rules (CER) and Distinguished 1120 Encoding Rules (DER)."; 1121 } 1122 } 1123 } // generate-certificate-signing-request 1124 } // asymmetric-key-pair-with-certs-grouping 1125 } 1127 1129 2.3. Examples 1131 2.3.1. The "asymmetric-key-pair-with-certs-grouping" Grouping 1133 The following example module illustrates the use of both the 1134 "symmetric-key-grouping" and the "asymmetric-key-pair-with-certs- 1135 grouping" groupings defined in the "ietf-crypto-types" module. 1137 module ex-crypto-types-usage { 1138 yang-version 1.1; 1140 namespace "http://example.com/ns/example-crypto-types-usage"; 1141 prefix "ectu"; 1143 import ietf-crypto-types { 1144 prefix ct; 1145 reference 1146 "RFC XXXX: Common YANG Data Types for Cryptography"; 1147 } 1149 organization 1150 "Example Corporation"; 1152 contact 1153 "Author: YANG Designer "; 1155 description 1156 "This module illustrates the grouping 1157 defined in the crypto-types draft called 1158 'asymmetric-key-pair-with-certs-grouping'."; 1160 revision "1001-01-01" { 1161 description 1162 "Initial version"; 1163 reference 1164 "RFC ????: Usage Example for RFC XXXX"; 1165 } 1167 container symmetric-keys { 1168 description 1169 "A container of symmetric keys."; 1170 list symmetric-key { 1171 key name; 1172 description 1173 "A symmetric key"; 1174 leaf name { 1175 type string; 1176 description 1177 "An arbitrary name for this key."; 1178 } 1179 uses ct:symmetric-key-grouping; 1180 } 1181 } 1182 container asymmetric-keys { 1183 description 1184 "A container of asymmetric keys."; 1185 list asymmetric-key { 1186 key name; 1187 leaf name { 1188 type string; 1189 description 1190 "An arbitrary name for this key."; 1191 } 1192 uses ct:asymmetric-key-pair-with-certs-grouping; 1193 description 1194 "An asymmetric key pair with associated certificates."; 1195 } 1196 } 1197 } 1199 Given the above example usage module, the following example 1200 illustrates some configured keys. 1202 1205 1206 ex-symmetric-key 1207 aes-256-cbc 1208 ct:octet-string-key-format 1209 base64encodedvalue== 1210 1211 1212 ex-hidden-symmetric-key 1213 aes-256-cbc 1214 1215 1216 1218 1221 1222 ex-asymmetric-key 1223 rsa2048 1224 1225 ct:subject-public-key-info-format 1226 1227 base64encodedvalue== 1228 1229 ct:rsa-private-key-format 1230 1231 base64encodedvalue== 1232 1233 1234 ex-cert 1235 base64encodedvalue== 1236 1237 1238 1239 1240 ex-hidden-asymmetric-key 1241 rsa2048 1242 1243 ct:subject-public-key-info-format 1244 1245 base64encodedvalue== 1246 1247 1248 1249 ex-hidden-key-cert 1250 base64encodedvalue== 1251 1252 1253 1254 1256 2.3.2. The "generate-certificate-signing-request" Action 1258 The following example illustrates the "generate-certificate-signing- 1259 request" action with the NETCONF protocol. 1261 REQUEST 1263 1265 1266 1268 1269 ex-key-sect571r1 1270 1271 base64encodedvalue== 1272 base64encodedvalue== 1273 1274 1275 1276 1277 1279 RESPONSE 1281 1283 1285 base64encodedvalue== 1286 1287 1289 2.3.3. The "certificate-expiration" Notification 1291 The following example illustrates the "certificate-expiration" 1292 notification with the NETCONF protocol. 1294 1296 2018-05-25T00:01:00Z 1297 1298 1299 locally-defined key 1300 1301 1302 my-cert 1303 1304 1305 2018-08-05T14:18:53-05:00 1306 1307 1308 1309 1310 1311 1312 1314 3. The Symmetric Algorithms Module 1316 3.1. Tree Diagram 1318 This section provides a tree diagram [RFC8340] for the "iana- 1319 symmetric-algs" module. Only the "container" statement is 1320 represented, as tree diagrams have no means to represent "typedef" 1321 statements. 1323 module: iana-symmetric-algs 1324 +--ro supported-symmetric-algorithms 1325 +--ro supported-symmetric-algorithm* [algorithm] 1326 +--ro algorithm symmetric-algorithm-type 1328 3.2. YANG Module 1330 This module has normative references to FIXME... 1332 file "iana-symmetric-algs@2019-11-20.yang" 1334 module iana-symmetric-algs { 1335 yang-version 1.1; 1336 namespace "urn:ietf:params:xml:ns:yang:iana-symmetric-algs"; 1337 prefix isa; 1339 organization 1340 "IETF NETCONF (Network Configuration) Working Group"; 1342 contact 1343 "WG Web: 1344 WG List: 1345 Author: Kent Watsen 1346 Author: Wang Haiguang "; 1348 description 1349 "This module defines a typedef for symmetric algorithms, and 1350 a container for a list of symmetric algorithms supported by 1351 the server. 1353 Copyright (c) 2019 IETF Trust and the persons identified 1354 as authors of the code. All rights reserved. 1355 Redistribution and use in source and binary forms, with 1356 or without modification, is permitted pursuant to, and 1357 subject to the license terms contained in, the Simplified 1358 BSD License set forth in Section 4.c of the IETF Trust's 1359 Legal Provisions Relating to IETF Documents 1360 (https://trustee.ietf.org/license-info). 1362 This version of this YANG module is part of RFC XXXX 1363 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1364 itself for full legal notices. 1366 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1367 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1368 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1369 are to be interpreted as described in BCP 14 (RFC 2119) 1370 (RFC 8174) when, and only when, they appear in all 1371 capitals, as shown here."; 1373 revision 2019-11-20 { 1374 description 1375 "Initial version"; 1376 reference 1377 "RFC XXXX: Common YANG Data Types for Cryptography"; 1378 } 1380 // Typedefs 1382 typedef symmetric-algorithm-type { 1383 type enumeration { 1384 enum aes-128-cbc { 1385 value 1; 1386 description 1387 "Encrypt message with AES algorithm in CBC mode with 1388 a key length of 128 bits."; 1389 reference 1390 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1391 Encryption Algorithm in Cryptographic Message Syntax 1392 (CMS)"; 1393 } 1394 enum aes-192-cbc { 1395 value 2; 1396 description 1397 "Encrypt message with AES algorithm in CBC mode with 1398 a key length of 192 bits"; 1399 reference 1400 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1401 Encryption Algorithm in Cryptographic Message Syntax 1402 (CMS)"; 1403 } 1404 enum aes-256-cbc { 1405 value 3; 1406 description 1407 "Encrypt message with AES algorithm in CBC mode with 1408 a key length of 256 bits"; 1409 reference 1410 "RFC 3565: Use of the Advanced Encryption Standard (AES) 1411 Encryption Algorithm in Cryptographic Message Syntax 1412 (CMS)"; 1413 } 1414 enum aes-128-ctr { 1415 value 4; 1416 description 1417 "Encrypt message with AES algorithm in CTR mode with 1418 a key length of 128 bits"; 1419 reference 1420 "RFC 3686: 1421 Using Advanced Encryption Standard (AES) Counter 1422 Mode with IPsec Encapsulating Security Payload 1423 (ESP)"; 1424 } 1425 enum aes-192-ctr { 1426 value 5; 1427 description 1428 "Encrypt message with AES algorithm in CTR mode with 1429 a key length of 192 bits"; 1430 reference 1431 "RFC 3686: 1432 Using Advanced Encryption Standard (AES) Counter 1433 Mode with IPsec Encapsulating Security Payload 1434 (ESP)"; 1435 } 1436 enum aes-256-ctr { 1437 value 6; 1438 description 1439 "Encrypt message with AES algorithm in CTR mode with 1440 a key length of 256 bits"; 1441 reference 1442 "RFC 3686: 1443 Using Advanced Encryption Standard (AES) Counter 1444 Mode with IPsec Encapsulating Security Payload 1445 (ESP)"; 1446 } 1447 enum des3-cbc-sha1-kd { 1448 value 7; 1449 description 1450 "Encrypt message with 3DES algorithm in CBC mode 1451 with sha1 function for key derivation"; 1452 reference 1453 "RFC 3961: 1454 Encryption and Checksum Specifications for 1455 Kerberos 5"; 1456 } 1457 enum rc4-hmac { 1458 value 8; 1459 description 1460 "Encrypt message with rc4 algorithm"; 1461 reference 1462 "RFC 4757: 1463 The RC4-HMAC Kerberos Encryption Types Used by 1464 Microsoft Windows"; 1465 } 1466 enum rc4-hmac-exp { 1467 value 9; 1468 description 1469 "Encrypt message with rc4 algorithm that is exportable"; 1470 reference 1471 "RFC 4757: 1472 The RC4-HMAC Kerberos Encryption Types Used by 1473 Microsoft Windows"; 1474 } 1475 } 1476 description 1477 "A typedef enumerating various symmetric key algorithms."; 1478 } 1480 // Protocol-accessible Nodes 1481 container supported-symmetric-algorithms { 1482 config false; 1483 description 1484 "A container for a list of supported symmetric algorithms. 1485 How algorithms come to be supported is outside the scope 1486 of this module."; 1487 list supported-symmetric-algorithm { 1488 key algorithm; 1489 description 1490 "A lists of symmetric algorithms supported by the server."; 1491 leaf algorithm { 1492 type symmetric-algorithm-type; 1493 description 1494 "An symmetric algorithms supported by the server."; 1495 } 1496 } 1497 } 1499 } 1501 1503 3.3. Examples 1505 The following example illustrates the "supported-symmetric- 1506 algorithms" "container" statement with the NETCONF protocol. 1508 1510 1511 aes-128-cbc 1512 1513 1514 aes-256-cbc 1515 1516 1518 4. The Asymmetric Algorithms Module 1520 4.1. Tree Diagram 1522 This section provides a tree diagram [RFC8340] for the "iana- 1523 asymmetric-algs" module. Only the "container" statement is 1524 represented, as tree diagrams have no means to represent "typedef" 1525 statements. 1527 module: iana-asymmetric-algs 1528 +--ro supported-asymmetric-algorithms 1529 +--ro supported-asymmetric-algorithm* [algorithm] 1530 +--ro algorithm asymmetric-algorithm-type 1532 4.2. YANG Module 1534 This module has normative references to FIXME... 1536 file "iana-asymmetric-algs@2019-11-20.yang" 1538 module iana-asymmetric-algs { 1539 yang-version 1.1; 1540 namespace "urn:ietf:params:xml:ns:yang:iana-asymmetric-algs"; 1541 prefix iasa; 1543 organization 1544 "IETF NETCONF (Network Configuration) Working Group"; 1546 contact 1547 "WG Web: 1548 WG List: 1549 Author: Kent Watsen 1550 Author: Wang Haiguang "; 1552 description 1553 "This module defines a typedef for asymmetric algorithms, and 1554 a container for a list of asymmetric algorithms supported by 1555 the server. 1557 Copyright (c) 2019 IETF Trust and the persons identified 1558 as authors of the code. All rights reserved. 1559 Redistribution and use in source and binary forms, with 1560 or without modification, is permitted pursuant to, and 1561 subject to the license terms contained in, the Simplified 1562 BSD License set forth in Section 4.c of the IETF Trust's 1563 Legal Provisions Relating to IETF Documents 1564 (https://trustee.ietf.org/license-info). 1566 This version of this YANG module is part of RFC XXXX 1567 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1568 itself for full legal notices. 1570 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1571 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1572 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1573 are to be interpreted as described in BCP 14 (RFC 2119) 1574 (RFC 8174) when, and only when, they appear in all 1575 capitals, as shown here."; 1577 revision 2019-11-20 { 1578 description 1579 "Initial version"; 1580 reference 1581 "RFC XXXX: Common YANG Data Types for Cryptography"; 1582 } 1584 // Typedefs 1586 typedef asymmetric-algorithm-type { 1587 type enumeration { 1588 enum rsa1024 { 1589 value 1; 1590 description 1591 "The RSA algorithm using a 1024-bit key."; 1592 reference 1593 "RFC 8017: PKCS #1: RSA Cryptography 1594 Specifications Version 2.2."; 1595 } 1596 enum rsa2048 { 1597 value 2; 1598 description 1599 "The RSA algorithm using a 2048-bit key."; 1600 reference 1601 "RFC 8017: 1602 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1603 } 1604 enum rsa3072 { 1605 value 3; 1606 description 1607 "The RSA algorithm using a 3072-bit key."; 1608 reference 1609 "RFC 8017: 1610 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1611 } 1612 enum rsa4096 { 1613 value 4; 1614 description 1615 "The RSA algorithm using a 4096-bit key."; 1616 reference 1617 "RFC 8017: 1618 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1619 } 1620 enum rsa7680 { 1621 value 5; 1622 description 1623 "The RSA algorithm using a 7680-bit key."; 1624 reference 1625 "RFC 8017: 1626 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1627 } 1628 enum rsa15360 { 1629 value 6; 1630 description 1631 "The RSA algorithm using a 15360-bit key."; 1632 reference 1633 "RFC 8017: 1634 PKCS #1: RSA Cryptography Specifications Version 2.2."; 1635 } 1636 enum secp192r1 { 1637 value 7; 1638 description 1639 "The asymmetric algorithm using a NIST P192 Curve."; 1640 reference 1641 "RFC 6090: 1642 Fundamental Elliptic Curve Cryptography Algorithms. 1643 RFC 5480: 1644 Elliptic Curve Cryptography Subject Public Key 1645 Information."; 1646 } 1647 enum secp224r1 { 1648 value 8; 1649 description 1650 "The asymmetric algorithm using a NIST P224 Curve."; 1651 reference 1652 "RFC 6090: 1653 Fundamental Elliptic Curve Cryptography Algorithms. 1654 RFC 5480: 1655 Elliptic Curve Cryptography Subject Public Key 1656 Information."; 1657 } 1658 enum secp256r1 { 1659 value 9; 1660 description 1661 "The asymmetric algorithm using a NIST P256 Curve."; 1662 reference 1663 "RFC 6090: 1664 Fundamental Elliptic Curve Cryptography Algorithms. 1665 RFC 5480: 1666 Elliptic Curve Cryptography Subject Public Key 1667 Information."; 1668 } 1669 enum secp384r1 { 1670 value 10; 1671 description 1672 "The asymmetric algorithm using a NIST P384 Curve."; 1673 reference 1674 "RFC 6090: 1675 Fundamental Elliptic Curve Cryptography Algorithms. 1676 RFC 5480: 1677 Elliptic Curve Cryptography Subject Public Key 1678 Information."; 1679 } 1680 enum secp521r1 { 1681 value 11; 1682 description 1683 "The asymmetric algorithm using a NIST P521 Curve."; 1684 reference 1685 "RFC 6090: 1686 Fundamental Elliptic Curve Cryptography Algorithms. 1687 RFC 5480: 1688 Elliptic Curve Cryptography Subject Public Key 1689 Information."; 1690 } 1691 enum x25519 { 1692 value 12; 1693 description 1694 "The asymmetric algorithm using a x.25519 Curve."; 1695 reference 1696 "RFC 7748: 1697 Elliptic Curves for Security."; 1698 } 1699 enum x448 { 1700 value 13; 1701 description 1702 "The asymmetric algorithm using a x.448 Curve."; 1703 reference 1704 "RFC 7748: 1705 Elliptic Curves for Security."; 1706 } 1707 } 1708 description 1709 "A typedef enumerating various asymmetric key algorithms."; 1710 } 1712 // Protocol-accessible Nodes 1714 container supported-asymmetric-algorithms { 1715 config false; 1716 description 1717 "A container for a list of supported asymmetric algorithms. 1718 How algorithms come to be supported is outside the scope 1719 of this module."; 1720 list supported-asymmetric-algorithm { 1721 key algorithm; 1722 description 1723 "A lists of asymmetric algorithms supported by the server."; 1724 leaf algorithm { 1725 type asymmetric-algorithm-type; 1726 description 1727 "An asymmetric algorithms supported by the server."; 1728 } 1729 } 1730 } 1732 } 1734 1736 4.3. Examples 1738 The following example illustrates the "supported-asymmetric- 1739 algorithms" "container" statement with the NETCONF protocol. 1741 1743 1744 rsa2048 1745 1746 1747 secp256r1 1748 1749 1751 5. The Hash Algorithms Module 1753 5.1. Tree Diagram 1755 This section provides a tree diagram [RFC8340] for the "iana-hash- 1756 algs" module. Only the "container" statement is represented, as tree 1757 diagrams have no means to represent "typedef" statements. 1759 module: iana-hash-algs 1760 +--ro supported-hash-algorithms 1761 +--ro supported-hash-algorithm* [algorithm] 1762 +--ro algorithm hash-algorithm-type 1764 5.2. YANG Module 1766 This module has normative references to FIXME... 1768 file "iana-hash-algs@2019-11-20.yang" 1770 module iana-hash-algs { 1771 yang-version 1.1; 1772 namespace "urn:ietf:params:xml:ns:yang:iana-hash-algs"; 1773 prefix iha; 1775 organization 1776 "IETF NETCONF (Network Configuration) Working Group"; 1778 contact 1779 "WG Web: 1780 WG List: 1781 Author: Kent Watsen 1782 Author: Wang Haiguang "; 1784 description 1785 "This module defines a typedef for hash algorithms, and 1786 a container for a list of hash algorithms supported by 1787 the server. 1789 Copyright (c) 2019 IETF Trust and the persons identified 1790 as authors of the code. All rights reserved. 1791 Redistribution and use in source and binary forms, with 1792 or without modification, is permitted pursuant to, and 1793 subject to the license terms contained in, the Simplified 1794 BSD License set forth in Section 4.c of the IETF Trust's 1795 Legal Provisions Relating to IETF Documents 1796 (https://trustee.ietf.org/license-info). 1798 This version of this YANG module is part of RFC XXXX 1799 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 1800 itself for full legal notices. 1802 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1803 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1804 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1805 are to be interpreted as described in BCP 14 (RFC 2119) 1806 (RFC 8174) when, and only when, they appear in all 1807 capitals, as shown here."; 1809 revision 2019-11-20 { 1810 description 1811 "Initial version"; 1813 reference 1814 "RFC XXXX: Common YANG Data Types for Cryptography"; 1815 } 1817 // Typedefs 1819 typedef hash-algorithm-type { 1820 type enumeration { 1821 enum sha1 { 1822 value 1; 1823 status obsolete; 1824 description 1825 "The SHA1 algorithm."; 1826 reference 1827 "RFC 3174: US Secure Hash Algorithms 1 (SHA1)."; 1828 } 1829 enum sha-224 { 1830 value 2; 1831 description 1832 "The SHA-224 algorithm."; 1833 reference 1834 "RFC 6234: US Secure Hash Algorithms."; 1835 } 1836 enum sha-256 { 1837 value 3; 1838 description 1839 "The SHA-256 algorithm."; 1840 reference 1841 "RFC 6234: US Secure Hash Algorithms."; 1842 } 1843 enum sha-384 { 1844 value 4; 1845 description 1846 "The SHA-384 algorithm."; 1847 reference 1848 "RFC 6234: US Secure Hash Algorithms."; 1849 } 1850 enum sha-512 { 1851 value 5; 1852 description 1853 "The SHA-512 algorithm."; 1854 reference 1855 "RFC 6234: US Secure Hash Algorithms."; 1856 } 1857 enum shake-128 { 1858 value 6; 1859 description 1860 "The SHA3 algorithm with 128-bits output."; 1862 reference 1863 "National Institute of Standards and Technology, 1864 SHA-3 Standard: Permutation-Based Hash and 1865 Extendable-Output Functions, FIPS PUB 202, DOI 1866 10.6028/NIST.FIPS.202, August 2015."; 1867 } 1868 enum shake-224 { 1869 value 7; 1870 description 1871 "The SHA3 algorithm with 224-bits output."; 1872 reference 1873 "National Institute of Standards and Technology, 1874 SHA-3 Standard: Permutation-Based Hash and 1875 Extendable-Output Functions, FIPS PUB 202, DOI 1876 10.6028/NIST.FIPS.202, August 2015."; 1877 } 1878 enum shake-256 { 1879 value 8; 1880 description 1881 "The SHA3 algorithm with 256-bits output."; 1882 reference 1883 "National Institute of Standards and Technology, 1884 SHA-3 Standard: Permutation-Based Hash and 1885 Extendable-Output Functions, FIPS PUB 202, DOI 1886 10.6028/NIST.FIPS.202, August 2015."; 1887 } 1888 enum shake-384 { 1889 value 9; 1890 description 1891 "The SHA3 algorithm with 384-bits output."; 1892 reference 1893 "National Institute of Standards and Technology, 1894 SHA-3 Standard: Permutation-Based Hash and 1895 Extendable-Output Functions, FIPS PUB 202, DOI 1896 10.6028/NIST.FIPS.202, August 2015."; 1897 } 1898 enum shake-512 { 1899 value 10; 1900 description 1901 "The SHA3 algorithm with 384-bits output."; 1902 reference 1903 "National Institute of Standards and Technology, 1904 SHA-3 Standard: Permutation-Based Hash and 1905 Extendable-Output Functions, FIPS PUB 202, DOI 1906 10.6028/NIST.FIPS.202, August 2015."; 1907 } 1908 } 1909 description 1910 "A typedef enumerating various hash key algorithms."; 1911 } 1913 // Protocol-accessible Nodes 1915 container supported-hash-algorithms { 1916 config false; 1917 description 1918 "A container for a list of supported hash algorithms. 1919 How algorithms come to be supported is outside the 1920 scope of this module."; 1921 list supported-hash-algorithm { 1922 key algorithm; 1923 description 1924 "A lists of hash algorithms supported by the server."; 1925 leaf algorithm { 1926 type hash-algorithm-type; 1927 description 1928 "An hash algorithms supported by the server."; 1929 } 1930 } 1931 } 1933 } 1935 1937 5.3. Examples 1939 The following example illustrates the "supported-hash-algorithms" 1940 "container" statement with the NETCONF protocol. 1942 1944 1945 sha-256 1946 1947 1948 sha-512 1949 1950 1952 6. Security Considerations 1953 6.1. Support for Algorithms 1955 In order to use YANG identities for algorithm identifiers, only the 1956 most commonly used RSA key lengths are supported for the RSA 1957 algorithm. Additional key lengths can be defined in another module 1958 or added into a future version of this document. 1960 This document limits the number of elliptical curves supported. This 1961 was done to match industry trends and IETF best practice (e.g., 1962 matching work being done in TLS 1.3). If additional algorithms are 1963 needed, they can be defined by another module or added into a future 1964 version of this document. 1966 6.2. No Support for CRMF 1968 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1969 signing-request" action. The use of Certificate Request Message 1970 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1971 was market demand for it. If it is desired to support CRMF in the 1972 future, a backwards compatible solution can be defined at that time. 1974 6.3. Access to Data Nodes 1976 The YANG module in this document defines "grouping" statements that 1977 are designed to be accessed via YANG based management protocols, such 1978 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1979 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1980 with mutual authentication. 1982 The NETCONF access control model (NACM) [RFC8341] provides the means 1983 to restrict access for particular users to a pre-configured subset of 1984 all available protocol operations and content. 1986 Since the module in this document only define groupings, these 1987 considerations are primarily for the designers of other modules that 1988 use these groupings. 1990 There are a number of data nodes defined by the grouping statements 1991 that are writable/creatable/deletable (i.e., config true, which is 1992 the default). Some of these data nodes may be considered sensitive 1993 or vulnerable in some network environments. Write operations (e.g., 1994 edit-config) to these data nodes without proper protection can have a 1995 negative effect on network operations. These are the subtrees and 1996 data nodes and their sensitivity/vulnerability: 1998 *: All of the data nodes defined by all the groupings are 1999 considered sensitive to write operations. For instance, the 2000 modification of a public key or a certificate can dramatically 2001 alter the implemented security policy. For this reason, the 2002 NACM extension "default-deny-write" has been applied to all the 2003 data nodes defined by all the groupings. 2005 Some of the readable data nodes in the YANG module may be considered 2006 sensitive or vulnerable in some network environments. It is thus 2007 important to control read access (e.g., via get, get-config, or 2008 notification) to these data nodes. These are the subtrees and data 2009 nodes and their sensitivity/vulnerability: 2011 /private-key: The "private-key" node defined in the "asymmetric- 2012 key-pair-grouping" grouping is additionally sensitive to read 2013 operations such that, in normal use cases, it should never be 2014 returned to a client. For this reason, the NACM extension 2015 "default-deny-all" has been applied to it here. 2017 Some of the operations in this YANG module may be considered 2018 sensitive or vulnerable in some network environments. It is thus 2019 important to control access to these operations. These are the 2020 operations and their sensitivity/vulnerability: 2022 *: All of the "action" statements defined by groupings SHOULD only 2023 be executed by authorized users. For this reason, the NACM 2024 extension "default-deny-all" has been applied to all of them. 2025 Note that NACM uses "default-deny-all" to protect "RPC" and 2026 "action" statements; it does not define, e.g., an extension 2027 called "default-deny-execute". 2029 generate-certificate-signing-request: For this action, it is 2030 RECOMMENDED that implementations assert channel binding 2031 [RFC5056], so as to ensure that the application layer that sent 2032 the request is the same as the device authenticated when the 2033 secure transport layer was established. 2035 7. IANA Considerations 2037 7.1. The IETF XML Registry 2039 This document registers four URIs in the "ns" subregistry of the IETF 2040 XML Registry [RFC3688]. Following the format in [RFC3688], the 2041 following registrations are requested: 2043 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2044 Registrant Contact: The NETCONF WG of the IETF. 2045 XML: N/A, the requested URI is an XML namespace. 2047 URI: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 2048 Registrant Contact: The NETCONF WG of the IETF. 2049 XML: N/A, the requested URI is an XML namespace. 2051 URI: urn:ietf:params:xml:ns:yang:iana-ssymmetric-algs 2052 Registrant Contact: The NETCONF WG of the IETF. 2053 XML: N/A, the requested URI is an XML namespace. 2055 URI: urn:ietf:params:xml:ns:yang:iana-hash-algs 2056 Registrant Contact: The NETCONF WG of the IETF. 2057 XML: N/A, the requested URI is an XML namespace. 2059 7.2. The YANG Module Names Registry 2061 This document registers four YANG modules in the YANG Module Names 2062 registry [RFC6020]. Following the format in [RFC6020], the the 2063 following registrations are requested: 2065 name: ietf-crypto-types 2066 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2067 prefix: ct 2068 reference: RFC XXXX 2070 name: iana-symmetric-algs 2071 namespace: urn:ietf:params:xml:ns:yang:iana-symmetric-algs 2072 prefix: isa 2073 reference: RFC XXXX 2075 name: iana-asymmetric-algs 2076 namespace: urn:ietf:params:xml:ns:yang:iana-asymmetric-algs 2077 prefix: iasa 2078 reference: RFC XXXX 2080 name: iana-hash-algs 2081 namespace: urn:ietf:params:xml:ns:yang:iana-hash-algs 2082 prefix: iha 2083 reference: RFC XXXX 2085 8. References 2086 8.1. Normative References 2088 [ITU.X690.2015] 2089 International Telecommunication Union, "Information 2090 Technology - ASN.1 encoding rules: Specification of Basic 2091 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2092 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2093 X.690, ISO/IEC 8825-1, August 2015, 2094 . 2096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2097 Requirement Levels", BCP 14, RFC 2119, 2098 DOI 10.17487/RFC2119, March 1997, 2099 . 2101 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2102 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 2103 1998, . 2105 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 2106 Encryption Algorithm in Cryptographic Message Syntax 2107 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 2108 . 2110 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2111 Counter Mode With IPsec Encapsulating Security Payload 2112 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2113 . 2115 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2116 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2117 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2118 . 2120 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2121 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2122 January 2006, . 2124 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 2125 Ciphersuites for Transport Layer Security (TLS)", 2126 RFC 4279, DOI 10.17487/RFC4279, December 2005, 2127 . 2129 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2130 Mode with IPsec Encapsulating Security Payload (ESP)", 2131 RFC 4309, DOI 10.17487/RFC4309, December 2005, 2132 . 2134 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 2135 Algorithm and Its Use with IPsec", RFC 4494, 2136 DOI 10.17487/RFC4494, June 2006, 2137 . 2139 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2140 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2141 DOI 10.17487/RFC4543, May 2006, 2142 . 2144 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 2145 384, and HMAC-SHA-512 with IPsec", RFC 4868, 2146 DOI 10.17487/RFC4868, May 2007, 2147 . 2149 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2150 Housley, R., and W. Polk, "Internet X.509 Public Key 2151 Infrastructure Certificate and Certificate Revocation List 2152 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2153 . 2155 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2156 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2157 . 2159 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 2160 Integration in the Secure Shell Transport Layer", 2161 RFC 5656, DOI 10.17487/RFC5656, December 2009, 2162 . 2164 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 2165 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 2166 March 2011, . 2168 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2169 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2170 . 2172 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 2173 Ephemeral Parameters for Transport Layer Security (TLS)", 2174 RFC 7919, DOI 10.17487/RFC7919, August 2016, 2175 . 2177 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2178 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2179 . 2181 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2182 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2183 May 2017, . 2185 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 2186 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 2187 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 2188 . 2190 [RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in 2191 the Secure Shell (SSH) Protocol", RFC 8332, 2192 DOI 10.17487/RFC8332, March 2018, 2193 . 2195 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2196 Access Control Model", STD 91, RFC 8341, 2197 DOI 10.17487/RFC8341, March 2018, 2198 . 2200 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 2201 Curve Cryptography (ECC) Cipher Suites for Transport Layer 2202 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 2203 DOI 10.17487/RFC8422, August 2018, 2204 . 2206 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2207 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2208 . 2210 8.2. Informative References 2212 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2213 Request Syntax Specification Version 1.7", RFC 2986, 2214 DOI 10.17487/RFC2986, November 2000, 2215 . 2217 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 2218 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 2219 . 2221 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2222 DOI 10.17487/RFC3688, January 2004, 2223 . 2225 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2226 Certificate Request Message Format (CRMF)", RFC 4211, 2227 DOI 10.17487/RFC4211, September 2005, 2228 . 2230 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2231 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2232 2006, . 2234 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2235 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2236 . 2238 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2239 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2240 . 2242 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2243 the Network Configuration Protocol (NETCONF)", RFC 6020, 2244 DOI 10.17487/RFC6020, October 2010, 2245 . 2247 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2248 Verification of Domain-Based Application Service Identity 2249 within Internet Public Key Infrastructure Using X.509 2250 (PKIX) Certificates in the Context of Transport Layer 2251 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2252 2011, . 2254 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2255 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2256 DOI 10.17487/RFC6234, May 2011, 2257 . 2259 [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell 2260 (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011, 2261 . 2263 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2264 and A. Bierman, Ed., "Network Configuration Protocol 2265 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2266 . 2268 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 2269 Signatures for Identity-Based Encryption (ECCSI)", 2270 RFC 6507, DOI 10.17487/RFC6507, February 2012, 2271 . 2273 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2274 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2275 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2276 . 2278 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2279 Signature Algorithm (EdDSA)", RFC 8032, 2280 DOI 10.17487/RFC8032, January 2017, 2281 . 2283 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2284 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2285 . 2287 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2288 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2289 . 2291 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2292 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2293 . 2295 Appendix A. Change Log 2297 A.1. I-D to 00 2299 o Removed groupings and notifications. 2301 o Added typedefs for identityrefs. 2303 o Added typedefs for other RFC 5280 structures. 2305 o Added typedefs for other RFC 5652 structures. 2307 o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2309 A.2. 00 to 01 2311 o Moved groupings from the draft-ietf-netconf-keystore here. 2313 A.3. 01 to 02 2315 o Removed unwanted "mandatory" and "must" statements. 2317 o Added many new crypto algorithms (thanks Haiguang!) 2319 o Clarified in asymmetric-key-pair-with-certs-grouping, in 2320 certificates/certificate/name/description, that if the name MUST 2321 NOT match the name of a certificate that exists independently in 2322 , enabling certs installed by the manufacturer (e.g., 2323 an IDevID). 2325 A.4. 02 to 03 2327 o renamed base identity 'asymmetric-key-encryption-algorithm' to 2328 'asymmetric-key-algorithm'. 2330 o added new 'asymmetric-key-algorithm' identities for secp192r1, 2331 secp224r1, secp256r1, secp384r1, and secp521r1. 2333 o removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2334 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2335 aes-256-gcm, and mac-chacha20-poly1305. 2337 o for all -cbc and -ctr identities, renamed base identity 2338 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2340 o for all -ccm and -gcm identities, renamed base identity 2341 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2342 algorithm' and renamed the identity to remove the "enc-" prefix. 2344 o for all the 'signature-algorithm' based identities, renamed from 2345 'rsa-*' to 'rsassa-*'. 2347 o removed all of the "x509v3-" prefixed 'signature-algorithm' based 2348 identities. 2350 o added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2351 and 'rsaes-pkcs1-v1_5'. 2353 o renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2354 'symmetric-key-algorithm-ref'. 2356 o renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2357 'asymmetric-key-algorithm-ref'. 2359 o added typedef 'encryption-and-mac-algorithm-ref'. 2361 o Updated copyright date, boilerplate template, affiliation, and 2362 folding algorithm. 2364 A.5. 03 to 04 2366 o ran YANG module through formatter. 2368 A.6. 04 to 05 2370 o fixed broken symlink causing reformatted YANG module to not show. 2372 A.7. 05 to 06 2374 o Added NACM annotations. 2376 o Updated Security Considerations section. 2378 o Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2380 o Removed text from 'permanently-hidden' enum regarding such keys 2381 not being backed up or restored. 2383 o Updated the boilerplate text in module-level "description" 2384 statement to match copyeditor convention. 2386 o Added an explanation to the 'public-key-grouping' and 'asymmetric- 2387 key-pair-grouping' statements as for why the nodes are not 2388 mandatory (e.g., because they may exist only in . 2390 o Added 'must' expressions to the 'public-key-grouping' and 2391 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2392 are either all exist or do not all exist. 2394 o Added an explanation to the 'permanently-hidden' that the value 2395 cannot be configured directly by clients and servers MUST fail any 2396 attempt to do so. 2398 o Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2399 grouping' (the plural form of existing groupings). 2401 o Now states that keys created in by the *-hidden-key 2402 actions are bound to the lifetime of the parent 'config true' 2403 node, and that subsequent invocations of either action results in 2404 a failure. 2406 A.8. 06 to 07 2408 o Added clarifications that implementations SHOULD assert that 2409 configured certificates contain the matching public key. 2411 o Replaced the 'generate-hidden-key' and 'install-hidden-key' 2412 actions with special 'crypt-hash' -like input/output values. 2414 A.9. 07 to 08 2416 o Removed the 'generate-key and 'hidden-key' features. 2418 o Added grouping symmetric-key-grouping 2420 o Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2421 statement for the keystone module to augment into, as well as 2422 replacing the 'union' with leafs (having different NACM settings. 2424 A.10. 08 to 09 2426 o Converting algorithm from identities to enumerations. 2428 A.11. 09 to 10 2430 o All of the below changes are to the algorithm enumerations defined 2431 in ietf-crypto-types. 2433 o Add in support for key exchange over x.25519 and x.448 based on 2434 RFC 8418. 2436 o Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2437 o Revise/add in enum of signature algorithm for x25519 and x448 2439 o Add in des3-cbc-sha1 for IPSec 2441 o Add in sha1-des3-kd for IPSec 2443 o Add in definit for rc4-hmac and rc4-hmac-exp. These two 2444 algorithms have been deprecated in RFC 8429. But some existing 2445 draft in i2nsf may still want to use them. 2447 o Add x25519 and x448 curve for asymmetric algorithms 2449 o Add signature algorithms ed25519, ed25519-cts, ed25519ph 2451 o add signature algorithms ed448, ed448ph 2453 o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2455 A.12. 10 to 11 2457 o Added a "key-format" identity. 2459 o Added symmetric keys to the example in Section 2.3. 2461 A.13. 11 to 12 2463 o Removed all non-essential (to NC/RC) algorithm types. 2465 o Moved remaining algorithm types each into its own module. 2467 o Added a 'config false' "algorithms-supported" list to each of the 2468 algorithm-type modules. 2470 A.14. 12 to 13 2472 o Added the four features: "[encrypted-]one-[a]symmetric-key- 2473 format", each protecting a 'key-format' identity of the same name. 2475 o Added 'must' expressions asserting that the 'key-format' leaf 2476 exists whenever a non-hidden key is specified. 2478 o Improved the 'description' statements and added 'reference' 2479 statements for the 'key-format' identities. 2481 o Added a questionable forward reference to "encrypted-*" leafs in a 2482 couple 'when' expressions. 2484 o Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 2486 Acknowledgements 2488 The authors would like to thank for following for lively discussions 2489 on list and in the halls (ordered by last name): Martin Bjorklund, 2490 Nick Hancock, Balazs Kovacs, Juergen Schoenwaelder, Eric Voit, and 2491 Liang Xia. 2493 Authors' Addresses 2495 Kent Watsen 2496 Watsen Networks 2498 EMail: kent+ietf@watsen.net 2500 Wang Haiguang 2501 Huawei 2503 EMail: wang.haiguang.shieldlab@huawei.com