idnits 2.17.1 draft-kwatsen-netconf-crypto-types-00.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 124 has weird spacing: '...on-date yan...' == Line 136 has weird spacing: '...request bin...' == Line 143 has weird spacing: '...gorithm ide...' -- The document date (March 5, 2018) is 2206 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) == Unused Reference: 'RFC7950' is defined on line 792, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 5915 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track March 5, 2018 5 Expires: September 6, 2018 7 Common YANG Data Types for Cryptography 8 draft-kwatsen-netconf-crypto-types-00 10 Abstract 12 This document defines a YANG identities, typedefs, and groupings 13 useful for when working with ASN.1 structures, algorithms, and 14 private keys. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains many placeholder values that need to be replaced 19 with finalized values at the time of publication. This note 20 summarizes all of the substitutions that are needed. No other RFC 21 Editor 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 "XXXX" --> 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 "2018-03-05" --> the publication date of this draft 33 The following Appendix section is to be removed prior to publication: 35 o Appendix A. Change Log 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 6, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3 74 2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Private Key and Associated Certificate Configuration . . 4 77 3.2. Certificate Signing Request Action . . . . . . . . . . . 5 78 3.3. Generate Private Key Action . . . . . . . . . . . . . . . 6 79 3.4. Certificate Expiration Notification . . . . . . . . . . . 6 80 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 84 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 8.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Appendix A. Example YANG Module . . . . . . . . . . . . . . . . 20 90 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 93 1. Introduction 95 This document defines a YANG identities, typedefs, and groupings 96 useful for when working with ASN.1 structures, algorithms, and 97 private keys. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 1.2. Tree Diagram Notation 109 Tree diagrams used in this document follow the notation defined in 110 [I-D.ietf-netmod-yang-tree-diagrams]. 112 2. Tree Diagram 114 The following tree diagram provides an overview of the groupings, 115 actions, and notifications defined in the ietf-crypto-types YANG 116 module. The YANG module defines many identities and typedefs that 117 are not represented by this tree diagram. 119 module: ietf-crypto-types 121 notifications: 122 +---n certificate-expiration 123 +--ro certificate instance-identifier 124 +--ro expiration-date yang:date-and-time 126 grouping certificates-grouping 127 +---- certificates 128 | +---- certificate* [name] 129 | +---- name? string 130 | +---- value? binary 131 +---x generate-certificate-signing-request 132 +---w input 133 | +---w subject binary 134 | +---w attributes? binary 135 +--ro output 136 +--ro certificate-signing-request binary 137 grouping private-key-grouping 138 +---- algorithm? identityref 139 +---- private-key? union 140 +---- public-key? binary 141 +---x generate-private-key 142 +---w input 143 +---w algorithm identityref 145 3. Examples 147 These examples illustrate the use of the groupings, actions, and 148 notifications defined in the ietf-crypto-types YANG module. The YANG 149 module defines many identities and typedefs that are not represented 150 that are not represented by these examples. 152 3.1. Private Key and Associated Certificate Configuration 154 The following example illustrates a configured private key along with 155 an associated certificate. This example uses the "ex-crypto-types- 156 usage" module defined in Appendix A. 158 [ note: '\' line wrapping for formatting only] 160 161 ct:secp521r1 163 base64encodedvalue== 164 base64encodedvalue== 165 166 167 domain certificate 168 base64encodedvalue== 169 170 171 173 3.2. Certificate Signing Request Action 175 The following example illustrates the "generate-certificate-signing- 176 request" action in use with the NETCONF protocol. This example uses 177 the "ex-crypto-types-usage" module defined in Appendix A. 179 REQUEST 180 ------- 181 182 183 184 185 base64encodedvalue== 186 base64encodedvalue== 187 188 189 190 192 RESPONSE 193 -------- 194 196 198 base64encodedvalue== 199 200 202 3.3. Generate Private Key Action 204 The following example illustrates the "generate-private-key" action 205 in use with the NETCONF protocol. This example uses the "ex-crypto- 206 types-usage" module defined in Appendix A. 208 REQUEST 209 ------- 210 [ note: '\' line wrapping for formatting only] 212 214 215 216 217 ct:secp521r1 219 220 221 222 224 RESPONSE 225 -------- 226 228 229 231 3.4. Certificate Expiration Notification 233 The following example illustrates the "certificate-expiration" 234 notification in use with the NETCONF protocol. This example uses the 235 "ex-crypto-types-usage" module defined in Appendix A. 237 [ note: '\' line wrapping for formatting only] 239 241 2016-07-08T00:01:00Z 242 244 246 /ex:key/ex:certificates/ex:certificate[ex:name='domain certifi\ 247 cate'] 248 249 2016-08-08T14:18:53-05:00 250 251 253 4. YANG Module 255 This YANG module imports modules defined in [RFC6536] and [RFC6991]. 256 This module uses data types defined in [RFC2315], [RFC2986], 257 [RFC3447], [RFC4253], [RFC5280], [RFC5915], and [ITU.X690.1994]. 258 This module uses algorithms defined in [RFC3447] and [RFC5480]. 260 file "ietf-crypto-types@2018-03-05.yang" 261 module ietf-crypto-types { 262 yang-version 1.1; 264 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 265 prefix "ct"; 267 import ietf-yang-types { 268 prefix yang; 269 reference 270 "RFC 6991: Common YANG Data Types"; 271 } 273 import ietf-netconf-acm { 274 prefix nacm; 275 reference 276 "RFC 6536: Network Configuration Protocol (NETCONF) Access 277 Control Model"; 278 } 280 organization 281 "IETF NETCONF (Network Configuration) Working Group"; 283 contact 284 "WG Web: 285 WG List: 287 Author: Kent Watsen 288 "; 290 description 291 "This module defines common YANG types for cryptography applications. 293 Copyright (c) 2018 IETF Trust and the persons identified 294 as authors of the code. All rights reserved. 296 Redistribution and use in source and binary forms, with 297 or without modification, is permitted pursuant to, and 298 subject to the license terms contained in, the Simplified 299 BSD License set forth in Section 4.c of the IETF Trust's 300 Legal Provisions Relating to IETF Documents 301 (http://trustee.ietf.org/license-info). 303 This version of this YANG module is part of RFC XXXX; see 304 the RFC itself for full legal notices."; 306 revision "2018-03-05" { 307 description 308 "Initial version"; 309 reference 310 "RFC XXXX: Common YANG Data Types for Cryptography"; 311 } 313 /****************************************/ 314 /* Identities for Hashing Algorithms */ 315 /****************************************/ 317 identity hash-algorithm { 318 description 319 "A base identity for hash algorithm verification. 321 This identity is used in the ietf-zerotouch-information 322 module (draft-ietf-netconf-zerotouch)"; 323 } 325 identity sha-256 { 326 base "hash-algorithm"; 327 description "The SHA-256 algorithm."; 328 reference "RFC 6234: US Secure Hash Algorithms."; 329 } 330 /************************************************************/ 331 /* Identities for Key Algorithms (used by Certificates) */ 332 /************************************************************/ 334 identity key-algorithm { 335 description 336 "Base identity from which all key-algorithms are derived. 338 This identity is used in the 'private-key-grouping' grouping 339 and the 'generate-private-key' action below."; 340 } 342 identity rsa1024 { 343 base key-algorithm; 344 description 345 "The RSA algorithm using a 1024-bit key."; 346 reference 347 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 348 RSA Cryptography Specifications Version 2.1."; 349 } 351 identity rsa2048 { 352 base key-algorithm; 353 description 354 "The RSA algorithm using a 2048-bit key."; 355 reference 356 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 357 RSA Cryptography Specifications Version 2.1."; 358 } 360 identity rsa3072 { 361 base key-algorithm; 362 description 363 "The RSA algorithm using a 3072-bit key."; 364 reference 365 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 366 RSA Cryptography Specifications Version 2.1."; 367 } 369 identity rsa4096 { 370 base key-algorithm; 371 description 372 "The RSA algorithm using a 4096-bit key."; 373 reference 374 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 375 RSA Cryptography Specifications Version 2.1."; 376 } 377 identity rsa7680 { 378 base key-algorithm; 379 description 380 "The RSA algorithm using a 7680-bit key."; 381 reference 382 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 383 RSA Cryptography Specifications Version 2.1."; 384 } 386 identity rsa15360 { 387 base key-algorithm; 388 description 389 "The RSA algorithm using a 15360-bit key."; 390 reference 391 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: 392 RSA Cryptography Specifications Version 2.1."; 393 } 395 identity secp192r1 { 396 base key-algorithm; 397 description 398 "The secp192r1 algorithm."; 399 reference 400 "RFC5480: 401 Elliptic Curve Cryptography Subject Public Key Information."; 402 } 404 identity secp256r1 { 405 base key-algorithm; 406 description 407 "The secp256r1 algorithm."; 408 reference 409 "RFC5480: 410 Elliptic Curve Cryptography Subject Public Key Information."; 411 } 413 identity secp384r1 { 414 base key-algorithm; 415 description 416 "The secp384r1 algorithm."; 417 reference 418 "RFC5480: 419 Elliptic Curve Cryptography Subject Public Key Information."; 420 } 422 identity secp521r1 { 423 base key-algorithm; 424 description 425 "The secp521r1 algorithm."; 426 reference 427 "RFC5480: 428 Elliptic Curve Cryptography Subject Public Key Information."; 429 } 431 /************************************/ 432 /* Typedefs for ASN.1 structures */ 433 /************************************/ 435 typedef x509 { 436 type binary; 437 description 438 "A Certificate structure, as specified in RFC 5280, encoded using 439 ASN.1 distinguished encoding rules (DER), as specified in 440 ITU-T X.690."; 441 reference 442 "RFC 5652: 443 Cryptographic Message Syntax (CMS) 444 ITU-T X.690: 445 Information technology - ASN.1 encoding rules: 446 Specification of Basic Encoding Rules (BER), 447 Canonical Encoding Rules (CER) and Distinguished 448 Encoding Rules (DER)."; 449 } 451 typedef cms { 452 type binary; 453 description 454 "A ContentInfo structure, as specified in RFC 5652, encoded 455 using ASN.1 distinguished encoding rules (DER), as specified 456 in ITU-T X.690."; 457 reference 458 "RFC 5652: 459 Cryptographic Message Syntax (CMS) 460 ITU-T X.690: 461 Information technology - ASN.1 encoding rules: 462 Specification of Basic Encoding Rules (BER), 463 Canonical Encoding Rules (CER) and Distinguished 464 Encoding Rules (DER)."; 465 } 467 /******************************************************************/ 468 /* Groupings for a Private Key and its Associated Certificates */ 469 /******************************************************************/ 471 grouping private-key-grouping { 472 description 473 "A private/public key pair, and an action to request the 474 system to generate a private key. 476 This grouping is currently used by the YANG modules 477 ietf-ssh-client, ietf-ssh-server, ietf-tls-client, 478 and ietf-tls-server, where it populates the SSH/TLS 479 peer object's private key parameters."; 480 leaf algorithm { 481 type identityref { 482 base "key-algorithm"; 483 } 484 description 485 "Identifies the key's algorithm. More specifically, this 486 leaf specifies how the 'private-key' and 'public-key' 487 binary leafs are encoded."; 488 } 489 leaf private-key { 490 nacm:default-deny-all; 491 type union { 492 type binary; 493 type enumeration { 494 enum "hardware-protected" { 495 description 496 "The private key is inaccessible due to being 497 protected by a cryptographic hardware module 498 (e.g., a TPM)."; 499 } 500 } 501 } 502 must "../algorithm"; 503 description 504 "A binary that contains the value of the private key. The 505 interpretation of the content is defined by the key 506 algorithm. For example, a DSA key is an integer, an RSA 507 key is represented as RSAPrivateKey as defined in 508 [RFC3447], and an Elliptic Curve Cryptography (ECC) key 509 is represented as ECPrivateKey as defined in [RFC5915]"; 510 reference 511 "RFC 3447: Public-Key Cryptography Standards (PKCS) #1: 512 RSA Cryptography Specifications Version 2.1. 513 RFC 5915: Elliptic Curve Private Key Structure."; 514 } 515 leaf public-key { 516 type binary; 517 must "../algorithm"; 518 must "../private-key"; 519 description 520 "A binary that contains the value of the public key. The 521 interpretation of the content is defined by the key 522 algorithm. For example, a DSA key is an integer, an RSA 523 key is represented as RSAPublicKey as defined in 524 [RFC3447], and an Elliptic Curve Cryptography (ECC) key 525 is represented using the 'publicKey' described in 526 [RFC5915]"; 527 reference 528 "RFC 3447: Public-Key Cryptography Standards (PKCS) #1: 529 RSA Cryptography Specifications Version 2.1. 530 RFC 5915: Elliptic Curve Private Key Structure."; 531 } 532 action generate-private-key { 533 description 534 "Requests the device to generate a private key using the 535 specified key algorithm. This action is primarily to 536 support cryptographic processors that must generate 537 the private key themselves. The resulting key is 538 considered operational state and hence only present 539 in ."; 540 input { 541 leaf algorithm { 542 type identityref { 543 base "key-algorithm"; 544 } 545 mandatory true; 546 description 547 "The algorithm to be used when generating the key."; 548 } 549 } 550 } // end generate-private-key 551 } 553 grouping certificates-grouping { 554 description 555 "A container of certificates, and an action to generate 556 a certificate signing request. 558 This grouping is currently used by the YANG modules 559 ietf-ssh-client, ietf-ssh-server, ietf-tls-client, 560 and ietf-tls-server, where it populates the SSH/TLS 561 peer object's value for a certificates associated 562 with the private key."; 564 container certificates { 565 description 566 "Certificates associated with this key. More than one 567 certificate supports, for instance, a TPM-protected 568 key that has both IDevID and LDevID certificates 569 associated."; 570 list certificate { 571 key name; 572 description 573 "A certificate for this private key."; 574 leaf name { 575 type string; 576 description 577 "An arbitrary name for the certificate."; 578 } 579 leaf value { 580 type binary; 581 description 582 "A PKCS #7 SignedData structure, as specified by 583 Section 9.1 in RFC 2315, containing just certificates 584 (no content, signatures, or CRLs), encoded using ASN.1 585 distinguished encoding rules (DER), as specified in 586 ITU-T X.690. 588 This structure contains the certificate itself as well 589 as any intermediate certificates leading up to a trust 590 anchor certificate. The trust anchor certificate MAY 591 be included as well."; 592 reference 593 "RFC 2315: 594 PKCS #7: Cryptographic Message Syntax Version 1.5. 595 ITU-T X.690: 596 Information technology - ASN.1 encoding rules: 597 Specification of Basic Encoding Rules (BER), 598 Canonical Encoding Rules (CER) and Distinguished 599 Encoding Rules (DER)."; 600 } 601 } 602 } 603 action generate-certificate-signing-request { 604 description 605 "Generates a certificate signing request structure for 606 the associated private key using the passed subject and 607 attribute values. The specified assertions need to be 608 appropriate for the certificate's use. For example, 609 an entity certificate for a TLS server SHOULD have 610 values that enable clients to satisfy RFC 6125 611 processing."; 613 input { 614 leaf subject { 615 type binary; 616 mandatory true; 617 description 618 "The 'subject' field from the CertificationRequestInfo 619 structure as specified by RFC 2986, Section 4.1 encoded 620 using the ASN.1 distinguished encoding rules (DER), as 621 specified in ITU-T X.690."; 622 reference 623 "RFC 2986: 624 PKCS #10: Certification Request Syntax Specification 625 Version 1.7. 626 ITU-T X.690: 627 Information technology - ASN.1 encoding rules: 628 Specification of Basic Encoding Rules (BER), 629 Canonical Encoding Rules (CER) and Distinguished 630 Encoding Rules (DER)."; 631 } 632 leaf attributes { 633 type binary; 634 description 635 "The 'attributes' field from the CertificationRequestInfo 636 structure as specified by RFC 2986, Section 4.1 encoded 637 using the ASN.1 distinguished encoding rules (DER), as 638 specified in ITU-T X.690."; 639 reference 640 "RFC 2986: 641 PKCS #10: Certification Request Syntax Specification 642 Version 1.7. 643 ITU-T X.690: 644 Information technology - ASN.1 encoding rules: 645 Specification of Basic Encoding Rules (BER), 646 Canonical Encoding Rules (CER) and Distinguished 647 Encoding Rules (DER)."; 648 } 649 } 650 output { 651 leaf certificate-signing-request { 652 type binary; 653 mandatory true; 654 description 655 "A CertificationRequest structure as specified by RFC 656 2986, Section 4.1 encoded using the ASN.1 distinguished 657 encoding rules (DER), as specified in ITU-T X.690."; 658 reference 659 "RFC 2986: 660 PKCS #10: Certification Request Syntax Specification 661 Version 1.7. 662 ITU-T X.690: 663 Information technology - ASN.1 encoding rules: 664 Specification of Basic Encoding Rules (BER), 665 Canonical Encoding Rules (CER) and Distinguished 666 Encoding Rules (DER)."; 668 } 669 } 670 } 671 } 673 notification certificate-expiration { 674 description 675 "A notification indicating that a configured certificate is 676 either about to expire or has already expired. When to send 677 notifications is an implementation specific decision, but 678 it is RECOMMENDED that a notification be sent once a month 679 for 3 months, then once a week for four weeks, and then once 680 a day thereafter."; 681 leaf certificate { 682 type instance-identifier; 683 mandatory true; 684 description 685 "Identifies which certificate is expiring or is expired."; 686 } 687 leaf expiration-date { 688 type yang:date-and-time; 689 mandatory true; 690 description 691 "Identifies the expiration date on the certificate."; 692 } 693 } 695 } 696 698 5. Security Considerations 700 TBD 702 6. IANA Considerations 703 6.1. The IETF XML Registry 705 This document registers one URI in the IETF XML registry [RFC3688]. 706 Following the format in [RFC3688], the following registration is 707 requested: 709 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 710 Registrant Contact: The NETCONF WG of the IETF. 711 XML: N/A, the requested URI is an XML namespace. 713 6.2. The YANG Module Names Registry 715 This document registers one YANG module in the YANG Module Names 716 registry [RFC6020]. Following the format in [RFC6020], the the 717 following registration is requested: 719 name: ietf-crypto-types 720 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 721 prefix: ct 722 reference: RFC XXXX 724 7. Acknowledgements 726 The authors would like to thank for following for lively discussions 727 on list and in the halls (ordered by last name): 729 8. References 731 8.1. Normative References 733 [ITU.X690.1994] 734 International Telecommunications Union, "Information 735 Technology - ASN.1 encoding rules: Specification of Basic 736 Encoding Rules (BER), Canonical Encoding Rules (CER) and 737 Distinguished Encoding Rules (DER)", ITU-T Recommendation 738 X.690, 1994. 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, 742 DOI 10.17487/RFC2119, March 1997, 743 . 745 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 746 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 747 . 749 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 750 Request Syntax Specification Version 1.7", RFC 2986, 751 DOI 10.17487/RFC2986, November 2000, 752 . 754 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 755 Standards (PKCS) #1: RSA Cryptography Specifications 756 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 757 2003, . 759 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 760 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 761 January 2006, . 763 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 764 Housley, R., and W. Polk, "Internet X.509 Public Key 765 Infrastructure Certificate and Certificate Revocation List 766 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 767 . 769 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 770 "Elliptic Curve Cryptography Subject Public Key 771 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 772 . 774 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 775 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 776 . 778 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 779 the Network Configuration Protocol (NETCONF)", RFC 6020, 780 DOI 10.17487/RFC6020, October 2010, 781 . 783 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 784 Protocol (NETCONF) Access Control Model", RFC 6536, 785 DOI 10.17487/RFC6536, March 2012, 786 . 788 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 789 RFC 6991, DOI 10.17487/RFC6991, July 2013, 790 . 792 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 793 RFC 7950, DOI 10.17487/RFC7950, August 2016, 794 . 796 8.2. Informative References 798 [I-D.ietf-netmod-yang-tree-diagrams] 799 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 800 ietf-netmod-yang-tree-diagrams-06 (work in progress), 801 February 2018. 803 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 804 DOI 10.17487/RFC3688, January 2004, 805 . 807 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 808 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 809 May 2017, . 811 Appendix A. Example YANG Module 813 The following example YANG module has been constructed to illustrate 814 the groupings defined in the "ietf-crypto-types" module. This YANG 815 module is uses as a basis for the protocol examples in Section 3. 817 module ex-crypto-types-usage { 818 yang-version 1.1; 820 namespace "http://example.com/ns/example-crypto-types-usage"; 821 prefix "ctu"; 823 import ietf-crypto-types { 824 prefix ct; 825 reference 826 "RFC XXXX: Common YANG Data Types for Cryptography"; 827 } 829 organization 830 "IETF NETCONF (Network Configuration) Working Group"; 832 contact 833 "WG Web: 834 WG List: 835 Author: Kent Watsen "; 837 description 838 "This module illustrates using groupings defined in the YANG 839 module ietf-crypto-types."; 841 revision "YYYY-MM-DD" { 842 description 843 "Initial version"; 844 } 846 container key { 847 uses ct:private-key-grouping; 848 uses ct:certificates-grouping; 849 description 850 "A container of certificates, and an action to generate 851 a certificate signing request."; 852 } 853 } 855 Appendix B. Change Log 857 TBD 859 Author's Address 861 Kent Watsen 862 Juniper Networks 864 EMail: kwatsen@juniper.net