idnits 2.17.1 draft-ietf-netconf-trust-anchors-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 141 has weird spacing: '...on-date yan...' == Line 147 has weird spacing: '...ost-key ct:...' == Line 155 has weird spacing: '...on-date yan...' == Line 165 has weird spacing: '...on-date yan...' -- The document date (April 29, 2019) is 1823 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) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 April 29, 2019 5 Expires: October 31, 2019 7 YANG Data Model for Global Trust Anchors 8 draft-ietf-netconf-trust-anchors-04 10 Abstract 12 This document defines a YANG 1.1 data model for configuring global 13 sets of X.509 certificates and SSH host-keys that can be referenced 14 by other data models for trust. While the SSH host-keys are uniquely 15 for the SSH protocol, the X.509 certificates may have multiple uses, 16 including authenticating protocol peers and verifying signatures. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 Artwork in this document contains shorthand references to drafts in 26 progress. Please apply the following replacements: 28 o "XXXX" --> the assigned RFC value for this draft 30 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-crypto- 31 types 33 Artwork in this document contains placeholder values for the date of 34 publication of this draft. Please apply the following replacement: 36 o "2019-04-29" --> the publication date of this draft 38 The following Appendix section is to be removed prior to publication: 40 o Appendix A. Change Log 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on October 31, 2019. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 78 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3 79 2. The Trust Anchors Model . . . . . . . . . . . . . . . . . . . 3 80 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 81 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4 82 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 83 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14 86 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 87 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 5.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 91 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 17 92 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 17 93 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 17 94 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 This document defines a YANG 1.1 [RFC7950] data model for configuring 101 global sets of X.509 certificates and SSH host-keys that can be 102 referenced by other data models for trust. While the SSH host-keys 103 are uniquely for the SSH protocol, the X.509 certificates may be used 104 for multiple uses, including authenticating protocol peers and 105 verifying signatures. 107 This document in compliant with Network Management Datastore 108 Architecture (NMDA) [RFC8342]. For instance, to support trust 109 anchors installed during manufacturing, it is expected that such data 110 may appear only in . 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 1.2. Tree Diagram Notation 122 Tree diagrams used in this document follow the notation defined in 123 [RFC8340]. 125 2. The Trust Anchors Model 127 2.1. Tree Diagram 129 The following tree diagram provides an overview of the "ietf-trust- 130 anchors" module. 132 module: ietf-trust-anchors 133 +--rw trust-anchors 134 +--rw pinned-certificates* [name] {x509-certificates}? 135 | +--rw name string 136 | +--rw description? string 137 | +--rw pinned-certificate* [name] 138 | +--rw name string 139 | +--rw cert trust-anchor-cert-cms 140 | +---n certificate-expiration 141 | +-- expiration-date yang:date-and-time 142 +--rw pinned-host-keys* [name] {ssh-host-keys}? 143 +--rw name string 144 +--rw description? string 145 +--rw pinned-host-key* [name] 146 +--rw name string 147 +--rw host-key ct:ssh-host-key 149 grouping local-or-truststore-certs-grouping 150 +-- (local-or-truststore) 151 +--:(local) {local-trust-anchors-supported}? 152 | +-- local-definition 153 | +-- cert* trust-anchor-cert-cms 154 | +---n certificate-expiration 155 | +-- expiration-date yang:date-and-time 156 +--:(truststore) {truststore-supported}? 157 +-- truststore-reference? ta:pinned-certificates-ref 158 grouping local-or-truststore-host-keys-grouping 159 +-- (local-or-truststore) 160 +--:(local) {local-trust-anchors-supported}? 161 | +-- local-definition 162 | +-- host-key* ct:ssh-host-key 163 | +-- cert* trust-anchor-cert-cms 164 | +---n certificate-expiration 165 | +-- expiration-date yang:date-and-time 166 +--:(truststore) {truststore-supported}? 167 +-- truststore-reference? ta:pinned-host-keys-ref 169 2.2. Example Usage 171 The following example illustrates trust anchors in as 172 described by Section 5.3 in [RFC8342]. This datastore view 173 illustrates data set by the manufacturing process alongside 174 conventional configuration. This trust anchors instance has six sets 175 of pinned certificates and one set of pinned host keys. 177 181 182 183 manufacturers-root-ca-certs 184 185 Certificates built into the device for authenticating 186 manufacturer-signed objects, such as TLS server certificates, 187 vouchers, etc. Note, though listed here, these are not 188 configurable; any attempt to do so will be denied. 189 190 191 Manufacturer Root CA cert 1 192 base64encodedvalue== 193 194 195 Manufacturer Root CA cert 2 196 base64encodedvalue== 197 198 200 201 202 explicitly-trusted-server-certs 203 204 Specific server authentication certificates for explicitly 205 trusted servers. These are needed for server certificates 206 that are not signed by a pinned CA. 207 208 209 Fred Flintstone 210 base64encodedvalue== 211 212 214 215 216 explicitly-trusted-server-ca-certs 217 218 Trust anchors (i.e. CA certs) that are used to authenticate 219 server connections. Servers are authenticated if their 220 certificate has a chain of trust to one of these CA 221 certificates. 222 223 224 ca.example.com 225 base64encodedvalue== 226 227 228 229 230 explicitly-trusted-client-certs 231 232 Specific client authentication certificates for explicitly 233 trusted clients. These are needed for client certificates 234 that are not signed by a pinned CA. 235 236 237 George Jetson 238 base64encodedvalue== 239 240 242 243 244 explicitly-trusted-client-ca-certs 245 246 Trust anchors (i.e. CA certs) that are used to authenticate 247 client connections. Clients are authenticated if their 248 certificate has a chain of trust to one of these CA 249 certificates. 250 251 252 ca.example.com 253 base64encodedvalue== 254 255 257 258 259 common-ca-certs 260 261 Trusted certificates to authenticate common HTTPS servers. 262 These certificates are similar to those that might be 263 shipped with a web browser. 264 265 266 ex-certificate-authority 267 base64encodedvalue== 268 269 271 272 273 explicitly-trusted-ssh-host-keys 274 275 Trusted SSH host keys used to authenticate SSH servers. 277 These host keys would be analogous to those stored in 278 a known_hosts file in OpenSSH. 279 280 281 corp-fw1 282 base64encodedvalue== 283 284 286 288 The following example illustrates the "certificate-expiration" 289 notification in use with the NETCONF protocol. 291 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 293 295 2018-05-25T00:01:00Z 296 298 299 explicitly-trusted-client-certs 300 301 George Jetson 302 303 2018-08-05T14:18:53-05:00 305 306 307 308 309 311 2.3. YANG Module 313 This YANG module imports modules from [RFC8341] and 314 [I-D.ietf-netconf-crypto-types]. 316 file "ietf-trust-anchors@2019-04-29.yang" 317 module ietf-trust-anchors { 318 yang-version 1.1; 319 namespace "urn:ietf:params:xml:ns:yang:ietf-trust-anchors"; 320 prefix ta; 322 import ietf-netconf-acm { 323 prefix nacm; 324 reference 325 "RFC 8341: Network Configuration Access Control Model"; 326 } 328 import ietf-crypto-types { 329 prefix ct; 330 reference 331 "RFC YYYY: Common YANG Data Types for Cryptography"; 332 } 334 organization 335 "IETF NETCONF (Network Configuration) Working Group"; 337 contact 338 "WG Web: 339 WG List: 340 Author: Kent Watsen "; 342 description 343 "This module defines a data model for configuring global 344 trust anchors used by other data models. The data model 345 enables the configuration of sets of trust anchors. 346 This data model supports configuring trust anchors for 347 both X.509 certificates and SSH host keys. 349 Copyright (c) 2019 IETF Trust and the persons identified 350 as authors of the code. All rights reserved. 352 Redistribution and use in source and binary forms, with 353 or without modification, is permitted pursuant to, and 354 subject to the license terms contained in, the Simplified 355 BSD License set forth in Section 4.c of the IETF Trust's 356 Legal Provisions Relating to IETF Documents 357 (https://trustee.ietf.org/license-info). 359 This version of this YANG module is part of RFC XXXX 360 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 361 itself for full legal notices.; 363 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 364 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 365 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 366 are to be interpreted as described in BCP 14 (RFC 2119) 367 (RFC 8174) when, and only when, they appear in all 368 capitals, as shown here."; 370 revision 2019-04-29 { 371 description 372 "Initial version"; 373 reference 374 "RFC XXXX: YANG Data Model for Global Trust Anchors"; 375 } 377 /****************/ 378 /* Features */ 379 /****************/ 381 feature truststore-supported { 382 description 383 "The 'truststore-supported' feature indicates that the 384 server supports the truststore."; 385 } 387 feature local-trust-anchors-supported { 388 description 389 "The 'local-keys-supported' feature indicates that the 390 server supports locally-defined trust anchors."; 391 } 393 feature x509-certificates { 394 description 395 "The 'x509-certificates' feature indicates that the server 396 implements the /trust-anchors/pinned-certificates subtree."; 397 } 399 feature ssh-host-keys { 400 description 401 "The 'ssh-host-keys' feature indicates that the server 402 implements the /trust-anchors/pinned-host-keys subtree."; 403 } 405 /****************/ 406 /* Typedefs */ 407 /****************/ 409 typedef pinned-certificates-ref { 410 type leafref { 411 path "/ta:trust-anchors/ta:pinned-certificates/ta:name"; 412 require-instance false; // IS THIS STILL TRUE? 413 // - doesn't the client now create a 'config' instance? 414 // - they do in order to config a new cert (e.g., LDevID) 415 } 416 description 417 "This typedef enables importing modules to easily define a 418 leafref to a 'pinned-certificates' object. The 'require- 419 instance' attribute is 'false' to enable the referencing 420 of pinned certificates that exist only in ."; 421 reference 422 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 423 } 425 typedef pinned-host-keys-ref { 426 type leafref { 427 path "/ta:trust-anchors/ta:pinned-host-keys/ta:name"; 428 require-instance false; // IS THIS STILL TRUE? 429 // - doesn't the client now create a 'config' instance? 430 // - they do in order to config a new cert (e.g., LDevID) 431 } 432 description 433 "This typedef enables importing modules to easily define 434 a leafref to a 'pinned-host-keys' object. The 'require- 435 instance' attribute is 'false' to enable the referencing 436 of pinned host keys that exist only in ."; 437 reference 438 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 439 } 441 /*****************/ 442 /* Groupings */ 443 /*****************/ 445 grouping local-or-truststore-certs-grouping { 446 description 447 "A grouping that expands to allow trust anchors to be 448 either stored locally, within the using data model, or be 449 a reference to trust anchors stored in the truststore."; 450 choice local-or-truststore { 451 mandatory true; 452 case local { 453 if-feature "local-trust-anchors-supported"; 454 container local-definition { 455 description 456 "Container to hold the local trust anchor definitions. 457 A list is defined so as to be symmetric with the 458 truststore definition."; 459 uses ct:trust-anchor-certs-grouping; 460 } 461 } 462 case truststore { 463 if-feature "truststore-supported"; 464 leaf truststore-reference { 465 type ta:pinned-certificates-ref; 466 description 467 "A reference to a trust anchor that exists in the 468 truststore."; 469 } 470 } 471 description 472 "A choice between an inlined definition and a definition 473 that exists in the truststore."; 474 } 475 } 477 grouping local-or-truststore-host-keys-grouping { 478 description 479 "A grouping that expands to allow trust anchors to be 480 either stored locally, within the using data model, or be 481 a reference to trust anchors stored in the truststore."; 482 choice local-or-truststore { 483 mandatory true; 484 case local { 485 if-feature "local-trust-anchors-supported"; 486 container local-definition { 487 description 488 "Container to hold the local trust anchor definitions. 489 A list is defined so as to be symmetric with the 490 truststore definition."; 491 leaf-list host-key { 492 nacm:default-deny-write; 493 type ct:ssh-host-key; 494 description 495 "The binary data for this host key."; 496 reference 497 "RFC YYYY: Common YANG Data Types for Cryptography"; 498 } 499 uses ct:trust-anchor-certs-grouping; 500 } 501 } 502 case truststore { 503 if-feature "truststore-supported"; 504 leaf truststore-reference { 505 type ta:pinned-host-keys-ref; 506 description 507 "A reference to a trust anchor that exists in the 508 truststore."; 509 } 510 } 511 description 512 "A choice between an inlined definition and a definition 513 that exists in the truststore."; 514 } 515 } 516 /*********************************/ 517 /* Protocol accessible nodes */ 518 /*********************************/ 520 container trust-anchors { 521 nacm:default-deny-write; 522 description 523 "Contains sets of X.509 certificates and SSH host keys."; 524 list pinned-certificates { 525 if-feature "x509-certificates"; 526 key "name"; 527 description 528 "A list of pinned certificates. These certificates can be 529 used by a server to authenticate clients, or by a client 530 to authenticate servers. Each list of pinned certificates 531 SHOULD be specific to a purpose, as the list as a whole 532 may be referenced by other modules. For instance, a 533 RESTCONF server's configuration might use a specific list 534 of pinned certificates for when authenticating RESTCONF 535 client connections."; 536 leaf name { 537 type string; 538 description 539 "An arbitrary name for this list of pinned certificates."; 540 } 541 leaf description { 542 type string; 543 description 544 "An arbitrary description for this list of pinned 545 certificates."; 546 } 547 list pinned-certificate { 548 key "name"; 549 description 550 "A pinned certificate."; 551 leaf name { 552 type string; 553 description 554 "An arbitrary name for this pinned certificate. The 555 name must be unique across all lists of pinned 556 certificates (not just this list) so that leafrefs 557 from another module can resolve to unique values."; 558 } 559 uses ct:trust-anchor-cert-grouping { 560 refine "cert" { 561 mandatory true; 562 } 563 } 565 } 566 } 567 list pinned-host-keys { 568 if-feature "ssh-host-keys"; 569 key "name"; 570 description 571 "A list of pinned host keys. These pinned host-keys can 572 be used by clients to authenticate SSH servers. Each 573 list of pinned host keys SHOULD be specific to a purpose, 574 so the list as a whole may be referenced by other modules. 575 For instance, a NETCONF client's configuration might 576 point to a specific list of pinned host keys for when 577 authenticating specific SSH servers."; 578 leaf name { 579 type string; 580 description 581 "An arbitrary name for this list of pinned SSH 582 host keys."; 583 } 584 leaf description { 585 type string; 586 description 587 "An arbitrary description for this list of pinned SSH 588 host keys."; 589 } 590 list pinned-host-key { 591 key "name"; 592 description 593 "A pinned host key."; 594 leaf name { 595 type string; 596 description 597 "An arbitrary name for this pinned host-key. Must be 598 unique across all lists of pinned host-keys (not just 599 this list) so that a leafref to it from another module 600 can resolve to unique values."; 601 } 602 leaf host-key { 603 type ct:ssh-host-key; 604 mandatory true; 605 description 606 "The binary public key data for this pinned host key."; 607 reference 608 "RFC YYYY: Common YANG Data Types for Cryptography"; 609 } 610 } 611 } 612 } 614 } 615 617 3. Security Considerations 619 The YANG module defined in this document is designed to be accessed 620 via YANG based management protocols, such as NETCONF [RFC6241] and 621 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 622 implement secure transport layers (e.g., SSH, TLS) with mutual 623 authentication. 625 The NETCONF access control model (NACM) [RFC8341] provides the means 626 to restrict access for particular users to a pre-configured subset of 627 all available protocol operations and content. 629 There are a number of data nodes defined in this YANG module that are 630 writable/creatable/deletable (i.e., config true, which is the 631 default). These data nodes may be considered sensitive or vulnerable 632 in some network environments. Write operations (e.g., edit-config) 633 to these data nodes without proper protection can have a negative 634 effect on network operations. These are the subtrees and data nodes 635 and their sensitivity/vulnerability: 637 /: The entire data tree defined by this module is sensitive to 638 write operations. For instance, the addition or removal of any 639 trust anchor may dramatically alter the implemented security 640 policy. For this reason, the NACM extension "default-deny- 641 write" has been set for the entire data tree. 643 None of the readable data nodes in this YANG module are considered 644 sensitive or vulnerable in network environments. 646 This module does not define any RPCs, actions, or notifications, and 647 thus the security consideration for such is not provided here. 649 4. IANA Considerations 651 4.1. The IETF XML Registry 653 This document registers one URI in the "ns" subregistry of the IETF 654 XML Registry [RFC3688]. Following the format in [RFC3688], the 655 following registration is requested: 657 URI: urn:ietf:params:xml:ns:yang:ietf-trust-anchors 658 Registrant Contact: The NETCONF WG of the IETF. 659 XML: N/A, the requested URI is an XML namespace. 661 4.2. The YANG Module Names Registry 663 This document registers one YANG module in the YANG Module Names 664 registry [RFC6020]. Following the format in [RFC6020], the the 665 following registration is requested: 667 name: ietf-trust-anchors 668 namespace: urn:ietf:params:xml:ns:yang:ietf-trust-anchors 669 prefix: ta 670 reference: RFC XXXX 672 5. References 674 5.1. Normative References 676 [I-D.ietf-netconf-crypto-types] 677 Watsen, K. and H. Wang, "Common YANG Data Types for 678 Cryptography", draft-ietf-netconf-crypto-types-05 (work in 679 progress), March 2019. 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 687 RFC 7950, DOI 10.17487/RFC7950, August 2016, 688 . 690 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 691 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 692 May 2017, . 694 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 695 Access Control Model", STD 91, RFC 8341, 696 DOI 10.17487/RFC8341, March 2018, 697 . 699 5.2. Informative References 701 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 702 DOI 10.17487/RFC3688, January 2004, 703 . 705 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 706 the Network Configuration Protocol (NETCONF)", RFC 6020, 707 DOI 10.17487/RFC6020, October 2010, 708 . 710 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 711 and A. Bierman, Ed., "Network Configuration Protocol 712 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 713 . 715 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 716 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 717 . 719 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 720 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 721 . 723 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 724 and R. Wilton, "Network Management Datastore Architecture 725 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 726 . 728 Appendix A. Change Log 730 A.1. 00 to 01 732 o Added features "x509-certificates" and "ssh-host-keys". 734 o Added nacm:default-deny-write to "trust-anchors" container. 736 A.2. 01 to 02 738 o Switched "list pinned-certificate" to use the "trust-anchor-cert- 739 grouping" from crypto-types. Effectively the same definition as 740 before. 742 A.3. 02 to 03 744 o Updated copyright date, boilerplate template, affiliation, folding 745 algorithm, and reformatted the YANG module. 747 A.4. 03 to 04 749 o Added groupings 'local-or-truststore-certs-grouping' and 'local- 750 or-truststore-host-keys-grouping', matching similar definitions in 751 the keystore draft. Note new (and incomplete) "truststore" usage! 753 o Related to above, also added features 'truststore-supported' and 754 'local-trust-anchors-supported'. 756 Acknowledgements 758 The authors would like to thank for following for lively discussions 759 on list and in the halls (ordered by last name): Martin Bjorklund, 760 Balazs Kovacs, Eric Voit, and Liang Xia. 762 Author's Address 764 Kent Watsen 765 Watsen Networks 767 EMail: kent+ietf@watsen.net