draft-ietf-netconf-keystore-01.txt   draft-ietf-netconf-keystore-02.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track March 13, 2017 Intended status: Standards Track June 13, 2017
Expires: September 14, 2017 Expires: December 15, 2017
Keystore Model Keystore Model
draft-ietf-netconf-keystore-01 draft-ietf-netconf-keystore-02
Abstract Abstract
This document defines a YANG data module for a system-level keystore This document defines a YANG data module for a system-level keystore
mechanism, that might be used to hold onto private keys and mechanism, that might be used to hold onto private keys and
certificates that are trusted by the system advertising support for certificates that are trusted by the system advertising support for
this module. this module.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 "VVVV" --> the assigned RFC value for this draft o "VVVV" --> 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 "2017-03-13" --> the publication date of this draft o "2017-06-13" --> the publication date of this draft
The following two Appendix sections are to be removed prior to The following Appendix section is to be removed prior to publication:
publication:
o Appendix A. Change Log o Appendix A. Change Log
o Appendix B. Open Issues
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 14, 2017. This Internet-Draft will expire on December 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 38 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3
2. The Keystore Model . . . . . . . . . . . . . . . . . . . . . 4 2. The Keystore Model . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 20 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 22 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 23
5.2. The YANG Module Names Registry . . . . . . . . . . . . . 22 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 23 7.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 25 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 26
A.2. keychain-00 to keystore-00 . . . . . . . . . . . . . . . 25 A.2. keychain-00 to keystore-00 . . . . . . . . . . . . . . . 26
A.3. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 25 A.3. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 25 A.4. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] data module for a system-level This document defines a YANG [RFC6020] data module for a system-level
keystore mechanism, which can be used to hold onto private keys and keystore mechanism, which can be used to hold onto private keys and
certificates that are trusted by the system advertising support for certificates that are trusted by the system advertising support for
this module. this module.
This module provides a centralized location for security sensitive This module provides a centralized location for security sensitive
data, so that the data can be then referenced by other modules. data, so that the data can be then referenced by other modules.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
2.1. Overview 2.1. Overview
The keystore module has the following tree diagram. Please see The keystore module has the following tree diagram. Please see
Section 1.2 for information on how to interpret this diagram. Section 1.2 for information on how to interpret this diagram.
module: ietf-keystore module: ietf-keystore
+--rw keystore +--rw keystore
+--rw keys +--rw keys
| +--rw key* [name] | +--rw key* [name]
| +--rw name string | | +--rw name string
| +--rw algorithm-identifier identityref | | +--rw algorithm-identifier identityref
| +--rw private-key union | | +--rw private-key union
| +--ro public-key binary | | +--ro public-key binary
| +--rw certificates | | +--rw certificates
| | +--rw certificate* [name] | | | +--rw certificate* [name]
| | +--rw name string | | | +--rw name string
| | +--rw value? binary | | | +--rw value? binary
| +---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
| +---x generate-private-key
| +---w input
| +---w name string
| +---w algorithm identityref
+--rw trusted-certificates* [name] +--rw trusted-certificates* [name]
| +--rw name string | +--rw name string
| +--rw description? string | +--rw description? string
| +--rw trusted-certificate* [name] | +--rw trusted-certificate* [name]
| +--rw name string | +--rw name string
| +--rw certificate? binary | +--rw certificate? binary
+--rw trusted-host-keys* [name] +--rw trusted-host-keys* [name]
+--rw name string +--rw name string
+--rw description? string +--rw description? string
+--rw trusted-host-key* [name] +--rw trusted-host-key* [name]
skipping to change at page 8, line 37 skipping to change at page 8, line 42
request" action in use with the NETCONF protocol. request" action in 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">
<keystore <keystore
xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"> xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
<private-keys> <keys>
<private-key> <key>
<name>ex-key-sect571r1</name> <name>ex-key-sect571r1</name>
<generate-certificate-signing-request> <generate-certificate-signing-request>
<subject> <subject>
cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2R
manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO manZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNlmO
Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo= Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmR6Zgo=
</subject> </subject>
<attributes> <attributes>
bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4 bwtakWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvut4
arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm arnZvO3NkZmJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYm
Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp= Z2aXNiZGZpYmhzZG87ZmJvO3NkZ25iO29pLmC6Rhp=
</attributes> </attributes>
</generate-certificate-signing-request> </generate-certificate-signing-request>
</key>
</private-key> </keys>
</private-keys>
</keystore> </keystore>
</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
skipping to change at page 9, line 38 skipping to change at page 9, line 42
ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d
mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0 mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0
RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx
rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx
TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d
c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV
SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
</certificate-signing-request> </certificate-signing-request>
</rpc-reply> </rpc-reply>
The following example illustrates the "generate-private-key" action
in use with the RESTCONF protocol and JSON encoding.
REQUEST
-------
['\' line wrapping added for formatting only]
POST https://example.com/restconf/data/ietf-keystore:keystore/\
keys/generate-private-key HTTP/1.1
HOST: example.com
Content-Type: application/yang.operation+json
{
"ietf-keystore:input" : {
"name" : "ex-key-sect571r1",
"algorithm" : "sect571r1"
}
}
RESPONSE
--------
HTTP/1.1 204 No Content
Date: Mon, 31 Oct 2015 11:01:00 GMT
Server: example-server
The following example illustrates a "certificate-expiration" The following example illustrates a "certificate-expiration"
notification in XML. notification in XML.
['\' line wrapping added for formatting only] ['\' line wrapping added for formatting only]
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2016-07-08T00:01:00Z</eventTime> <eventTime>2016-07-08T00:01:00Z</eventTime>
<certificate-expiration <certificate-expiration
xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"> xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
skipping to change at page 10, line 24 skipping to change at page 11, line 5
</certificate> </certificate>
<expiration-date>2016-08-08T14:18:53-05:00</expiration-date> <expiration-date>2016-08-08T14:18:53-05:00</expiration-date>
</certificate-expiration> </certificate-expiration>
</notification> </notification>
2.3. YANG Module 2.3. YANG Module
This YANG module makes extensive use of data types defined in This YANG module makes extensive use of data types defined in
[RFC5280] and [RFC5958]. [RFC5280] and [RFC5958].
<CODE BEGINS> file "ietf-keystore@2017-03-13.yang" <CODE BEGINS> file "ietf-keystore@2017-06-13.yang"
module ietf-keystore { module ietf-keystore {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; namespace "urn:ietf:params:xml:ns:yang:ietf-keystore";
prefix "ks"; prefix "ks";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
skipping to change at page 11, line 24 skipping to change at page 12, line 5
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). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2017-03-13" { revision "2017-06-13" {
description description
"Initial version"; "Initial version";
reference reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration "RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models"; Models";
} }
// Identities // Identities
identity key-algorithm { identity key-algorithm {
skipping to change at page 14, line 21 skipping to change at page 14, line 48
type string; type string;
description description
"An arbitrary name for the key."; "An arbitrary name for the key.";
} }
leaf algorithm-identifier { leaf algorithm-identifier {
type identityref { type identityref {
base "key-algorithm"; base "key-algorithm";
} }
mandatory true; mandatory true;
description description
"Identifies which algorithm is to be used with the key. "Identifies which algorithm is to be used to generate the
This value determines how the 'private-key' and 'public- key.";
key' fields are interpreted."; // no 'params' like in RFC 5912? - none are set for
// no params, such as in RFC 5912? (no are set for algs // algs we care about, but what about the future?
// we care about, but what about the future?
} }
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 "RESTRICTED" {
description
"The private key is restricted due to access-control.";
}
enum "INACCESSIBLE" { enum "INACCESSIBLE" {
description description
"The private key is inaccessible due to being protected "The private key is inaccessible due to being protected
by the cryptographic hardware modules (e.g., a TPM)."; by a cryptographic hardware module (e.g., a TPM).";
} }
} }
} }
mandatory true; mandatory true;
description description
"A binary string that contains the value of the private "A binary string that contains the value of the private
key. The interpretation of the content is defined in the key. The interpretation of the content is defined in the
registration of the key algorithm. For example, a DSA key registration of the key algorithm. For example, a DSA key
is an INTEGER, an RSA key is represented as RSAPrivateKey is an INTEGER, an RSA key is represented as RSAPrivateKey
as defined in [RFC3447], and an Elliptic Curve Cryptography as defined in [RFC3447], and an Elliptic Curve Cryptography
skipping to change at page 16, line 18 skipping to change at page 16, line 40
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).";
} }
} }
} }
action generate-certificate-signing-request { action generate-certificate-signing-request {
description description
"Generates a certificate signing request structure for "Generates a certificate signing request structure for
the associated private key using the passed subject and the associated private key using the passed subject and
attribute values. Please review both the Security attribute values. The specified assertions need to be
Considerations and Design Considerations sections in appropriate for the certificate's use. For example,
RFC VVVV for more information regarding this action an entity certificate for a TLS server SHOULD have
statement."; values that enable clients to satisfy RFC 6125
processing.";
input { input {
leaf subject { leaf subject {
type binary; type binary;
mandatory true; mandatory true;
description description
"The 'subject' field from the CertificationRequestInfo "The 'subject' field from the CertificationRequestInfo
structure as specified by RFC 2986, Section 4.1 encoded structure as specified by RFC 2986, Section 4.1 encoded
using the ASN.1 distinguished encoding rules (DER), as using the ASN.1 distinguished encoding rules (DER), as
specified in ITU-T X.690."; specified in ITU-T X.690.";
reference reference
skipping to change at page 17, line 33 skipping to change at page 18, line 8
Version 1.7. 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).";
} }
} }
} }
} } // end key
}
action generate-private-key {
description
"Requests the device to generate a private key using the
specified key algorithm. This action is primarily to
support cryptographic processors that MUST generate
the private key themselves. The resulting key is
considered operational state and hence initially only
present in the <operational> datastore, as defined in
[I-D.netmod-revised-datastores].";
input {
leaf name {
type string;
mandatory true;
description
"The name this private-key should have when listed
in /keys/key. As such, the passed value MUST NOT
match any existing 'name' value.";
}
leaf algorithm {
type identityref {
base "key-algorithm";
}
mandatory true;
description
"The algorithm to be used when generating the key.";
}
}
} // end generate-private-key
} // end keys
list trusted-certificates { list trusted-certificates {
key name; key name;
description description
"A list of trusted certificates. These certificates "A list of trusted certificates. These certificates
can be used by a server to authenticate clients, or by can be used by a server to authenticate clients, or by
clients to authenticate servers. The certificates may clients to authenticate servers. The certificates may
be endpoint specific or for certificate authorities, be endpoint specific or for certificate authorities,
to authenticate many clients at once. Each list of to authenticate many clients at once. Each list of
certificates SHOULD be specific to a purpose, as the certificates SHOULD be specific to a purpose, as the
skipping to change at page 22, line 22 skipping to change at page 23, line 28
NACM value 'default-deny-all'. NACM value 'default-deny-all'.
Some of the RPC operations in this YANG module may be considered Some of the RPC 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:
generate-certificate-signing-request: For this RPC operation, it generate-certificate-signing-request: For this RPC operation, it
is RECOMMENDED that implementations assert channel binding is 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 in the the request is the same as the device authenticated when the
secure transport layer was established. secure transport layer was established.
5. IANA Considerations 5. IANA Considerations
5.1. The IETF XML Registry 5.1. The IETF XML Registry
This document registers one URI in the IETF XML registry [RFC3688]. This document registers one URI in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in [RFC3688], the following registration is
requested: requested:
skipping to change at page 23, line 9 skipping to change at page 24, line 14
name: ietf-keystore name: ietf-keystore
namespace: urn:ietf:params:xml:ns:yang:ietf-keystore namespace: urn:ietf:params:xml:ns:yang:ietf-keystore
prefix: kc prefix: kc
reference: RFC VVVV reference: RFC VVVV
6. Acknowledgements 6. 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): Andy Bierman, Martin on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder; Phil Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
Shafer, Sean Turner, and Bert Wijnen. Juergen Schoenwaelder; Phil Shafer, Sean Turner, and Bert Wijnen.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 25, line 34 skipping to change at page 26, line 34
o Replaced the 'certificate-chain' structures with PKCS#7 o Replaced the 'certificate-chain' structures with PKCS#7
structures. (Issue #1) structures. (Issue #1)
o Added 'private-key' as a configurable data node, and removed the o Added 'private-key' as a configurable data node, and removed the
'generate-private-key' and 'load-private-key' actions. (Issue #2) 'generate-private-key' and 'load-private-key' actions. (Issue #2)
o Moved 'user-auth-credentials' to the ietf-ssh-client module. o Moved 'user-auth-credentials' to the ietf-ssh-client module.
(Issues #4 and #5) (Issues #4 and #5)
Appendix B. Open Issues A.4. 01 to 02
Please see: https://github.com/netconf-wg/keystore/issues. o Added back 'generate-private-key' action.
o Removed 'RESTRICTED' enum from the 'private-key' leaf type.
o Fixed up a few description statements.
Author's Address Author's Address
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
 End of changes. 22 change blocks. 
67 lines changed or deleted 124 lines changed or added

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