draft-ietf-netconf-crypto-types-05.txt   draft-ietf-netconf-crypto-types-06.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Watsen Networks Internet-Draft Watsen Networks
Intended status: Standards Track H. Wang Intended status: Standards Track H. Wang
Expires: September 10, 2019 Huawei Expires: October 31, 2019 Huawei
March 9, 2019 April 29, 2019
Common YANG Data Types for Cryptography Common YANG Data Types for Cryptography
draft-ietf-netconf-crypto-types-05 draft-ietf-netconf-crypto-types-06
Abstract Abstract
This document defines YANG identities, typedefs, the groupings useful This document defines YANG identities, typedefs, the groupings useful
for 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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 "2019-03-09" --> the publication date of this draft o "2019-04-29" --> 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 B. 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 September 10, 2019. This Internet-Draft will expire on October 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 38 3. Security Considerations . . . . . . . . . . . . . . . . . . . 42
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 3.1. Support for Algorithms . . . . . . . . . . . . . . . . . 42
4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 39 3.2. No Support for CRMF . . . . . . . . . . . . . . . . . . . 43
4.2. The YANG Module Names Registry . . . . . . . . . . . . . 39 3.3. Access to Data Nodes . . . . . . . . . . . . . . . . . . 43
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
5.1. Normative References . . . . . . . . . . . . . . . . . . 39 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 44
5.2. Informative References . . . . . . . . . . . . . . . . . 42 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 44
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 44 5.1. Normative References . . . . . . . . . . . . . . . . . . 45
A.2. The "generate-hidden-key" Action . . . . . . . . . . . . 46 5.2. Informative References . . . . . . . . . . . . . . . . . 47
A.3. The "install-hidden-key" Action . . . . . . . . . . . . . 47 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 50
A.4. The "generate-certificate-signing-request" Action . . . . 47 A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 50
A.5. The "certificate-expiration" Notification . . . . . . . . 48 A.2. The "generate-hidden-key" Action . . . . . . . . . . . . 52
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 49 A.3. The "install-hidden-key" Action . . . . . . . . . . . . . 53
B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.4. The "generate-certificate-signing-request" Action . . . . 53
B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.5. The "certificate-expiration" Notification . . . . . . . . 54
B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 49 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 55
B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 55
B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 55
B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 55
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 56
B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 57
B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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, typedefs, and groupings 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
skipping to change at page 3, line 45 skipping to change at page 3, line 49
| +---w algorithm asymmetric-key-algorithm-ref | +---w algorithm asymmetric-key-algorithm-ref
+---x install-hidden-key +---x install-hidden-key
+---- input +---- input
+---w algorithm asymmetric-key-algorithm-ref +---w algorithm asymmetric-key-algorithm-ref
+---w public-key? binary +---w public-key? binary
+---w private-key? binary +---w private-key? binary
grouping trust-anchor-cert-grouping: grouping trust-anchor-cert-grouping:
+---- cert? trust-anchor-cert-cms +---- cert? trust-anchor-cert-cms
+---n certificate-expiration +---n certificate-expiration
+--ro expiration-date ietf-yang-types:date-and-time +--ro expiration-date ietf-yang-types:date-and-time
grouping trust-anchor-certs-grouping:
+---- cert* trust-anchor-cert-cms
+---n certificate-expiration
+--ro expiration-date ietf-yang-types:date-and-time
grouping end-entity-cert-grouping: grouping end-entity-cert-grouping:
+---- cert? end-entity-cert-cms +---- cert? end-entity-cert-cms
+---n certificate-expiration +---n certificate-expiration
+--ro expiration-date ietf-yang-types:date-and-time +--ro expiration-date ietf-yang-types:date-and-time
grouping end-entity-certs-grouping:
+---- cert* end-entity-cert-cms
+---n certificate-expiration
+--ro expiration-date ietf-yang-types:date-and-time
grouping asymmetric-key-pair-with-cert-grouping:
+---- algorithm?
| asymmetric-key-algorithm-ref
+---- public-key? binary
+---- private-key? union
+---x generate-hidden-key
| +---- input
| +---w algorithm asymmetric-key-algorithm-ref
+---x install-hidden-key
| +---- input
| +---w algorithm asymmetric-key-algorithm-ref
| +---w public-key? binary
| +---w private-key? binary
+---- cert? end-entity-cert-cms
+---n certificate-expiration
+--ro expiration-date ietf-yang-types:date-and-time
+---x generate-certificate-signing-request
+---- input
| +---w subject binary
| +---w attributes? binary
+---- output
+--ro certificate-signing-request binary
grouping asymmetric-key-pair-with-certs-grouping: grouping asymmetric-key-pair-with-certs-grouping:
+---- algorithm? +---- algorithm?
| asymmetric-key-algorithm-ref | asymmetric-key-algorithm-ref
+---- public-key? binary +---- public-key? binary
+---- private-key? union +---- private-key? union
+---x generate-hidden-key +---x generate-hidden-key
| +---- input | +---- input
| +---w algorithm asymmetric-key-algorithm-ref | +---w algorithm asymmetric-key-algorithm-ref
+---x install-hidden-key +---x install-hidden-key
| +---- input | +---- input
skipping to change at page 4, line 38 skipping to change at page 5, line 25
This module has normative references to [RFC2404], [RFC3565], This module has normative references to [RFC2404], [RFC3565],
[RFC3686], [RFC4106], [RFC4253], [RFC4279], [RFC4309], [RFC4494], [RFC3686], [RFC4106], [RFC4253], [RFC4279], [RFC4309], [RFC4494],
[RFC4543], [RFC4868], [RFC5280], [RFC5652], [RFC5656], [RFC6187], [RFC4543], [RFC4868], [RFC5280], [RFC5652], [RFC5656], [RFC6187],
[RFC6991], [RFC7919], [RFC8268], [RFC8332], [RFC8341], [RFC8422], [RFC6991], [RFC7919], [RFC8268], [RFC8332], [RFC8341], [RFC8422],
[RFC8446], and [ITU.X690.2015]. [RFC8446], and [ITU.X690.2015].
This module has an informational reference to [RFC2986], [RFC3174], This module has an informational reference to [RFC2986], [RFC3174],
[RFC4493], [RFC5915], [RFC6125], [RFC6234], [RFC6239], [RFC6507], [RFC4493], [RFC5915], [RFC6125], [RFC6234], [RFC6239], [RFC6507],
[RFC8017], [RFC8032], [RFC8439]. [RFC8017], [RFC8032], [RFC8439].
<CODE BEGINS> file "ietf-crypto-types@2019-03-09.yang" <CODE BEGINS> file "ietf-crypto-types@2019-04-29.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";
skipping to change at page 4, line 50 skipping to change at page 5, line 37
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 <mailto:kent+ietf@watsen.net> Author: Kent Watsen <mailto:kent+ietf@watsen.net>
Author: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>"; Author: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>";
description description
"This module defines common YANG types for cryptographic "This module defines common YANG types for cryptographic
applications. applications.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified Copyright (c) 2019 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX
the RFC itself for full legal notices."; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.;
revision 2019-03-09 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2019-04-29 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Common YANG Data Types for Cryptography"; "RFC XXXX: Common YANG Data Types for Cryptography";
} }
/**************************************/ /**************************************/
/* Identities for Hash Algorithms */ /* Identities for Hash Algorithms */
/**************************************/ /**************************************/
skipping to change at page 32, line 28 skipping to change at page 33, line 13
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile."; and Certificate Revocation List (CRL) Profile.";
} }
/**********************************************/ /**********************************************/
/* Groupings for keys and/or certificates */ /* Groupings for keys and/or certificates */
/**********************************************/ /**********************************************/
grouping public-key-grouping { grouping public-key-grouping {
description description
"A public key."; "A public key.
The 'algorithm' and 'public-key' nodes are not
mandatory because they MAY be defined in <operational>.
Implementations SHOULD assert that these values are
either configured or that they exist in <operational>.";
leaf algorithm { leaf algorithm {
nacm:default-deny-write;
type asymmetric-key-algorithm-ref; type asymmetric-key-algorithm-ref;
must '../public-key';
description description
"Identifies the key's algorithm. More specifically, "Identifies the key's algorithm. More specifically,
this leaf specifies how the 'public-key' binary leaf this leaf specifies how the 'public-key' binary leaf
is encoded."; is encoded.";
reference reference
"RFC CCCC: Common YANG Data Types for Cryptography"; "RFC CCCC: Common YANG Data Types for Cryptography";
} }
leaf public-key { leaf public-key {
nacm:default-deny-write;
type binary; type binary;
must '../algorithm';
description description
"A binary that contains the value of the public key. The "A binary that contains the value of the public key. The
interpretation of the content is defined by the key interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPublicKey as defined in key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in is represented using the 'publicKey' described in
RFC 5915."; RFC 5915.";
reference reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1: "RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
skipping to change at page 33, line 4 skipping to change at page 33, line 47
algorithm. For example, a DSA key is an integer, an RSA algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPublicKey as defined in key is represented as RSAPublicKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented using the 'publicKey' described in is represented using the 'publicKey' described in
RFC 5915."; RFC 5915.";
reference reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1: "RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2. RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure."; RFC 5915: Elliptic Curve Private Key Structure.";
} }
} }
grouping asymmetric-key-pair-grouping { grouping asymmetric-key-pair-grouping {
description description
"A private/public key pair."; "A private/public key pair.
uses public-key-grouping;
The 'algorithm', 'public-key', and 'private-key' nodes are
not mandatory because they MAY be defined in <operational>.
Implementations SHOULD assert that these values are either
configured or that they exist in <operational>.";
uses public-key-grouping;
leaf private-key { leaf private-key {
nacm:default-deny-all; nacm:default-deny-all;
type union { type union {
type binary; type binary;
type enumeration { type enumeration {
enum permanently-hidden { enum permanently-hidden {
description description
"The private key is inaccessible due to being "The private key is inaccessible due to being
protected by the system (e.g., a cryptographic protected by the system (e.g., a cryptographic
hardware module). It is not possible to hardware module).
configure a permanently hidden key, as a real
private key value must be set. Permanently How such keys are backed-up and restored, if
hidden keys cannot be archived or backed up."; at all, is implementation specific.
Servers MUST fail any attempt by a client to
configure this value directly. This value is
not set by clients, but rather is set by the
'generate-hidden-key' and 'install-hidden-key'
actions.";
} }
} }
} }
must '../public-key';
description description
"A binary that contains the value of the private key. The "A binary that contains the value of the private key. The
interpretation of the content is defined by the key interpretation of the content is defined by the key
algorithm. For example, a DSA key is an integer, an RSA algorithm. For example, a DSA key is an integer, an RSA
key is represented as RSAPrivateKey as defined in key is represented as RSAPrivateKey as defined in
RFC 8017, and an Elliptic Curve Cryptography (ECC) key RFC 8017, and an Elliptic Curve Cryptography (ECC) key
is represented as ECPrivateKey as defined in RFC 5915."; is represented as ECPrivateKey as defined in RFC 5915.";
reference reference
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1: "RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2. RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure."; RFC 5915: Elliptic Curve Private Key Structure.";
} // private-key } // private-key
action generate-hidden-key { action generate-hidden-key {
nacm:default-deny-all;
description description
"Requests the device to generate a hidden key using the "Requests the device to generate a hidden key using the
specified asymmetric key algorithm. This action is specified asymmetric key algorithm. This action is
used to request the system to generate a key that used to request the system to generate a key that is
is 'permanently-hidden', perhaps protected by a 'permanently-hidden', perhaps protected by a cryptographic
cryptographic hardware module. The resulting hardware module. The resulting asymmetric key values are
asymmetric key values are considered operational considered operational state and hence present only in
state and hence present only in <operational>."; <operational> and bound to the lifetime of the parent
'config true' node. Subsequent invocations of this or
the 'install-hidden-key' action are denied with error-tag
'data-exists'.";
input { input {
leaf algorithm { leaf algorithm {
type asymmetric-key-algorithm-ref; type asymmetric-key-algorithm-ref;
mandatory true; mandatory true;
description description
"The algorithm to be used when generating the "The algorithm to be used when generating the
asymmetric key."; asymmetric key.";
reference reference
"RFC CCCC: Common YANG Data Types for Cryptography"; "RFC CCCC: Common YANG Data Types for Cryptography";
} }
} }
} // generate-hidden-key } // generate-hidden-key
action install-hidden-key { action install-hidden-key {
nacm:default-deny-all;
description description
"Requests the device to load the specified values into "Requests the device to load the specified values into
a hidden key. The resulting asymmetric key values are a hidden key. The resulting asymmetric key values are
considered operational state and hence present only in considered operational state and hence present only in
<operational>."; <operational> and bound to the lifetime of the parent
'config true' node. Subsequent invocations of this
or the 'generate-hidden-key' action are denied with
error-tag 'data-exists'.";
input { input {
leaf algorithm { leaf algorithm {
type asymmetric-key-algorithm-ref; type asymmetric-key-algorithm-ref;
mandatory true; mandatory true;
description description
"The algorithm to be used when generating the "The algorithm to be used when generating the
asymmetric key."; asymmetric key.";
reference reference
"RFC CCCC: Common YANG Data Types for Cryptography"; "RFC CCCC: Common YANG Data Types for Cryptography";
} }
skipping to change at page 35, line 17 skipping to change at page 36, line 30
"RFC 8017: Public-Key Cryptography Standards (PKCS) #1: "RFC 8017: Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.2. RSA Cryptography Specifications Version 2.2.
RFC 5915: Elliptic Curve Private Key Structure."; RFC 5915: Elliptic Curve Private Key Structure.";
} }
} }
} // install-hidden-key } // install-hidden-key
} // asymmetric-key-pair-grouping } // asymmetric-key-pair-grouping
grouping trust-anchor-cert-grouping { grouping trust-anchor-cert-grouping {
description description
"A certificate, and a notification for when it might expire."; "A trust anchor certificate, and a notification for when
it is about to (or already has) expire.";
leaf cert { leaf cert {
nacm:default-deny-write;
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.";
}
}
}
grouping trust-anchor-certs-grouping {
description
"A list of trust anchor certificates, and a notification
for when one is about to (or already has) expire.";
leaf-list cert {
nacm:default-deny-write;
type trust-anchor-cert-cms; type trust-anchor-cert-cms;
description description
"The binary certificate data for this certificate."; "The binary certificate data for this certificate.";
reference reference
"RFC YYYY: Common YANG Data Types for Cryptography"; "RFC YYYY: Common YANG Data Types for Cryptography";
} }
notification certificate-expiration { notification certificate-expiration {
description description
"A notification indicating that the configured certificate "A notification indicating that the configured certificate
is either about to expire or has already expired. When to is either about to expire or has already expired. When to
skipping to change at page 35, line 44 skipping to change at page 37, line 41
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Identifies the expiration date on the certificate."; "Identifies the expiration date on the certificate.";
} }
} }
} }
grouping end-entity-cert-grouping { grouping end-entity-cert-grouping {
description description
"A certificate, and a notification for when it might expire."; "An end entity certificate, and a notification for when
it is about to (or already has) expire.";
leaf cert { leaf cert {
nacm:default-deny-write;
type end-entity-cert-cms; type end-entity-cert-cms;
description description
"The binary certificate data for this certificate."; "The binary certificate data for this certificate.";
reference reference
"RFC YYYY: Common YANG Data Types for Cryptography"; "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.";
}
}
}
grouping end-entity-certs-grouping {
description
"A list of end entity certificates, and a notification for
when one is about to (or already has) expire.";
leaf-list cert {
nacm:default-deny-write;
type end-entity-cert-cms;
description
"The binary certificate data for this certificate.";
reference
"RFC YYYY: Common YANG Data Types for Cryptography";
} }
notification certificate-expiration { notification certificate-expiration {
description description
"A notification indicating that the configured certificate "A notification indicating that the configured certificate
is either about to expire or has already expired. When to is either about to expire or has already expired. When to
send notifications is an implementation specific decision, send notifications is an implementation specific decision,
but it is RECOMMENDED that a notification be sent once a but it is RECOMMENDED that a notification be sent once a
month for 3 months, then once a week for four weeks, and month for 3 months, then once a week for four weeks, and
then once a day thereafter until the issue is resolved."; then once a day thereafter until the issue is resolved.";
leaf expiration-date { leaf expiration-date {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Identifies the expiration date on the certificate."; "Identifies the expiration date on the certificate.";
} }
} }
} }
grouping asymmetric-key-pair-with-cert-grouping {
description
"A private/public key pair and an associated certificate.";
uses asymmetric-key-pair-grouping;
uses end-entity-cert-grouping;
action generate-certificate-signing-request {
nacm:default-deny-all;
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 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).";
}
}
} // generate-certificate-signing-request
} // asymmetric-key-pair-with-cert-grouping
grouping asymmetric-key-pair-with-certs-grouping { grouping asymmetric-key-pair-with-certs-grouping {
description description
"A private/public key pair and associated certificates."; "A private/public key pair and associated certificates.";
uses asymmetric-key-pair-grouping; uses asymmetric-key-pair-grouping;
container certificates { container certificates {
nacm:default-deny-write;
description description
"Certificates associated with this asymmetric key. "Certificates associated with this asymmetric key.
More than one certificate supports, for instance, More than one certificate supports, for instance,
a TPM-protected asymmetric key that has both IDevID a TPM-protected asymmetric key that has both IDevID
and LDevID certificates associated."; and LDevID certificates associated.";
list certificate { list certificate {
key "name"; key "name";
description description
"A certificate for this asymmetric key."; "A certificate for this asymmetric key.";
leaf name { leaf name {
skipping to change at page 36, line 44 skipping to change at page 41, line 4
key "name"; key "name";
description description
"A certificate for this asymmetric key."; "A certificate for this asymmetric key.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the certificate. If the name "An arbitrary name for the certificate. If the name
matches the name of a certificate that exists matches the name of a certificate that exists
independently in <operational> (i.e., an IDevID), independently in <operational> (i.e., an IDevID),
then the 'cert' node MUST NOT be configured."; then the 'cert' node MUST NOT be configured.";
} }
uses end-entity-cert-grouping; uses end-entity-cert-grouping;
} }
} // certificates } // certificates
action generate-certificate-signing-request { action generate-certificate-signing-request {
nacm:default-deny-all;
description description
"Generates a certificate signing request structure for "Generates a certificate signing request structure for
the associated asymmetric key using the passed subject the associated asymmetric key using the passed subject
and attribute values. The specified assertions need and attribute values. The specified assertions need
to be appropriate for the certificate's use. For to be appropriate for the certificate's use. For
example, an entity certificate for a TLS server example, an entity certificate for a TLS server
SHOULD have values that enable clients to satisfy SHOULD have values that enable clients to satisfy
RFC 6125 processing."; RFC 6125 processing.";
input { input {
leaf subject { leaf subject {
skipping to change at page 38, line 20 skipping to change at page 42, line 30
Specification Version 1.7. Specification Version 1.7.
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER).";
} }
} }
} // generate-certificate-signing-request } // generate-certificate-signing-request
} // asymmetric-key-pair-with-certs-grouping } // asymmetric-key-pair-with-certs-grouping
} }
<CODE ENDS> <CODE ENDS>
3. Security Considerations 3. Security Considerations
3.1. Support for Algorithms
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.
3.2. No Support for CRMF
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, a backwards compatible solution can be defined at that time.
3.3. Access to Data Nodes
The YANG module in this document defines "grouping" statements that
are designed to be accessed via YANG based management protocols, such
as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols
have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.
The NETCONF access control model (NACM) [RFC8341] provides the means
to restrict access for particular users to a pre-configured subset of
all available protocol operations and content.
Since the module in this document only define groupings, these
considerations are primarily for the designers of other modules that
use these groupings.
There are a number of data nodes defined by the grouping statements
that are writable/creatable/deletable (i.e., config true, which is
the default). Some of these data nodes may be considered sensitive
or vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations. These are the subtrees and
data nodes and their sensitivity/vulnerability:
*: All of the data nodes defined by all the groupings are
considered sensitive to write operations. For instance, the
modification of a public key or a certificate can dramatically
alter the implemented security policy. For this reason, the
NACM extension "default-deny-write" has been applied to all the
data nodes defined by all the groupings.
Some of the readable data nodes in the YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/private-key: The "private-key" node defined in the "asymmetric-
key-pair-grouping" grouping is additionally sensitive to read
operations such that, in normal use cases, it should never be
returned to a client. For this reason, the NACM extension
"default-deny-all" has been applied to it here.
Some of the operations in this YANG module may be considered Some of the operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
*: All of the "action" statements defined by groupings SHOULD only
be executed by authorized users. For this reason, the NACM
extension "default-deny-all" has been applied to all of them.
Note that NACM uses "default-deny-all" to protect "RPC" and
"action" statements; it does not define, e.g., an extension
called "default-deny-execute".
generate-certificate-signing-request: For this action, it is generate-certificate-signing-request: For this action, it is
RECOMMENDED that implementations assert channel binding RECOMMENDED that implementations assert channel binding
[RFC5056], so as to ensure that the application layer that sent [RFC5056], so as to ensure that the application layer that sent
the request is the same as the device authenticated when the the request is the same as the device authenticated when the
secure transport layer was established. 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
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
skipping to change at page 43, line 26 skipping to change at page 48, line 43
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell [RFC6239] Igoe, K., "Suite B Cryptographic Suites for Secure Shell
(SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011, (SSH)", RFC 6239, DOI 10.17487/RFC6239, May 2011,
<https://www.rfc-editor.org/info/rfc6239>. <https://www.rfc-editor.org/info/rfc6239>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)", Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, DOI 10.17487/RFC6507, February 2012, RFC 6507, DOI 10.17487/RFC6507, February 2012,
<https://www.rfc-editor.org/info/rfc6507>. <https://www.rfc-editor.org/info/rfc6507>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
Appendix A. Examples Appendix A. Examples
skipping to change at page 51, line 9 skipping to change at page 57, line 9
folding algorithm. folding algorithm.
B.5. 03 to 04 B.5. 03 to 04
o ran YANG module through formatter. o ran YANG module through formatter.
B.6. 04 to 05 B.6. 04 to 05
o fixed broken symlink causing reformatted YANG module to not show. o fixed broken symlink causing reformatted YANG module to not show.
B.7. 05 to 06
o Added NACM annotations.
o Updated Security Considerations section.
o Added 'asymmetric-key-pair-with-cert-grouping' grouping.
o Removed text from 'permanently-hidden' enum regarding such keys
not being backed up or restored.
o Updated the boilerplate text in module-level "description"
statement to match copyeditor convention.
o Added an explanation to the 'public-key-grouping' and 'asymmetric-
key-pair-grouping' statements as for why the nodes are not
mandatory (e.g., because they may exist only in <operational>.
o Added 'must' expressions to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements ensuring sibling nodes
are either all exist or do not all exist.
o Added an explanation to the 'permanently-hidden' that the value
cannot be configured directly by clients and servers MUST fail any
attempt to do so.
o Added 'trust-anchor-certs-grouping' and 'end-entity-certs-
grouping' (the plural form of existing groupings).
o Now states that keys created in <operational> by the *-hidden-key
actions are bound to the lifetime of the parent 'config true'
node, and that subsequent invocations of either action results in
a failure.
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, Juergen Schoenwaelder, Eric Voit, and Liang Xia.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
EMail: kent+ietf@watsen.net EMail: kent+ietf@watsen.net
Wang Haiguang Wang Haiguang
Huawei Huawei
 End of changes. 48 change blocks. 
70 lines changed or deleted 367 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/