idnits 2.17.1 draft-ietf-netconf-trust-anchors-10.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 198 has weird spacing: '...on-date yan...' == Line 205 has weird spacing: '...-format ide...' == Line 214 has weird spacing: '...on-date yan...' == Line 223 has weird spacing: '...-format ide...' == Line 236 has weird spacing: '...on-date yan...' == (1 more instance...) -- The document date (May 20, 2020) is 1436 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 1024 -- Looks like a reference, but probably isn't: '2' on line 1026 -- Looks like a reference, but probably isn't: '3' on line 1028 -- Looks like a reference, but probably isn't: '4' on line 1030 -- Looks like a reference, but probably isn't: '5' on line 1032 -- Looks like a reference, but probably isn't: '6' on line 1034 -- Looks like a reference, but probably isn't: '7' on line 1036 -- Looks like a reference, but probably isn't: '8' on line 1038 -- Looks like a reference, but probably isn't: '9' on line 1041 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-14 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 10 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 A YANG Data Model for a Truststore 8 draft-ietf-netconf-trust-anchors-10 10 Abstract 12 This document defines a YANG 1.1 data model for configuring globally- 13 accessible bags of certificates and public keys that can be 14 referenced by other data models for trust. 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 draft-ietf-netconf-crypto- 27 types 29 o "BBBB" --> the assigned RFC value for this draft 31 Artwork in this document contains placeholder values for the date of 32 publication of this draft. Please apply the following replacement: 34 o "2020-05-20" --> the publication date of this draft 36 The following Appendix section is to be removed prior to publication: 38 o Appendix A. Change Log 40 Note to Reviewers (To be removed by RFC Editor) 42 This document presents a YANG module or modules that is/are part of a 43 collection of drafts that work together to produce the ultimate goal 44 of the NETCONF WG: to define configuration modules for NETCONF client 45 and servers, and RESTCONF client and servers. 47 The relationship between the various drafts in the collection is 48 presented in the below diagram. 50 crypto-types 51 ^ ^ 52 / \ 53 / \ 54 trust-anchors keystore 55 ^ ^ ^ ^ 56 | +---------+ | | 57 | | | | 58 | +------------+ | 59 tcp-client-server | / | | 60 ^ ^ ssh-client-server | | 61 | | ^ tls-client-server 62 | | | ^ ^ http-client-server 63 | | | | | ^ 64 | | | +-----+ +---------+ | 65 | | | | | | 66 | +-----------|--------|--------------+ | | 67 | | | | | | 68 +-----------+ | | | | | 69 | | | | | | 70 | | | | | | 71 netconf-client-server restconf-client-server 73 Full draft names and link to drafts: 75 o draft-ietf-netconf-crypto-types (html [1]) 77 o draft-ietf-netconf-trust-anchors (html [2]) 79 o draft-ietf-netconf-keystore (html [3]) 81 o draft-ietf-netconf-tcp-client-server (html [4]) 83 o draft-ietf-netconf-ssh-client-server (html [5]) 85 o draft-ietf-netconf-tls-client-server (html [6]) 87 o draft-ietf-netconf-http-client-server (html [7]) 89 o draft-ietf-netconf-netconf-client-server (html [8]) 91 o draft-ietf-netconf-restconf-client-server (html [9]) 93 Status of This Memo 95 This Internet-Draft is submitted in full conformance with the 96 provisions of BCP 78 and BCP 79. 98 Internet-Drafts are working documents of the Internet Engineering 99 Task Force (IETF). Note that other groups may also distribute 100 working documents as Internet-Drafts. The list of current Internet- 101 Drafts is at https://datatracker.ietf.org/drafts/current/. 103 Internet-Drafts are draft documents valid for a maximum of six months 104 and may be updated, replaced, or obsoleted by other documents at any 105 time. It is inappropriate to use Internet-Drafts as reference 106 material or to cite them other than as "work in progress." 108 This Internet-Draft will expire on November 21, 2020. 110 Copyright Notice 112 Copyright (c) 2020 IETF Trust and the persons identified as the 113 document authors. All rights reserved. 115 This document is subject to BCP 78 and the IETF Trust's Legal 116 Provisions Relating to IETF Documents 117 (https://trustee.ietf.org/license-info) in effect on the date of 118 publication of this document. Please review these documents 119 carefully, as they describe your rights and restrictions with respect 120 to this document. Code Components extracted from this document must 121 include Simplified BSD License text as described in Section 4.e of 122 the Trust Legal Provisions and are provided without warranty as 123 described in the Simplified BSD License. 125 Table of Contents 127 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 128 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 129 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 4 130 2. The Trust Anchors Model . . . . . . . . . . . . . . . . . . . 4 131 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 132 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 133 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 134 3. Support for Built-in Trust Anchors . . . . . . . . . . . . . 17 135 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 136 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 137 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21 138 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 21 139 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 140 6.1. Normative References . . . . . . . . . . . . . . . . . . 22 141 6.2. Informative References . . . . . . . . . . . . . . . . . 22 142 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 143 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 144 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 24 145 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 24 146 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 24 147 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 24 148 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 24 149 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 25 150 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 25 151 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 25 152 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 25 153 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 25 154 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 155 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 157 1. Introduction 159 This document defines a YANG 1.1 [RFC7950] data model for configuring 160 globally-accessible bags of certificates and public keys that can be 161 referenced by other data models for trust. 163 This document in compliant with Network Management Datastore 164 Architecture (NMDA) [RFC8342]. For instance, trust anchors installed 165 during manufacturing (e.g., for trusted well-known services), are 166 expected to appear in (see Section 3). 168 1.1. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 1.2. Tree Diagram Notation 178 Tree diagrams used in this document follow the notation defined in 179 [RFC8340]. 181 2. The Trust Anchors Model 183 2.1. Tree Diagram 185 The following tree diagram provides an overview of the "ietf- 186 truststore" module. 188 module: ietf-truststore 189 +--rw truststore 190 +--rw certificate-bags! {certificates}? 191 | +--rw certificate-bag* [name] 192 | +--rw name string 193 | +--rw description? string 194 | +--rw certificate* [name] 195 | +--rw name string 196 | +--rw cert trust-anchor-cert-cms 197 | +---n certificate-expiration 198 | +-- expiration-date yang:date-and-time 199 +--rw public-key-bags! {public-keys}? 200 +--rw public-key-bag* [name] 201 +--rw name string 202 +--rw description? string 203 +--rw public-key* [name] 204 +--rw name string 205 +--rw public-key-format identityref 206 +--rw public-key binary 208 grouping local-or-truststore-certs-grouping 209 +-- (local-or-truststore) 210 +--:(local) {local-definitions-supported}? 211 | +-- local-definition 212 | +-- cert* trust-anchor-cert-cms 213 | +---n certificate-expiration 214 | +-- expiration-date yang:date-and-time 215 +--:(truststore) {truststore-supported,certificates}? 216 +-- truststore-reference? ts:certificate-bag-ref 217 grouping local-or-truststore-public-keys-grouping 218 +-- (local-or-truststore) 219 +--:(local) {local-definitions-supported}? 220 | +-- local-definition 221 | +-- public-key* [name] 222 | +-- name? string 223 | +-- public-key-format identityref 224 | +-- public-key binary 225 +--:(truststore) {truststore-supported,public-keys}? 226 +-- truststore-reference? ts:public-key-bag-ref 227 grouping truststore-grouping 228 +-- certificate-bags! {certificates}? 229 | +-- certificate-bag* [name] 230 | +-- name? string 231 | +-- description? string 232 | +-- certificate* [name] 233 | +-- name? string 234 | +-- cert trust-anchor-cert-cms 235 | +---n certificate-expiration 236 | +-- expiration-date yang:date-and-time 237 +-- public-key-bags! {public-keys}? 238 +-- public-key-bag* [name] 239 +-- name? string 240 +-- description? string 241 +-- public-key* [name] 242 +-- name? string 243 +-- public-key-format identityref 244 +-- public-key binary 246 2.2. Example Usage 248 The following example illustrates trust anchors in . 249 Please see Section 3 for an example illustrating built-in values in 250 . 252 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 254 258 259 261 262 263 trusted-server-ca-certs 264 265 Trust anchors (i.e. CA certs) used to authenticate server 266 certificates. A server certificate is authenticated if its 267 end-entity certificate has a chain of trust to one of these 268 certificates. 269 270 271 Server Cert Issuer #1 272 base64encodedvalue== 273 274 275 Server Cert Issuer #2 276 base64encodedvalue== 277 278 280 281 282 trusted-server-ee-certs 283 284 Specific end-entity certificates used to authenticate server 285 certificates. A server certificate is authenticated if its 286 end-entity certificate is an exact match to one of these 287 certificates. 288 289 290 My Application #1 291 base64encodedvalue== 292 293 294 My Application #2 295 base64encodedvalue== 296 297 299 300 301 trusted-client-ca-certs 302 303 Trust anchors (i.e. CA certs) used to authenticate client 304 certificates. A client certificate is authenticated if its 305 end-entity certificate has a chain of trust to one of these 306 certificates. 307 308 309 Client Identity Issuer #1 310 base64encodedvalue== 311 312 313 Client Identity Issuer #2 314 base64encodedvalue== 315 316 318 319 320 trusted-client-ee-certs 321 322 Specific end-entity certificates used to authenticate client 323 certificates. A client certificate is authenticated if its 324 end-entity certificate is an exact match to one of these 325 certificates. 326 327 328 George Jetson 329 base64encodedvalue== 330 331 332 Fred Flintstone 333 base64encodedvalue== 334 335 336 338 339 341 342 343 trusted-ssh-public-keys 344 345 Specific SSH public keys used to authenticate SSH server 346 public keys. An SSH server public key is authenticated if 347 its public key is an exact match to one of these public keys. 349 This list of SSH public keys is analogous to OpenSSH's 350 "/etc/ssh/ssh_known_hosts" file. 351 352 353 corp-fw1 354 ct:ssh-public-key-format 356 base64encodedvalue== 357 358 359 corp-fw2 360 ct:ssh-public-key-format 362 base64encodedvalue== 363 364 366 367 368 SSH Public Keys for User A 369 370 SSH public keys used to authenticate a user A's SSH public 371 keys. An SSH public key is authenticated if it is an exact 372 match to one of these public keys. 374 This list of public keys is analogous to OpenSSH's 375 "~A/.ssh/authorized_keys" file. 376 377 378 From Source #1 379 ct:ssh-public-key-format 381 base64encodedvalue== 382 383 384 From Source #2 385 ct:ssh-public-key-format 387 base64encodedvalue== 388 389 391 392 393 SSH Public Keys for User B 394 395 SSH public keys used to authenticate a user B's SSH public 396 keys. An SSH public key is authenticated if it is an exact 397 match to one of these public keys. 399 This list of public keys is analogous to OpenSSH's 400 "~B/.ssh/authorized_keys" file. 401 402 403 From Source #1 404 ct:ssh-public-key-format 406 base64encodedvalue== 407 408 409 From Source #2 410 ct:ssh-public-key-format 412 base64encodedvalue== 413 414 416 417 418 Raw Public Keys for TLS Servers 419 420 Raw Public Key #1 421 ct:subject-public-key-info-format 423 base64encodedvalue== 424 425 426 Raw Public Key #2 427 ct:subject-public-key-info-format 429 base64encodedvalue== 430 431 433 434 435 Raw Public Keys for TLS Clients 436 437 Raw Public Key #1 438 ct:subject-public-key-info-format 440 base64encodedvalue== 441 442 443 Raw Public Key #2 444 ct:subject-public-key-info-format 446 base64encodedvalue== 447 448 449 450 452 The following example illustrates the "certificate-expiration" 453 notification in use with the NETCONF protocol. 455 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 457 459 2018-05-25T00:01:00Z 460 461 462 463 explicitly-trusted-client-certs 464 465 George Jetson 466 467 2018-08-05T14:18:53-05:00 469 470 471 472 473 474 476 2.3. YANG Module 478 This YANG module imports modules from [RFC8341] and 479 [I-D.ietf-netconf-crypto-types]. 481 file "ietf-truststore@2020-05-20.yang" 483 module ietf-truststore { 484 yang-version 1.1; 485 namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; 486 prefix ts; 488 import ietf-netconf-acm { 489 prefix nacm; 490 reference 491 "RFC 8341: Network Configuration Access Control Model"; 492 } 494 import ietf-crypto-types { 495 prefix ct; 496 reference 497 "RFC AAAA: Common YANG Data Types for Cryptography"; 498 } 500 organization 501 "IETF NETCONF (Network Configuration) Working Group"; 503 contact 504 "WG Web : 505 WG List : 506 Author : Kent Watsen 507 Author : Henk Birkholz "; 509 description 510 "This module defines a Truststore to centralize management 511 of trust anchors including certificates and public keys. 513 Copyright (c) 2020 IETF Trust and the persons identified 514 as authors of the code. All rights reserved. 516 Redistribution and use in source and binary forms, with 517 or without modification, is permitted pursuant to, and 518 subject to the license terms contained in, the Simplified 519 BSD License set forth in Section 4.c of the IETF Trust's 520 Legal Provisions Relating to IETF Documents 521 (https://trustee.ietf.org/license-info). 523 This version of this YANG module is part of RFC BBBB 524 (https://www.rfc-editor.org/info/rfcBBBB); see the RFC 525 itself for full legal notices. 527 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 528 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 529 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 530 are to be interpreted as described in BCP 14 (RFC 2119) 531 (RFC 8174) when, and only when, they appear in all 532 capitals, as shown here."; 534 revision 2020-05-20 { 535 description 536 "Initial version"; 537 reference 538 "RFC BBBB: A YANG Data Model for a Truststore"; 539 } 541 /****************/ 542 /* Features */ 543 /****************/ 545 feature truststore-supported { 546 description 547 "The 'truststore-supported' feature indicates that the 548 server supports the Truststore (i.e., implements the 549 'ietf-truststore' module)."; 550 } 552 feature local-definitions-supported { 553 description 554 "The 'local-definitions-supported' feature indicates that 555 the server supports locally-defined trust anchors."; 556 } 558 feature certificates { 559 description 560 "The 'certificates' feature indicates that the server 561 implements the /truststore/certificate-bags subtree."; 562 } 564 feature public-keys { 565 description 566 "The 'public-keys' feature indicates that the server 567 implements the /truststore/public-key-bags subtree."; 568 } 570 /****************/ 571 /* Typedefs */ 572 /****************/ 574 typedef certificate-bag-ref { 575 type leafref { 576 path "/ts:truststore/ts:certificate-bags/" 577 + "ts:certificate-bag/ts:name"; 578 } 579 description 580 "This typedef defines a reference to a certificate bag 581 defined in the Truststore."; 582 } 584 typedef certificate-ref { 585 type leafref { 586 path "/ts:truststore/certificate-bags/certificate-bag" + 587 "[name = current()/../certificate-bag]/certificate/name"; 588 } 589 description 590 "This typedef define a reference to a specific certificate 591 in a certificate bag defined in the Truststore. This 592 typedef requires that there exist a sibling 'leaf' node 593 called 'certificate-bag' that SHOULD have the typedef 594 'certificate-bag-ref'."; 595 } 597 typedef public-key-bag-ref { 598 type leafref { 599 path "/ts:truststore/ts:public-key-bags/" 600 + "ts:public-key-bag/ts:name"; 601 } 602 description 603 "This typedef define a reference to a public key bag 604 defined in the Truststore."; 605 } 607 typedef public-key-ref { 608 type leafref { 609 path "/ts:truststore/public-key-bags/public-key-bag" + 610 "[name = current()/../public-key-bag]/" + 611 "public-key/name"; 612 } 613 description 614 "This typedef define a reference to a specific public key 615 in a public key bag defined in the Truststore. This 616 typedef requires that there exist a sibling 'leaf' node 617 called 'public-key-bag' that SHOULD have the typedef 618 'public-key-bag-ref'."; 619 } 620 /*****************/ 621 /* Groupings */ 622 /*****************/ 624 grouping local-or-truststore-certs-grouping { 625 description 626 "A grouping that allows the certificates to be either 627 configured locally, within the using data model, or be a 628 reference to a certificate bag stored in the Truststore."; 629 choice local-or-truststore { 630 mandatory true; 631 case local { 632 if-feature "local-definitions-supported"; 633 container local-definition { 634 description 635 "A container for locally configured trust anchor 636 certificates."; 637 uses ct:trust-anchor-certs-grouping; 638 } 639 } 640 case truststore { 641 if-feature "truststore-supported"; 642 if-feature "certificates"; 643 leaf truststore-reference { 644 type ts:certificate-bag-ref; 645 description 646 "A reference to a certificate bag that exists in the 647 Truststore."; 648 } 649 } 650 description 651 "A choice between an inlined definition and a definition 652 that exists in the Truststore."; 653 } 654 } 656 grouping local-or-truststore-public-keys-grouping { 657 description 658 "A grouping that allows the public keys to be either 659 configured locally, within the using data model, or be a 660 reference to a public key bag stored in the Truststore."; 661 choice local-or-truststore { 662 mandatory true; 663 case local { 664 if-feature "local-definitions-supported"; 665 container local-definition { 666 description 667 "Container to hold local public key definitions."; 668 list public-key { 669 key name; 670 description 671 "A public key definition."; 672 leaf name { 673 type string; 674 description 675 "An arbitrary name for this public key."; 676 } 677 uses ct:public-key-grouping; 678 } 679 } 680 } 681 case truststore { 682 if-feature "truststore-supported"; 683 if-feature "public-keys"; 684 leaf truststore-reference { 685 type ts:public-key-bag-ref; 686 description 687 "A reference to a bag of public keys that exist 688 in the Truststore."; 689 } 690 } 691 description 692 "A choice between an inlined definition and a definition 693 that exists in the Truststore."; 694 } 695 } 697 grouping truststore-grouping { 698 description 699 "Grouping definition enables use in other contexts. Where 700 used, implementations SHOULD augment new 'case' statements 701 into the local-or-truststore 'choice' statements to supply 702 leafrefs to the model-specific location."; 703 container certificate-bags { 704 if-feature "certificates"; 705 presence 706 "Indicates that certificate bags have been configured."; 707 description 708 "A collection of certificate bags."; 709 list certificate-bag { 710 key "name"; 711 min-elements 1; 712 description 713 "A bag of certificates. Each bag of certificates SHOULD 714 be for a specific purpose. For instance, one bag could 715 be used to authenticate a specific set of servers, while 716 another could be used to authenticate a specific set of 717 clients."; 718 leaf name { 719 type string; 720 description 721 "An arbitrary name for this bag of certificates."; 722 } 723 leaf description { 724 type string; 725 description 726 "A description for this bag of certificates. The 727 intended purpose for the bag SHOULD be described."; 728 } 729 list certificate { 730 key "name"; 731 min-elements 1; 732 description 733 "A trust anchor certificate."; 734 leaf name { 735 type string; 736 description 737 "An arbitrary name for this certificate."; 738 } 739 uses ct:trust-anchor-cert-grouping { 740 refine "cert" { 741 mandatory true; 742 } 743 } 744 } 745 } 746 } 747 container public-key-bags { 748 if-feature "public-keys"; 749 presence 750 "Indicates that public keys have been configured."; 751 description 752 "A collection of public key bags."; 753 list public-key-bag { 754 key "name"; 755 min-elements 1; 756 description 757 "A bag of public keys. Each bag of keys SHOULD be for 758 a specific purpose. For instance, one bag could be used 759 authenticate a specific set of servers, while another 760 could be used to authenticate a specific set of clients."; 761 leaf name { 762 type string; 763 description 764 "An arbitrary name for this bag of public keys."; 765 } 766 leaf description { 767 type string; 768 description 769 "A description for this bag public keys. The 770 intended purpose for the bag SHOULD be described."; 771 } 772 list public-key { 773 key "name"; 774 min-elements 1; 775 description 776 "A public key."; 777 leaf name { 778 type string; 779 description 780 "An arbitrary name for this public key."; 781 } 782 uses ct:public-key-grouping; 783 } 784 } 785 } 786 } 788 /*********************************/ 789 /* Protocol accessible nodes */ 790 /*********************************/ 792 container truststore { 793 nacm:default-deny-write; 794 description 795 "The Truststore contains bags of certificates and 796 public keys."; 797 uses truststore-grouping; 798 } 799 } 801 803 3. Support for Built-in Trust Anchors 805 In some implementations, a server may define some built-in trust 806 anchors. For instance, there may be built-in trust anchors enabling 807 the server to securely connect to well-known services (e.g., an SZTP 808 [RFC8572] bootstrap server) or public CA certificates to connect to 809 arbitrary services using public PKI. 811 Built-in trust anchors are expected to be set by a vendor-specific 812 process. Any ability for operators to modify built-in trust anchors 813 is outside the scope of this document. 815 As built-in trust anchors are provided by the system, they are 816 present in . The example below illustrates what the 817 Truststore in might look like for a server in its 818 factory default state. 820 825 827 828 Built-In Manufacturer CA Certificates 829 830 Certificates built into the device for authenticating 831 manufacturer-signed objects, such as TLS server certificates, 832 vouchers, etc. 833 834 835 Manufacturer Root CA Cert 836 base64encodedvalue== 837 838 840 841 Built-In Public CA Certificates 842 843 Certificates built into the device for authenticating 844 certificates issued by public certificate authorities, 845 such as the end-entity certificate for web servers. 846 847 848 Public Root CA Cert 1 849 base64encodedvalue== 850 851 852 Public Root CA Cert 2 853 base64encodedvalue== 854 855 856 Public Root CA Cert 3 857 base64encodedvalue== 858 859 861 862 864 In order for the built-in trust anchors to be referenced by 865 configuration, the referenced nodes MUST first be copied into 866 . They SHOULD be copied into using the same "key" 867 values, so that the system can bind the references to the built-in 868 entries. Only the referenced nodes need to be copied. When using 869 the same key values as in no new values can be added 870 and no existing values can be changed; that which is in can 871 only be a subset of that which is in . 873 For instance, the following example illustrates how a single built-in 874 public CA certificate from the previous example has been propagated 875 to : 877 880 882 883 Built-In Public CA Certificates 884 885 Certificates built into the device for authenticating 886 certificates issued by public certificate authorities, 887 such as the end-entity certificate for web servers. 889 Only the subset of the certificates that are referenced 890 by other configuration nodes need to be copied. For 891 instance, only "Public Root CA Cert 3" is present here. 893 No new certificates can be added, nor existing certificate 894 values changed. Missing certificates have no effect on 895 "operational" when the configuration is applied. 896 897 898 Public Root CA Cert 3 899 base64encodedvalue== 900 901 903 904 906 4. Security Considerations 908 The YANG module defined in this document is designed to be accessed 909 via YANG based management protocols, such as NETCONF [RFC6241] and 910 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 911 implement secure transport layers (e.g., SSH, TLS) with mutual 912 authentication. 914 The NETCONF access control model (NACM) [RFC8341] provides the means 915 to restrict access for particular users to a pre-configured subset of 916 all available protocol operations and content. 918 There are a number of data nodes defined in this YANG module that are 919 writable/creatable/deletable (i.e., config true, which is the 920 default). These data nodes may be considered sensitive or vulnerable 921 in some network environments. Write operations (e.g., edit-config) 922 to these data nodes without proper protection can have a negative 923 effect on network operations. These are the subtrees and data nodes 924 and their sensitivity/vulnerability: 926 /: The entire data tree defined by this module is sensitive to 927 write operations. For instance, the addition or removal of any 928 trust anchor may dramatically alter the implemented security 929 policy. For this reason, the NACM extension "default-deny- 930 write" has been set for the entire data tree. 932 None of the readable data nodes in this YANG module are considered 933 sensitive or vulnerable in network environments. 935 This module does not define any RPCs, actions, or notifications, and 936 thus the security consideration for such is not provided here. 938 5. IANA Considerations 940 5.1. The IETF XML Registry 942 This document registers one URI in the "ns" subregistry of the IETF 943 XML Registry [RFC3688]. Following the format in [RFC3688], the 944 following registration is requested: 946 URI: urn:ietf:params:xml:ns:yang:ietf-truststore 947 Registrant Contact: The NETCONF WG of the IETF. 948 XML: N/A, the requested URI is an XML namespace. 950 5.2. The YANG Module Names Registry 952 This document registers one YANG module in the YANG Module Names 953 registry [RFC6020]. Following the format in [RFC6020], the the 954 following registration is requested: 956 name: ietf-truststore 957 namespace: urn:ietf:params:xml:ns:yang:ietf-truststore 958 prefix: ta 959 reference: RFC BBBB 961 6. References 963 6.1. Normative References 965 [I-D.ietf-netconf-crypto-types] 966 Watsen, K. and H. Wang, "Common YANG Data Types for 967 Cryptography", draft-ietf-netconf-crypto-types-14 (work in 968 progress), March 2020. 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, 972 DOI 10.17487/RFC2119, March 1997, 973 . 975 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 976 RFC 7950, DOI 10.17487/RFC7950, August 2016, 977 . 979 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 980 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 981 May 2017, . 983 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 984 Access Control Model", STD 91, RFC 8341, 985 DOI 10.17487/RFC8341, March 2018, 986 . 988 6.2. Informative References 990 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 991 DOI 10.17487/RFC3688, January 2004, 992 . 994 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 995 the Network Configuration Protocol (NETCONF)", RFC 6020, 996 DOI 10.17487/RFC6020, October 2010, 997 . 999 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1000 and A. Bierman, Ed., "Network Configuration Protocol 1001 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1002 . 1004 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1005 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1006 . 1008 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1009 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1010 . 1012 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1013 and R. Wilton, "Network Management Datastore Architecture 1014 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1015 . 1017 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1018 Touch Provisioning (SZTP)", RFC 8572, 1019 DOI 10.17487/RFC8572, April 2019, 1020 . 1022 6.3. URIs 1024 [1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types 1026 [2] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors 1028 [3] https://tools.ietf.org/html/draft-ietf-netconf-keystore 1030 [4] https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server 1032 [5] https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server 1034 [6] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server 1036 [7] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server 1038 [8] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client- 1039 server 1041 [9] https://tools.ietf.org/html/draft-ietf-netconf-restconf-client- 1042 server 1044 Appendix A. Change Log 1046 A.1. 00 to 01 1048 o Added features "x509-certificates" and "ssh-host-keys". 1050 o Added nacm:default-deny-write to "trust-anchors" container. 1052 A.2. 01 to 02 1054 o Switched "list pinned-certificate" to use the "trust-anchor-cert- 1055 grouping" from crypto-types. Effectively the same definition as 1056 before. 1058 A.3. 02 to 03 1060 o Updated copyright date, boilerplate template, affiliation, folding 1061 algorithm, and reformatted the YANG module. 1063 A.4. 03 to 04 1065 o Added groupings 'local-or-truststore-certs-grouping' and 'local- 1066 or-truststore-host-keys-grouping', matching similar definitions in 1067 the keystore draft. Note new (and incomplete) "truststore" usage! 1069 o Related to above, also added features 'truststore-supported' and 1070 'local-trust-anchors-supported'. 1072 A.5. 04 to 05 1074 o Renamed "trust-anchors" to "truststore" 1076 o Removed "pinned." prefix everywhere, to match truststore rename 1078 o Moved everything under a top-level 'grouping' to enable use in 1079 other contexts. 1081 o Renamed feature from 'local-trust-anchors-supported' to 'local- 1082 definitions-supported' (same name used in keystore) 1084 o Removed the "require-instance false" statement from the "*-ref" 1085 typedefs. 1087 o Added missing "ssh-host-keys" and "x509-certificates" if-feature 1088 statements 1090 A.6. 05 to 06 1092 o Editorial changes only. 1094 A.7. 06 to 07 1096 o Added Henk Birkholz as a co-author (thanks Henk!) 1098 o Added PSKs and raw public keys to Truststore. 1100 A.8. 07 to 08 1102 o Added new "Support for Built-in Trust Anchors" section. 1104 o Removed spurious "uses ct:trust-anchor-certs-grouping" line. 1106 o Removed PSK from model. 1108 A.9. 08 to 09 1110 o Removed remaining PSK references from text. 1112 o Wrapped each top-level list with a container. 1114 o Introduced "bag" term. 1116 o Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public 1117 Keys" bag. Consuming downstream modules (i.e., "ietf-[ssh/tls]- 1118 [client/server]) refine the "public-key-format" to be either SSH 1119 or TLS specific as needed. 1121 A.10. 09 to 10 1123 o Removed "algorithm" node from examples. 1125 o Removed the no longer used statements supporting the old "ssh- 1126 public-key" and "raw-public-key" nodes. 1128 o Added a "Note to Reviewers" note to first page. 1130 Acknowledgements 1132 The authors especially thank Henk Birkholz for contributing YANG to 1133 the ietf-truststore module supporting raw public keys and PSKs (pre- 1134 shared or pairwise-symmetric keys). While these contributions were 1135 eventually replaced by reusing the existing support for asymmetric 1136 and symmetric trust anchors, respectively, it was only thru Henk's 1137 initiative that the WG was able to come to that result. 1139 The authors additionally thank the following for helping give shape 1140 to this work (ordered by last name): Martin Bjorklund, Nick Hancock, 1141 Balazs Kovacs, Eric Voit, and Liang Xia. 1143 Author's Address 1145 Kent Watsen 1146 Watsen Networks 1148 EMail: kent+ietf@watsen.net