<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"> <?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc linkmailto="no" ?> <?rfc editing="no" ?> <?rfc comments="yes" ?> <?rfc inline="yes"?> <?rfc rfcedstyle="yes"?> <?rfc-ext allow-markup-in-artwork="yes" ?> <?rfc-ext include-index="no" ?> <!--<?rfc strict="no"?> -->[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true"ipr="trust200902"docName="draft-ietf-netconf-sztp-csr-14" number="9646" ipr="trust200902" updates="8572" obsoletes=""submissionType="IETF"xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.45.3 --> <front> <title abbrev="Conveying a CSR in an SZTP Request">Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request</title> <!--[rfced] Regarding the title and use throughout the document, we suggest adding a hyphen to "zero-touch". Even though it wasn't used in RFC 8572, this is correct as the term is an adjective. Please let us know if this update is acceptable. Original: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request Suggested: Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request --> <seriesInfoname="Internet-Draft" value="draft-ietf-netconf-sztp-csr-14"/>name="RFC" value="9646"/> <author initials="K." surname="Watsen" fullname="Kent Watsen"> <organization>Watsen Networks</organization> <address> <email>kent+ietf@watsen.net</email> </address> </author> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization>Vigil Security, LLC</organization> <address> <email>housley@vigilsec.com</email> </address> </author> <author initials="S." surname="Turner" fullname="Sean Turner"> <organization>sn3rd</organization> <address> <email>sean@sn3rd.com</email> </address> </author><date/> <area>Operations</area> <workgroup>NETCONF Working Group</workgroup><date year="2024" month="August"/> <area>ops</area> <workgroup>netconf</workgroup> <keyword>zerotouch</keyword> <keyword>bootstrap</keyword> <keyword>sztp</keyword> <keyword>ztp</keyword> <keyword>csr</keyword> <keyword>pkcs#10</keyword> <keyword>p10</keyword> <keyword>p10cr</keyword> <keyword>cmc</keyword> <keyword>cmp</keyword> <abstract> <t>Thisdraftdocument extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g.,an LDevIDa Local Device Identifier (LDevID) from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply.</t> </abstract><note> <name>Editorial Note (To be removed by RFC Editor)</name> <t>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.</t> <t>Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: </t> <ul spacing="normal"> <li> <tt>XXXX</tt> --> the assigned numerical RFC value for this draft</li> <li> <tt>AAAA</tt> --> the assigned RFC value for I-D.ietf-netconf-crypto-types</li> </ul> <t>Artwork in this document contains a placeholder value for the publication date of this draft. Please apply the following replacement: </t> <ul spacing="normal"> <li> <tt>2022-03-02</tt> --> the publication date of this draft</li> </ul> <t>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: </t> <ul spacing="normal"> <li>I-D.ietf-netconf-crypto-types</li> <li>I-D.ietf-netconf-keystore</li> <li>I-D.ietf-netconf-trust-anchors</li> </ul> <!-- <t>The following one Appendix section is to be removed prior to publication: <list style="symbols"> <t>Appendix A. Change Log</t> </list> </t> --> </note></front> <middle> <section numbered="true" toc="default"> <name>Introduction</name> <section numbered="true" toc="default"> <name>Overview</name> <t>Thisdraftdocument extends the input to the "get-bootstrapping-data" RPC defined in <xref target="RFC8572" format="default"/> to include an optional certificate signing request (CSR) <xref target="RFC2986" format="default"/>, enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID from <xref target="Std-802.1AR-2018" format="default"/>) as part of the "onboarding information" response provided in the RPC-reply.</t> <t>The ability to provision an identity certificate that is purpose-built for a production environment during the bootstrapping process removes reliance on the manufacturer CA, and it also enables the bootstrapped device to join the production environment with an appropriate identity and other attributes in its identity certificate (e.g., an LDevID).</t> <t>Two YANG <xref target="RFC7950" format="default"/> modules are defined. The "ietf-ztp-types" module defines three YANG groupings for the various messages defined in this document. The "ietf-sztp-csr" module augments two groupings into the "get-bootstrapping-data" RPC and defines a YANGData Structuredata structure <xref target="RFC8791" format="default"/> around the third grouping.</t> </section> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t>This document uses the following terms from <xref target="RFC8572" format="default"/>:</t> <ul spacing="compact"> <li>Bootstrap Server</li> <li>Bootstrapping Data</li> <!--[rfced] Per the list in Section 1.2, we note that "Conveyed Information" only occurs as ""conveyed-information" node" in the running text of this document. Due to the context of its use, should it be listed in the Terminology section? --> <li>Conveyed Information</li> <li>Device</li> <li>Manufacturer</li> <li>Onboarding Information</li> <li>Signed Data</li> </ul> <t>This document defines the following new terms:</t> <!--<dl hanging="false"> FIXME: xml2rfc fails --> <dl><dt>SZTP-client</dt><dt>SZTP-client:</dt> <dd>The term "SZTP-client" refers to a "device" that is using a "bootstrap server" as a source of "bootstrapping data".</dd><dt>SZTP-server</dt><dt>SZTP-server:</dt> <dd>The term "SZTP-server" is an alternative term for "bootstrap server" that is symmetric with the "SZTP-client" term.</dd> <!-- <list style="hanging" hangIndent="4"> <t hangText="SZTP-client:">The term "SZTP-client" refers to a "device" that is using a "bootstrap server" as a source of "bootstrapping data".</t> <t hangText="SZTP-server:">The term "SZTP-server" refers to a "bootstrap server".</t> </list> --> </dl> </section> <section anchor="requirements-language" numbered="true" toc="default"> <name>Requirements Language</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section numbered="true" toc="default"> <name>Conventions</name> <t>Various examples used in this document use a placeholder value for binary data that has been base64 encoded (e.g., "BASE64VALUE="). This placeholder value is usedassince realbase64 encodedbase64-encoded structures are often many lineslonglong, andhencehence, distracting to the example being presented.</t> </section> </section> <!-- end Introduction --> <section numbered="true" toc="default"> <name>The "ietf-sztp-csr" Module</name> <t>The "ietf-sztp-csr" module is a YANG 1.1 <xref target="RFC7950" format="default"/> module that augments the "ietf-sztp-bootstrap-server" module defined in <xref target="RFC8572" format="default"/> and defines a YANG "structure" that is to be conveyed in the "error-info" node defined in <relref section="7.1" target="RFC8040"/>.</t> <section numbered="true" toc="default"> <name>Data Model Overview</name> <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates the "ietf-sztp-csr" module.</t><artwork name="ietf-sztp-csr-tree.txt" type="" align="left" alt=""><![CDATA[<sourcecode type="yangtree" name="ietf-sztp-csr-tree.txt"><![CDATA[ module: ietf-sztp-csr augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: +---w (msg-type)? +--:(csr-support) | +---w csr-support | +---w key-generation! | | +---w supported-algorithms | | +---w algorithm-identifier* binary | +---w csr-generation | +---w supported-formats | +---w format-identifier* identityref +--:(csr) +---w (csr-type) +--:(p10-csr) | +---w p10-csr? ct:csr +--:(cmc-csr) | +---w cmc-csr? binary +--:(cmp-csr) +---w cmp-csr? binary structure csr-request: +-- key-generation! | +-- selected-algorithm | +-- algorithm-identifier binary +-- csr-generation | +-- selected-format | +-- format-identifier identityref +-- cert-req-info? ct:csr-info]]></artwork>]]></sourcecode> <t>The augmentation defines two kinds of parameters that an SZTP-client can send to an SZTP-server. The YANG structure defines one collection of parameters that an SZTP-server can send to an SZTP-client.</t> <!--[rfced] As the preceding text indicates a specific sequence, should the list in Section 2.1 be converted to a numbered list? Original: In the order of their intended use: --> <t>In the order of their intended use:</t> <ul> <li>The "csr-support" node is used by the SZTP-client to signal to the SZTP-server that it supports the ability to generate CSRs. This parameter conveys if the SZTP-client is able to generate a new asymmetric key and, if so, which key algorithms it supports, as well asconveyswhat kinds of CSR structures the SZTP-client is able to generate.</li> <li>The "csr-request" structure is used by the SZTP-server to request the SZTP-client to generate a CSR. This structure is used to select the key algorithm the SZTP-client should use to generate a new asymmetrickey, if supported,key (if supported), the kind of CSR structure the SZTP-client shouldgenerate and, optionally,generate, and optionally the content for the CSR itself.</li> <li>The various "csr" nodes are used by the SZTP-client to communicate a CSR to the SZTP-server.</li> </ul> <aside> <t>No data model isdefineddefined, enabling an SZTP-server to communicate the signed certificate to the SZTP-client. How to do this is discussed in <xref target="example-usage" format="default"/>.</t> </aside> <t>To further illustrate how the augmentation and structure defined by the "ietf-sztp-csr" module are used, below are two additional tree diagrams showing these nodes placed where they are used.</t> <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates SZTP's "get-bootstrapping-data" RPC with the augmentation in place.</t><artwork name="ietf-sztp-csr-api-n-csr-tree.txt" type="" align="left" alt=""><![CDATA[<sourcecode type="yangtree" name="ietf-sztp-csr-api-n-csr-tree.txt"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ module: ietf-sztp-bootstrap-server rpcs: +---x get-bootstrapping-data +---w input | +---w signed-data-preferred? empty | +---w hw-model? string | +---w os-name? string | +---w os-version? string | +---w nonce? binary | +---w (sztp-csr:msg-type)? | +--:(sztp-csr:csr-support) | | +---w sztp-csr:csr-support | | +---w sztp-csr:key-generation! | | | +---w sztp-csr:supported-algorithms | | | +---w sztp-csr:algorithm-identifier* bina\ ry | | +---w sztp-csr:csr-generation | | +---w sztp-csr:supported-formats | | +---w sztp-csr:format-identifier* identit\ yref | +--:(sztp-csr:csr) | +---w (sztp-csr:csr-type) | +--:(sztp-csr:p10-csr) | | +---w sztp-csr:p10-csr? ct:csr | +--:(sztp-csr:cmc-csr) | | +---w sztp-csr:cmc-csr? binary | +--:(sztp-csr:cmp-csr) | +---w sztp-csr:cmp-csr? binary +--ro output +--ro reporting-level? enumeration {onboarding-server}? +--ro conveyed-information cms +--ro owner-certificate? cms +--ro ownership-voucher? cms]]></artwork>]]></sourcecode> <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates RESTCONF's "errors" RPC-reply message with the "csr-request" structure in place.</t><artwork name="ietf-sztp-csr-errors-n-struct-tree.txt" type="" align="left" alt=""><![CDATA[<sourcecode type="yangtree" name="ietf-sztp-csr-errors-n-struct-tree.txt"><![CDATA[ module: ietf-restconf +--ro errors +--ro error* [] +--ro error-type enumeration +--ro error-tag string +--ro error-app-tag? string +--ro error-path? instance-identifier +--ro error-message? string +--ro error-info +--ro sztp-csr:csr-request +--ro sztp-csr:key-generation! | +--ro sztp-csr:selected-algorithm | +--ro sztp-csr:algorithm-identifier binary +--ro sztp-csr:csr-generation | +--ro sztp-csr:selected-format | +--ro sztp-csr:format-identifier identityref +--ro sztp-csr:cert-req-info? ct:csr-info]]></artwork>]]></sourcecode> </section> <section anchor="example-usage" numbered="true" toc="default"> <name>Example Usage</name> <aside> <t>The examples below are encoded using JSON, but they could equally well be encoded using XML, as is supported by SZTP.</t> </aside> <t>An SZTP-client implementing this specification would signal to the bootstrap server its willingness to generate a CSR by including the "csr-support" node in its "get-bootstrapping-data" RPC. In the example below, the SZTP-client additionally indicates that it is able to generate keys and provides a list of key algorithms it supports, as well as provide a list of certificate formats it supports.</t> <t keepWithNext="true">REQUEST</t><artwork name="ex-api-gbd-without-csr-rpc.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-api-gbd-without-csr-rpc.json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ ng-data HTTP/1.1 HOST: example.com Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:input" : { "hw-model": "model-x", "os-name": "vendor-os", "os-version": "17.3R2.1", "nonce": "extralongbase64encodedvalue=", "ietf-sztp-csr:csr-support": { "key-generation": { "supported-algorithms": { "algorithm-identifier": [ "BASE64VALUE1", "BASE64VALUE2", "BASE64VALUE3" ] } }, "csr-generation": { "supported-formats": { "format-identifier": [ "ietf-ztp-types:p10-csr", "ietf-ztp-types:cmc-csr", "ietf-ztp-types:cmp-csr" ] } } } } }]]></artwork>]]></sourcecode> <t>Assuming the SZTP-server wishes to prompt the SZTP-client to provide a CSR, then it would respond with an HTTP 400 Bad Request error code. In the example below, the SZTP-server specifies that it wishes the SZTP-client to generate a key using a specific algorithm and generate a PKCS#10-based CSR containing specific content.</t> <t keepWithNext="true">RESPONSE</t><artwork name="ex-api-gbd-without-csr-rpc-reply.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-api-gbd-without-csr-rpc-reply.json"><![CDATA[ HTTP/1.1 400 Bad Request Date: Sat, 31 Oct 2021 17:02:40 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:errors" : { "error" : [ { "error-type": "application", "error-tag": "missing-attribute", "error-message": "Missing input parameter", "error-info": { "ietf-sztp-csr:csr-request": { "key-generation": { "selected-algorithm": { "algorithm-identifier": "BASE64VALUE=" } }, "csr-generation": { "selected-format": { "format-identifier": "ietf-ztp-types:p10-csr" } }, "cert-req-info": "BASE64VALUE=" } } } ] } }]]></artwork>]]></sourcecode> <t>Upon being prompted to provide a CSR, the SZTP-client would POST another "get-bootstrapping-data"request,request but this time including one of the "csr" nodes to convey its CSR to the SZTP-server:</t> <t keepWithNext="true">REQUEST</t><artwork name="ex-api-gbd-with-csr-rpc.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-api-gbd-with-csr-rpc.json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ ng-data HTTP/1.1 HOST: example.com Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:input" : { "hw-model": "model-x", "os-name": "vendor-os", "os-version": "17.3R2.1", "nonce": "extralongbase64encodedvalue=", "ietf-sztp-csr:p10-csr": "BASE64VALUE=" } }]]></artwork>]]></sourcecode> <t>At this point, it is expected that the SZTP-server, perhaps in conjunction with other systems, such as a backend CA orRA,registration authority (RA), will validate the CSR's origin and proof-of-possession and, assuming the CSR is approved, issue a signed certificate for the bootstrapping device.</t> <t>The SZTP-server responds with "onboarding-information" (encoded inside the "conveyed-information" node, shown below) containing a signed identity certificate for the CSR provided by the SZTP-client:</t> <t keepWithNext="true">RESPONSE</t><artwork name="ex-api-gbd-with-csr-rpc-reply.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-api-gbd-with-csr-rpc-reply.json"><![CDATA[ HTTP/1.1 200 OK Date: Sat, 31 Oct 2021 17:02:40 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:output" : { "reporting-level": "verbose", "conveyed-information": "BASE64VALUE=" } }]]></artwork>]]></sourcecode> <t>How the signed certificate is conveyed inside the onboarding information is outside the scope of this document. Some implementations may choose to convey it inside a script (e.g., SZTP's "pre-configuration-script"), while other implementations may choose to convey it inside the SZTP "configuration" node. SZTP onboarding information is described in <relref section="2.2" target="RFC8572"/>.</t> <t>Below are two examples of conveying the signed certificate inside the "configuration" node. Both examples assume that the SZTP-client understands the "ietf-keystore" module defined in <xreftarget="I-D.ietf-netconf-keystore"target="RFC9642" format="default"/>.</t> <t>This first example illustrates the case where the signed certificate is for the same asymmetric key used by the SZTP-client's manufacturer-generated identity certificate (e.g., anIDevID,Initial Device Identifier (IDevID) from <xref target="Std-802.1AR-2018" format="default"/>). As such, the configuration needs to associate the newly signed certificate with the existing asymmetric key:</t><artwork name="ex-keystore-ldevid-same-key.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-keystore-ldevid-same-key.json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-keystore:keystore": { "asymmetric-keys": { "asymmetric-key": [ { "name": "Manufacturer-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Manufacturer-Generated IDevID Cert", "cert-data": "BASE64VALUE=" }, { "name": "Newly-Generated LDevID Cert", "cert-data": "BASE64VALUE=" } ] } } ] } } }]]></artwork>]]></sourcecode> <t>This second example illustrates the case where the signed certificate is for a newly generated asymmetric key. As such, the configuration needs to associate the newly signed certificate with the newly generated asymmetric key:</t><artwork name="ex-keystore-ldevid-new-key.json" type="" align="left" alt=""><![CDATA[<sourcecode type="json" name="ex-keystore-ldevid-new-key.json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-keystore:keystore": { "asymmetric-keys": { "asymmetric-key": [ { "name": "Manufacturer-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Manufacturer-Generated IDevID Cert", "cert-data": "BASE64VALUE=" } ] } }, { "name": "Newly-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Newly-Generated LDevID Cert", "cert-data": "BASE64VALUE=" } ] } } ] } } }]]></artwork>]]></sourcecode> <t>In addition to configuring the signed certificate, it is often necessary to also configure theIssuer'sissuer's signing certificate so that the device (i.e., STZP-client) can authenticate certificates 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 to use the "ietf-truststore" module defined in <xreftarget="I-D.ietf-netconf-trust-anchors"target="RFC9641" format="default"/>.</t> </section> <!-- Example Usage --> <section numbered="true" toc="default"> <name>YANG Module</name> <t>This module augments an RPC defined in <xref target="RFC8572" format="default"/>. The module usesadata types and groupings defined in <xref target="RFC8572" format="default"/>, <xref target="RFC8791" format="default"/>, and <xreftarget="I-D.ietf-netconf-crypto-types"target="RFC9640" format="default"/>. The module also has an informative reference to <xref target="Std-802.1AR-2018" format="default"/>.</t><t keepWithNext="true"><CODE BEGINS> file "ietf-sztp-csr@2022-03-02.yang"</t> <artwork<sourcecode type="yang" name="ietf-sztp-csr@2022-03-02.yang"type="" align="left" alt=""><![CDATA[markers="true"><![CDATA[ module ietf-sztp-csr { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; prefix sztp-csr; import ietf-sztp-bootstrap-server { prefix sztp-svr; reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } import ietf-ztp-types { prefix zt; reference "RFCXXXX:9646: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: https://datatracker.ietf.org/wg/netconf WG List: NETCONF WG list <mailto:netconf@ietf.org> Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Russ Housley <mailto:housley@vigilsec.com> Sean Turner <mailto:sean@sn3rd.com>"; description "This module augments the 'get-bootstrapping-data' RPC, defined in the 'ietf-sztp-bootstrap-server' module from SZTP (RFC 8572), enabling the SZTP-client to obtain a signed identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the SZTP onboarding information response. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c)20222024 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 RFCXXXX (https://www.rfc-editor.org/info/rfcXXXX);9646 (https://www.rfc-editor.org/info/rfc9646); see the RFC itself for full legalnotices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.";notices."; revision 2022-03-02 { description "Initialversion";version."; reference "RFCXXXX:9646: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } // Protocol-accessible nodes augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { description "This augmentation adds the 'csr-support' and 'csr' nodes to the SZTP (RFC 8572) 'get-bootstrapping-data' request message, enabling the SZTP-client to obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding information response provided by the SZTP-server. The 'csr-support' node enables the SZTP-client to indicate that it supports generating certificate signing requests(CSRs),(CSRs) and to provide details around the CSRs it is able to generate. The 'csr' node enables the SZTP-client to relay a CSR to the SZTP-server."; reference "IEEE 802.1AR: IEEE Standard for Local andmetropolitan area networksMetropolitan Area Networks - Secure Device Identity RFC 8572: Secure Zero Touch Provisioning (SZTP)"; choice msg-type { description "Messages are mutually exclusive."; case csr-support { description "Indicates how the SZTP-client supports generating CSRs. If present and a SZTP-server wishes to request the SZTP-client generate a CSR, the SZTP-server MUST respond with an HTTPcode400 Bad Request error code with an 'ietf-restconf:errors' message having the 'error-tag' value 'missing-attribute' and the 'error-info' node containing the 'csr-request' structure described in this module."; uses zt:csr-support-grouping; } case csr { description "Provides the CSR generated by the SZTP-client. When present, the SZTP-server SHOULD respond with an SZTP onboarding information message containing a signed certificate for the conveyed CSR. The SZTP-server MAY alternatively respond with another HTTP error containing another'csr-request','csr-request'; in whichcasecase, the SZTP-client MUST delete any key generated for the previously generated CSR."; uses zt:csr-grouping; } } } sx:structure csr-request { description "A YANG data structure, per RFC 8791, that specifies details for the CSR that the ZTP-client is to generate."; reference "RFC 8791: YANG Data Structure Extensions"; uses zt:csr-request-grouping; } }]]></artwork> <t keepWithPrevious="true"><CODE ENDS></t>]]></sourcecode> </section> <!-- YANG Module --> </section> <section numbered="true" toc="default"> <name>The "ietf-ztp-types" Module</name> <t>This section defines a YANG 1.1 <xref target="RFC7950" format="default"/> module that defines three YANG groupings, oneeachformessageseach message sent between a ZTP-client and ZTP-server. This module is defined independently of the "ietf-sztp-csr" module so thatit'sits groupings may be used by bootstrapping protocols other than SZTP <xref target="RFC8572" format="default"/>.</t> <section numbered="true" toc="default"> <name>Data Model Overview</name> <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates the three groupings defined in the "ietf-ztp-types" module.</t><artwork name="ietf-ztp-types-tree.txt" type="" align="left" alt=""><![CDATA[<sourcecode type="yangtree" name="ietf-ztp-types-tree.txt"><![CDATA[ module: ietf-ztp-types grouping csr-support-grouping +-- csr-support +-- key-generation! | +-- supported-algorithms | +-- algorithm-identifier* binary +-- csr-generation +-- supported-formats +-- format-identifier* identityref grouping csr-request-grouping +-- key-generation! | +-- selected-algorithm | +-- algorithm-identifier binary +-- csr-generation | +-- selected-format | +-- format-identifier identityref +-- cert-req-info? ct:csr-info grouping csr-grouping +-- (csr-type) +--:(p10-csr) | +-- p10-csr? ct:csr +--:(cmc-csr) | +-- cmc-csr? binary +--:(cmp-csr) +-- cmp-csr? binary]]></artwork>]]></sourcecode> </section> <section numbered="true" toc="default"> <name>YANG Module</name> <t>This module usesadata types and groupings defined in <xref target="RFC8791" format="default"/> and <xreftarget="I-D.ietf-netconf-crypto-types"target="RFC9640" format="default"/>. The module has additional normative references to <xref target="RFC2986" format="default"/>, <xref target="RFC4210" format="default"/>, <xref target="RFC5272" format="default"/>, and <xreftarget="ITU.X690.2015" format="default"/>,target="ITU.X690.2021" format="default"/> and an informative reference to <xref target="Std-802.1AR-2018" format="default"/>.</t><t keepWithNext="true"><CODE BEGINS> file "ietf-ztp-types@2022-03-02.yang"</t> <artwork<!--[rfced] The following error was given by pyang with the ietf option for ietf-ztp-types@2022-03-02.yang. Please let us know if any updates are needed. 281: error: type "csr" not found in module "ietf-crypto-types" where line 281 contains: type ct:csr; --> <!--[rfced] FYI, minor updates were made to the YANG module ietf-ztp-types to match the formatted output of pyang. --> <sourcecode name="ietf-ztp-types@2022-03-02.yang"type="" align="left" alt=""><![CDATA[type="yang" markers="true"><![CDATA[ module ietf-ztp-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; prefix zt; import ietf-crypto-types { prefix ct; reference "RFCAAAA:9640: YANG Data Types and Groupings for Cryptography"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: https://datatracker.ietf.org/wg/netconf WG List: NETCONF WG list <mailto:netconf@ietf.org> Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Russ Housley <mailto:housley@vigilsec.com> Sean Turner <mailto:sean@sn3rd.com>"; description "This module defines three groupings that enable bootstrapping devices to 1) indicate if and how they support generating CSRs, 2) obtain a request to generate a CSR, and 3) communicate the requested CSR. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c)20222024 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 RFCXXXX (https://www.rfc-editor.org/info/rfcXXXX);9646 (https://www.rfc-editor.org/info/rfc9646); see the RFC itself for full legalnotices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.";notices."; revision 2022-03-02 { description "Initialversion";version."; reference "RFCXXXX:9646: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } identity certificate-request-format { description "A base identity for the request formats supported by the ZTP-client. Additional derived identities MAY be defined by future efforts."; } identity p10-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using the 'CertificationRequest' structure defined in RFC 2986."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7"; } identity cmp-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using a profiled version of the PKIMessage that MUST contain a PKIHeader followed by a PKIBody containing only the ir, cr, kur, or p10crstructurestructures defined in RFC 4210."; reference "RFC 4210: Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)"; } identity cmc-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using a profiled version of the 'Full PKI Request' structure defined in RFC 5272."; reference "RFC 5272: Certificate Management over CMS (CMC)"; } // Protocol-accessible nodes grouping csr-support-grouping { description "A grouping enabling use by other efforts."; container csr-support { description "Enables a ZTP-client to indicate that it supports generating certificate signing requests (CSRs) and provides details about the CSRs it is able to generate."; container key-generation { presence "Indicates that the ZTP-client is capable of generating a new asymmetric key pair. If this node is not present, the ZTP-server MAY request a CSR using the asymmetric key associated with the device's existing identity certificate (e.g., an IDevID from IEEE 802.1AR)."; description "Specifies details for the ZTP-client's ability to generate a new asymmetric key pair."; container supported-algorithms { description "A list of public key algorithms supported by the ZTP-client for generating a new asymmetric key."; leaf-list algorithm-identifier { type binary; min-elements 1; description "An AlgorithmIdentifier, as defined in RFC 2986, encoded using ASN.1distinguished encoding rulesDistinguished Encoding Rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).";(DER)"; } } } container csr-generation { description "Specifies details for the ZTP-client's ability to generateacertificate signing requests."; container supported-formats { description "A list of certificate request formats supported by the ZTP-client for generating a new key."; leaf-list format-identifier { type identityref { base zt:certificate-request-format; } min-elements 1; description "A certificate request format supported by the ZTP-client."; } } } } } grouping csr-request-grouping { description "A grouping enabling use by other efforts."; container key-generation { presence "Provided by a ZTP-server to indicate that it wishes the ZTP-client to generate a new asymmetric key. This statement is present so the mandatory descendant nodes do not imply that this node must be configured."; description "The key generation parameters selected by the ZTP-server. This leaf MUST only appear if the ZTP-client's 'csr-support' included the 'key-generation' node."; container selected-algorithm { description "The key algorithm selected by the ZTP-server. The algorithm MUST be one of the algorithms specified by the 'supported-algorithms' node in the ZTP-client's message containing the 'csr-support' structure."; leaf algorithm-identifier { type binary; mandatory true; description "An AlgorithmIdentifier, as defined in RFC 2986, encoded using ASN.1distinguished encoding rulesDistinguished Encoding Rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).";(DER)"; } } } container csr-generation { description "Specifies details for the CSR that the ZTP-client is to generate."; container selected-format { description "The CSR format selected by the ZTP-server. The format MUST be one of the formats specified by the 'supported-formats' node in the ZTP-client's request message."; leaf format-identifier { type identityref { base zt:certificate-request-format; } mandatory true; description "A certificate request format to be used by the ZTP-client."; } } } leaf cert-req-info { type ct:csr-info; description "A CertificationRequestInfo structure, as defined in RFC 2986, and modeled via a 'typedef' statement by RFCAAAA.9640. Enables the ZTP-server to provide afully-populatedfully populated CertificationRequestInfo structure that the ZTP-client only needs to sign in order to generate the complete 'CertificationRequest' structure to send to the ZTP-server in its next 'get-bootstrapping-data' request message. When provided, the ZTP-client MUST use this structure to generate its CSR; failure to do so will result in a 400 Bad Request response containing another 'csr-request' structure. When not provided, the ZTP-client SHOULD generate a CSR using the same structure defined in its existing identity certificate (e.g., an IDevID from IEEE 802.1AR). If the 'AlgorithmIdentifier' field contained inside the certificate 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 RFCAAAA:9640: YANG Data Types and Groupings for Cryptography"; } } grouping csr-grouping { description "Enables a ZTP-client to convey a certificate signing request, using the encoding format selected by a ZTP-server's 'csr-request' response to the ZTP-client's previously sent request containing the 'csr-support' node."; choice csr-type { mandatory true; description "A choice amongst certificate signing request formats. Additional formats MAY be augmented into this 'choice' statement by future efforts."; case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986. Encoding details are defined in the 'ct:csr' typedef defined in RFCAAAA.9640. A raw P10 does not support origin authentication in the CSR structure. External origin authentication may be provided via the ZTP-client's authentication to the ZTP-server at the transport layer (e.g., TLS)."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 RFCAAAA:9640: YANG Data Types and Groupings for Cryptography"; } } case cmc-csr { leaf cmc-csr { type binary; description "A profiled version of the 'Full PKI Request' message defined in RFC 5272, encoded using ASN.1distinguished encoding rulesDistinguished Encoding Rules (DER), as specified in ITU-T X.690. Forasymmetric key-basedasymmetric-key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated identity certificate's public key, the PKIData contains one reqSequence element and no cmsSequence or otherMsgSequence elements. The reqSequence is theTaggedRequestTaggedRequest, and it is the tcr CHOICE branch. The tcr is theTaggedCertificationRequestTaggedCertificationRequest, and it is thebodyPartIdbodyPartID and the certificateRequest elements. The certificateRequest is signed with the initial device identity certificate's private key. The initial device identitycertificatecertificate, and optionally its certificate chain is included in the SignedData certificates thatencapsulatesencapsulate the PKIData. Forasymmetric key-basedasymmetric-key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, the PKIData contains one cmsSequence element and no reqSequence or otherMsgSequence elements. The cmsSequence is theTaggedContentInfoTaggedContentInfo, and it includes a bodyPartID element and a contentInfo. The contentInfo is a SignedData encapsulating a PKIData with one reqSequence element and no cmsSequence or otherMsgSequence elements. The reqSequence is theTaggedRequestTaggedRequest, and it is the tcr CHOICE. The tcr is theTaggedCertificationRequestTaggedCertificationRequest, and it is thebodyPartIdbodyPartID and the certificateRequest elements. PKIData contains one cmsSequence element and no controlSequence, reqSequence, or otherMsgSequence elements. The certificateRequest is signed with the local device identity certificate's private key. The initial device identity certificate and optionally its certificate chain is included in the SignedData certificates thatencapsulatesencapsulate the PKIData. Forshared secret-basedshared-secret-based origin authentication of a CSR signed by the local device identity certificate's private key, the PKIData contains one cmsSequence element and no reqSequence or otherMsgSequence elements. The cmsSequence is theTaggedContentInfoTaggedContentInfo, and it includes a bodyPartID element and a contentInfo. The contentInfo is an AuthenticatedData encapsulating a PKIData with one reqSequence element and no cmsSequences or otherMsgSequence elements. The reqSequence is theTaggedRequestTaggedRequest, and it is the tcr CHOICE. The tcr is theTaggedCertificationRequestTaggedCertificationRequest, and it is thebodyPartIdbodyPartID and the certificateRequest elements. The certificateRequest is signed with the local device identity certificate's private key. The initial device identity certificate and optionally its certificate chain is included in the SignedData certificates thatencapsulatesencapsulate the PKIData."; reference "RFC 5272: Certificate Management over CMS (CMC) ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).";(DER)"; } } case cmp-csr { leaf cmp-csr { type binary; description "A PKIMessage structure, as defined in RFC 4210, encoded using ASN.1distinguished encoding rulesDistinguished Encoding Rules (DER), as specified in ITU-T X.690. Forasymmetric key-basedasymmetric-key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated initial device identity certificate's public key, PKIMessagescontainscontain one PKIMessage with the header and body elements,nodo not contain a protection element, and SHOULD contain the extraCerts element. The header element contains the pvno, sender, and recipient elements. The pvno contains cmp2000, and the sender contains the subject of the initial device identity certificate. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the initial device identity certificate's private key. The extraCerts element contains the initial device identity certificate, optionally followed by its certificate chain excluding the trust anchor. Forasymmetric key-basedasymmetric-key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, PKIMessagescontainscontain one PKIMessage with the header, body, and protectionelements,elements and SHOULD contain the extraCerts element. The header element contains the pvno, sender, recipient, protectionAlg, and optionally senderKID elements. The pvno contains cmp2000, the sender contains the subject of the initial device identity certificate, the protectionAlg contains the AlgorithmIdentifier of the used signature algorithm, and the senderKID contains the subject key identifier of the initial device identity certificate. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the local device identity certificate's private key. The protection element contains the digital signature generated with the initial device identity certificate's private key. The extraCerts element contains the initial device identity certificate, optionally followed by its certificate chain excluding the trust anchor. Forshared secret-basedshared-secret-based origin authentication of a CSR signed by the local device identity certificate's private key, PKIMessagescontainscontain one PKIMessage with the header, body, and protectionelement,element and no extraCerts element. The header element contains the pvno, sender, recipient, protectionAlg, and senderKID elements. The pvno contains cmp2000, the protectionAlg contains the AlgorithmIdentifier of the usedMACMessage Authentication Code (MAC) algorithm, and the senderKID contains a reference the recipient can use to identify the shared secret. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the local device identity certificate's private key. The protection element contains the MAC value generated with the shared secret."; reference "RFC 4210: Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).";(DER)"; } } } } }]]></artwork> <t keepWithPrevious="true"><CODE ENDS></t>]]></sourcecode> </section> <!-- YANG Module --> </section> <section anchor="sec-con" numbered="true" toc="default"> <name>Security Considerations</name> <t>This document builds on top of the solution presented in <xref target="RFC8572"format="default"/>format="default"/>, and therefore all theSecurity Considerationssecurity considerations discussed inRFC 8572<xref target="RFC8572"/> apply here as well.</t> <t>For the various CSR formats, when using PKCS#10, the security considerations in <xref target="RFC2986" format="default"/>apply,apply; when using CMP, the security considerations in <xref target="RFC4210" format="default"/>apply and,apply; and when using CMC, the security considerations in <xref target="RFC5272" format="default"/> apply.</t> <!--[rfced] RFC 7235 has been obsoleted by RFC 9110. May we replace RFC 7235 with RFC 9110? Original: For the various authentication mechanisms, when using TLS-level authentication, the security considerations in [RFC8446] apply and, when using HTTP-level authentication, the security considerations in [RFC7235] apply. --> <t>For the various authentication mechanisms, when using TLS-level authentication, the security considerations in <xref target="RFC8446" format="default"/>apply and,apply, and when using HTTP-level authentication, the security considerations in <xref target="RFC7235" format="default"/> apply.</t> <section numbered="true" toc="default"> <name>SZTP-Client Considerations</name> <section numbered="true" toc="default"> <name>Ensuring the Integrity of Asymmetric Private Keys</name> <t>The private key the SZTP-client uses for thedynamically-generateddynamically generated identity certificateMUST<bcp14>MUST</bcp14> be protected from inadvertent disclosure in order to prevent identity fraud.</t> <t>The security of this private key is essential in order to ensure the associated identity certificate can be used to authenticate the device it is issued to.</t> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that devices are manufactured withan HSM (hardwarea hardware securitymodule),module (HSM), such as aTPM (trustedtrusted platformmodule),module (TPM), to generate and contain the private key within the security perimeter of the HSM. In such cases, the privatekey,key and its associatedcertificates, MAYcertificates <bcp14>MAY</bcp14> have long validity periods.</t> <t>In cases where the SZTP-client does not possess anHSM,HSM or is unable to use an HSM to protect the private key, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to periodically reset the private key (and associated identity certificates) in order to minimize the lifetime of unprotected private keys. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using, e.g., aPKCS #12PKCS#12 message <xref target="RFC7292" format="default"/>. In another example, the SZTP-client could be configured to periodically reset the configuration to its factory default, thus causing removal of the private key and associated identity certificates and re-execution of the SZTP protocol.</t> </section> <section numbered="true" toc="default"> <name>Reuse of aManufacturer-generatedManufacturer-Generated Private Key</name> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that a new private key is generated for each CSR described in this document.</t> <t>Implementations must randomly generate nonces and private keys. The use of inadequatepseudo-randompseudorandom number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. As an example of predictable randomnumbersnumbers, see CVE-2008-0166 <xref target="CVE-2008-0166" format="default"/>, and some consequences of low-entropy random numbers are discussed inMining"Mining Your Ps andQsQs" <xref target="MiningPsQs" format="default"/>. The generation of quality random numbers is difficult. <xref target="ISO.20543-2019" format="default"/>, <xref target="NIST.SP.800-90Ar1" format="default"/>, BSI AIS 31 <xref target="AIS31" format="default"/>, BCP 106 <xref target="RFC4086" format="default"/>, and others offer valuable guidance in this area.</t> <t>This private keySHOULD<bcp14>SHOULD</bcp14> be protected as well as the built-in private key associated with the SZTP-client's initial device identity certificate (e.g., theIDevID,IDevID from <xref target="Std-802.1AR-2018" format="default"/>).</t> <t>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 isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to reuse the built-in private key rather than generate a new private key that is not as well protected.</t> </section> <section numbered="true" toc="default"> <name>Replay Attack Protection</name> <t>This RFC enables an SZTP-client to announce an ability to generate a new key to use for its CSR.</t> <t>When the SZTP-server responds with a request for the SZTP-client to generate a new key, it is essential that the SZTP-client actually generates a new key.</t> <t>Generating a new key each time enables the random bytes used to create the key to also serve the dual-purpose of acting like a "nonce" used in other mechanisms to detect replay attacks.</t> <t>When a fresh public/private key pair is generated for the request, confirmation to the SZTP-client that the response has not been replayed is enabled by the SZTP-client's fresh public key appearing in the signed certificate provided by the SZTP-server.</t> <t>When a public/private key pair associated with the manufacturer-generated identity certificate (e.g., IDevID) is used for 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 lost certificate that is associated to the private key known only to the SZTP-client. Protection of the private-key information is vital to public-key cryptography. Disclosure of the private-key material to another entity can lead to masquerades.</t> </section> <section anchor="untrusted" numbered="true" toc="default"> <name>Connecting to an Untrusted Bootstrap Server</name> <t><xref target="RFC8572" format="default"/> allows SZTP-clients to connect to untrustedSZTP-servers,SZTP-servers by blindly authenticating the SZTP-server's TLS end-entity certificate.</t> <t>As is discussed in <relref section="9.5" target="RFC8572"/>, in suchcasescases, the SZTP-clientMUST<bcp14>MUST</bcp14> assert that the bootstrapping data returned issigned,signed if the SZTP-client is to trust it.</t> <t>However, the HTTP error message used in this document cannot be signed data, as described inRFC 8572.</t><xref target="RFC8572"/>.</t> <t>Therefore, the solution presented in this document cannot be used when the SZTP-client connects to an untrusted SZTP-server.</t> <t>Consistent with the recommendation presented in <relref section="9.6" target="RFC8572"/>, SZTP-clientsSHOULD NOT<bcp14>SHOULD NOT</bcp14> pass the "csr-support" input parameter to an untrusted SZTP-server. SZTP-clientsSHOULD pass<bcp14>SHOULD</bcp14> instead pass the "signed-data-preferred" input parameter, as discussed in <relref section="B" target="RFC8572"/>.</t> </section> <section numbered="true" toc="default"> <name>Selecting the Best Origin Authentication Mechanism</name> <t>The origin of the CSR must be verified before a certificate is issued.</t> <t>When generating a new key, it is important that the SZTP-client be able to provide additional proof that it was the entity that generated the key.</t> <t>The CMP and CMC certificate request formats defined in this document support origin authentication. A raw PKCS#10 CSR does not support origin authentication.</t> <t>The CMP and CMC request formats support origin authentication using both PKI and a shared secret.</t> <t>Typically, only one possible origin authentication mechanism can possibly beused but,used, but in the case that the SZTP-client authenticates itself using both TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed by <relref section="5.3" target="RFC8572"/>, then the SZTP-client may need to choose between the two options.</t> <t>In the case that the SZTP-client must choose between an asymmetric key option versus a shared secret for origin authentication, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the SZTP-client choose using the asymmetric key.</t> </section> <section numbered="true" toc="default"> <name>Clearing the Private Key and Associated Certificate</name> <t>Unlike a manufacturer-generated identity certificate (e.g., IDevID), the deployment-generated identity certificate (e.g., LDevID) and the associated private key (assuming a new private key was generated for thepurpose),purpose) are considered user data andSHOULD<bcp14>SHOULD</bcp14> be cleared whenever the SZTP-client is reset to its factory default state, such as by the "factory-reset" RPC defined in <xref target="RFC8808" format="default"/>.</t> </section> </section> <section numbered="true" toc="default"> <name>SZTP-Server Considerations</name> <section numbered="true" toc="default"> <name>VerifyingProof of Possession</name> <t>RegardlessProof-of-Possession</name> <t>Regardless, if using a new asymmetric key or the bootstrapping 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 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.</t> </section> <section numbered="true" toc="default"> <name>VerifyingProof of Origin</name>Proof-of-Origin</name> <t>When the bootstrapping device's manufacturer-generated private key (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 CSR uses the same key pair.</t> <t>When the bootstrapping device's manufacturer-generated private key (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 ensuring that the CSR uses the same key pair.</t> <t>When a fresh asymmetric key is used with the CMP or CMC formats, the authentication is part of the protocols, which could employ either the manufacturer-generated private key or a shared secret. In addition, CMP and CMC support processing byaan RA before the request is passed to the CA, which allows for more robust handling of errors.</t> </section> <section numbered="true" toc="default"> <name>Supporting SZTP-Clientsthat don't trustThat Don't Trust the SZTP-Server</name> <t><xref target="RFC8572" format="default"/> allows SZTP-clients to connect to untrustedSZTP-servers,SZTP-servers by blindly authenticating the SZTP-server's TLS end-entity certificate.</t> <t>As is recommended in <xref target="untrusted" format="default"/>inof this document, in such cases, SZTP-clientsSHOULD<bcp14>SHOULD</bcp14> pass the "signed-data-preferred" input parameter.</t> <t>The reciprocal of this statement is that SZTP-servers, wanting to support SZTP-clients that don't trust them,SHOULD<bcp14>SHOULD</bcp14> support the "signed-data-preferred" input parameter, as discussed in <relref section="B" target="RFC8572"/>.</t> </section> </section> <!--[rfced] *AD - Please review the Security Considerations section of this document and confirm that the text at https://wiki.ietf.org/group/ops/yang-security-guidelines is not necessary. --> <section numbered="true" toc="default"> <name>Security Considerations for the "ietf-sztp-csr" YANG Module</name> <t>The recommended format for documenting theSecurity Considerationssecurity considerations for YANG modules is described in <relref section="3.7" target="RFC8407"/>. However, this module only augments two input parameters into the "get-bootstrapping-data" RPC in <xref target="RFC8572"format="default"/>,format="default"/> and therefore only needs to point to the relevant Security Considerations sections in that RFC.</t> <ul spacing="normal"> <li>Security considerations for the "get-bootstrapping-data" RPC are described in <relref section="9.16" target="RFC8572"/>.</li> <li>Security considerations for the "input" parameters passed inside the "get-bootstrapping-data" RPC are described in <relref section="9.6" target="RFC8572"/>.</li> </ul> </section> <section numbered="true" toc="default"> <name>Security Considerations for the "ietf-ztp-types" YANG Module</name> <t>The recommended format for documenting theSecurity Considerationssecurity considerations for YANG modules is described in <relref section="3.7" target="RFC8407"/>. However, this module does not define any protocol-accessible nodes (it only defines "identity" and "grouping"statements)statements), and therefore there are noSecuritysecurity considerations to report.</t> </section> </section> <!-- end Security Considerations --> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <section numbered="true" toc="default"> <name>The"IETF XML"IETF XML Registry</name><t>This document registers<t>IANA has registered two URIs in the "ns"subregistryregistry of theIETF"IETF XMLRegistryRegistry" <xref target="RFC3688" format="default"/> maintained at <ereftarget="https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns"/>. Following the format in <xref target="RFC3688" format="default"/>, the following registrations are requested:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr Registrant Contact: Thetarget="https://www.iana.org/assignments/xml-registry/" brackets="angle"/>. </t> <dl newline="false" spacing="compact"> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-sztp-csr</dd> <dt>Registrant Contact:</dt> <dd>The NETCONF WG of theIETF. XML: N/A,IETF.</dd> <dt>XML:</dt> <dd>N/A; the requested URI is an XMLnamespace. URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types Registrant Contact: Thenamespace.</dd> </dl> <dl newline="false" spacing="compact"> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ztp-types</dd> <dt>Registrant Contact:</dt> <dd>The NETCONF WG of theIETF. XML: N/A,IETF.</dd> <dt>XML:</dt> <dd>N/A; the requested URI is an XMLnamespace. ]]></artwork>namespace.</dd> </dl> </section> <section numbered="true" toc="default"> <name>The"YANGYANG ModuleNames"Names Registry</name><t>This document registers<t>IANA has registered two YANG modules in theYANG"YANG ModuleNamesNames" registry <xref target="RFC6020" format="default"/> maintained at <ereftarget="https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml"/>. Following the format defined in <xref target="RFC6020" format="default"/>, the below registrations are requested:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ name: ietf-sztp-csr namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr prefix: sztp-csr reference: RFC XXXX name: ietf-ztp-types namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types prefix: ztp-types reference: RFC XXXX ]]></artwork>target="https://www.iana.org/assignments/yang-parameters/" brackets="angle"/>.</t> <dl newline="false" spacing="compact"> <dt>Name:</dt> <dd>ietf-sztp-csr</dd> <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-sztp-csr</dd> <dt>Prefix:</dt> <dd>sztp-csr</dd> <dt>Reference:</dt> <dd>RFC 9646</dd> </dl> <dl newline="false" spacing="compact"> <dt>Name:</dt> <dd>ietf-ztp-types</dd> <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ztp-types</dd> <dt>Prefix:</dt> <dd>ztp-types</dd> <dt>Reference:</dt> <dd>RFC 9646</dd> </dl> </section> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="BCP" value="14"/> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization/> </author> <date year="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> </reference> <reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2986" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"> <front> <title>PKCS #10: Certification Request Syntax Specification Version 1.7</title> <seriesInfo name="DOI" value="10.17487/RFC2986"/> <seriesInfo name="RFC" value="2986"/> <author initials="M." surname="Nystrom" fullname="M. Nystrom"> <organization/> </author> <author initials="B." surname="Kaliski" fullname="B. Kaliski"> <organization/> </author> <date year="2000" month="November"/> <abstract> <t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t> </abstract> </front> </reference> <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> <front> <title>The IETF XML Registry</title> <seriesInfo name="DOI" value="10.17487/RFC3688"/> <seriesInfo name="RFC" value="3688"/> <seriesInfo name="BCP" value="81"/> <author initials="M." surname="Mealling" fullname="M. Mealling"> <organization/> </author> <date year="2004" month="January"/> <abstract> <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t> </abstract> </front> </reference> <reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4210" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"> <front> <title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title> <seriesInfo name="DOI" value="10.17487/RFC4210"/> <seriesInfo name="RFC" value="4210"/> <author initials="C." surname="Adams" fullname="C. Adams"> <organization/> </author> <author initials="S." surname="Farrell" fullname="S. Farrell"> <organization/> </author> <author initials="T." surname="Kause" fullname="T. Kause"> <organization/> </author> <author initials="T." surname="Mononen" fullname="T. Mononen"> <organization/> </author> <date year="2005" month="September"/> <abstract> <t>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]</t> </abstract> </front> </reference> <reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5272" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"> <front> <title>Certificate Management over CMS (CMC)</title> <seriesInfo name="DOI" value="10.17487/RFC5272"/> <seriesInfo name="RFC" value="5272"/> <author initials="J." surname="Schaad" fullname="J. Schaad"> <organization/> </author> <author initials="M." surname="Myers" fullname="M. Myers"> <organization/> </author> <date year="2008" month="June"/> <abstract> <t>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t> <t>1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t> <t>2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t> <t>CMC also requires the use of the transport document and the requirements usage document along with this<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7235.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/> <!-- [I-D.ietf-netconf-crypto-types] IESG state I-D Exists; companion documentfor a full definition. [STANDARDS-TRACK]</t> </abstract> </front> </reference>RFC 9640 --> <referenceanchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">anchor='RFC9640' target='https://www.rfc-editor.org/info/rfc9640'> <front> <title>YANG- ADataModeling Language for the Network Configuration Protocol (NETCONF)</title> <seriesInfo name="DOI" value="10.17487/RFC6020"/> <seriesInfo name="RFC" value="6020"/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"> <organization/> </author> <date year="2010" month="October"/> <abstract> <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls,Types andNETCONF notifications. [STANDARDS-TRACK]</t> </abstract> </front> </reference> <reference anchor="RFC7235" target="https://www.rfc-editor.org/info/rfc7235" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7235.xml"> <front> <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title> <seriesInfo name="DOI" value="10.17487/RFC7235"/> <seriesInfo name="RFC" value="7235"/> <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor"> <organization/> </author> <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor"> <organization/> </author> <date year="2014" month="June"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocolGroupings fordistributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.</t> </abstract> </front> </reference> <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"> <front> <title>The YANG 1.1 Data Modeling Language</title> <seriesInfo name="DOI" value="10.17487/RFC7950"/> <seriesInfo name="RFC" value="7950"/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"> <organization/> </author> <date year="2016" month="August"/> <abstract> <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t> </abstract> </front> </reference> <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"> <front> <title>RESTCONF Protocol</title> <seriesInfo name="DOI" value="10.17487/RFC8040"/> <seriesInfo name="RFC" value="8040"/> <author initials="A." surname="Bierman" fullname="A. Bierman"> <organization/> </author> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund"> <organization/> </author>Cryptography</title> <author initials="K." surname="Watsen"fullname="K.fullname="Kent Watsen"><organization/> </author> <date year="2017" month="January"/> <abstract> <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t> </abstract> </front> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="BCP" value="14"/> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization/> </author> <date year="2017" month="May"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> </reference> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <seriesInfo name="DOI" value="10.17487/RFC8446"/> <seriesInfo name="RFC" value="8446"/> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization/><organization>Watsen Networks</organization> </author> <dateyear="2018" month="August"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract>month="August" year="2024"/> </front></reference> <reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8572" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"> <front> <title>Secure Zero Touch Provisioning (SZTP)</title> <seriesInfo name="DOI" value="10.17487/RFC8572"/><seriesInfo name="RFC"value="8572"/> <author initials="K." surname="Watsen" fullname="K. Watsen"> <organization/> </author> <author initials="I." surname="Farrer" fullname="I. Farrer"> <organization/> </author> <author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson"> <organization/> </author> <date year="2019" month="April"/> <abstract> <t>This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t> </abstract> </front> </reference> <reference anchor="RFC8791" target="https://www.rfc-editor.org/info/rfc8791" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"> <front> <title>YANG Data Structure Extensions</title>value="9640"/> <seriesInfo name="DOI"value="10.17487/RFC8791"/> <seriesInfo name="RFC" value="8791"/> <author initials="A." surname="Bierman" fullname="A. Bierman"> <organization/> </author> <author initials="M." surname="Björklund" fullname="M. Björklund"> <organization/> </author> <author initials="K." surname="Watsen" fullname="K. Watsen"> <organization/> </author> <date year="2020" month="June"/> <abstract> <t>This document describes YANG mechanisms for defining abstract data structures with YANG.</t> </abstract> </front>value="10.17487/RFC9640"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-crypto-types.xml"/><!-- THE FOLLOWING LINE DOESN'T RESOLVE FOR SOME REASON: <?rfc include="_reference.ITU.X690.2015.xml"?> --> <!-- THE FOLLOWING IS COPIED FROM RFC 8366 --> <!-- [rfced] As the reference below has been superseded by a 2021 version, we have updated it as follows. Please let us know of any objections. Original: [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/>. Current: [ITU.X690.2021] ITU, "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, February 2021, <https://www.itu.int/rec/T-REC-X.690/>. --> <referenceanchor="ITU.X690.2015"anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-X.690/"> <front> <title>InformationTechnologytechnology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <seriesInfo name="ITU-TRecommendation X.690," value="ISO/IEC 8825-1"/>Recommendation" value="X.690"/> <seriesInfo name="ISO/IEC" value="8825-1"/> <author><organization>International Telecommunication Union</organization><organization>ITU</organization> </author> <datemonth="August" year="2015"/>month="February" year="2021"/> </front> </reference> </references> <references> <name>Informative References</name> <!-- [rfced] The URL for the following reference redirects to https://standards.ieee.org/ieee/802.1AR/6995/. We have updated it accordingly. Original: [Std-802.1AR-2018] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", 14 June 2018, <https://standards.ieee.org/standard/802_1AR-2018.html>. Current: [Std-802.1AR-2018] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", August 2018, <https://standards.ieee.org/standard/802_1AR-2018.html>. --> <reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/standard/802_1AR-2018.html"> <front> <title>IEEE Standard for Local andmetropolitan area networksMetropolitan Area Networks - Secure Device Identity</title><author fullname="WG802.1 - Higher Layer LAN Protocols Working Group"> <organization>IEEE SA-Standards Board</organization><author> <organization>IEEE</organization> </author> <dateday="14" month="June"month="August" year="2018"/> </front> </reference> <reference anchor="CVE-2008-0166" target="https://nvd.nist.gov/vuln/detail/CVE-2008-0166"> <front> <title>National Vulnerability Database -CVE-2008-0166</title>CVE-2008-0166 Detail</title> <author> <organization>National Institute of Science and Technology (NIST)</organization> </author> <dateday="13"month="May" year="2008"/> </front> </reference> <reference anchor="MiningPsQs" target="https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger"> <front> <title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices</title><author> <organization>Security'12: Proceedings of the 21st USENIX conference on Security symposium</organization> </author><author fullname="NadiaHeninger">Heninger" initials="N." surname="Heninger"> <organization>UC San Diego</organization> </author> <author fullname="ZakirDurumeric">Durumeric" initials="Z." surname="Durumeric"> <organization>University of Michigan</organization> </author> <author fullname="EricWustrow">Wustrow" initials="E." surname="Wustrow"> <organization>University of Michigan</organization> </author> <author fullname="J. AlexHalderman">Halderman" initials="J." surname="Halderman"> <organization>University of Michigan</organization> </author> <date month="August" year="2012"/> </front> <refcontent>Security'12: Proceedings of the 21st USENIX Conference on Security Symposium</refcontent> </reference> <reference anchor="ISO.20543-2019"> <front> <title>Information technology -- Security techniques -- Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408</title><seriesInfo name="ISO" value="Draft Standard 20543-2019"/><author> <organization>International Organization for Standardization (ISO)</organization> </author> <date month="October" year="2019"/> </front> <seriesInfo name="ISO/IEC" value="20543:2019"/> </reference> <reference anchor="NIST.SP.800-90Ar1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf"> <front> <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators</title><seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/> <seriesInfo name="NIST" value="NIST SP 800-90Ar1"/><authorinitials="Elaine B."initials="E" surname="Barker" fullname="Elaine B. Barker"> <organization>Information Technology Laboratory</organization> </author> <authorinitials="John M."initials="J" surname="Kelsey" fullname="John M. Kelsey"> <organization>Information Technology Laboratory</organization> </author> <date year="2015" month="June"/> </front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/> <seriesInfo name="NIST SP" value="800-90Ar1"/> </reference> <reference anchor="AIS31" target="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_random_number_generators_e.pdf"> <front> <title>A proposal for: Functionality classes for random numbergenerators, versiongenerators - Version 2.0</title><author> <organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization> </author><author initials="W" surname="Killmann" fullname="Wolfgang Killmann"> <organization>T-Systems GEI GmbH</organization> </author> <author initials="W." surname="Schindler" fullname="Werner Schindler"> <organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization><!-- <organization>Federal Office for Information Security (BSI)</organization> --></author> <dateday="18" month="09"month="September" year="2011"/> </front> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8808.xml"/> <!-- [I-D.ietf-netconf-trust-anchors] IESG state: RFC Ed Queue as of 03/21/24--> <referenceanchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc9641"> <front><title>Randomness Requirements for Security</title> <seriesInfo name="DOI" value="10.17487/RFC4086"/> <seriesInfo name="RFC" value="4086"/> <seriesInfo name="BCP" value="106"/> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"> <organization/> </author> <author initials="J." surname="Schiller" fullname="J. Schiller"> <organization/> </author> <author initials="S." surname="Crocker" fullname="S. Crocker"> <organization/> </author> <date year="2005" month="June"/> <abstract> <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used<title>A YANG Data Model forthis purpose. It provides suggestions to ameliorate the problem whenahardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> </reference> <reference anchor="RFC7292" target="https://www.rfc-editor.org/info/rfc7292" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml"> <front> <title>PKCS #12: Personal Information Exchange Syntax v1.1</title> <seriesInfo name="DOI" value="10.17487/RFC7292"/> <seriesInfo name="RFC" value="7292"/>Truststore</title> <author initials="K."surname="Moriarty" fullname="K. Moriarty" role="editor"> <organization/> </author> <author initials="M." surname="Nystrom" fullname="M. Nystrom"> <organization/> </author> <author initials="S." surname="Parkinson" fullname="S. Parkinson"> <organization/> </author> <author initials="A." surname="Rusch" fullname="A. Rusch"> <organization/> </author> <author initials="M." surname="Scott" fullname="M. Scott"> <organization/>surname="Watsen" fullname="Kent Watsen"> <organization>Watsen Networks</organization> </author> <dateyear="2014" month="July"/> <abstract> <t>PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.</t> <t>This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t> </abstract>month="August" year="2024"/> </front></reference> <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> <front> <title>YANG Tree Diagrams</title> <seriesInfo name="DOI" value="10.17487/RFC8340"/><seriesInfo name="RFC"value="8340"/> <seriesInfo name="BCP" value="215"/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund"> <organization/> </author> <author initials="L." surname="Berger" fullname="L. Berger" role="editor"> <organization/> </author> <date year="2018" month="March"/> <abstract> <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t> </abstract> </front> </reference> <reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8407" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>value="9641"/> <seriesInfo name="DOI"value="10.17487/RFC8407"/> <seriesInfo name="RFC" value="8407"/> <seriesInfo name="BCP" value="216"/> <author initials="A." surname="Bierman" fullname="A. Bierman"> <organization/> </author> <date year="2018" month="October"/> <abstract> <t>This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.</t> </abstract> </front>value="10.17487/RFC9641"/> </reference> <!-- [I-D.ietf-netconf-keystore] IESG state: RFC Ed Queue as of 03/21/24--> <referenceanchor="RFC8808" target="https://www.rfc-editor.org/info/rfc8808" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8808.xml">anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9642"> <front> <title>A YANG Data Model forFactory Default Settings</title> <seriesInfo name="DOI" value="10.17487/RFC8808"/> <seriesInfo name="RFC" value="8808"/> <author initials="Q." surname="Wu" fullname="Q. Wu"> <organization/> </author> <author initials="B." surname="Lengyel" fullname="B. Lengyel"> <organization/> </author>a Keystore and Keystore Operations</title> <authorinitials="Y." surname="Niu" fullname="Y. Niu"> <organization/>initials="K." surname="Watsen" fullname="Kent Watsen"> <organization>Watsen Networks</organization> </author> <dateyear="2020" month="August"/> <abstract> <t>This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t> </abstract>month="August" year="2024"/> </front> <seriesInfo name="RFC" value="9642"/> <seriesInfo name="DOI" value="10.17487/RFC9642"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-keystore.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-trust-anchors.xml"/></references> </references> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thank for following for lively discussions on list and in the halls (ordered by first name):Benjamin Kaduk, David<contact fullname="Benjamin Kaduk"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="David vonOheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz, Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman Sarkar.Oheimb"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Guy Fedorkow"/>, <contact fullname="Hendrik Brockhaus"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Meral Shirazipour"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Rich Salz"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Qin Wu"/>, <contact fullname="Yaron Sheffer"/>, and <contact fullname="Zaheduzzaman Sarkar"/>. </t> </section> <section numbered="false" toc="default"> <name>Contributors</name> <t>Special thanks go toDavid<contact fullname="David vonOheimbOheimb"/> andHendrik Brockhaus<contact fullname="Hendrik Brockhaus"/> for helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes.</t> </section> <!--[rfced] We note that names of structures appear within no quotes, single quotes, and double quotes. Please review and let us know if/how these may be made consistent. Examples are listed below. CertificationRequestInfo structure vs. 'csr-support' structure vs. "csr-request" structure --> <!--[rfced] Acronyms a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Initial Device Identifier (IDevID) Local Device Identifier (LDevID) registration authority (RA) b) Should "CA" be expanded as "certification authority" or "certificate authority"? Original: The ability to provision an identity certificate that is purpose- built for a production environment during the bootstrapping process removes reliance on the manufacturer CA, c) Should "NMS" be expanded as "Network Management System" or "Network Management Station"? Original: For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR)... --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>