1 module ietf-tls-common {
3 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
6 import iana-tls-cipher-suite-algs {
9 "RFC FFFF: YANG Groupings for TLS Clients and SSH Servers";
12 import ietf-crypto-types {
15 "RFC AAAA: YANG Data Types and Groupings for Cryptography";
18 import ietf-keystore {
21 "RFC CCCC: A YANG Data Model for a Keystore";
25 "IETF NETCONF (Network Configuration) Working Group";
28 "WG List: NETCONF WG list <mailto:netconf@ietf.org>
29 WG Web: https://datatracker.ietf.org/wg/netconf
30 Author: Kent Watsen <mailto:kent+ietf@watsen.net>
31 Author: Jeff Hartley <mailto:jeff.hartley@commscope.com>
32 Author: Gary Wu <mailto:garywu@cisco.com>";
35 "This module defines a common features and groupings for
36 Transport Layer Security (TLS).
38 Copyright (c) 2023 IETF Trust and the persons identified
39 as authors of the code. All rights reserved.
41 Redistribution and use in source and binary forms, with
42 or without modification, is permitted pursuant to, and
43 subject to the license terms contained in, the Revised
44 BSD License set forth in Section 4.c of the IETF Trust's
45 Legal Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info).
48 This version of this YANG module is part of RFC FFFF
49 (https://www.rfc-editor.org/info/rfcFFFF); see the RFC
50 itself for full legal notices.
52 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
53 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
54 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
55 are to be interpreted as described in BCP 14 (RFC 2119)
56 (RFC 8174) when, and only when, they appear in all
57 capitals, as shown here.";
63 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
71 "TLS Protocol Version 1.0 is supported. TLS 1.0 is obsolete
72 and thus it is NOT RECOMMENDED to enable this feature.";
74 "RFC 2246: The TLS Protocol Version 1.0";
80 "TLS Protocol Version 1.1 is supported. TLS 1.1 is obsolete
81 and thus it is NOT RECOMMENDED to enable this feature.";
83 "RFC 4346: The Transport Layer Security (TLS) Protocol
90 "TLS Protocol Version 1.2 is supported. TLS 1.2 is obsolete
91 and thus it is NOT RECOMMENDED to enable this feature.";
93 "RFC 5246: The Transport Layer Security (TLS) Protocol
99 "TLS Protocol Version 1.3 is supported.";
101 "RFC 8446: The Transport Layer Security (TLS)
102 Protocol Version 1.3";
105 feature hello-params {
107 "TLS hello message parameters are configurable.";
110 feature public-key-generation {
112 "Indicates that the server implements the
113 'generate-public-key' RPC.";
118 identity tls-version-base {
120 "Base identity used to identify TLS protocol versions.";
125 base tls-version-base;
128 "TLS Protocol Version 1.0.";
130 "RFC 2246: The TLS Protocol Version 1.0";
135 base tls-version-base;
138 "TLS Protocol Version 1.1.";
140 "RFC 4346: The Transport Layer Security (TLS) Protocol
146 base tls-version-base;
149 "TLS Protocol Version 1.2.";
151 "RFC 5246: The Transport Layer Security (TLS) Protocol
157 base tls-version-base;
159 "TLS Protocol Version 1.3.";
161 "RFC 8446: The Transport Layer Security (TLS)
162 Protocol Version 1.3";
167 typedef epsk-supported-hash {
179 "As per Section 4.2.11 of RFC 8446, the hash algorithm
180 supported by an instance of an External Pre-Shared
183 "RFC 8446: The Transport Layer Security (TLS)
184 Protocol Version 1.3";
190 grouping hello-params-grouping {
192 "A reusable grouping for TLS hello message parameters.";
194 "RFC 5246: The Transport Layer Security (TLS) Protocol
196 RFC 8446: The Transport Layer Security (TLS) Protocol
198 container tls-versions {
200 "Parameters regarding TLS versions.";
201 leaf-list tls-version {
203 base tls-version-base;
207 "Acceptable TLS protocol versions.
209 If this leaf-list is not configured (has zero elements)
210 the acceptable TLS protocol versions are implementation-
214 container cipher-suites {
216 "Parameters regarding cipher suites.";
217 leaf-list cipher-suite {
219 base tlscsa:cipher-suite-alg-base;
223 "Acceptable cipher suites in order of descending
224 preference. The configured host key algorithms should
225 be compatible with the algorithm used by the configured
226 private key. Please see Section 5 of RFC FFFF for
229 If this leaf-list is not configured (has zero elements)
230 the acceptable cipher suites are implementation-
233 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
236 } // hello-params-grouping
238 rpc generate-public-key {
239 if-feature "public-key-generation";
241 "Requests the device to generate an public key using
242 the specified key algorithm.";
245 type tlscsa:cipher-suite-algorithm-ref;
248 "The cipher suite algorithm that the generated key is
249 to work with. Implementations derive the public key
250 algorithm from the cipher suite algorithm. Example:
251 cipher suite 'tls-rsa-with-aes-256-cbc-sha256' maps
252 to the RSA public key.";
257 "Specifies the number of bits in the key to create.
258 For RSA keys, the minimum size is 1024 bits and
259 the default is 3072 bits. Generally, 3072 bits is
260 considered sufficient. DSA keys must be exactly 1024
261 bits as specified by FIPS 186-2. For elliptical
262 keys, the 'num-bits' value determines the key length
263 of the curve (e.g., 256, 384 or 521), where valid
264 values supported by the server are conveyed via an
265 unspecified mechanism. For some public algorithms,
266 the keys have a fixed length and thus the 'num-bits'
267 value is not specified.";
269 container private-key-encoding {
271 "Indicates how the private key is to be encoded.";
272 choice private-key-encoding {
275 "A choice amongst optional private key handling.";
277 if-feature "ct:cleartext-private-keys";
281 "Indicates that the private key is to be returned
282 as a cleartext value.";
286 if-feature "ct:encrypted-private-keys";
287 container encrypted {
289 "Indicates that the key is to be encrypted using
290 the specified symmetric or asymmetric key.";
291 uses ks:encrypted-by-grouping;
295 if-feature "ct:hidden-private-keys";
299 "Indicates that the private key is to be hidden.
301 Unlike the 'cleartext' and 'encrypt' options, the
302 key returned is a placeholder for an internally
303 stored key. See the 'Support for Built-in Keys'
304 section in RFC CCCC for information about hidden
312 uses ct:asymmetric-key-pair-grouping;
314 } // end generate-public-key