draft-ietf-netconf-crypto-types-10.txt   draft-ietf-netconf-crypto-types-11.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: January 3, 2020 Huawei Expires: April 20, 2020 Huawei
July 2, 2019 October 18, 2019
Common YANG Data Types for Cryptography Common YANG Data Types for Cryptography
draft-ietf-netconf-crypto-types-10 draft-ietf-netconf-crypto-types-11
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-07-02" --> the publication date of this draft o "2019-10-18" --> 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 January 3, 2020. This Internet-Draft will expire on April 20, 2020.
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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 48 3. Security Considerations . . . . . . . . . . . . . . . . . . . 51
3.1. Support for Algorithms . . . . . . . . . . . . . . . . . 48 3.1. Support for Algorithms . . . . . . . . . . . . . . . . . 51
3.2. No Support for CRMF . . . . . . . . . . . . . . . . . . . 48 3.2. No Support for CRMF . . . . . . . . . . . . . . . . . . . 51
3.3. Access to Data Nodes . . . . . . . . . . . . . . . . . . 48 3.3. Access to Data Nodes . . . . . . . . . . . . . . . . . . 51
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 50 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 52
4.2. The YANG Module Names Registry . . . . . . . . . . . . . 50 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 53
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1. Normative References . . . . . . . . . . . . . . . . . . 50 5.1. Normative References . . . . . . . . . . . . . . . . . . 53
5.2. Informative References . . . . . . . . . . . . . . . . . 53 5.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 56 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 58
A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 56 A.1. The "asymmetric-key-pair-with-certs-grouping" Grouping . 58
A.2. The "generate-certificate-signing-request" Action . . . . 58 A.2. The "generate-certificate-signing-request" Action . . . . 60
A.3. The "certificate-expiration" Notification . . . . . . . . 59 A.3. The "certificate-expiration" Notification . . . . . . . . 61
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 62
B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 60 B.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 62
B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 60 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 62
B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 60 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 62
B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 61 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 63
B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 61 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 63
B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 62 B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 62 B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 62 B.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 63 B.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 63 B.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 63 B.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 65
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63 B.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
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 34 skipping to change at page 3, line 35
2.1. Tree Diagram 2.1. Tree Diagram
This section provides a tree diagram [RFC8340] for the "ietf-crypto- This section provides a tree diagram [RFC8340] for the "ietf-crypto-
types" module. Only the groupings as represented, as tree diagrams types" module. Only the groupings as represented, as tree diagrams
have no means to represent identities or typedefs. have no means to represent identities or typedefs.
module: ietf-crypto-types module: ietf-crypto-types
grouping symmetric-key-grouping grouping symmetric-key-grouping
+-- algorithm encryption-algorithm-t +-- algorithm encryption-algorithm-t
+-- key-format? identityref
+-- (key-type) +-- (key-type)
+--:(key) +--:(key)
| +-- key? binary | +-- key? binary
+--:(hidden-key) +--:(hidden-key)
+-- hidden-key? empty +-- hidden-key? empty
grouping public-key-grouping grouping public-key-grouping
+-- algorithm asymmetric-key-algorithm-t +-- algorithm asymmetric-key-algorithm-t
+-- public-key binary +-- public-key-format? identityref
+-- public-key binary
grouping asymmetric-key-pair-grouping grouping asymmetric-key-pair-grouping
+-- algorithm asymmetric-key-algorithm-t +-- algorithm asymmetric-key-algorithm-t
+-- public-key-format? identityref
+-- public-key binary +-- public-key binary
+-- private-key-format? identityref
+-- (private-key-type) +-- (private-key-type)
+--:(private-key) +--:(private-key)
| +-- private-key? binary | +-- private-key? binary
+--:(hidden-private-key) +--:(hidden-private-key)
+-- hidden-private-key? empty +-- hidden-private-key? empty
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
+-- expiration-date yang:date-and-time +-- expiration-date yang:date-and-time
grouping trust-anchor-certs-grouping grouping trust-anchor-certs-grouping
skipping to change at page 4, line 21 skipping to change at page 4, line 26
+-- cert? 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 end-entity-certs-grouping grouping end-entity-certs-grouping
+-- cert* 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 asymmetric-key-pair-with-cert-grouping grouping asymmetric-key-pair-with-cert-grouping
+-- algorithm +-- algorithm
| asymmetric-key-algorithm-t | asymmetric-key-algorithm-t
+-- public-key-format? identityref
+-- public-key binary +-- public-key binary
+-- private-key-format? identityref
+-- (private-key-type) +-- (private-key-type)
| +--:(private-key) | +--:(private-key)
| | +-- private-key? binary | | +-- private-key? binary
| +--:(hidden-private-key) | +--:(hidden-private-key)
| +-- hidden-private-key? empty | +-- hidden-private-key? empty
+-- cert? 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 asymmetric-key-pair-with-certs-grouping grouping asymmetric-key-pair-with-certs-grouping
+-- algorithm +-- algorithm
| asymmetric-key-algorithm-t | asymmetric-key-algorithm-t
+-- public-key-format? identityref
+-- public-key binary +-- public-key binary
+-- private-key-format? identityref
+-- (private-key-type) +-- (private-key-type)
| +--:(private-key) | +--:(private-key)
| | +-- private-key? binary | | +-- private-key? binary
| +--:(hidden-private-key) | +--:(hidden-private-key)
| +-- hidden-private-key? empty | +-- hidden-private-key? empty
+-- certificates +-- certificates
| +-- certificate* [name] | +-- certificate* [name]
| +-- name? string | +-- name? string
| +-- cert? end-entity-cert-cms | +-- cert? end-entity-cert-cms
| +---n certificate-expiration | +---n certificate-expiration
skipping to change at page 5, line 22 skipping to change at page 5, line 31
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-07-02.yang" <CODE BEGINS> file "ietf-crypto-types@2019-10-18.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 6, line 27 skipping to change at page 6, line 36
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.; itself for full legal notices.;
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision 2019-07-02 { revision 2019-10-18 {
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 35, line 35 skipping to change at page 35, line 44
} }
default "0"; default "0";
description description
"The uint16 filed shall be set by individual protocol "The uint16 filed shall be set by individual protocol
families according to the key exchange algorithm value families according to the key exchange algorithm value
assigned by IANA. The setting is optional and by default assigned by IANA. The setting is optional and by default
is 0. The enumeration filed is set to the selected key is 0. The enumeration filed is set to the selected key
exchange algorithm."; exchange algorithm.";
} }
/********************************************/
/* Identities for Key Format Structures */
/********************************************/
/*** all key format types ****/
identity key-format-base {
description "Base key-format identity for all keys.";
}
identity public-key-format {
base "key-format-base";
description "Base key-format identity for public keys.";
}
identity private-key-format {
base "key-format-base";
description "Base key-format identity for private keys.";
}
identity symmetric-key-format {
base "key-format-base";
description "Base key-format identity for symmetric keys.";
}
/**** for private keys ****/
identity rsa-private-key-format {
base "private-key-format";
description "An RSAPrivateKey (from RFC 3447).";
}
identity ec-private-key-format {
base "private-key-format";
description "An ECPrivateKey (from RFC 5915)";
}
identity one-asymmetric-key-format {
base "private-key-format";
description "A OneAsymmetricKey (from RFC 5958).";
}
identity encrypted-private-key-format {
base "private-key-format";
description
"A CMS EncryptedData structure (RFC 5652)
containing a OneAsymmetricKey (RFC 5958).";
}
/**** for public keys ****/
identity ssh-public-key-format {
base "public-key-format";
description
"The public key format described by RFC 4716.";
}
identity subject-public-key-info-format {
base "public-key-format";
description
"A SubjectPublicKeyInfo (from RFC 5280).";
}
/**** for symmetric keys ****/
identity octet-string-key-format {
base "symmetric-key-format";
description "An OctetString from ASN.1.";
/*
// Knowing that it is an "OctetString" isn't really helpful.
// Knowing the length of the octet string would be helpful,
// as it relates to the algorithm's block size. We may want
// to only (for now) use "one-symmetric-key-format" for
// symmetric keys...were the usability issues Juergen
// mentioned before only apply to asymmetric keys?
*/
}
identity one-symmetric-key-format {
base "symmetric-key-format";
description "A OneSymmetricKey (from RFC6031).";
}
identity encrypted-symmetric-key-format {
base "symmetric-key-format";
description
"A CMS EncryptedData structure (RFC 5652)
containing a OneSymmetricKey (RFC 6031).";
}
/***************************************************/ /***************************************************/
/* Typedefs for ASN.1 structures from RFC 5280 */ /* Typedefs for ASN.1 structures from RFC 5280 */
/***************************************************/ /***************************************************/
typedef x509 { typedef x509 {
type binary; type binary;
description description
"A Certificate structure, as specified in RFC 5280, "A Certificate structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER), encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690."; as specified in ITU-T X.690.";
skipping to change at page 40, line 9 skipping to change at page 42, line 15
This CMS encodes the degenerate form of the SignedData This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509 structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280)."; certificates and revocation objects (RFC 5280).";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile."; and Certificate Revocation List (CRL) Profile.";
} }
typedef ssh-public-key-type { // DELETE?
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";
}
/**********************************************/ /**********************************************/
/* Groupings for keys and/or certificates */ /* Groupings for keys and/or certificates */
/**********************************************/ /**********************************************/
grouping symmetric-key-grouping { grouping symmetric-key-grouping {
description description
"A symmetric key and algorithm."; "A symmetric key and algorithm.";
leaf algorithm { leaf algorithm {
type encryption-algorithm-t; type encryption-algorithm-t;
mandatory true; mandatory true;
description description
"The algorithm to be used when generating the key."; "The algorithm to be used when generating the key.";
reference reference
"RFC CCCC: Common YANG Data Types for Cryptography"; "RFC CCCC: Common YANG Data Types for Cryptography";
} }
leaf key-format {
nacm:default-deny-write;
when "../key";
type identityref {
base symmetric-key-format;
}
description "Identifies the symmetric key's format.";
}
choice key-type { choice key-type {
mandatory true; mandatory true;
description description
"Choice between key types."; "Choice between key types.";
leaf key { leaf key {
nacm:default-deny-all; nacm:default-deny-all;
type binary; type binary;
//must "../key-format"; FIXME: remove comment if approach ok
description description
"The binary value of the key. The interpretation of "The binary value of the key. The interpretation of
the value is defined by 'algorithm'. For example, the value is defined by 'key-format'. For example,
FIXME."; FIXME.";
reference reference
"RFC XXXX: FIXME"; "RFC XXXX: FIXME";
} }
leaf hidden-key { leaf hidden-key {
nacm:default-deny-write; nacm:default-deny-write;
type empty; type empty;
description description
"A permanently hidden key. How such keys are created "A permanently hidden key. How such keys are created
is outside the scope of this module."; is outside the scope of this module.";
skipping to change at page 41, line 12 skipping to change at page 43, line 41
"A public key and its associated algorithm."; "A public key and its associated algorithm.";
leaf algorithm { leaf algorithm {
nacm:default-deny-write; nacm:default-deny-write;
type asymmetric-key-algorithm-t; type asymmetric-key-algorithm-t;
mandatory true; mandatory true;
description description
"Identifies the key's algorithm."; "Identifies the key's algorithm.";
reference reference
"RFC CCCC: Common YANG Data Types for Cryptography"; "RFC CCCC: Common YANG Data Types for Cryptography";
} }
leaf public-key-format {
nacm:default-deny-write;
when "../public-key";
type identityref {
base public-key-format;
}
description "Identifies the key's format.";
}
leaf public-key { leaf public-key {
nacm:default-deny-write; nacm:default-deny-write;
type binary; type binary;
//must "../public-key-format"; FIXME: rm comment if approach ok
mandatory true; mandatory true;
description description
"The binary value of the public key. The interpretation "The binary value of the public key. The interpretation
of the value is defined by 'algorithm'. For example, of the value is defined by 'public-key-format' field.";
a DSA key is an integer, an RSA key is represented as
RSAPublicKey per RFC 8017, and an 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.";
} }
} }
grouping asymmetric-key-pair-grouping { grouping asymmetric-key-pair-grouping {
description description
"A private key and its associated public key and algorithm."; "A private key and its associated public key and algorithm.";
uses public-key-grouping; uses public-key-grouping;
leaf private-key-format {
nacm:default-deny-write;
when "../private-key";
type identityref {
base private-key-format;
}
description "Identifies the key's format.";
}
choice private-key-type { choice private-key-type {
mandatory true; mandatory true;
description description
"Choice between key types."; "Choice between key types.";
leaf private-key { leaf private-key {
nacm:default-deny-all; nacm:default-deny-all;
type binary; type binary;
//must "../private-key-format"; FIXME: rm comment if ok
description description
"The value of the binary key. The key's value is "The value of the binary key. The key's value is
interpreted by the 'algorithm'. For example, a DSA key interpreted by the 'private-key-format' field.";
is an integer, an RSA key is represented as RSAPrivateKey
as defined in RFC 8017, and an 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.";
} }
leaf hidden-private-key { leaf hidden-private-key {
nacm:default-deny-write; nacm:default-deny-write;
type empty; type empty;
description description
"A permanently hidden key. How such keys are created "A permanently hidden key. How such keys are created
is outside the scope of this module."; is outside the scope of this module.";
} }
} }
} }
skipping to change at page 56, line 9 skipping to change at page 58, line 9
<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
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 illustrates the use of both the
of the "asymmetric-key-pair-with-certs-grouping" grouping defined in "symmetric-key-grouping" and the "asymmetric-key-pair-with-certs-
the "ietf-crypto-types" module. grouping" groupings defined in the "ietf-crypto-types" module.
Note that the "asymmetric-key-pair-with-certs-grouping" grouping uses
both the "asymmetric-key-pair-grouping" and "end-entity-cert-
grouping" groupings, and that the "asymmetric-key-pair-grouping"
grouping uses the "public-key-grouping" grouping. Thus, a total of
four of the five groupings defined in the "ietf-crypto-types" module
are illustrated through the use of this one grouping. The only
grouping not represented is the "trust-anchor-cert-grouping"
grouping.
module ex-crypto-types-usage { module ex-crypto-types-usage {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/ns/example-crypto-types-usage"; namespace "http://example.com/ns/example-crypto-types-usage";
prefix "ectu"; prefix "ectu";
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
skipping to change at page 57, line 35 skipping to change at page 58, line 43
defined in the crypto-types draft called defined in the crypto-types draft called
'asymmetric-key-pair-with-certs-grouping'."; 'asymmetric-key-pair-with-certs-grouping'.";
revision "1001-01-01" { revision "1001-01-01" {
description description
"Initial version"; "Initial version";
reference reference
"RFC ????: Usage Example for RFC XXXX"; "RFC ????: Usage Example for RFC XXXX";
} }
container keys { container symmetric-keys {
description description
"A container of keys."; "A container of symmetric keys.";
list key { list symmetric-key {
key name;
description
"A symmetric key";
leaf name {
type string;
description
"An arbitrary name for this key.";
}
uses ct:symmetric-key-grouping;
}
}
container asymmetric-keys {
description
"A container of asymmetric keys.";
list asymmetric-key {
key name; key name;
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for this key."; "An arbitrary name for this key.";
} }
uses ct:asymmetric-key-pair-with-certs-grouping; uses ct:asymmetric-key-pair-with-certs-grouping;
description description
"An asymmetric key pair with associated certificates."; "An asymmetric key pair with associated certificates.";
} }
skipping to change at page 58, line 4 skipping to change at page 59, line 25
type string; type string;
description description
"An arbitrary name for this key."; "An arbitrary name for this key.";
} }
uses ct:asymmetric-key-pair-with-certs-grouping; uses ct:asymmetric-key-pair-with-certs-grouping;
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"> ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<key>
<name>ex-key</name> <symmetric-keys xmlns="http://example.com/ns/example-crypto-types-us\
age"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<symmetric-key>
<name>ex-symmetric-key</name>
<algorithm>aes-256-cbc</algorithm>
<key-format>ct:octet-string-key-format</key-format>
<key>base64encodedvalue==</key>
</symmetric-key>
<symmetric-key>
<name>ex-hidden-symmetric-key</name>
<algorithm>aes-256-cbc</algorithm>
<hidden-key/>
</symmetric-key>
</symmetric-keys>
<asymmetric-keys xmlns="http://example.com/ns/example-crypto-types-u\
sage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<asymmetric-key>
<name>ex-asymmetric-key</name>
<algorithm>rsa2048</algorithm> <algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public-key\
-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<private-key-format>ct:rsa-private-key-format</private-key-forma\
t>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-cert</name> <name>ex-cert</name>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</certificate> </certificate>
</certificates> </certificates>
</key> </asymmetric-key>
<key> <asymmetric-key>
<name>ex-hidden-key</name> <name>ex-hidden-asymmetric-key</name>
<algorithm>rsa2048</algorithm> <algorithm>rsa2048</algorithm>
<public-key-format>ct:subject-public-key-info-format</public-key\
-format>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<hidden-private-key/> <hidden-private-key/>
<certificates> <certificates>
<certificate> <certificate>
<name>ex-hidden-key-cert</name> <name>ex-hidden-key-cert</name>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</certificate> </certificate>
</certificates> </certificates>
</key> </asymmetric-key>
</keys> </asymmetric-keys>
A.2. The "generate-certificate-signing-request" Action A.2. The "generate-certificate-signing-request" Action
The following example illustrates the "generate-certificate-signing- The following example illustrates the "generate-certificate-signing-
request" action in use with the NETCONF protocol. request" action in use with the NETCONF protocol.
REQUEST REQUEST
========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
<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"> <asymmetric-keys xmlns="http://example.com/ns/example-crypto-typ\
<key> es-usage">
<asymmetric-key>
<name>ex-key-sect571r1</name> <name>ex-key-sect571r1</name>
<generate-certificate-signing-request> <generate-certificate-signing-request>
<subject>base64encodedvalue==</subject> <subject>base64encodedvalue==</subject>
<attributes>base64encodedvalue==</attributes> <attributes>base64encodedvalue==</attributes>
</generate-certificate-signing-request> </generate-certificate-signing-request>
</key> </asymmetric-key>
</keys> </asymmetric-keys>
</action> </action>
</rpc> </rpc>
RESPONSE RESPONSE
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<certificate-signing-request <certificate-signing-request
xmlns="http://example.com/ns/example-crypto-types-usage"> xmlns="http://example.com/ns/example-crypto-types-usage">
base64encodedvalue== base64encodedvalue==
skipping to change at page 63, line 47 skipping to change at page 65, line 47
draft in i2nsf may still want to use them. draft in i2nsf may still want to use them.
o Add x25519 and x448 curve for asymmetric algorithms o Add x25519 and x448 curve for asymmetric algorithms
o Add signature algorithms ed25519, ed25519-cts, ed25519ph o Add signature algorithms ed25519, ed25519-cts, ed25519ph
o add signature algorithms ed448, ed448ph o add signature algorithms ed448, ed448ph
o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332) o Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332)
B.12. 10 to 11
o Added a "key-format" identity.
o Added symmetric keys to the example in Appendix A.
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,
Nick Hancock, Balazs Kovacs, Juergen Schoenwaelder, Eric Voit, and Nick Hancock, Balazs Kovacs, Juergen Schoenwaelder, Eric Voit, and
Liang Xia. Liang Xia.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
 End of changes. 40 change blocks. 
81 lines changed or deleted 250 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/