idnits 2.17.1 draft-ietf-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 410 has weird spacing: '... string cer...' -- The document date (June 4, 2018) is 2152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' Summary: 0 errors (**), 0 flaws (~~), 2 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 June 4, 2018 5 Expires: December 6, 2018 7 Common YANG Data Types for Cryptography 8 draft-ietf-netconf-crypto-types-00 10 Abstract 12 This document defines YANG identities and typedefs useful for 13 cryptographic applications. 15 Editorial Note (To be removed by RFC Editor) 17 This draft contains many placeholder values that need to be replaced 18 with finalized values at the time of publication. This note 19 summarizes all of the substitutions that are needed. No other RFC 20 Editor instructions are specified elsewhere in this document. 22 Artwork in this document contains shorthand references to drafts in 23 progress. Please apply the following replacements: 25 o "XXXX" --> the assigned RFC value for this draft 27 Artwork in this document contains placeholder values for the date of 28 publication of this draft. Please apply the following replacement: 30 o "2018-06-04" --> the publication date of this draft 32 The following Appendix section is to be removed prior to publication: 34 o Appendix A. Change Log 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 6, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 11 75 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 12 76 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 5.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 80 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 This document defines a YANG 1.1 [RFC7950] module specifying 87 identities and typedefs useful for cryptography. 89 As the YANG module only defines identities and typedefs, this draft 90 does not present a YANG tree diagram [RFC8340] or any examples 91 illustrating usage of the module. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 2. YANG Module 101 This module has normartive references for [RFC4253], [RFC5280], 102 [RFC5480], [RFC5652], and [ITU.X690.2015] and has informational 103 references to [RFC6234] and [RFC8017] 105 file "ietf-crypto-types@2018-06-04.yang" 106 module ietf-crypto-types { 107 yang-version 1.1; 109 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 110 prefix "ct"; 112 organization 113 "IETF NETCONF (Network Configuration) Working Group"; 115 contact 116 "WG Web: 117 WG List: 119 Author: Kent Watsen 120 "; 122 description 123 "This module defines common YANG types for cryptographic 124 applications. 126 Copyright (c) 2018 IETF Trust and the persons identified 127 as authors of the code. All rights reserved. 129 Redistribution and use in source and binary forms, with 130 or without modification, is permitted pursuant to, and 131 subject to the license terms contained in, the Simplified 132 BSD License set forth in Section 4.c of the IETF Trust's 133 Legal Provisions Relating to IETF Documents 134 (http://trustee.ietf.org/license-info). 136 This version of this YANG module is part of RFC XXXX; see 137 the RFC itself for full legal notices."; 139 revision "2018-06-04" { 140 description 141 "Initial version"; 142 reference 143 "RFC XXXX: Common YANG Data Types for Cryptography"; 145 } 147 /*****************************************/ 148 /* Identities for Hashing Algorithms */ 149 /*****************************************/ 151 identity hash-algorithm { 152 description 153 "A base identity for hash algorithm verification."; 154 } 156 identity sha-256 { 157 base "hash-algorithm"; 158 description "The SHA-256 algorithm."; 159 reference "RFC 6234: US Secure Hash Algorithms."; 160 } 162 /*************************************/ 163 /* Identities for Key Algorithms */ 164 /*************************************/ 166 identity key-algorithm { 167 description 168 "Base identity from which all key-algorithms are derived."; 169 } 171 identity rsa1024 { 172 base key-algorithm; 173 description 174 "The RSA algorithm using a 1024-bit key."; 175 reference 176 "RFC 8017: 177 PKCS #1: RSA Cryptography Specifications Version 2.2."; 178 } 180 identity rsa2048 { 181 base key-algorithm; 182 description 183 "The RSA algorithm using a 2048-bit key."; 184 reference 185 "RFC 8017: 186 PKCS #1: RSA Cryptography Specifications Version 2.2."; 187 } 189 identity rsa3072 { 190 base key-algorithm; 191 description 192 "The RSA algorithm using a 3072-bit key."; 193 reference 194 "RFC 8017: 195 PKCS #1: RSA Cryptography Specifications Version 2.2."; 196 } 198 identity rsa4096 { 199 base key-algorithm; 200 description 201 "The RSA algorithm using a 4096-bit key."; 202 reference 203 "RFC 8017: 204 PKCS #1: RSA Cryptography Specifications Version 2.2."; 205 } 207 identity rsa7680 { 208 base key-algorithm; 209 description 210 "The RSA algorithm using a 7680-bit key."; 211 reference 212 "RFC 8017: 213 PKCS #1: RSA Cryptography Specifications Version 2.2."; 214 } 216 identity rsa15360 { 217 base key-algorithm; 218 description 219 "The RSA algorithm using a 15360-bit key."; 220 reference 221 "RFC 8017: 222 PKCS #1: RSA Cryptography Specifications Version 2.2."; 223 } 225 identity secp192r1 { 226 base key-algorithm; 227 description 228 "The secp192r1 algorithm."; 229 reference 230 "RFC 5480: Elliptic Curve Cryptography Subject Public 231 Key Information."; 232 } 234 identity secp256r1 { 235 base key-algorithm; 236 description 237 "The secp256r1 algorithm."; 238 reference 239 "RFC 5480: Elliptic Curve Cryptography Subject Public 240 Key Information."; 241 } 243 identity secp384r1 { 244 base key-algorithm; 245 description 246 "The secp384r1 algorithm."; 247 reference 248 "RFC 5480: Elliptic Curve Cryptography Subject Public 249 Key Information."; 250 } 252 identity secp521r1 { 253 base key-algorithm; 254 description 255 "The secp521r1 algorithm."; 256 reference 257 "RFC 5480: Elliptic Curve Cryptography Subject Public 258 Key Information."; 259 } 261 /*********************************************************/ 262 /* Typedefs for identityrefs to above base identites */ 263 /*********************************************************/ 265 typedef hash-algorithm-ref { 266 type identityref { 267 base "hash-algorithm"; 268 } 269 description 270 "This typedef enables importing modules to easily define an 271 identityref to the 'hash-algorithm' base identity."; 272 } 274 typedef key-algorithm-ref { 275 type identityref { 276 base "key-algorithm"; 277 } 278 description 279 "This typedef enables importing modules to easily define an 280 identityref to the 'key-algorithm' base identity."; 281 } 283 /***************************************************/ 284 /* Typedefs for ASN.1 structures from RFC 5280 */ 285 /***************************************************/ 286 typedef x509 { 287 type binary; 288 description 289 "A Certificate structure, as specified in RFC 5280, 290 encoded using ASN.1 distinguished encoding rules (DER), 291 as specified in ITU-T X.690."; 292 reference 293 "RFC 5280: 294 Internet X.509 Public Key Infrastructure Certificate 295 and Certificate Revocation List (CRL) Profile 296 ITU-T X.690: 297 Information technology - ASN.1 encoding rules: 298 Specification of Basic Encoding Rules (BER), 299 Canonical Encoding Rules (CER) and Distinguished 300 Encoding Rules (DER)."; 301 } 303 typedef crl { 304 type binary; 305 description 306 "A CertificateList structure, as specified in RFC 5280, 307 encoded using ASN.1 distinguished encoding rules (DER), 308 as specified in ITU-T X.690."; 309 reference 310 "RFC 5280: 311 Internet X.509 Public Key Infrastructure Certificate 312 and Certificate Revocation List (CRL) Profile 313 ITU-T X.690: 314 Information technology - ASN.1 encoding rules: 315 Specification of Basic Encoding Rules (BER), 316 Canonical Encoding Rules (CER) and Distinguished 317 Encoding Rules (DER)."; 318 } 320 /***********************************************/ 321 /* Typedefs for ASN.1 structures from 5652 */ 322 /***********************************************/ 324 typedef cms { 325 type binary; 326 description 327 "A ContentInfo structure, as specified in RFC 5652, 328 encoded using ASN.1 distinguished encoding rules (DER), 329 as specified in ITU-T X.690."; 330 reference 331 "RFC 5652: 332 Cryptographic Message Syntax (CMS) 333 ITU-T X.690: 335 Information technology - ASN.1 encoding rules: 336 Specification of Basic Encoding Rules (BER), 337 Canonical Encoding Rules (CER) and Distinguished 338 Encoding Rules (DER)."; 339 } 341 typedef data-content-cms { 342 type cms; 343 description 344 "A CMS structure whose top-most content type MUST be the 345 data content type, as described by Section 4 in RFC 5652."; 346 reference 347 "RFC 5652: Cryptographic Message Syntax (CMS)"; 348 } 350 typedef signed-data-cms { 351 type cms; 352 description 353 "A CMS structure whose top-most content type MUST be the 354 signed-data content type, as described by Section 5 in 355 RFC 5652."; 356 reference 357 "RFC 5652: Cryptographic Message Syntax (CMS)"; 358 } 360 typedef enveloped-data-cms { 361 type cms; 362 description 363 "A CMS structure whose top-most content type MUST be the 364 enveloped-data content type, as described by Section 6 365 in RFC 5652."; 366 reference 367 "RFC 5652: Cryptographic Message Syntax (CMS)"; 368 } 370 typedef digested-data-cms { 371 type cms; 372 description 373 "A CMS structure whose top-most content type MUST be the 374 digested-data content type, as described by Section 7 375 in RFC 5652."; 376 reference 377 "RFC 5652: Cryptographic Message Syntax (CMS)"; 378 } 380 typedef encrypted-data-cms { 381 type cms; 382 description 383 "A CMS structure whose top-most content type MUST be the 384 encrypted-data content type, as described by Section 8 385 in RFC 5652."; 386 reference 387 "RFC 5652: Cryptographic Message Syntax (CMS)"; 388 } 390 typedef authenticated-data-cms { 391 type cms; 392 description 393 "A CMS structure whose top-most content type MUST be the 394 authenticated-data content type, as described by Section 9 395 in RFC 5652."; 396 reference 397 "RFC 5652: Cryptographic Message Syntax (CMS)"; 398 } 400 /***************************************************/ 401 /* Typedefs for structures related to RFC 4253 */ 402 /***************************************************/ 404 typedef ssh-host-key { 405 type binary; 406 description 407 "The binary public key data for this SSH key, as 408 specified by RFC 4253, Section 6.6, i.e.: 410 string certificate or public key format 411 identifier 412 byte[n] key/certificate data."; 413 reference 414 "RFC 4253: The Secure Shell (SSH) Transport Layer 415 Protocol"; 416 } 418 /*********************************************************/ 419 /* Typedefs for ASN.1 structures related to RFC 5280 */ 420 /*********************************************************/ 422 typedef trust-anchor-cert-x509 { 423 type x509; 424 description 425 "A Certificate structure that MUST encode a self-signed 426 root certificate."; 427 } 429 typedef end-entity-cert-x509 { 430 type x509; 431 description 432 "A Certificate structure that MUST encode a certificate 433 that is neither self-signed nor having Basic constraint 434 CA true."; 435 } 437 /*********************************************************/ 438 /* Typedefs for ASN.1 structures related to RFC 5652 */ 439 /*********************************************************/ 441 typedef trust-anchor-cert-cms { 442 type signed-data-cms; 443 description 444 "A CMS SignedData structure that MUST contain the chain of 445 X.509 certificates needed to authenticate the certificate 446 presented by a client or end-entity. 448 The CMS MUST contain only a single chain of certificates. 449 The client or end-entity certificate MUST only authenticate 450 to last intermediate CA certificate listed in the chain. 452 In all cases, the chain MUST include a self-signed root 453 certificate. In the case where the root certificate is 454 itself the issuer of the client or end-entity certificate, 455 only one certificate is present. 457 This CMS structure MAY (as applicable where this type is 458 used) also contain suitably fresh (as defined by local 459 policy) revocation objects with which the device can 460 verify the revocation status of the certificates. 462 This CMS encodes the degenerate form of the SignedData 463 structure that is commonly used to disseminate X.509 464 certificates and revocation objects (RFC 5280)."; 465 reference 466 "RFC 5280: 467 Internet X.509 Public Key Infrastructure Certificate 468 and Certificate Revocation List (CRL) Profile."; 469 } 471 typedef end-entity-cert-cms { 472 type signed-data-cms; 473 description 474 "A CMS SignedData structure that MUST contain the end 475 entity certificate itself, and MAY contain any number 476 of intermediate certificates leading up to a trust 477 anchor certificate. The trust anchor certificate 478 MAY be included as well. 480 The CMS MUST contain a single end entity certificate. 481 The CMS MUST NOT contain any spurious certificates. 483 This CMS structure MAY (as applicable where this type is 484 used) also contain suitably fresh (as defined by local 485 policy) revocation objects with which the device can 486 verify the revocation status of the certificates. 488 This CMS encodes the degenerate form of the SignedData 489 structure that is commonly used to disseminate X.509 490 certificates and revocation objects (RFC 5280)."; 491 reference 492 "RFC 5280: 493 Internet X.509 Public Key Infrastructure Certificate 494 and Certificate Revocation List (CRL) Profile."; 495 } 497 } 498 500 3. Security Considerations 502 In order to use YANG identities for algorithm identifiers, only the 503 most commonly used RSA key lengths are supported for the RSA 504 algorithm. Additional key lengths can be defined in another module 505 or added into a future version of this document. 507 This document limits the number of elliptical curves supported. This 508 was done to match industry trends and IETF best practice (e.g., 509 matching work being done in TLS 1.3). If additional algorithms are 510 needed, they can be defined by another module or added into a future 511 version of this document. 513 The YANG module defined in this document specifies only typedefs and 514 identities, and hence there are no YANG-specific security 515 considerations that need to be addressed. 517 4. IANA Considerations 519 4.1. The IETF XML Registry 521 This document registers one URI in the "ns" subregistry of the IETF 522 XML Registry [RFC3688]. Following the format in [RFC3688], the 523 following registration is requested: 525 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 526 Registrant Contact: The NETCONF WG of the IETF. 527 XML: N/A, the requested URI is an XML namespace. 529 4.2. The YANG Module Names Registry 531 This document registers one YANG module in the YANG Module Names 532 registry [RFC6020]. Following the format in [RFC6020], the the 533 following registration is requested: 535 name: ietf-crypto-types 536 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 537 prefix: ct 538 reference: RFC XXXX 540 5. References 542 5.1. Normative References 544 [ITU.X690.2015] 545 International Telecommunication Union, "Information 546 Technology - ASN.1 encoding rules: Specification of Basic 547 Encoding Rules (BER), Canonical Encoding Rules (CER) and 548 Distinguished Encoding Rules (DER)", ITU-T Recommendation 549 X.690, ISO/IEC 8825-1, August 2015, 550 . 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 558 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 559 January 2006, . 561 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 562 Housley, R., and W. Polk, "Internet X.509 Public Key 563 Infrastructure Certificate and Certificate Revocation List 564 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 565 . 567 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 568 "Elliptic Curve Cryptography Subject Public Key 569 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 570 . 572 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 573 RFC 5652, DOI 10.17487/RFC5652, September 2009, 574 . 576 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 577 RFC 7950, DOI 10.17487/RFC7950, August 2016, 578 . 580 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 581 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 582 May 2017, . 584 5.2. Informative References 586 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 587 DOI 10.17487/RFC3688, January 2004, 588 . 590 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 591 the Network Configuration Protocol (NETCONF)", RFC 6020, 592 DOI 10.17487/RFC6020, October 2010, 593 . 595 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 596 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 597 DOI 10.17487/RFC6234, May 2011, 598 . 600 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 601 "PKCS #1: RSA Cryptography Specifications Version 2.2", 602 RFC 8017, DOI 10.17487/RFC8017, November 2016, 603 . 605 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 606 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 607 . 609 Appendix A. Change Log 611 A.1. I-D to 00 613 o Removed groupings and notifications. 615 o Added typedefs for identityrefs. 617 o Added typedefs for other RFC 5280 structures. 619 o Added typedefs for other RFC 5652 structures. 621 o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 623 Acknowledgements 625 The authors would like to thank for following for lively discussions 626 on list and in the halls (ordered by last name): Martin Bjorklund, 627 Balazs Kovacs, Eric Voit, and Liang Xia. 629 Author's Address 631 Kent Watsen 632 Juniper Networks 634 EMail: kwatsen@juniper.net