idnits 2.17.1 draft-ietf-netconf-crypto-types-15.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 189 has weird spacing: '...-format ide...' == Line 203 has weird spacing: '...on-date yan...' == Line 207 has weird spacing: '...on-date yan...' == Line 211 has weird spacing: '...on-date yan...' == Line 215 has weird spacing: '...on-date yan...' == (6 more instances...) -- The document date (May 20, 2020) is 1438 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) -- Looks like a reference, but probably isn't: '1' on line 1494 -- Looks like a reference, but probably isn't: '2' on line 1496 -- Looks like a reference, but probably isn't: '3' on line 1498 -- Looks like a reference, but probably isn't: '4' on line 1500 -- Looks like a reference, but probably isn't: '5' on line 1502 -- Looks like a reference, but probably isn't: '6' on line 1504 -- Looks like a reference, but probably isn't: '7' on line 1506 -- Looks like a reference, but probably isn't: '8' on line 1508 -- Looks like a reference, but probably isn't: '9' on line 1511 == Unused Reference: 'RFC5226' is defined on line 1458, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 13 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 May 20, 2020 5 Expires: November 21, 2020 7 Common YANG Data Types for Cryptography 8 draft-ietf-netconf-crypto-types-15 10 Abstract 12 This document presents a YANG 1.1 (RFC 7950) module defining 13 identities, typedefs, and groupings useful to cryptographic 14 applications. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains placeholder values that need to be replaced with 19 finalized values at the time of publication. This note summarizes 20 all of the substitutions that are needed. No other RFC Editor 21 instructions are specified elsewhere in this document. 23 Artwork in this document contains shorthand references to drafts in 24 progress. Please apply the following replacements: 26 o "AAAA" --> the assigned RFC value for this draft 28 Artwork in this document contains placeholder values for the date of 29 publication of this draft. Please apply the following replacement: 31 o "2020-05-20" --> the publication date of this draft 33 The following Appendix section is to be removed prior to publication: 35 o Appendix B. Change Log 37 Note to Reviewers (To be removed by RFC Editor) 39 This document presents a YANG module or modules that is/are part of a 40 collection of drafts that work together to produce the ultimate goal 41 of the NETCONF WG: to define configuration modules for NETCONF client 42 and servers, and RESTCONF client and servers. 44 The relationship between the various drafts in the collection is 45 presented in the below diagram. 47 crypto-types 48 ^ ^ 49 / \ 50 / \ 51 trust-anchors keystore 52 ^ ^ ^ ^ 53 | +---------+ | | 54 | | | | 55 | +------------+ | 56 tcp-client-server | / | | 57 ^ ^ ssh-client-server | | 58 | | ^ tls-client-server 59 | | | ^ ^ http-client-server 60 | | | | | ^ 61 | | | +-----+ +---------+ | 62 | | | | | | 63 | +-----------|--------|--------------+ | | 64 | | | | | | 65 +-----------+ | | | | | 66 | | | | | | 67 | | | | | | 68 netconf-client-server restconf-client-server 70 Full draft names and link to drafts: 72 o draft-ietf-netconf-crypto-types (html [1]) 74 o draft-ietf-netconf-trust-anchors (html [2]) 76 o draft-ietf-netconf-keystore (html [3]) 78 o draft-ietf-netconf-tcp-client-server (html [4]) 80 o draft-ietf-netconf-ssh-client-server (html [5]) 82 o draft-ietf-netconf-tls-client-server (html [6]) 84 o draft-ietf-netconf-http-client-server (html [7]) 86 o draft-ietf-netconf-netconf-client-server (html [8]) 88 o draft-ietf-netconf-restconf-client-server (html [9]) 90 Status of This Memo 92 This Internet-Draft is submitted in full conformance with the 93 provisions of BCP 78 and BCP 79. 95 Internet-Drafts are working documents of the Internet Engineering 96 Task Force (IETF). Note that other groups may also distribute 97 working documents as Internet-Drafts. The list of current Internet- 98 Drafts is at https://datatracker.ietf.org/drafts/current/. 100 Internet-Drafts are draft documents valid for a maximum of six months 101 and may be updated, replaced, or obsoleted by other documents at any 102 time. It is inappropriate to use Internet-Drafts as reference 103 material or to cite them other than as "work in progress." 105 This Internet-Draft will expire on November 21, 2020. 107 Copyright Notice 109 Copyright (c) 2020 IETF Trust and the persons identified as the 110 document authors. All rights reserved. 112 This document is subject to BCP 78 and the IETF Trust's Legal 113 Provisions Relating to IETF Documents 114 (https://trustee.ietf.org/license-info) in effect on the date of 115 publication of this document. Please review these documents 116 carefully, as they describe your rights and restrictions with respect 117 to this document. Code Components extracted from this document must 118 include Simplified BSD License text as described in Section 4.e of 119 the Trust Legal Provisions and are provided without warranty as 120 described in the Simplified BSD License. 122 Table of Contents 124 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 125 2. The Crypto Types Module . . . . . . . . . . . . . . . . . . . 4 126 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 127 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 128 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 129 3. Security Considerations . . . . . . . . . . . . . . . . . . . 28 130 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 28 131 3.2. Access to Data Nodes . . . . . . . . . . . . . . . . . . 28 132 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 133 4.1. Update the "IETF XML" Registry . . . . . . . . . . . . . 30 134 4.2. Update the "YANG Module Names" Registry . . . . . . . . . 30 135 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 136 5.1. Normative References . . . . . . . . . . . . . . . . . . 30 137 5.2. Informative References . . . . . . . . . . . . . . . . . 31 138 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 139 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 34 140 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 34 141 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 34 142 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 34 143 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 34 144 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 35 145 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 35 146 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 35 147 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 36 148 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 36 149 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 36 150 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 36 151 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 37 152 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 37 153 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 37 154 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 38 155 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 38 156 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38 157 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 159 1. Introduction 161 This document presents a YANG 1.1 [RFC7950] module defining 162 identities, typedefs, and groupings useful to cryptographic 163 applications. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 2. The Crypto Types Module 173 2.1. Tree Diagram 175 This section provides a tree diagram [RFC8340] for the "ietf-crypto- 176 types" module. Only "grouping" statements are represented, as tree 177 diagrams have no means to represent identities or typedefs. 179 module: ietf-crypto-types 181 grouping symmetric-key-grouping 182 +-- key-format? identityref 183 +-- (key-type) 184 +--:(key) 185 | +-- key? binary 186 +--:(hidden-key) 187 +-- hidden-key? empty 188 grouping public-key-grouping 189 +-- public-key-format identityref 190 +-- public-key binary 191 grouping asymmetric-key-pair-grouping 192 +-- public-key-format identityref 193 +-- public-key binary 194 +-- private-key-format? identityref 195 +-- (private-key-type) 196 +--:(private-key) 197 | +-- private-key? binary 198 +--:(hidden-private-key) 199 +-- hidden-private-key? empty 200 grouping trust-anchor-cert-grouping 201 +-- cert? trust-anchor-cert-cms 202 +---n certificate-expiration 203 +-- expiration-date yang:date-and-time 204 grouping trust-anchor-certs-grouping 205 +-- cert* trust-anchor-cert-cms 206 +---n certificate-expiration 207 +-- expiration-date yang:date-and-time 208 grouping end-entity-cert-grouping 209 +-- cert? end-entity-cert-cms 210 +---n certificate-expiration 211 +-- expiration-date yang:date-and-time 212 grouping end-entity-certs-grouping 213 +-- cert* end-entity-cert-cms 214 +---n certificate-expiration 215 +-- expiration-date yang:date-and-time 216 grouping generate-csr-grouping 217 +---x generate-certificate-signing-request 218 {certificate-signing-request-generation}? 219 +---w input 220 | +---w subject binary 221 | +---w attributes? binary 222 +--ro output 223 +--ro certificate-signing-request ct:csr 224 grouping asymmetric-key-pair-with-cert-grouping 225 +-- public-key-format identityref 226 +-- public-key binary 227 +-- private-key-format? identityref 228 +-- (private-key-type) 229 | +--:(private-key) 230 | | +-- private-key? binary 231 | +--:(hidden-private-key) 232 | +-- hidden-private-key? empty 233 +-- cert? end-entity-cert-cms 234 +---n certificate-expiration 235 | +-- expiration-date yang:date-and-time 236 +---x generate-certificate-signing-request 237 {certificate-signing-request-generation}? 238 +---w input 239 | +---w subject binary 240 | +---w attributes? binary 241 +--ro output 242 +--ro certificate-signing-request ct:csr 243 grouping asymmetric-key-pair-with-certs-grouping 244 +-- public-key-format identityref 245 +-- public-key binary 246 +-- private-key-format? identityref 247 +-- (private-key-type) 248 | +--:(private-key) 249 | | +-- private-key? binary 250 | +--:(hidden-private-key) 251 | +-- hidden-private-key? empty 252 +-- certificates 253 | +-- certificate* [name] 254 | +-- name? string 255 | +-- cert end-entity-cert-cms 256 | +---n certificate-expiration 257 | +-- expiration-date yang:date-and-time 258 +---x generate-certificate-signing-request 259 {certificate-signing-request-generation}? 260 +---w input 261 | +---w subject binary 262 | +---w attributes? binary 263 +--ro output 264 +--ro certificate-signing-request ct:csr 266 2.2. YANG Module 268 This module has normative references to [RFC2119], [RFC2986], 269 [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], 270 [RFC6031], [RFC6125], [RFC6991], [RFC8174], [RFC8341], and 271 [ITU.X690.2015]. 273 file "ietf-crypto-types@2020-05-20.yang" 275 module ietf-crypto-types { 276 yang-version 1.1; 277 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 278 prefix ct; 280 import ietf-yang-types { 281 prefix yang; 282 reference 283 "RFC 6991: Common YANG Data Types"; 284 } 286 import ietf-netconf-acm { 287 prefix nacm; 288 reference 289 "RFC 8341: Network Configuration Access Control Model"; 290 } 292 organization 293 "IETF NETCONF (Network Configuration) Working Group"; 295 contact 296 "WG Web: 297 WG List: 298 Author: Kent Watsen "; 300 description 301 "This module defines common YANG types for cryptographic 302 applications. 304 Copyright (c) 2020 IETF Trust and the persons identified 305 as authors of the code. All rights reserved. 307 Redistribution and use in source and binary forms, with 308 or without modification, is permitted pursuant to, and 309 subject to the license terms contained in, the Simplified 310 BSD License set forth in Section 4.c of the IETF Trust's 311 Legal Provisions Relating to IETF Documents 312 (https://trustee.ietf.org/license-info). 314 This version of this YANG module is part of RFC AAAA 315 (https://www.rfc-editor.org/info/rfcAAAA); see the RFC 316 itself for full legal notices. 318 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 319 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 320 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 321 are to be interpreted as described in BCP 14 (RFC 2119) 322 (RFC 8174) when, and only when, they appear in all 323 capitals, as shown here."; 325 revision 2020-05-20 { 326 description 327 "Initial version"; 328 reference 329 "RFC AAAA: Common YANG Data Types for Cryptography"; 331 } 333 /****************/ 334 /* Features */ 335 /****************/ 337 feature one-asymmetric-key-format { 338 description 339 "Indicates that the server supports the 340 'one-asymmetric-key-format' identity."; 341 } 343 feature one-symmetric-key-format { 344 description 345 "Indicates that the server supports the 346 'one-symmetric-key-format' identity."; 347 } 349 feature encrypted-one-symmetric-key-format { 350 description 351 "Indicates that the server supports the 352 'encrypted-one-symmetric-key-format' identity."; 353 } 355 feature encrypted-one-asymmetric-key-format { 356 description 357 "Indicates that the server supports the 358 'encrypted-one-asymmetric-key-format' identity."; 359 } 361 feature certificate-signing-request-generation { 362 description 363 "Indicates that the server implements the 364 'generate-certificate-signing-request' action."; 365 } 367 /*************************************************/ 368 /* Base Identities for Key Format Structures */ 369 /*************************************************/ 371 identity public-key-format { 372 description "Base key-format identity for public keys."; 373 } 375 identity private-key-format { 376 description "Base key-format identity for private keys."; 378 } 380 identity symmetric-key-format { 381 description "Base key-format identity for symmetric keys."; 382 } 384 /****************************************************/ 385 /* Identities for Private Key Format Structures */ 386 /****************************************************/ 388 identity rsa-private-key-format { 389 base "private-key-format"; 390 description 391 "Indicates that the private key value is encoded 392 as an RSAPrivateKey (from RFC 3447)."; 393 reference 394 "RFC 3447: PKCS #1: RSA Cryptography 395 Specifications Version 2.2"; 396 } 398 identity ec-private-key-format { 399 base "private-key-format"; 400 description 401 "Indicates that the private key value is encoded 402 as an ECPrivateKey (from RFC 5915)"; 403 reference 404 "RFC 5915: Elliptic Curve Private Key Structure"; 405 } 407 identity one-asymmetric-key-format { 408 if-feature "one-asymmetric-key-format"; 409 base "private-key-format"; 410 description 411 "Indicates that the private key value is a CMS 412 OneAsymmetricKey structure, as defined in RFC 5958, 413 encoded using ASN.1 distinguished encoding rules 414 (DER), as specified in ITU-T X.690."; 415 reference 416 "RFC 5958: Asymmetric Key Packages 417 ITU-T X.690: 418 Information technology - ASN.1 encoding rules: 419 Specification of Basic Encoding Rules (BER), 420 Canonical Encoding Rules (CER) and Distinguished 421 Encoding Rules (DER)."; 422 } 424 identity encrypted-one-asymmetric-key-format { 425 if-feature "encrypted-one-asymmetric-key-format"; 426 base "private-key-format"; 427 description 428 "Indicates that the private key value is a CMS EnvelopedData 429 structure, per Section 8 in RFC 5652, containing a 430 OneAsymmetricKey structure, as defined in RFC 5958, 431 encoded using ASN.1 distinguished encoding rules (DER), 432 as specified in ITU-T X.690."; 433 reference 434 "RFC 5652: Cryptographic Message Syntax (CMS) 435 RFC 5958: Asymmetric Key Packages 436 ITU-T X.690: 437 Information technology - ASN.1 encoding rules: 438 Specification of Basic Encoding Rules (BER), 439 Canonical Encoding Rules (CER) and Distinguished 440 Encoding Rules (DER)."; 441 } 443 /***************************************************/ 444 /* Identities for Public Key Format Structures */ 445 /***************************************************/ 447 identity ssh-public-key-format { 448 base "public-key-format"; 449 description 450 "Indicates that the public key value is an SSH public key, 451 as specified by RFC 4253, Section 6.6, i.e.: 453 string certificate or public key format 454 identifier 455 byte[n] key/certificate data."; 456 reference 457 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 458 } 460 identity subject-public-key-info-format { 461 base "public-key-format"; 462 description 463 "Indicates that the public key value is a SubjectPublicKeyInfo 464 structure, as described in RFC 5280 encoded using ASN.1 465 distinguished encoding rules (DER), as specified in 466 ITU-T X.690."; 467 reference 468 "RFC 5280: 469 Internet X.509 Public Key Infrastructure Certificate 470 and Certificate Revocation List (CRL) Profile 471 ITU-T X.690: 473 Information technology - ASN.1 encoding rules: 474 Specification of Basic Encoding Rules (BER), 475 Canonical Encoding Rules (CER) and Distinguished 476 Encoding Rules (DER)."; 477 } 479 /******************************************************/ 480 /* Identities for Symmetric Key Format Structures */ 481 /******************************************************/ 483 identity octet-string-key-format { 484 base "symmetric-key-format"; 485 description 486 "Indicates that the key is encoded as a raw octet string. 487 The length of the octet string MUST be appropriate for 488 the associated algorithm's block size."; 489 } 491 identity one-symmetric-key-format { 492 if-feature "one-symmetric-key-format"; 493 base "symmetric-key-format"; 494 description 495 "Indicates that the private key value is a CMS 496 OneSymmetricKey structure, as defined in RFC 6031, 497 encoded using ASN.1 distinguished encoding rules 498 (DER), as specified in ITU-T X.690."; 499 reference 500 "RFC 6031: Cryptographic Message Syntax (CMS) 501 Symmetric Key Package Content Type 502 ITU-T X.690: 503 Information technology - ASN.1 encoding rules: 504 Specification of Basic Encoding Rules (BER), 505 Canonical Encoding Rules (CER) and Distinguished 506 Encoding Rules (DER)."; 507 } 509 identity encrypted-one-symmetric-key-format { 510 if-feature "encrypted-one-symmetric-key-format"; 511 base "symmetric-key-format"; 512 description 513 "Indicates that the private key value is a CMS 514 EnvelopedData structure, per Section 8 in RFC 5652, 515 containing a OneSymmetricKey structure, as defined 516 in RFC 6031, encoded using ASN.1 distinguished 517 encoding rules (DER), as specified in ITU-T X.690."; 518 reference 519 "RFC 5652: Cryptographic Message Syntax (CMS) 520 RFC 6031: Cryptographic Message Syntax (CMS) 521 Symmetric Key Package Content Type 522 ITU-T X.690: 523 Information technology - ASN.1 encoding rules: 524 Specification of Basic Encoding Rules (BER), 525 Canonical Encoding Rules (CER) and Distinguished 526 Encoding Rules (DER)."; 527 } 529 /***************************************************/ 530 /* Typedefs for ASN.1 structures from RFC 2986 */ 531 /***************************************************/ 533 typedef csr { 534 type binary; 535 description 536 "A CertificationRequest structure, as specified in RFC 2986, 537 encoded using ASN.1 distinguished encoding rules (DER), as 538 specified in ITU-T X.690."; 539 reference 540 "RFC 2986: 541 PKCS #10: Certification Request Syntax Specification 542 Version 1.7 543 ITU-T X.690: 544 Information technology - ASN.1 encoding rules: 545 Specification of Basic Encoding Rules (BER), 546 Canonical Encoding Rules (CER) and Distinguished 547 Encoding Rules (DER)."; 548 } 550 /***************************************************/ 551 /* Typedefs for ASN.1 structures from RFC 5280 */ 552 /***************************************************/ 554 typedef x509 { 555 type binary; 556 description 557 "A Certificate structure, as specified in RFC 5280, 558 encoded using ASN.1 distinguished encoding rules (DER), 559 as specified in ITU-T X.690."; 560 reference 561 "RFC 5280: 562 Internet X.509 Public Key Infrastructure Certificate 563 and Certificate Revocation List (CRL) Profile 564 ITU-T X.690: 565 Information technology - ASN.1 encoding rules: 566 Specification of Basic Encoding Rules (BER), 567 Canonical Encoding Rules (CER) and Distinguished 568 Encoding Rules (DER)."; 569 } 571 typedef crl { 572 type binary; 573 description 574 "A CertificateList structure, as specified in RFC 5280, 575 encoded using ASN.1 distinguished encoding rules (DER), 576 as specified in ITU-T X.690."; 577 reference 578 "RFC 5280: 579 Internet X.509 Public Key Infrastructure Certificate 580 and Certificate Revocation List (CRL) Profile 581 ITU-T X.690: 582 Information technology - ASN.1 encoding rules: 583 Specification of Basic Encoding Rules (BER), 584 Canonical Encoding Rules (CER) and Distinguished 585 Encoding Rules (DER)."; 586 } 588 /***********************************************/ 589 /* Typedefs for ASN.1 structures from 5652 */ 590 /***********************************************/ 592 typedef cms { 593 type binary; 594 description 595 "A ContentInfo structure, as specified in RFC 5652, 596 encoded using ASN.1 distinguished encoding rules (DER), 597 as specified in ITU-T X.690."; 598 reference 599 "RFC 5652: 600 Cryptographic Message Syntax (CMS) 601 ITU-T X.690: 602 Information technology - ASN.1 encoding rules: 603 Specification of Basic Encoding Rules (BER), 604 Canonical Encoding Rules (CER) and Distinguished 605 Encoding Rules (DER)."; 606 } 608 typedef data-content-cms { 609 type cms; 610 description 611 "A CMS structure whose top-most content type MUST be the 612 data content type, as described by Section 4 in RFC 5652."; 613 reference 614 "RFC 5652: Cryptographic Message Syntax (CMS)"; 615 } 617 typedef signed-data-cms { 618 type cms; 619 description 620 "A CMS structure whose top-most content type MUST be the 621 signed-data content type, as described by Section 5 in 622 RFC 5652."; 623 reference 624 "RFC 5652: Cryptographic Message Syntax (CMS)"; 625 } 627 typedef enveloped-data-cms { 628 type cms; 629 description 630 "A CMS structure whose top-most content type MUST be the 631 enveloped-data content type, as described by Section 6 632 in RFC 5652."; 633 reference 634 "RFC 5652: Cryptographic Message Syntax (CMS)"; 635 } 637 typedef digested-data-cms { 638 type cms; 639 description 640 "A CMS structure whose top-most content type MUST be the 641 digested-data content type, as described by Section 7 642 in RFC 5652."; 643 reference 644 "RFC 5652: Cryptographic Message Syntax (CMS)"; 645 } 647 typedef encrypted-data-cms { 648 type cms; 649 description 650 "A CMS structure whose top-most content type MUST be the 651 encrypted-data content type, as described by Section 8 652 in RFC 5652."; 653 reference 654 "RFC 5652: Cryptographic Message Syntax (CMS)"; 655 } 657 typedef authenticated-data-cms { 658 type cms; 659 description 660 "A CMS structure whose top-most content type MUST be the 661 authenticated-data content type, as described by Section 9 662 in RFC 5652."; 663 reference 664 "RFC 5652: Cryptographic Message Syntax (CMS)"; 665 } 667 /*********************************************************/ 668 /* Typedefs for ASN.1 structures related to RFC 5280 */ 669 /*********************************************************/ 671 typedef trust-anchor-cert-x509 { 672 type x509; 673 description 674 "A Certificate structure that MUST encode a self-signed 675 root certificate."; 676 } 678 typedef end-entity-cert-x509 { 679 type x509; 680 description 681 "A Certificate structure that MUST encode a certificate 682 that is neither self-signed nor having Basic constraint 683 CA true."; 684 } 686 /*********************************************************/ 687 /* Typedefs for ASN.1 structures related to RFC 5652 */ 688 /*********************************************************/ 690 typedef trust-anchor-cert-cms { 691 type signed-data-cms; 692 description 693 "A CMS SignedData structure that MUST contain the chain of 694 X.509 certificates needed to authenticate the certificate 695 presented by a client or end-entity. 697 The CMS MUST contain only a single chain of certificates. 698 The client or end-entity certificate MUST only authenticate 699 to last intermediate CA certificate listed in the chain. 701 In all cases, the chain MUST include a self-signed root 702 certificate. In the case where the root certificate is 703 itself the issuer of the client or end-entity certificate, 704 only one certificate is present. 706 This CMS structure MAY (as applicable where this type is 707 used) also contain suitably fresh (as defined by local 708 policy) revocation objects with which the device can 709 verify the revocation status of the certificates. 711 This CMS encodes the degenerate form of the SignedData 712 structure that is commonly used to disseminate X.509 713 certificates and revocation objects (RFC 5280)."; 714 reference 715 "RFC 5280: 716 Internet X.509 Public Key Infrastructure Certificate 717 and Certificate Revocation List (CRL) Profile."; 718 } 720 typedef end-entity-cert-cms { 721 type signed-data-cms; 722 description 723 "A CMS SignedData structure that MUST contain the end 724 entity certificate itself, and MAY contain any number 725 of intermediate certificates leading up to a trust 726 anchor certificate. The trust anchor certificate 727 MAY be included as well. 729 The CMS MUST contain a single end entity certificate. 730 The CMS MUST NOT contain any spurious certificates. 732 This CMS structure MAY (as applicable where this type is 733 used) also contain suitably fresh (as defined by local 734 policy) revocation objects with which the device can 735 verify the revocation status of the certificates. 737 This CMS encodes the degenerate form of the SignedData 738 structure that is commonly used to disseminate X.509 739 certificates and revocation objects (RFC 5280)."; 740 reference 741 "RFC 5280: 742 Internet X.509 Public Key Infrastructure Certificate 743 and Certificate Revocation List (CRL) Profile."; 744 } 746 /**********************************************/ 747 /* Groupings for keys and/or certificates */ 748 /**********************************************/ 750 grouping symmetric-key-grouping { 751 description 752 "A symmetric key and algorithm."; 753 leaf key-format { 754 nacm:default-deny-write; 755 type identityref { 756 base symmetric-key-format; 757 } 758 description "Identifies the symmetric key's format."; 759 } 760 choice key-type { 761 mandatory true; 762 description 763 "Choice between key types."; 764 leaf key { 765 nacm:default-deny-all; 766 type binary; 767 must "../key-format"; 768 description 769 "The binary value of the key. The interpretation of 770 the value is defined by the 'key-format' field."; 771 } 772 leaf hidden-key { 773 nacm:default-deny-write; 774 type empty; 775 must "not(../key-format)"; 776 description 777 "A permanently hidden key. How such keys are created 778 is outside the scope of this module."; 779 } 780 } 781 } 783 grouping public-key-grouping { 784 description 785 "A public key and its associated algorithm."; 786 leaf public-key-format { 787 nacm:default-deny-write; 788 type identityref { 789 base public-key-format; 790 } 791 mandatory true; 792 description "Identifies the key's format."; 793 } 794 leaf public-key { 795 nacm:default-deny-write; 796 type binary; 797 mandatory true; 798 description 799 "The binary value of the public key. The interpretation 800 of the value is defined by 'public-key-format' field."; 801 } 802 } 803 grouping asymmetric-key-pair-grouping { 804 description 805 "A private key and its associated public key and algorithm."; 806 uses public-key-grouping; 807 leaf private-key-format { 808 nacm:default-deny-write; 809 type identityref { 810 base private-key-format; 811 } 812 description "Identifies the key's format."; 813 } 814 choice private-key-type { 815 mandatory true; 816 description 817 "Choice between key types."; 818 leaf private-key { 819 nacm:default-deny-all; 820 type binary; 821 must "../private-key-format"; 822 description 823 "The value of the binary key The key's value is 824 interpreted by the 'private-key-format' field."; 825 } 826 leaf hidden-private-key { 827 nacm:default-deny-write; 828 type empty; 829 must "not(../private-key-format)"; 830 description 831 "A permanently hidden key. How such keys are created 832 is outside the scope of this module."; 833 } 834 } 835 } 837 grouping trust-anchor-cert-grouping { 838 description 839 "A trust anchor certificate, and a notification for when 840 it is about to (or already has) expire."; 841 leaf cert { 842 nacm:default-deny-write; 843 type trust-anchor-cert-cms; 844 description 845 "The binary certificate data for this certificate."; 846 reference 847 "RFC YYYY: Common YANG Data Types for Cryptography"; 848 } 849 notification certificate-expiration { 850 description 851 "A notification indicating that the configured certificate 852 is either about to expire or has already expired. When to 853 send notifications is an implementation specific decision, 854 but it is RECOMMENDED that a notification be sent once a 855 month for 3 months, then once a week for four weeks, and 856 then once a day thereafter until the issue is resolved."; 857 leaf expiration-date { 858 type yang:date-and-time; 859 mandatory true; 860 description 861 "Identifies the expiration date on the certificate."; 862 } 863 } 864 } 866 grouping trust-anchor-certs-grouping { 867 description 868 "A list of trust anchor certificates, and a notification 869 for when one is about to (or already has) expire."; 870 leaf-list cert { 871 nacm:default-deny-write; 872 type trust-anchor-cert-cms; 873 description 874 "The binary certificate data for this certificate."; 875 reference 876 "RFC YYYY: Common YANG Data Types for Cryptography"; 877 } 878 notification certificate-expiration { 879 description 880 "A notification indicating that the configured certificate 881 is either about to expire or has already expired. When to 882 send notifications is an implementation specific decision, 883 but it is RECOMMENDED that a notification be sent once a 884 month for 3 months, then once a week for four weeks, and 885 then once a day thereafter until the issue is resolved."; 886 leaf expiration-date { 887 type yang:date-and-time; 888 mandatory true; 889 description 890 "Identifies the expiration date on the certificate."; 891 } 892 } 893 } 895 grouping end-entity-cert-grouping { 896 description 897 "An end entity certificate, and a notification for when 898 it is about to (or already has) expire. Implementations 899 SHOULD assert that, where used, the end entity certificate 900 contains the expected public key."; 901 leaf cert { 902 nacm:default-deny-write; 903 type end-entity-cert-cms; 904 description 905 "The binary certificate data for this certificate."; 906 reference 907 "RFC YYYY: Common YANG Data Types for Cryptography"; 908 } 909 notification certificate-expiration { 910 description 911 "A notification indicating that the configured certificate 912 is either about to expire or has already expired. When to 913 send notifications is an implementation specific decision, 914 but it is RECOMMENDED that a notification be sent once a 915 month for 3 months, then once a week for four weeks, and 916 then once a day thereafter until the issue is resolved."; 917 leaf expiration-date { 918 type yang:date-and-time; 919 mandatory true; 920 description 921 "Identifies the expiration date on the certificate."; 922 } 923 } 924 } 926 grouping end-entity-certs-grouping { 927 description 928 "A list of end entity certificates, and a notification for 929 when one is about to (or already has) expire."; 930 leaf-list cert { 931 nacm:default-deny-write; 932 type end-entity-cert-cms; 933 description 934 "The binary certificate data for this certificate."; 935 reference 936 "RFC YYYY: Common YANG Data Types for Cryptography"; 937 } 938 notification certificate-expiration { 939 description 940 "A notification indicating that the configured certificate 941 is either about to expire or has already expired. When to 942 send notifications is an implementation specific decision, 943 but it is RECOMMENDED that a notification be sent once a 944 month for 3 months, then once a week for four weeks, and 945 then once a day thereafter until the issue is resolved."; 946 leaf expiration-date { 947 type yang:date-and-time; 948 mandatory true; 949 description 950 "Identifies the expiration date on the certificate."; 951 } 952 } 953 } 955 grouping generate-csr-grouping { 956 description 957 "Defines the 'generate-certificate-signing-request' action."; 958 action generate-certificate-signing-request { 959 if-feature certificate-signing-request-generation; 960 nacm:default-deny-all; 961 description 962 "Generates a certificate signing request structure for 963 the associated asymmetric key using the passed subject 964 and attribute values. 966 This action statement is only available when the 967 associated 'public-key-format' node's value is 968 'subject-public-key-info-format'."; 969 reference 970 "RFC 6125: 971 Representation and Verification of Domain-Based 972 Application Service Identity within Internet Public Key 973 Infrastructure Using X.509 (PKIX) Certificates in the 974 Context of Transport Layer Security (TLS)"; 975 input { 976 leaf subject { 977 type binary; 978 mandatory true; 979 description 980 "The 'subject' field per the CertificationRequestInfo 981 structure as specified by RFC 2986, Section 4.1 982 encoded using the ASN.1 distinguished encoding 983 rules (DER), as specified in ITU-T X.690."; 984 reference 985 "RFC 2986: PKCS #10: Certification Request Syntax 986 Specification Version 1.7. 987 ITU-T X.690: 988 Information technology - ASN.1 encoding rules: 989 Specification of Basic Encoding Rules (BER), 990 Canonical Encoding Rules (CER) and Distinguished 991 Encoding Rules (DER)."; 992 } 993 leaf attributes { 994 type binary; 995 description 996 "The 'attributes' field from the structure 997 CertificationRequestInfo as specified by RFC 2986, 998 Section 4.1 encoded using the ASN.1 distinguished 999 encoding rules (DER), as specified in ITU-T X.690."; 1000 reference 1001 "RFC 2986: PKCS #10: Certification Request Syntax 1002 Specification Version 1.7. 1003 ITU-T X.690: 1004 Information technology - ASN.1 encoding rules: 1005 Specification of Basic Encoding Rules (BER), 1006 Canonical Encoding Rules (CER) and Distinguished 1007 Encoding Rules (DER)."; 1008 } 1009 } 1010 output { 1011 leaf certificate-signing-request { 1012 type ct:csr; 1013 mandatory true; 1014 description 1015 "The requested certificate signing request structure."; 1016 } 1017 } 1018 } 1019 } // generate-csr-grouping 1021 grouping asymmetric-key-pair-with-cert-grouping { 1022 description 1023 "A private/public key pair and an associated certificate. 1024 Implementations SHOULD assert that certificates contain 1025 the matching public key."; 1026 uses asymmetric-key-pair-grouping; 1027 uses end-entity-cert-grouping; 1028 uses generate-csr-grouping; 1029 } // asymmetric-key-pair-with-cert-grouping 1031 grouping asymmetric-key-pair-with-certs-grouping { 1032 description 1033 "A private/public key pair and associated certificates. 1034 Implementations SHOULD assert that certificates contain 1035 the matching public key."; 1036 uses asymmetric-key-pair-grouping; 1037 container certificates { 1038 nacm:default-deny-write; 1039 description 1040 "Certificates associated with this asymmetric key. 1041 More than one certificate supports, for instance, 1042 a TPM-protected asymmetric key that has both IDevID 1043 and LDevID certificates associated."; 1044 list certificate { 1045 key "name"; 1046 description 1047 "A certificate for this asymmetric key."; 1048 leaf name { 1049 type string; 1050 description 1051 "An arbitrary name for the certificate. If the name 1052 matches the name of a certificate that exists 1053 independently in (i.e., an IDevID), 1054 then the 'cert' node MUST NOT be configured."; 1055 } 1056 uses end-entity-cert-grouping { 1057 refine cert { 1058 mandatory true; 1059 } 1060 } 1061 } 1062 } 1063 uses generate-csr-grouping; 1064 } // asymmetric-key-pair-with-certs-grouping 1066 } 1068 1070 2.3. Examples 1072 2.3.1. The "asymmetric-key-pair-with-certs-grouping" Grouping 1074 The following example module illustrates the use of both the 1075 "symmetric-key-grouping" and the "asymmetric-key-pair-with-certs- 1076 grouping" groupings defined in the "ietf-crypto-types" module. 1078 module ex-crypto-types-usage { 1079 yang-version 1.1; 1081 namespace "http://example.com/ns/example-crypto-types-usage"; 1082 prefix "ectu"; 1084 import ietf-crypto-types { 1085 prefix ct; 1086 reference 1087 "RFC AAAA: Common YANG Data Types for Cryptography"; 1088 } 1090 organization 1091 "Example Corporation"; 1093 contact 1094 "Author: YANG Designer "; 1096 description 1097 "This module illustrates the grouping 1098 defined in the crypto-types draft called 1099 'asymmetric-key-pair-with-certs-grouping'."; 1101 revision "2020-05-20" { 1102 description 1103 "Initial version"; 1104 reference 1105 "RFC AAAA: Common YANG Data Types for Cryptography"; 1106 } 1108 container symmetric-keys { 1109 description 1110 "A container of symmetric keys."; 1111 list symmetric-key { 1112 key name; 1113 description 1114 "A symmetric key"; 1115 leaf name { 1116 type string; 1117 description 1118 "An arbitrary name for this key."; 1119 } 1120 uses ct:symmetric-key-grouping; 1121 } 1122 } 1123 container asymmetric-keys { 1124 description 1125 "A container of asymmetric keys."; 1126 list asymmetric-key { 1127 key name; 1128 leaf name { 1129 type string; 1130 description 1131 "An arbitrary name for this key."; 1132 } 1133 uses ct:asymmetric-key-pair-with-certs-grouping; 1134 description 1135 "An asymmetric key pair with associated certificates."; 1136 } 1137 } 1138 } 1139 Given the above example usage module, the following example 1140 illustrates some configured keys. 1142 1145 1146 ex-hidden-symmetric-key 1147 1148 1149 1150 ex-octet-string-based-symmetric-key 1151 ct:octet-string-key-format 1152 base64encodedvalue== 1153 1154 1155 ex-one-symmetric-based-symmetric-key 1156 ct:one-symmetric-key-format 1157 base64encodedvalue== 1158 1159 1160 ex-encrypted-one-symmetric-based-symmetric-key 1161 ct:encrypted-one-symmetric-key-format 1162 base64encodedvalue== 1163 1164 1166 1169 1170 ex-hidden-asymmetric-key 1171 1172 ct:subject-public-key-info-format 1173 1174 base64encodedvalue== 1175 1176 1177 1178 ex-hidden-key-cert 1179 base64encodedvalue== 1180 1181 1182 1183 1184 ex-subject-public-info-based-asymmetric-key 1185 1186 ct:subject-public-key-info-format 1188 1189 base64encodedvalue== 1190 1191 ct:rsa-private-key-format 1192 1193 base64encodedvalue== 1194 1195 1196 ex-cert 1197 base64encodedvalue== 1198 1199 1200 1201 1202 ex-one-asymmetric-based-symmetric-key 1203 1204 ct:subject-public-key-info-format 1205 1206 base64encodedvalue== 1207 1208 ct:one-asymmetric-key-format 1209 1210 base64encodedvalue== 1211 1212 1213 ex-encrypted-one-asymmetric-based-symmetric-key 1214 1215 ct:subject-public-key-info-format 1216 1217 base64encodedvalue== 1218 1219 ct:encrypted-one-asymmetric-key-format 1220 1221 base64encodedvalue== 1222 1223 1225 2.3.2. The "generate-certificate-signing-request" Action 1227 The following example illustrates the "generate-certificate-signing- 1228 request" action with the NETCONF protocol. 1230 REQUEST 1232 1234 1235 1237 1238 ex-key-sect571r1 1239 1240 base64encodedvalue== 1241 base64encodedvalue== 1242 1243 1244 1245 1246 1248 RESPONSE 1250 1252 1254 base64encodedvalue== 1255 1256 1258 2.3.3. The "certificate-expiration" Notification 1260 The following example illustrates the "certificate-expiration" 1261 notification with the NETCONF protocol. 1263 1265 2018-05-25T00:01:00Z 1266 1267 1268 locally-defined key 1269 1270 1271 my-cert 1272 1273 1274 2018-08-05T14:18:53-05:00 1275 1276 1277 1278 1279 1280 1281 1283 3. Security Considerations 1285 3.1. No Support for CRMF 1287 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 1288 signing-request" action. The use of Certificate Request Message 1289 Format (CRMF) [RFC4211] was considered, but is was unclear if there 1290 was market demand for it. If it is desired to support CRMF in the 1291 future, a backwards compatible solution can be defined at that time. 1293 3.2. Access to Data Nodes 1295 The YANG module in this document defines "grouping" statements that 1296 are designed to be accessed via YANG based management protocols, such 1297 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1298 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1299 with mutual authentication. 1301 The NETCONF access control model (NACM) [RFC8341] provides the means 1302 to restrict access for particular users to a pre-configured subset of 1303 all available protocol operations and content. 1305 Since the module in this document only define groupings, these 1306 considerations are primarily for the designers of other modules that 1307 use these groupings. 1309 There are a number of data nodes defined by the grouping statements 1310 that are writable/creatable/deletable (i.e., config true, which is 1311 the default). Some of these data nodes may be considered sensitive 1312 or vulnerable in some network environments. Write operations (e.g., 1313 edit-config) to these data nodes without proper protection can have a 1314 negative effect on network operations. These are the subtrees and 1315 data nodes and their sensitivity/vulnerability: 1317 *: All of the data nodes defined by all the groupings are 1318 considered sensitive to write operations. For instance, the 1319 modification of a public key or a certificate can dramatically 1320 alter the implemented security policy. For this reason, the 1321 NACM extension "default-deny-write" has been applied to all the 1322 data nodes defined by all the groupings. 1324 Some of the readable data nodes in the YANG module may be considered 1325 sensitive or vulnerable in some network environments. It is thus 1326 important to control read access (e.g., via get, get-config, or 1327 notification) to these data nodes. These are the subtrees and data 1328 nodes and their sensitivity/vulnerability: 1330 /private-key: The "private-key" node defined in the "asymmetric- 1331 key-pair-grouping" grouping is additionally sensitive to read 1332 operations such that, in normal use cases, it should never be 1333 returned to a client. For this reason, the NACM extension 1334 "default-deny-all" has been applied to it here. 1336 Some of the operations in this YANG module may be considered 1337 sensitive or vulnerable in some network environments. It is thus 1338 important to control access to these operations. These are the 1339 operations and their sensitivity/vulnerability: 1341 *: All of the "action" statements defined by groupings SHOULD only 1342 be executed by authorized users. For this reason, the NACM 1343 extension "default-deny-all" has been applied to all of them. 1344 Note that NACM uses "default-deny-all" to protect "RPC" and 1345 "action" statements; it does not define, e.g., an extension 1346 called "default-deny-execute". 1348 generate-certificate-signing-request: For this action, it is 1349 RECOMMENDED that implementations assert channel binding 1350 [RFC5056], so as to ensure that the application layer that sent 1351 the request is the same as the device authenticated when the 1352 secure transport layer was established. 1354 4. IANA Considerations 1355 4.1. Update the "IETF XML" Registry 1357 This document registers one URI in the "ns" subregistry of the "IETF 1358 XML" registry [RFC3688]. Following the format in [RFC3688], the 1359 following registration is requested: 1361 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 1362 Registrant Contact: The NETCONF WG of the IETF. 1363 XML: N/A, the requested URI is an XML namespace. 1365 4.2. Update the "YANG Module Names" Registry 1367 This document registers one YANG module in the "YANG Module Names" 1368 registry [RFC6020]. Following the format in [RFC6020], the the 1369 following registration is requested: 1371 name: ietf-crypto-types 1372 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 1373 prefix: ct 1374 reference: RFC AAAA 1376 5. References 1378 5.1. Normative References 1380 [ITU.X690.2015] 1381 International Telecommunication Union, "Information 1382 Technology - ASN.1 encoding rules: Specification of Basic 1383 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1384 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1385 X.690, ISO/IEC 8825-1, August 2015, 1386 . 1388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1389 Requirement Levels", BCP 14, RFC 2119, 1390 DOI 10.17487/RFC2119, March 1997, 1391 . 1393 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1394 Standards (PKCS) #1: RSA Cryptography Specifications 1395 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 1396 2003, . 1398 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1399 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1400 January 2006, . 1402 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1403 Housley, R., and W. Polk, "Internet X.509 Public Key 1404 Infrastructure Certificate and Certificate Revocation List 1405 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1406 . 1408 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1409 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1410 . 1412 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1413 DOI 10.17487/RFC5958, August 2010, 1414 . 1416 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 1417 (CMS) Symmetric Key Package Content Type", RFC 6031, 1418 DOI 10.17487/RFC6031, December 2010, 1419 . 1421 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1422 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1423 . 1425 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1426 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1427 . 1429 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1430 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1431 May 2017, . 1433 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1434 Access Control Model", STD 91, RFC 8341, 1435 DOI 10.17487/RFC8341, March 2018, 1436 . 1438 5.2. Informative References 1440 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1441 Request Syntax Specification Version 1.7", RFC 2986, 1442 DOI 10.17487/RFC2986, November 2000, 1443 . 1445 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1446 DOI 10.17487/RFC3688, January 2004, 1447 . 1449 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1450 Certificate Request Message Format (CRMF)", RFC 4211, 1451 DOI 10.17487/RFC4211, September 2005, 1452 . 1454 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1455 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1456 . 1458 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1459 IANA Considerations Section in RFCs", RFC 5226, 1460 DOI 10.17487/RFC5226, May 2008, 1461 . 1463 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 1464 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 1465 . 1467 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1468 the Network Configuration Protocol (NETCONF)", RFC 6020, 1469 DOI 10.17487/RFC6020, October 2010, 1470 . 1472 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1473 Verification of Domain-Based Application Service Identity 1474 within Internet Public Key Infrastructure Using X.509 1475 (PKIX) Certificates in the Context of Transport Layer 1476 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1477 2011, . 1479 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1480 and A. Bierman, Ed., "Network Configuration Protocol 1481 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1482 . 1484 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1485 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1486 . 1488 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1489 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1490 . 1492 5.3. URIs 1494 [1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types 1496 [2] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors 1498 [3] https://tools.ietf.org/html/draft-ietf-netconf-keystore 1500 [4] https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server 1502 [5] https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server 1504 [6] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server 1506 [7] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server 1508 [8] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client- 1509 server 1511 [9] https://tools.ietf.org/html/draft-ietf-netconf-restconf-client- 1512 server 1514 Appendix A. Change Log 1516 A.1. I-D to 00 1518 o Removed groupings and notifications. 1520 o Added typedefs for identityrefs. 1522 o Added typedefs for other RFC 5280 structures. 1524 o Added typedefs for other RFC 5652 structures. 1526 o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 1528 A.2. 00 to 01 1530 o Moved groupings from the draft-ietf-netconf-keystore here. 1532 A.3. 01 to 02 1534 o Removed unwanted "mandatory" and "must" statements. 1536 o Added many new crypto algorithms (thanks Haiguang!) 1538 o Clarified in asymmetric-key-pair-with-certs-grouping, in 1539 certificates/certificate/name/description, that if the name MUST 1540 NOT match the name of a certificate that exists independently in 1541 , enabling certs installed by the manufacturer (e.g., 1542 an IDevID). 1544 A.4. 02 to 03 1546 o renamed base identity 'asymmetric-key-encryption-algorithm' to 1547 'asymmetric-key-algorithm'. 1549 o added new 'asymmetric-key-algorithm' identities for secp192r1, 1550 secp224r1, secp256r1, secp384r1, and secp521r1. 1552 o removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 1553 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 1554 aes-256-gcm, and mac-chacha20-poly1305. 1556 o for all -cbc and -ctr identities, renamed base identity 1557 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 1559 o for all -ccm and -gcm identities, renamed base identity 1560 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 1561 algorithm' and renamed the identity to remove the "enc-" prefix. 1563 o for all the 'signature-algorithm' based identities, renamed from 1564 'rsa-*' to 'rsassa-*'. 1566 o removed all of the "x509v3-" prefixed 'signature-algorithm' based 1567 identities. 1569 o added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 1570 and 'rsaes-pkcs1-v1_5'. 1572 o renamed typedef 'symmetric-key-encryption-algorithm-ref' to 1573 'symmetric-key-algorithm-ref'. 1575 o renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 1576 'asymmetric-key-algorithm-ref'. 1578 o added typedef 'encryption-and-mac-algorithm-ref'. 1580 o Updated copyright date, boilerplate template, affiliation, and 1581 folding algorithm. 1583 A.5. 03 to 04 1585 o ran YANG module through formatter. 1587 A.6. 04 to 05 1589 o fixed broken symlink causing reformatted YANG module to not show. 1591 A.7. 05 to 06 1593 o Added NACM annotations. 1595 o Updated Security Considerations section. 1597 o Added 'asymmetric-key-pair-with-cert-grouping' grouping. 1599 o Removed text from 'permanently-hidden' enum regarding such keys 1600 not being backed up or restored. 1602 o Updated the boilerplate text in module-level "description" 1603 statement to match copyeditor convention. 1605 o Added an explanation to the 'public-key-grouping' and 'asymmetric- 1606 key-pair-grouping' statements as for why the nodes are not 1607 mandatory (e.g., because they may exist only in . 1609 o Added 'must' expressions to the 'public-key-grouping' and 1610 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 1611 are either all exist or do not all exist. 1613 o Added an explanation to the 'permanently-hidden' that the value 1614 cannot be configured directly by clients and servers MUST fail any 1615 attempt to do so. 1617 o Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 1618 grouping' (the plural form of existing groupings). 1620 o Now states that keys created in by the *-hidden-key 1621 actions are bound to the lifetime of the parent 'config true' 1622 node, and that subsequent invocations of either action results in 1623 a failure. 1625 A.8. 06 to 07 1627 o Added clarifications that implementations SHOULD assert that 1628 configured certificates contain the matching public key. 1630 o Replaced the 'generate-hidden-key' and 'install-hidden-key' 1631 actions with special 'crypt-hash' -like input/output values. 1633 A.9. 07 to 08 1635 o Removed the 'generate-key and 'hidden-key' features. 1637 o Added grouping symmetric-key-grouping 1639 o Modified 'asymmetric-key-pair-grouping' to have a 'choice' 1640 statement for the keystone module to augment into, as well as 1641 replacing the 'union' with leafs (having different NACM settings. 1643 A.10. 08 to 09 1645 o Converting algorithm from identities to enumerations. 1647 A.11. 09 to 10 1649 o All of the below changes are to the algorithm enumerations defined 1650 in ietf-crypto-types. 1652 o Add in support for key exchange over x.25519 and x.448 based on 1653 RFC 8418. 1655 o Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 1656 o Revise/add in enum of signature algorithm for x25519 and x448 1658 o Add in des3-cbc-sha1 for IPSec 1660 o Add in sha1-des3-kd for IPSec 1662 o Add in definit for rc4-hmac and rc4-hmac-exp. These two 1663 algorithms have been deprecated in RFC 8429. But some existing 1664 draft in i2nsf may still want to use them. 1666 o Add x25519 and x448 curve for asymmetric algorithms 1668 o Add signature algorithms ed25519, ed25519-cts, ed25519ph 1670 o add signature algorithms ed448, ed448ph 1672 o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 1674 A.12. 10 to 11 1676 o Added a "key-format" identity. 1678 o Added symmetric keys to the example in Section 2.3. 1680 A.13. 11 to 12 1682 o Removed all non-essential (to NC/RC) algorithm types. 1684 o Moved remaining algorithm types each into its own module. 1686 o Added a 'config false' "algorithms-supported" list to each of the 1687 algorithm-type modules. 1689 A.14. 12 to 13 1691 o Added the four features: "[encrypted-]one-[a]symmetric-key- 1692 format", each protecting a 'key-format' identity of the same name. 1694 o Added 'must' expressions asserting that the 'key-format' leaf 1695 exists whenever a non-hidden key is specified. 1697 o Improved the 'description' statements and added 'reference' 1698 statements for the 'key-format' identities. 1700 o Added a questionable forward reference to "encrypted-*" leafs in a 1701 couple 'when' expressions. 1703 o Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 1705 A.15. 13 to 14 1707 o Resolved the "FIXME: forward ref" issue by modulating 'must', 1708 'when', and 'mandatory' expressions. 1710 o Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' 1711 actions from ietf-keystore to ietf-crypto-types, now as RPCs. 1713 o Cleaned up various description statements and removed lingering 1714 FIXMEs. 1716 o Converted the "iana--algs" YANG modules to IANA 1717 registries with instructions for how to generate modules from the 1718 registries, whenever they may be updated. 1720 A.16. 14 to 15 1722 o Removed the IANA-maintained registries for symmetric, asymmetric, 1723 and hash algorithms. 1725 o Removed the "generate-symmetric-key" and "generate-asymmetric-key" 1726 RPCs. 1728 o Removed the "algorithm" node in the various symmetric and 1729 asymmetric key groupings. 1731 o Added 'typedef csr' and 'feature certificate-signing-request- 1732 generation'. 1734 o Refined a usage of "end-entity-cert-grouping" to make the "cert" 1735 node mandatory true. 1737 o Added a "Note to Reviewers" note to first page. 1739 Acknowledgements 1741 The authors would like to thank for following for lively discussions 1742 on list and in the halls (ordered by last name): Martin Bjorklund, 1743 Nick Hancock, Wang Haiguang, Balazs Kovacs, Rich Salz, Juergen 1744 Schoenwaelder, Eric Voit, Rob Wilton, and Liang Xia. 1746 Author's Address 1748 Kent Watsen 1749 Watsen Networks 1751 EMail: kent+ietf@watsen.net