< draft-kwatsen-netconf-sztp-csr-00.txt   draft-kwatsen-netconf-sztp-csr-01.txt >
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Watsen Networks Internet-Draft Watsen Networks
Updates: 8572 (if approved) R. Housley Updates: 8572 (if approved) R. Housley
Intended status: Standards Track Vigil Security, LLC Intended status: Standards Track Vigil Security, LLC
Expires: 11 December 2020 S. Turner Expires: 12 December 2020 S. Turner
sn3rd sn3rd
9 June 2020 10 June 2020
Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request Provisioning (SZTP) Bootstrapping Request
draft-kwatsen-netconf-sztp-csr-00 draft-kwatsen-netconf-sztp-csr-01
Abstract Abstract
This draft extends the "get-bootstrapping-data" RPC defined in RFC This draft extends the "get-bootstrapping-data" RPC defined in RFC
8572 to include an optional certificate signing request (CSR), 8572 to include an optional certificate signing request (CSR),
enabling a bootstrapping device to additionally obtain an identity enabling a bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
"onboarding information" response provided in the RPC-reply. "onboarding information" response provided in the RPC-reply.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
* "XXXX" --> the assigned numerical RFC value for this draft * "XXXX" --> the assigned numerical RFC value for this draft
* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto- * "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto-
types types
Artwork in this document contains a placeholder value for the Artwork in this document contains a placeholder value for the
publication date of this draft. Please apply the following publication date of this draft. Please apply the following
replacement: replacement:
* "2020-06-09" --> the publication date of this draft * "2020-06-10" --> the publication date of this draft
This document contains references to other drafts in progress, both This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their throughout. Please update the following references to reflect their
final RFC assignments: final RFC assignments:
* I-D.ietf-netconf-crypto-types * I-D.ietf-netconf-crypto-types
* I-D.ietf-netconf-keystore * I-D.ietf-netconf-keystore
* I-D.ietf-netconf-trust-anchors * I-D.ietf-netconf-trust-anchors
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 11 December 2020. This Internet-Draft will expire on 12 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3.1.6. Clearing the Private Key and Associated 3.1.6. Clearing the Private Key and Associated
Certificate . . . . . . . . . . . . . . . . . . . . . 25 Certificate . . . . . . . . . . . . . . . . . . . . . 25
3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25 3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25
3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25 3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25
3.2.2. Supporting SZTP-Clients that don't trust the 3.2.2. Supporting SZTP-Clients that don't trust the
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25
3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26 3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 26 4.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 26
4.2. The YANG Module Names Registry . . . . . . . . . . . . . 26 4.2. The YANG Module Names Registry . . . . . . . . . . . . . 26
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Normative References . . . . . . . . . . . . . . . . . . 27 5.1. Normative References . . . . . . . . . . . . . . . . . . 27
5.2. Informative References . . . . . . . . . . . . . . . . . 28 5.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This draft extends the "get-bootstrapping-data" RPC defined in This draft extends the "get-bootstrapping-data" RPC defined in
[RFC8572] to include an optional certificate signing request (CSR) [RFC8572] to include an optional certificate signing request (CSR)
[RFC2986], enabling a bootstrapping device to additionally obtain an [RFC2986], enabling a bootstrapping device to additionally obtain an
identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of
skipping to change at page 13, line 12 skipping to change at page 13, line 12
to use the "ietf-truststore" module defined in to use the "ietf-truststore" module defined in
[I-D.ietf-netconf-trust-anchors]. [I-D.ietf-netconf-trust-anchors].
2.3. YANG Module 2.3. YANG Module
This module augments an RPC defined in [RFC8572], uses a data type This module augments an RPC defined in [RFC8572], uses a data type
defined in [I-D.ietf-netconf-crypto-types], has an normative defined in [I-D.ietf-netconf-crypto-types], has an normative
references to [RFC2986] and [ITU.X690.2015], and an informative references to [RFC2986] and [ITU.X690.2015], and an informative
reference to [Std-802.1AR-2018]. reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2020-06-09.yang" <CODE BEGINS> file "ietf-sztp-csr@2020-06-10.yang"
module ietf-sztp-csr { module ietf-sztp-csr {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";
prefix sztp-csr; prefix sztp-csr;
import ietf-sztp-bootstrap-server { import ietf-sztp-bootstrap-server {
prefix sztp-svr; prefix sztp-svr;
reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)";
} }
skipping to change at page 14, line 24 skipping to change at page 14, line 24
(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 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision 2020-06-09 { revision 2020-06-10 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC XXXX: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
identity certificate-request-format { identity certificate-request-format {
description description
skipping to change at page 15, line 19 skipping to change at page 15, line 19
PKI Request' structure defined in RFC 5272."; PKI Request' structure defined in RFC 5272.";
reference reference
"RFC 5272: Certificate Management over CMS (CMC)"; "RFC 5272: Certificate Management over CMS (CMC)";
} }
identity cmp { identity cmp {
base "certificate-request-format"; base "certificate-request-format";
description description
"Indicates that the SZTP-client supports generating "Indicates that the SZTP-client supports generating
requests that contain a PKCS#10 Certificate Signing requests that contain a PKCS#10 Certificate Signing
Request (p10cr) encapsulated in a Nested Message Request (p10cr), as defined in RFC 2986, encapsulated
Content (nested), as defined in RFC 4210."; in a Nested Message Content (nested), as defined in
RFC 4210.";
// FIXME: need to describe exactly what the structure
// looks like when the origination-authentication
// strategy uses an asymmetric-key vs a shared secret.
//
// e.g., see Sections D.4 and E.7 in RFC 4210
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7 Specification Version 1.7
RFC 4210: Internet X.509 Public Key Infrastructure RFC 4210: Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)"; Certificate Management Protocol (CMP)";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" {
 End of changes. 10 change blocks. 
18 lines changed or deleted 12 lines changed or added

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