draft-ietf-netconf-crypto-types-01.txt   draft-ietf-netconf-crypto-types-02.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track September 20, 2018 Intended status: Standards Track H. Wang
Expires: March 24, 2019 Expires: April 25, 2019 Huawei
October 22, 2018
Common YANG Data Types for Cryptography Common YANG Data Types for Cryptography
draft-ietf-netconf-crypto-types-01 draft-ietf-netconf-crypto-types-02
Abstract Abstract
This document defines YANG identities and typedefs useful for This document defines YANG identities, typedefs, the groupings useful
cryptographic applications. for cryptographic applications.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document. Editor instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
o "XXXX" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2018-09-20" --> the publication date of this draft o "2018-10-22" --> the publication date of this draft
The following Appendix section is to be removed prior to publication: The following Appendix section is to be removed prior to publication:
o Appendix A. Change Log o Appendix B. Change Log
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Crypto Types Module . . . . . . . . . . . . . . . . . . . 3 2. The Crypto Types Module . . . . . . . . . . . . . . . . . . . 3
2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 3. Security Considerations . . . . . . . . . . . . . . . . . . . 39
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 19 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 40
4.2. The YANG Module Names Registry . . . . . . . . . . . . . 20 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 40
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. Normative References . . . . . . . . . . . . . . . . . . 20 5.1. Normative References . . . . . . . . . . . . . . . . . . 40
5.2. Informative References . . . . . . . . . . . . . . . . . 21 5.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 45
A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 23 A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 45
A.2. The "generate-hidden-key" Action . . . . . . . . . . . . 25 A.2. The "generate-hidden-key" Action . . . . . . . . . . . . 47
A.3. The "install-hidden-key" Action . . . . . . . . . . . . . 26 A.3. The "install-hidden-key" Action . . . . . . . . . . . . . 48
A.4. The "generate-certificate-signing-request" Action . . . . 26 A.4. The "generate-certificate-signing-request" Action . . . . 49
A.5. The "certificate-expiration" Notification . . . . . . . . 27 A.5. The "certificate-expiration" Notification . . . . . . . . 50
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 51
B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 28 B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 51
B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 51
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document defines a YANG 1.1 [RFC7950] module specifying This document defines a YANG 1.1 [RFC7950] module specifying
identities and typedefs useful for cryptography. identities, typedefs, and groupings useful for cryptography.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The Crypto Types Module 2. The Crypto Types Module
2.1. Tree Diagram 2.1. Tree Diagram
This section provides a tree diagrams [RFC8340] for the "ietf-crypto- This section provides a tree diagram [RFC8340] for the "ietf-crypto-
types" module that, in addition to typedefs and identities, also types" module. Only the groupings as represented, as tree diagrams
presents groupings intended for external usage. have no means to represent identities or typedefs.
[Note: '\' line wrapping for formatting only]
module: ietf-crypto-types module: ietf-crypto-types
grouping asymmetric-key-pair-grouping grouping asymmetric-key-pair-grouping
+-- algorithm? ct:key-algorithm-ref +-- algorithm? asymmetric-key-encryption-algorithm-r\
ef
+-- public-key? binary +-- public-key? binary
+-- private-key? union +-- private-key? union
+---x generate-hidden-key +---x generate-hidden-key
| +---w input | +---w input
| +---w algorithm ct:key-algorithm-ref | +---w algorithm asymmetric-key-encryption-algorithm-ref
+---x install-hidden-key +---x install-hidden-key
+---w input +---w input
+---w algorithm ct:key-algorithm-ref +---w algorithm asymmetric-key-encryption-algorithm-r\
ef
+---w public-key? binary +---w public-key? binary
+---w private-key? binary +---w private-key? binary
grouping public-key-grouping grouping public-key-grouping
+-- algorithm? ct:key-algorithm-ref +-- algorithm? asymmetric-key-encryption-algorithm-ref
+-- public-key? binary +-- public-key? binary
grouping asymmetric-key-pair-with-certs-grouping grouping asymmetric-key-pair-with-certs-grouping
+-- algorithm? ct:key-algorithm-ref +-- algorithm?
| asymmetric-key-encryption-algorithm-ref
+-- public-key? binary +-- public-key? binary
+-- private-key? union +-- private-key? union
+---x generate-hidden-key +---x generate-hidden-key
| +---w input | +---w input
| +---w algorithm ct:key-algorithm-ref | +---w algorithm asymmetric-key-encryption-algorithm-ref
+---x install-hidden-key +---x install-hidden-key
| +---w input | +---w input
| +---w algorithm ct:key-algorithm-ref | +---w algorithm asymmetric-key-encryption-algorithm-r\
ef
| +---w public-key? binary | +---w public-key? binary
| +---w private-key? binary | +---w private-key? binary
+-- certificates +-- certificates
| +-- certificate* [name] | +-- certificate* [name]
| +-- name? string | +-- name? string
| +-- cert ct:end-entity-cert-cms | +-- cert? end-entity-cert-cms
| +---n certificate-expiration | +---n certificate-expiration
| +-- expiration-date? yang:date-and-time | +-- expiration-date yang:date-and-time
+---x generate-certificate-signing-request +---x generate-certificate-signing-request
+---w input +---w input
| +---w subject binary | +---w subject binary
| +---w attributes? binary | +---w attributes? binary
+--ro output +--ro output
+--ro certificate-signing-request binary +--ro certificate-signing-request binary
grouping end-entity-cert-grouping grouping end-entity-cert-grouping
+-- cert ct:end-entity-cert-cms +-- cert? end-entity-cert-cms
+---n certificate-expiration +---n certificate-expiration
+-- expiration-date? yang:date-and-time +-- expiration-date yang:date-and-time
grouping trust-anchor-cert-grouping grouping trust-anchor-cert-grouping
+-- cert ct:trust-anchor-cert-cms +-- cert? trust-anchor-cert-cms
+---n certificate-expiration
+-- expiration-date yang:date-and-time
2.2. YANG Module 2.2. YANG Module
This module has normative references to [RFC4253], [RFC5280], This module has normative references to [RFC2404], [RFC2986],
[RFC5480], [RFC5652], [RFC6991], [RFC8341] and [ITU.X690.2015]. [RFC3174], [RFC3565], [RFC3686], [RFC4106], [RFC4253], [RFC4279],
[RFC4309], [RFC4493], [RFC4494], [RFC4543], [RFC4868], [RFC5280],
[RFC5652], [RFC5656], [RFC5915], [RFC6187], [RFC6234], [RFC6239],
[RFC6507], [RFC6991], [RFC7539], [RFC7919], [RFC8017], [RFC8032],
[RFC8268], [RFC8332], [RFC8341], [RFC8422], [RFC8446], and
[ITU.X690.2015].
This module has informational references to [RFC2986], [RFC5915], This module has an informational reference to [RFC6125].
[RFC6125], [RFC6234], and [RFC8017]
<CODE BEGINS> file "ietf-crypto-types@2018-09-20.yang" <CODE BEGINS> file "ietf-crypto-types@2018-10-22.yang"
module ietf-crypto-types { module ietf-crypto-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types";
prefix "ct"; prefix "ct";
import ietf-yang-types { import ietf-yang-types {
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: <http://datatracker.ietf.org/wg/netconf/> "WG Web: <http://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net>"; <mailto:kwatsen@juniper.net>
description Author: Wang Haiguang
"This module defines common YANG types for cryptographic <wang.haiguang.shieldlab@huawei.com>";
applications.
Copyright (c) 2018 IETF Trust and the persons identified description
as authors of the code. All rights reserved. "This module defines common YANG types for cryptographic
applications.
Redistribution and use in source and binary forms, with Copyright (c) 2018 IETF Trust and the persons identified
or without modification, is permitted pursuant to, and as authors of the code. All rights reserved.
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 XXXX; see Redistribution and use in source and binary forms, with
the RFC itself for full legal notices."; 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).
revision "2018-09-20" { This version of this YANG module is part of RFC XXXX; see
description the RFC itself for full legal notices.";
"Initial version";
reference
"RFC XXXX: Common YANG Data Types for Cryptography";
}
/*****************************************/ revision "2018-10-22" {
/* Identities for Hashing Algorithms */ description
/*****************************************/ "Initial version";
reference
"RFC XXXX: Common YANG Data Types for Cryptography";
}
/**************************************/
/* Identities for Hash Algorithms */
/**************************************/
identity hash-algorithm { identity hash-algorithm {
description description
"A base identity for hash algorithm verification."; "A base identity for hash algorithm verification.";
} }
identity sha-256 { identity sha-224 {
base "hash-algorithm"; base "hash-algorithm";
description "The SHA-256 algorithm."; description "The SHA-224 algorithm.";
reference "RFC 6234: US Secure Hash Algorithms."; reference "RFC 6234: US Secure Hash Algorithms.";
} }
/*************************************/ identity sha-256 {
/* Identities for Key Algorithms */ base "hash-algorithm";
/*************************************/ description "The SHA-256 algorithm.";
reference "RFC 6234: US Secure Hash Algorithms.";
}
identity key-algorithm { identity sha-384 {
description base "hash-algorithm";
"Base identity from which all key-algorithms are derived."; description "The SHA-384 algorithm.";
} reference "RFC 6234: US Secure Hash Algorithms.";
}
identity rsa1024 { identity sha-512 {
base key-algorithm; base "hash-algorithm";
description description "The SHA-512 algorithm.";
"The RSA algorithm using a 1024-bit key."; reference "RFC 6234: US Secure Hash Algorithms.";
reference }
"RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2.";
}
identity rsa2048 { /********************************************************/
base key-algorithm; /* Identities for Asymmetric Key Encyption Algorithms */
description /********************************************************/
"The RSA algorithm using a 2048-bit key.";
reference
"RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2.";
}
identity rsa3072 { identity asymmetric-key-encryption-algorithm {
base key-algorithm; description
description "Base identity from which all asymmetric key
"The RSA algorithm using a 3072-bit key."; encryption Algorithm.";
reference }
"RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2.";
}
identity rsa4096 { identity rsa1024 {
base key-algorithm; base asymmetric-key-encryption-algorithm;
description description
"The RSA algorithm using a 4096-bit key."; "The RSA algorithm using a 1024-bit key.";
reference reference
"RFC 8017: "RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2."; PKCS #1: RSA Cryptography Specifications Version 2.2.";
} }
identity rsa7680 { identity rsa2048 {
base key-algorithm; base asymmetric-key-encryption-algorithm;
description description
"The RSA algorithm using a 7680-bit key."; "The RSA algorithm using a 2048-bit key.";
reference reference
"RFC 8017: "RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2."; PKCS #1: RSA Cryptography Specifications Version 2.2.";
} }
identity rsa15360 { identity rsa3072 {
base key-algorithm; base asymmetric-key-encryption-algorithm;
description description
"The RSA algorithm using a 15360-bit key."; "The RSA algorithm using a 3072-bit key.";
reference reference
"RFC 8017: "RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2."; PKCS #1: RSA Cryptography Specifications Version 2.2.";
} }
identity secp192r1 { identity rsa4096 {
base key-algorithm; base asymmetric-key-encryption-algorithm;
description description
"The secp192r1 algorithm."; "The RSA algorithm using a 4096-bit key.";
reference
"RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2.";
}
reference identity rsa7680 {
"RFC 5480: Elliptic Curve Cryptography Subject Public base asymmetric-key-encryption-algorithm;
Key Information."; description
} "The RSA algorithm using a 7680-bit key.";
reference
"RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2.";
}
identity secp256r1 { identity rsa15360 {
base key-algorithm; base asymmetric-key-encryption-algorithm;
description description
"The secp256r1 algorithm."; "The RSA algorithm using a 15360-bit key.";
reference reference
"RFC 5480: Elliptic Curve Cryptography Subject Public "RFC 8017:
Key Information."; PKCS #1: RSA Cryptography Specifications Version 2.2.";
} }
/*************************************/
/* Identities for MAC Algorithms */
/*************************************/
identity secp384r1 { identity mac-algorithm {
base key-algorithm; description
description "A base identity for mac generation.";
"The secp384r1 algorithm."; }
reference
"RFC 5480: Elliptic Curve Cryptography Subject Public
Key Information.";
}
identity secp521r1 { identity hmac-sha1 {
base key-algorithm; base "mac-algorithm";
description description "Generating MAC using SHA1 hash function";
"The secp521r1 algorithm."; reference "RFC 3174: US Secure Hash Algorithm 1 (SHA1)";
reference }
"RFC 5480: Elliptic Curve Cryptography Subject Public
Key Information.";
}
/*********************************************************/ identity hmac-sha1-96 {
/* Typedefs for identityrefs to above base identites */ base "mac-algorithm";
/*********************************************************/ description "Generating MAC using SHA1 hash function";
reference "RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH";
}
typedef hash-algorithm-ref { identity hmac-sha2-224 {
type identityref { base "mac-algorithm";
base "hash-algorithm"; description
} "Generating MAC using SHA2 hash function";
description reference
"This typedef enables importing modules to easily define an "RFC 6234:
identityref to the 'hash-algorithm' base identity."; US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)";
} }
typedef key-algorithm-ref { identity hmac-sha2-256 {
type identityref { base "mac-algorithm";
base "key-algorithm"; description
} "Generating MAC using SHA2 hash function";
description reference
"This typedef enables importing modules to easily define an "RFC 6234:
identityref to the 'key-algorithm' base identity."; US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)";
} }
/***************************************************/ identity hmac-sha2-256-128 {
/* Typedefs for ASN.1 structures from RFC 5280 */ base "mac-algorithm";
/***************************************************/ description
"Generating a 256 bits MAC using SHA2 hash function and truncate
it to 128 bits";
reference
"RFC 4868:
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
IPsec";
typedef x509 { }
type binary;
description
"A Certificate structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"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).";
}
typedef crl { identity hmac-sha2-384 {
type binary; base "mac-algorithm";
description description
"A CertificateList structure, as specified in RFC 5280, "Generating MAC using SHA2 hash function";
encoded using ASN.1 distinguished encoding rules (DER), reference
as specified in ITU-T X.690."; "RFC 6234:
reference US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)";
"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).";
}
/***********************************************/ identity hmac-sha2-384-192 {
/* Typedefs for ASN.1 structures from 5652 */ base "mac-algorithm";
/***********************************************/ description
"Generating a 384 bits MAC using SHA2 hash function and truncate
it to 192 bits";
reference
"RFC 4868:
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
IPsec";
}
typedef cms { identity hmac-sha2-512 {
type binary; base "mac-algorithm";
description description "Generating MAC using SHA2 hash function";
"A ContentInfo structure, as specified in RFC 5652, reference
encoded using ASN.1 distinguished encoding rules (DER), "RFC 6234:
as specified in ITU-T X.690."; US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)";
reference }
"RFC 5652:
Cryptographic Message Syntax (CMS)
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).";
}
typedef data-content-cms { identity hmac-sha2-512-256 {
type cms; base "mac-algorithm";
description description
"A CMS structure whose top-most content type MUST be the "Generating a 512 bits MAC using SHA2 hash function and
data content type, as described by Section 4 in RFC 5652."; truncating it to 256 bits";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 4868:
} Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
IPsec";
}
typedef signed-data-cms { identity aes-128-gmac {
type cms; base "mac-algorithm";
description description
"A CMS structure whose top-most content type MUST be the "Generating MAC using the Advanced Encryption Standard (AES)
signed-data content type, as described by Section 5 in Galois Message Authentication Code (GMAC) as a mechanism to
RFC 5652."; provide data origin authentication";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 4543:
} The Use of Galois Message Authentication Code (GMAC) in
IPsec ESP and AH";
}
typedef enveloped-data-cms { identity aes-192-gmac {
type cms; base "mac-algorithm";
description description
"A CMS structure whose top-most content type MUST be the "Generating MAC using the Advanced Encryption Standard (AES)
enveloped-data content type, as described by Section 6 Galois Message Authentication Code (GMAC) as a mechanism to
in RFC 5652."; provide data origin authentication";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 4543:
} The Use of Galois Message Authentication Code (GMAC) in
IPsec ESP and AH";
typedef digested-data-cms { }
type cms;
description
"A CMS structure whose top-most content type MUST be the
digested-data content type, as described by Section 7
in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef encrypted-data-cms { identity aes-256-gmac {
type cms; base "mac-algorithm";
description description
"A CMS structure whose top-most content type MUST be the "Generating MAC using the Advanced Encryption Standard (AES)
encrypted-data content type, as described by Section 8 Galois Message Authentication Code (GMAC) as a mechanism to
in RFC 5652."; provide data origin authentication";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 4543:
} The Use of Galois Message Authentication Code (GMAC) in
IPsec ESP and AH";
}
typedef authenticated-data-cms { identity aes-cmac-96 {
type cms; base "mac-algorithm";
description description
"A CMS structure whose top-most content type MUST be the "Generating MAC using Advanced Encryption Standard (AES)
authenticated-data content type, as described by Section 9 Cipher-based Message Authentication Code (CMAC)";
in RFC 5652."; reference
reference "RFC 4494: The AES-CMAC-96 Algorithm and its Use with IPsec";
"RFC 5652: Cryptographic Message Syntax (CMS)"; }
}
/***************************************************/ identity aes-cmac-128 {
/* Typedefs for structures related to RFC 4253 */ base "mac-algorithm";
/***************************************************/ description
"Generating MAC using Advanced Encryption Standard (AES)
Cipher-based Message Authentication Code (CMAC)";
reference
"RFC 4493: The AES-CMAC Algorithm";
}
identity mac-aes-128-ccm {
base "mac-algorithm";
description
"Generating MAC using Advanced Encryption Standard (AES) in
CCM (Counter with CBC-MAC) mode (AES CCM)";
reference
"RFC 4309:
Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP)";
}
typedef ssh-host-key { identity mac-aes-192-ccm {
type binary; base "mac-algorithm";
description description
"The binary public key data for this SSH key, as "Generating MAC using Advanced Encryption Standard (AES) in
specified by RFC 4253, Section 6.6, i.e.: CCM (Counter with CBC-MAC) mode (AES CCM)";
reference
"RFC 4309:
Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP)";
}
string certificate or public key format identity mac-aes-256-ccm {
identifier base "mac-algorithm";
byte[n] key/certificate data."; description
reference "Generating MAC using Advanced Encryption Standard (AES) in
"RFC 4253: The Secure Shell (SSH) Transport Layer CCM (Counter with CBC-MAC) mode (AES CCM)";
Protocol"; reference
} "RFC 4309:
Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP)";
}
/*********************************************************/ identity mac-aes-128-gcm {
/* Typedefs for ASN.1 structures related to RFC 5280 */ base "mac-algorithm";
/*********************************************************/ description
"Generating MAC when using Advanced Encryption Standard (AES)
GCM mode for encryption";
reference
"RFC 4106:
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
Security Payload (ESP)";
}
typedef trust-anchor-cert-x509 { identity mac-aes-192-gcm {
type x509; base "mac-algorithm";
description description
"A Certificate structure that MUST encode a self-signed "Generating MAC when using Advanced Encryption Standard (AES)
root certificate."; GCM mode for encryption";
} reference
"RFC 4106:
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
Security Payload (ESP)";
}
typedef end-entity-cert-x509 { identity mac-aes-256-gcm {
type x509; base "mac-algorithm";
description description
"A Certificate structure that MUST encode a certificate "Generating MAC when using Advanced Encryption Standard (AES)
that is neither self-signed nor having Basic constraint GCM mode for encryption";
CA true."; reference
} "RFC 4106:
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
Security Payload (ESP)";
}
/*********************************************************/ identity mac-chacha20-poly1305 {
/* Typedefs for ASN.1 structures related to RFC 5652 */ base "mac-algorithm";
/*********************************************************/ description
"Generating MAC using poly1305 algorithm";
reference
"RFC 7539: ChaCha20 and Poly1305 for IETF Protocols";
}
typedef trust-anchor-cert-cms { /*******************************************************/
type signed-data-cms; /* Identities for Symmetric Key Encryption Algorithms*/
description /*******************************************************/
"A CMS SignedData structure that MUST contain the chain of
X.509 certificates needed to authenticate the certificate
presented by a client or end-entity.
The CMS MUST contain only a single chain of certificates. identity symmetric-key-encryption-algorithm {
The client or end-entity certificate MUST only authenticate description
to last intermediate CA certificate listed in the chain. "A base identity for encryption algorithm.";
}
In all cases, the chain MUST include a self-signed root identity aes-128-cbc {
certificate. In the case where the root certificate is base "symmetric-key-encryption-algorithm";
itself the issuer of the client or end-entity certificate, description
only one certificate is present. "Encrypt message with AES algorithm in CBC mode with a key
length of 128 bits";
reference
"RFC 3565:
Use of the Advanced Encryption Standard (AES) Encryption
Algorithm in Cryptographic Message Syntax (CMS)";
}
This CMS structure MAY (as applicable where this type is identity aes-192-cbc {
used) also contain suitably fresh (as defined by local base "symmetric-key-encryption-algorithm";
policy) revocation objects with which the device can description
verify the revocation status of the certificates. "Encrypt message with AES algorithm in CBC mode with a key
length of 192 bits";
reference
"RFC 3565:
Use of the Advanced Encryption Standard (AES) Encryption
Algorithm in Cryptographic Message Syntax (CMS)";
}
This CMS encodes the degenerate form of the SignedData identity aes-256-cbc {
structure that is commonly used to disseminate X.509 base "symmetric-key-encryption-algorithm";
certificates and revocation objects (RFC 5280)."; description
reference "Encrypt message with AES algorithm in CBC mode with a key
"RFC 5280: length of 256 bits";
reference
"RFC 3565:
Use of the Advanced Encryption Standard (AES) Encryption
Algorithm in Cryptographic Message Syntax (CMS)";
}
Internet X.509 Public Key Infrastructure Certificate identity aes-128-ctr {
and Certificate Revocation List (CRL) Profile."; base "symmetric-key-encryption-algorithm";
} description
"Encrypt message with AES algorithm in CTR mode with a key
length of 128 bits";
reference
"RFC 3686:
Using Advanced Encryption Standard (AES) Counter Mode with
IPsec Encapsulating Security Payload (ESP)";
}
typedef end-entity-cert-cms { identity aes-192-ctr {
type signed-data-cms; base "symmetric-key-encryption-algorithm";
description description
"A CMS SignedData structure that MUST contain the end "Encrypt message with AES algorithm in CTR mode with a key
entity certificate itself, and MAY contain any number length of 192 bits";
of intermediate certificates leading up to a trust reference
anchor certificate. The trust anchor certificate "RFC 3686:
MAY be included as well. Using Advanced Encryption Standard (AES) Counter Mode with
IPsec Encapsulating Security Payload (ESP)";
}
The CMS MUST contain a single end entity certificate. identity aes-256-ctr {
The CMS MUST NOT contain any spurious certificates. base "symmetric-key-encryption-algorithm";
description
"Encrypt message with AES algorithm in CTR mode with a key
length of 256 bits";
This CMS structure MAY (as applicable where this type is reference
used) also contain suitably fresh (as defined by local "RFC 3686:
policy) revocation objects with which the device can Using Advanced Encryption Standard (AES) Counter Mode with
verify the revocation status of the certificates. IPsec Encapsulating Security Payload (ESP)";
}
This CMS encodes the degenerate form of the SignedData identity enc-aes-128-ccm {
structure that is commonly used to disseminate X.509 base "symmetric-key-encryption-algorithm";
certificates and revocation objects (RFC 5280)."; description
reference "Encrypt message with AES algorithm in CCM mode with a key
"RFC 5280: length of 128 bits";
Internet X.509 Public Key Infrastructure Certificate reference
and Certificate Revocation List (CRL) Profile."; "RFC 4309:
} Using Advanced Encryption Standard (AES) CCM Mode with IPsec
Encapsulating Security Payload (ESP)";
}
/**********************************************/ identity enc-aes-192-ccm {
/* Groupings for keys and/or certificates */ base "symmetric-key-encryption-algorithm";
/**********************************************/ description
"Encrypt message with AES algorithm in CCM mode with a key
length of 192 bits";
reference
"RFC 4309:
Using Advanced Encryption Standard (AES) CCM Mode with IPsec
Encapsulating Security Payload (ESP)";
}
grouping public-key-grouping { identity enc-aes-256-ccm {
description base "symmetric-key-encryption-algorithm";
"A public key."; description
leaf algorithm { "Encrypt message with AES algorithm in CCM mode with a key
type ct:key-algorithm-ref; length of 256 bits";
description reference
"Identifies the key's algorithm. More specifically, "RFC 4309:
this leaf specifies how the 'public-key' binary leaf Using Advanced Encryption Standard (AES) CCM Mode with IPsec
is encoded."; Encapsulating Security Payload (ESP)";
reference }
"RFC CCCC: Common YANG Data Types for Cryptography";
}
leaf public-key {
type binary;
description
"A binary that contains the value of the public key. The
interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in
RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
}
} // end public-key-grouping
grouping asymmetric-key-pair-grouping { identity enc-aes-128-gcm {
description base "symmetric-key-encryption-algorithm";
"A private/public key pair."; description
uses public-key-grouping; "Encrypt message with AES algorithm in GCM mode with a key
leaf private-key { length of 128 bits";
nacm:default-deny-all; reference
type union { "RFC 4106:
type binary; The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
type enumeration { Security Payload (ESP)";
enum "permanently-hidden" {
description
"The private key is inaccessible due to being
protected by the system (e.g., a cryptographic
hardware module). It is not possible to
configure a permanently hidden key, as a real
private key value must be set. Permanently
hidden keys cannot be archived or backed up.";
}
}
}
description
"A binary that contains the value of the private key. The
interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPrivateKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented as ECPrivateKey as defined in RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
} }
action generate-hidden-key {
description
"Requests the device to generate a hidden key using the
specified asymmetric key algorithm. This action is
used to request the system the generate a key that
is 'permanently-hidden', perhaps protected by a
cryptographic hardware module. The resulting
asymmetric key values are considered operational
state and hence present only in <operational>.";
input {
leaf algorithm {
type ct:key-algorithm-ref;
mandatory true;
description
"The algorithm to be used when generating the
asymmetric key.";
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
}
} // end generate-hidden-key
action install-hidden-key {
description
"Requests the device to load the specified values into
a hidden key. The resulting asymmetric key values are
considered operational state and hence present only in
<operational>.";
input {
leaf algorithm {
type ct:key-algorithm-ref;
mandatory true;
description
"The algorithm to be used when generating the
asymmetric key.";
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
leaf public-key {
type binary;
description
"A binary that contains the value of the public key.
The interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an
RSA key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in
RFC 5915.";
reference identity enc-aes-192-gcm {
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1: base "symmetric-key-encryption-algorithm";
RSA Cryptography Specifications Version 2.2. description
RFC 5915: Elliptic Curve Private Key Structure."; "Encrypt message with AES algorithm in GCM mode with a key
} length of 192 bits";
leaf private-key { reference
type binary; "RFC 4106:
description The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
"A binary that contains the value of the private key. Security Payload (ESP)";
The interpretation of the content is defined by the key }
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPrivateKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented as ECPrivateKey as defined in RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
}
}
} // end install-hidden-key
} // end asymmetric-key-pair-grouping
grouping trust-anchor-cert-grouping { identity enc-aes-256-gcm {
description base "symmetric-key-encryption-algorithm";
"A certificate, and a notification for when it might expire."; description
leaf cert { "Encrypt message with AES algorithm in GCM mode with a key
type ct:trust-anchor-cert-cms; length of 256 bits";
mandatory true; reference
description "RFC 4106:
"The binary certificate data for this certificate."; The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
reference Security Payload (ESP)";
}
identity enc-chacha20-poly1305 {
base "symmetric-key-encryption-algorithm";
description
"Encrypt message with chacha20 algorithm and generate MAC with
POLY1305";
reference
"RFC 7539: ChaCha20 and Poly1305 for IETF Protocols";
}
/******************************************/
/* Identities for signature algorithm */
/******************************************/
identity signature-algorithm {
description
"A base identity for asymmetric key encryption algorithm.";
}
identity dsa-sha1 {
base "signature-algorithm";
description
"The signature algorithm using DSA algorithm with SHA1 hash
algorithm";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer Protocol";
}
identity rsa-pkcs1-sha1 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PKCS1-v1_5 with the SHA1
hash algorithm.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer Protocol";
}
identity rsa-pkcs1-sha256 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PKCS1-v1_5 with the
SHA256 hash algorithm.";
reference
"RFC 8332:
Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell
(SSH) Protocol
RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pkcs1-sha384 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PKCS1-v1_5 with the
SHA384 hash algorithm.";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pkcs1-sha512 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PKCS1-v1_5 with the
SHA512 hash algorithm.";
reference
"RFC 8332:
Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell
(SSH) Protocol
RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-rsae-sha256 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA256 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the rsaEncryption
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-rsae-sha384 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA384 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the rsaEncryption
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-rsae-sha512 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA512 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the rsaEncryption
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-pss-sha256 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA256 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-pss-sha384 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA256 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity rsa-pss-pss-sha512 {
base "signature-algorithm";
description
"The signature algorithm using RSASSA-PSS with mask generation
function 1 and SHA256 hash algorithm. If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS
OID";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity ecdsa-secp256r1-sha256 {
base "signature-algorithm";
description
"The signature algorithm using ECDSA wtih curve name secp256r1
and SHA256 hash algorithm.";
reference
"RFC 5656: Elliptic Curve Algorithm Integration in the
Secure Shell Transport Layer
RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity ecdsa-secp384r1-sha384 {
base "signature-algorithm";
description
"The signature algorithm using ECDSA wtih curve name secp384r1
and SHA384 hash algorithm.";
reference
"RFC 5656: Elliptic Curve Algorithm Integration in the
Secure Shell Transport Layer
RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity ecdsa-secp521r1-sha512 {
base "signature-algorithm";
description
"The signature algorithm using ECDSA wtih curve name secp521r1
and SHA512 hash algorithm.";
reference
"RFC 5656: Elliptic Curve Algorithm Integration in the
Secure Shell Transport Layer
RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity x509v3-rsa-pkcs1-sha1 {
base "signature-algorithm";
description
"The signature algorithm using x509v3-ssh-rsa key format and
RSASSA-PKCS1-v1_5 with the SHA1 hash algorithm.";
reference
"RFC 6187:
X.509v3 Certificates for Secure Shell Authentication";
}
identity x509v3-rsa2048-pkcs1-sha256 {
base "signature-algorithm";
description
"The signature algorithm using x509v3-rsa2048-sha256
key format and RSASSA-PKCS1-v1_5 with the SHA-256
hash algorithm.";
reference
"RFC 6187:
X.509v3 Certificates for Secure Shell Authentication";
}
identity x509v3-ecdsa-secp256r1-sha256 {
base "signature-algorithm";
description
"The signature algorithm using x509v3-ecdsa-sha2-secp256r1 key
format and ECDSA algorithm with the SHA-256 hash algorithm.";
reference
"RFC 6187:
X.509v3 Certificates for Secure Shell Authentication";
}
identity x509v3-ecdsa-secp384r1-sha384 {
base "signature-algorithm";
description
"The signature algorithm using x509v3-ecdsa-sha2-secp384r1 key
format and ECDSA algorithm with the SHA-384 hash algorithm.";
reference
"RFC 6187:
X.509v3 Certificates for Secure Shell Authentication";
}
identity x509v3-ecdsa-secp521r1-sha512 {
base "signature-algorithm";
description
"The signature algorithm using x509v3-ecdsa-sha2-secp521r1 key
format and ECDSA algorithm with the SHA-512 hash algorithm.";
reference
"RFC 6187:
X.509v3 Certificates for Secure Shell Authentication";
}
identity ed25519 {
base "signature-algorithm";
description
"The signature algorithm using EdDSA as defined in RFC 8032 or
its successors.";
reference
"RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)";
}
identity ed448 {
base "signature-algorithm";
description
"The signature algorithm using EdDSA as defined in RFC 8032 or
its successors.";
reference
"RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)";
}
identity eccsi {
base "signature-algorithm";
description
"The signature algorithm using ECCSI signature as defined in
RFC 6507.";
reference
"RFC 6507:
Elliptic Curve-Based Certificateless Signatures for
Identity-based Encryption (ECCSI)";
}
/**********************************************/
/* Identities for key exchange algorithms */
/**********************************************/
identity key-exchange-algorithm {
description
"A base identity for Diffe-Hellman based key exchange
algorithm.";
}
identity psk-only {
base "key-exchange-algorithm";
description
"Using Pre-shared key for authentication and key exhange";
reference
"RFC 4279:
Pre-Shared Key Ciphersuites for Transport Layer Security
(TLS)";
}
identity dhe-ffdhe2048 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with 2048 bit
finite field";
reference
"RFC 7919:
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for Transport Layer Security (TLS)";
}
identity dhe-ffdhe3072 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with 3072 bit finite
field";
reference
"RFC 7919:
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for Transport Layer Security (TLS)";
}
identity dhe-ffdhe4096 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with 4096 bit
finite field";
reference
"RFC 7919:
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for Transport Layer Security (TLS)";
}
identity dhe-ffdhe6144 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with 6144 bit
finite field";
reference
"RFC 7919:
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for Transport Layer Security (TLS)";
}
identity dhe-ffdhe8192 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with 8192 bit
finite field";
reference
"RFC 7919:
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for Transport Layer Security (TLS)";
}
identity psk-dhe-ffdhe2048 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with Diffie-Hellman key
generation mechansim, where the DH group is FFDHE2048";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-dhe-ffdhe3072 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with Diffie-Hellman key
generation mechansim, where the DH group is FFDHE3072";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-dhe-ffdhe4096 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with Diffie-Hellman key
generation mechansim, where the DH group is FFDHE4096";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-dhe-ffdhe6144 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with Diffie-Hellman key
generation mechansim, where the DH group is FFDHE6144";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-dhe-ffdhe8192 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with Diffie-Hellman key
generation mechansim, where the DH group is FFDHE8192";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity ecdhe-secp256r1 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with elliptic group
over curve secp256r1";
reference
"RFC 8422:
Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier";
}
identity ecdhe-secp384r1 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with elliptic group
over curve secp384r1";
reference
"RFC 8422:
Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier";
}
identity ecdhe-secp521r1 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with elliptic group
over curve secp521r1";
reference
"RFC 8422:
Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier";
}
identity ecdhe-x25519 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with elliptic group
over curve x25519";
reference
"RFC 8422:
Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier";
}
identity ecdhe-x448 {
base "key-exchange-algorithm";
description
"Ephemeral Diffie Hellman key exhange with elliptic group
over curve x448";
reference
"RFC 8422:
Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier";
}
identity psk-ecdhe-secp256r1 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with elliptic group-based
Ephemeral Diffie Hellman key exhange over curve secp256r1";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-ecdhe-secp384r1 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with elliptic group-based
Ephemeral Diffie Hellman key exhange over curve secp384r1";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-ecdhe-secp521r1 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with elliptic group-based
Ephemeral Diffie Hellman key exhange over curve secp521r1";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-ecdhe-x25519 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with elliptic group-based
Ephemeral Diffie Hellman key exhange over curve x25519";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity psk-ecdhe-x448 {
base "key-exchange-algorithm";
description
"Key exchange using pre-shared key with elliptic group-based
Ephemeral Diffie Hellman key exhange over curve x448";
reference
"RFC 8446:
The Transport Layer Security (TLS) Protocol Version 1.3";
}
identity diffie-hellman-group14-sha1 {
base "key-exchange-algorithm";
description
"Using DH group14 and SHA1 for key exchange";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer Protocol";
}
identity diffie-hellman-group14-sha256 {
base "key-exchange-algorithm";
description
"Using DH group14 and SHA256 for key exchange";
reference
"RFC 8268:
More Modular Exponentiation (MODP) Diffie-Hellman (DH)
Key Exchange (KEX) Groups for Secure Shell (SSH)";
}
identity diffie-hellman-group15-sha512 {
base "key-exchange-algorithm";
description
"Using DH group15 and SHA512 for key exchange";
reference
"RFC 8268:
More Modular Exponentiation (MODP) Diffie-Hellman (DH)
Key Exchange (KEX) Groups for Secure Shell (SSH)";
}
identity diffie-hellman-group16-sha512 {
base "key-exchange-algorithm";
description
"Using DH group16 and SHA512 for key exchange";
reference
"RFC 8268:
More Modular Exponentiation (MODP) Diffie-Hellman (DH)
Key Exchange (KEX) Groups for Secure Shell (SSH)";
}
identity diffie-hellman-group17-sha512 {
base "key-exchange-algorithm";
description
"Using DH group17 and SHA512 for key exchange";
reference
"RFC 8268:
More Modular Exponentiation (MODP) Diffie-Hellman (DH)
Key Exchange (KEX) Groups for Secure Shell (SSH)";
}
identity diffie-hellman-group18-sha512 {
base "key-exchange-algorithm";
description
"Using DH group18 and SHA512 for key exchange";
reference
"RFC 8268:
More Modular Exponentiation (MODP) Diffie-Hellman (DH)
Key Exchange (KEX) Groups for Secure Shell (SSH)";
}
identity ecdh-sha2-secp256r1 {
base "key-exchange-algorithm";
description
"Elliptic curve-based Diffie Hellman key exhange over curve
secp256r1 and using SHA2 for MAC generation";
reference
"RFC 6239: Suite B Cryptographic Suites for Secure Shell (SSH)";
}
identity ecdh-sha2-secp384r1 {
base "key-exchange-algorithm";
description
"Elliptic curve-based Diffie Hellman key exhange over curve
secp384r1 and using SHA2 for MAC generation";
reference
"RFC 6239: Suite B Cryptographic Suites for Secure Shell (SSH)";
}
/*********************************************************/
/* Typedefs for identityrefs to above base identites */
/*********************************************************/
typedef hash-algorithm-ref {
type identityref {
base "hash-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'hash-algorithm' base identity.";
}
typedef signature-algorithm-ref {
type identityref {
base "signature-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'signature-algorithm' base identity.";
}
typedef mac-algorithm-ref {
type identityref {
base "mac-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'mac-algorithm' base identity.";
}
typedef symmetric-key-encryption-algorithm-ref {
type identityref {
base "symmetric-key-encryption-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'symmetric-key-encryption-algorithm'
base identity.";
}
typedef asymmetric-key-encryption-algorithm-ref {
type identityref {
base "asymmetric-key-encryption-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'asymmetric-key-encryption-algorithm'
base identity.";
}
typedef key-exchange-algorithm-ref {
type identityref {
base "key-exchange-algorithm";
}
description
"This typedef enables importing modules to easily define an
identityref to the 'key-exchange-algorithm' base identity.";
}
/***************************************************/
/* Typedefs for ASN.1 structures from RFC 5280 */
/***************************************************/
typedef x509 {
type binary;
description
"A Certificate structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"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).";
}
typedef crl {
type binary;
description
"A CertificateList structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"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).";
}
/***********************************************/
/* Typedefs for ASN.1 structures from 5652 */
/***********************************************/
typedef cms {
type binary;
description
"A ContentInfo structure, as specified in RFC 5652,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"RFC 5652:
Cryptographic Message Syntax (CMS)
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).";
}
typedef data-content-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
data content type, as described by Section 4 in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef signed-data-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
signed-data content type, as described by Section 5 in
RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef enveloped-data-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
enveloped-data content type, as described by Section 6
in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef digested-data-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
digested-data content type, as described by Section 7
in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef encrypted-data-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
encrypted-data content type, as described by Section 8
in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
typedef authenticated-data-cms {
type cms;
description
"A CMS structure whose top-most content type MUST be the
authenticated-data content type, as described by Section 9
in RFC 5652.";
reference
"RFC 5652: Cryptographic Message Syntax (CMS)";
}
/***************************************************/
/* Typedefs for structures related to RFC 4253 */
/***************************************************/
typedef ssh-host-key {
type binary;
description
"The binary public key data for this SSH key, as
specified by RFC 4253, Section 6.6, i.e.:
string certificate or public key format
identifier
byte[n] key/certificate data.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
}
/*********************************************************/
/* Typedefs for ASN.1 structures related to RFC 5280 */
/*********************************************************/
typedef trust-anchor-cert-x509 {
type x509;
description
"A Certificate structure that MUST encode a self-signed
root certificate.";
}
typedef end-entity-cert-x509 {
type x509;
description
"A Certificate structure that MUST encode a certificate
that is neither self-signed nor having Basic constraint
CA true.";
}
/*********************************************************/
/* Typedefs for ASN.1 structures related to RFC 5652 */
/*********************************************************/
typedef trust-anchor-cert-cms {
type signed-data-cms;
description
"A CMS SignedData structure that MUST contain the chain of
X.509 certificates needed to authenticate the certificate
presented by a client or end-entity.
The CMS MUST contain only a single chain of certificates.
The client or end-entity certificate MUST only authenticate
to last intermediate CA certificate listed in the chain.
In all cases, the chain MUST include a self-signed root
certificate. In the case where the root certificate is
itself the issuer of the client or end-entity certificate,
only one certificate is present.
This CMS structure MAY (as applicable where this type is
used) also contain suitably fresh (as defined by local
policy) revocation objects with which the device can
verify the revocation status of the certificates.
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.";
}
typedef end-entity-cert-cms {
type signed-data-cms;
description
"A CMS SignedData structure that MUST contain the end
entity certificate itself, and MAY contain any number
of intermediate certificates leading up to a trust
anchor certificate. The trust anchor certificate
MAY be included as well.
The CMS MUST contain a single end entity certificate.
The CMS MUST NOT contain any spurious certificates.
This CMS structure MAY (as applicable where this type is
used) also contain suitably fresh (as defined by local
policy) revocation objects with which the device can
verify the revocation status of the certificates.
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.";
}
/**********************************************/
/* Groupings for keys and/or certificates */
/**********************************************/
grouping public-key-grouping {
description
"A public key.";
leaf algorithm {
type asymmetric-key-encryption-algorithm-ref;
description
"Identifies the key's algorithm. More specifically,
this leaf specifies how the 'public-key' binary leaf
is encoded.";
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
leaf public-key {
type binary;
description
"A binary that contains the value of the public key. The
interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in
RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
}
} // end public-key-grouping
grouping asymmetric-key-pair-grouping {
description
"A private/public key pair.";
uses public-key-grouping;
leaf private-key {
nacm:default-deny-all;
type union {
type binary;
type enumeration {
enum "permanently-hidden" {
description
"The private key is inaccessible due to being
protected by the system (e.g., a cryptographic
hardware module). It is not possible to
configure a permanently hidden key, as a real
private key value must be set. Permanently
hidden keys cannot be archived or backed up.";
}
}
}
description
"A binary that contains the value of the private key. The
interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPrivateKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented as ECPrivateKey as defined in RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
} // end private-key
action generate-hidden-key {
description
"Requests the device to generate a hidden key using the
specified asymmetric key algorithm. This action is
used to request the system to generate a key that
is 'permanently-hidden', perhaps protected by a
cryptographic hardware module. The resulting
asymmetric key values are considered operational
state and hence present only in <operational>.";
input {
leaf algorithm {
type asymmetric-key-encryption-algorithm-ref;
mandatory true;
description
"The algorithm to be used when generating the
asymmetric key.";
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
}
} // end generate-hidden-key
action install-hidden-key {
description
"Requests the device to load the specified values into
a hidden key. The resulting asymmetric key values are
considered operational state and hence present only in
<operational>.";
input {
leaf algorithm {
type asymmetric-key-encryption-algorithm-ref;
mandatory true;
description
"The algorithm to be used when generating the
asymmetric key.";
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
leaf public-key {
type binary;
description
"A binary that contains the value of the public key.
The interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an
RSA key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in
RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
}
leaf private-key {
type binary;
description
"A binary that contains the value of the private key.
The interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPrivateKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented as ECPrivateKey as defined in RFC 5915.";
reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure.";
}
}
} // end install-hidden-key
} // end asymmetric-key-pair-grouping
grouping trust-anchor-cert-grouping {
description
"A certificate, and a notification for when it might expire.";
leaf cert {
type trust-anchor-cert-cms;
description
"The binary certificate data for this certificate.";
reference
"RFC YYYY: Common YANG Data Types for Cryptography";
}
notification certificate-expiration {
description
"A notification indicating that the 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 until the issue is resolved.";
leaf expiration-date {
type yang:date-and-time;
mandatory true;
description
"Identifies the expiration date on the certificate.";
}
}
} // end trust-anchor-cert-grouping
grouping end-entity-cert-grouping {
description
"A certificate, and a notification for when it might expire.";
leaf cert {
type end-entity-cert-cms;
description
"The binary certificate data for this certificate.";
reference
"RFC YYYY: Common YANG Data Types for Cryptography"; "RFC YYYY: Common YANG Data Types for Cryptography";
} }
} // end trust-anchor-cert-grouping notification certificate-expiration {
description
"A notification indicating that the 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 until the issue is resolved.";
leaf expiration-date {
type yang:date-and-time;
mandatory true;
description
"Identifies the expiration date on the certificate.";
}
}
grouping end-entity-cert-grouping { } // end end-entity-cert-grouping
description
"A certificate, and a notification for when it might expire.";
leaf cert {
type ct:end-entity-cert-cms;
mandatory true;
description
"The binary certificate data for this certificate.";
reference
"RFC YYYY: Common YANG Data Types for Cryptography";
} grouping asymmetric-key-pair-with-certs-grouping {
notification certificate-expiration { description
description "A private/public key pair and associated certificates.";
"A notification indicating that the configured certificate uses asymmetric-key-pair-grouping;
is either about to expire or has already expired. When to container certificates {
send notifications is an implementation specific decision, description
but it is RECOMMENDED that a notification be sent once a "Certificates associated with this asymmetric key.
month for 3 months, then once a week for four weeks, and More than one certificate supports, for instance,
then once a day thereafter until the issue is resolved."; a TPM-protected asymmetric key that has both IDevID
leaf expiration-date { and LDevID certificates associated.";
type yang:date-and-time; list certificate {
//mandatory true; key name;
description description
"Identifies the expiration date on the certificate."; "A certificate for this asymmetric key.";
} leaf name {
} type string;
} // end end-entity-cert-grouping description
"An arbitrary name for the certificate. If the name
matches the name of a certificate that exists
independently in <operational> (i.e., an IDevID),
then the 'cert' node MUST NOT be configured.";
grouping asymmetric-key-pair-with-certs-grouping { }
description uses end-entity-cert-grouping;
"A private/public key pair and associated certificates."; } // end certificate
uses asymmetric-key-pair-grouping; } // end certificates
container certificates {
description
"Certificates associated with this asymmetric key.
More than one certificate supports, for instance,
a TPM-protected asymmetric key that has both IDevID
and LDevID certificates associated.";
list certificate {
must "../../algorithm
and ../../public-key
and ../../private-key";
key name;
description
"A certificate for this asymmetric key.";
leaf name {
type string;
description
"An arbitrary name for the certificate.";
}
uses end-entity-cert-grouping;
} // end certificate
} // end certificates
action generate-certificate-signing-request {
description
"Generates a certificate signing request structure for
the associated asymmetric key using the passed subject
and attribute values. The specified assertions need
to be appropriate for the certificate's use. For
example, an entity certificate for a TLS server
SHOULD have values that enable clients to satisfy
RFC 6125 processing.";
input {
leaf subject {
type binary;
mandatory true;
description
"The 'subject' field per 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.";
reference
"RFC 2986:
PKCS #10: Certification Request Syntaxi
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).";
}
leaf attributes {
type binary;
description
"The 'attributes' field from the structure
CertificationRequestInfo as specified by RFC 2986,
Section 4.1 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.";
reference
"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).";
}
}
output {
leaf certificate-signing-request {
type binary;
mandatory true;
description
"A CertificationRequest structure as specified by
RFC 2986, Section 4.2 encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU-T X.690.";
reference
"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).";
} action generate-certificate-signing-request {
} description
} // end generate-certificate-signing-request "Generates a certificate signing request structure for
} // end asymmetric-key-pair-with-certs-grouping the associated asymmetric key using the passed subject
and attribute values. The specified assertions need
to be appropriate for the certificate's use. For
example, an entity certificate for a TLS server
SHOULD have values that enable clients to satisfy
RFC 6125 processing.";
input {
leaf subject {
type binary;
mandatory true;
description
"The 'subject' field per 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.";
} reference
<CODE ENDS> "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).";
}
leaf attributes {
type binary;
description
"The 'attributes' field from the structure
CertificationRequestInfo as specified by RFC 2986,
Section 4.1 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.";
reference
"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).";
}
}
output {
leaf certificate-signing-request {
type binary;
mandatory true;
description
"A CertificationRequest structure as specified by
RFC 2986, Section 4.2 encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU-T X.690.";
reference
"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).";
}
}
} // end generate-certificate-signing-request
} // end asymmetric-key-pair-with-certs-grouping
}
<CODE ENDS>
3. Security Considerations 3. Security Considerations
In order to use YANG identities for algorithm identifiers, only the In order to use YANG identities for algorithm identifiers, only the
most commonly used RSA key lengths are supported for the RSA most commonly used RSA key lengths are supported for the RSA
algorithm. Additional key lengths can be defined in another module algorithm. Additional key lengths can be defined in another module
or added into a future version of this document. or added into a future version of this document.
This document limits the number of elliptical curves supported. This This document limits the number of elliptical curves supported. This
was done to match industry trends and IETF best practice (e.g., was done to match industry trends and IETF best practice (e.g.,
matching work being done in TLS 1.3). If additional algorithms are matching work being done in TLS 1.3). If additional algorithms are
needed, they can be defined by another module or added into a future needed, they can be defined by another module or added into a future
version of this document. version of this document.
The YANG module defined in this document specifies only typedefs and Some of the operations in this YANG module may be considered
identities, and hence there are no YANG-specific security sensitive or vulnerable in some network environments. It is thus
considerations that need to be addressed. important to control access to these operations. These are the
operations and their sensitivity/vulnerability:
generate-certificate-signing-request: For this action, it is
RECOMMENDED that implementations assert channel binding
[RFC5056], so as to ensure that the application layer that sent
the request is the same as the device authenticated when the
secure transport layer was established.
This document uses PKCS #10 [RFC2986] for the "generate-certificate-
signing-request" action. The use of Certificate Request Message
Format (CRMF) [RFC4211] was considered, but is was unclear if there
was market demand for it. If it is desired to support CRMF in the
future, placing a "choice" statement in both the input and output
statements, along with an "if-feature" statement on the CRMF option,
would enable a backwards compatible solution.
NACM:default-deny-all is set on asymmetric-key-pair-grouping's
"private-key" node, as private keys should never be revealed without
explicit permission.
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 This document registers one URI in the "ns" subregistry of the IETF
XML Registry [RFC3688]. Following the format in [RFC3688], the XML Registry [RFC3688]. Following the format in [RFC3688], the
following registration is requested: following registration is requested:
URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types
skipping to change at page 20, line 37 skipping to change at page 40, line 45
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, ISO/IEC 8825-1, August 2015, X.690, ISO/IEC 8825-1, August 2015,
<https://www.itu.int/rec/T-REC-X.690/>. <https://www.itu.int/rec/T-REC-X.690/>.
[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>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>.
[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>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>.
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
<https://www.rfc-editor.org/info/rfc3565>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<https://www.rfc-editor.org/info/rfc3686>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
[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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005,
<https://www.rfc-editor.org/info/rfc4309>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494,
DOI 10.17487/RFC4494, June 2006,
<https://www.rfc-editor.org/info/rfc4494>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
DOI 10.17487/RFC4543, May 2006,
<https://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[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>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
[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>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[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>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell
(SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011,
<https://www.rfc-editor.org/info/rfc6239>.
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, DOI 10.17487/RFC6507, February 2012,
<https://www.rfc-editor.org/info/rfc6507>.
[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>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016,
<https://www.rfc-editor.org/info/rfc7919>.
[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,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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>.
[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
<https://www.rfc-editor.org/info/rfc8268>.
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
the Secure Shell (SSH) Protocol", RFC 8332,
DOI 10.17487/RFC8332, March 2018,
<https://www.rfc-editor.org/info/rfc8332>.
[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 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Request Syntax Specification Version 1.7", RFC 2986, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc8446>.
<https://www.rfc-editor.org/info/rfc2986>.
5.2. Informative References
[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>.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, Certificate Request Message Format (CRMF)", RFC 4211,
<https://www.rfc-editor.org/info/rfc5915>. DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
[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>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[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>.
Appendix A. Examples Appendix A. Examples
A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping
The following example module has been constructed to illustrate use The following example module has been constructed to illustrate use
of the "asymmetric-key-pair-with-certs-grouping" grouping defined in of the "asymmetric-key-pair-with-certs-grouping" grouping defined in
skipping to change at page 25, line 9 skipping to change at page 47, line 9
description description
"An asymmetric key pair with associated certificates."; "An asymmetric key pair with associated certificates.";
} }
} }
} }
Given the above example usage module, the following example Given the above example usage module, the following example
illustrates some configured keys. illustrates some configured keys.
<keys xmlns="http://example.com/ns/example-crypto-types-usage"> <keys xmlns="http://example.com/ns/example-crypto-types-usage">
<key> <key>
<name>locally-defined key</name> <name>ex-key</name>
<algorithm <algorithm
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
ct:secp521r1 ct:rsa2048
</algorithm> </algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<certificates>
<certificate>
<name>ex-cert</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
</key> </key>
</keys> </keys>
A.2. The "generate-hidden-key" Action A.2. The "generate-hidden-key" Action
The following example illustrates the "generate-hidden-key" action in The following example illustrates the "generate-hidden-key" action in
use with the NETCONF protocol. use with the NETCONF 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">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<keys xmlns="http://example.com/ns/example-crypto-types-usage"> <keys xmlns="http://example.com/ns/example-crypto-types-usage">
<key> <key>
<name>empty-key</name> <name>empty-key</name>
<generate-hidden-key> <generate-hidden-key>
<algorithm <algorithm
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
ct:secp521r1 ct:rsa2048
</algorithm> </algorithm>
</generate-hidden-key> </generate-hidden-key>
</key> </key>
</keys> </keys>
</action> </action>
</rpc> </rpc>
RESPONSE RESPONSE
-------- --------
<rpc-reply message-id="101" <rpc-reply message-id="101"
skipping to change at page 26, line 21 skipping to change at page 49, line 16
------- -------
<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">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<keys xmlns="http://example.com/ns/example-crypto-types-usage"> <keys xmlns="http://example.com/ns/example-crypto-types-usage">
<key> <key>
<name>empty-key</name> <name>empty-key</name>
<install-hidden-key> <install-hidden-key>
<algorithm <algorithm
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
ct:secp521r1 ct:rsa2048
</algorithm> </algorithm>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
</install-hidden-key> </install-hidden-key>
</key> </key>
</keys> </keys>
</action> </action>
</rpc> </rpc>
RESPONSE RESPONSE
skipping to change at page 28, line 43 skipping to change at page 51, line 43
o Added typedefs for other RFC 5280 structures. o Added typedefs for other RFC 5280 structures.
o Added typedefs for other RFC 5652 structures. o Added typedefs for other RFC 5652 structures.
o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652. o Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652.
B.2. 00 to 01 B.2. 00 to 01
o Moved groupings from the draft-ietf-netconf-keystore here. o Moved groupings from the draft-ietf-netconf-keystore here.
B.3. 01 to 02
o Removed unwanted "mandatory" and "must" statements.
o Added many new crypto algorithms (thanks Haiguang!)
o 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).
Acknowledgements Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Martin Bjorklund, on list and in the halls (ordered by last name): Martin Bjorklund,
Balazs Kovacs, Eric Voit, and Liang Xia. Balazs Kovacs, Eric Voit, and Liang Xia.
Author's Address Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
Wang Haiguang
Huawei
EMail: wang.haiguang.shieldlab@huawei.com
 End of changes. 114 change blocks. 
689 lines changed or deleted 1809 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/