| rfc9640.original | rfc9640.txt | |||
|---|---|---|---|---|
| NETCONF Working Group K. Watsen | Internet Engineering Task Force (IETF) K. Watsen | |||
| Internet-Draft Watsen Networks | Request for Comments: 9640 Watsen Networks | |||
| Intended status: Standards Track 16 March 2024 | Category: Standards Track October 2024 | |||
| Expires: 17 September 2024 | ISSN: 2070-1721 | |||
| YANG Data Types and Groupings for Cryptography | YANG Data Types and Groupings for Cryptography | |||
| draft-ietf-netconf-crypto-types-34 | ||||
| Abstract | Abstract | |||
| This document presents a YANG 1.1 (RFC 7950) module defining | This document presents a YANG 1.1 (RFC 7950) module defining | |||
| identities, typedefs, and groupings useful to cryptographic | identities, typedefs, and groupings useful to cryptographic | |||
| applications. | applications. | |||
| Editorial Note (To be removed by RFC Editor) | ||||
| This draft contains placeholder values that need to be replaced with | ||||
| finalized values at the time of publication. This note summarizes | ||||
| all of the substitutions that are needed. No other RFC Editor | ||||
| instructions are specified elsewhere in this document. | ||||
| Artwork in this document contains shorthand references to drafts in | ||||
| progress. Please apply the following replacements: | ||||
| * AAAA --> the assigned RFC value for this draft | ||||
| Artwork in this document contains placeholder values for the date of | ||||
| publication of this draft. Please apply the following replacement: | ||||
| * 2024-03-16 --> the publication date of this draft | ||||
| The "Relation to other RFCs" section Section 1.1 contains the text | ||||
| "one or more YANG modules" and, later, "modules". This text is | ||||
| sourced from a file in a context where it is unknown how many modules | ||||
| a draft defines. The text is not wrong as is, but it may be improved | ||||
| by stating more directly how many modules are defined. | ||||
| The "Relation to other RFCs" section Section 1.1 contains a self- | ||||
| reference to this draft, along with a corresponding reference in the | ||||
| Appendix. Please replace the self-reference in this section with | ||||
| "This RFC" (or similar) and remove the self-reference in the | ||||
| "Normative/Informative References" section, whichever it is in. | ||||
| Tree-diagrams in this draft may use the '\' line-folding mode defined | ||||
| in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding | ||||
| mode is used. The AD suggested suggested putting a request here for | ||||
| the RFC Editor to help convert "ugly" '\' folded examples to use the | ||||
| '\\' folding mode. "Help convert" may be interpreted as, identify | ||||
| what looks ugly and ask the authors to make the adjustment. | ||||
| The following Appendix section is to be removed prior to publication: | ||||
| * Appendix A. Change Log | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
| provisions of BCP 78 and BCP 79. | ||||
| Internet-Drafts are working documents of the Internet Engineering | ||||
| Task Force (IETF). Note that other groups may also distribute | ||||
| working documents as Internet-Drafts. The list of current Internet- | ||||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
| and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
| time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
| material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | ||||
| This Internet-Draft will expire on 17 September 2024. | Information about the current status of this document, any errata, | |||
| and how to provide feedback on it may be obtained at | ||||
| https://www.rfc-editor.org/info/rfc9640. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
| described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
| provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
| in the Revised BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction | |||
| 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4 | 1.1. Relation to Other RFCs | |||
| 1.2. Specification Language . . . . . . . . . . . . . . . . . 6 | 1.2. Specification Language | |||
| 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 6 | 1.3. Adherence to the NMDA | |||
| 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.4. Conventions | |||
| 2. The "ietf-crypto-types" Module . . . . . . . . . . . . . . . 6 | 2. The "ietf-crypto-types" Module | |||
| 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 | 2.1. Data Model Overview | |||
| 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 17 | 2.2. Example Usage | |||
| 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 | 2.3. YANG Module | |||
| 3. Security Considerations . . . . . . . . . . . . . . . . . . . 49 | 3. Security Considerations | |||
| 3.1. No Support for CRMF . . . . . . . . . . . . . . . . . . . 49 | 3.1. No Support for CRMF | |||
| 3.2. No Support for Key Generation . . . . . . . . . . . . . . 50 | 3.2. No Support for Key Generation | |||
| 3.3. Unconstrained Public Key Usage . . . . . . . . . . . . . 50 | 3.3. Unconstrained Public Key Usage | |||
| 3.4. Unconstrained Private Key Usage . . . . . . . . . . . . . 50 | 3.4. Unconstrained Private Key Usage | |||
| 3.5. Cleartext Passwords and Keys . . . . . . . . . . . . . . 50 | 3.5. Cleartext Passwords and Keys | |||
| 3.6. Encrypting Passwords and Keys . . . . . . . . . . . . . . 51 | 3.6. Encrypting Passwords and Keys | |||
| 3.7. Deletion of Cleartext Key Values . . . . . . . . . . . . 51 | 3.7. Deletion of Cleartext Key Values | |||
| 3.8. Considerations for the "ietf-crypto-types" YANG Module . 51 | 3.8. Considerations for the "ietf-crypto-types" YANG Module | |||
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | 4. IANA Considerations | |||
| 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 53 | 4.1. The IETF XML Registry | |||
| 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 53 | 4.2. The YANG Module Names Registry | |||
| 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 5. References | |||
| 5.1. Normative References . . . . . . . . . . . . . . . . . . 53 | 5.1. Normative References | |||
| 5.2. Informative References . . . . . . . . . . . . . . . . . 55 | 5.2. Informative References | |||
| Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 58 | Acknowledgements | |||
| A.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 58 | Author's Address | |||
| A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
| A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
| A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
| A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 59 | ||||
| A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 59 | ||||
| A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 59 | ||||
| A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 60 | ||||
| A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 60 | ||||
| A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 60 | ||||
| A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 60 | ||||
| A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
| A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
| A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
| A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 62 | ||||
| A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 62 | ||||
| A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 62 | ||||
| A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 63 | ||||
| A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 63 | ||||
| A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 63 | ||||
| A.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.23. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.24. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.25. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.26. 24 to 25 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.27. 25 to 26 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.28. 26 to 27 . . . . . . . . . . . . . . . . . . . . . . . . 64 | ||||
| A.29. 27 to 28 . . . . . . . . . . . . . . . . . . . . . . . . 65 | ||||
| A.30. 28 to 29 . . . . . . . . . . . . . . . . . . . . . . . . 65 | ||||
| A.31. 29 to 30 . . . . . . . . . . . . . . . . . . . . . . . . 66 | ||||
| A.32. 30 to 32 . . . . . . . . . . . . . . . . . . . . . . . . 66 | ||||
| A.33. 32 to 34 . . . . . . . . . . . . . . . . . . . . . . . . 66 | ||||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 66 | ||||
| 1. Introduction | 1. Introduction | |||
| This document presents a YANG 1.1 [RFC7950] module defining | This document presents a YANG 1.1 [RFC7950] module defining | |||
| identities, typedefs, and groupings useful to cryptographic | identities, typedefs, and groupings useful to cryptographic | |||
| applications. | applications. | |||
| 1.1. Relation to other RFCs | 1.1. Relation to Other RFCs | |||
| This document presents one or more YANG modules [RFC7950] that are | This document presents a YANG module [RFC7950] that is part of a | |||
| part of a collection of RFCs that work together to, ultimately, | collection of RFCs that work together to, ultimately, support the | |||
| support the configuration of both the clients and servers of both the | configuration of both the clients and servers of both the Network | |||
| NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. | Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. | |||
| The dependency relationship between the primary YANG groupings | The dependency relationship between the primary YANG groupings | |||
| defined in the various RFCs is presented in the below diagram. In | defined in the various RFCs is presented in the below diagram. In | |||
| some cases, a draft may define secondary groupings that introduce | some cases, a document may define secondary groupings that introduce | |||
| dependencies not illustrated in the diagram. The labels in the | dependencies not illustrated in the diagram. The labels in the | |||
| diagram are a shorthand name for the defining RFC. The citation | diagram are shorthand names for the defining RFCs. The citation | |||
| reference for shorthand name is provided below the diagram. | references for the shorthand names are provided below the diagram. | |||
| Please note that the arrows in the diagram point from referencer to | Please note that the arrows in the diagram point from referencer to | |||
| referenced. For example, the "crypto-types" RFC does not have any | referenced. For example, the "crypto-types" RFC does not have any | |||
| dependencies, whilst the "keystore" RFC depends on the "crypto-types" | dependencies, whilst the "keystore" RFC depends on the "crypto-types" | |||
| RFC. | RFC. | |||
| crypto-types | crypto-types | |||
| ^ ^ | ^ ^ | |||
| / \ | / \ | |||
| / \ | / \ | |||
| skipping to change at page 5, line 28 ¶ | skipping to change at line 121 ¶ | |||
| | | | | | ^ | | | | | | ^ | |||
| | | | +-----+ +---------+ | | | | | +-----+ +---------+ | | |||
| | | | | | | | | | | | | | | |||
| | +-----------|--------|--------------+ | | | | +-----------|--------|--------------+ | | | |||
| | | | | | | | | | | | | | | |||
| +-----------+ | | | | | | +-----------+ | | | | | | |||
| | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | |||
| netconf-client-server restconf-client-server | netconf-client-server restconf-client-server | |||
| +======================+===========================================+ | +========================+==========================+ | |||
| |Label in Diagram | Originating RFC | | | Label in Diagram | Reference | | |||
| +======================+===========================================+ | +========================+==========================+ | |||
| |crypto-types | [I-D.ietf-netconf-crypto-types] | | | crypto-types | RFC 9640 | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |truststore | [I-D.ietf-netconf-trust-anchors] | | | truststore | [RFC9641] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |keystore | [I-D.ietf-netconf-keystore] | | | keystore | [RFC9642] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | | | tcp-client-server | [RFC9643] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | | | ssh-client-server | [RFC9644] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |tls-client-server | [I-D.ietf-netconf-tls-client-server] | | | tls-client-server | [RFC9645] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |http-client-server | [I-D.ietf-netconf-http-client-server] | | | http-client-server | [HTTP-CLIENT-SERVER] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | | | netconf-client-server | [NETCONF-CLIENT-SERVER] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| |restconf-client-server| [I-D.ietf-netconf-restconf-client-server] | | | restconf-client-server | [RESTCONF-CLIENT-SERVER] | | |||
| +----------------------+-------------------------------------------+ | +------------------------+--------------------------+ | |||
| Table 1: Label in Diagram to RFC Mapping | Table 1: Labels in Diagram to RFC Mapping | |||
| 1.2. Specification Language | 1.2. Specification Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 1.3. Adherence to the NMDA | 1.3. Adherence to the NMDA | |||
| This document is compliant with the Network Management Datastore | This document is compliant with the Network Management Datastore | |||
| Architecture (NMDA) [RFC8342]. It does not define any protocol | Architecture (NMDA) [RFC8342]. It does not define any protocol- | |||
| accessible nodes that are "config false". | accessible nodes that are "config false". | |||
| 1.4. Conventions | 1.4. Conventions | |||
| Various examples in this document use "BASE64VALUE=" as a placeholder | Various examples in this document use "BASE64VALUE=" as a placeholder | |||
| value for binary data that has been base64 encoded (per Section 9.8 | value for binary data that has been base64 encoded (per Section 9.8 | |||
| of [RFC7950]). This placeholder value is used because real base64 | of [RFC7950]). This placeholder value is used because real | |||
| encoded structures are often many lines long and hence distracting to | base64-encoded structures are often many lines long and hence | |||
| the example being presented. | distracting to the example being presented. | |||
| Various examples in this document use the XML [W3C.REC-xml-20081126] | ||||
| encoding. Other encodings, such as JSON [RFC8259], could | ||||
| alternatively be used. | ||||
| Various examples in this document contain long lines that may be | ||||
| folded, as described in [RFC8792]. | ||||
| 2. The "ietf-crypto-types" Module | 2. The "ietf-crypto-types" Module | |||
| This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- | This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto- | |||
| types". A high-level overview of the module is provided in | types". A high-level overview of the module is provided in | |||
| Section 2.1. Examples illustrating the module's use are provided in | Section 2.1. Examples illustrating the module's use are provided in | |||
| Examples (Section 2.2). The YANG module itself is defined in | Section 2.2. The YANG module itself is defined in Section 2.3. | |||
| Section 2.3. | ||||
| 2.1. Data Model Overview | 2.1. Data Model Overview | |||
| This section provides an overview of the "ietf-crypto-types" module | This section provides an overview of the "ietf-crypto-types" module | |||
| in terms of its features, identities, typedefs, and groupings. | in terms of its features, identities, typedefs, and groupings. | |||
| 2.1.1. Features | 2.1.1. Features | |||
| The following diagram lists all the "feature" statements defined in | The following diagram lists all the "feature" statements defined in | |||
| the "ietf-crypto-types" module: | the "ietf-crypto-types" module: | |||
| skipping to change at page 8, line 39 ¶ | skipping to change at line 253 ¶ | |||
| The diagram above uses syntax that is similar to but not the same as | The diagram above uses syntax that is similar to but not the same as | |||
| that in [RFC8340]. | that in [RFC8340]. | |||
| Comments: | Comments: | |||
| * The diagram shows that there are five base identities. The first | * The diagram shows that there are five base identities. The first | |||
| three identities are used to indicate the format for the key data, | three identities are used to indicate the format for the key data, | |||
| while the fourth identity is used to indicate the format for | while the fourth identity is used to indicate the format for | |||
| encrypted values. The fifth identity is used to indicate the | encrypted values. The fifth identity is used to indicate the | |||
| format for a certificate signing request. The base identities are | format for a certificate signing request (CSR). The base | |||
| "abstract", in the object oriented programming sense, in that they | identities are "abstract", in the object oriented programming | |||
| only define a "class" of formats, rather than a specific format. | sense, in that they only define a "class" of formats, rather than | |||
| a specific format. | ||||
| * The various terminal identities define specific encoding formats. | * The various terminal identities define specific encoding formats. | |||
| The derived identities defined in this document are sufficient for | The derived identities defined in this document are sufficient for | |||
| the effort described in Section 1.1 but, by nature of them being | the effort described in Section 1.1, but by nature of them being | |||
| identities, additional derived identities MAY be defined by future | identities, additional derived identities MAY be defined by future | |||
| efforts. | efforts. | |||
| * Identities used to specify uncommon formats are enabled by | * Identities used to specify uncommon formats are enabled by | |||
| "feature" statements, allowing applications to support them when | "feature" statements, allowing applications to support them when | |||
| needed. | needed. | |||
| 2.1.3. Typedefs | 2.1.3. Typedefs | |||
| The following diagram illustrates the relationship amongst the | The following diagram illustrates the relationship amongst the | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at line 348 ¶ | |||
| Comments: | Comments: | |||
| * The "encrypted-by" node is an empty container (difficult to see in | * The "encrypted-by" node is an empty container (difficult to see in | |||
| the diagram) that a consuming module MUST augment key references | the diagram) that a consuming module MUST augment key references | |||
| into. The "ietf-crypto-types" module is unable to populate this | into. The "ietf-crypto-types" module is unable to populate this | |||
| container as the module only defines groupings. Section 2.2.1 | container as the module only defines groupings. Section 2.2.1 | |||
| presents an example illustrating a consuming module populating the | presents an example illustrating a consuming module populating the | |||
| "encrypted-by" container. | "encrypted-by" container. | |||
| * The "encrypted-value" node is the value, encrypted by the key | * The "encrypted-value" node is the value encrypted by the key | |||
| referenced by the "encrypted-by" node, and encoded in the format | referenced by the "encrypted-by" node and encoded in the format | |||
| appropriate for the kind of key it was encrypted by. | appropriate for the kind of key it was encrypted by. | |||
| - If the value is encrypted by a symmetric key, then the | - If the value is encrypted by a symmetric key, then the | |||
| encrypted value is encoded using the format associated with the | encrypted value is encoded using the format associated with the | |||
| "symmetrically-encrypted-value-format" identity. | "symmetrically-encrypted-value-format" identity. | |||
| - If the value is encrypted by an asymmetric key, then the | - If the value is encrypted by an asymmetric key, then the | |||
| encrypted value is encoded using the format associated with the | encrypted value is encoded using the format associated with the | |||
| "asymmetrically-encrypted-value-format" identity. | "asymmetrically-encrypted-value-format" identity. | |||
| See Section 2.1.2 for information about the "format" identities. | See Section 2.1.2 for information about the "format" identities. | |||
| 2.1.4.2. The "password-grouping" Grouping | 2.1.4.2. The "password-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "password-grouping" grouping. This tree diagram does not expand the | "password-grouping" grouping. This tree diagram does not expand the | |||
| internally used grouping statement(s): | internally used "grouping" statement(s): | |||
| grouping password-grouping: | grouping password-grouping: | |||
| +-- (password-type) | +-- (password-type) | |||
| +--:(cleartext-password) {cleartext-passwords}? | +--:(cleartext-password) {cleartext-passwords}? | |||
| | +-- cleartext-password? string | | +-- cleartext-password? string | |||
| +--:(encrypted-password) {encrypted-passwords}? | +--:(encrypted-password) {encrypted-passwords}? | |||
| +-- encrypted-password | +-- encrypted-password | |||
| +---u encrypted-value-grouping | +---u encrypted-value-grouping | |||
| Comments: | Comments: | |||
| * The "password-grouping" enables configuration of credentials | * The "password-grouping" enables the configuration of credentials | |||
| needed to authenticate to a remote system. The 'ianach:crypt- | needed to authenticate to a remote system. The "ianach:crypt- | |||
| hash' typedef from [RFC7317] should be used instead when needing | hash" typedef from [RFC7317] should be used instead when needing | |||
| to configure a password to authencate a local account. | to configure a password to authenticate a local account. | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "encrypted-value-grouping" grouping is discussed in | - The "encrypted-value-grouping" grouping is discussed in | |||
| Section 2.1.4.1. | Section 2.1.4.1. | |||
| * The "choice" statement enables the password data to be cleartext | * The "choice" statement enables the password data to be cleartext | |||
| or encrypted, as follows: | or encrypted, as follows: | |||
| - The "cleartext-password" node can encode any cleartext value. | - The "cleartext-password" node can encode any cleartext value. | |||
| - The "encrypted-password" node's structure is discussed in | ||||
| Section 2.1.4.1. | - The "encrypted-password" node is an instance of the "encrypted- | |||
| value-grouping" discussed in Section 2.1.4.1. | ||||
| 2.1.4.3. The "symmetric-key-grouping" Grouping | 2.1.4.3. The "symmetric-key-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "symmetric-key-grouping" grouping. This tree diagram does not expand | "symmetric-key-grouping" grouping. This tree diagram does not expand | |||
| the internally used grouping statement(s): | the internally used "grouping" statement(s): | |||
| grouping symmetric-key-grouping: | grouping symmetric-key-grouping: | |||
| +-- key-format? identityref | +-- key-format? identityref | |||
| +-- (key-type) | +-- (key-type) | |||
| +--:(cleartext-symmetric-key) | +--:(cleartext-symmetric-key) | |||
| | +-- cleartext-symmetric-key? binary | | +-- cleartext-symmetric-key? binary | |||
| | {cleartext-symmetric-keys}? | | {cleartext-symmetric-keys}? | |||
| +--:(hidden-symmetric-key) {hidden-symmetric-keys}? | +--:(hidden-symmetric-key) {hidden-symmetric-keys}? | |||
| | +-- hidden-symmetric-key? empty | | +-- hidden-symmetric-key? empty | |||
| +--:(encrypted-symmetric-key) {encrypted-symmetric-keys}? | +--:(encrypted-symmetric-key) {encrypted-symmetric-keys}? | |||
| +-- encrypted-symmetric-key | +-- encrypted-symmetric-key | |||
| +---u encrypted-value-grouping | +---u encrypted-value-grouping | |||
| Comments: | Comments: | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "encrypted-value-grouping" grouping is discussed in | - The "encrypted-value-grouping" grouping is discussed in | |||
| Section 2.1.4.1. | Section 2.1.4.1. | |||
| * The "key-format" node is an identity-reference to the "symmetric- | * The "key-format" node is an identity-reference to the "symmetric- | |||
| key-format" abstract base identity discussed in Section 2.1.2, | key-format" abstract base identity discussed in Section 2.1.2, | |||
| enabling the symmetric key to be encoded using any of the formats | enabling the symmetric key to be encoded using any of the formats | |||
| defined by the derived identities. | defined by the derived identities. | |||
| * The "choice" statement enables the private key data to be | * The "choice" statement enables the private key data to be | |||
| skipping to change at page 12, line 34 ¶ | skipping to change at line 431 ¶ | |||
| * The "key-format" node is an identity-reference to the "symmetric- | * The "key-format" node is an identity-reference to the "symmetric- | |||
| key-format" abstract base identity discussed in Section 2.1.2, | key-format" abstract base identity discussed in Section 2.1.2, | |||
| enabling the symmetric key to be encoded using any of the formats | enabling the symmetric key to be encoded using any of the formats | |||
| defined by the derived identities. | defined by the derived identities. | |||
| * The "choice" statement enables the private key data to be | * The "choice" statement enables the private key data to be | |||
| cleartext, encrypted, or hidden, as follows: | cleartext, encrypted, or hidden, as follows: | |||
| - The "cleartext-symmetric-key" node can encode any cleartext key | - The "cleartext-symmetric-key" node can encode any cleartext key | |||
| value. | value. | |||
| - The "hidden-symmetric-key" node is of type "empty" as the real | - The "hidden-symmetric-key" node is of type "empty" as the real | |||
| value cannot be presented via the management interface. | value cannot be presented via the management interface. | |||
| - The "encrypted-symmetric-key" node's structure is discussed in | - The "encrypted-symmetric-key" node's structure is discussed in | |||
| Section 2.1.4.1. | Section 2.1.4.1. | |||
| 2.1.4.4. The "public-key-grouping" Grouping | 2.1.4.4. The "public-key-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "public-key-grouping" grouping. This tree diagram does not expand | "public-key-grouping" grouping. This tree diagram does not expand | |||
| any internally used grouping statement(s): | any internally used "grouping" statement(s): | |||
| grouping public-key-grouping: | grouping public-key-grouping: | |||
| +-- public-key-format identityref | +-- public-key-format identityref | |||
| +-- public-key binary | +-- public-key binary | |||
| Comments: | Comments: | |||
| * The "public-key-format" node is an identity-reference to the | * The "public-key-format" node is an identity-reference to the | |||
| "public-key-format" abstract base identity discussed in | "public-key-format" abstract base identity discussed in | |||
| Section 2.1.2, enabling the public key to be encoded using any of | Section 2.1.2, enabling the public key to be encoded using any of | |||
| skipping to change at page 13, line 19 ¶ | skipping to change at line 464 ¶ | |||
| * The "public-key" node is the public key data in the selected | * The "public-key" node is the public key data in the selected | |||
| format. No "choice" statement is used to hide or encrypt the | format. No "choice" statement is used to hide or encrypt the | |||
| public key data because it is unnecessary to do so for public | public key data because it is unnecessary to do so for public | |||
| keys. | keys. | |||
| 2.1.4.5. The "private-key-grouping" Grouping | 2.1.4.5. The "private-key-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "private-key-grouping" grouping. This tree diagram does not expand | "private-key-grouping" grouping. This tree diagram does not expand | |||
| the internally used grouping statement(s): | the internally used "grouping" statement(s): | |||
| grouping private-key-grouping: | grouping private-key-grouping: | |||
| +-- private-key-format? identityref | +-- private-key-format? identityref | |||
| +-- (private-key-type) | +-- (private-key-type) | |||
| +--:(cleartext-private-key) {cleartext-private-keys}? | +--:(cleartext-private-key) {cleartext-private-keys}? | |||
| | +-- cleartext-private-key? binary | | +-- cleartext-private-key? binary | |||
| +--:(hidden-private-key) {hidden-private-keys}? | +--:(hidden-private-key) {hidden-private-keys}? | |||
| | +-- hidden-private-key? empty | | +-- hidden-private-key? empty | |||
| +--:(encrypted-private-key) {encrypted-private-keys}? | +--:(encrypted-private-key) {encrypted-private-keys}? | |||
| +-- encrypted-private-key | +-- encrypted-private-key | |||
| +---u encrypted-value-grouping | +---u encrypted-value-grouping | |||
| Comments: | Comments: | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "encrypted-value-grouping" grouping is discussed in | - The "encrypted-value-grouping" grouping is discussed in | |||
| Section 2.1.4.1. | Section 2.1.4.1. | |||
| * The "private-key-format" node is an identity-reference to the | * The "private-key-format" node is an identity-reference to the | |||
| "private-key-format" abstract base identity discussed in | "private-key-format" abstract base identity discussed in | |||
| Section 2.1.2, enabling the private key to be encoded using any of | Section 2.1.2, enabling the private key to be encoded using any of | |||
| the formats defined by the derived identities. | the formats defined by the derived identities. | |||
| * The "choice" statement enables the private key data to be | * The "choice" statement enables the private key data to be | |||
| skipping to change at page 13, line 49 ¶ | skipping to change at line 494 ¶ | |||
| * The "private-key-format" node is an identity-reference to the | * The "private-key-format" node is an identity-reference to the | |||
| "private-key-format" abstract base identity discussed in | "private-key-format" abstract base identity discussed in | |||
| Section 2.1.2, enabling the private key to be encoded using any of | Section 2.1.2, enabling the private key to be encoded using any of | |||
| the formats defined by the derived identities. | the formats defined by the derived identities. | |||
| * The "choice" statement enables the private key data to be | * The "choice" statement enables the private key data to be | |||
| cleartext, encrypted, or hidden, as follows: | cleartext, encrypted, or hidden, as follows: | |||
| - The "cleartext-private-key" node can encode any cleartext key | - The "cleartext-private-key" node can encode any cleartext key | |||
| value. | value. | |||
| - The "hidden-private-key" node is of type "empty" as the real | - The "hidden-private-key" node is of type "empty" as the real | |||
| value cannot be presented via the management interface. | value cannot be presented via the management interface. | |||
| - The "encrypted-private-key" node's structure is discussed in | - The "encrypted-private-key" node's structure is discussed in | |||
| Section 2.1.4.1. | Section 2.1.4.1. | |||
| 2.1.4.6. The "asymmetric-key-pair-grouping" Grouping | 2.1.4.6. The "asymmetric-key-pair-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "asymmetric-key-pair-grouping" grouping. This tree diagram does not | "asymmetric-key-pair-grouping" grouping. This tree diagram does not | |||
| expand the internally used grouping statement(s): | expand the internally used "grouping" statement(s): | |||
| grouping asymmetric-key-pair-grouping: | grouping asymmetric-key-pair-grouping: | |||
| +---u public-key-grouping | +---u public-key-grouping | |||
| +---u private-key-grouping | +---u private-key-grouping | |||
| Comments: | Comments: | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "public-key-grouping" grouping is discussed in | - The "public-key-grouping" grouping is discussed in | |||
| Section 2.1.4.4. | Section 2.1.4.4. | |||
| - The "private-key-grouping" grouping is discussed in | - The "private-key-grouping" grouping is discussed in | |||
| Section 2.1.4.5. | Section 2.1.4.5. | |||
| 2.1.4.7. The "certificate-expiration-grouping" Grouping | 2.1.4.7. The "certificate-expiration-grouping" Grouping | |||
| The following tree diagram [RFC8340] illustrates the "certificate- | This section presents a tree diagram [RFC8340] illustrating the | |||
| expiration-grouping" grouping: | "certificate-expiration-grouping" grouping: | |||
| grouping certificate-expiration-grouping: | grouping certificate-expiration-grouping: | |||
| +---n certificate-expiration | +---n certificate-expiration | |||
| {certificate-expiration-notification}? | {certificate-expiration-notification}? | |||
| +-- expiration-date yang:date-and-time | +-- expiration-date yang:date-and-time | |||
| Comments: | Comments: | |||
| * This grouping's only purpose is to define the "certificate- | * This grouping's only purpose is to define the "certificate- | |||
| expiration" notification statement, used by the groupings defined | expiration" notification statement, used by the groupings defined | |||
| in Section 2.1.4.8 and Section 2.1.4.9. | in Sections 2.1.4.8 and 2.1.4.9. | |||
| * The "certificate-expiration" notification enables servers to | * The "certificate-expiration" notification enables servers to | |||
| notify clients when certificates are nearing expiration. | notify clients when certificates are nearing expiration. | |||
| * The "expiration-date" node indicates when the designated | * The "expiration-date" node indicates when the designated | |||
| certificate will (or did) expire. | certificate will (or did) expire. | |||
| * Identification of the certificate that is expiring is built into | * Identification of the certificate that is expiring is built into | |||
| the notification itself. For an example, please see | the notification itself. For an example, please see | |||
| Section 2.2.3. | Section 2.2.3. | |||
| 2.1.4.8. The "trust-anchor-cert-grouping" Grouping | 2.1.4.8. The "trust-anchor-cert-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "trust-anchor-cert-grouping" grouping. This tree diagram does not | "trust-anchor-cert-grouping" grouping. This tree diagram does not | |||
| expand the internally used grouping statement(s): | expand the internally used "grouping" statement(s): | |||
| grouping trust-anchor-cert-grouping: | grouping trust-anchor-cert-grouping: | |||
| +-- cert-data? trust-anchor-cert-cms | +-- cert-data? trust-anchor-cert-cms | |||
| +---u certificate-expiration-grouping | +---u certificate-expiration-grouping | |||
| Comments: | Comments: | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "certificate-expiration-grouping" grouping is discussed in | - The "certificate-expiration-grouping" grouping is discussed in | |||
| Section 2.1.4.7. | Section 2.1.4.7. | |||
| * The "cert-data" node contains a chain of one or more certificates | * The "cert-data" node contains a chain of one or more certificates | |||
| containing at most one self-signed certificates (the "root" | containing at most one self-signed certificate (the "root" | |||
| certificate), encoded using a "signed-data-cms" typedef discussed | certificate), encoded using a "signed-data-cms" typedef discussed | |||
| in Section 2.1.3. | in Section 2.1.3. | |||
| 2.1.4.9. The "end-entity-cert-grouping" Grouping | 2.1.4.9. The "end-entity-cert-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the "end- | This section presents a tree diagram [RFC8340] illustrating the "end- | |||
| entity-cert-grouping" grouping. This tree diagram does not expand | entity-cert-grouping" grouping. This tree diagram does not expand | |||
| the internally used grouping statement(s): | the internally used "grouping" statement(s): | |||
| grouping end-entity-cert-grouping: | grouping end-entity-cert-grouping: | |||
| +-- cert-data? end-entity-cert-cms | +-- cert-data? end-entity-cert-cms | |||
| +---u certificate-expiration-grouping | +---u certificate-expiration-grouping | |||
| Comments: | Comments: | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "certificate-expiration-grouping" grouping is discussed in | - The "certificate-expiration-grouping" grouping is discussed in | |||
| Section 2.1.4.7. | Section 2.1.4.7. | |||
| * The "cert-data" node contains a chain of one or more certificates | * The "cert-data" node contains a chain of one or more certificates | |||
| containing at most one certificate that is neither self-signed nor | containing at most one certificate that is not self-signed and | |||
| having Basic constraint "CA true", encoded using a "signed-data- | does not have Basic constraint "CA true" (where "CA" means | |||
| cms" typedef discussed in Section 2.1.3. | Certification Authority), encoded using a "signed-data-cms" | |||
| typedef discussed in Section 2.1.3. | ||||
| 2.1.4.10. The "generate-csr-grouping" Grouping | 2.1.4.10. The "generate-csr-grouping" Grouping | |||
| The following tree diagram [RFC8340] illustrates the "generate-csr- | This section presents a tree diagram [RFC8340] illustrating the | |||
| grouping" grouping: | "generate-csr-grouping" grouping: | |||
| grouping generate-csr-grouping: | grouping generate-csr-grouping: | |||
| +---x generate-csr {csr-generation}? | +---x generate-csr {csr-generation}? | |||
| +---w input | +---w input | |||
| | +---w csr-format identityref | | +---w csr-format identityref | |||
| | +---w csr-info csr-info | | +---w csr-info csr-info | |||
| +--ro output | +--ro output | |||
| +--ro (csr-type) | +--ro (csr-type) | |||
| +--:(p10-csr) | +--:(p10-csr) | |||
| +--ro p10-csr? p10-csr | +--ro p10-csr? p10-csr | |||
| Comments: | Comments: | |||
| * This grouping's only purpose is to define the "generate- | * This grouping's only purpose is to define the "generate-csr" | |||
| certificate-signing-request" action statement, used by the | action statement, used by the groupings defined in Sections | |||
| groupings defined in Section 2.1.4.11 and Section 2.1.4.12. | 2.1.4.11 and 2.1.4.12. | |||
| * This action takes as input a "csr-info" type and returns a "csr" | * This action takes two input parameters: a "csr-info" parameter, | |||
| type, both of which are discussed in Section 2.1.3. | for what content should be in the certificate, and a "csr-format" | |||
| parameter, for what CSR format to return. The action returns the | ||||
| CSR in the specified format. Both the "csr-info" and "csr" types | ||||
| are discussed in Section 2.1.3. | ||||
| * For an example, please see Section 2.2.2. | * For an example, please see Section 2.2.2. | |||
| 2.1.4.11. The "asymmetric-key-pair-with-cert-grouping" Grouping | 2.1.4.11. The "asymmetric-key-pair-with-cert-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "asymmetric-key-pair-with-cert-grouping" grouping. This tree diagram | "asymmetric-key-pair-with-cert-grouping" grouping. This tree diagram | |||
| does not expand the internally used grouping statement(s): | does not expand the internally used "grouping" statement(s): | |||
| grouping asymmetric-key-pair-with-cert-grouping: | grouping asymmetric-key-pair-with-cert-grouping: | |||
| +---u asymmetric-key-pair-grouping | +---u asymmetric-key-pair-grouping | |||
| +---u end-entity-cert-grouping | +---u end-entity-cert-grouping | |||
| +---u generate-csr-grouping | +---u generate-csr-grouping | |||
| Comments: | Comments: | |||
| * This grouping defines an asymmetric key with at most one | * This grouping defines an asymmetric key with at most one | |||
| associated certificate, a commonly needed combination in protocol | associated certificate, a commonly needed combination in protocol | |||
| models. | models. | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "asymmetric-key-pair-grouping" grouping is discussed in | - The "asymmetric-key-pair-grouping" grouping is discussed in | |||
| Section 2.1.4.6. | Section 2.1.4.6. | |||
| - The "end-entity-cert-grouping" grouping is discussed in | - The "end-entity-cert-grouping" grouping is discussed in | |||
| Section 2.1.4.9. | Section 2.1.4.9. | |||
| - The "generate-csr-grouping" grouping is discussed in | - The "generate-csr-grouping" grouping is discussed in | |||
| Section 2.1.4.10. | Section 2.1.4.10. | |||
| 2.1.4.12. The "asymmetric-key-pair-with-certs-grouping" Grouping | 2.1.4.12. The "asymmetric-key-pair-with-certs-grouping" Grouping | |||
| This section presents a tree diagram [RFC8340] illustrating the | This section presents a tree diagram [RFC8340] illustrating the | |||
| "asymmetric-key-pair-with-certs-grouping" grouping. This tree | "asymmetric-key-pair-with-certs-grouping" grouping. This tree | |||
| diagram does not expand the internally used grouping statement(s): | diagram does not expand the internally used "grouping" statement(s): | |||
| grouping asymmetric-key-pair-with-certs-grouping: | grouping asymmetric-key-pair-with-certs-grouping: | |||
| +---u asymmetric-key-pair-grouping | +---u asymmetric-key-pair-grouping | |||
| +-- certificates | +-- certificates | |||
| | +-- certificate* [name] | | +-- certificate* [name] | |||
| | +-- name? string | | +-- name string | |||
| | +---u end-entity-cert-grouping | | +---u end-entity-cert-grouping | |||
| +---u generate-csr-grouping | +---u generate-csr-grouping | |||
| Comments: | Comments: | |||
| * This grouping defines an asymmetric key with one or more | * This grouping defines an asymmetric key with one or more | |||
| associated certificates, a commonly needed combination in | associated certificates, a commonly needed combination in | |||
| configuration models. | configuration models. | |||
| * For the referenced grouping statement(s): | * For the referenced "grouping" statement(s): | |||
| - The "asymmetric-key-pair-grouping" grouping is discussed in | - The "asymmetric-key-pair-grouping" grouping is discussed in | |||
| Section 2.1.4.6. | Section 2.1.4.6. | |||
| - The "end-entity-cert-grouping" grouping is discussed in | - The "end-entity-cert-grouping" grouping is discussed in | |||
| Section 2.1.4.9. | Section 2.1.4.9. | |||
| - The "generate-csr-grouping" grouping is discussed in | - The "generate-csr-grouping" grouping is discussed in | |||
| Section 2.1.4.10. | Section 2.1.4.10. | |||
| 2.1.5. Protocol-accessible Nodes | 2.1.5. Protocol-Accessible Nodes | |||
| The "ietf-crypto-types" module does not contain any protocol- | The "ietf-crypto-types" module does not contain any protocol- | |||
| accessible nodes, but the module needs to be "implemented", as | accessible nodes, but the module needs to be "implemented", as | |||
| described in Section 5.6.5 of [RFC7950], in order for the identities | described in Section 5.6.5 of [RFC7950], in order for the identities | |||
| in Section 2.1.2 to be defined. | in Section 2.1.2 to be defined. | |||
| 2.2. Example Usage | 2.2. Example Usage | |||
| 2.2.1. The "symmetric-key-grouping", "asymmetric-key-pair-with-certs- | 2.2.1. The "symmetric-key-grouping", "asymmetric-key-pair-with-certs- | |||
| grouping", and "password-grouping" Groupings | grouping", and "password-grouping" Groupings | |||
| The following non-normative module is constructed in order to | The following non-normative module is constructed in order to | |||
| illustrate the use of the "symmetric-key-grouping" (Section 2.1.4.3), | illustrate the use of the "symmetric-key-grouping" (Section 2.1.4.3), | |||
| the "asymmetric-key-pair-with-certs-grouping" (Section 2.1.4.12), and | the "asymmetric-key-pair-with-certs-grouping" (Section 2.1.4.12), and | |||
| the "password-grouping" (Section 2.1.4.2) grouping statements. | the "password-grouping" (Section 2.1.4.2) "grouping" statements. | |||
| Notably, this example module and associated configuration data | Notably, this example module and associated configuration data | |||
| illustrates that a hidden private key (ex-hidden-asymmetric-key) has | illustrates that a hidden private key (ex-hidden-asymmetric-key) has | |||
| been used to encrypt a symmetric key (ex-encrypted-one-symmetric- | been used to encrypt a symmetric key (ex-encrypted-one-symmetric- | |||
| based-symmetric-key) that has been used to encrypt another private | based-symmetric-key) that has been used to encrypt another private | |||
| key (ex-encrypted-rsa-based-asymmetric-key). Additionally, the | key (ex-encrypted-rsa-based-asymmetric-key). Additionally, the | |||
| symmetric key is also used to encrypt a password (ex-encrypted- | symmetric key is also used to encrypt a password (ex-encrypted- | |||
| password). | password). | |||
| 2.2.1.1. Example Module | 2.2.1.1. Example Module | |||
| module ex-crypto-types-usage { | module ex-crypto-types-usage { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "https://example.com/ns/example-crypto-types-usage"; | namespace "https://example.com/ns/example-crypto-types-usage"; | |||
| prefix ectu; | prefix ectu; | |||
| import ietf-crypto-types { | import ietf-crypto-types { | |||
| prefix ct; | prefix ct; | |||
| reference | reference | |||
| "RFC AAAA: YANG Data Types and Groupings for Cryptography"; | "RFC 9640: YANG Data Types and Groupings for Cryptography"; | |||
| } | } | |||
| organization | organization | |||
| "Example Corporation"; | "Example Corporation"; | |||
| contact | contact | |||
| "YANG Designer <mailto:yang.designer@example.com>"; | "YANG Designer <mailto:yang.designer@example.com>"; | |||
| description | description | |||
| "This example module illustrates the 'symmetric-key-grouping' | "This example module illustrates the 'symmetric-key-grouping' | |||
| and 'asymmetric-key-grouping' groupings defined in the | and 'asymmetric-key-grouping' groupings defined in the | |||
| 'ietf-crypto-types' module defined in RFC AAAA."; | 'ietf-crypto-types' module defined in RFC 9640."; | |||
| revision 2024-03-16 { | revision 2024-03-16 { | |||
| description | description | |||
| "Initial version"; | "Initial version."; | |||
| reference | reference | |||
| "RFC AAAA: Common YANG Data Types for Cryptography"; | "RFC 9640: YANG Data Types and Groupings for Cryptography"; | |||
| } | } | |||
| container symmetric-keys { | container symmetric-keys { | |||
| description | description | |||
| "A container of symmetric keys."; | "A container of symmetric keys."; | |||
| list symmetric-key { | list symmetric-key { | |||
| key "name"; | key "name"; | |||
| description | description | |||
| "A symmetric key"; | "A symmetric key."; | |||
| leaf name { | leaf name { | |||
| type string; | type string; | |||
| description | description | |||
| "An arbitrary name for this key."; | "An arbitrary name for this key."; | |||
| } | } | |||
| uses ct:symmetric-key-grouping { | uses ct:symmetric-key-grouping { | |||
| augment "key-type/encrypted-symmetric-key/" | augment "key-type/encrypted-symmetric-key/" | |||
| + "encrypted-symmetric-key/encrypted-by" { | + "encrypted-symmetric-key/encrypted-by" { | |||
| description | description | |||
| "Augments in a choice statement enabling the | "Augments in a 'choice' statement enabling the | |||
| encrypting key to be any other symmetric or | encrypting key to be any other symmetric or | |||
| asymmetric key."; | asymmetric key."; | |||
| uses encrypted-by-grouping; | uses encrypted-by-grouping; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| container asymmetric-keys { | container asymmetric-keys { | |||
| description | description | |||
| "A container of asymmetric keys."; | "A container of asymmetric keys."; | |||
| skipping to change at page 19, line 32 ¶ | skipping to change at line 773 ¶ | |||
| key "name"; | key "name"; | |||
| leaf name { | leaf name { | |||
| type string; | type string; | |||
| description | description | |||
| "An arbitrary name for this key."; | "An arbitrary name for this key."; | |||
| } | } | |||
| uses ct:asymmetric-key-pair-with-certs-grouping { | uses ct:asymmetric-key-pair-with-certs-grouping { | |||
| augment "private-key-type/encrypted-private-key/" | augment "private-key-type/encrypted-private-key/" | |||
| + "encrypted-private-key/encrypted-by" { | + "encrypted-private-key/encrypted-by" { | |||
| description | description | |||
| "Augments in a choice statement enabling the | "Augments in a 'choice' statement enabling the | |||
| encrypting key to be any other symmetric or | encrypting key to be any other symmetric or | |||
| asymmetric key."; | asymmetric key."; | |||
| uses encrypted-by-grouping; | uses encrypted-by-grouping; | |||
| } | } | |||
| } | } | |||
| description | description | |||
| "An asymmetric key pair with associated certificates."; | "An asymmetric key pair with associated certificates."; | |||
| } | } | |||
| } | } | |||
| container passwords { | container passwords { | |||
| skipping to change at page 20, line 8 ¶ | skipping to change at line 797 ¶ | |||
| key "name"; | key "name"; | |||
| leaf name { | leaf name { | |||
| type string; | type string; | |||
| description | description | |||
| "An arbitrary name for this password."; | "An arbitrary name for this password."; | |||
| } | } | |||
| uses ct:password-grouping { | uses ct:password-grouping { | |||
| augment "password-type/encrypted-password/" | augment "password-type/encrypted-password/" | |||
| + "encrypted-password/encrypted-by" { | + "encrypted-password/encrypted-by" { | |||
| description | description | |||
| "Augments in a choice statement enabling the | "Augments in a 'choice' statement enabling the | |||
| encrypting key to be any symmetric or | encrypting key to be any symmetric or | |||
| asymmetric key."; | asymmetric key."; | |||
| uses encrypted-by-grouping; | uses encrypted-by-grouping; | |||
| } | } | |||
| } | } | |||
| description | description | |||
| "A password."; | "A password."; | |||
| } | } | |||
| } | } | |||
| skipping to change at page 21, line 7 ¶ | skipping to change at line 842 ¶ | |||
| description | description | |||
| "Identifies the asymmetric key that encrypts this key."; | "Identifies the asymmetric key that encrypts this key."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 2.2.1.2. Tree Diagram for the Example Module | 2.2.1.2. Tree Diagram for the Example Module | |||
| The tree diagram [RFC8340] for this example module follows: | The tree diagram [RFC8340] for this example module is as follows: | |||
| module: ex-crypto-types-usage | module: ex-crypto-types-usage | |||
| +--rw symmetric-keys | +--rw symmetric-keys | |||
| | +--rw symmetric-key* [name] | | +--rw symmetric-key* [name] | |||
| | +--rw name string | | +--rw name string | |||
| | +--rw key-format? identityref | | +--rw key-format? identityref | |||
| | +--rw (key-type) | | +--rw (key-type) | |||
| | +--:(cleartext-symmetric-key) | | +--:(cleartext-symmetric-key) | |||
| | | +--rw cleartext-symmetric-key? binary | | | +--rw cleartext-symmetric-key? binary | |||
| | | {cleartext-symmetric-keys}? | | | {cleartext-symmetric-keys}? | |||
| skipping to change at page 22, line 37 ¶ | skipping to change at line 921 ¶ | |||
| | +--:(symmetric-key-ref) | | +--:(symmetric-key-ref) | |||
| | | +--rw symmetric-key-ref? leafref | | | +--rw symmetric-key-ref? leafref | |||
| | +--:(asymmetric-key-ref) | | +--:(asymmetric-key-ref) | |||
| | +--rw asymmetric-key-ref? leafref | | +--rw asymmetric-key-ref? leafref | |||
| +--rw encrypted-value-format identityref | +--rw encrypted-value-format identityref | |||
| +--rw encrypted-value binary | +--rw encrypted-value binary | |||
| 2.2.1.3. Usage Example for the Example Module | 2.2.1.3. Usage Example for the Example Module | |||
| Finally, the following example illustrates various symmetric and | Finally, the following example illustrates various symmetric and | |||
| asymmetric keys as they might appear in configuration: | asymmetric keys as they might appear in configuration. | |||
| =============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
| <symmetric-keys | <symmetric-keys | |||
| xmlns="https://example.com/ns/example-crypto-types-usage" | xmlns="https://example.com/ns/example-crypto-types-usage" | |||
| xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | |||
| <symmetric-key> | <symmetric-key> | |||
| <name>ex-hidden-symmetric-key</name> | <name>ex-hidden-symmetric-key</name> | |||
| <hidden-symmetric-key/> | <hidden-symmetric-key/> | |||
| </symmetric-key> | </symmetric-key> | |||
| skipping to change at page 25, line 9 ¶ | skipping to change at line 1037 ¶ | |||
| <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ | <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ | |||
| c-key</symmetric-key-ref> | c-key</symmetric-key-ref> | |||
| </encrypted-by> | </encrypted-by> | |||
| <encrypted-value-format>ct:cms-encrypted-data-format</encrypte\ | <encrypted-value-format>ct:cms-encrypted-data-format</encrypte\ | |||
| d-value-format> | d-value-format> | |||
| <encrypted-value>BASE64VALUE=</encrypted-value> | <encrypted-value>BASE64VALUE=</encrypted-value> | |||
| </encrypted-password> | </encrypted-password> | |||
| </password> | </password> | |||
| </passwords> | </passwords> | |||
| 2.2.2. The "generate-certificate-signing-request" Action | 2.2.2. The "generate-csr" Action | |||
| The following example illustrates the "generate-certificate-signing- | The following example illustrates the "generate-csr" action, | |||
| request" action, discussed in Section 2.1.4.10, with the NETCONF | discussed in Section 2.1.4.10, with the NETCONF protocol. | |||
| protocol. | ||||
| REQUEST | REQUEST | |||
| <rpc message-id="101" | <rpc message-id="101" | |||
| xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
| xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | |||
| <action xmlns="urn:ietf:params:xml:ns:yang:1"> | <action xmlns="urn:ietf:params:xml:ns:yang:1"> | |||
| <asymmetric-keys | <asymmetric-keys | |||
| xmlns="https://example.com/ns/example-crypto-types-usage"> | xmlns="https://example.com/ns/example-crypto-types-usage"> | |||
| <asymmetric-key> | <asymmetric-key> | |||
| skipping to change at page 27, line 4 ¶ | skipping to change at line 1123 ¶ | |||
| prefix yang; | prefix yang; | |||
| reference | reference | |||
| "RFC 6991: Common YANG Data Types"; | "RFC 6991: Common YANG Data Types"; | |||
| } | } | |||
| import ietf-netconf-acm { | import ietf-netconf-acm { | |||
| prefix nacm; | prefix nacm; | |||
| reference | reference | |||
| "RFC 8341: Network Configuration Access Control Model"; | "RFC 8341: Network Configuration Access Control Model"; | |||
| } | } | |||
| organization | organization | |||
| "IETF NETCONF (Network Configuration) Working Group"; | "IETF NETCONF (Network Configuration) Working Group"; | |||
| contact | contact | |||
| "WG Web: https://datatracker.ietf.org/wg/netconf | "WG Web: https://datatracker.ietf.org/wg/netconf | |||
| WG List: NETCONF WG list <mailto:netconf@ietf.org> | WG List: NETCONF WG list <mailto:netconf@ietf.org> | |||
| Author: Kent Watsen <mailto:kent+ietf@watsen.net>"; | Author: Kent Watsen <mailto:kent+ietf@watsen.net>"; | |||
| description | description | |||
| "This module defines common YANG types for cryptographic | "This module defines common YANG types for cryptographic | |||
| applications. | applications. | |||
| The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | ||||
| 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | ||||
| 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | ||||
| are to be interpreted as described in BCP 14 (RFC 2119) | ||||
| (RFC 8174) when, and only when, they appear in all | ||||
| capitals, as shown here. | ||||
| Copyright (c) 2024 IETF Trust and the persons identified | Copyright (c) 2024 IETF Trust and the persons identified | |||
| as authors of the code. All rights reserved. | as authors of the code. All rights reserved. | |||
| Redistribution and use in source and binary forms, with | Redistribution and use in source and binary forms, with | |||
| or without modification, is permitted pursuant to, and | or without modification, is permitted pursuant to, and | |||
| subject to the license terms contained in, the Revised | subject to the license terms contained in, the Revised | |||
| BSD License set forth in Section 4.c of the IETF Trust's | BSD License set forth in Section 4.c of the IETF Trust's | |||
| Legal Provisions Relating to IETF Documents | Legal Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
| This version of this YANG module is part of RFC AAAA | This version of this YANG module is part of RFC 9640 | |||
| (https://www.rfc-editor.org/info/rfcAAAA); see the RFC | (https://www.rfc-editor.org/info/rfc9640); see the RFC | |||
| itself for full legal notices. | itself for full legal notices."; | |||
| The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | ||||
| 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | ||||
| 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | ||||
| are to be interpreted as described in BCP 14 (RFC 2119) | ||||
| (RFC 8174) when, and only when, they appear in all | ||||
| capitals, as shown here."; | ||||
| revision 2024-03-16 { | revision 2024-03-16 { | |||
| description | description | |||
| "Initial version"; | "Initial version."; | |||
| reference | reference | |||
| "RFC AAAA: YANG Data Types and Groupings for Cryptography"; | "RFC 9640: YANG Data Types and Groupings for Cryptography"; | |||
| } | } | |||
| /****************/ | /****************/ | |||
| /* Features */ | /* Features */ | |||
| /****************/ | /****************/ | |||
| feature one-symmetric-key-format { | feature one-symmetric-key-format { | |||
| description | description | |||
| "Indicates that the server supports the | "Indicates that the server supports the | |||
| 'one-symmetric-key-format' identity."; | 'one-symmetric-key-format' identity."; | |||
| skipping to change at page 30, line 45 ¶ | skipping to change at line 1309 ¶ | |||
| an RSAPrivateKey (from RFC 8017), encoded using ASN.1 | an RSAPrivateKey (from RFC 8017), encoded using ASN.1 | |||
| distinguished encoding rules (DER), as specified in | distinguished encoding rules (DER), as specified in | |||
| ITU-T X.690."; | ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 8017: | "RFC 8017: | |||
| PKCS #1: RSA Cryptography Specifications Version 2.2 | PKCS #1: RSA Cryptography Specifications Version 2.2 | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| identity ec-private-key-format { | identity ec-private-key-format { | |||
| base private-key-format; | base private-key-format; | |||
| description | description | |||
| "Indicates that the private key value is encoded as | "Indicates that the private key value is encoded as | |||
| an ECPrivateKey (from RFC 5915), encoded using ASN.1 | an ECPrivateKey (from RFC 5915), encoded using ASN.1 | |||
| distinguished encoding rules (DER), as specified in | distinguished encoding rules (DER), as specified in | |||
| ITU-T X.690."; | ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 5915: | "RFC 5915: | |||
| Elliptic Curve Private Key Structure | Elliptic Curve Private Key Structure | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| identity one-asymmetric-key-format { | identity one-asymmetric-key-format { | |||
| if-feature "one-asymmetric-key-format"; | if-feature "one-asymmetric-key-format"; | |||
| base private-key-format; | base private-key-format; | |||
| description | description | |||
| "Indicates that the private key value is a CMS | "Indicates that the private key value is a | |||
| OneAsymmetricKey structure, as defined in RFC 5958, | Cryptographic Message Syntax (CMS) OneAsymmetricKey | |||
| encoded using ASN.1 distinguished encoding rules | structure, as defined in RFC 5958, encoded using | |||
| (DER), as specified in ITU-T X.690."; | ASN.1 distinguished encoding rules (DER), as | |||
| specified in ITU-T X.690."; | ||||
| reference | reference | |||
| "RFC 5958: Asymmetric Key Packages | "RFC 5958: | |||
| Asymmetric Key Packages | ||||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /***************************************************/ | /***************************************************/ | |||
| /* Identities for Public Key Format Structures */ | /* Identities for Public Key Format Structures */ | |||
| /***************************************************/ | /***************************************************/ | |||
| identity ssh-public-key-format { | identity ssh-public-key-format { | |||
| base public-key-format; | base public-key-format; | |||
| description | description | |||
| "Indicates that the public key value is an SSH public key, | "Indicates that the public key value is a Secure Shell (SSH) | |||
| as specified by RFC 4253, Section 6.6, i.e.: | public key, as specified in RFC 4253, Section 6.6, i.e.: | |||
| string certificate or public key format | string certificate or public key format | |||
| identifier | identifier | |||
| byte[n] key/certificate data."; | byte[n] key/certificate data."; | |||
| reference | reference | |||
| "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; | "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; | |||
| } | } | |||
| identity subject-public-key-info-format { | identity subject-public-key-info-format { | |||
| base public-key-format; | base public-key-format; | |||
| description | description | |||
| "Indicates that the public key value is a SubjectPublicKeyInfo | "Indicates that the public key value is a SubjectPublicKeyInfo | |||
| structure, as described in RFC 5280 encoded using ASN.1 | structure, as described in RFC 5280, encoded using ASN.1 | |||
| distinguished encoding rules (DER), as specified in | distinguished encoding rules (DER), as specified in | |||
| ITU-T X.690."; | ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 5280: | "RFC 5280: | |||
| Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile | and Certificate Revocation List (CRL) Profile | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /******************************************************/ | /******************************************************/ | |||
| /* Identities for Symmetric Key Format Structures */ | /* Identities for Symmetric Key Format Structures */ | |||
| /******************************************************/ | /******************************************************/ | |||
| identity octet-string-key-format { | identity octet-string-key-format { | |||
| base symmetric-key-format; | base symmetric-key-format; | |||
| description | description | |||
| "Indicates that the key is encoded as a raw octet string. | "Indicates that the key is encoded as a raw octet string. | |||
| The length of the octet string MUST be appropriate for | The length of the octet string MUST be appropriate for | |||
| the associated algorithm's block size. | the associated algorithm's block size. | |||
| The identity of the associated algorithm is outside the | The identity of the associated algorithm is outside the | |||
| scope of this specification. This is also true when | scope of this specification. This is also true when | |||
| the octet string has been encrypted."; | the octet string has been encrypted."; | |||
| } | } | |||
| identity one-symmetric-key-format { | identity one-symmetric-key-format { | |||
| if-feature "one-symmetric-key-format"; | if-feature "one-symmetric-key-format"; | |||
| base symmetric-key-format; | base symmetric-key-format; | |||
| description | description | |||
| "Indicates that the private key value is a CMS | "Indicates that the private key value is a CMS | |||
| OneSymmetricKey structure, as defined in RFC 6031, | OneSymmetricKey structure, as defined in RFC 6031, | |||
| encoded using ASN.1 distinguished encoding rules | encoded using ASN.1 distinguished encoding rules | |||
| (DER), as specified in ITU-T X.690."; | (DER), as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 6031: Cryptographic Message Syntax (CMS) | "RFC 6031: | |||
| Symmetric Key Package Content Type | Cryptographic Message Syntax (CMS) | |||
| Symmetric Key Package Content Type | ||||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /*************************************************/ | /*************************************************/ | |||
| /* Identities for Encrypted Value Structures */ | /* Identities for Encrypted Value Structures */ | |||
| /*************************************************/ | /*************************************************/ | |||
| identity encrypted-value-format { | identity encrypted-value-format { | |||
| description | description | |||
| "Base format identity for encrypted values."; | "Base format identity for encrypted values."; | |||
| } | } | |||
| skipping to change at page 33, line 40 ¶ | skipping to change at line 1451 ¶ | |||
| } | } | |||
| identity cms-encrypted-data-format { | identity cms-encrypted-data-format { | |||
| if-feature "cms-encrypted-data-format"; | if-feature "cms-encrypted-data-format"; | |||
| base symmetrically-encrypted-value-format; | base symmetrically-encrypted-value-format; | |||
| description | description | |||
| "Indicates that the encrypted value conforms to | "Indicates that the encrypted value conforms to | |||
| the 'encrypted-data-cms' type with the constraint | the 'encrypted-data-cms' type with the constraint | |||
| that the 'unprotectedAttrs' value is not set."; | that the 'unprotectedAttrs' value is not set."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS) | "RFC 5652: | |||
| Cryptographic Message Syntax (CMS) | ||||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| identity cms-enveloped-data-format { | identity cms-enveloped-data-format { | |||
| if-feature "cms-enveloped-data-format"; | if-feature "cms-enveloped-data-format"; | |||
| base asymmetrically-encrypted-value-format; | base asymmetrically-encrypted-value-format; | |||
| description | description | |||
| "Indicates that the encrypted value conforms to the | "Indicates that the encrypted value conforms to the | |||
| 'enveloped-data-cms' type with the following constraints: | 'enveloped-data-cms' type with the following constraints: | |||
| The EnvelopedData structure MUST have exactly one | The EnvelopedData structure MUST have exactly one | |||
| 'RecipientInfo'. | 'RecipientInfo'. | |||
| If the asymmetric key supports public key cryptography | If the asymmetric key supports public key cryptography | |||
| (e.g., RSA), then the 'RecipientInfo' must be a | (e.g., RSA), then the 'RecipientInfo' must be a | |||
| 'KeyTransRecipientInfo' with the 'RecipientIdentifier' | 'KeyTransRecipientInfo' with the 'RecipientIdentifier' | |||
| using a 'subjectKeyIdentifier' with the value set using | using a 'subjectKeyIdentifier' with the value set using | |||
| 'method 1' in RFC 7093 over the recipient's public key. | 'method 1' in RFC 7093 over the recipient's public key. | |||
| Otherwise, if the asymmetric key supports key agreement | Otherwise, if the asymmetric key supports key agreement | |||
| (e.g., ECC), then the 'RecipientInfo' must be a | (e.g., Elliptic Curve Cryptography (ECC)), then the | |||
| 'KeyAgreeRecipientInfo'. The 'OriginatorIdentifierOrKey' | 'RecipientInfo' must be a 'KeyAgreeRecipientInfo'. The | |||
| value must use the 'OriginatorPublicKey' alternative. | 'OriginatorIdentifierOrKey' value must use the | |||
| The 'UserKeyingMaterial' value must not be present. | 'OriginatorPublicKey' alternative. The | |||
| There must be exactly one 'RecipientEncryptedKeys' value | 'UserKeyingMaterial' value must not be present. There | |||
| must be exactly one 'RecipientEncryptedKeys' value | ||||
| having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' | having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' | |||
| with the value set using 'method 1' in RFC 7093 over the | with the value set using 'method 1' in RFC 7093 over the | |||
| recipient's public key."; | recipient's public key."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS) | "RFC 5652: | |||
| Cryptographic Message Syntax (CMS) | ||||
| RFC 7093: | RFC 7093: | |||
| Additional Methods for Generating Key | Additional Methods for Generating Key | |||
| Identifiers Values | Identifiers Values | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /*********************************************************/ | /*********************************************************/ | |||
| /* Identities for Certificate Signing Request Formats */ | /* Identities for Certificate Signing Request Formats */ | |||
| /*********************************************************/ | /*********************************************************/ | |||
| identity csr-format { | identity csr-format { | |||
| description | description | |||
| "A base identity for the certificate signing request | "A base identity for the certificate signing request | |||
| formats. Additional derived identities MAY be defined | formats. Additional derived identities MAY be defined | |||
| by future efforts."; | by future efforts."; | |||
| } | } | |||
| identity p10-csr-format { | identity p10-csr-format { | |||
| if-feature "p10-csr-format"; | if-feature "p10-csr-format"; | |||
| base csr-format; | base csr-format; | |||
| description | description | |||
| "Indicates the 'CertificationRequest' structure | "Indicates the CertificationRequest structure | |||
| defined in RFC 2986."; | defined in RFC 2986."; | |||
| reference | reference | |||
| "RFC 2986: PKCS #10: Certification Request Syntax | "RFC 2986: PKCS #10: Certification Request Syntax | |||
| Specification Version 1.7"; | Specification Version 1.7"; | |||
| } | } | |||
| /***************************************************/ | /***************************************************/ | |||
| /* Typedefs for ASN.1 structures from RFC 2986 */ | /* Typedefs for ASN.1 structures from RFC 2986 */ | |||
| /***************************************************/ | /***************************************************/ | |||
| typedef csr-info { | typedef csr-info { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A CertificationRequestInfo structure, as defined in | "A CertificationRequestInfo structure, as defined in | |||
| RFC 2986, encoded using ASN.1 distinguished encoding | RFC 2986, encoded using ASN.1 distinguished encoding | |||
| rules (DER), as specified in ITU-T X.690."; | rules (DER), as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 2986: PKCS #10: Certification Request Syntax | "RFC 2986: | |||
| Specification Version 1.7 | PKCS #10: Certification Request Syntax | |||
| Specification Version 1.7 | ||||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| typedef p10-csr { | typedef p10-csr { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A CertificationRequest structure, as specified in | "A CertificationRequest structure, as specified in | |||
| RFC 2986, encoded using ASN.1 distinguished encoding | RFC 2986, encoded using ASN.1 distinguished encoding | |||
| rules (DER), as specified in ITU-T X.690."; | rules (DER), as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 2986: | "RFC 2986: | |||
| PKCS #10: Certification Request Syntax Specification | PKCS #10: Certification Request Syntax Specification | |||
| Version 1.7 | Version 1.7 | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /***************************************************/ | /***************************************************/ | |||
| /* Typedefs for ASN.1 structures from RFC 5280 */ | /* Typedefs for ASN.1 structures from RFC 5280 */ | |||
| /***************************************************/ | /***************************************************/ | |||
| typedef x509 { | typedef x509 { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A Certificate structure, as specified in RFC 5280, | "A Certificate structure, as specified in RFC 5280, | |||
| encoded using ASN.1 distinguished encoding rules (DER), | encoded using ASN.1 distinguished encoding rules (DER), | |||
| as specified in ITU-T X.690."; | as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 5280: | "RFC 5280: | |||
| Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile | and Certificate Revocation List (CRL) Profile | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| typedef crl { | typedef crl { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A CertificateList structure, as specified in RFC 5280, | "A CertificateList structure, as specified in RFC 5280, | |||
| encoded using ASN.1 distinguished encoding rules (DER), | encoded using ASN.1 distinguished encoding rules (DER), | |||
| as specified in ITU-T X.690."; | as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 5280: | "RFC 5280: | |||
| Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile | and Certificate Revocation List (CRL) Profile | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /***************************************************/ | /***************************************************/ | |||
| /* Typedefs for ASN.1 structures from RFC 6960 */ | /* Typedefs for ASN.1 structures from RFC 6960 */ | |||
| /***************************************************/ | /***************************************************/ | |||
| typedef oscp-request { | typedef oscp-request { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A OCSPRequest structure, as specified in RFC 6960, | "A OCSPRequest structure, as specified in RFC 6960, | |||
| skipping to change at page 37, line 4 ¶ | skipping to change at line 1611 ¶ | |||
| typedef oscp-request { | typedef oscp-request { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A OCSPRequest structure, as specified in RFC 6960, | "A OCSPRequest structure, as specified in RFC 6960, | |||
| encoded using ASN.1 distinguished encoding rules | encoded using ASN.1 distinguished encoding rules | |||
| (DER), as specified in ITU-T X.690."; | (DER), as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 6960: | "RFC 6960: | |||
| X.509 Internet Public Key Infrastructure Online | X.509 Internet Public Key Infrastructure Online | |||
| Certificate Status Protocol - OCSP | Certificate Status Protocol - OCSP | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| typedef oscp-response { | typedef oscp-response { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A OCSPResponse structure, as specified in RFC 6960, | "A OCSPResponse structure, as specified in RFC 6960, | |||
| encoded using ASN.1 distinguished encoding rules | encoded using ASN.1 distinguished encoding rules | |||
| (DER), as specified in ITU-T X.690."; | (DER), as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 6960: | "RFC 6960: | |||
| X.509 Internet Public Key Infrastructure Online | X.509 Internet Public Key Infrastructure Online | |||
| Certificate Status Protocol - OCSP | Certificate Status Protocol - OCSP | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| /***********************************************/ | /***********************************************/ | |||
| /* Typedefs for ASN.1 structures from 5652 */ | /* Typedefs for ASN.1 structures from 5652 */ | |||
| /***********************************************/ | /***********************************************/ | |||
| typedef cms { | typedef cms { | |||
| type binary; | type binary; | |||
| description | description | |||
| "A ContentInfo structure, as specified in RFC 5652, | "A ContentInfo structure, as specified in RFC 5652, | |||
| encoded using ASN.1 distinguished encoding rules (DER), | encoded using ASN.1 distinguished encoding rules (DER), | |||
| as specified in ITU-T X.690."; | as specified in ITU-T X.690."; | |||
| reference | reference | |||
| "RFC 5652: | "RFC 5652: | |||
| Cryptographic Message Syntax (CMS) | Cryptographic Message Syntax (CMS) | |||
| ITU-T X.690: | ITU-T X.690: | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), | Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) 02/2021."; | Encoding Rules (DER) 02/2021"; | |||
| } | } | |||
| typedef data-content-cms { | typedef data-content-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| data content type, as described by Section 4 in RFC 5652."; | data content type, as described in Section 4 of RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef signed-data-cms { | typedef signed-data-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| signed-data content type, as described by Section 5 in | signed-data content type, as described in Section 5 of | |||
| RFC 5652."; | RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef enveloped-data-cms { | typedef enveloped-data-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| enveloped-data content type, as described by Section 6 | enveloped-data content type, as described in Section 6 | |||
| in RFC 5652."; | of RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef digested-data-cms { | typedef digested-data-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| digested-data content type, as described by Section 7 | digested-data content type, as described in Section 7 | |||
| in RFC 5652."; | of RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef encrypted-data-cms { | typedef encrypted-data-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| encrypted-data content type, as described by Section 8 | encrypted-data content type, as described in Section 8 | |||
| in RFC 5652."; | of RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef authenticated-data-cms { | typedef authenticated-data-cms { | |||
| type cms; | type cms; | |||
| description | description | |||
| "A CMS structure whose top-most content type MUST be the | "A CMS structure whose top-most content type MUST be the | |||
| authenticated-data content type, as described by Section 9 | authenticated-data content type, as described in Section 9 | |||
| in RFC 5652."; | of RFC 5652."; | |||
| reference | reference | |||
| "RFC 5652: Cryptographic Message Syntax (CMS)"; | "RFC 5652: Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| /*********************************************************/ | /*********************************************************/ | |||
| /* Typedefs for ASN.1 structures related to RFC 5280 */ | /* Typedefs for ASN.1 structures related to RFC 5280 */ | |||
| /*********************************************************/ | /*********************************************************/ | |||
| typedef trust-anchor-cert-x509 { | typedef trust-anchor-cert-x509 { | |||
| type x509; | type x509; | |||
| description | description | |||
| "A Certificate structure that MUST encode a self-signed | "A Certificate structure that MUST encode a self-signed | |||
| root certificate."; | root certificate."; | |||
| } | } | |||
| typedef end-entity-cert-x509 { | typedef end-entity-cert-x509 { | |||
| type x509; | type x509; | |||
| description | description | |||
| "A Certificate structure that MUST encode a certificate | "A Certificate structure that MUST encode a certificate | |||
| that is neither self-signed nor having Basic constraint | that is neither self-signed nor has Basic constraint | |||
| CA true."; | CA true."; | |||
| } | } | |||
| /*********************************************************/ | /*********************************************************/ | |||
| /* Typedefs for ASN.1 structures related to RFC 5652 */ | /* Typedefs for ASN.1 structures related to RFC 5652 */ | |||
| /*********************************************************/ | /*********************************************************/ | |||
| typedef trust-anchor-cert-cms { | typedef trust-anchor-cert-cms { | |||
| type signed-data-cms; | type signed-data-cms; | |||
| description | description | |||
| "A CMS SignedData structure that MUST contain the chain of | "A CMS SignedData structure that MUST contain the chain of | |||
| X.509 certificates needed to authenticate the certificate | X.509 certificates needed to authenticate the certificate | |||
| presented by a client or end-entity. | presented by a client or end entity. | |||
| The CMS MUST contain only a single chain of certificates. | The CMS MUST contain only a single chain of certificates. | |||
| The client or end-entity certificate MUST only authenticate | The client or end-entity certificate MUST only authenticate | |||
| to the last intermediate CA certificate listed in the chain. | to the last intermediate CA certificate listed in the chain. | |||
| In all cases, the chain MUST include a self-signed root | In all cases, the chain MUST include a self-signed root | |||
| certificate. In the case where the root certificate is | certificate. In the case where the root certificate is | |||
| itself the issuer of the client or end-entity certificate, | itself the issuer of the client or end-entity certificate, | |||
| only one certificate is present. | only one certificate is present. | |||
| skipping to change at page 40, line 14 ¶ | skipping to change at line 1765 ¶ | |||
| policy) revocation objects with which the device can | policy) revocation objects with which the device can | |||
| verify the revocation status of the certificates. | verify the revocation status of the certificates. | |||
| This CMS encodes the degenerate form of the SignedData | This CMS encodes the degenerate form of the SignedData | |||
| structure (RFC 5652, Section 5.2) that is commonly used | structure (RFC 5652, Section 5.2) that is commonly used | |||
| to disseminate X.509 certificates and revocation objects | to disseminate X.509 certificates and revocation objects | |||
| (RFC 5280)."; | (RFC 5280)."; | |||
| reference | reference | |||
| "RFC 5280: | "RFC 5280: | |||
| Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile. | and Certificate Revocation List (CRL) Profile | |||
| RFC 5652: | RFC 5652: | |||
| Cryptographic Message Syntax (CMS)"; | Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| typedef end-entity-cert-cms { | typedef end-entity-cert-cms { | |||
| type signed-data-cms; | type signed-data-cms; | |||
| description | description | |||
| "A CMS SignedData structure that MUST contain the end | "A CMS SignedData structure that MUST contain the end-entity | |||
| entity certificate itself, and MAY contain any number | certificate itself and MAY contain any number | |||
| of intermediate certificates leading up to a trust | of intermediate certificates leading up to a trust | |||
| anchor certificate. The trust anchor certificate | anchor certificate. The trust anchor certificate | |||
| MAY be included as well. | MAY be included as well. | |||
| The CMS MUST contain a single end entity certificate. | The CMS MUST contain a single end-entity certificate. | |||
| The CMS MUST NOT contain any spurious certificates. | The CMS MUST NOT contain any spurious certificates. | |||
| This CMS structure MAY (as applicable where this type is | This CMS structure MAY (as applicable where this type is | |||
| used) also contain suitably fresh (as defined by local | used) also contain suitably fresh (as defined by local | |||
| policy) revocation objects with which the device can | policy) revocation objects with which the device can | |||
| verify the revocation status of the certificates. | verify the revocation status of the certificates. | |||
| This CMS encodes the degenerate form of the SignedData | This CMS encodes the degenerate form of the SignedData | |||
| structure (RFC 5652, Section 5.2) that is commonly | structure (RFC 5652, Section 5.2) that is commonly | |||
| used to disseminate X.509 certificates and revocation | used to disseminate X.509 certificates and revocation | |||
| objects (RFC 5280)."; | objects (RFC 5280)."; | |||
| reference | reference | |||
| "RFC 5280: | "RFC 5280: | |||
| Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile. | and Certificate Revocation List (CRL) Profile | |||
| RFC 5652: | RFC 5652: | |||
| Cryptographic Message Syntax (CMS)"; | Cryptographic Message Syntax (CMS)"; | |||
| } | } | |||
| /*****************/ | /*****************/ | |||
| /* Groupings */ | /* Groupings */ | |||
| /*****************/ | /*****************/ | |||
| grouping encrypted-value-grouping { | grouping encrypted-value-grouping { | |||
| description | description | |||
| "A reusable grouping for a value that has been encrypted by | "A reusable grouping for a value that has been encrypted by | |||
| a referenced symmetric or asymmetric key."; | a referenced symmetric or asymmetric key."; | |||
| container encrypted-by { | container encrypted-by { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| description | description | |||
| "An empty container enabling a reference to the key that | "An empty container enabling a reference to the key that | |||
| encrypted the value to be augmented in. The referenced | encrypted the value to be augmented in. The referenced | |||
| key MUST be a symmetric key or an asymmetric key. | key MUST be a symmetric key or an asymmetric key. | |||
| A symmetric key MUST be referenced via a leaf node called | A symmetric key MUST be referenced via a leaf node called | |||
| 'symmetric-key-ref'. An asymmetric key MUST be referenced | 'symmetric-key-ref'. An asymmetric key MUST be referenced | |||
| via a leaf node called 'asymmetric-key-ref'. | via a leaf node called 'asymmetric-key-ref'. | |||
| The leaf nodes MUST be direct descendants in the data tree, | The leaf nodes MUST be direct descendants in the data tree | |||
| and MAY be direct descendants in the schema tree (e.g., | and MAY be direct descendants in the schema tree (e.g., | |||
| choice/case statements are allowed, but not a container)."; | 'choice'/'case' statements are allowed but not a | |||
| container)."; | ||||
| } | } | |||
| leaf encrypted-value-format { | leaf encrypted-value-format { | |||
| type identityref { | type identityref { | |||
| base encrypted-value-format; | base encrypted-value-format; | |||
| } | } | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Identifies the format of the 'encrypted-value' leaf. | "Identifies the format of the 'encrypted-value' leaf. | |||
| If 'encrypted-by' points to a symmetric key, then a | If 'encrypted-by' points to a symmetric key, then an | |||
| 'symmetrically-encrypted-value-format' based identity | identity based on 'symmetrically-encrypted-value-format' | |||
| MUST be set (e.g., cms-encrypted-data-format). | MUST be set (e.g., 'cms-encrypted-data-format'). | |||
| If 'encrypted-by' points to an asymmetric key, then an | If 'encrypted-by' points to an asymmetric key, then an | |||
| 'asymmetrically-encrypted-value-format' based identity | identity based on 'asymmetrically-encrypted-value-format' | |||
| MUST be set (e.g., cms-enveloped-data-format)."; | MUST be set (e.g., 'cms-enveloped-data-format')."; | |||
| } | } | |||
| leaf encrypted-value { | leaf encrypted-value { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| type binary; | type binary; | |||
| must '../encrypted-by'; | must '../encrypted-by'; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "The value, encrypted using the referenced symmetric | "The value, encrypted using the referenced symmetric | |||
| or asymmetric key. The value MUST be encoded using | or asymmetric key. The value MUST be encoded using | |||
| the format associated with the 'encrypted-value-format' | the format associated with the 'encrypted-value-format' | |||
| skipping to change at page 42, line 4 ¶ | skipping to change at line 1852 ¶ | |||
| type binary; | type binary; | |||
| must '../encrypted-by'; | must '../encrypted-by'; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "The value, encrypted using the referenced symmetric | "The value, encrypted using the referenced symmetric | |||
| or asymmetric key. The value MUST be encoded using | or asymmetric key. The value MUST be encoded using | |||
| the format associated with the 'encrypted-value-format' | the format associated with the 'encrypted-value-format' | |||
| leaf."; | leaf."; | |||
| } | } | |||
| } | } | |||
| grouping password-grouping { | grouping password-grouping { | |||
| description | description | |||
| "A password used for authenticating to a remote system. | "A password used for authenticating to a remote system. | |||
| The 'ianach:crypt-hash' typedef from RFC 7317 should be | The 'ianach:crypt-hash' typedef from RFC 7317 should be | |||
| used instead when needing a password to authencate a | used instead when needing a password to authenticate a | |||
| local account."; | local account."; | |||
| choice password-type { | choice password-type { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Choice between password types."; | "Choice between password types."; | |||
| case cleartext-password { | case cleartext-password { | |||
| if-feature "cleartext-passwords"; | if-feature "cleartext-passwords"; | |||
| leaf cleartext-password { | leaf cleartext-password { | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| skipping to change at page 42, line 51 ¶ | skipping to change at line 1900 ¶ | |||
| type identityref { | type identityref { | |||
| base symmetric-key-format; | base symmetric-key-format; | |||
| } | } | |||
| description | description | |||
| "Identifies the symmetric key's format. Implementations | "Identifies the symmetric key's format. Implementations | |||
| SHOULD ensure that the incoming symmetric key value is | SHOULD ensure that the incoming symmetric key value is | |||
| encoded in the specified format. | encoded in the specified format. | |||
| For encrypted keys, the value is the decrypted key's | For encrypted keys, the value is the decrypted key's | |||
| format (i.e., the 'encrypted-value-format' conveys the | format (i.e., the 'encrypted-value-format' conveys the | |||
| encrypted key's format."; | encrypted key's format)."; | |||
| } | } | |||
| choice key-type { | choice key-type { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Choice between key types."; | "Choice between key types."; | |||
| case cleartext-symmetric-key { | case cleartext-symmetric-key { | |||
| leaf cleartext-symmetric-key { | leaf cleartext-symmetric-key { | |||
| if-feature "cleartext-symmetric-keys"; | if-feature "cleartext-symmetric-keys"; | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| skipping to change at page 43, line 28 ¶ | skipping to change at line 1924 ¶ | |||
| "The binary value of the key. The interpretation of | "The binary value of the key. The interpretation of | |||
| the value is defined by the 'key-format' field."; | the value is defined by the 'key-format' field."; | |||
| } | } | |||
| } | } | |||
| case hidden-symmetric-key { | case hidden-symmetric-key { | |||
| if-feature "hidden-symmetric-keys"; | if-feature "hidden-symmetric-keys"; | |||
| leaf hidden-symmetric-key { | leaf hidden-symmetric-key { | |||
| type empty; | type empty; | |||
| must 'not(../key-format)'; | must 'not(../key-format)'; | |||
| description | description | |||
| "A hidden key is not exportable, and not extractable, | "A hidden key is not exportable and not extractable; | |||
| and therefore, it is of type 'empty' as its value is | therefore, it is of type 'empty' as its value is | |||
| inaccessible via management interfaces. Though hidden | inaccessible via management interfaces. Though hidden | |||
| to users, such keys are not hidden to the server and | to users, such keys are not hidden to the server and | |||
| may be referenced by configuration to indicate which | may be referenced by configuration to indicate which | |||
| key a server should use for a cryptographic operation. | key a server should use for a cryptographic operation. | |||
| How such keys are created is outside the scope of this | How such keys are created is outside the scope of this | |||
| module."; | module."; | |||
| } | } | |||
| } | } | |||
| case encrypted-symmetric-key { | case encrypted-symmetric-key { | |||
| if-feature "encrypted-symmetric-keys"; | if-feature "encrypted-symmetric-keys"; | |||
| container encrypted-symmetric-key { | container encrypted-symmetric-key { | |||
| skipping to change at page 44, line 13 ¶ | skipping to change at line 1958 ¶ | |||
| grouping public-key-grouping { | grouping public-key-grouping { | |||
| description | description | |||
| "A public key."; | "A public key."; | |||
| leaf public-key-format { | leaf public-key-format { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| type identityref { | type identityref { | |||
| base public-key-format; | base public-key-format; | |||
| } | } | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Identifies the public key's format. Implementations SHOULD | "Identifies the public key's format. Implementations SHOULD | |||
| ensure that the incoming public key value is encoded in the | ensure that the incoming public key value is encoded in the | |||
| specified format."; | specified format."; | |||
| } | } | |||
| leaf public-key { | leaf public-key { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| type binary; | type binary; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "The binary value of the public key. The interpretation | "The binary value of the public key. The interpretation | |||
| of the value is defined by 'public-key-format' field."; | of the value is defined by the 'public-key-format' field."; | |||
| } | } | |||
| } | } | |||
| grouping private-key-grouping { | grouping private-key-grouping { | |||
| description | description | |||
| "A private key."; | "A private key."; | |||
| leaf private-key-format { | leaf private-key-format { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| type identityref { | type identityref { | |||
| base private-key-format; | base private-key-format; | |||
| } | } | |||
| description | description | |||
| "Identifies the private key's format. Implementations SHOULD | "Identifies the private key's format. Implementations SHOULD | |||
| ensure that the incoming private key value is encoded in the | ensure that the incoming private key value is encoded in the | |||
| specified format. | specified format. | |||
| For encrypted keys, the value is the decrypted key's | For encrypted keys, the value is the decrypted key's | |||
| format (i.e., the 'encrypted-value-format' conveys the | format (i.e., the 'encrypted-value-format' conveys the | |||
| encrypted key's format."; | encrypted key's format)."; | |||
| } | } | |||
| choice private-key-type { | choice private-key-type { | |||
| nacm:default-deny-write; | nacm:default-deny-write; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Choice between key types."; | "Choice between key types."; | |||
| case cleartext-private-key { | case cleartext-private-key { | |||
| if-feature "cleartext-private-keys"; | if-feature "cleartext-private-keys"; | |||
| leaf cleartext-private-key { | leaf cleartext-private-key { | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| type binary; | type binary; | |||
| must '../private-key-format'; | must '../private-key-format'; | |||
| description | description | |||
| "The value of the binary key The key's value is | "The value of the binary key. The key's value is | |||
| interpreted by the 'private-key-format' field."; | interpreted by the 'private-key-format' field."; | |||
| } | } | |||
| } | } | |||
| case hidden-private-key { | case hidden-private-key { | |||
| if-feature "hidden-private-keys"; | if-feature "hidden-private-keys"; | |||
| leaf hidden-private-key { | leaf hidden-private-key { | |||
| type empty; | type empty; | |||
| must 'not(../private-key-format)'; | must 'not(../private-key-format)'; | |||
| description | description | |||
| "A hidden key. It is of type 'empty' as its value is | "A hidden key. It is of type 'empty' as its value is | |||
| inaccessible via management interfaces. Though hidden | inaccessible via management interfaces. Though hidden | |||
| to users, such keys are not hidden to the server and | to users, such keys are not hidden to the server and | |||
| and may be referenced by configuration to indicate which | may be referenced by configuration to indicate which | |||
| key a server should use for a cryptographic operation. | key a server should use for a cryptographic operation. | |||
| How such keys are created is outside the scope of this | How such keys are created is outside the scope of this | |||
| module."; | module."; | |||
| } | } | |||
| } | } | |||
| case encrypted-private-key { | case encrypted-private-key { | |||
| if-feature "encrypted-private-keys"; | if-feature "encrypted-private-keys"; | |||
| container encrypted-private-key { | container encrypted-private-key { | |||
| must '../private-key-format'; | must '../private-key-format'; | |||
| description | description | |||
| skipping to change at page 45, line 47 ¶ | skipping to change at line 2040 ¶ | |||
| } | } | |||
| } | } | |||
| } | } | |||
| grouping asymmetric-key-pair-grouping { | grouping asymmetric-key-pair-grouping { | |||
| description | description | |||
| "A private key and, optionally, its associated public key. | "A private key and, optionally, its associated public key. | |||
| Implementations MUST ensure that the two keys, when both | Implementations MUST ensure that the two keys, when both | |||
| are specified, are a matching pair."; | are specified, are a matching pair."; | |||
| uses public-key-grouping { | uses public-key-grouping { | |||
| refine public-key-format { | refine "public-key-format" { | |||
| mandatory false; | mandatory false; | |||
| } | } | |||
| refine public-key { | refine "public-key" { | |||
| mandatory false; | mandatory false; | |||
| } | } | |||
| } | } | |||
| uses private-key-grouping; | uses private-key-grouping; | |||
| } | } | |||
| grouping certificate-expiration-grouping { | grouping certificate-expiration-grouping { | |||
| description | description | |||
| "A notification for when a certificate is about to, or | "A notification for when a certificate is about to expire or | |||
| already has, expired."; | has already expired."; | |||
| notification certificate-expiration { | notification certificate-expiration { | |||
| if-feature "certificate-expiration-notification"; | if-feature "certificate-expiration-notification"; | |||
| description | description | |||
| "A notification indicating that the configured certificate | "A notification indicating that the configured certificate | |||
| is either about to expire or has already expired. When to | is either about to expire or has already expired. When to | |||
| send notifications is an implementation specific decision, | send notifications is an implementation-specific decision, | |||
| but it is RECOMMENDED that a notification be sent once a | but it is RECOMMENDED that a notification be sent once a | |||
| month for 3 months, then once a week for four weeks, and | month for 3 months, then once a week for four weeks, and | |||
| then once a day thereafter until the issue is resolved. | then once a day thereafter until the issue is resolved. | |||
| If the certificate's Issuer maintains a Certificate | If the certificate's issuer maintains a Certificate | |||
| Revocation List (CRL), the expiration notification MAY | Revocation List (CRL), the expiration notification MAY | |||
| be sent if the CRL is about to expire."; | be sent if the CRL is about to expire."; | |||
| leaf expiration-date { | leaf expiration-date { | |||
| type yang:date-and-time; | type yang:date-and-time; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Identifies the expiration date on the certificate."; | "Identifies the expiration date on the certificate."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| grouping trust-anchor-cert-grouping { | grouping trust-anchor-cert-grouping { | |||
| description | description | |||
| "A trust anchor certificate, and a notification for when | "A trust anchor certificate and a notification for when | |||
| it is about to (or already has) expire."; | it is about to expire or has already expired."; | |||
| leaf cert-data { | leaf cert-data { | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| type trust-anchor-cert-cms; | type trust-anchor-cert-cms; | |||
| description | description | |||
| "The binary certificate data for this certificate."; | "The binary certificate data for this certificate."; | |||
| } | } | |||
| uses certificate-expiration-grouping; | uses certificate-expiration-grouping; | |||
| } | } | |||
| grouping end-entity-cert-grouping { | grouping end-entity-cert-grouping { | |||
| description | description | |||
| "An end entity certificate, and a notification for when | "An end-entity certificate and a notification for when | |||
| it is about to (or already has) expire. Implementations | it is about to expire or has already expired. Implementations | |||
| SHOULD assert that, where used, the end entity certificate | SHOULD assert that, where used, the end-entity certificate | |||
| contains the expected public key."; | contains the expected public key."; | |||
| leaf cert-data { | leaf cert-data { | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| type end-entity-cert-cms; | type end-entity-cert-cms; | |||
| description | description | |||
| "The binary certificate data for this certificate."; | "The binary certificate data for this certificate."; | |||
| } | } | |||
| uses certificate-expiration-grouping; | uses certificate-expiration-grouping; | |||
| } | } | |||
| skipping to change at page 47, line 26 ¶ | skipping to change at line 2115 ¶ | |||
| description | description | |||
| "Defines the 'generate-csr' action."; | "Defines the 'generate-csr' action."; | |||
| action generate-csr { | action generate-csr { | |||
| if-feature "csr-generation"; | if-feature "csr-generation"; | |||
| nacm:default-deny-all; | nacm:default-deny-all; | |||
| description | description | |||
| "Generates a certificate signing request structure for | "Generates a certificate signing request structure for | |||
| the associated asymmetric key using the passed subject | the associated asymmetric key using the passed subject | |||
| and attribute values. | and attribute values. | |||
| This action statement is only available when the | This 'action' statement is only available when the | |||
| associated 'public-key-format' node's value is | associated 'public-key-format' node's value is | |||
| 'subject-public-key-info-format'."; | 'subject-public-key-info-format'."; | |||
| input { | input { | |||
| leaf csr-format { | leaf csr-format { | |||
| type identityref { | type identityref { | |||
| base csr-format; | base csr-format; | |||
| } | } | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "Specifies the format for the returned certificate."; | "Specifies the format for the returned certificate."; | |||
| } | } | |||
| leaf csr-info { | leaf csr-info { | |||
| type csr-info; | type csr-info; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "A CertificationRequestInfo structure, as defined in | "A CertificationRequestInfo structure, as defined in | |||
| RFC 2986. | RFC 2986. | |||
| Enables the client to provide a fully-populated | Enables the client to provide a fully populated | |||
| CertificationRequestInfo structure that the server | CertificationRequestInfo structure that the server | |||
| only needs to sign in order to generate the complete | only needs to sign in order to generate the complete | |||
| 'CertificationRequest' structure to return in the | CertificationRequest structure to return in the | |||
| 'output'. | 'output'. | |||
| The 'AlgorithmIdentifier' field contained inside | The 'AlgorithmIdentifier' field contained inside | |||
| the 'SubjectPublicKeyInfo' field MUST be one known | the 'SubjectPublicKeyInfo' field MUST be one known | |||
| to be supported by the device."; | to be supported by the device."; | |||
| reference | reference | |||
| "RFC 2986: | "RFC 2986: | |||
| PKCS #10: Certification Request Syntax Specification | PKCS #10: Certification Request Syntax Specification | |||
| RFC AAAA: | RFC 9640: | |||
| YANG Data Types and Groupings for Cryptography"; | YANG Data Types and Groupings for Cryptography"; | |||
| } | } | |||
| } | } | |||
| output { | output { | |||
| choice csr-type { | choice csr-type { | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "A choice amongst certificate signing request formats. | "A choice amongst certificate signing request formats. | |||
| Additional formats MAY be augmented into this 'choice' | Additional formats MAY be augmented into this 'choice' | |||
| statement by future efforts."; | statement by future efforts."; | |||
| skipping to change at page 48, line 33 ¶ | skipping to change at line 2168 ¶ | |||
| leaf p10-csr { | leaf p10-csr { | |||
| type p10-csr; | type p10-csr; | |||
| description | description | |||
| "A CertificationRequest, as defined in RFC 2986."; | "A CertificationRequest, as defined in RFC 2986."; | |||
| } | } | |||
| description | description | |||
| "A CertificationRequest, as defined in RFC 2986."; | "A CertificationRequest, as defined in RFC 2986."; | |||
| reference | reference | |||
| "RFC 2986: | "RFC 2986: | |||
| PKCS #10: Certification Request Syntax Specification | PKCS #10: Certification Request Syntax Specification | |||
| RFC AAAA: | RFC 9640: | |||
| YANG Data Types and Groupings for Cryptography"; | YANG Data Types and Groupings for Cryptography"; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } // generate-csr-grouping | } // generate-csr-grouping | |||
| grouping asymmetric-key-pair-with-cert-grouping { | grouping asymmetric-key-pair-with-cert-grouping { | |||
| description | description | |||
| "A private/public key pair and an associated certificate. | "A private/public key pair and an associated certificate. | |||
| skipping to change at page 49, line 32 ¶ | skipping to change at line 2216 ¶ | |||
| refine "cert-data" { | refine "cert-data" { | |||
| mandatory true; | mandatory true; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| uses generate-csr-grouping; | uses generate-csr-grouping; | |||
| } // asymmetric-key-pair-with-certs-grouping | } // asymmetric-key-pair-with-certs-grouping | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 3. Security Considerations | 3. Security Considerations | |||
| 3.1. No Support for CRMF | 3.1. No Support for CRMF | |||
| This document uses PKCS #10 [RFC2986] for the "generate-certificate- | This document uses PKCS #10 [RFC2986] for the "generate-csr" action. | |||
| signing-request" action. The use of Certificate Request Message | The use of Certificate Request Message Format (CRMF) [RFC4211] was | |||
| Format (CRMF) [RFC4211] was considered, but it was unclear if there | considered, but it was unclear if there was market demand for it. If | |||
| was market demand for it. If it is desired to support CRMF in the | it is desired to support CRMF in the future, a backwards compatible | |||
| future, a backwards compatible solution can be defined at that time. | solution can be defined at that time. | |||
| 3.2. No Support for Key Generation | 3.2. No Support for Key Generation | |||
| Early revisions of this document included "rpc" statements for | Early revisions of this document included "rpc" statements for | |||
| generating symmetric and asymmetric keys. These statements were | generating symmetric and asymmetric keys. These statements were | |||
| removed due to an inability to obtain consensus for how to | removed due to an inability to obtain consensus for how to | |||
| generically identify the key-algorithm to use. Hence, the solution | generically identify the key algorithm to use. Hence, the solution | |||
| presented in this document only supports keys to be configured via an | presented in this document only supports keys to be configured via an | |||
| external client. | external client. | |||
| Separate protocol-specific modules can present protocol-specific key- | Separate protocol-specific modules can present protocol-specific key- | |||
| generating RPCs (e.g., the "generate-public-key" RPC in | generating RPCs (e.g., the "generate-asymmetric-key-pair" RPC in | |||
| [I-D.ietf-netconf-ssh-client-server] and | [RFC9644] and [RFC9645]). | |||
| [I-D.ietf-netconf-tls-client-server]). | ||||
| 3.3. Unconstrained Public Key Usage | 3.3. Unconstrained Public Key Usage | |||
| This module defines the "public-key-grouping" grouping, which enables | This module defines the "public-key-grouping" grouping, which enables | |||
| the configuration of public keys without constraints on their usage, | the configuration of public keys without constraints on their usage, | |||
| e.g., what operations the key is allowed to be used for (encryption, | e.g., what operations the key is allowed to be used for (e.g., | |||
| verification, both). | encryption, verification, or both). | |||
| The "asymmetric-key-pair-grouping" grouping uses the aforementioned | The "asymmetric-key-pair-grouping" grouping uses the aforementioned | |||
| "public-key-grouping" grouping, and carries the same traits. | "public-key-grouping" grouping and carries the same traits. | |||
| The "asymmetric-key-pair-with-cert-grouping" grouping uses the | The "asymmetric-key-pair-with-cert-grouping" grouping uses the | |||
| aforementioned "asymmetric-key-pair-grouping" grouping, whereby | aforementioned "asymmetric-key-pair-grouping" grouping, whereby | |||
| associated certificates MUST constrain the usage of the public key | associated certificates MUST constrain the usage of the public key | |||
| according to local policy. | according to local policy. | |||
| 3.4. Unconstrained Private Key Usage | 3.4. Unconstrained Private Key Usage | |||
| This module defines the "asymmetric-key-pair-grouping" grouping, | This module defines the "asymmetric-key-pair-grouping" grouping, | |||
| which enables the configuration of private keys without constraints | which enables the configuration of private keys without constraints | |||
| on their usage, e.g., what operations the key is allowed to be used | on their usage, e.g., what operations the key is allowed to be used | |||
| for (e.g., signature, decryption, both). | for (e.g., signature, decryption, or both). | |||
| The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned | The "asymmetric-key-pair-with-cert-grouping" grouping uses the | |||
| "asymmetric-key-pair-grouping" grouping, whereby configured | aforementioned "asymmetric-key-pair-grouping" grouping, whereby | |||
| certificates (e.g., identity certificates) may constrain the use of | configured certificates (e.g., identity certificates) may constrain | |||
| the public key according to local policy. | the use of the public key according to local policy. | |||
| 3.5. Cleartext Passwords and Keys | 3.5. Cleartext Passwords and Keys | |||
| The module contained within this document enables, only when specific | The module contained within this document enables, only when specific | |||
| "feature" statements are enabled, for the cleartext value of | "feature" statements are enabled, for the cleartext value of | |||
| passwords and keys to be stored in the configuration database. | passwords and keys to be stored in the configuration database. | |||
| Storing cleartext values for passwords and keys is NOT RECOMMENDED. | Storing cleartext values for passwords and keys is NOT RECOMMENDED. | |||
| 3.6. Encrypting Passwords and Keys | 3.6. Encrypting Passwords and Keys | |||
| The module contained within this document enables cleartext passwords | The module contained within this document enables cleartext passwords | |||
| and keys to be encrypted via another key, either symmetric or | and keys to be encrypted via another key, either symmetric or | |||
| asymmetric. Both formats use a CMS structure (EncryptedData and | asymmetric. Both formats use a CMS structure (EncryptedData and | |||
| EnvelopedData respectively), which allows any encryption algorithm to | EnvelopedData, respectively), which allows any encryption algorithm | |||
| be used. | to be used. | |||
| To securely encrypt a password or key with a symmetric key, a proper | To securely encrypt a password or key with a symmetric key, a proper | |||
| block cipher mode such as an AEAD or CBC MUST be used. This ensures | block cipher mode, such as an Authenticated Encryption with | |||
| that a random IV is part of the input, which guarantees that the | Associated Data (AEAD) or Cipher Block Chaining (CBC), MUST be used. | |||
| output for encrypting the same password or key still produces a | This ensures that a random Initialization Vector (IV) is part of the | |||
| different unpredictable ciphertext. This avoids leaking that some | input, which guarantees that the output for encrypting the same | |||
| encrypted keys or passwords are the same and makes it much harder to | password or key still produces a different unpredictable ciphertext. | |||
| pre-generate rainbow tables to brute force attack weak passwords. | This avoids leaking that some encrypted keys or passwords are the | |||
| The ECB block cipher mode MUST NOT be used. | same and makes it much harder to pre-generate rainbow tables to | |||
| brute-force attack weak passwords. The Electronic Codebook (ECB) | ||||
| block cipher mode MUST NOT be used. | ||||
| 3.7. Deletion of Cleartext Key Values | 3.7. Deletion of Cleartext Key Values | |||
| This module defines storage for cleartext key values that SHOULD be | This module defines storage for cleartext key values that SHOULD be | |||
| zeroized when deleted, so as to prevent the remnants of their | zeroized when deleted so as to prevent the remnants of their | |||
| persisted storage locations from being analyzed in any meaningful | persisted storage locations from being analyzed in any meaningful | |||
| way. | way. | |||
| The cleartext key values are the "cleartext-symmetric-key" node | The cleartext key values are the "cleartext-symmetric-key" node | |||
| defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3) | defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3) | |||
| and the "cleartext-private-key" node defined in the "asymmetric-key- | and the "cleartext-private-key" node defined in the "asymmetric-key- | |||
| pair-grouping" grouping ("Section 2.1.4.6). | pair-grouping" grouping (Section 2.1.4.6). | |||
| 3.8. Considerations for the "ietf-crypto-types" YANG Module | 3.8. Considerations for the "ietf-crypto-types" YANG Module | |||
| This section follows the template defined in Section 3.7.1 of | This section is modeled after the template defined in Section 3.7.1 | |||
| [RFC8407]. | of [RFC8407]. | |||
| The YANG module in this document defines "grouping" statements that | The "ietf-crypto-types" YANG module defines "grouping" statements | |||
| are designed to be accessed via YANG based management protocols, such | that are designed to be accessed via YANG-based management protocols, | |||
| as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols | such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these | |||
| have mandatory-to-implement secure transport layers (e.g., SSH, TLS) | protocols have mandatory-to-implement secure transport layers (e.g., | |||
| with mutual authentication. | Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and | |||
| mandatory-to-implement mutual authentication. | ||||
| The Network Access Control Model (NACM) [RFC8341] provides the means | The Network Configuration Access Control Model (NACM) [RFC8341] | |||
| to restrict access for particular users to a pre-configured subset of | provides the means to restrict access for particular users to a | |||
| all available protocol operations and content. | preconfigured subset of all available protocol operations and | |||
| content. | ||||
| Since the module in this document only defines groupings, these | Since the module in this document only defines groupings, these | |||
| considerations are primarily for the designers of other modules that | considerations are primarily for the designers of other modules that | |||
| use these groupings. | use these groupings. | |||
| Some of the readable data nodes defined in this YANG module may be | Some of the readable data nodes defined in this YANG module may be | |||
| considered sensitive or vulnerable in some network environments. It | considered sensitive or vulnerable in some network environments. It | |||
| is thus important to control read access (e.g., via get, get-config, | is thus important to control read access (e.g., via get, get-config, | |||
| or notification) to these data nodes. The following subtrees and | or notification) to these data nodes. The following subtrees and | |||
| data nodes have particular sensitivity/vulnerability: | data nodes have particular sensitivity/vulnerability: | |||
| skipping to change at page 52, line 33 ¶ | skipping to change at line 2355 ¶ | |||
| operations such that, in normal use cases, it should never be | operations such that, in normal use cases, it should never be | |||
| returned to a client. For this reason, the NACM extension | returned to a client. For this reason, the NACM extension | |||
| "default-deny-all" has been applied to it. | "default-deny-all" has been applied to it. | |||
| * The "cleartext-private-key" node: | * The "cleartext-private-key" node: | |||
| The "cleartext-private-key" node defined in the "asymmetric- | The "cleartext-private-key" node defined in the "asymmetric- | |||
| key-pair-grouping" grouping is additionally sensitive to read | key-pair-grouping" grouping is additionally sensitive to read | |||
| operations such that, in normal use cases, it should never be | operations such that, in normal use cases, it should never be | |||
| returned to a client. For this reason, the NACM extension | returned to a client. For this reason, the NACM extension | |||
| "default-deny-all" has been applied. | "default-deny-all" has been applied to it. | |||
| * The "cert-data" node: | * The "cert-data" node: | |||
| The "cert-data" node, defined in both the "trust-anchor-cert- | The "cert-data" node defined in both the "trust-anchor-cert- | |||
| grouping" and "end-entity-cert-grouping" groupings, is | grouping" and "end-entity-cert-grouping" groupings is | |||
| additionally sensitive to read operations, as certificates may | additionally sensitive to read operations, as certificates may | |||
| provide insight into which other resources/applications/servers | provide insight into which other resources/applications/servers | |||
| this particular server communicates with, as well as | this particular server communicates with, as well as | |||
| potentially divulge personally identifying information (e.g., | potentially divulge personally identifying information (e.g., | |||
| end-entity certificates). For this reason, the NACM extension | end-entity certificates). For this reason, the NACM extension | |||
| "default-deny-all" has been applied. | "default-deny-all" has been applied to it. | |||
| All the writable data nodes defined by all the groupings defined in | All the writable data nodes defined by all the groupings defined in | |||
| this module may be considered sensitive or vulnerable in some network | this module may be considered sensitive or vulnerable in some network | |||
| environments. For instance, even the modification of a public key or | environments. For instance, even the modification of a public key or | |||
| a certificate can dramatically alter the implemented security policy. | a certificate can dramatically alter the implemented security policy. | |||
| For this reason, the NACM extension "default-deny-write" has been | For this reason, the NACM extension "default-deny-write" has been | |||
| applied to all the data nodes defined in the module. | applied to all the data nodes defined in the module. | |||
| Some of the operations in this YANG module may be considered | Some of the operations in this YANG module may be considered | |||
| sensitive or vulnerable in some network environments. It is thus | sensitive or vulnerable in some network environments. It is thus | |||
| important to control access to these operations. These are the | important to control access to these operations. These are the | |||
| operations and their sensitivity/vulnerability: | operations and their sensitivity/vulnerability: | |||
| * generate-certificate-signing-request: | * generate-csr: | |||
| This "action" statement SHOULD only be executed by authorized | This "action" statement SHOULD only be executed by authorized | |||
| users. For this reason, the NACM extension "default-deny-all" | users. For this reason, the NACM extension "default-deny-all" | |||
| has been applied. Note that NACM uses "default-deny-all" to | has been applied. Note that NACM uses "default-deny-all" to | |||
| protect "RPC" and "action" statements; it does not define, | protect "rpc" and "action" statements; it does not define, | |||
| e.g., an extension called "default-deny-execute". | e.g., an extension called "default-deny-execute". | |||
| For this action, it is RECOMMENDED that implementations assert | For this action, it is RECOMMENDED that implementations assert | |||
| channel binding [RFC5056], so as to ensure that the application | channel binding [RFC5056] so as to ensure that the application | |||
| layer that sent the request is the same as the device | layer that sent the request is the same as the device | |||
| authenticated when the secure transport layer was established. | authenticated when the secure transport layer was established. | |||
| 4. IANA Considerations | 4. IANA Considerations | |||
| 4.1. The "IETF XML" Registry | 4.1. The IETF XML Registry | |||
| This document registers one URI in the "ns" subregistry of the "IETF | IANA has registered the following URI in the "ns" registry of the | |||
| XML" registry [RFC3688]. Following the format in [RFC3688], the | "IETF XML Registry" [RFC3688]. | |||
| following registration is requested: | ||||
| URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types | URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types | |||
| Registrant Contact: The IESG | Registrant Contact: The IESG | |||
| XML: N/A, the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
| 4.2. The "YANG Module Names" Registry | 4.2. The YANG Module Names Registry | |||
| This document registers one YANG module in the "YANG Module Names" | IANA has registered the following YANG module in the "YANG Module | |||
| registry [RFC6020]. Following the format in [RFC6020], the following | Names" registry [RFC6020]. | |||
| registration is requested: | ||||
| name: ietf-crypto-types | Name: ietf-crypto-types | |||
| namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types | Namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types | |||
| prefix: ct | Prefix: ct | |||
| reference: RFC AAAA | Reference: RFC 9640 | |||
| 5. References | 5. References | |||
| 5.1. Normative References | 5.1. Normative References | |||
| [ITU.X680.2021] | [ITU.X680.2021] | |||
| International Telecommunication Union, "Information | ITU-T, "Information technology - Abstract Syntax Notation | |||
| technology - Abstract Syntax Notation One (ASN.1): | One (ASN.1): Specification of basic notation", ITU-T | |||
| Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, | ||||
| Specification of basic notation", ITU-T Recommendation | ||||
| X.680, ISO/IEC 8824-1:2021, February 2021, | ||||
| <https://www.itu.int/rec/T-REC-X.680-202102-I>. | <https://www.itu.int/rec/T-REC-X.680-202102-I>. | |||
| [ITU.X690.2021] | [ITU.X690.2021] | |||
| International Telecommunication Union, "Information | ITU-T, "Information Technology - ASN.1 encoding rules: | |||
| Technology - ASN.1 encoding rules: Specification of Basic | Specification of Basic Encoding Rules (BER), Canonical | |||
| Encoding Rules (BER), Canonical Encoding Rules (CER) and | Encoding Rules (CER) and Distinguished Encoding Rules | |||
| Distinguished Encoding Rules (DER)", ITU-T Recommendation | (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021, | |||
| X.690, ISO/IEC 8825-1:2021, February 2021, | February 2021, | |||
| <https://www.itu.int/rec/T-REC-X.690-202102-I>. | <https://www.itu.int/rec/T-REC-X.690-202102-I>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | ||||
| Request Syntax Specification Version 1.7", RFC 2986, | ||||
| DOI 10.17487/RFC2986, November 2000, | ||||
| <https://www.rfc-editor.org/info/rfc2986>. | ||||
| [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | ||||
| Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, | ||||
| January 2006, <https://www.rfc-editor.org/info/rfc4252>. | ||||
| [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | |||
| Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, | Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, | |||
| January 2006, <https://www.rfc-editor.org/info/rfc4253>. | January 2006, <https://www.rfc-editor.org/info/rfc4253>. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
| (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
| <https://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | |||
| [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | |||
| RFC 5652, DOI 10.17487/RFC5652, September 2009, | RFC 5652, DOI 10.17487/RFC5652, September 2009, | |||
| <https://www.rfc-editor.org/info/rfc5652>. | <https://www.rfc-editor.org/info/rfc5652>. | |||
| [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key | ||||
| Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5915>. | ||||
| [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, | [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, | |||
| DOI 10.17487/RFC5958, August 2010, | DOI 10.17487/RFC5958, August 2010, | |||
| <https://www.rfc-editor.org/info/rfc5958>. | <https://www.rfc-editor.org/info/rfc5958>. | |||
| [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax | [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax | |||
| (CMS) Symmetric Key Package Content Type", RFC 6031, | (CMS) Symmetric Key Package Content Type", RFC 6031, | |||
| DOI 10.17487/RFC6031, December 2010, | DOI 10.17487/RFC6031, December 2010, | |||
| <https://www.rfc-editor.org/info/rfc6031>. | <https://www.rfc-editor.org/info/rfc6031>. | |||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
| and A. Bierman, Ed., "Network Configuration Protocol | ||||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6241>. | ||||
| [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., | [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., | |||
| Galperin, S., and C. Adams, "X.509 Internet Public Key | Galperin, S., and C. Adams, "X.509 Internet Public Key | |||
| Infrastructure Online Certificate Status Protocol - OCSP", | Infrastructure Online Certificate Status Protocol - OCSP", | |||
| RFC 6960, DOI 10.17487/RFC6960, June 2013, | RFC 6960, DOI 10.17487/RFC6960, June 2013, | |||
| <https://www.rfc-editor.org/info/rfc6960>. | <https://www.rfc-editor.org/info/rfc6960>. | |||
| [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | |||
| RFC 6991, DOI 10.17487/RFC6991, July 2013, | RFC 6991, DOI 10.17487/RFC6991, July 2013, | |||
| <https://www.rfc-editor.org/info/rfc6991>. | <https://www.rfc-editor.org/info/rfc6991>. | |||
| skipping to change at page 55, line 23 ¶ | skipping to change at line 2502 ¶ | |||
| [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | |||
| RFC 7950, DOI 10.17487/RFC7950, August 2016, | RFC 7950, DOI 10.17487/RFC7950, August 2016, | |||
| <https://www.rfc-editor.org/info/rfc7950>. | <https://www.rfc-editor.org/info/rfc7950>. | |||
| [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, | [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, | |||
| "PKCS #1: RSA Cryptography Specifications Version 2.2", | "PKCS #1: RSA Cryptography Specifications Version 2.2", | |||
| RFC 8017, DOI 10.17487/RFC8017, November 2016, | RFC 8017, DOI 10.17487/RFC8017, November 2016, | |||
| <https://www.rfc-editor.org/info/rfc8017>. | <https://www.rfc-editor.org/info/rfc8017>. | |||
| [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | ||||
| Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8040>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | |||
| Access Control Model", STD 91, RFC 8341, | Access Control Model", STD 91, RFC 8341, | |||
| DOI 10.17487/RFC8341, March 2018, | DOI 10.17487/RFC8341, March 2018, | |||
| <https://www.rfc-editor.org/info/rfc8341>. | <https://www.rfc-editor.org/info/rfc8341>. | |||
| 5.2. Informative References | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8446>. | ||||
| [I-D.ietf-netconf-crypto-types] | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Watsen, K., "YANG Data Types and Groupings for | Multiplexed and Secure Transport", RFC 9000, | |||
| Cryptography", Work in Progress, Internet-Draft, draft- | DOI 10.17487/RFC9000, May 2021, | |||
| ietf-netconf-crypto-types-33, 1 March 2024, | <https://www.rfc-editor.org/info/rfc9000>. | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| crypto-types-33>. | ||||
| [I-D.ietf-netconf-http-client-server] | 5.2. Informative References | |||
| [HTTP-CLIENT-SERVER] | ||||
| Watsen, K., "YANG Groupings for HTTP Clients and HTTP | Watsen, K., "YANG Groupings for HTTP Clients and HTTP | |||
| Servers", Work in Progress, Internet-Draft, draft-ietf- | Servers", Work in Progress, Internet-Draft, draft-ietf- | |||
| netconf-http-client-server-19, 1 March 2024, | netconf-http-client-server-23, 15 August 2024, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| http-client-server-19>. | ||||
| [I-D.ietf-netconf-keystore] | ||||
| Watsen, K., "A YANG Data Model for a Keystore and Keystore | ||||
| Operations", Work in Progress, Internet-Draft, draft-ietf- | ||||
| netconf-keystore-34, 1 March 2024, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | |||
| keystore-34>. | http-client-server-23>. | |||
| [I-D.ietf-netconf-netconf-client-server] | [NETCONF-CLIENT-SERVER] | |||
| Watsen, K., "NETCONF Client and Server Models", Work in | Watsen, K., "NETCONF Client and Server Models", Work in | |||
| Progress, Internet-Draft, draft-ietf-netconf-netconf- | Progress, Internet-Draft, draft-ietf-netconf-netconf- | |||
| client-server-35, 1 March 2024, | client-server-37, 14 August 2024, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | |||
| netconf-client-server-35>. | netconf-client-server-37>. | |||
| [I-D.ietf-netconf-restconf-client-server] | [RESTCONF-CLIENT-SERVER] | |||
| Watsen, K., "RESTCONF Client and Server Models", Work in | Watsen, K., "RESTCONF Client and Server Models", Work in | |||
| Progress, Internet-Draft, draft-ietf-netconf-restconf- | Progress, Internet-Draft, draft-ietf-netconf-restconf- | |||
| client-server-35, 1 March 2024, | client-server-38, 14 August 2024, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| restconf-client-server-35>. | ||||
| [I-D.ietf-netconf-ssh-client-server] | ||||
| Watsen, K., "YANG Groupings for SSH Clients and SSH | ||||
| Servers", Work in Progress, Internet-Draft, draft-ietf- | ||||
| netconf-ssh-client-server-39, 1 March 2024, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| ssh-client-server-39>. | ||||
| [I-D.ietf-netconf-tcp-client-server] | ||||
| Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients | ||||
| and TCP Servers", Work in Progress, Internet-Draft, draft- | ||||
| ietf-netconf-tcp-client-server-23, 1 March 2024, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| tcp-client-server-23>. | ||||
| [I-D.ietf-netconf-tls-client-server] | ||||
| Watsen, K., "YANG Groupings for TLS Clients and TLS | ||||
| Servers", Work in Progress, Internet-Draft, draft-ietf- | ||||
| netconf-tls-client-server-40, 1 March 2024, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | ||||
| tls-client-server-40>. | ||||
| [I-D.ietf-netconf-trust-anchors] | ||||
| Watsen, K., "A YANG Data Model for a Truststore", Work in | ||||
| Progress, Internet-Draft, draft-ietf-netconf-trust- | ||||
| anchors-27, 1 March 2024, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | <https://datatracker.ietf.org/doc/html/draft-ietf-netconf- | |||
| trust-anchors-27>. | restconf-client-server-38>. | |||
| [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | ||||
| Request Syntax Specification Version 1.7", RFC 2986, | ||||
| DOI 10.17487/RFC2986, November 2000, | ||||
| <https://www.rfc-editor.org/info/rfc2986>. | ||||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
| DOI 10.17487/RFC3688, January 2004, | DOI 10.17487/RFC3688, January 2004, | |||
| <https://www.rfc-editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
| [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure | [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure | |||
| Certificate Request Message Format (CRMF)", RFC 4211, | Certificate Request Message Format (CRMF)", RFC 4211, | |||
| DOI 10.17487/RFC4211, September 2005, | DOI 10.17487/RFC4211, September 2005, | |||
| <https://www.rfc-editor.org/info/rfc4211>. | <https://www.rfc-editor.org/info/rfc4211>. | |||
| [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure | [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure | |||
| Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, | Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, | |||
| <https://www.rfc-editor.org/info/rfc5056>. | <https://www.rfc-editor.org/info/rfc5056>. | |||
| [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key | ||||
| Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5915>. | ||||
| [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
| the Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
| DOI 10.17487/RFC6020, October 2010, | DOI 10.17487/RFC6020, October 2010, | |||
| <https://www.rfc-editor.org/info/rfc6020>. | <https://www.rfc-editor.org/info/rfc6020>. | |||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | ||||
| and A. Bierman, Ed., "Network Configuration Protocol | ||||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6241>. | ||||
| [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for | [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for | |||
| System Management", RFC 7317, DOI 10.17487/RFC7317, August | System Management", RFC 7317, DOI 10.17487/RFC7317, August | |||
| 2014, <https://www.rfc-editor.org/info/rfc7317>. | 2014, <https://www.rfc-editor.org/info/rfc7317>. | |||
| [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
| Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | Interchange Format", STD 90, RFC 8259, | |||
| <https://www.rfc-editor.org/info/rfc8040>. | DOI 10.17487/RFC8259, December 2017, | |||
| <https://www.rfc-editor.org/info/rfc8259>. | ||||
| [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | |||
| BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | |||
| <https://www.rfc-editor.org/info/rfc8340>. | <https://www.rfc-editor.org/info/rfc8340>. | |||
| [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | |||
| and R. Wilton, "Network Management Datastore Architecture | and R. Wilton, "Network Management Datastore Architecture | |||
| (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | |||
| <https://www.rfc-editor.org/info/rfc8342>. | <https://www.rfc-editor.org/info/rfc8342>. | |||
| [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of | [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of | |||
| Documents Containing YANG Data Models", BCP 216, RFC 8407, | Documents Containing YANG Data Models", BCP 216, RFC 8407, | |||
| DOI 10.17487/RFC8407, October 2018, | DOI 10.17487/RFC8407, October 2018, | |||
| <https://www.rfc-editor.org/info/rfc8407>. | <https://www.rfc-editor.org/info/rfc8407>. | |||
| Appendix A. Change Log | [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | |||
| "Handling Long Lines in Content of Internet-Drafts and | ||||
| A.1. I-D to 00 | RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | |||
| <https://www.rfc-editor.org/info/rfc8792>. | ||||
| * Removed groupings and notifications. | ||||
| * Added typedefs for identityrefs. | ||||
| * Added typedefs for other RFC 5280 structures. | ||||
| * Added typedefs for other RFC 5652 structures. | ||||
| * Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. | ||||
| A.2. 00 to 01 | ||||
| * Moved groupings from the draft-ietf-netconf-keystore here. | ||||
| A.3. 01 to 02 | ||||
| * Removed unwanted "mandatory" and "must" statements. | ||||
| * Added many new crypto algorithms (thanks Haiguang!) | ||||
| * Clarified in asymmetric-key-pair-with-certs-grouping, in | ||||
| certificates/certificate/name/description, that if the name MUST | ||||
| NOT match the name of a certificate that exists independently in | ||||
| <operational>, enabling certs installed by the manufacturer (e.g., | ||||
| an IDevID). | ||||
| A.4. 02 to 03 | ||||
| * renamed base identity 'asymmetric-key-encryption-algorithm' to | ||||
| 'asymmetric-key-algorithm'. | ||||
| * added new 'asymmetric-key-algorithm' identities for secp192r1, | ||||
| secp224r1, secp256r1, secp384r1, and secp521r1. | ||||
| * removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes- | ||||
| 192-ccm, mac-aes-256-ccm, mac-aes-128-gcm, mac-aes-192-gcm, mac- | ||||
| aes-256-gcm, and mac-chacha20-poly1305. | ||||
| * for all -cbc and -ctr identities, renamed base identity | ||||
| 'symmetric-key-encryption-algorithm' to 'encryption-algorithm'. | ||||
| * for all -ccm and -gcm identities, renamed base identity | ||||
| 'symmetric-key-encryption-algorithm' to 'encryption-and-mac- | ||||
| algorithm' and renamed the identity to remove the "enc-" prefix. | ||||
| * for all the 'signature-algorithm' based identities, renamed from | ||||
| 'rsa-*' to 'rsassa-*'. | ||||
| * removed all of the "x509v3-" prefixed 'signature-algorithm' based | ||||
| identities. | ||||
| * added 'key-exchange-algorithm' based identities for 'rsaes-oaep' | ||||
| and 'rsaes-pkcs1-v1_5'. | ||||
| * renamed typedef 'symmetric-key-encryption-algorithm-ref' to | ||||
| 'symmetric-key-algorithm-ref'. | ||||
| * renamed typedef 'asymmetric-key-encryption-algorithm-ref' to | ||||
| 'asymmetric-key-algorithm-ref'. | ||||
| * added typedef 'encryption-and-mac-algorithm-ref'. | ||||
| * Updated copyright date, boilerplate template, affiliation, and | ||||
| folding algorithm. | ||||
| A.5. 03 to 04 | ||||
| * ran YANG module through formatter. | ||||
| A.6. 04 to 05 | ||||
| * fixed broken symlink causing reformatted YANG module to not show. | ||||
| A.7. 05 to 06 | ||||
| * Added NACM annotations. | ||||
| * Updated Security Considerations section. | ||||
| * Added 'asymmetric-key-pair-with-cert-grouping' grouping. | ||||
| * Removed text from 'permanently-hidden' enum regarding such keys | ||||
| not being backed up or restored. | ||||
| * Updated the boilerplate text in module-level "description" | ||||
| statement to match copyeditor convention. | ||||
| * Added an explanation to the 'public-key-grouping' and 'asymmetric- | ||||
| key-pair-grouping' statements as for why the nodes are not | ||||
| mandatory (e.g., because they may exist only in <operational>. | ||||
| * Added 'must' expressions to the 'public-key-grouping' and | ||||
| 'asymmetric-key-pair-grouping' statements ensuring sibling nodes | ||||
| are either all exist or do not all exist. | ||||
| * Added an explanation to the 'permanently-hidden' that the value | ||||
| cannot be configured directly by clients and servers MUST fail any | ||||
| attempt to do so. | ||||
| * Added 'trust-anchor-certs-grouping' and 'end-entity-certs- | ||||
| grouping' (the plural form of existing groupings). | ||||
| * Now states that keys created in <operational> by the *-hidden-key | ||||
| actions are bound to the lifetime of the parent 'config true' | ||||
| node, and that subsequent invocations of either action results in | ||||
| a failure. | ||||
| A.8. 06 to 07 | ||||
| * Added clarifications that implementations SHOULD assert that | ||||
| configured certificates contain the matching public key. | ||||
| * Replaced the 'generate-hidden-key' and 'install-hidden-key' | ||||
| actions with special 'crypt-hash' -like input/output values. | ||||
| A.9. 07 to 08 | ||||
| * Removed the 'generate-key and 'hidden-key' features. | ||||
| * Added grouping symmetric-key-grouping | ||||
| * Modified 'asymmetric-key-pair-grouping' to have a 'choice' | ||||
| statement for the keystone module to augment into, as well as | ||||
| replacing the 'union' with leafs (having different NACM settings. | ||||
| A.10. 08 to 09 | ||||
| * Converting algorithm from identities to enumerations. | ||||
| A.11. 09 to 10 | ||||
| * All the below changes are to the algorithm enumerations defined in | ||||
| ietf-crypto-types. | ||||
| * Add in support for key exchange over x.25519 and x.448 based on | ||||
| RFC 8418. | ||||
| * Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512 | ||||
| * Revise/add in enum of signature algorithm for x25519 and x448 | ||||
| * Add in des3-cbc-sha1 for IPSec | ||||
| * Add in sha1-des3-kd for IPSec | ||||
| * Add in definit for rc4-hmac and rc4-hmac-exp. These two | ||||
| algorithms have been deprecated in RFC 8429. But some existing | ||||
| draft in i2nsf may still want to use them. | ||||
| * Add x25519 and x448 curve for asymmetric algorithms | ||||
| * Add signature algorithms ed25519, ed25519-cts, ed25519ph | ||||
| * add signature algorithms ed448, ed448ph | ||||
| * Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) | ||||
| A.12. 10 to 11 | ||||
| * Added a "key-format" identity. | ||||
| * Added symmetric keys to the example in Section 2.2. | ||||
| A.13. 11 to 12 | ||||
| * Removed all non-essential (to NC/RC) algorithm types. | ||||
| * Moved remaining algorithm types each into its own module. | ||||
| * Added a 'config false' "algorithms-supported" list to each of the | ||||
| algorithm-type modules. | ||||
| A.14. 12 to 13 | ||||
| * Added the four features: "[encrypted-]one-[a]symmetric-key- | ||||
| format", each protecting a 'key-format' identity of the same name. | ||||
| * Added 'must' expressions asserting that the 'key-format' leaf | ||||
| exists whenever a non-hidden key is specified. | ||||
| * Improved the 'description' statements and added 'reference' | ||||
| statements for the 'key-format' identities. | ||||
| * Added a questionable forward reference to "encrypted-*" leafs in a | ||||
| couple 'when' expressions. | ||||
| * Did NOT move "config false" alg-supported lists to SSH/TLS drafts. | ||||
| A.15. 13 to 14 | ||||
| * Resolved the "FIXME: forward ref" issue by modulating 'must', | ||||
| 'when', and 'mandatory' expressions. | ||||
| * Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' | ||||
| actions from ietf-keystore to ietf-crypto-types, now as RPCs. | ||||
| * Cleaned up various description statements and removed lingering | ||||
| FIXMEs. | ||||
| * Converted the "iana-<alg-type>-algs" YANG modules to IANA | ||||
| registries with instructions for how to generate modules from the | ||||
| registries, whenever they may be updated. | ||||
| A.16. 14 to 15 | ||||
| * Removed the IANA-maintained registries for symmetric, asymmetric, | ||||
| and hash algorithms. | ||||
| * Removed the "generate-symmetric-key" and "generate-asymmetric-key" | ||||
| RPCs. | ||||
| * Removed the "algorithm" node in the various symmetric and | ||||
| asymmetric key groupings. | ||||
| * Added 'typedef csr' and 'feature certificate-signing-request- | ||||
| generation'. | ||||
| * Refined a usage of "end-entity-cert-grouping" to make the "cert" | ||||
| node mandatory true. | ||||
| * Added a "Note to Reviewers" note to first page. | ||||
| A.17. 15 to 16 | ||||
| * Updated draft title (refer to "Groupings" too). | ||||
| * Removed 'end-entity-certs-grouping' as it wasn't being used | ||||
| anywhere. | ||||
| * Removed 'trust-anchor-certs-grouping' as it was no longer being | ||||
| used after modifying 'inline-or-truststore-certs-grouping' to use | ||||
| lists (not leaf-lists). | ||||
| * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. | ||||
| * Added "csr-info" typedef, to complement the existing "csr" | ||||
| typedef. | ||||
| * Added "ocsp-request" and "ocsp-response" typedefs, to complement | ||||
| the existing "crl" typedef. | ||||
| * Added "encrypted" cases to both symmetric-key-grouping and | ||||
| asymmetric-key-pair-grouping (Moved from Keystore draft). | ||||
| * Expanded "Data Model Overview section(s) [remove "wall" of tree | ||||
| diagrams]. | ||||
| * Updated the Security Considerations section. | ||||
| A.18. 16 to 17 | ||||
| * [Re]-added a "Strength of Keys Configured" Security Consideration | ||||
| * Prefixed "cleartext-" in the "key" and "private-key" node names. | ||||
| A.19. 17 to 18 | ||||
| * Fixed issues found by the SecDir review of the "keystore" draft. | ||||
| * Added "password-grouping", discussed during the IETF 108 session. | ||||
| A.20. 18 to 19 | ||||
| * Added a "Unconstrained Public Key Usage" Security Consideration to | ||||
| address concern raised by SecDir of the 'truststore' draft. | ||||
| * Added a "Unconstrained Private Key Usage" Security Consideration | ||||
| to address concern raised by SecDir of the 'truststore' draft. | ||||
| * Changed the encryption strategy, after conferring with Russ | ||||
| Housley. | ||||
| * Added a "password-grouping" example to the "crypto-types-usage" | ||||
| example. | ||||
| * Added an "Encrypting Passwords" section to Security Consideration. | ||||
| * Addressed other comments raised by YANG Doctor. | ||||
| A.21. 19 to 20 | ||||
| * Nits found via YANG Doctors reviews. | ||||
| * Aligned modules with `pyang -f` formatting. | ||||
| A.22. 20 to 21 | ||||
| * Replaced "base64encodedvalue==" with "BASE64VALUE=". | ||||
| * Accommodated SecDir review by Valery Smyslov. | ||||
| A.23. 21 to 22 | ||||
| * fixup the 'WG Web' and 'WG List' lines in YANG module(s) | ||||
| * fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s) | ||||
| * added 'hidden-keys' feature. | ||||
| A.24. 22 to 23 | ||||
| * Fixed an example to reference correct key. | ||||
| * Fixed an example to not have line-returns around the encoding for | ||||
| a binary value. | ||||
| A.25. 23 to 24 | ||||
| * Added mandatory leaf "csr-format" to action "generate-csr". | ||||
| * s/certificate-signing-request/csr/g in the YANG module. | ||||
| A.26. 24 to 25 | ||||
| * Updated per Shepherd reviews impacting the suite of drafts. | ||||
| A.27. 25 to 26 | ||||
| * Updated per Shepherd reviews impacting the suite of drafts. | ||||
| A.28. 26 to 27 | ||||
| * Updated per Tom Petch and AD reviews. | ||||
| * Renamed numerous "feature" statements and some "grouping" | ||||
| statements (in YANG) | ||||
| * Added "csr-format" and "p10-csr-format" identities to doc (they | ||||
| were already in YANG) | ||||
| * Clarified that the 'rsa-private-key-format' and 'ec-private-key- | ||||
| format' formats must be encoded using DER | ||||
| * Added 'if-feature cleartext-passwords' statement to 'case | ||||
| cleartext-password' in grouping 'password-grouping'. | ||||
| * Added 'if-feature cleartext-keys' statement to 'case cleartext- | ||||
| key' in grouping 'symmetric-key-grouping'. | ||||
| * Added 'if-feature cleartext-cleartext-private-keys' statement to | ||||
| 'case cleartext-private-key' in grouping 'asymmetric-key- | ||||
| grouping'. | ||||
| * Updated Section titles. | ||||
| * Clarified Security Considerations about the "generate-public-key" | ||||
| RPCs. | ||||
| A.29. 27 to 28 | ||||
| * Mostly addresses AD review comments. | ||||
| * Also addresses on-list comment regarding public-keys being | ||||
| "mandatory true." | ||||
| * Added note to Editor to fix line foldings. | ||||
| * Factored 'private-key-grouping' from 'asymmetric-key-pair- | ||||
| grouping'. | ||||
| * Made public-key in 'asymmetric-key-pair-grouping' be "mandatory | ||||
| false". | ||||
| * Renamed 'encrypted-by-choice-grouping' to 'encrypted-by-grouping'. | ||||
| A.30. 28 to 29 | ||||
| * Addresses Gen-ART review by Dale Worley. | ||||
| * Addresses review by Tom Petch. | ||||
| A.31. 29 to 30 | ||||
| * Addresses 1st-round of IESG reviews. | ||||
| A.32. 30 to 32 | ||||
| * Addresses issues found in OpsDir of the ssh-client-server draft. | [RFC9641] Watsen, K., "A YANG Data Model for a Truststore", | |||
| RFC 9641, DOI 10.17487/RFC9641, October 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9641>. | ||||
| * Removed "Strength of Keys Conveyed" section. | [RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642, | |||
| DOI 10.17487/RFC9642, October 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9642>. | ||||
| * Renamed Security Considerations section s/Template for/ | [RFC9643] Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients | |||
| Considerations for/ | and TCP Servers", RFC 9643, DOI 10.17487/RFC9643, October | |||
| 2024, <https://www.rfc-editor.org/info/rfc9643>. | ||||
| * Improved Security Consideration for 'cert-data' node. | [RFC9644] Watsen, K., "YANG Groupings for SSH Clients and SSH | |||
| Servers", RFC 9644, DOI 10.17487/RFC9644, October 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9644>. | ||||
| A.33. 32 to 34 | [RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS | |||
| Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9645>. | ||||
| * Nothing changed. Only bumped for automation... | [W3C.REC-xml-20081126] | |||
| Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., | ||||
| and F. Yergeau, "Extensible Markup Language (XML) 1.0 | ||||
| (Fifth Edition)", World Wide Web Consortium | ||||
| Recommendation REC-xml-20081126, November 2008, | ||||
| <https://www.w3.org/TR/2008/REC-xml-20081126/>. | ||||
| Acknowledgements | Acknowledgements | |||
| The authors would like to thank the following for lively discussions | The authors would like to thank the following for lively discussions | |||
| on list and in the halls (ordered by first name): Balázs Kovács, | on list and in the halls (ordered by first name): Balázs Kovács, | |||
| Carsten Bormann, Dale Worley, Eric Voit, Éric Vyncke, Francesca | Carsten Bormann, Dale Worley, Eric Voit, Éric Vyncke, Francesca | |||
| Palombini, Jürgen Schönwälder, Lars Eggert, Liang Xia, Martin | Palombini, Jürgen Schönwälder, Lars Eggert, Liang Xia, Mahesh | |||
| Björklund, Mahesh Jethanandani, Murray Kucherawy, Nick Hancock, Orie | Jethanandani, Martin Björklund, Murray Kucherawy, Nick Hancock, Orie | |||
| Steele, Paul Wouters, Rich Salz, Rifaat Shekh-Yusef, Rob Wilton, | Steele, Paul Wouters, Rich Salz, Rifaat Shekh-Yusef, Rob Wilton, | |||
| Roman Danyliw, Russ Housley, Sandra Murphy, Tom Petch, Valery | Roman Danyliw, Russ Housley, Sandra Murphy, Tom Petch, Valery | |||
| Smyslov, Wang Haiguang, Warren Kumari, and Zaheduzzaman Sarker. | Smyslov, Wang Haiguang, Warren Kumari, and Zaheduzzaman Sarker. | |||
| Author's Address | Author's Address | |||
| Kent Watsen | Kent Watsen | |||
| Watsen Networks | Watsen Networks | |||
| Email: kent+ietf@watsen.net | Email: kent+ietf@watsen.net | |||
| End of changes. 198 change blocks. | ||||
| 853 lines changed or deleted | 417 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||