idnits 2.17.1 draft-ietf-netconf-crypto-types-19.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 348 has weird spacing: '...-format ide...' == Line 398 has weird spacing: '...-format ide...' == Line 445 has weird spacing: '...-format ide...' == Line 475 has weird spacing: '...-format ide...' == Line 522 has weird spacing: '...-format ide...' == (20 more instances...) -- The document date (10 February 2021) is 1170 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.X680.2015' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 7093 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-20 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-21 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-22 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-08 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-22 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-13 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 4 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 10 February 2021 5 Expires: 14 August 2021 7 YANG Data Types and Groupings for Cryptography 8 draft-ietf-netconf-crypto-types-19 10 Abstract 12 This document presents a YANG 1.1 (RFC 7950) module defining 13 identities, typedefs, and groupings useful to cryptographic 14 applications. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains placeholder values that need to be replaced with 19 finalized values at the time of publication. This note summarizes 20 all of the substitutions that are needed. No other RFC Editor 21 instructions are specified elsewhere in this document. 23 Artwork in this document contains shorthand references to drafts in 24 progress. Please apply the following replacements: 26 * "AAAA" --> the assigned RFC value for this draft 28 Artwork in this document contains placeholder values for the date of 29 publication of this draft. Please apply the following replacement: 31 * "2021-02-10" --> the publication date of this draft 33 The following Appendix section is to be removed prior to publication: 35 * 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 14 August 2021. 54 Copyright Notice 56 Copyright (c) 2021 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 (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 72 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 73 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 74 2. The "ietf-crypto-types" Module . . . . . . . . . . . . . . . 5 75 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 76 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18 77 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 78 3. Security Considerations . . . . . . . . . . . . . . . . . . . 47 79 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 48 80 3.2. No Support for Key Generation . . . . . . . . . . . . . . 48 81 3.3. Unconstrained Public Key Usage . . . . . . . . . . . . . 48 82 3.4. Unconstrained Private Key Usage . . . . . . . . . . . . . 48 83 3.5. Strength of Keys Configured . . . . . . . . . . . . . . . 49 84 3.6. Encrypting Passwords . . . . . . . . . . . . . . . . . . 49 85 3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 49 86 3.8. The "ietf-crypto-types" YANG Module . . . . . . . . . . . 49 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 88 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 51 89 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 51 90 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 91 5.1. Normative References . . . . . . . . . . . . . . . . . . 51 92 5.2. Informative References . . . . . . . . . . . . . . . . . 53 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55 94 A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 55 95 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 55 96 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 56 97 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 56 98 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 57 99 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 57 100 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 57 101 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 58 102 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 58 103 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 58 104 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 58 105 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 59 106 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 59 107 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 59 108 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 59 109 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 60 110 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 60 111 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 60 112 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 61 113 A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 61 114 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 117 1. Introduction 119 This document presents a YANG 1.1 [RFC7950] module defining 120 identities, typedefs, and groupings useful to cryptographic 121 applications. 123 1.1. Relation to other RFCs 125 This document presents one or more YANG modules [RFC7950] that are 126 part of a collection of RFCs that work together to, ultimately, 127 enable the configuration of the clients and servers of both the 128 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 130 The modules have been defined in a modular fashion to enable their 131 use by other efforts, some of which are known to be in progress at 132 the time of this writing, with many more expected to be defined in 133 time. 135 The normative dependency relationship between the various RFCs in the 136 collection is presented in the below diagram. The labels in the 137 diagram represent the primary purpose provided by each RFC. 138 Hyperlinks to each RFC are provided below the diagram. 140 crypto-types 141 ^ ^ 142 / \ 143 / \ 144 truststore keystore 145 ^ ^ ^ ^ 146 | +---------+ | | 147 | | | | 148 | +------------+ | 149 tcp-client-server | / | | 150 ^ ^ ssh-client-server | | 151 | | ^ tls-client-server 152 | | | ^ ^ http-client-server 153 | | | | | ^ 154 | | | +-----+ +---------+ | 155 | | | | | | 156 | +-----------|--------|--------------+ | | 157 | | | | | | 158 +-----------+ | | | | | 159 | | | | | | 160 | | | | | | 161 netconf-client-server restconf-client-server 163 +=======================+===========================================+ 164 |Label in Diagram | Originating RFC | 165 +=======================+===========================================+ 166 |crypto-types | [I-D.ietf-netconf-crypto-types] | 167 +-----------------------+-------------------------------------------+ 168 |truststore | [I-D.ietf-netconf-trust-anchors] | 169 +-----------------------+-------------------------------------------+ 170 |keystore | [I-D.ietf-netconf-keystore] | 171 +-----------------------+-------------------------------------------+ 172 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 173 +-----------------------+-------------------------------------------+ 174 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 175 +-----------------------+-------------------------------------------+ 176 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 177 +-----------------------+-------------------------------------------+ 178 |http-client-server | [I-D.ietf-netconf-http-client-server] | 179 +-----------------------+-------------------------------------------+ 180 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 181 +-----------------------+-------------------------------------------+ 182 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 183 +-----------------------+-------------------------------------------+ 185 Table 1: Label to RFC Mapping 187 1.2. Specification Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 1.3. Adherence to the NMDA 197 This document in compliant with the Network Management Datastore 198 Architecture (NMDA) [RFC8342]. It does not define any protocol 199 accessible nodes that are "config false". 201 2. The "ietf-crypto-types" Module 203 This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- 204 types". A high-level overview of the module is provided in 205 Section 2.1. Examples illustatrating the module's use are provided 206 in Examples (Section 2.2). The YANG module itself is defined in 207 Section 2.3. 209 2.1. Data Model Overview 211 This section provides an overview of the "ietf-crypto-types" module 212 in terms of its features, indentities, typedefs, and groupings. 214 2.1.1. Features 216 The following diagram lists all the "feature" statements defined in 217 the "ietf-crypto-types" module: 219 Features: 220 +-- one-symmetric-key-format 221 +-- one-asymmetric-key-format 222 +-- certificate-signing-request-generation 223 +-- certificate-expiration-notification 224 +-- symmetrically-encrypted-value-format 225 +-- asymmetrically-encrypted-value-format 226 +-- cms-encrypted-data-format 227 +-- cms-enveloped-data-format 229 | The diagram above uses syntax that is similar to but not 230 | defined in [RFC8340]. 232 2.1.2. Identities 234 The following diagram illustrates the relationship amongst the 235 "identity" statements defined in the "ietf-crypto-types" module: 237 Identities: 238 +-- public-key-format 239 | +-- subject-public-key-info-format 240 | +-- ssh-public-key-format 241 +-- private-key-format 242 | +-- rsa-private-key-format 243 | +-- ec-private-key-format 244 | +-- one-asymmetric-key-format 245 | {one-asymmetric-key-format}? 246 +-- symmetric-key-format 247 | +-- octet-string-key-format 248 | +-- one-symmetric-key-format 249 | {one-symmetric-key-format}? 250 +-- encrypted-value-format 251 +-- symmetrically-encrypted-value-format 252 | | {symmetrically-encrypted-value-format}? 253 | +-- cms-encrypted-data-format 254 | {cms-encrypted-data-format}? 255 +-- asymmetrically-encrypted-value-format 256 | {asymmetrically-encrypted-value-format}? 257 +-- cms-enveloped-data-format 258 {cms-enveloped-data-format}? 260 | The diagram above uses syntax that is similar to but not 261 | defined in [RFC8340]. 263 Comments: 265 * The diagram shows that there are four base identities. The first 266 three identities are used to indicate the format that key data, 267 while the fourth identity is used to indicate the format for 268 encrypted values. The base identities are "abstract", in the 269 object orientied programming sense, in that they only define a 270 "class" of formats, rather than a specific format. 272 * The various "leaf" identities define specific encoding formats. 273 The derived identities defined in this document are sufficient for 274 the effort described in Section 1.1 but, by nature of them being 275 identities, additional derived identities MAY be defined by future 276 efforts. 278 * Identities used to specify uncommon formats are enabled by 279 "feature" statements, allowing applications to support them when 280 needed. 282 2.1.3. Typedefs 284 The following diagram illustrates the relationship amongst the 285 "typedef" statements defined in the "ietf-crypto-types" module: 287 Typedefs: 288 binary 289 +-- csr-info 290 +-- csr 291 +-- x509 292 | +-- trust-anchor-cert-x509 293 | +-- end-entity-cert-x509 294 +-- crl 295 +-- ocsp-request 296 +-- ocsp-response 297 +-- cms 298 +-- data-content-cms 299 +-- signed-data-cms 300 | +-- trust-anchor-cert-cms 301 | +-- end-entity-cert-cms 302 +-- enveloped-data-cms 303 +-- digested-data-cms 304 +-- encrypted-data-cms 305 +-- authenticated-data-cms 307 | The diagram above uses syntax that is similar to but not 308 | defined in [RFC8340]. 310 Comments: 312 * All of the typedefs defined in the "ietf-crypto-types" module 313 extend the "binary" type defined in [RFC7950]. 315 * Additionally, all the typedefs define a type for encoding an ASN.1 316 [ITU.X680.2015] structure using DER [ITU.X690.2015]. 318 * The "trust-anchor-*" and "end-entity-*" typedefs are syntactically 319 identical to their base typedefs and only distiguish themselves by 320 the expected nature of their content. These typedefs are defined 321 to facilitate common modeling needs. 323 2.1.4. Groupings 325 The "ietf-crypto-types" module defines the following "grouping" 326 statements: 328 * encrypted-value-grouping 329 * password-grouping 330 * symmetric-key-grouping 331 * public-key-grouping 332 * asymmetric-key-pair-grouping 333 * trust-anchor-cert-grouping 334 * end-entity-cert-grouping 335 * generate-csr-grouping 336 * asymmetric-key-pair-with-cert-grouping 337 * asymmetric-key-pair-with-certs-grouping 339 Each of these groupings are presented in the following subsections. 341 2.1.4.1. The "encrypted-value-grouping" Grouping 343 The following tree diagram [RFC8340] illustrates the "encrypted- 344 value-grouping" grouping: 346 grouping encrypted-value-grouping 347 +-- encrypted-by 348 +-- encrypted-value-format identityref 349 +-- encrypted-value binary 351 Comments: 353 * The "encrypted-by" node is an empty container (difficult to see in 354 the diagram) that a consuming module MUST augment key references 355 into. The "ietf-crypto-types" module is unable to populate this 356 container as the module only defines groupings. Section 2.2.1 357 presents an example illustrating a consuming module populating the 358 "encrypted-by" container. 360 * The "encrypted-value" node is the value, encrypted by the key 361 referenced by the "encrypted-by" node, and encoded in the format 362 appropriate for the kind of key it was encrypted by. 364 - If the value is encrypted by a symmetric key, then the 365 encrypted value is encoded using the format associated with the 366 "symmetrically-encrypted-value-format" identity. 368 - If the value is encrypted by an asymmetric key, then the 369 encrypted value is encoded using the format associated with the 370 "asymmetrically-encrypted-value-format" identity. 372 See Section 2.1.2 for information about the "format" identities. 374 2.1.4.2. The "password-grouping" Grouping 376 This section presents two tree diagrams [RFC8340] illustrating the 377 "password-grouping" grouping. The first tree diagram does not expand 378 the internally used grouping statement(s): 380 grouping password-grouping 381 +-- (password-type) 382 +--:(cleartext-password) 383 | +-- cleartext-password? string 384 +--:(encrypted-password) {password-encryption}? 385 +-- encrypted-password 386 +---u encrypted-value-grouping 388 The following tree diagram expands the internally used grouping 389 statement(s), enabling the grouping's full structure to be seen: 391 grouping password-grouping 392 +-- (password-type) 393 +--:(cleartext-password) 394 | +-- cleartext-password? string 395 +--:(encrypted-password) {password-encryption}? 396 +-- encrypted-password 397 +-- encrypted-by 398 +-- encrypted-value-format identityref 399 +-- encrypted-value binary 401 Comments: 403 * For the referenced grouping statement(s): 405 - The "encrypted-value-grouping" grouping is discussed in 406 Section 2.1.4.1. 408 * The "choice" statement enables the password data to be cleartext 409 or encrypted, as follows: 411 - The "cleartext-password" node can encode any cleartext value. 412 - The "encrypted-password" node's structure is discussed in 413 Section 2.1.4.1. 415 2.1.4.3. The "symmetric-key-grouping" Grouping 417 This section presents two tree diagrams [RFC8340] illustrating the 418 "symmetric-key-grouping" grouping. The first tree diagram does not 419 expand the internally used grouping statement(s): 421 grouping symmetric-key-grouping 422 +-- key-format? identityref 423 +-- (key-type) 424 +--:(cleartext-key) 425 | +-- cleartext-key? binary 426 +--:(hidden-key) 427 | +-- hidden-key? empty 428 +--:(encrypted-key) {symmetric-key-encryption}? 429 +-- encrypted-key 430 +---u encrypted-value-grouping 432 The following tree diagram expands the internally used grouping 433 statement(s), enabling the grouping's full structure to be seen: 435 grouping symmetric-key-grouping 436 +-- key-format? identityref 437 +-- (key-type) 438 +--:(cleartext-key) 439 | +-- cleartext-key? binary 440 +--:(hidden-key) 441 | +-- hidden-key? empty 442 +--:(encrypted-key) {symmetric-key-encryption}? 443 +-- encrypted-key 444 +-- encrypted-by 445 +-- encrypted-value-format identityref 446 +-- encrypted-value binary 448 Comments: 450 * For the referenced grouping statement(s): 452 - The "encrypted-value-grouping" grouping is discussed in 453 Section 2.1.4.1. 455 * The "key-format" node is an identity-reference to the "symmetric- 456 key-format" abstract base identity discussed in Section 2.1.2, 457 enabling the symmetric key to be encoded using the format defined 458 by any of the derived identities. 460 * The "choice" statement enables the private key data to be 461 cleartext, encrypted, or hidden, as follows: 463 - The "cleartext-key" node can encode any cleartext key value. 464 - The "hidden-key" node is of type "empty" as the real value 465 cannot be presented via the management interface. 466 - The "encrypted-key" node's structure is discussed in 467 Section 2.1.4.1. 469 2.1.4.4. The "public-key-grouping" Grouping 471 The following tree diagram [RFC8340] illustrates the "public-key- 472 grouping" grouping: 474 grouping public-key-grouping 475 +-- public-key-format identityref 476 +-- public-key binary 478 Comments: 480 * The "public-key-format" node is an identity-reference to the 481 "public-key-format" abstract base identity discussed in 482 Section 2.1.2, enabling the public key to be encoded using the 483 format defined by any of the derived identities. 485 * The "public-key" node is the public key data in the selected 486 format. No "choice" statement is used to hide or encrypt the 487 public key data because it is unecessary to do so for public keys. 489 2.1.4.5. The "asymmetric-key-pair-grouping" Grouping 491 This section presents two tree diagrams [RFC8340] illustrating the 492 "asymmetric-key-pair-grouping" grouping. The first tree diagram does 493 not expand the internally used grouping statement(s): 495 grouping asymmetric-key-pair-grouping 496 +---u public-key-grouping 497 +-- private-key-format? identityref 498 +-- (private-key-type) 499 +--:(cleartext-private-key) 500 | +-- cleartext-private-key? binary 501 +--:(hidden-private-key) 502 | +-- hidden-private-key? empty 503 +--:(encrypted-private-key) {private-key-encryption}? 504 +-- encrypted-private-key 505 +---u encrypted-value-grouping 507 The following tree diagram expands the internally used grouping 508 statement(s), enabling the grouping's full structure to be seen: 510 grouping asymmetric-key-pair-grouping 511 +-- public-key-format identityref 512 +-- public-key binary 513 +-- private-key-format? identityref 514 +-- (private-key-type) 515 +--:(cleartext-private-key) 516 | +-- cleartext-private-key? binary 517 +--:(hidden-private-key) 518 | +-- hidden-private-key? empty 519 +--:(encrypted-private-key) {private-key-encryption}? 520 +-- encrypted-private-key 521 +-- encrypted-by 522 +-- encrypted-value-format identityref 523 +-- encrypted-value binary 525 Comments: 527 * For the referenced grouping statement(s): 529 - The "public-key-grouping" grouping is discussed in 530 Section 2.1.4.4. 531 - The "encrypted-value-grouping" grouping is discussed in 532 Section 2.1.4.1. 534 * The "private-key-format" node is an identity-reference to the 535 "private-key-format" abstract base identity discussed in 536 Section 2.1.2, enabling the private key to be encoded using the 537 format defined by any of the derived identities. 539 * The "choice" statement enables the private key data to be 540 cleartext, encrypted, or hidden, as follows: 542 - The "cleartext-private-key" node can encode any cleartext key 543 value. 544 - The "hidden-private-key" node is of type "empty" as the real 545 value cannot be presented via the management interface. 546 - The "encrypted-private-key" node's structure is discussed in 547 Section 2.1.4.1. 549 2.1.4.6. The "certificate-expiration-grouping" Grouping 551 The following tree diagram [RFC8340] illustrates the "certificate- 552 expiration-grouping" grouping: 554 grouping certificate-expiration-grouping 555 +---n certificate-expiration 556 {certificate-expiration-notification}? 557 +-- expiration-date yang:date-and-time 559 Comments: 561 * This grouping's only purpose is to define the "certificate- 562 expiration" notification statement, used by the groupings defined 563 in Section 2.1.4.7 and Section 2.1.4.8. 565 * The "certificate-expiration" notification enables servers to 566 notify clients when certificates are nearing expiration. 568 * The "expiration-date" node indicates when the designated 569 certificate will (or did) expire. 571 * Identification of the certificate that is expiring is built into 572 the notification itself. For an example, please see 573 Section 2.2.3. 575 2.1.4.7. The "trust-anchor-cert-grouping" Grouping 577 This section presents two tree diagrams [RFC8340] illustrating the 578 "trust-anchor-cert-grouping" grouping. The first tree diagram does 579 not expand the internally used grouping statement(s): 581 grouping trust-anchor-cert-grouping 582 +-- cert-data? trust-anchor-cert-cms 583 +---u certificate-expiration-grouping 585 The following tree diagram expands the internally used grouping 586 statement(s), enabling the grouping's full structure to be seen: 588 grouping trust-anchor-cert-grouping 589 +-- cert-data? trust-anchor-cert-cms 590 +---n certificate-expiration 591 {certificate-expiration-notification}? 592 +-- expiration-date yang:date-and-time 594 Comments: 596 * For the referenced grouping statement(s): 598 - The "certificate-expiration-grouping" grouping is discussed in 599 Section 2.1.4.6. 601 * The "cert-data" node contains a chain of one or more certificates 602 encoded using a "signed-data-cms" typedef discussed in 603 Section 2.1.3. 605 2.1.4.8. The "end-entity-cert-grouping" Grouping 607 This section presents two tree diagrams [RFC8340] illustrating the 608 "end-entity-cert-grouping" grouping. The first tree diagram does not 609 expand the internally used grouping statement(s): 611 grouping end-entity-cert-grouping 612 +-- cert-data? end-entity-cert-cms 613 +---u certificate-expiration-grouping 615 The following tree diagram expands the internally used grouping 616 statement(s), enabling the grouping's full structure to be seen: 618 grouping end-entity-cert-grouping 619 +-- cert-data? end-entity-cert-cms 620 +---n certificate-expiration 621 {certificate-expiration-notification}? 622 +-- expiration-date yang:date-and-time 624 Comments: 626 * For the referenced grouping statement(s): 628 - The "certificate-expiration-grouping" grouping is discussed in 629 Section 2.1.4.6. 631 * The "cert-data" node contains a chain of one or more certificates 632 encoded using a "signed-data-cms" typedef discussed in 633 Section 2.1.3. 635 2.1.4.9. The "generate-csr-grouping" Grouping 637 The following tree diagram [RFC8340] illustrates the "generate-csr- 638 grouping" grouping: 640 grouping generate-csr-grouping 641 +---x generate-certificate-signing-request 642 {certificate-signing-request-generation}? 643 +---w input 644 | +---w csr-info ct:csr-info 645 +--ro output 646 +--ro certificate-signing-request ct:csr 648 Comments: 650 * This grouping's only purpose is to define the "generate- 651 certificate-signing-request" action statement, used by the 652 groupings defined in Section 2.1.4.10 and Section 2.1.4.11. 654 * This action takes as input a "csr-info" type and returns a "csr" 655 type, both of which are discussed in Section 2.1.3. 657 * For an example, please see Section 2.2.2. 659 2.1.4.10. The "asymmetric-key-pair-with-cert-grouping" Grouping 661 This section presents two tree diagrams [RFC8340] illustrating the 662 "asymmetric-key-pair-with-cert-grouping" grouping. The first tree 663 diagram does not expand the internally used grouping statement(s): 665 grouping asymmetric-key-pair-with-cert-grouping 666 +---u asymmetric-key-pair-grouping 667 +---u end-entity-cert-grouping 668 +---u generate-csr-grouping 670 The following tree diagram expands the internally used grouping 671 statement(s), enabling the grouping's full structure to be seen: 673 grouping asymmetric-key-pair-with-cert-grouping 674 +-- public-key-format identityref 675 +-- public-key binary 676 +-- private-key-format? identityref 677 +-- (private-key-type) 678 | +--:(cleartext-private-key) 679 | | +-- cleartext-private-key? binary 680 | +--:(hidden-private-key) 681 | | +-- hidden-private-key? empty 682 | +--:(encrypted-private-key) {private-key-encryption}? 683 | +-- encrypted-private-key 684 | +-- encrypted-by 685 | +-- encrypted-value-format identityref 686 | +-- encrypted-value binary 687 +-- cert-data? end-entity-cert-cms 688 +---n certificate-expiration 689 | {certificate-expiration-notification}? 690 | +-- expiration-date yang:date-and-time 691 +---x generate-certificate-signing-request 692 {certificate-signing-request-generation}? 693 +---w input 694 | +---w csr-info ct:csr-info 695 +--ro output 696 +--ro certificate-signing-request ct:csr 698 Comments: 700 * This grouping defines an asymmetric key with at most one 701 associated certificate, a commonly needed combination in protocol 702 models. 704 * For the referenced grouping statement(s): 706 - The "asymmetric-key-pair-grouping" grouping is discussed in 707 Section 2.1.4.5. 708 - The "end-entity-cert-grouping" grouping is discussed in 709 Section 2.1.4.8. 710 - The "generate-csr-grouping" grouping is discussed in 711 Section 2.1.4.9. 713 2.1.4.11. The "asymmetric-key-pair-with-certs-grouping" Grouping 715 This section presents two tree diagrams [RFC8340] illustrating the 716 "asymmetric-key-pair-with-certs-grouping" grouping. The first tree 717 diagram does not expand the internally used grouping statement(s): 719 grouping asymmetric-key-pair-with-certs-grouping 720 +---u asymmetric-key-pair-grouping 721 +-- certificates 722 | +-- certificate* [name] 723 | +-- name? string 724 | +---u end-entity-cert-grouping 725 +---u generate-csr-grouping 727 The following tree diagram expands the internally used grouping 728 statement(s), enabling the grouping's full structure to be seen: 730 grouping asymmetric-key-pair-with-certs-grouping 731 +-- public-key-format identityref 732 +-- public-key binary 733 +-- private-key-format? identityref 734 +-- (private-key-type) 735 | +--:(cleartext-private-key) 736 | | +-- cleartext-private-key? binary 737 | +--:(hidden-private-key) 738 | | +-- hidden-private-key? empty 739 | +--:(encrypted-private-key) {private-key-encryption}? 740 | +-- encrypted-private-key 741 | +-- encrypted-by 742 | +-- encrypted-value-format identityref 743 | +-- encrypted-value binary 744 +-- certificates 745 | +-- certificate* [name] 746 | +-- name? string 747 | +-- cert-data end-entity-cert-cms 748 | +---n certificate-expiration 749 | {certificate-expiration-notification}? 750 | +-- expiration-date yang:date-and-time 751 +---x generate-certificate-signing-request 752 {certificate-signing-request-generation}? 753 +---w input 754 | +---w csr-info ct:csr-info 755 +--ro output 756 +--ro certificate-signing-request ct:csr 758 Comments: 760 * This grouping defines an asymmetric key with one or more 761 associated certificates, a commonly needed combination in 762 configuration models. 764 * For the referenced grouping statement(s): 766 - The "asymmetric-key-pair-grouping" grouping is discussed in 767 Section 2.1.4.5. 768 - The "end-entity-cert-grouping" grouping is discussed in 769 Section 2.1.4.8. 770 - The "generate-csr-grouping" grouping is discussed in 771 Section 2.1.4.9. 773 2.1.5. Protocol-accessible Nodes 775 The "ietf-crypto-types" module does not contain any protocol- 776 accessible nodes, but the module needs to be "implemented", as 777 described in Section 5.6.5 of [RFC7950], in order for the identities 778 in Section 2.1.2 to be defined. 780 2.2. Example Usage 782 2.2.1. The "symmetric-key-grouping" and "asymmetric-key-pair-with- 783 certs-grouping" Grouping 785 The following non-normative module is constructed in order to 786 illustrate the use of the "symmetric-key-grouping" (Section 2.1.4.3), 787 the "asymmetric-key-pair-with-certs-grouping" (Section 2.1.4.11), and 788 the "password-grouping" (Section 2.1.4.2) grouping statements. 790 Notably, this example illustrates a hidden asymmetric key (ex-hidden- 791 asymmetric-key) has been used to encrypt a symmetric key (ex- 792 encrypted-one-symmetric-based-symmetric-key) that has been used to 793 encrypt another asymmetric key (ex-encrypted-rsa-based-asymmetric- 794 key). Additionally, the symmetric key is also used to encrypt a 795 password (ex-encrypted-password). 797 module ex-crypto-types-usage { 798 yang-version 1.1; 800 namespace "http://example.com/ns/example-crypto-types-usage"; 801 prefix "ectu"; 803 import ietf-crypto-types { 804 prefix ct; 805 reference 806 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 807 } 809 organization "Example Corporation"; 810 contact "YANG Designer "; 812 description 813 "This module illustrates the 'symmetric-key-grouping' 814 and 'asymmetric-key-grouping' groupings defined in 815 the 'ietf-crypto-types' module defined in RFC AAAA."; 817 revision "2021-02-10" { 818 description 819 "Initial version"; 820 reference 821 "RFC AAAA: Common YANG Data Types for Cryptography"; 822 } 824 container symmetric-keys { 825 description 826 "A container of symmetric keys."; 827 list symmetric-key { 828 key name; 829 description 830 "A symmetric key"; 831 leaf name { 832 type string; 833 description 834 "An arbitrary name for this key."; 835 } 836 uses ct:symmetric-key-grouping { 837 augment "key-type/encrypted-key/encrypted-key/" 838 + "encrypted-by" { 839 description 840 "Augments in a choice statement enabling the 841 encrypting key to be any other symmetric or 842 asymmetric key."; 843 uses encrypted-by-choice-grouping; 844 } 845 } 846 } 847 } 849 container asymmetric-keys { 850 description 851 "A container of asymmetric keys."; 852 list asymmetric-key { 853 key name; 854 leaf name { 855 type string; 856 description 857 "An arbitrary name for this key."; 858 } 859 uses ct:asymmetric-key-pair-with-certs-grouping { 860 augment "private-key-type/encrypted-private-key/" 861 + "encrypted-private-key/encrypted-by" { 862 description 863 "Augments in a choice statement enabling the 864 encrypting key to be any other symmetric or 865 asymmetric key."; 866 uses encrypted-by-choice-grouping; 867 } 869 } 870 description 871 "An asymmetric key pair with associated certificates."; 872 } 873 } 875 container passwords { 876 description 877 "A container of passwords."; 878 list password { 879 key name; 880 leaf name { 881 type string; 882 description 883 "An arbitrary name for this password."; 884 } 885 uses ct:password-grouping { 886 augment "password-type/encrypted-password/" 887 + "encrypted-password/encrypted-by" { 888 description 889 "Augments in a choice statement enabling the 890 encrypting key to be any symmetric or 891 asymmetric key."; 892 uses encrypted-by-choice-grouping; 893 } 894 } 895 description 896 "A password."; 897 } 898 } 900 grouping encrypted-by-choice-grouping { 901 description 902 "A grouping that defines a choice enabling references 903 to other keys."; 904 choice encrypted-by-choice { 905 mandatory true; 906 description 907 "A choice amongst other symmetric or asymmetric keys."; 908 case symmetric-key-ref { 909 leaf symmetric-key-ref { 910 type leafref { 911 path "/ectu:symmetric-keys/ectu:symmetric-key/" 912 + "ectu:name"; 913 } 914 description 915 "Identifies the symmetric key used to encrypt this key."; 917 } 918 } 919 case asymmetric-key-ref { 920 leaf asymmetric-key-ref { 921 type leafref { 922 path "/ectu:asymmetric-keys/ectu:asymmetric-key/" 923 + "ectu:name"; 924 } 925 description 926 "Identifies the asymmetric key used to encrypt this key."; 927 } 928 } 929 } 930 } 932 } 934 The tree diagram [RFC8340] for this example module follows: 936 module: ex-crypto-types-usage 937 +--rw symmetric-keys 938 | +--rw symmetric-key* [name] 939 | +--rw name string 940 | +--rw key-format? identityref 941 | +--rw (key-type) 942 | +--:(cleartext-key) 943 | | +--rw cleartext-key? binary 944 | +--:(hidden-key) 945 | | +--rw hidden-key? empty 946 | +--:(encrypted-key) {symmetric-key-encryption}? 947 | +--rw encrypted-key 948 | +--rw encrypted-by 949 | | +--rw (encrypted-by-choice) 950 | | +--:(symmetric-key-ref) 951 | | | +--rw symmetric-key-ref? leafref 952 | | +--:(asymmetric-key-ref) 953 | | +--rw asymmetric-key-ref? leafref 954 | +--rw encrypted-value-format identityref 955 | +--rw encrypted-value binary 956 +--rw asymmetric-keys 957 | +--rw asymmetric-key* [name] 958 | +--rw name string 959 | +--rw public-key-format identityref 960 | +--rw public-key binary 961 | +--rw private-key-format? identityref 962 | +--rw (private-key-type) 963 | | +--:(cleartext-private-key) 964 | | | +--rw cleartext-private-key? binary 965 | | +--:(hidden-private-key) 966 | | | +--rw hidden-private-key? empty 967 | | +--:(encrypted-private-key) {private-key-encryption}? 968 | | +--rw encrypted-private-key 969 | | +--rw encrypted-by 970 | | | +--rw (encrypted-by-choice) 971 | | | +--:(symmetric-key-ref) 972 | | | | +--rw symmetric-key-ref? leafref 973 | | | +--:(asymmetric-key-ref) 974 | | | +--rw asymmetric-key-ref? leafref 975 | | +--rw encrypted-value-format identityref 976 | | +--rw encrypted-value binary 977 | +--rw certificates 978 | | +--rw certificate* [name] 979 | | +--rw name string 980 | | +--rw cert-data end-entity-cert-cms 981 | | +---n certificate-expiration 982 | | {certificate-expiration-notification}? 983 | | +-- expiration-date yang:date-and-time 984 | +---x generate-certificate-signing-request 985 | {certificate-signing-request-generation}? 986 | +---w input 987 | | +---w csr-info ct:csr-info 988 | +--ro output 989 | +--ro certificate-signing-request ct:csr 990 +--rw passwords 991 +--rw password* [name] 992 +--rw name string 993 +--rw (password-type) 994 +--:(cleartext-password) 995 | +--rw cleartext-password? string 996 +--:(encrypted-password) {password-encryption}? 997 +--rw encrypted-password 998 +--rw encrypted-by 999 | +--rw (encrypted-by-choice) 1000 | +--:(symmetric-key-ref) 1001 | | +--rw symmetric-key-ref? leafref 1002 | +--:(asymmetric-key-ref) 1003 | +--rw asymmetric-key-ref? leafref 1004 +--rw encrypted-value-format identityref 1005 +--rw encrypted-value binary 1007 Finally, the following example illustrates various symmetric and 1008 asymmetric keys as they might appear in configration: 1010 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1012 1015 1016 ex-hidden-symmetric-key 1017 1018 1019 1020 ex-octet-string-based-symmetric-key 1021 ct:octet-string-key-format 1022 base64encodedvalue== 1023 1024 1025 ex-one-symmetric-based-symmetric-key 1026 ct:one-symmetric-key-format 1027 base64encodedvalue== 1028 1029 1030 ex-encrypted-one-symmetric-based-symmetric-key 1031 ct:one-symmetric-key-format 1032 1033 1034 ex-hidden-asymmetric-key 1036 1037 1038 ct:cms-enveloped-data-format 1039 1040 base64encodedvalue== 1041 1042 1043 1045 1048 1049 ex-hidden-asymmetric-key 1050 1051 ct:subject-public-key-info-format 1052 1053 base64encodedvalue== 1054 1055 1056 1057 ex-hidden-asymmetric-key-cert 1058 base64encodedvalue== 1059 1060 1061 1062 1063 ex-rsa-based-asymmetric-key 1064 1065 ct:subject-public-key-info-format 1066 1067 base64encodedvalue== 1068 1069 ct:rsa-private-key-format 1070 1071 base64encodedvalue== 1073 1074 1075 ex-cert 1076 base64encodedvalue== 1077 1078 1079 1080 1081 ex-one-asymmetric-based-asymmetric-key 1082 1083 ct:subject-public-key-info-format 1084 1085 base64encodedvalue== 1086 1087 ct:one-asymmetric-key-format 1088 1089 base64encodedvalue== 1091 1092 1093 ex-encrypted-rsa-based-asymmetric-key 1094 1095 ct:subject-public-key-info-format 1096 1097 base64encodedvalue== 1098 1099 ct:rsa-private-key-format 1100 1101 1102 1103 ex-encrypted-one-symmetric-based-symmetri\ 1104 c-key 1105 1106 1107 ct:cms-encrypted-data-format 1108 1109 base64encodedvalue== 1110 1111 1112 1114 1117 1118 ex-cleartext-password 1119 super-secret 1120 1121 1122 ex-encrypted-password 1123 1124 1125 ex-encrypted-one-symmetric-based-symmetri\ 1126 c-key 1127 1128 1129 ct:cms-encrypted-data-format 1130 1131 base64encodedvalue== 1132 1133 1134 1136 2.2.2. The "generate-certificate-signing-request" Action 1138 The following example illustrates the "generate-certificate-signing- 1139 request" action, discussed in Section 2.1.4.9, with the NETCONF 1140 protocol. 1142 REQUEST 1143 1145 1146 1148 1149 ex-key-sect571r1 1150 1151 base64encodedvalue== 1152 1153 1154 1155 1156 1158 RESPONSE 1160 1162 1164 base64encodedvalue== 1165 1166 1168 2.2.3. The "certificate-expiration" Notification 1170 The following example illustrates the "certificate-expiration" 1171 notification, discussed in Section 2.1.4.6, with the NETCONF 1172 protocol. 1174 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1176 1178 2018-05-25T00:01:00Z 1179 1181 1182 ex-hidden-asymmetric-key 1183 1184 1185 ex-hidden-asymmetric-key 1186 1187 2018-08-05T14:18:53-05:00 1189 1190 1191 1192 1193 1194 1196 2.3. YANG Module 1198 This module has normative references to [RFC2119], [RFC2986], 1199 [RFC3447], [RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], 1200 [RFC6031], [RFC6125], [RFC6991], [RFC7093], [RFC8174], [RFC8341], and 1201 [ITU.X690.2015]. 1203 file "ietf-crypto-types@2021-02-10.yang" 1205 module ietf-crypto-types { 1206 yang-version 1.1; 1207 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; 1208 prefix ct; 1210 import ietf-yang-types { 1211 prefix yang; 1212 reference 1213 "RFC 6991: Common YANG Data Types"; 1214 } 1216 import ietf-netconf-acm { 1217 prefix nacm; 1218 reference 1219 "RFC 8341: Network Configuration Access Control Model"; 1220 } 1221 organization 1222 "IETF NETCONF (Network Configuration) Working Group"; 1224 contact 1225 "WG Web: 1226 WG List: 1227 Author: Kent Watsen "; 1229 description 1230 "This module defines common YANG types for cryptographic 1231 applications. 1233 Copyright (c) 2020 IETF Trust and the persons identified 1234 as authors of the code. All rights reserved. 1236 Redistribution and use in source and binary forms, with 1237 or without modification, is permitted pursuant to, and 1238 subject to the license terms contained in, the Simplified 1239 BSD License set forth in Section 4.c of the IETF Trust's 1240 Legal Provisions Relating to IETF Documents 1241 (https://trustee.ietf.org/license-info). 1243 This version of this YANG module is part of RFC AAAA 1244 (https://www.rfc-editor.org/info/rfcAAAA); see the RFC 1245 itself for full legal notices. 1247 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1248 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1249 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1250 are to be interpreted as described in BCP 14 (RFC 2119) 1251 (RFC 8174) when, and only when, they appear in all 1252 capitals, as shown here."; 1254 revision 2021-02-10 { 1255 description 1256 "Initial version"; 1257 reference 1258 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 1259 } 1261 /****************/ 1262 /* Features */ 1263 /****************/ 1265 feature one-symmetric-key-format { 1266 description 1267 "Indicates that the server supports the 1268 'one-symmetric-key-format' identity."; 1269 } 1271 feature one-asymmetric-key-format { 1272 description 1273 "Indicates that the server supports the 1274 'one-asymmetric-key-format' identity."; 1275 } 1277 feature symmetrically-encrypted-value-format { 1278 description 1279 "Indicates that the server supports the 1280 'symmetrically-encrypted-value-format' identity."; 1281 } 1283 feature asymmetrically-encrypted-value-format { 1284 description 1285 "Indicates that the server supports the 1286 'asymmetrically-encrypted-value-format' identity."; 1287 } 1289 feature cms-enveloped-data-format { 1290 description 1291 "Indicates that the server supports the 1292 'cms-enveloped-data-format' identity."; 1293 } 1295 feature cms-encrypted-data-format { 1296 description 1297 "Indicates that the server supports the 1298 'cms-encrypted-data-format' identity."; 1299 } 1301 feature certificate-signing-request-generation { 1302 description 1303 "Indicates that the server implements the 1304 'generate-certificate-signing-request' action."; 1305 } 1307 feature certificate-expiration-notification { 1308 description 1309 "Indicates that the server implements the 1310 'certificate-expiration' notification."; 1311 } 1313 feature password-encryption { 1314 description 1315 "Indicates that the server supports password 1316 encryption."; 1317 } 1319 feature symmetric-key-encryption { 1320 description 1321 "Indicates that the server supports encryption 1322 of symmetric keys."; 1323 } 1325 feature private-key-encryption { 1326 description 1327 "Indicates that the server supports encryption 1328 of private keys."; 1329 } 1331 /*************************************************/ 1332 /* Base Identities for Key Format Structures */ 1333 /*************************************************/ 1335 identity symmetric-key-format { 1336 description "Base key-format identity for symmetric keys."; 1337 } 1339 identity public-key-format { 1340 description "Base key-format identity for public keys."; 1341 } 1343 identity private-key-format { 1344 description "Base key-format identity for private keys."; 1345 } 1347 /****************************************************/ 1348 /* Identities for Private Key Format Structures */ 1349 /****************************************************/ 1351 identity rsa-private-key-format { 1352 base "private-key-format"; 1353 description 1354 "Indicates that the private key value is encoded 1355 as an RSAPrivateKey (from RFC 3447)."; 1356 reference 1357 "RFC 3447: PKCS #1: RSA Cryptography 1358 Specifications Version 2.2"; 1359 } 1361 identity ec-private-key-format { 1362 base "private-key-format"; 1363 description 1364 "Indicates that the private key value is encoded 1365 as an ECPrivateKey (from RFC 5915)"; 1366 reference 1367 "RFC 5915: Elliptic Curve Private Key Structure"; 1368 } 1370 identity one-asymmetric-key-format { 1371 if-feature "one-asymmetric-key-format"; 1372 base "private-key-format"; 1373 description 1374 "Indicates that the private key value is a CMS 1375 OneAsymmetricKey structure, as defined in RFC 5958, 1376 encoded using ASN.1 distinguished encoding rules 1377 (DER), as specified in ITU-T X.690."; 1378 reference 1379 "RFC 5958: Asymmetric Key Packages 1380 ITU-T X.690: 1381 Information technology - ASN.1 encoding rules: 1382 Specification of Basic Encoding Rules (BER), 1383 Canonical Encoding Rules (CER) and Distinguished 1384 Encoding Rules (DER)."; 1385 } 1387 /***************************************************/ 1388 /* Identities for Public Key Format Structures */ 1389 /***************************************************/ 1391 identity ssh-public-key-format { 1392 base "public-key-format"; 1393 description 1394 "Indicates that the public key value is an SSH public key, 1395 as specified by RFC 4253, Section 6.6, i.e.: 1397 string certificate or public key format 1398 identifier 1399 byte[n] key/certificate data."; 1400 reference 1401 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 1402 } 1404 identity subject-public-key-info-format { 1405 base "public-key-format"; 1406 description 1407 "Indicates that the public key value is a SubjectPublicKeyInfo 1408 structure, as described in RFC 5280 encoded using ASN.1 1409 distinguished encoding rules (DER), as specified in 1410 ITU-T X.690."; 1412 reference 1413 "RFC 5280: 1414 Internet X.509 Public Key Infrastructure Certificate 1415 and Certificate Revocation List (CRL) Profile 1416 ITU-T X.690: 1417 Information technology - ASN.1 encoding rules: 1418 Specification of Basic Encoding Rules (BER), 1419 Canonical Encoding Rules (CER) and Distinguished 1420 Encoding Rules (DER)."; 1421 } 1423 /******************************************************/ 1424 /* Identities for Symmetric Key Format Structures */ 1425 /******************************************************/ 1427 identity octet-string-key-format { 1428 base "symmetric-key-format"; 1429 description 1430 "Indicates that the key is encoded as a raw octet string. 1431 The length of the octet string MUST be appropriate for 1432 the associated algorithm's block size. 1434 How the associated algorithm is known is outside the 1435 scope of this module. This statement also applies when 1436 the octet string has been encrypted."; 1437 } 1439 identity one-symmetric-key-format { 1440 if-feature "one-symmetric-key-format"; 1441 base "symmetric-key-format"; 1442 description 1443 "Indicates that the private key value is a CMS 1444 OneSymmetricKey structure, as defined in RFC 6031, 1445 encoded using ASN.1 distinguished encoding rules 1446 (DER), as specified in ITU-T X.690."; 1447 reference 1448 "RFC 6031: Cryptographic Message Syntax (CMS) 1449 Symmetric Key Package Content Type 1450 ITU-T X.690: 1451 Information technology - ASN.1 encoding rules: 1452 Specification of Basic Encoding Rules (BER), 1453 Canonical Encoding Rules (CER) and Distinguished 1454 Encoding Rules (DER)."; 1455 } 1457 /*************************************************/ 1458 /* Identities for Encrytped Value Structures */ 1459 /*************************************************/ 1461 identity encrypted-value-format { 1462 description 1463 "Base format identity for encrypted values."; 1464 } 1466 identity symmetrically-encrypted-value-format { 1467 if-feature "symmetrically-encrypted-value-format"; 1468 base "encrypted-value-format"; 1469 description 1470 "Base format identity for symmetrically encrypted 1471 values."; 1472 } 1474 identity asymmetrically-encrypted-value-format { 1475 if-feature "asymmetrically-encrypted-value-format"; 1476 base "encrypted-value-format"; 1477 description 1478 "Base format identity for asymmetrically encrypted 1479 values."; 1480 } 1482 identity cms-encrypted-data-format { 1483 if-feature "cms-encrypted-data-format"; 1484 base "symmetrically-encrypted-value-format"; 1485 description 1486 "Indicates that the encrypted value conforms to 1487 the 'encrypted-data-cms' type with the constraint 1488 that the 'unprotectedAttrs' value is not set."; 1489 reference 1490 "RFC 5652: Cryptographic Message Syntax (CMS) 1491 ITU-T X.690: 1492 Information technology - ASN.1 encoding rules: 1493 Specification of Basic Encoding Rules (BER), 1494 Canonical Encoding Rules (CER) and Distinguished 1495 Encoding Rules (DER)."; 1496 } 1498 identity cms-enveloped-data-format { 1499 if-feature "cms-enveloped-data-format"; 1500 base "asymmetrically-encrypted-value-format"; 1501 description 1502 "Indicates that the encrypted value conforms to the 1503 'enveloped-data-cms' type with the following constraints: 1505 The EnvelopedData structure MUST have exactly one 1506 'RecipientInfo'. 1508 If the asymmetric key supports public key cryptography 1509 (e.g., RSA), then the 'RecipientInfo' must be a 1510 'KeyTransRecipientInfo' with the 'RecipientIdentifier' 1511 using a 'subjectKeyIdentifier' with the value set using 1512 'method 1' in RFC 7093 over the recipient's public key. 1514 Otherwise, if the asymmetric key supports key agreement 1515 (e.g., ECC), then the 'RecipientInfo' must be a 1516 'KeyAgreeRecipientInfo'. The 'OriginatorIdentifierOrKey' 1517 value must use the 'OriginatorPublicKey' alternative. 1518 The 'UserKeyingMaterial' value must not be present. 1519 There must be exactly one 'RecipientEncryptedKeys' value 1520 having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' 1521 with the value set using 'method 1' in RFC 7093 over the 1522 recipient's public key."; 1523 reference 1524 "RFC 5652: Cryptographic Message Syntax (CMS) 1525 RFC 7093: 1526 Additional Methods for Generating Key 1527 Identifiers Values 1528 ITU-T X.690: 1529 Information technology - ASN.1 encoding rules: 1530 Specification of Basic Encoding Rules (BER), 1531 Canonical Encoding Rules (CER) and Distinguished 1532 Encoding Rules (DER)."; 1533 } 1535 /***************************************************/ 1536 /* Typedefs for ASN.1 structures from RFC 2986 */ 1537 /***************************************************/ 1539 typedef csr-info { 1540 type binary; 1541 description 1542 "A CertificationRequestInfo structure, as defined in 1543 RFC 2986, encoded using ASN.1 distinguished encoding 1544 rules (DER), as specified in ITU-T X.690."; 1545 reference 1546 "RFC 2986: PKCS #10: Certification Request Syntax 1547 Specification Version 1.7 1548 ITU-T X.690: 1549 Information technology - ASN.1 encoding rules: 1550 Specification of Basic Encoding Rules (BER), 1551 Canonical Encoding Rules (CER) and Distinguished 1552 Encoding Rules (DER)."; 1553 } 1555 typedef csr { 1556 type binary; 1557 description 1558 "A CertificationRequest structure, as specified in 1559 RFC 2986, encoded using ASN.1 distinguished encoding 1560 rules (DER), as specified in ITU-T X.690."; 1561 reference 1562 "RFC 2986: 1563 PKCS #10: Certification Request Syntax Specification 1564 Version 1.7 1565 ITU-T X.690: 1566 Information technology - ASN.1 encoding rules: 1567 Specification of Basic Encoding Rules (BER), 1568 Canonical Encoding Rules (CER) and Distinguished 1569 Encoding Rules (DER)."; 1570 } 1572 /***************************************************/ 1573 /* Typedefs for ASN.1 structures from RFC 5280 */ 1574 /***************************************************/ 1576 typedef x509 { 1577 type binary; 1578 description 1579 "A Certificate structure, as specified in RFC 5280, 1580 encoded using ASN.1 distinguished encoding rules (DER), 1581 as specified in ITU-T X.690."; 1582 reference 1583 "RFC 5280: 1584 Internet X.509 Public Key Infrastructure Certificate 1585 and Certificate Revocation List (CRL) Profile 1586 ITU-T X.690: 1587 Information technology - ASN.1 encoding rules: 1588 Specification of Basic Encoding Rules (BER), 1589 Canonical Encoding Rules (CER) and Distinguished 1590 Encoding Rules (DER)."; 1591 } 1593 typedef crl { 1594 type binary; 1595 description 1596 "A CertificateList structure, as specified in RFC 5280, 1597 encoded using ASN.1 distinguished encoding rules (DER), 1598 as specified in ITU-T X.690."; 1599 reference 1600 "RFC 5280: 1601 Internet X.509 Public Key Infrastructure Certificate 1602 and Certificate Revocation List (CRL) Profile 1603 ITU-T X.690: 1605 Information technology - ASN.1 encoding rules: 1606 Specification of Basic Encoding Rules (BER), 1607 Canonical Encoding Rules (CER) and Distinguished 1608 Encoding Rules (DER)."; 1609 } 1611 /***************************************************/ 1612 /* Typedefs for ASN.1 structures from RFC 6960 */ 1613 /***************************************************/ 1615 typedef oscp-request { 1616 type binary; 1617 description 1618 "A OCSPRequest structure, as specified in RFC 6960, 1619 encoded using ASN.1 distinguished encoding rules 1620 (DER), as specified in ITU-T X.690."; 1621 reference 1622 "RFC 6960: 1623 X.509 Internet Public Key Infrastructure Online 1624 Certificate Status Protocol - OCSP 1625 ITU-T X.690: 1626 Information technology - ASN.1 encoding rules: 1627 Specification of Basic Encoding Rules (BER), 1628 Canonical Encoding Rules (CER) and Distinguished 1629 Encoding Rules (DER)."; 1630 } 1632 typedef oscp-response { 1633 type binary; 1634 description 1635 "A OCSPResponse structure, as specified in RFC 6960, 1636 encoded using ASN.1 distinguished encoding rules 1637 (DER), as specified in ITU-T X.690."; 1638 reference 1639 "RFC 6960: 1640 X.509 Internet Public Key Infrastructure Online 1641 Certificate Status Protocol - OCSP 1642 ITU-T X.690: 1643 Information technology - ASN.1 encoding rules: 1644 Specification of Basic Encoding Rules (BER), 1645 Canonical Encoding Rules (CER) and Distinguished 1646 Encoding Rules (DER)."; 1647 } 1649 /***********************************************/ 1650 /* Typedefs for ASN.1 structures from 5652 */ 1651 /***********************************************/ 1653 typedef cms { 1654 type binary; 1655 description 1656 "A ContentInfo structure, as specified in RFC 5652, 1657 encoded using ASN.1 distinguished encoding rules (DER), 1658 as specified in ITU-T X.690."; 1659 reference 1660 "RFC 5652: 1661 Cryptographic Message Syntax (CMS) 1662 ITU-T X.690: 1663 Information technology - ASN.1 encoding rules: 1664 Specification of Basic Encoding Rules (BER), 1665 Canonical Encoding Rules (CER) and Distinguished 1666 Encoding Rules (DER)."; 1667 } 1669 typedef data-content-cms { 1670 type cms; 1671 description 1672 "A CMS structure whose top-most content type MUST be the 1673 data content type, as described by Section 4 in RFC 5652."; 1674 reference 1675 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1676 } 1678 typedef signed-data-cms { 1679 type cms; 1680 description 1681 "A CMS structure whose top-most content type MUST be the 1682 signed-data content type, as described by Section 5 in 1683 RFC 5652."; 1684 reference 1685 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1686 } 1688 typedef enveloped-data-cms { 1689 type cms; 1690 description 1691 "A CMS structure whose top-most content type MUST be the 1692 enveloped-data content type, as described by Section 6 1693 in RFC 5652."; 1694 reference 1695 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1696 } 1698 typedef digested-data-cms { 1699 type cms; 1700 description 1701 "A CMS structure whose top-most content type MUST be the 1702 digested-data content type, as described by Section 7 1703 in RFC 5652."; 1704 reference 1705 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1706 } 1708 typedef encrypted-data-cms { 1709 type cms; 1710 description 1711 "A CMS structure whose top-most content type MUST be the 1712 encrypted-data content type, as described by Section 8 1713 in RFC 5652."; 1714 reference 1715 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1716 } 1718 typedef authenticated-data-cms { 1719 type cms; 1720 description 1721 "A CMS structure whose top-most content type MUST be the 1722 authenticated-data content type, as described by Section 9 1723 in RFC 5652."; 1724 reference 1725 "RFC 5652: Cryptographic Message Syntax (CMS)"; 1726 } 1728 /*********************************************************/ 1729 /* Typedefs for ASN.1 structures related to RFC 5280 */ 1730 /*********************************************************/ 1732 typedef trust-anchor-cert-x509 { 1733 type x509; 1734 description 1735 "A Certificate structure that MUST encode a self-signed 1736 root certificate."; 1737 } 1739 typedef end-entity-cert-x509 { 1740 type x509; 1741 description 1742 "A Certificate structure that MUST encode a certificate 1743 that is neither self-signed nor having Basic constraint 1744 CA true."; 1745 } 1746 /*********************************************************/ 1747 /* Typedefs for ASN.1 structures related to RFC 5652 */ 1748 /*********************************************************/ 1750 typedef trust-anchor-cert-cms { 1751 type signed-data-cms; 1752 description 1753 "A CMS SignedData structure that MUST contain the chain of 1754 X.509 certificates needed to authenticate the certificate 1755 presented by a client or end-entity. 1757 The CMS MUST contain only a single chain of certificates. 1758 The client or end-entity certificate MUST only authenticate 1759 to last intermediate CA certificate listed in the chain. 1761 In all cases, the chain MUST include a self-signed root 1762 certificate. In the case where the root certificate is 1763 itself the issuer of the client or end-entity certificate, 1764 only one certificate is present. 1766 This CMS structure MAY (as applicable where this type is 1767 used) also contain suitably fresh (as defined by local 1768 policy) revocation objects with which the device can 1769 verify the revocation status of the certificates. 1771 This CMS encodes the degenerate form of the SignedData 1772 structure that is commonly used to disseminate X.509 1773 certificates and revocation objects (RFC 5280)."; 1774 reference 1775 "RFC 5280: 1776 Internet X.509 Public Key Infrastructure Certificate 1777 and Certificate Revocation List (CRL) Profile."; 1778 } 1780 typedef end-entity-cert-cms { 1781 type signed-data-cms; 1782 description 1783 "A CMS SignedData structure that MUST contain the end 1784 entity certificate itself, and MAY contain any number 1785 of intermediate certificates leading up to a trust 1786 anchor certificate. The trust anchor certificate 1787 MAY be included as well. 1789 The CMS MUST contain a single end entity certificate. 1790 The CMS MUST NOT contain any spurious certificates. 1792 This CMS structure MAY (as applicable where this type is 1793 used) also contain suitably fresh (as defined by local 1794 policy) revocation objects with which the device can 1795 verify the revocation status of the certificates. 1797 This CMS encodes the degenerate form of the SignedData 1798 structure that is commonly used to disseminate X.509 1799 certificates and revocation objects (RFC 5280)."; 1800 reference 1801 "RFC 5280: 1802 Internet X.509 Public Key Infrastructure Certificate 1803 and Certificate Revocation List (CRL) Profile."; 1804 } 1806 /*****************/ 1807 /* Groupings */ 1808 /*****************/ 1810 grouping encrypted-value-grouping { 1811 description 1812 "A reusable grouping for a value that has been encrypted by 1813 a symmetric or asymmetric key in the Keystore."; 1814 container encrypted-by { 1815 nacm:default-deny-write; 1816 description 1817 "An empty container enabling a reference to the key that 1818 encrypted the value to be augmented in. The referenced 1819 key MUST be a symmetric key or an asymmetric key. 1821 A symmetric key MUST be referenced via a leaf node called 1822 'symmetric-key-ref'. An asymmetric key MUST be referenced 1823 via a leaf node called 'asymmetric-key-ref'. 1825 The leaf nodes MUST be direct descendents in the data tree, 1826 and MAY be direct descendents in the schema tree."; 1827 } 1828 leaf encrypted-value-format { 1829 type identityref { 1830 base encrypted-value-format; 1831 } 1832 mandatory true; 1833 description 1834 "Identifies the format of the 'encrypted-value' leaf. 1836 If 'encrypted-by' points to a symmetric key, then a 1837 'symmetrically-encrypted-value-format' based identity 1838 MUST by set (e.g., cms-encrypted-data-format). 1840 If 'encrypted-by' points to an asymmetric key, then an 1841 'asymmetrically-encrypted-value-format' based identity 1842 MUST by set (e.g., cms-enveloped-data-format)."; 1843 } 1844 leaf encrypted-value { 1845 nacm:default-deny-write; 1846 type binary; 1847 must "../encrypted-by"; 1848 mandatory true; 1849 description 1850 "The value, encrypted using the referenced symmetric 1851 or asymmetric key. The value MUST be encoded using 1852 the format associated with the 'encrypted-value-format' 1853 leaf."; 1854 } 1855 } 1857 grouping password-grouping { 1858 description 1859 "A password that MAY be encrypted."; 1860 choice password-type { 1861 nacm:default-deny-write; 1862 mandatory true; 1863 description 1864 "Choice between password types."; 1865 case cleartext-password { 1866 leaf cleartext-password { 1867 nacm:default-deny-all; 1868 type string; 1869 description 1870 "The cleartext value of the password."; 1871 } 1872 } 1873 case encrypted-password { 1874 if-feature password-encryption; 1875 container encrypted-password { 1876 description 1877 "A container for the encrypted password value."; 1878 uses encrypted-value-grouping; 1879 } 1880 } 1881 } 1882 } 1884 grouping symmetric-key-grouping { 1885 description 1886 "A symmetric key."; 1887 leaf key-format { 1888 nacm:default-deny-write; 1889 type identityref { 1890 base symmetric-key-format; 1891 } 1892 description 1893 "Identifies the symmetric key's format. Implementations 1894 SHOULD ensure that the incoming symmetric key value is 1895 encoded in the specified format. 1897 For encrypted keys, the value is the same as it would 1898 have been if the key were not encrypted."; 1899 } 1900 choice key-type { 1901 nacm:default-deny-write; 1902 mandatory true; 1903 description 1904 "Choice between key types."; 1905 case cleartext-key { 1906 leaf cleartext-key { 1907 nacm:default-deny-all; 1908 type binary; 1909 must "../key-format"; 1910 description 1911 "The binary value of the key. The interpretation of 1912 the value is defined by the 'key-format' field."; 1913 } 1914 } 1915 case hidden-key { 1916 leaf hidden-key { 1917 type empty; 1918 must "not(../key-format)"; 1919 description 1920 "A hidden key. How such keys are created is outside 1921 the scope of this module."; 1922 } 1923 } 1924 case encrypted-key { 1925 if-feature symmetric-key-encryption; 1926 container encrypted-key { 1927 must "../key-format"; 1928 description 1929 "A container for the encrypted symmetric key value. 1930 The interpretation of the 'encrypted-value' node 1931 is via the 'key-format' node"; 1932 uses encrypted-value-grouping; 1933 } 1934 } 1935 } 1936 } 1937 grouping public-key-grouping { 1938 description 1939 "A public key."; 1940 leaf public-key-format { 1941 nacm:default-deny-write; 1942 type identityref { 1943 base public-key-format; 1944 } 1945 mandatory true; 1946 description 1947 "Identifies the public key's format. Implementations SHOULD 1948 ensure that the incoming public key value is encoded in the 1949 specified format."; 1950 } 1951 leaf public-key { 1952 nacm:default-deny-write; 1953 type binary; 1954 mandatory true; 1955 description 1956 "The binary value of the public key. The interpretation 1957 of the value is defined by 'public-key-format' field."; 1958 } 1959 } 1961 grouping asymmetric-key-pair-grouping { 1962 description 1963 "A private key and its associated public key. Implementations 1964 SHOULD ensure that the two keys are a matching pair."; 1965 uses public-key-grouping; 1966 leaf private-key-format { 1967 nacm:default-deny-write; 1968 type identityref { 1969 base private-key-format; 1970 } 1971 description 1972 "Identifies the private key's format. Implementations SHOULD 1973 ensure that the incoming private key value is encoded in the 1974 specified format. 1976 For encrypted keys, the value is the same as it would have 1977 been if the key were not encrypted."; 1978 } 1979 choice private-key-type { 1980 nacm:default-deny-write; 1981 mandatory true; 1982 description 1983 "Choice between key types."; 1984 case cleartext-private-key { 1985 leaf cleartext-private-key { 1986 nacm:default-deny-all; 1987 type binary; 1988 must "../private-key-format"; 1989 description 1990 "The value of the binary key The key's value is 1991 interpreted by the 'private-key-format' field."; 1992 } 1993 } 1994 case hidden-private-key { 1995 leaf hidden-private-key { 1996 type empty; 1997 must "not(../private-key-format)"; 1998 description 1999 "A hidden key. How such keys are created is 2000 outside the scope of this module."; 2001 } 2002 } 2003 case encrypted-private-key { 2004 if-feature private-key-encryption; 2005 container encrypted-private-key { 2006 must "../private-key-format"; 2007 description 2008 "A container for the encrypted asymmetric private key 2009 value. The interpretation of the 'encrypted-value' 2010 node is via the 'private-key-format' node"; 2011 uses encrypted-value-grouping; 2012 } 2013 } 2014 } 2015 } 2017 grouping certificate-expiration-grouping { 2018 description 2019 "A notification for when a certificate is about to, or 2020 already has, expired."; 2021 notification certificate-expiration { 2022 if-feature certificate-expiration-notification; 2023 description 2024 "A notification indicating that the configured certificate 2025 is either about to expire or has already expired. When to 2026 send notifications is an implementation specific decision, 2027 but it is RECOMMENDED that a notification be sent once a 2028 month for 3 months, then once a week for four weeks, and 2029 then once a day thereafter until the issue is resolved."; 2030 leaf expiration-date { 2031 type yang:date-and-time; 2032 mandatory true; 2033 description 2034 "Identifies the expiration date on the certificate."; 2035 } 2036 } 2037 } 2039 grouping trust-anchor-cert-grouping { 2040 description 2041 "A trust anchor certificate, and a notification for when 2042 it is about to (or already has) expire."; 2043 leaf cert-data { 2044 nacm:default-deny-write; 2045 type trust-anchor-cert-cms; 2046 description 2047 "The binary certificate data for this certificate."; 2048 } 2049 uses certificate-expiration-grouping; 2050 } 2052 grouping end-entity-cert-grouping { 2053 description 2054 "An end entity certificate, and a notification for when 2055 it is about to (or already has) expire. Implementations 2056 SHOULD assert that, where used, the end entity certificate 2057 contains the expected public key."; 2058 leaf cert-data { 2059 nacm:default-deny-write; 2060 type end-entity-cert-cms; 2061 description 2062 "The binary certificate data for this certificate."; 2063 } 2064 uses certificate-expiration-grouping; 2065 } 2067 grouping generate-csr-grouping { 2068 description 2069 "Defines the 'generate-certificate-signing-request' action."; 2070 action generate-certificate-signing-request { 2071 if-feature certificate-signing-request-generation; 2072 nacm:default-deny-all; 2073 description 2074 "Generates a certificate signing request structure for 2075 the associated asymmetric key using the passed subject 2076 and attribute values. 2078 This action statement is only available when the 2079 associated 'public-key-format' node's value is 2080 'subject-public-key-info-format'."; 2082 reference 2083 "RFC 6125: 2084 Representation and Verification of Domain-Based 2085 Application Service Identity within Internet Public Key 2086 Infrastructure Using X.509 (PKIX) Certificates in the 2087 Context of Transport Layer Security (TLS)"; 2088 input { 2089 leaf csr-info { 2090 type ct:csr-info; 2091 mandatory true; 2092 description 2093 "A CertificationRequestInfo structure, as defined in 2094 RFC 2986. 2096 Enables the client to provide a fully-populated 2097 CertificationRequestInfo structure that the server 2098 only needs to sign in order to generate the complete 2099 'CertificationRequest' structure to return in the 2100 'output'. 2102 The 'AlgorithmIdentifier' field contained inside 2103 the 'SubjectPublicKeyInfo' field MUST be one known 2104 to be supported by the device."; 2105 reference 2106 "RFC 2986: 2107 PKCS #10: Certification Request Syntax Specification 2108 RFC AAAA: 2109 YANG Data Types and Groupings for Cryptography"; 2110 } 2111 } 2112 output { 2113 leaf certificate-signing-request { 2114 type ct:csr; 2115 mandatory true; 2116 description 2117 "A CertificationRequest structure, as defined in 2118 RFC 2986."; 2119 reference 2120 "RFC 2986: 2121 PKCS #10: Certification Request Syntax Specification 2122 RFC AAAA: 2123 YANG Data Types and Groupings for Cryptography"; 2124 } 2125 } 2126 } 2127 } // generate-csr-grouping 2129 grouping asymmetric-key-pair-with-cert-grouping { 2130 description 2131 "A private/public key pair and an associated certificate. 2132 Implementations SHOULD assert that certificates contain 2133 the matching public key."; 2134 uses asymmetric-key-pair-grouping; 2135 uses end-entity-cert-grouping; 2136 uses generate-csr-grouping; 2137 } // asymmetric-key-pair-with-cert-grouping 2139 grouping asymmetric-key-pair-with-certs-grouping { 2140 description 2141 "A private/public key pair and associated certificates. 2142 Implementations SHOULD assert that certificates contain 2143 the matching public key."; 2144 uses asymmetric-key-pair-grouping; 2145 container certificates { 2146 nacm:default-deny-write; 2147 description 2148 "Certificates associated with this asymmetric key."; 2149 list certificate { 2150 key "name"; 2151 description 2152 "A certificate for this asymmetric key."; 2153 leaf name { 2154 type string; 2155 description 2156 "An arbitrary name for the certificate."; 2157 } 2158 uses end-entity-cert-grouping { 2159 refine cert-data { 2160 mandatory true; 2161 } 2162 } 2163 } 2164 } 2165 uses generate-csr-grouping; 2166 } // asymmetric-key-pair-with-certs-grouping 2168 } 2170 2172 3. Security Considerations 2173 3.1. No Support for CRMF 2175 This document uses PKCS #10 [RFC2986] for the "generate-certificate- 2176 signing-request" action. The use of Certificate Request Message 2177 Format (CRMF) [RFC4211] was considered, but it was unclear if there 2178 was market demand for it. If it is desired to support CRMF in the 2179 future, a backwards compatible solution can be defined at that time. 2181 3.2. No Support for Key Generation 2183 Early revisions of this document included "rpc" statements for 2184 generating symmetric and asymmetric keys. There statements were 2185 removed due to an inability to obtain consensus for how to identify 2186 the key-algorithm to use. Thusly, the solution presented in this 2187 document only supports keys to be configured via an external client, 2188 which does not support Security best practice. 2190 3.3. Unconstrained Public Key Usage 2192 This module defines the "public-key-grouping" grouping, which enables 2193 the configuration of public keys without constraints on their usage, 2194 e.g., what operations the key is allowed to be used for (encryption, 2195 verification, both). 2197 The "asymmetric-key-pair-grouping" grouping uses the aforementioned 2198 "public-key-grouping" grouping, and carries the same traits. 2200 The "asymmetric-key-pair-with-cert-grouping" grouping uses the 2201 aforementioned "asymmetric-key-pair-grouping" grouping, whereby each 2202 certificate may constrain the usage of the public key according to 2203 local policy. 2205 3.4. Unconstrained Private Key Usage 2207 This module defines the "asymmetric-key-pair-grouping" grouping, 2208 which enables the configuration of private keys without constraints 2209 on their usage, e.g., what operations the key is allowed to be used 2210 for (e.g., signature, decryption, both). 2212 The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned 2213 "asymmetric-key-pair-grouping" grouping, whereby configured 2214 certificates (e.g., identity certificates) may constrain the use of 2215 the public key according to local policy. 2217 3.5. Strength of Keys Configured 2219 When configuring key values, implementations SHOULD ensure that the 2220 strength of the key being configured is not greater than the strength 2221 of the underlying secure transport connection over which it is 2222 communicated. Implementations SHOULD fail the write-request if ever 2223 the strength of the private key is greater then the strength of the 2224 underlying transport. 2226 3.6. Encrypting Passwords 2228 The module contained within this document enables passwords to be 2229 encrypted. Passwords may be encrypted via a symmetric key using the 2230 "cms-encrypted-data-format" format. This format uses the CMS 2231 EncryptedData structure, which allows any encryption algorithm to be 2232 used. 2234 In order to thrawt rainbow attacks, algorithms that result in a 2235 unique output for the same input SHOULD be used. For instance, AES 2236 using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" 2237 mode is okay since it a unique initialization vector (IV) should be 2238 used for each run. 2240 3.7. Deletion of Cleartext Key Values 2242 This module defines storage for cleartext key values that SHOULD be 2243 zeroized when deleted, so as to prevent the remnants of their 2244 persisted storage locations from being analyzed in any meaningful 2245 way. 2247 The cleartext key values are the "cleartext-key" node defined in the 2248 "symmetric-key-grouping" grouping (Section 2.1.4.3) and the 2249 "cleartext-private-key" node defined in the "asymmetric-key-pair- 2250 grouping" grouping ("Section 2.1.4.5). 2252 3.8. The "ietf-crypto-types" YANG Module 2254 The YANG module in this document defines "grouping" statements that 2255 are designed to be accessed via YANG based management protocols, such 2256 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 2257 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 2258 with mutual authentication. 2260 The NETCONF access control model (NACM) [RFC8341] provides the means 2261 to restrict access for particular users to a pre-configured subset of 2262 all available protocol operations and content. 2264 Since the module in this document only define groupings, these 2265 considerations are primarily for the designers of other modules that 2266 use these groupings. 2268 Some of the readable data nodes defined in this YANG module may be 2269 considered sensitive or vulnerable in some network environments. It 2270 is thus important to control read access (e.g., via get, get-config, 2271 or notification) to these data nodes. These are the subtrees and 2272 data nodes and their sensitivity/vulnerability: 2274 * The "cleartext-key" node: 2276 The "cleartext-key" node defined in the "symmetric-key- 2277 grouping" grouping is additionally sensitive to read operations 2278 such that, in normal use cases, it should never be returned to 2279 a client. For this reason, the NACM extension "default-deny- 2280 all" has been applied to it. 2282 * The "cleartext-private-key" node: 2284 The "cleartext-private-key" node defined in the "asymmetric- 2285 key-pair-grouping" grouping is additionally sensitive to read 2286 operations such that, in normal use cases, it should never be 2287 returned to a client. For this reason, the NACM extension 2288 "default-deny-all" has been applied. 2290 All of the writable data nodes defined by all the groupings defined 2291 in this module may be considered sensitive or vulnerable in some 2292 network environments. For instance, even the modification of a 2293 public key or a certificate can dramatically alter the implemented 2294 security policy. For this reason, the NACM extension "default-deny- 2295 write" has been applied to all the data nodes defined in the module. 2297 Some of the operations in this YANG module may be considered 2298 sensitive or vulnerable in some network environments. It is thus 2299 important to control access to these operations. These are the 2300 operations and their sensitivity/vulnerability: 2302 * generate-certificate-signing-request: 2304 This "action" statement SHOULD only be executed by authorized 2305 users. For this reason, the NACM extension "default-deny-all" 2306 has been applied. Note that NACM uses "default-deny-all" to 2307 protect "RPC" and "action" statements; it does not define, 2308 e.g., an extension called "default-deny-execute". 2310 For this action, it is RECOMMENDED that implementations assert 2311 channel binding [RFC5056], so as to ensure that the application 2312 layer that sent the request is the same as the device 2313 authenticated when the secure transport layer was established. 2315 4. IANA Considerations 2317 4.1. The "IETF XML" Registry 2319 This document registers one URI in the "ns" subregistry of the "IETF 2320 XML" registry [RFC3688]. Following the format in [RFC3688], the 2321 following registration is requested: 2323 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2324 Registrant Contact: The IESG 2325 XML: N/A, the requested URI is an XML namespace. 2327 4.2. The "YANG Module Names" Registry 2329 This document registers one YANG module in the "YANG Module Names" 2330 registry [RFC6020]. Following the format in [RFC6020], the following 2331 registration is requested: 2333 name: ietf-crypto-types 2334 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types 2335 prefix: ct 2336 reference: RFC AAAA 2338 5. References 2340 5.1. Normative References 2342 [ITU.X680.2015] 2343 International Telecommunication Union, "Information 2344 technology - Abstract Syntax Notation One (ASN.1): 2345 Specification of basic notation", ITU-T Recommendation 2346 X.680, ISO/IEC 8824-1:2015, August 2015, 2347 . 2349 [ITU.X690.2015] 2350 International Telecommunication Union, "Information 2351 Technology - ASN.1 encoding rules: Specification of Basic 2352 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2353 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2354 X.690, ISO/IEC 8825-1:2015, August 2015, 2355 . 2357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2358 Requirement Levels", BCP 14, RFC 2119, 2359 DOI 10.17487/RFC2119, March 1997, 2360 . 2362 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2363 Standards (PKCS) #1: RSA Cryptography Specifications 2364 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2365 2003, . 2367 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2368 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2369 January 2006, . 2371 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2372 Housley, R., and W. Polk, "Internet X.509 Public Key 2373 Infrastructure Certificate and Certificate Revocation List 2374 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2375 . 2377 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2378 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2379 . 2381 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 2382 DOI 10.17487/RFC5958, August 2010, 2383 . 2385 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2386 (CMS) Symmetric Key Package Content Type", RFC 6031, 2387 DOI 10.17487/RFC6031, December 2010, 2388 . 2390 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2391 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2392 . 2394 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 2395 for Generating Key Identifiers Values", RFC 7093, 2396 DOI 10.17487/RFC7093, December 2013, 2397 . 2399 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2400 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2401 . 2403 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2404 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2405 May 2017, . 2407 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2408 Access Control Model", STD 91, RFC 8341, 2409 DOI 10.17487/RFC8341, March 2018, 2410 . 2412 5.2. Informative References 2414 [I-D.ietf-netconf-crypto-types] 2415 Watsen, K., "YANG Data Types and Groupings for 2416 Cryptography", Work in Progress, Internet-Draft, draft- 2417 ietf-netconf-crypto-types-18, 20 August 2020, 2418 . 2421 [I-D.ietf-netconf-http-client-server] 2422 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 2423 Servers", Work in Progress, Internet-Draft, draft-ietf- 2424 netconf-http-client-server-05, 20 August 2020, 2425 . 2428 [I-D.ietf-netconf-keystore] 2429 Watsen, K., "A YANG Data Model for a Keystore", Work in 2430 Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 2431 20 August 2020, . 2434 [I-D.ietf-netconf-netconf-client-server] 2435 Watsen, K., "NETCONF Client and Server Models", Work in 2436 Progress, Internet-Draft, draft-ietf-netconf-netconf- 2437 client-server-21, 20 August 2020, 2438 . 2441 [I-D.ietf-netconf-restconf-client-server] 2442 Watsen, K., "RESTCONF Client and Server Models", Work in 2443 Progress, Internet-Draft, draft-ietf-netconf-restconf- 2444 client-server-21, 20 August 2020, 2445 . 2448 [I-D.ietf-netconf-ssh-client-server] 2449 Watsen, K., "YANG Groupings for SSH Clients and SSH 2450 Servers", Work in Progress, Internet-Draft, draft-ietf- 2451 netconf-ssh-client-server-22, 20 August 2020, 2452 . 2455 [I-D.ietf-netconf-tcp-client-server] 2456 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 2457 and TCP Servers", Work in Progress, Internet-Draft, draft- 2458 ietf-netconf-tcp-client-server-08, 20 August 2020, 2459 . 2462 [I-D.ietf-netconf-tls-client-server] 2463 Watsen, K., "YANG Groupings for TLS Clients and TLS 2464 Servers", Work in Progress, Internet-Draft, draft-ietf- 2465 netconf-tls-client-server-22, 20 August 2020, 2466 . 2469 [I-D.ietf-netconf-trust-anchors] 2470 Watsen, K., "A YANG Data Model for a Truststore", Work in 2471 Progress, Internet-Draft, draft-ietf-netconf-trust- 2472 anchors-13, 20 August 2020, . 2475 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2476 Request Syntax Specification Version 1.7", RFC 2986, 2477 DOI 10.17487/RFC2986, November 2000, 2478 . 2480 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2481 DOI 10.17487/RFC3688, January 2004, 2482 . 2484 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2485 Certificate Request Message Format (CRMF)", RFC 4211, 2486 DOI 10.17487/RFC4211, September 2005, 2487 . 2489 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2490 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2491 . 2493 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 2494 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 2495 . 2497 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2498 the Network Configuration Protocol (NETCONF)", RFC 6020, 2499 DOI 10.17487/RFC6020, October 2010, 2500 . 2502 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2503 Verification of Domain-Based Application Service Identity 2504 within Internet Public Key Infrastructure Using X.509 2505 (PKIX) Certificates in the Context of Transport Layer 2506 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2507 2011, . 2509 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2510 and A. Bierman, Ed., "Network Configuration Protocol 2511 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2512 . 2514 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2515 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2516 . 2518 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2519 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2520 . 2522 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2523 and R. Wilton, "Network Management Datastore Architecture 2524 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2525 . 2527 Appendix A. Change Log 2529 This section is to be removed before publishing as an RFC. 2531 A.1. I-D to 00 2533 * Removed groupings and notifications. 2535 * Added typedefs for identityrefs. 2537 * Added typedefs for other RFC 5280 structures. 2539 * Added typedefs for other RFC 5652 structures. 2541 * Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. 2543 A.2. 00 to 01 2544 * Moved groupings from the draft-ietf-netconf-keystore here. 2546 A.3. 01 to 02 2548 * Removed unwanted "mandatory" and "must" statements. 2550 * Added many new crypto algorithms (thanks Haiguang!) 2552 * Clarified in asymmetric-key-pair-with-certs-grouping, in 2553 certificates/certificate/name/description, that if the name MUST 2554 NOT match the name of a certificate that exists independently in 2555 , enabling certs installed by the manufacturer (e.g., 2556 an IDevID). 2558 A.4. 02 to 03 2560 * renamed base identity 'asymmetric-key-encryption-algorithm' to 2561 'asymmetric-key-algorithm'. 2563 * added new 'asymmetric-key-algorithm' identities for secp192r1, 2564 secp224r1, secp256r1, secp384r1, and secp521r1. 2566 * removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- 2567 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- 2568 aes-256-gcm, and mac-chacha20-poly1305. 2570 * for all -cbc and -ctr identities, renamed base identity 2571 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. 2573 * for all -ccm and -gcm identities, renamed base identity 2574 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- 2575 algorithm' and renamed the identity to remove the "enc-" prefix. 2577 * for all the 'signature-algorithm' based identities, renamed from 2578 'rsa-*' to 'rsassa-*'. 2580 * removed all of the "x509v3-" prefixed 'signature-algorithm' based 2581 identities. 2583 * added 'key-exchange-algorithm' based identities for 'rsaes-oaep' 2584 and 'rsaes-pkcs1-v1_5'. 2586 * renamed typedef 'symmetric-key-encryption-algorithm-ref' to 2587 'symmetric-key-algorithm-ref'. 2589 * renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 2590 'asymmetric-key-algorithm-ref'. 2592 * added typedef 'encryption-and-mac-algorithm-ref'. 2594 * Updated copyright date, boilerplate template, affiliation, and 2595 folding algorithm. 2597 A.5. 03 to 04 2599 * ran YANG module through formatter. 2601 A.6. 04 to 05 2603 * fixed broken symlink causing reformatted YANG module to not show. 2605 A.7. 05 to 06 2607 * Added NACM annotations. 2609 * Updated Security Considerations section. 2611 * Added 'asymmetric-key-pair-with-cert-grouping' grouping. 2613 * Removed text from 'permanently-hidden' enum regarding such keys 2614 not being backed up or restored. 2616 * Updated the boilerplate text in module-level "description" 2617 statement to match copyeditor convention. 2619 * Added an explanation to the 'public-key-grouping' and 'asymmetric- 2620 key-pair-grouping' statements as for why the nodes are not 2621 mandatory (e.g., because they may exist only in . 2623 * Added 'must' expressions to the 'public-key-grouping' and 2624 'asymmetric-key-pair-grouping' statements ensuring sibling nodes 2625 are either all exist or do not all exist. 2627 * Added an explanation to the 'permanently-hidden' that the value 2628 cannot be configured directly by clients and servers MUST fail any 2629 attempt to do so. 2631 * Added 'trust-anchor-certs-grouping' and 'end-entity-certs- 2632 grouping' (the plural form of existing groupings). 2634 * Now states that keys created in by the *-hidden-key 2635 actions are bound to the lifetime of the parent 'config true' 2636 node, and that subsequent invocations of either action results in 2637 a failure. 2639 A.8. 06 to 07 2641 * Added clarifications that implementations SHOULD assert that 2642 configured certificates contain the matching public key. 2644 * Replaced the 'generate-hidden-key' and 'install-hidden-key' 2645 actions with special 'crypt-hash' -like input/output values. 2647 A.9. 07 to 08 2649 * Removed the 'generate-key and 'hidden-key' features. 2651 * Added grouping symmetric-key-grouping 2653 * Modified 'asymmetric-key-pair-grouping' to have a 'choice' 2654 statement for the keystone module to augment into, as well as 2655 replacing the 'union' with leafs (having different NACM settings. 2657 A.10. 08 to 09 2659 * Converting algorithm from identities to enumerations. 2661 A.11. 09 to 10 2663 * All of the below changes are to the algorithm enumerations defined 2664 in ietf-crypto-types. 2666 * Add in support for key exchange over x.25519 and x.448 based on 2667 RFC 8418. 2669 * Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 2671 * Revise/add in enum of signature algorithm for x25519 and x448 2673 * Add in des3-cbc-sha1 for IPSec 2675 * Add in sha1-des3-kd for IPSec 2677 * Add in definit for rc4-hmac and rc4-hmac-exp. These two 2678 algorithms have been deprecated in RFC 8429. But some existing 2679 draft in i2nsf may still want to use them. 2681 * Add x25519 and x448 curve for asymmetric algorithms 2683 * Add signature algorithms ed25519, ed25519-cts, ed25519ph 2685 * add signature algorithms ed448, ed448ph 2686 * Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) 2688 A.12. 10 to 11 2690 * Added a "key-format" identity. 2692 * Added symmetric keys to the example in Section 2.2. 2694 A.13. 11 to 12 2696 * Removed all non-essential (to NC/RC) algorithm types. 2698 * Moved remaining algorithm types each into its own module. 2700 * Added a 'config false' "algorithms-supported" list to each of the 2701 algorithm-type modules. 2703 A.14. 12 to 13 2705 * Added the four features: "[encrypted-]one-[a]symmetric-key- 2706 format", each protecting a 'key-format' identity of the same name. 2708 * Added 'must' expressions asserting that the 'key-format' leaf 2709 exists whenever a non-hidden key is specified. 2711 * Improved the 'description' statements and added 'reference' 2712 statements for the 'key-format' identities. 2714 * Added a questionable forward reference to "encrypted-*" leafs in a 2715 couple 'when' expressions. 2717 * Did NOT move "config false" alg-supported lists to SSH/TLS drafts. 2719 A.15. 13 to 14 2721 * Resolved the "FIXME: forward ref" issue by modulating 'must', 2722 'when', and 'mandatory' expressions. 2724 * Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' 2725 actions from ietf-keystore to ietf-crypto-types, now as RPCs. 2727 * Cleaned up various description statements and removed lingering 2728 FIXMEs. 2730 * Converted the "iana--algs" YANG modules to IANA 2731 registries with instructions for how to generate modules from the 2732 registries, whenever they may be updated. 2734 A.16. 14 to 15 2736 * Removed the IANA-maintained registries for symmetric, asymmetric, 2737 and hash algorithms. 2739 * Removed the "generate-symmetric-key" and "generate-asymmetric-key" 2740 RPCs. 2742 * Removed the "algorithm" node in the various symmetric and 2743 asymmetric key groupings. 2745 * Added 'typedef csr' and 'feature certificate-signing-request- 2746 generation'. 2748 * Refined a usage of "end-entity-cert-grouping" to make the "cert" 2749 node mandatory true. 2751 * Added a "Note to Reviewers" note to first page. 2753 A.17. 15 to 16 2755 * Updated draft title (refer to "Groupings" too). 2757 * Removed 'end-entity-certs-grouping' as it wasn't being used 2758 anywhere. 2760 * Removed 'trust-anchor-certs-grouping' as it was no longer being 2761 used after modifying 'local-or-truststore-certs-grouping' to use 2762 lists (not leaf-lists). 2764 * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. 2766 * Added "csr-info" typedef, to complement the existing "csr" 2767 typedef. 2769 * Added "ocsp-request" and "ocsp-response" typedefs, to complement 2770 the existing "crl" typedef. 2772 * Added "encrypted" cases to both symmetric-key-grouping and 2773 asymmetric-key-pair-grouping (Moved from Keystore draft). 2775 * Expanded "Data Model Overview section(s) [remove "wall" of tree 2776 diagrams]. 2778 * Updated the Security Considerations section. 2780 A.18. 16 to 17 2781 * [Re]-added a "Strength of Keys Configured" Security Consideration 2783 * Prefixed "cleartext-" in the "key" and "private-key" node names. 2785 A.19. 17 to 18 2787 * Fixed issues found by the SecDir review of the "keystore" draft. 2789 * Added "password-grouping", discussed during the IETF 108 session. 2791 A.20. 18 to 19 2793 * Added a "Unconstrained Public Key Usage" Security Consideration to 2794 address concern raised by SecDir of the 'truststore' draft. 2796 * Added a "Unconstrained Private Key Usage" Security Consideration 2797 to address concern raised by SecDir of the 'truststore' draft. 2799 * Changed the encryption strategy, after conferring with Russ 2800 Housley. 2802 * Added a "password-grouping" example to the "crypto-types-usage" 2803 example. 2805 * Added an "Encrypting Passwords" section to Security Consideration. 2807 * Addressed other comments raised by YANG Doctor. 2809 Acknowledgements 2811 The authors would like to thank for following for lively discussions 2812 on list and in the halls (ordered by first name): Balazs Kovacs, Eric 2813 Voit, Juergen Schoenwaelder, Liang Xia, Martin Bjorklund, Nick 2814 Hancock, Rich Salz, Rob Wilton, Russ Housley, Sandra Murphy, Tom 2815 Petch, and Wang Haiguang. 2817 Author's Address 2819 Kent Watsen 2820 Watsen Networks 2822 Email: kent+ietf@watsen.net