diff options
Diffstat (limited to 'vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin')
| -rw-r--r-- | vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin | 596 |
1 files changed, 596 insertions, 0 deletions
diff --git a/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin new file mode 100644 index 00000000..d1208bd2 --- /dev/null +++ b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin @@ -0,0 +1,596 @@ +<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-1"> + <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"><?xml version="1.0" encoding="UTF-8"?> +<module name="ietf-keystore" + xmlns="urn:ietf:params:xml:ns:yang:yin:1" + xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keystore" + xmlns:yang="urn:ietf:params:xml:ns:yang:ietf-yang-types"> + <yang-version value="1.1"/> + <namespace uri="urn:ietf:params:xml:ns:yang:ietf-keystore"/> + <prefix value="ks"/> + <import module="ietf-yang-types"> + <prefix value="yang"/> + <reference> + <text>RFC 6991: Common YANG Data Types</text> + </reference> + </import> + <organization> + <text>IETF NETCONF (Network Configuration) Working Group</text> + </organization> + <contact> + <text>WG Web: &lt;http://tools.ietf.org/wg/netconf/&gt; +WG List: &lt;mailto:netconf@ietf.org&gt; + +WG Chair: Mehmet Ersue + &lt;mailto:mehmet.ersue@nsn.com&gt; + +WG Chair: Mahesh Jethanandani + &lt;mailto:mjethanandani@gmail.com&gt; + +Editor: Kent Watsen + &lt;mailto:kwatsen@juniper.net&gt;</text> + </contact> + <description> + <text>This module defines a keystore to centralize management of +security credentials. + +Copyright (c) 2014 IETF Trust and the persons identified as +authors of the code. All rights reserved. + +Redistribution and use in source and binary forms, with or +without modification, is permitted pursuant to, and subject +to the license terms contained in, the Simplified BSD +License set forth in Section 4.c of the IETF Trust's +Legal Provisions Relating to IETF Documents +(http://trustee.ietf.org/license-info). + +This version of this YANG module is part of RFC VVVV; see +the RFC itself for full legal notices.</text> + </description> + <revision date="2016-10-31"> + <description> + <text>Initial version</text> + </description> + <reference> + <text>RFC VVVV: NETCONF Server and RESTCONF Server Configuration + Models</text> + </reference> + </revision> + <identity name="key-algorithm"> + <description> + <text>Base identity from which all key-algorithms are derived.</text> + </description> + </identity> + <identity name="rsa"> + <base name="key-algorithm"/> + <description> + <text>The RSA algorithm.</text> + </description> + <reference> + <text>RFC3447: Public-Key Cryptography Standards (PKCS) #1: + RSA Cryptography Specifications Version 2.1.</text> + </reference> + </identity> + <identity name="secp192r1"> + <base name="key-algorithm"/> + <description> + <text>The secp192r1 algorithm.</text> + </description> + <reference> + <text>RFC5480: + Elliptic Curve Cryptography Subject Public Key Information.</text> + </reference> + </identity> + <identity name="secp256r1"> + <base name="key-algorithm"/> + <description> + <text>The secp256r1 algorithm.</text> + </description> + <reference> + <text>RFC5480: + Elliptic Curve Cryptography Subject Public Key Information.</text> + </reference> + </identity> + <identity name="secp384r1"> + <base name="key-algorithm"/> + <description> + <text>The secp384r1 algorithm.</text> + </description> + <reference> + <text>RFC5480: + Elliptic Curve Cryptography Subject Public Key Information.</text> + </reference> + </identity> + <identity name="secp521r1"> + <base name="key-algorithm"/> + <description> + <text>The secp521r1 algorithm.</text> + </description> + <reference> + <text>RFC5480: + Elliptic Curve Cryptography Subject Public Key Information.</text> + </reference> + </identity> + <container name="keystore"> + <description> + <text>A list of private-keys and their associated certificates, as +well as lists of trusted certificates for client certificate +authentication. RPCs are provided to generate a new private +key and to generate a certificate signing requests.</text> + </description> + <container name="private-keys"> + <description> + <text>A list of private key maintained by the keystore.</text> + </description> + <list name="private-key"> + <key value="name"/> + <description> + <text>A private key.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for the private key.</text> + </description> + </leaf> + <leaf name="algorithm"> + <type name="identityref"> + <base name="key-algorithm"/> + </type> + <config value="false"/> + <description> + <text>The algorithm used by the private key.</text> + </description> + </leaf> + <leaf name="key-length"> + <type name="uint32"/> + <config value="false"/> + <description> + <text>The key-length used by the private key.</text> + </description> + </leaf> + <leaf name="public-key"> + <type name="binary"/> + <config value="false"/> + <mandatory value="true"/> + <description> + <text>An OneAsymmetricKey 'publicKey' structure as specified +by RFC 5958, Section 2 encoded using the ASN.1 +distinguished encoding rules (DER), as specified +in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 5958: + Asymmetric Key Packages +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + <container name="certificate-chains"> + <description> + <text>Certificate chains associated with this private key. +More than one chain per key is enabled to support, +for instance, a TPM-protected key that has associated +both IDevID and LDevID certificates.</text> + </description> + <list name="certificate-chain"> + <key value="name"/> + <description> + <text>A certificate chain for this public key.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for the certificate chain. The +name must be a unique across all private keys, not +just within this private key.</text> + </description> + </leaf> + <leaf-list name="certificate"> + <type name="binary"/> + <ordered-by value="user"/> + <description> + <text>An X.509 v3 certificate structure as specified by RFC +5280, Section 4 encoded using the ASN.1 distinguished +encoding rules (DER), as specified in ITU-T X.690. +The list of certificates that run from the server +certificate towards the trust anchor. The chain MAY +include the trust anchor certificate itself.</text> + </description> + <reference> + <text>RFC 5280: + Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile. +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf-list> + </list> + </container> + <action name="generate-certificate-signing-request"> + <description> + <text>Generates a certificate signing request structure for +the associated private key using the passed subject and +attribute values. Please review both the Security +Considerations and Design Considerations sections in +RFC VVVV for more information regarding this action +statement.</text> + </description> + <input> + <leaf name="subject"> + <type name="binary"/> + <mandatory value="true"/> + <description> + <text>The 'subject' field from the CertificationRequestInfo +structure as specified by RFC 2986, Section 4.1 encoded +using the ASN.1 distinguished encoding rules (DER), as +specified in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 2986: + PKCS #10: Certification Request Syntax Specification + Version 1.7. +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + <leaf name="attributes"> + <type name="binary"/> + <description> + <text>The 'attributes' field from the CertificationRequestInfo +structure as specified by RFC 2986, Section 4.1 encoded +using the ASN.1 distinguished encoding rules (DER), as +specified in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 2986: + PKCS #10: Certification Request Syntax Specification + Version 1.7. +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + </input> + <output> + <leaf name="certificate-signing-request"> + <type name="binary"/> + <mandatory value="true"/> + <description> + <text>A CertificationRequest structure as specified by RFC +2986, Section 4.1 encoded using the ASN.1 distinguished +encoding rules (DER), as specified in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 2986: + PKCS #10: Certification Request Syntax Specification + Version 1.7. +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + </output> + </action> + </list> + <action name="generate-private-key"> + <description> + <text>Requests the device to generate a private key using the +specified algorithm and key length.</text> + </description> + <input> + <leaf name="name"> + <type name="string"/> + <mandatory value="true"/> + <description> + <text>The name this private-key should have when listed +in /keystore/private-keys. As such, the passed +value must not match any existing 'name' value.</text> + </description> + </leaf> + <leaf name="algorithm"> + <type name="identityref"> + <base name="key-algorithm"/> + </type> + <mandatory value="true"/> + <description> + <text>The algorithm to be used when generating the key.</text> + </description> + </leaf> + <leaf name="key-length"> + <type name="uint32"/> + <description> + <text>For algorithms that need a key length specified +when generating the key.</text> + </description> + </leaf> + </input> + </action> + <action name="load-private-key"> + <description> + <text>Requests the device to load a private key</text> + </description> + <input> + <leaf name="name"> + <type name="string"/> + <mandatory value="true"/> + <description> + <text>The name this private-key should have when listed +in /keystore/private-keys. As such, the passed +value must not match any existing 'name' value.</text> + </description> + </leaf> + <leaf name="private-key"> + <type name="binary"/> + <mandatory value="true"/> + <description> + <text>An OneAsymmetricKey structure as specified by RFC +5958, Section 2 encoded using the ASN.1 distinguished +encoding rules (DER), as specified in ITU-T X.690. +Note that this is the raw private with no shrouding +to protect it. The strength of this private key +MUST NOT be greater than the strength of the secure +connection over which it is communicated. Devices +SHOULD fail this request if ever that happens.</text> + </description> + <reference> + <text>RFC 5958: + Asymmetric Key Packages +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + </input> + </action> + </container> + <list name="trusted-certificates"> + <key value="name"/> + <description> + <text>A list of trusted certificates. These certificates +can be used by a server to authenticate clients, or by clients +to authenticate servers. The certificates may be endpoint +specific or for certificate authorities (to authenticate many +clients at once. Each list of certificates SHOULD be specific +to a purpose, as the list as a whole may be referenced by other +modules. For instance, a NETCONF server model might point to +a list of certificates to use when authenticating client +certificates.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for this list of trusted certificates.</text> + </description> + </leaf> + <leaf name="description"> + <type name="string"/> + <description> + <text>An arbitrary description for this list of trusted +certificates.</text> + </description> + </leaf> + <list name="trusted-certificate"> + <key value="name"/> + <description> + <text>A trusted certificate for a specific use. Note, this +'certificate' is a list in order to encode any +associated intermediate certificates.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for this trusted certificate. Must +be unique across all lists of trusted certificates +(not just this list) so that a leafref to it from +another module can resolve to unique values.</text> + </description> + </leaf> + <leaf name="certificate"> + <type name="binary"/> + <description> + <text>An X.509 v3 certificate structure as specified by RFC +5280, Section 4 encoded using the ASN.1 distinguished +encoding rules (DER), as specified in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 5280: + Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile. +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + </list> + </list> + <list name="trusted-ssh-host-keys"> + <key value="name"/> + <description> + <text>A list of trusted host-keys. These host-keys can be used +by clients to authenticate SSH servers. The host-keys are +endpoint specific. Each list of host-keys SHOULD be +specific to a purpose, as the list as a whole may be +referenced by other modules. For instance, a NETCONF +client model might point to a list of host-keys to use +when authenticating servers host-keys.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for this list of trusted SSH host keys.</text> + </description> + </leaf> + <leaf name="description"> + <type name="string"/> + <description> + <text>An arbitrary description for this list of trusted SSH host +keys.</text> + </description> + </leaf> + <list name="trusted-host-key"> + <key value="name"/> + <description> + <text>A trusted host key.</text> + </description> + <leaf name="name"> + <type name="string"/> + <description> + <text>An arbitrary name for this trusted host-key. Must be +unique across all lists of trusted host-keys (not just +this list) so that a leafref to it from another module +can resolve to unique values. + +Note that, for when the SSH client is able to listen +for call-home connections as well, there is no reference +identifier (e.g., hostname, IP address, etc.) that it +can use to uniquely identify the server with. The +call-home draft recommends SSH servers use X.509v3 +certificates (RFC6187) when calling home.</text> + </description> + </leaf> + <leaf name="host-key"> + <type name="binary"/> + <mandatory value="true"/> + <description> + <text>An OneAsymmetricKey 'publicKey' structure as specified +by RFC 5958, Section 2 encoded using the ASN.1 +distinguished encoding rules (DER), as specified +in ITU-T X.690.</text> + </description> + <reference> + <text>RFC 5958: + Asymmetric Key Packages +ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER).</text> + </reference> + </leaf> + </list> + </list> + <container name="user-auth-credentials"> + <description> + <text>A list of user authentication credentials that can be used +by an SSH client to log into an SSH server, using any of +the supported authentication methods (e.g., password, +public key, client certificate, etc.).</text> + </description> + <list name="user-auth-credential"> + <key value="username"/> + <description> + <text>The authentication credentials for a specific user.</text> + </description> + <leaf name="username"> + <type name="string"/> + <description> + <text>The username of this user. This will be the username +used, for instance, to log into an SSH server.</text> + </description> + </leaf> + <list name="auth-method"> + <key value="priority"/> + <description> + <text>A method of authenticating as this user.</text> + </description> + <leaf name="priority"> + <type name="uint8"/> + <description> + <text>When multiple authentication methods in this list are +supported by the server, the one with the lowest priority +value will be the one that is used.</text> + </description> + </leaf> + <choice name="auth-type"> + <description> + <text>The authentication type.</text> + </description> + <leaf-list name="certificate"> + <type name="leafref"> + <path value="/keystore/private-keys/private-key/certificate-chains/certificate-chain/name"/> + </type> + <ordered-by value="user"/> + <description> + <text>A list of references to certificates that can be used +for user authentication. When multiple certificates +in this list supported by the server, the one that +comes before the others in the leaf-list will be +used.</text> + </description> + </leaf-list> + <leaf-list name="public-key"> + <type name="leafref"> + <path value="/keystore/private-keys/private-key/name"/> + </type> + <ordered-by value="user"/> + <description> + <text>A list of references to public keys that can be used +for user authentication. When multiple public keys +in this list supported by the server, the one that +comes before the others in the leaf-list will be +used.</text> + </description> + </leaf-list> + <leaf name="ciphertext-password"> + <type name="string"/> + <description> + <text>An ciphertext password. The method of encipherment +and how that method can be determined from this +string is implementation-specific.</text> + </description> + </leaf> + <leaf name="cleartext-password"> + <type name="string"/> + <description> + <text>An cleartext password.</text> + </description> + </leaf> + </choice> + </list> + </list> + </container> + </container> + <notification name="certificate-expiration"> + <description> + <text>A notification indicating that a configured certificate is +either about to expire or has already expired. When to send +notifications is an implementation specific decision, but +it is RECOMMENDED that a notification be sent once a month +for 3 months, then once a week for four weeks, and then once +a day thereafter.</text> + </description> + <leaf name="certificate"> + <type name="instance-identifier"/> + <mandatory value="true"/> + <description> + <text>Identifies which certificate is expiring or is expired.</text> + </description> + </leaf> + <leaf name="expiration-date"> + <type name="yang:date-and-time"/> + <mandatory value="true"/> + <description> + <text>Identifies the expiration date on the certificate.</text> + </description> + </leaf> + </notification> +</module> +</data> +</rpc-reply> |