rfc9646.original   rfc9646.txt 
NETCONF Working Group K. Watsen Internet Engineering Task Force (IETF) K. Watsen
Internet-Draft Watsen Networks Request for Comments: 9646 Watsen Networks
Updates: 8572 (if approved) R. Housley Updates: 8572 R. Housley
Intended status: Standards Track Vigil Security, LLC Category: Standards Track Vigil Security
Expires: 3 September 2022 S. Turner ISSN: 2070-1721 S. Turner
sn3rd sn3rd
2 March 2022 October 2024
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-ietf-netconf-sztp-csr-14
Abstract Abstract
This draft extends the input to the "get-bootstrapping-data" RPC This document extends the input to the "get-bootstrapping-data" RPC
defined in RFC 8572 to include an optional certificate signing defined in RFC 8572 to include an optional certificate signing
request (CSR), enabling a bootstrapping device to additionally obtain request (CSR), enabling a bootstrapping device to additionally obtain
an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part an identity certificate (e.g., a Local Device Identifier (LDevID)
of the "onboarding information" response provided in the RPC-reply. from IEEE 802.1AR) as part of the "onboarding information" response
provided in the RPC-reply.
Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
* XXXX --> the assigned numerical RFC value for this draft
* AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types
Artwork in this document contains a placeholder value for the
publication date of this draft. Please apply the following
replacement:
* 2022-03-02 --> the publication date of this draft
This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their
final RFC assignments:
* I-D.ietf-netconf-crypto-types
* I-D.ietf-netconf-keystore
* I-D.ietf-netconf-trust-anchors
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 3 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9646.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2024 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Conventions
2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 2. The "ietf-sztp-csr" Module
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Data Model Overview
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Example Usage
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. YANG Module
3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 3. The "ietf-ztp-types" Module
3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 3.1. Data Model Overview
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. YANG Module
4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4. Security Considerations
4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 4.1. SZTP-Client Considerations
4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 4.1.1. Ensuring the Integrity of Asymmetric Private Keys
4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 28 4.1.2. Reuse of a Manufacturer-Generated Private Key
4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 29 4.1.3. Replay Attack Protection
4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 29 4.1.4. Connecting to an Untrusted Bootstrap Server
4.1.5. Selecting the Best Origin Authentication Mechanism . 30 4.1.5. Selecting the Best Origin Authentication Mechanism
4.1.6. Clearing the Private Key and Associated 4.1.6. Clearing the Private Key and Associated Certificate
Certificate . . . . . . . . . . . . . . . . . . . . . 30 4.2. SZTP-Server Considerations
4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30 4.2.1. Verifying Proof-of-Possession
4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 4.2.2. Verifying Proof-of-Origin
4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 31 4.2.3. Supporting SZTP-Clients That Don't Trust the
4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module
4.3. Security Considerations for the "ietf-sztp-csr" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Security Considerations for the "ietf-ztp-types" YANG 4.4. Security Considerations for the "ietf-ztp-types" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 32 Module
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations
5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 32 5.1. The IETF XML Registry
5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32 5.2. The YANG Module Names Registry
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 32 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 34 6.2. Informative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 Acknowledgements
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This draft extends the input to the "get-bootstrapping-data" RPC This document extends the input to the "get-bootstrapping-data" RPC
defined in [RFC8572] to include an optional certificate signing defined in [RFC8572] to include an optional certificate signing
request (CSR) [RFC2986], enabling a bootstrapping device to request (CSR) [RFC2986], enabling a bootstrapping device to
additionally obtain an identity certificate (e.g., an LDevID additionally obtain an identity certificate (e.g., an LDevID from
[Std-802.1AR-2018]) as part of the "onboarding information" response [Std-802.1AR-2018]) as part of the "onboarding information" response
provided in the RPC-reply. provided in the RPC-reply.
The ability to provision an identity certificate that is purpose- The ability to provision an identity certificate that is purpose-
built for a production environment during the bootstrapping process built for a production environment during the bootstrapping process
removes reliance on the manufacturer CA, and it also enables the removes reliance on the manufacturer Certification Authority (CA),
bootstrapped device to join the production environment with an and it also enables the bootstrapped device to join the production
appropriate identity and other attributes in its identity certificate environment with an appropriate identity and other attributes in its
(e.g., an LDevID). identity certificate (e.g., an LDevID).
Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module
defines three YANG groupings for the various messages defined in this defines three YANG groupings for the various messages defined in this
document. The "ietf-sztp-csr" module augments two groupings into the document. The "ietf-sztp-csr" module augments two groupings into the
"get-bootstrapping-data" RPC and defines a YANG Data Structure "get-bootstrapping-data" RPC and defines a YANG data structure
[RFC8791] around the third grouping. [RFC8791] around the third grouping.
1.2. Terminology 1.2. Terminology
This document uses the following terms from [RFC8572]: This document uses the following terms from [RFC8572]:
* Bootstrap Server * Bootstrap Server
* Bootstrapping Data * Bootstrapping Data
* Conveyed Information * Conveyed Information
* Device * Device
* Manufacturer * Manufacturer
* Onboarding Information * Onboarding Information
* Signed Data * Signed Data
This document defines the following new terms: This document defines the following new terms:
SZTP-client The term "SZTP-client" refers to a "device" that is SZTP-client: The term "SZTP-client" refers to a "device" that is
using a "bootstrap server" as a source of "bootstrapping data". using a "bootstrap server" as a source of "bootstrapping data".
SZTP-server The term "SZTP-server" is an alternative term for SZTP-server: The term "SZTP-server" is an alternative term for
"bootstrap server" that is symmetric with the "SZTP-client" term. "bootstrap server" that is symmetric with the "SZTP-client" term.
1.3. Requirements Language 1.3. Requirements Language
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.4. Conventions 1.4. Conventions
Various examples used in this document use a placeholder value for Various examples in this document use "BASE64VALUE=" as a placeholder
binary data that has been base64 encoded (e.g., "BASE64VALUE="). value for binary data that has been base64 encoded (per Section 9.8
This placeholder value is used as real base64 encoded structures are of [RFC7950]). This placeholder value is used because real
often many lines long and hence distracting to the example being base64-encoded structures are often many lines long and hence
presented. distracting to the example being presented.
Various examples in this document contain long lines that may be
folded, as described in [RFC8792].
2. The "ietf-sztp-csr" Module 2. The "ietf-sztp-csr" Module
The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that
augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572]
and defines a YANG "structure" that is to be conveyed in the "error- and defines a YANG "structure" that is to be conveyed in the "error-
info" node defined in Section 7.1 of [RFC8040]. info" node defined in Section 7.1 of [RFC8040].
2.1. Data Model Overview 2.1. Data Model Overview
skipping to change at page 5, line 47 skipping to change at line 203
| +-- format-identifier identityref | +-- format-identifier identityref
+-- cert-req-info? ct:csr-info +-- cert-req-info? ct:csr-info
The augmentation defines two kinds of parameters that an SZTP-client The augmentation defines two kinds of parameters that an SZTP-client
can send to an SZTP-server. The YANG structure defines one can send to an SZTP-server. The YANG structure defines one
collection of parameters that an SZTP-server can send to an SZTP- collection of parameters that an SZTP-server can send to an SZTP-
client. client.
In the order of their intended use: In the order of their intended use:
* The "csr-support" node is used by the SZTP-client to signal to the 1. The SZTP-client sends a "csr-support" node, encoded in a first
SZTP-server that it supports the ability to generate CSRs. This "get-bootstrapping-data" request to the SZTP-server, to indicate
parameter conveys if the SZTP-client is able to generate a new that it supports the ability to generate CSRs. This input
asymmetric key and, if so, which key algorithms it supports, as parameter conveys if the SZTP-client is able to generate a new
well as conveys what kinds of CSR structures the SZTP-client is asymmetric key and, if so, which key algorithms it supports, as
able to generate. well as what kinds of CSR structures the SZTP-client is able to
generate.
* The "csr-request" structure is used by the SZTP-server to request 2. The SZTP-server responds with an error, containing the "csr-
the SZTP-client to generate a CSR. This structure is used to request" structure, to request the SZTP-client to generate a CSR.
select the key algorithm the SZTP-client should use to generate a This structure is used to select the key algorithm the SZTP-
new asymmetric key, if supported, the kind of CSR structure the client should use to generate a new asymmetric key (if
SZTP-client should generate and, optionally, the content for the supported), the kind of CSR structure the SZTP-client should
CSR itself. generate, and optionally the content for the CSR itself.
* The various "csr" nodes are used by the SZTP-client to communicate 3. The SZTP-client sends one of the "*-csr" nodes, encoded in a
a CSR to the SZTP-server. second "get-bootstrapping-data" request to the SZTP-server. This
node encodes the server-requested CSR.
| No data model is defined enabling an SZTP-server to communicate 4. The SZTP-server responds with onboarding information to
| the signed certificate to the SZTP-client. How to do this is communicate the signed certificate to the SZTP-client. How to do
| discussed in Section 2.2. this is discussed in Section 2.2.
To further illustrate how the augmentation and structure defined by To further illustrate how the augmentation and structure defined by
the "ietf-sztp-csr" module are used, below are two additional tree the "ietf-sztp-csr" module are used, below are two additional tree
diagrams showing these nodes placed where they are used. diagrams showing these nodes placed where they are used.
The following tree diagram [RFC8340] illustrates SZTP's "get- The following tree diagram [RFC8340] illustrates SZTP's "get-
bootstrapping-data" RPC with the augmentation in place. bootstrapping-data" RPC with the augmentation in place.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
skipping to change at page 8, line 25 skipping to change at line 293
+--ro sztp-csr:key-generation! +--ro sztp-csr:key-generation!
| +--ro sztp-csr:selected-algorithm | +--ro sztp-csr:selected-algorithm
| +--ro sztp-csr:algorithm-identifier binary | +--ro sztp-csr:algorithm-identifier binary
+--ro sztp-csr:csr-generation +--ro sztp-csr:csr-generation
| +--ro sztp-csr:selected-format | +--ro sztp-csr:selected-format
| +--ro sztp-csr:format-identifier identityref | +--ro sztp-csr:format-identifier identityref
+--ro sztp-csr:cert-req-info? ct:csr-info +--ro sztp-csr:cert-req-info? ct:csr-info
2.2. Example Usage 2.2. Example Usage
| The examples below are encoded using JSON, but they could | NOTE: The examples below are encoded using JSON, but they could
| equally well be encoded using XML, as is supported by SZTP. | equally well be encoded using XML, as is supported by SZTP.
An SZTP-client implementing this specification would signal to the An SZTP-client implementing this specification would signal to the
bootstrap server its willingness to generate a CSR by including the bootstrap server its willingness to generate a CSR by including the
"csr-support" node in its "get-bootstrapping-data" RPC. In the "csr-support" node in its "get-bootstrapping-data" RPC. In the
example below, the SZTP-client additionally indicates that it is able example below, the SZTP-client additionally indicates that it is able
to generate keys and provides a list of key algorithms it supports, to generate keys and provides a list of key algorithms it supports,
as well as provide a list of certificate formats it supports. as well as provide a list of certificate formats it supports.
REQUEST REQUEST
skipping to change at page 10, line 37 skipping to change at line 382
}, },
"cert-req-info": "BASE64VALUE=" "cert-req-info": "BASE64VALUE="
} }
} }
} }
] ]
} }
} }
Upon being prompted to provide a CSR, the SZTP-client would POST Upon being prompted to provide a CSR, the SZTP-client would POST
another "get-bootstrapping-data" request, but this time including one another "get-bootstrapping-data" request but this time including one
of the "csr" nodes to convey its CSR to the SZTP-server: of the "csr" nodes to convey its CSR to the SZTP-server:
REQUEST REQUEST
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1 ng-data HTTP/1.1
HOST: example.com HOST: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-sztp-bootstrap-server:input" : { "ietf-sztp-bootstrap-server:input" : {
"hw-model": "model-x", "hw-model": "model-x",
"os-name": "vendor-os", "os-name": "vendor-os",
"os-version": "17.3R2.1", "os-version": "17.3R2.1",
"nonce": "extralongbase64encodedvalue=", "nonce": "extralongbase64encodedvalue=",
"ietf-sztp-csr:p10-csr": "BASE64VALUE=" "ietf-sztp-csr:p10-csr": "BASE64VALUE="
} }
} }
At this point, it is expected that the SZTP-server, perhaps in At this point, it is expected that the SZTP-server, perhaps in
conjunction with other systems, such as a backend CA or RA, will conjunction with other systems, such as a backend CA or registration
validate the CSR's origin and proof-of-possession and, assuming the authority (RA), will validate the CSR's origin and proof-of-
CSR is approved, issue a signed certificate for the bootstrapping possession and, assuming the CSR is approved, issue a signed
device. certificate for the bootstrapping device.
The SZTP-server responds with "onboarding-information" (encoded The SZTP-server responds with conveyed information (the "conveyed-
inside the "conveyed-information" node, shown below) containing a information" node shown below) that encodes "onboarding-information"
signed identity certificate for the CSR provided by the SZTP-client: (inside the base64 value) containing a signed identity certificate
for the CSR provided by the SZTP-client:
RESPONSE RESPONSE
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sat, 31 Oct 2021 17:02:40 GMT Date: Sat, 31 Oct 2021 17:02:40 GMT
Server: example-server Server: example-server
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-sztp-bootstrap-server:output" : { "ietf-sztp-bootstrap-server:output" : {
skipping to change at page 12, line 7 skipping to change at line 438
How the signed certificate is conveyed inside the onboarding How the signed certificate is conveyed inside the onboarding
information is outside the scope of this document. Some information is outside the scope of this document. Some
implementations may choose to convey it inside a script (e.g., SZTP's implementations may choose to convey it inside a script (e.g., SZTP's
"pre-configuration-script"), while other implementations may choose "pre-configuration-script"), while other implementations may choose
to convey it inside the SZTP "configuration" node. SZTP onboarding to convey it inside the SZTP "configuration" node. SZTP onboarding
information is described in Section 2.2 of [RFC8572]. information is described in Section 2.2 of [RFC8572].
Below are two examples of conveying the signed certificate inside the Below are two examples of conveying the signed certificate inside the
"configuration" node. Both examples assume that the SZTP-client "configuration" node. Both examples assume that the SZTP-client
understands the "ietf-keystore" module defined in understands the "ietf-keystore" module defined in [RFC9642].
[I-D.ietf-netconf-keystore].
This first example illustrates the case where the signed certificate This first example illustrates the case where the signed certificate
is for the same asymmetric key used by the SZTP-client's is for the same asymmetric key used by the SZTP-client's
manufacturer-generated identity certificate (e.g., an IDevID, from manufacturer-generated identity certificate (e.g., an Initial Device
[Std-802.1AR-2018]). As such, the configuration needs to associate Identifier (IDevID) from [Std-802.1AR-2018]). As such, the
the newly signed certificate with the existing asymmetric key: configuration needs to associate the newly signed certificate with
the existing asymmetric key:
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-keystore:keystore": { "ietf-keystore:keystore": {
"asymmetric-keys": { "asymmetric-keys": {
"asymmetric-key": [ "asymmetric-key": [
{ {
"name": "Manufacturer-Generated Hidden Key", "name": "Manufacturer-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
skipping to change at page 13, line 47 skipping to change at line 524
} }
] ]
} }
} }
] ]
} }
} }
} }
In addition to configuring the signed certificate, it is often In addition to configuring the signed certificate, it is often
necessary to also configure the Issuer's signing certificate so that necessary to also configure the issuer's signing certificate so that
the device (i.e., STZP-client) can authenticate certificates the device (i.e., STZP-client) can authenticate certificates
presented by peer devices signed by the same issuer as its own. presented by peer devices signed by the same issuer as its own.
While outside the scope of this document, one way to do this would be While outside the scope of this document, one way to do this would be
to use the "ietf-truststore" module defined in to use the "ietf-truststore" module defined in [RFC9641].
[I-D.ietf-netconf-trust-anchors].
2.3. YANG Module 2.3. YANG Module
This module augments an RPC defined in [RFC8572]. The module uses a This module augments an RPC defined in [RFC8572]. The module uses
data types and groupings defined in [RFC8572], [RFC8791], and data types and groupings defined in [RFC8572], [RFC8791], and
[I-D.ietf-netconf-crypto-types]. The module also has an informative [RFC9640]. The module also has an informative reference to
reference to [Std-802.1AR-2018]. [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2022-03-02.yang" <CODE BEGINS> file "ietf-sztp-csr@2022-03-02.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 reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)"; "RFC 8572: Secure Zero Touch Provisioning (SZTP)";
} }
import ietf-yang-structure-ext { import ietf-yang-structure-ext {
prefix sx; prefix sx;
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
import ietf-ztp-types { import ietf-ztp-types {
prefix zt; prefix zt;
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero-Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
skipping to change at page 15, line 8 skipping to change at line 581
Sean Turner <mailto:sean@sn3rd.com>"; Sean Turner <mailto:sean@sn3rd.com>";
description description
"This module augments the 'get-bootstrapping-data' RPC, "This module augments the 'get-bootstrapping-data' RPC,
defined in the 'ietf-sztp-bootstrap-server' module from defined in the 'ietf-sztp-bootstrap-server' module from
SZTP (RFC 8572), enabling the SZTP-client to obtain a SZTP (RFC 8572), enabling the SZTP-client to obtain a
signed identity certificate (e.g., an LDevID from IEEE signed identity certificate (e.g., an LDevID from IEEE
802.1AR) as part of the SZTP onboarding information 802.1AR) as part of the SZTP onboarding information
response. response.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
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.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9646
(https://www.rfc-editor.org/info/rfc9646); see the
RFC itself for full legal notices.";
revision 2022-03-02 { revision 2022-03-02 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero-Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" {
description description
"This augmentation adds the 'csr-support' and 'csr' nodes to "This augmentation adds the 'csr-support' and 'csr' nodes to
the SZTP (RFC 8572) 'get-bootstrapping-data' request message, the SZTP (RFC 8572) 'get-bootstrapping-data' request message,
enabling the SZTP-client to obtain an identity certificate enabling the SZTP-client to obtain an identity certificate
(e.g., an LDevID from IEEE 802.1AR) as part of the onboarding (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding
information response provided by the SZTP-server. information response provided by the SZTP-server.
The 'csr-support' node enables the SZTP-client to indicate The 'csr-support' node enables the SZTP-client to indicate
that it supports generating certificate signing requests that it supports generating certificate signing requests
(CSRs), and to provide details around the CSRs it is able (CSRs) and to provide details around the CSRs it is able
to generate. to generate.
The 'csr' node enables the SZTP-client to relay a CSR to The 'csr' node enables the SZTP-client to relay a CSR to
the SZTP-server."; the SZTP-server.";
reference reference
"IEEE 802.1AR: IEEE Standard for Local and metropolitan "IEEE 802.1AR: IEEE Standard for Local and Metropolitan
area networks - Secure Device Identity Area Networks - Secure Device Identity
RFC 8572: Secure Zero Touch Provisioning (SZTP)"; RFC 8572: Secure Zero Touch Provisioning (SZTP)";
choice msg-type { choice msg-type {
description description
"Messages are mutually exclusive."; "Messages are mutually exclusive.";
case csr-support { case csr-support {
description description
"Indicates how the SZTP-client supports generating CSRs. "Indicates how the SZTP-client supports generating CSRs.
If present and a SZTP-server wishes to request the If present and a SZTP-server wishes to request the
SZTP-client generate a CSR, the SZTP-server MUST SZTP-client generate a CSR, the SZTP-server MUST
respond with HTTP code 400 Bad Request with an respond with an HTTP 400 Bad Request error code with an
'ietf-restconf:errors' message having the 'error-tag' 'ietf-restconf:errors' message having the 'error-tag'
value 'missing-attribute' and the 'error-info' node value 'missing-attribute' and the 'error-info' node
containing the 'csr-request' structure described containing the 'csr-request' structure described
in this module."; in this module.";
uses zt:csr-support-grouping; uses zt:csr-support-grouping;
} }
case csr { case csr {
description description
"Provides the CSR generated by the SZTP-client. "Provides the CSR generated by the SZTP-client.
When present, the SZTP-server SHOULD respond with When present, the SZTP-server SHOULD respond with
an SZTP onboarding information message containing an SZTP onboarding information message containing
a signed certificate for the conveyed CSR. The a signed certificate for the conveyed CSR. The
SZTP-server MAY alternatively respond with another SZTP-server MAY alternatively respond with another
HTTP error containing another 'csr-request', in HTTP error containing another 'csr-request'; in
which case the SZTP-client MUST delete any key which case, the SZTP-client MUST delete any key
generated for the previously generated CSR."; generated for the previously generated CSR.";
uses zt:csr-grouping; uses zt:csr-grouping;
} }
} }
} }
sx:structure csr-request { sx:structure csr-request {
description description
"A YANG data structure, per RFC 8791, that specifies "A YANG data structure, per RFC 8791, that specifies
details for the CSR that the ZTP-client is to generate."; details for the CSR that the ZTP-client is to generate.";
skipping to change at page 17, line 9 skipping to change at line 679
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
uses zt:csr-request-grouping; uses zt:csr-request-grouping;
} }
} }
<CODE ENDS> <CODE ENDS>
3. The "ietf-ztp-types" Module 3. The "ietf-ztp-types" Module
This section defines a YANG 1.1 [RFC7950] module that defines three This section defines a YANG 1.1 [RFC7950] module that defines three
YANG groupings, one each for messages sent between a ZTP-client and YANG groupings, one for each message sent between a ZTP-client and
ZTP-server. This module is defined independently of the "ietf-sztp- ZTP-server. This module is defined independently of the "ietf-sztp-
csr" module so that it's groupings may be used by bootstrapping csr" module so that its groupings may be used by bootstrapping
protocols other than SZTP [RFC8572]. protocols other than SZTP [RFC8572].
3.1. Data Model Overview 3.1. Data Model Overview
The following tree diagram [RFC8340] illustrates the three groupings The following tree diagram [RFC8340] illustrates the three groupings
defined in the "ietf-ztp-types" module. defined in the "ietf-ztp-types" module.
module: ietf-ztp-types module: ietf-ztp-types
grouping csr-support-grouping grouping csr-support-grouping
skipping to change at page 17, line 48 skipping to change at line 718
+-- (csr-type) +-- (csr-type)
+--:(p10-csr) +--:(p10-csr)
| +-- p10-csr? ct:csr | +-- p10-csr? ct:csr
+--:(cmc-csr) +--:(cmc-csr)
| +-- cmc-csr? binary | +-- cmc-csr? binary
+--:(cmp-csr) +--:(cmp-csr)
+-- cmp-csr? binary +-- cmp-csr? binary
3.2. YANG Module 3.2. YANG Module
This module uses a data types and groupings [RFC8791] and This module uses data types and groupings defined in [RFC8791] and
[I-D.ietf-netconf-crypto-types]. The module has additional normative [RFC9640]. The module has additional normative references to
references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2021] and an
and an informative reference to [Std-802.1AR-2018]. informative reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-ztp-types@2022-03-02.yang" <CODE BEGINS> file "ietf-ztp-types@2022-03-02.yang"
module ietf-ztp-types { module ietf-ztp-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";
prefix zt; prefix zt;
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; "RFC 9640: YANG Data Types and Groupings for Cryptography";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Russ Housley <mailto:housley@vigilsec.com> Russ Housley <mailto:housley@vigilsec.com>
Sean Turner <mailto:sean@sn3rd.com>"; Sean Turner <mailto:sean@sn3rd.com>";
description description
"This module defines three groupings that enable "This module defines three groupings that enable
bootstrapping devices to 1) indicate if and how they bootstrapping devices to 1) indicate if and how they
support generating CSRs, 2) obtain a request to support generating CSRs, 2) obtain a request to
generate a CSR, and 3) communicate the requested CSR. generate a CSR, and 3) communicate the requested CSR.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
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.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9646
(https://www.rfc-editor.org/info/rfc9646); see the
RFC itself for full legal notices.";
revision 2022-03-02 { revision 2022-03-02 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: 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
"A base identity for the request formats supported "A base identity for the request formats supported
by the ZTP-client. by the ZTP-client.
Additional derived identities MAY be defined by Additional derived identities MAY be defined by
future efforts."; future efforts.";
skipping to change at page 19, line 41 skipping to change at line 807
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7"; Specification Version 1.7";
} }
identity cmp-csr { identity cmp-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
requests using a profiled version of the PKIMessage requests using a profiled version of the PKIMessage
that MUST contain a PKIHeader followed by a PKIBody that MUST contain a PKIHeader followed by a PKIBody
containing only the ir, cr, kur, or p10cr structure containing only the ir, cr, kur, or p10cr structures
defined in RFC 4210."; defined in RFC 4210.";
reference reference
"RFC 4210: Internet X.509 Public Key Infrastructure "RFC 4210: Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)"; Certificate Management Protocol (CMP)";
} }
identity cmc-csr { identity cmc-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
skipping to change at page 20, line 17 skipping to change at line 831
"RFC 5272: Certificate Management over CMS (CMC)"; "RFC 5272: Certificate Management over CMS (CMC)";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
grouping csr-support-grouping { grouping csr-support-grouping {
description description
"A grouping enabling use by other efforts."; "A grouping enabling use by other efforts.";
container csr-support { container csr-support {
description description
"Enables a ZTP-client to indicate that it supports "Enables a ZTP-client to indicate that it supports
generating certificate signing requests (CSRs) and generating certificate signing requests (CSRs) and
provides details about the CSRs it is able to provides details about the CSRs it is able to
generate."; generate.";
container key-generation { container key-generation {
presence presence "Indicates that the ZTP-client is capable of
"Indicates that the ZTP-client is capable of generating a new asymmetric key pair.
generating a new asymmetric key pair.
If this node is not present, the ZTP-server MAY If this node is not present, the ZTP-server MAY
request a CSR using the asymmetric key associated request a CSR using the asymmetric key associated
with the device's existing identity certificate with the device's existing identity certificate
(e.g., an IDevID from IEEE 802.1AR)."; (e.g., an IDevID from IEEE 802.1AR).";
description description
"Specifies details for the ZTP-client's ability to "Specifies details for the ZTP-client's ability to
generate a new asymmetric key pair."; generate a new asymmetric key pair.";
container supported-algorithms { container supported-algorithms {
description description
"A list of public key algorithms supported by the "A list of public key algorithms supported by the
ZTP-client for generating a new asymmetric key."; ZTP-client for generating a new asymmetric key.";
leaf-list algorithm-identifier { leaf-list algorithm-identifier {
type binary; type binary;
min-elements 1; min-elements 1;
description description
"An AlgorithmIdentifier, as defined in RFC 2986, "An AlgorithmIdentifier, as defined in RFC 2986,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
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)";
} }
} }
} }
container csr-generation { container csr-generation {
description description
"Specifies details for the ZTP-client's ability to "Specifies details for the ZTP-client's ability to
generate a certificate signing requests."; generate certificate signing requests.";
container supported-formats { container supported-formats {
description description
"A list of certificate request formats supported "A list of certificate request formats supported
by the ZTP-client for generating a new key."; by the ZTP-client for generating a new key.";
leaf-list format-identifier { leaf-list format-identifier {
type identityref { type identityref {
base zt:certificate-request-format; base zt:certificate-request-format;
} }
min-elements 1; min-elements 1;
description description
skipping to change at page 21, line 34 skipping to change at line 894
} }
} }
} }
} }
} }
grouping csr-request-grouping { grouping csr-request-grouping {
description description
"A grouping enabling use by other efforts."; "A grouping enabling use by other efforts.";
container key-generation { container key-generation {
presence presence "Provided by a ZTP-server to indicate that it wishes
"Provided by a ZTP-server to indicate that it wishes the ZTP-client to generate a new asymmetric key.
the ZTP-client to generate a new asymmetric key.
This statement is present so the mandatory descendant This statement is present so the mandatory
nodes do not imply that this node must be configured."; descendant nodes do not imply that this node must
be configured.";
description description
"The key generation parameters selected by the ZTP-server. "The key generation parameters selected by the ZTP-server.
This leaf MUST only appear if the ZTP-client's This leaf MUST only appear if the ZTP-client's
'csr-support' included the 'key-generation' node."; 'csr-support' included the 'key-generation' node.";
container selected-algorithm { container selected-algorithm {
description description
"The key algorithm selected by the ZTP-server. The "The key algorithm selected by the ZTP-server. The
algorithm MUST be one of the algorithms specified by algorithm MUST be one of the algorithms specified by
the 'supported-algorithms' node in the ZTP-client's the 'supported-algorithms' node in the ZTP-client's
message containing the 'csr-support' structure."; message containing the 'csr-support' structure.";
leaf algorithm-identifier { leaf algorithm-identifier {
type binary; type binary;
mandatory true; mandatory true;
description description
"An AlgorithmIdentifier, as defined in RFC 2986, "An AlgorithmIdentifier, as defined in RFC 2986,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
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)";
} }
} }
} }
container csr-generation { container csr-generation {
description description
"Specifies details for the CSR that the ZTP-client "Specifies details for the CSR that the ZTP-client
is to generate."; is to generate.";
container selected-format { container selected-format {
description description
"The CSR format selected by the ZTP-server. The "The CSR format selected by the ZTP-server. The
format MUST be one of the formats specified by format MUST be one of the formats specified by
the 'supported-formats' node in the ZTP-client's the 'supported-formats' node in the ZTP-client's
request message."; request message.";
leaf format-identifier { leaf format-identifier {
type identityref { type identityref {
base zt:certificate-request-format; base zt:certificate-request-format;
} }
mandatory true; mandatory true;
description description
"A certificate request format to be used by the "A certificate request format to be used by the
ZTP-client."; ZTP-client.";
} }
} }
} }
leaf cert-req-info { leaf cert-req-info {
type ct:csr-info; type ct:csr-info;
description description
"A CertificationRequestInfo structure, as defined in "A CertificationRequestInfo structure, as defined in
RFC 2986, and modeled via a 'typedef' statement by RFC 2986, and modeled via a 'typedef' statement by
RFC AAAA. RFC 9640.
Enables the ZTP-server to provide a fully-populated Enables the ZTP-server to provide a fully populated
CertificationRequestInfo structure that the ZTP-client CertificationRequestInfo structure that the ZTP-client
only needs to sign in order to generate the complete only needs to sign in order to generate the complete
'CertificationRequest' structure to send to ZTP-server 'CertificationRequest' structure to send to the ZTP-server
in its next 'get-bootstrapping-data' request message. in its next 'get-bootstrapping-data' request message.
When provided, the ZTP-client MUST use this structure When provided, the ZTP-client MUST use this structure
to generate its CSR; failure to do so will result in a to generate its CSR; failure to do so will result in a
400 Bad Request response containing another 'csr-request' 400 Bad Request response containing another 'csr-request'
structure. structure.
When not provided, the ZTP-client SHOULD generate a CSR When not provided, the ZTP-client SHOULD generate a CSR
using the same structure defined in its existing identity using the same structure defined in its existing identity
certificate (e.g., an IDevID from IEEE 802.1AR). certificate (e.g., an IDevID from IEEE 802.1AR).
If the 'AlgorithmIdentifier' field contained inside the If the 'AlgorithmIdentifier' field contained inside the
certificate 'SubjectPublicKeyInfo' field does not match certificate 'SubjectPublicKeyInfo' field does not match
the algorithm identified by the 'selected-algorithm' node, the algorithm identified by the 'selected-algorithm' node,
then the client MUST reject the certificate and raise an then the client MUST reject the certificate and raise an
error."; error.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
RFC AAAA: Version 1.7
RFC 9640:
YANG Data Types and Groupings for Cryptography"; YANG Data Types and Groupings for Cryptography";
} }
} }
grouping csr-grouping { grouping csr-grouping {
description description
"Enables a ZTP-client to convey a certificate signing "Enables a ZTP-client to convey a certificate signing
request, using the encoding format selected by a request, using the encoding format selected by a
ZTP-server's 'csr-request' response to the ZTP-client's ZTP-server's 'csr-request' response to the ZTP-client's
previously sent request containing the 'csr-support' previously sent request containing the 'csr-support'
node."; node.";
choice csr-type { choice csr-type {
mandatory true; mandatory true;
description description
"A choice amongst certificate signing request formats. "A choice amongst certificate signing request formats.
Additional formats MAY be augmented into this 'choice' Additional formats MAY be augmented into this 'choice'
statement by future efforts."; statement by future efforts.";
case p10-csr { case p10-csr {
leaf p10-csr { leaf p10-csr {
type ct:csr; type ct:p10-csr;
description description
"A CertificationRequest structure, per RFC 2986. "A CertificationRequest structure, per RFC 2986.
Encoding details are defined in the 'ct:csr' Encoding details are defined in the 'ct:csr'
typedef defined in RFC AAAA. typedef defined in RFC 9640.
A raw P10 does not support origin authentication in A raw P10 does not support origin authentication in
the CSR structure. External origin authentication the CSR structure. External origin authentication
may be provided via the ZTP-client's authentication may be provided via the ZTP-client's authentication
to the ZTP-server at the transport layer (e.g., TLS)."; to the ZTP-server at the transport layer (e.g., TLS).";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Specification Version 1.7
RFC AAAA: YANG Data Types and Groupings for RFC 9640: YANG Data Types and Groupings for
Cryptography"; Cryptography";
} }
} }
case cmc-csr { case cmc-csr {
leaf cmc-csr { leaf cmc-csr {
type binary; type binary;
description description
"A profiled version of the 'Full PKI Request' "A profiled version of the 'Full PKI Request'
message defined in RFC 5272, encoded using ASN.1 message defined in RFC 5272, encoded using ASN.1
distinguished encoding rules (DER), as specified Distinguished Encoding Rules (DER), as specified
in ITU-T X.690. in ITU-T X.690.
For asymmetric key-based origin authentication of a For asymmetric-key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated identity certificate's private key for the associated identity certificate's
public key, the PKIData contains one reqSequence public key, the PKIData contains one reqSequence
element and no cmsSequence or otherMsgSequence element and no cmsSequence or otherMsgSequence
elements. The reqSequence is the TaggedRequest elements. The reqSequence is the TaggedRequest,
and it is the tcr CHOICE branch. The tcr is the and it is the tcr CHOICE branch. The tcr is the
TaggedCertificationRequest and it is the bodyPartId TaggedCertificationRequest, and it is the bodyPartID
and the certificateRequest elements. The and the certificateRequest elements. The
certificateRequest is signed with the initial device certificateRequest is signed with the initial device
identity certificate's private key. The initial device identity certificate's private key. The initial device
identity certificate and optionally its certificate identity certificate, and optionally its certificate
chain is included in the SignedData certificates that chain is included in the SignedData certificates that
encapsulates the PKIData. encapsulate the PKIData.
For asymmetric key-based origin authentication based on For asymmetric-key-based origin authentication based on
the initial device identity certificate's private key the initial device identity certificate's private key
that signs the encapsulated CSR signed by the local that signs the encapsulated CSR signed by the local
device identity certificate's private key, the device identity certificate's private key, the
PKIData contains one cmsSequence element and no PKIData contains one cmsSequence element and no
reqSequence or otherMsgSequence reqSequence or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo,
and it includes a bodyPartID element and a contentInfo. and it includes a bodyPartID element and a contentInfo.
The contentInfo is a SignedData encapsulating a PKIData The contentInfo is a SignedData encapsulating a PKIData
with one reqSequence element and no cmsSequence or with one reqSequence element and no cmsSequence or
otherMsgSequence elements. The reqSequence is the otherMsgSequence elements. The reqSequence is the
TaggedRequest and it is the tcr CHOICE. The tcr is the TaggedRequest, and it is the tcr CHOICE. The tcr is the
TaggedCertificationRequest and it is the bodyPartId and TaggedCertificationRequest, and it is the bodyPartID and
the certificateRequest elements. PKIData contains one the certificateRequest elements. PKIData contains one
cmsSequence element and no controlSequence, reqSequence, cmsSequence element and no controlSequence, reqSequence,
or otherMsgSequence elements. The certificateRequest or otherMsgSequence elements. The certificateRequest
is signed with the local device identity certificate's is signed with the local device identity certificate's
private key. The initial device identity certificate private key. The initial device identity certificate
and optionally its certificate chain is included in the and optionally its certificate chain is included in
SignedData certificates that encapsulates the PKIData. the SignedData certificates that encapsulate the
PKIData.
For shared secret-based origin authentication of a For shared-secret-based origin authentication of a
CSR signed by the local device identity certificate's CSR signed by the local device identity certificate's
private key, the PKIData contains one cmsSequence private key, the PKIData contains one cmsSequence
element and no reqSequence or otherMsgSequence element and no reqSequence or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo,
and it includes a bodyPartID element and a contentInfo. and it includes a bodyPartID element and a contentInfo.
The contentInfo is an AuthenticatedData encapsulating The contentInfo is an AuthenticatedData encapsulating
a PKIData with one reqSequence element and no a PKIData with one reqSequence element and no
cmsSequences or otherMsgSequence elements. The cmsSequences or otherMsgSequence elements. The
reqSequence is the TaggedRequest and it is the tcr reqSequence is the TaggedRequest, and it is the tcr
CHOICE. The tcr is the TaggedCertificationRequest CHOICE. The tcr is the TaggedCertificationRequest,
and it is the bodyPartId and the certificateRequest and it is the bodyPartID and the certificateRequest
elements. The certificateRequest is signed with the elements. The certificateRequest is signed with the
local device identity certificate's private key. The local device identity certificate's private key. The
initial device identity certificate and optionally its initial device identity certificate and optionally its
certificate chain is included in the SignedData certificate chain is included in the SignedData
certificates that encapsulates the PKIData."; certificates that encapsulate the PKIData.";
reference reference
"RFC 5272: Certificate Management over CMS (CMC) "RFC 5272: Certificate Management over CMS (CMC)
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)";
} }
} }
case cmp-csr { case cmp-csr {
leaf cmp-csr { leaf cmp-csr {
type binary; type binary;
description description
"A PKIMessage structure, as defined in RFC 4210, "A PKIMessage structure, as defined in RFC 4210,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690. (DER), as specified in ITU-T X.690.
For asymmetric key-based origin authentication of a For asymmetric-key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated initial device identity private key for the associated initial device identity
certificate's public key, PKIMessages contains one certificate's public key, PKIMessages contain one
PKIMessage with the header and body elements, no PKIMessage with the header and body elements, do not
protection element, and SHOULD contain the extraCerts contain a protection element, and SHOULD contain the
element. The header element contains the pvno, sender, extraCerts element. The header element contains the
and recipient elements. The pvno contains cmp2000, and pvno, sender, and recipient elements. The pvno contains
the sender contains the subject of the initial device cmp2000, and the sender contains the subject of the
identity certificate. The body element contains an ir, initial device identity certificate. The body element
cr, kur, or p10cr CHOICE of type CertificationRequest. contains an ir, cr, kur, or p10cr CHOICE of type
It is signed with the initial device identity CertificationRequest. It is signed with the initial
certificate's private key. The extraCerts element device identity certificate's private key. The
contains the initial device identity certificate, extraCerts element contains the initial device identity
optionally followed by its certificate chain excluding certificate, optionally followed by its certificate
the trust anchor. chain excluding the trust anchor.
For asymmetric key-based origin authentication based For asymmetric-key-based origin authentication based
on the initial device identity certificate's private on the initial device identity certificate's private
key that signs the encapsulated CSR signed by the local key that signs the encapsulated CSR signed by the local
device identity certificate's private key, PKIMessages device identity certificate's private key, PKIMessages
contains one PKIMessage with the header, body, and contain one PKIMessage with the header, body, and
protection elements, and SHOULD contain the extraCerts protection elements and SHOULD contain the extraCerts
element. The header element contains the pvno, sender, element. The header element contains the pvno, sender,
recipient, protectionAlg, and optionally senderKID recipient, protectionAlg, and optionally senderKID
elements. The pvno contains cmp2000, the sender elements. The pvno contains cmp2000, the sender
contains the subject of the initial device identity contains the subject of the initial device identity
certificate, the protectionAlg contains the certificate, the protectionAlg contains the
AlgorithmIdentifier of the used signature algorithm, AlgorithmIdentifier of the used signature algorithm,
and the senderKID contains the subject key identifier and the senderKID contains the subject key identifier
of the initial device identity certificate. The body of the initial device identity certificate. The body
element contains an ir, cr, kur, or p10cr CHOICE of element contains an ir, cr, kur, or p10cr CHOICE of
type CertificationRequest. It is signed with the local type CertificationRequest. It is signed with the local
device identity certificate's private key. The device identity certificate's private key. The
protection element contains the digital signature protection element contains the digital signature
generated with the initial device identity generated with the initial device identity
certificate's private key. The extraCerts element certificate's private key. The extraCerts element
contains the initial device identity certificate, contains the initial device identity certificate,
optionally followed by its certificate chain excluding optionally followed by its certificate chain excluding
the trust anchor. the trust anchor.
For shared secret-based origin authentication of a For shared-secret-based origin authentication of a
CSR signed by the local device identity certificate's CSR signed by the local device identity certificate's
private key, PKIMessages contains one PKIMessage with private key, PKIMessages contain one PKIMessage with
the header, body, and protection element, and no the header, body, and protection element and no
extraCerts element. The header element contains the extraCerts element. The header element contains the
pvno, sender, recipient, protectionAlg, and senderKID pvno, sender, recipient, protectionAlg, and senderKID
elements. The pvno contains cmp2000, the protectionAlg elements. The pvno contains cmp2000, the protectionAlg
contains the AlgorithmIdentifier of the used MAC contains the AlgorithmIdentifier of the used Message
algorithm, and the senderKID contains a reference the Authentication Code (MAC) algorithm, and the senderKID
recipient can use to identify the shared secret. The contains a reference the recipient can use to identify
body element contains an ir, cr, kur, or p10cr CHOICE the shared secret. The body element contains an ir, cr,
of type CertificationRequest. It is signed with the kur, or p10cr CHOICE of type CertificationRequest. It
local device identity certificate's private key. The is signed with the local device identity certificate's
protection element contains the MAC value generated private key. The protection element contains the MAC
with the shared secret."; value generated with the shared secret.";
reference reference
"RFC 4210: "RFC 4210:
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP) Certificate Management Protocol (CMP)
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)";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. Security Considerations 4. Security Considerations
This document builds on top of the solution presented in [RFC8572] This document builds on top of the solution presented in [RFC8572],
and therefore all the Security Considerations discussed in RFC 8572 and therefore all the security considerations discussed in [RFC8572]
apply here as well. apply here as well.
For the various CSR formats, when using PKCS#10, the security For the various CSR formats, when using PKCS#10, the security
considerations in [RFC2986] apply, when using CMP, the security considerations in [RFC2986] apply; when using CMP, the security
considerations in [RFC4210] apply and, when using CMC, the security considerations in [RFC4210] apply; and when using CMC, the security
considerations in [RFC5272] apply. considerations in [RFC5272] apply.
For the various authentication mechanisms, when using TLS-level For the various authentication mechanisms, when using TLS-level
authentication, the security considerations in [RFC8446] apply and, authentication, the security considerations in [RFC8446] apply, and
when using HTTP-level authentication, the security considerations in when using HTTP-level authentication, the security considerations in
[RFC7235] apply. [RFC9110] apply.
4.1. SZTP-Client Considerations 4.1. SZTP-Client Considerations
4.1.1. Ensuring the Integrity of Asymmetric Private Keys 4.1.1. Ensuring the Integrity of Asymmetric Private Keys
The private key the SZTP-client uses for the dynamically-generated The private key the SZTP-client uses for the dynamically generated
identity certificate MUST be protected from inadvertent disclosure in identity certificate MUST be protected from inadvertent disclosure in
order to prevent identity fraud. order to prevent identity fraud.
The security of this private key is essential in order to ensure the The security of this private key is essential in order to ensure the
associated identity certificate can be used to authenticate the associated identity certificate can be used to authenticate the
device it is issued to. device it is issued to.
It is RECOMMENDED that devices are manufactured with an HSM (hardware It is RECOMMENDED that devices are manufactured with a hardware
security module), such as a TPM (trusted platform module), to security module (HSM), such as a trusted platform module (TPM), to
generate and contain the private key within the security perimeter of generate and contain the private key within the security perimeter of
the HSM. In such cases, the private key, and its associated the HSM. In such cases, the private key and its associated
certificates, MAY have long validity periods. certificates MAY have long validity periods.
In cases where the SZTP-client does not possess an HSM, or is unable In cases where the SZTP-client does not possess an HSM or is unable
to use an HSM to protect the private key, it is RECOMMENDED to to use an HSM to protect the private key, it is RECOMMENDED to
periodically reset the private key (and associated identity periodically reset the private key (and associated identity
certificates) in order to minimize the lifetime of unprotected certificates) in order to minimize the lifetime of unprotected
private keys. For instance, an NMS controller/orchestrator private keys. For instance, a Network Management System (NMS)
application could periodically prompt the SZTP-client to generate a controller/orchestrator application could periodically prompt the
new private key and provide a certificate signing request (CSR) or, SZTP-client to generate a new private key and provide a certificate
alternatively, push both the key and an identity certificate to the signing request (CSR) or, alternatively, push both the key and an
SZTP-client using, e.g., a PKCS #12 message [RFC7292]. In another identity certificate to the SZTP-client using, e.g., a PKCS#12
example, the SZTP-client could be configured to periodically reset message [RFC7292]. In another example, the SZTP-client could be
the configuration to its factory default, thus causing removal of the configured to periodically reset the configuration to its factory
private key and associated identity certificates and re-execution of default, thus causing removal of the private key and associated
the SZTP protocol. identity certificates and re-execution of the SZTP protocol.
4.1.2. Reuse of a Manufacturer-generated Private Key 4.1.2. Reuse of a Manufacturer-Generated Private Key
It is RECOMMENDED that a new private key is generated for each CSR It is RECOMMENDED that a new private key is generated for each CSR
described in this document. described in this document.
Implementations must randomly generate nonces and private keys. The Implementations must randomly generate nonces and private keys. The
use of inadequate pseudo-random number generators (PRNGs) to generate use of inadequate pseudorandom number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute force searching the whole key space.
As an example of predictable random numbers see CVE-2008-0166 As an example of predictable random numbers, see CVE-2008-0166
[CVE-2008-0166], and some consequences of low-entropy random numbers [CVE-2008-0166], and some consequences of low-entropy random numbers
are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation are discussed in "Mining Your Ps and Qs" [MiningPsQs]. The
of quality random numbers is difficult. [ISO.20543-2019], generation of quality random numbers is difficult. [ISO.20543-2019],
[NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and
others offer valuable guidance in this area. others offer valuable guidance in this area.
This private key SHOULD be protected as well as the built-in private This private key SHOULD be protected as well as the built-in private
key associated with the SZTP-client's initial device identity key associated with the SZTP-client's initial device identity
certificate (e.g., the IDevID, from [Std-802.1AR-2018]). certificate (e.g., the IDevID from [Std-802.1AR-2018]).
In cases where it is not possible to generate a new private key that In cases where it is not possible to generate a new private key that
is protected as well as the built-in private key, it is RECOMMENDED is protected as well as the built-in private key, it is RECOMMENDED
to reuse the built-in private key rather than generate a new private to reuse the built-in private key rather than generate a new private
key that is not as well protected. key that is not as well protected.
4.1.3. Replay Attack Protection 4.1.3. Replay Attack Protection
This RFC enables an SZTP-client to announce an ability to generate a This RFC enables an SZTP-client to announce an ability to generate a
new key to use for its CSR. new key to use for its CSR.
skipping to change at page 29, line 34 skipping to change at line 1277
generated identity certificate (e.g., IDevID) is used for the generated identity certificate (e.g., IDevID) is used for the
request, there may not be confirmation to the SZTP-client that the request, there may not be confirmation to the SZTP-client that the
response has not been replayed; however, the worst case result is a response has not been replayed; however, the worst case result is a
lost certificate that is associated to the private key known only to lost certificate that is associated to the private key known only to
the SZTP-client. Protection of the private-key information is vital the SZTP-client. Protection of the private-key information is vital
to public-key cryptography. Disclosure of the private-key material to public-key cryptography. Disclosure of the private-key material
to another entity can lead to masquerades. to another entity can lead to masquerades.
4.1.4. Connecting to an Untrusted Bootstrap Server 4.1.4. Connecting to an Untrusted Bootstrap Server
[RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers by
by blindly authenticating the SZTP-server's TLS end-entity blindly authenticating the SZTP-server's TLS end-entity certificate.
certificate.
As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- As is discussed in Section 9.5 of [RFC8572], in such cases, the SZTP-
client MUST assert that the bootstrapping data returned is signed, if client MUST assert that the bootstrapping data returned is signed if
the SZTP-client is to trust it. the SZTP-client is to trust it.
However, the HTTP error message used in this document cannot be However, the HTTP error message used in this document cannot be
signed data, as described in RFC 8572. signed data, as described in [RFC8572].
Therefore, the solution presented in this document cannot be used Therefore, the solution presented in this document cannot be used
when the SZTP-client connects to an untrusted SZTP-server. when the SZTP-client connects to an untrusted SZTP-server.
Consistent with the recommendation presented in Section 9.6 of Consistent with the recommendation presented in Section 9.6 of
[RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input
parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass parameter to an untrusted SZTP-server. SZTP-clients SHOULD instead
instead the "signed-data-preferred" input parameter, as discussed in pass the "signed-data-preferred" input parameter, as discussed in
Appendix B of [RFC8572]. Appendix B of [RFC8572].
4.1.5. Selecting the Best Origin Authentication Mechanism 4.1.5. Selecting the Best Origin Authentication Mechanism
The origin of the CSR must be verified before a certificate is The origin of the CSR must be verified before a certificate is
issued. issued.
When generating a new key, it is important that the SZTP-client be When generating a new key, it is important that the SZTP-client be
able to provide additional proof that it was the entity that able to provide additional proof that it was the entity that
generated the key. generated the key.
The CMP and CMC certificate request formats defined in this document The CMP and CMC certificate request formats defined in this document
support origin authentication. A raw PKCS#10 CSR does not support support origin authentication. A raw PKCS#10 CSR does not support
origin authentication. origin authentication.
The CMP and CMC request formats support origin authentication using The CMP and CMC request formats support origin authentication using
both PKI and shared secret. both PKI and a shared secret.
Typically, only one possible origin authentication mechanism can Typically, only one possible origin authentication mechanism can
possibly be used but, in the case that the SZTP-client authenticates possibly be used, but in the case that the SZTP-client authenticates
itself using both TLS-level (e.g., IDevID) and HTTP-level credentials itself using both TLS-level (e.g., IDevID) and HTTP-level credentials
(e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the
SZTP-client may need to choose between the two options. SZTP-client may need to choose between the two options.
In the case that the SZTP-client must choose between an asymmetric In the case that the SZTP-client must choose between an asymmetric
key option versus a shared secret for origin authentication, it is key option versus a shared secret for origin authentication, it is
RECOMMENDED that the SZTP-client choose using the asymmetric key. RECOMMENDED that the SZTP-client choose using the asymmetric key.
4.1.6. Clearing the Private Key and Associated Certificate 4.1.6. Clearing the Private Key and Associated Certificate
Unlike a manufacturer-generated identity certificate (e.g., IDevID), Unlike a manufacturer-generated identity certificate (e.g., IDevID),
the deployment-generated identity certificate (e.g., LDevID) and the the deployment-generated identity certificate (e.g., LDevID) and the
associated private key (assuming a new private key was generated for associated private key (assuming a new private key was generated for
the purpose), are considered user data and SHOULD be cleared whenever the purpose) are considered user data and SHOULD be cleared whenever
the SZTP-client is reset to its factory default state, such as by the the SZTP-client is reset to its factory default state, such as by the
"factory-reset" RPC defined in [RFC8808]. "factory-reset" RPC defined in [RFC8808].
4.2. SZTP-Server Considerations 4.2. SZTP-Server Considerations
4.2.1. Verifying Proof of Possession 4.2.1. Verifying Proof-of-Possession
Regardless if using a new asymmetric key or the bootstrapping Regardless, if using a new asymmetric key or the bootstrapping
device's manufacturer-generated key (e.g., the IDevID key), the device's manufacturer-generated key (e.g., the IDevID key), the
public key is placed in the CSR and the CSR is signed by that private public key is placed in the CSR and the CSR is signed by that private
key. Proof-of-possession of the private key is verified by ensuring key. Proof-of-possession of the private key is verified by ensuring
the signature over the CSR using the public key placed in the CSR. the signature over the CSR using the public key placed in the CSR.
4.2.2. Verifying Proof of Origin 4.2.2. Verifying Proof-of-Origin
When the bootstrapping device's manufacturer-generated private key When the bootstrapping device's manufacturer-generated private key
(e.g., the IDevID key) is reused for the CSR, proof-of-origin is (e.g., the IDevID key) is reused for the CSR, proof-of-origin is
verified by validating the IDevID-issuer cert and ensuring that the verified by validating the IDevID-issuer cert and ensuring that the
CSR uses the same key pair. CSR uses the same key pair.
When the bootstrapping device's manufacturer-generated private key When the bootstrapping device's manufacturer-generated private key
(e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof- (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof-
of-origin is verified by validating the IDevID certification path and of-origin is verified by validating the IDevID certification path and
ensuring that the CSR uses the same key pair. ensuring that the CSR uses the same key pair.
When a fresh asymmetric key is used with the CMP or CMC formats, the When a fresh asymmetric key is used with the CMP or CMC formats, the
authentication is part of the protocols, which could employ either authentication is part of the protocols, which could employ either
the manufacturer-generated private key or a shared secret. In the manufacturer-generated private key or a shared secret. In
addition, CMP and CMC support processing by a RA before the request addition, CMP and CMC support processing by an RA before the request
is passed to the CA, which allows for more robust handling of errors. is passed to the CA, which allows for more robust handling of errors.
4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 4.2.3. Supporting SZTP-Clients That Don't Trust the SZTP-Server
[RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers by
by blindly authenticating the SZTP-server's TLS end-entity blindly authenticating the SZTP-server's TLS end-entity certificate.
certificate.
As is recommended in Section 4.1.4 in this document, in such cases, As is recommended in Section 4.1.4 of this document, in such cases,
SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. SZTP-clients SHOULD pass the "signed-data-preferred" input parameter.
The reciprocal of this statement is that SZTP-servers, wanting to The reciprocal of this statement is that SZTP-servers, wanting to
support SZTP-clients that don't trust them, SHOULD support the support SZTP-clients that don't trust them, SHOULD support the
"signed-data-preferred" input parameter, as discussed in Appendix B "signed-data-preferred" input parameter, as discussed in Appendix B
of [RFC8572]. of [RFC8572].
4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module
The recommended format for documenting the Security Considerations The recommended format for documenting the security considerations
for YANG modules is described in Section 3.7 of [RFC8407]. However, for YANG modules is described in Section 3.7 of [RFC8407]. However,
this module only augments two input parameters into the "get- this module only augments two input parameters into the "get-
bootstrapping-data" RPC in [RFC8572], and therefore only needs to bootstrapping-data" RPC in [RFC8572] and therefore only needs to
point to the relevant Security Considerations sections in that RFC. point to the relevant Security Considerations sections in that RFC.
* Security considerations for the "get-bootstrapping-data" RPC are * Security considerations for the "get-bootstrapping-data" RPC are
described in Section 9.16 of [RFC8572]. described in Section 9.16 of [RFC8572].
* Security considerations for the "input" parameters passed inside * Security considerations for the "input" parameters passed inside
the "get-bootstrapping-data" RPC are described in Section 9.6 of the "get-bootstrapping-data" RPC are described in Section 9.6 of
[RFC8572]. [RFC8572].
4.4. Security Considerations for the "ietf-ztp-types" YANG Module 4.4. Security Considerations for the "ietf-ztp-types" YANG Module
The recommended format for documenting the Security Considerations The recommended format for documenting the security considerations
for YANG modules is described in Section 3.7 of [RFC8407]. However, for YANG modules is described in Section 3.7 of [RFC8407]. However,
this module does not define any protocol-accessible nodes (it only this module does not define any protocol-accessible nodes (it only
defines "identity" and "grouping" statements) and therefore there are defines "identity" and "grouping" statements), and therefore there
no Security considerations to report. are no security considerations to report.
5. IANA Considerations 5. IANA Considerations
5.1. The "IETF XML" Registry 5.1. The IETF XML Registry
This document registers two URIs in the "ns" subregistry of the IETF IANA has registered two URIs in the "ns" registry of the "IETF XML
XML Registry [RFC3688] maintained at Registry" [RFC3688] maintained at <https://www.iana.org/assignments/
https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. xml-registry/>.
Following the format in [RFC3688], the following registrations are
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
5.2. The "YANG Module Names" Registry 5.2. The YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names IANA has registered two YANG modules in the "YANG Module Names"
registry [RFC6020] maintained at https://www.iana.org/assignments/ registry [RFC6020] maintained at <https://www.iana.org/assignments/
yang-parameters/yang-parameters.xhtml. Following the format defined yang-parameters/>.
in [RFC6020], the below registrations are requested:
name: ietf-sztp-csr Name: ietf-sztp-csr
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
reference: RFC XXXX Reference: RFC 9646
name: ietf-ztp-types Name: ietf-ztp-types
namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types Namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types
prefix: ztp-types Prefix: ztp-types
reference: RFC XXXX Reference: RFC 9646
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-netconf-crypto-types] [ITU.X690.2021]
Watsen, K., "YANG Data Types and Groupings for ITU, "Information technology - ASN.1 encoding rules:
Cryptography", Work in Progress, Internet-Draft, draft- Specification of Basic Encoding Rules (BER), Canonical
ietf-netconf-crypto-types-21, 14 September 2021, Encoding Rules (CER) and Distinguished Encoding Rules
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf- (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,
crypto-types-21>. February 2021, <https://www.itu.int/rec/T-REC-X.690/>.
[ITU.X690.2015]
International Telecommunication Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, ISO/IEC 8825-1, August 2015,
<https://www.itu.int/rec/T-REC-X.690/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 33, line 49 skipping to change at line 1467
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
skipping to change at page 34, line 30 skipping to change at line 1492
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9640] Watsen, K., "YANG Data Types and Groupings for
Cryptography", RFC 9640, DOI 10.17487/RFC9640, October
2024, <https://www.rfc-editor.org/info/rfc9640>.
6.2. Informative References 6.2. Informative References
[AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), [AIS31] Killmann, W. and W. Schindler, "A proposal for:
Killmann, W., and W. Schindler, "A proposal for: Functionality classes for random number generators -
Functionality classes for random number generators, Version 2.0", September 2011,
version 2.0", 18 September 2011,
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ <https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
Zertifizierung/Interpretationen/AIS_31_Functionality_class Zertifizierung/Interpretationen/AIS_31_Functionality_class
es_for_random_number_generators_e.pdf>. es_for_random_number_generators_e.pdf>.
[CVE-2008-0166] [CVE-2008-0166]
National Institute of Science and Technology (NIST), National Institute of Science and Technology (NIST),
"National Vulnerability Database - CVE-2008-0166", 13 May "National Vulnerability Database - CVE-2008-0166 Detail",
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. May 2008,
<https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.
[I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", Work in
Progress, Internet-Draft, draft-ietf-netconf-keystore-23,
14 December 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-keystore-23>.
[I-D.ietf-netconf-trust-anchors]
Watsen, K., "A YANG Data Model for a Truststore", Work in
Progress, Internet-Draft, draft-ietf-netconf-trust-
anchors-16, 14 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
trust-anchors-16>.
[ISO.20543-2019] [ISO.20543-2019]
International Organization for Standardization (ISO), International Organization for Standardization (ISO),
"Information technology -- Security techniques -- Test and "Information technology -- Security techniques -- Test and
analysis methods for random bit generators within ISO/IEC analysis methods for random bit generators within ISO/IEC
19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 19790 and ISO/IEC 15408", ISO/IEC 20543:2019, October
October 2019. 2019.
[MiningPsQs] [MiningPsQs]
Security'12: Proceedings of the 21st USENIX conference on Heninger, N., Durumeric, Z., Wustrow, E., and J.
Security symposium, Heninger, N., Durumeric, Z., Wustrow, Halderman, "Mining Your Ps and Qs: Detection of Widespread
E., and J. A. Halderman, "Mining Your Ps and Qs: Detection Weak Keys in Network Devices", Security'12: Proceedings of
of Widespread Weak Keys in Network Devices", August 2012, the 21st USENIX Conference on Security Symposium, August
<https://www.usenix.org/conference/usenixsecurity12/ 2012, <https://www.usenix.org/conference/usenixsecurity12/
technical-sessions/presentation/heninger>. technical-sessions/presentation/heninger>.
[NIST.SP.800-90Ar1] [NIST.SP.800-90Ar1]
Barker, Elaine B. and John M. Kelsey, "Recommendation for Barker, E. and J. Kelsey, "Recommendation for Random
Random Number Generation Using Deterministic Random Bit Number Generation Using Deterministic Random Bit
Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST
800-90Ar1, June 2015, SP 800-90Ar1, June 2015,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf>. NIST.SP.800-90Ar1.pdf>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange and M. Scott, "PKCS #12: Personal Information Exchange
skipping to change at page 36, line 5 skipping to change at line 1558
[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>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for [RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808, Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808,
August 2020, <https://www.rfc-editor.org/info/rfc8808>. August 2020, <https://www.rfc-editor.org/info/rfc8808>.
[RFC9641] Watsen, K., "A YANG Data Model for a Truststore",
RFC 9641, DOI 10.17487/RFC9641, October 2024,
<https://www.rfc-editor.org/info/rfc9641>.
[RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,
DOI 10.17487/RFC9642, October 2024,
<https://www.rfc-editor.org/info/rfc9642>.
[Std-802.1AR-2018] [Std-802.1AR-2018]
Group, W. -. H. L. L. P. W., "IEEE Standard for Local and IEEE, "IEEE Standard for Local and Metropolitan Area
metropolitan area networks - Secure Device Identity", 14 Networks - Secure Device Identity", August 2018,
June 2018, <https://standards.ieee.org/ieee/802.1AR/6995/>.
<https://standards.ieee.org/standard/802_1AR-2018.html>.
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 first name): Benjamin Kaduk, on list and in the halls (ordered by first name): Benjamin Kaduk, Dan
David von Oheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy Romascanu, David von Oheimb, Éric Vyncke, Guy Fedorkow, Hendrik
Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz, Brockhaus, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich
Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman Salz, Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and
Sarkar. Zaheduzzaman Sarkar.
Contributors Contributors
Special thanks go to David von Oheimb and Hendrik Brockhaus for Special thanks go to David von Oheimb and Hendrik Brockhaus for
helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
 End of changes. 154 change blocks. 
433 lines changed or deleted 392 lines changed or added

This html diff was produced by rfcdiff 1.48.