Internet Engineering Task Force (IETF) K. Watsen
Request for Comments: 8572 Watsen Networks
Category: Standards Track I. Farrer
ISSN: 2070-1721 Deutsche Telekom AG
M. Abrahamsson
T-Systems
April 2019
Internet Engineering Task Force (IETF) K. Watsen
Request for Comments: 8572 Watsen Networks
Category: Standards Track I. Farrer
ISSN: 2070-1721 Deutsche Telekom AG
M. Abrahamsson
T-Systems
April 2019
Secure Zero Touch Provisioning (SZTP)
安全零接触资源调配（SZTP）
Abstract
摘要
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.
本文档介绍了一种在网络设备以出厂默认状态启动时安全配置网络设备的技术。解决方案中的各种变体使其能够在公共和专用网络上使用。设置步骤能够更新引导映像、提交初始配置和执行任意脚本以满足辅助需求。更新后的设备随后能够与其他系统建立安全连接。例如，设备可以与特定于部署的网络管理系统建立NETCONF（RFC 6241）和/或restcconf（RFC 8040）连接。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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/rfc8572.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8572.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 8
1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8
2. Types of Conveyed Information . . . . . . . . . . . . . . . . 8
2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8
2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Conveyed Information . . . . . . . . . . . . . . . . . . 10
3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 12
3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 13
3.4. Artifact Encryption . . . . . . . . . . . . . . . . . . . 13
3.5. Artifact Groupings . . . . . . . . . . . . . . . . . . . 14
4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 15
4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 15
4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 21
5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Processing a Source of Bootstrapping Data . . . . . . . . 25
5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 27
5.5. Processing Redirect Information . . . . . . . . . . . . . 28
5.6. Processing Onboarding Information . . . . . . . . . . . . 28
6. The Conveyed Information Data Model . . . . . . . . . . . . . 32
6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 32
6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 32
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 34
7. The SZTP Bootstrap Server API . . . . . . . . . . . . . . . . 41
7.1. API Overview . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 42
7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 45
8. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1. DHCPv4 SZTP Redirect Option . . . . . . . . . . . . . . . 56
8.2. DHCPv6 SZTP Redirect Option . . . . . . . . . . . . . . . 58
8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 59
9.2. Use of IDevID Certificates . . . . . . . . . . . . . . . 60
9.3. Immutable Storage for Trust Anchors . . . . . . . . . . . 60
9.4. Secure Storage for Long-Lived Private Keys . . . . . . . 60
9.5. Blindly Authenticating a Bootstrap Server . . . . . . . . 60
9.6. Disclosing Information to Untrusted Servers . . . . . . . 60
9.7. Sequencing Sources of Bootstrapping Data . . . . . . . . 61
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 8
1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8
2. Types of Conveyed Information . . . . . . . . . . . . . . . . 8
2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8
2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Conveyed Information . . . . . . . . . . . . . . . . . . 10
3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 12
3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 13
3.4. Artifact Encryption . . . . . . . . . . . . . . . . . . . 13
3.5. Artifact Groupings . . . . . . . . . . . . . . . . . . . 14
4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 15
4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 15
4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 21
5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Processing a Source of Bootstrapping Data . . . . . . . . 25
5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 27
5.5. Processing Redirect Information . . . . . . . . . . . . . 28
5.6. Processing Onboarding Information . . . . . . . . . . . . 28
6. The Conveyed Information Data Model . . . . . . . . . . . . . 32
6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 32
6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 32
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 34
7. The SZTP Bootstrap Server API . . . . . . . . . . . . . . . . 41
7.1. API Overview . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 42
7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 45
8. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1. DHCPv4 SZTP Redirect Option . . . . . . . . . . . . . . . 56
8.2. DHCPv6 SZTP Redirect Option . . . . . . . . . . . . . . . 58
8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 59
9.2. Use of IDevID Certificates . . . . . . . . . . . . . . . 60
9.3. Immutable Storage for Trust Anchors . . . . . . . . . . . 60
9.4. Secure Storage for Long-Lived Private Keys . . . . . . . 60
9.5. Blindly Authenticating a Bootstrap Server . . . . . . . . 60
9.6. Disclosing Information to Untrusted Servers . . . . . . . 60
9.7. Sequencing Sources of Bootstrapping Data . . . . . . . . 61
9.8. Safety of Private Keys Used for Trust . . . . . . . . . . 62
9.9. Increased Reliance on Manufacturers . . . . . . . . . . . 62
9.10. Concerns with Trusted Bootstrap Servers . . . . . . . . . 63
9.11. Validity Period for Conveyed Information . . . . . . . . 63
9.12. Cascading Trust via Redirects . . . . . . . . . . . . . . 64
9.13. Possible Reuse of Private Keys . . . . . . . . . . . . . 65
9.14. Non-issue with Encrypting Signed Artifacts . . . . . . . 65
9.15. The "ietf-sztp-conveyed-info" YANG Module . . . . . . . . 65
9.16. The "ietf-sztp-bootstrap-server" YANG Module . . . . . . 66
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 67
10.2. The YANG Module Names Registry . . . . . . . . . . . . . 67
10.3. The SMI Security for S/MIME CMS Content Type Registry . 68
10.4. The BOOTP Vendor Extensions and DHCP Options Registry . 68
10.5. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Registry . . . . . . . . . . . . . . . . . . . 68
10.6. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
10.7. The Underscored and Globally Scoped DNS Node Names
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Example Device Data Model . . . . . . . . . . . . . 74
A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 74
A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 75
A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Promoting a Connection from Untrusted to Trusted . . 79
Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 80
C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 80
C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 83
C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 85
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
9.8. Safety of Private Keys Used for Trust . . . . . . . . . . 62
9.9. Increased Reliance on Manufacturers . . . . . . . . . . . 62
9.10. Concerns with Trusted Bootstrap Servers . . . . . . . . . 63
9.11. Validity Period for Conveyed Information . . . . . . . . 63
9.12. Cascading Trust via Redirects . . . . . . . . . . . . . . 64
9.13. Possible Reuse of Private Keys . . . . . . . . . . . . . 65
9.14. Non-issue with Encrypting Signed Artifacts . . . . . . . 65
9.15. The "ietf-sztp-conveyed-info" YANG Module . . . . . . . . 65
9.16. The "ietf-sztp-bootstrap-server" YANG Module . . . . . . 66
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 67
10.2. The YANG Module Names Registry . . . . . . . . . . . . . 67
10.3. The SMI Security for S/MIME CMS Content Type Registry . 68
10.4. The BOOTP Vendor Extensions and DHCP Options Registry . 68
10.5. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Registry . . . . . . . . . . . . . . . . . . . 68
10.6. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
10.7. The Underscored and Globally Scoped DNS Node Names
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Example Device Data Model . . . . . . . . . . . . . 74
A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 74
A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 75
A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Promoting a Connection from Untrusted to Trusted . . 79
Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 80
C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 80
C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 83
C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 85
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
A fundamental business requirement for any network operator is to reduce costs where possible. For network operators, deploying devices to many locations can be a significant cost, as sending trained specialists to each site for installations is both cost prohibitive and does not scale.
任何网络运营商的一个基本业务要求是尽可能降低成本。对于网络运营商来说，将设备部署到多个位置可能是一项巨大的成本，因为向每个站点派遣训练有素的专家进行安装既成本高昂，又无法扩展。
This document defines Secure Zero Touch Provisioning (SZTP), a bootstrapping strategy enabling devices to securely obtain bootstrapping data with no installer action beyond physical placement and connecting network and power cables. As such, SZTP enables non-technical personnel to bring up devices in remote locations without the need for any operator input.
本文档定义了安全零接触配置（SZTP），这是一种引导策略，使设备能够安全地获取引导数据，而无需安装程序执行物理放置和连接网络和电源电缆以外的操作。因此，SZTP使非技术人员能够在远程位置启动设备，而无需任何操作员输入。
The SZTP solution includes updating the boot image, committing an initial configuration, and executing 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 [RFC6241] and/or RESTCONF [RFC8040] connections with deployment-specific network management systems.
SZTP解决方案包括更新启动映像、提交初始配置以及执行任意脚本以满足辅助需求。更新后的设备随后能够与其他系统建立安全连接。例如，设备可以与特定于部署的网络管理系统建立NETCONF[RFC6241]和/或restcconf[RFC8040]连接。
This document primarily regards physical devices, where the setting of the device's initial state (described in Section 5.1) occurs during the device's manufacturing process. The SZTP solution may be extended to support virtual machines or other such logical constructs, but details for how this can be accomplished is left for future work.
本文件主要涉及物理设备，设备初始状态的设置（如第5.1节所述）发生在设备的制造过程中。SZTP解决方案可以扩展以支持虚拟机或其他类似的逻辑结构，但如何实现这一点的细节将留给未来的工作。
o Device connecting to a remotely administered network
o 连接到远程管理网络的设备
This use case involves scenarios, such as a remote branch office or convenience store, whereby a device connects as an access gateway to an ISP's network. Assuming it is not possible to customize the ISP's network to provide any bootstrapping support, and with no other nearby device to leverage, the device has no recourse but to reach out to an Internet-based bootstrap server to bootstrap from.
这个用例涉及到一些场景，例如远程分支办公室或便利店，其中一个设备作为访问网关连接到ISP的网络。假设无法自定义ISP的网络以提供任何引导支持，并且附近没有其他设备可供利用，则该设备只能通过基于Internet的引导服务器进行引导。
o Device connecting to a locally administered network
o 连接到本地管理网络的设备
This use case covers all other scenarios and differs only in that the device may additionally leverage nearby devices, which may direct it to use a local service to bootstrap from. If no such information is available, or the device is unable to use the information provided, it can then reach out to the network just as it would for the remotely administered network use case.
此用例涵盖所有其他场景，不同之处仅在于设备可能会额外利用附近的设备，这可能会指示其使用本地服务进行引导。如果没有此类信息可用，或者设备无法使用所提供的信息，那么它可以像远程管理网络用例一样接触网络。
Conceptual workflows for how SZTP might be deployed are provided in Appendix C.
关于如何部署SZTP的概念工作流程见附录C。
This document uses the following terms (sorted alphabetically):
本文件使用以下术语（按字母顺序排列）：
Artifact: The term "artifact" is used throughout this document to represent any of the three artifacts defined in Section 3 (conveyed information, ownership voucher, and owner certificate). These artifacts collectively provide all the bootstrapping data a device may use.
工件：本文档中使用术语“工件”来表示第3节（传递信息、所有权凭证和所有者证书）中定义的三个工件中的任何一个。这些工件共同提供设备可能使用的所有引导数据。
Bootstrapping Data: The term "bootstrapping data" is used throughout this document to refer to the collection of data that a device may obtain during the bootstrapping process. Specifically, it refers to the three artifacts defined in Section 3 (conveyed information, owner certificate, and ownership voucher).
引导数据：术语“引导数据”在本文档中用于指设备在引导过程中可能获得的数据集合。具体来说，它指的是第3节中定义的三个工件（传递信息、所有者证书和所有权凭证）。
Bootstrap Server: The term "bootstrap server" is used within this document to mean any RESTCONF server implementing the YANG module defined in Section 7.3.
引导服务器：本文档中的术语“引导服务器”是指任何实现第7.3节中定义的模块的RESTCONF服务器。
Conveyed Information: The term "conveyed information" is used herein to refer to either redirect information or onboarding information. Conveyed information is one of the three bootstrapping artifacts described in Section 3.
传达信息：术语“传达信息”在本文中用于指重定向信息或入职信息。传递的信息是第3节中描述的三个引导工件之一。
Device: The term "device" is used throughout this document to refer to a network element that needs to be bootstrapped. See Section 5 for more information about devices.
设备：本文档中使用的术语“设备”指的是需要引导的网元。有关设备的更多信息，请参见第5节。
Manufacturer: The term "manufacturer" is used herein to refer to the manufacturer of a device or a delegate of the manufacturer.
制造商：此处使用术语“制造商”指设备制造商或制造商代表。
Network Management System (NMS): The acronym "NMS" is used throughout this document to refer to the deployment-specific management system that the bootstrapping process is responsible for introducing devices to. From a device's perspective, when the bootstrapping process has completed, the NMS is a NETCONF or RESTCONF client.
网络管理系统（NMS）：本文档中使用的首字母缩略词“NMS”是指引导过程负责向其引入设备的特定于部署的管理系统。从设备的角度来看，当引导过程完成时，NMS是NETCONF或RESTCONF客户端。
Onboarding Information: The term "onboarding information" is used herein to refer to one of the two types of "conveyed information" defined in this document, the other being "redirect information". Onboarding information is formally defined by the "onboarding-information" container within the "conveyed-information" yang-data structure in Section 6.3.
入职信息：术语“入职信息”用于指本文件中定义的两种“传达信息”之一，另一种为“重定向信息”。入职信息由第6.3节“传达信息”数据结构中的“入职信息”容器正式定义。
Onboarding Server: The term "onboarding server" is used herein to refer to a bootstrap server that only returns onboarding information.
载入服务器：术语“载入服务器”在本文中用于指仅返回载入信息的引导服务器。
Owner: The term "owner" is used throughout this document to refer to the person or organization that purchased or otherwise owns a device.
所有者：本文档中使用的术语“所有者”指购买或以其他方式拥有设备的个人或组织。
Owner Certificate: The term "owner certificate" is used in this document to represent an X.509 certificate that binds an owner identity to a public key, which a device can use to validate a signature over the conveyed information artifact. The owner certificate may be communicated along with its chain of intermediate certificates leading up to a known trust anchor. The owner certificate is one of the three bootstrapping artifacts described in Section 3.
所有者证书：在本文档中，术语“所有者证书”用于表示将所有者身份绑定到公钥的X.509证书，设备可使用该公钥验证传输信息工件上的签名。所有者证书可以与其通向已知信任锚的中间证书链一起通信。所有者证书是第3节中描述的三个引导工件之一。
Ownership Voucher: The term "ownership voucher" is used in this document to represent the voucher artifact defined in [RFC8366]. The ownership voucher is used to assign a device to an owner. The ownership voucher is one of the three bootstrapping artifacts described in Section 3.
所有权凭证：本文档中使用术语“所有权凭证”来表示[RFC8366]中定义的凭证工件。所有权凭证用于将设备分配给所有者。所有权凭证是第3节中描述的三个引导工件之一。
Redirect Information: The term "redirect information" is used herein to refer to one of the two types of "conveyed information" defined in this document, the other being "onboarding information". Redirect information is formally defined by the "redirect-information" container within the "conveyed-information" yang-data structure in Section 6.3.
重定向信息：术语“重定向信息”在本文中用于指本文件中定义的两种“传达信息”中的一种，另一种是“入职信息”。重定向信息由第6.3节“传送信息”数据结构中的“重定向信息”容器正式定义。
Redirect Server: The term "redirect server" is used to refer to a bootstrap server that only returns redirect information. A redirect server is particularly useful when hosted by a manufacturer, as a well-known (e.g., Internet-based) resource to redirect devices to deployment-specific bootstrap servers.
重定向服务器：术语“重定向服务器”用于指仅返回重定向信息的引导服务器。当由制造商托管时，重定向服务器尤其有用，因为它是将设备重定向到特定于部署的引导服务器的众所周知的（例如，基于Internet的）资源。
Signed Data: The term "signed data" is used throughout to mean conveyed information that has been signed, specifically by a private key possessed by a device's owner.
签名数据：术语“签名数据”通篇用于表示已签名的传输信息，特别是由设备所有者拥有的私钥签名的信息。
Unsigned Data: The term "unsigned data" is used throughout to mean conveyed information that has not been signed.
未签名数据：术语“未签名数据”通篇用于表示未签名的传输信息。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Tree diagrams used in this document follow the notation defined in [RFC8340].
本文档中使用的树形图遵循[RFC8340]中定义的符号。
This document defines two types of conveyed information that devices can access during the bootstrapping process. These conveyed information types are described in this section. Examples are provided in Section 6.2.
本文档定义了引导过程中设备可以访问的两种类型的传输信息。本节将介绍这些传递的信息类型。第6.2节提供了示例。
Redirect information redirects a device to another bootstrap server. Redirect information encodes a list of bootstrap servers, each specifying the bootstrap server's hostname (or IP address), an optional port, and an optional trust anchor certificate that the device can use to authenticate the bootstrap server with.
重定向信息将设备重定向到另一个引导服务器。重定向信息对引导服务器列表进行编码，每个服务器指定引导服务器的主机名（或IP地址）、可选端口和可选信任锚证书，设备可使用这些证书对引导服务器进行身份验证。
Redirect information is YANG-modeled data formally defined by the "redirect-information" container in the YANG module presented in Section 6.3. This container has the tree diagram shown below.
重定向信息是由第6.3节所述YANG模块中的“重定向信息”容器正式定义的数据。此容器具有如下所示的树形图。
+--:(redirect-information)
+-- redirect-information
+-- bootstrap-server* [address]
+-- address inet:host
+-- port? inet:port-number
+-- trust-anchor? cms
+--:(redirect-information)
+-- redirect-information
+-- bootstrap-server* [address]
+-- address inet:host
+-- port? inet:port-number
+-- trust-anchor? cms
Redirect information may be trusted or untrusted. The redirect information is trusted whenever it is obtained via a secure connection to a trusted bootstrap server or whenever it is signed by the device's owner. In all other cases, the redirect information is untrusted.
重定向信息可能受信任，也可能不受信任。只要重定向信息是通过与可信引导服务器的安全连接获得的，或者是由设备所有者签名的，重定向信息都是可信的。在所有其他情况下，重定向信息都是不可信的。
Trusted redirect information is useful for enabling a device to establish a secure connection to a specified bootstrap server, which is possible when the redirect information includes the bootstrap server's trust anchor certificate.
可信重定向信息对于使设备能够建立到指定引导服务器的安全连接非常有用，当重定向信息包括引导服务器的信任锚证书时，这是可能的。
Untrusted redirect information is useful for directing a device to a bootstrap server where signed data has been staged for it to obtain. Note that, when the redirect information is untrusted, devices discard any potentially included trust anchor certificates.
不受信任的重定向信息可用于将设备定向到引导服务器，其中已暂存签名数据供其获取。请注意，当重定向信息不受信任时，设备会丢弃任何可能包含的信任锚证书。
How devices process redirect information is described in Section 5.5.
第5.5节描述了设备如何处理重定向信息。
Onboarding information provides data necessary for a device to bootstrap itself and establish secure connections with other systems. As defined in this document, onboarding information can specify details about the boot image a device must be running, an initial configuration the device must commit, and scripts that the device must successfully execute.
载入信息提供设备自引导和与其他系统建立安全连接所需的数据。如本文档中所定义，入职信息可以指定有关设备必须运行的引导映像、设备必须提交的初始配置以及设备必须成功执行的脚本的详细信息。
Onboarding information is YANG-modeled data formally defined by the "onboarding-information" container in the YANG module presented in Section 6.3. This container has the tree diagram shown below.
入职信息是由第6.3节所述YANG模块中的“入职信息”容器正式定义的YANG建模数据。此容器具有如下所示的树形图。
+--:(onboarding-information)
+-- onboarding-information
+-- boot-image
| +-- os-name? string
| +-- os-version? string
| +-- download-uri* inet:uri
| +-- image-verification* [hash-algorithm]
| +-- hash-algorithm identityref
| +-- hash-value yang:hex-string
+-- configuration-handling? enumeration
+-- pre-configuration-script? script
+-- configuration? binary
+-- post-configuration-script? script
+--:(onboarding-information)
+-- onboarding-information
+-- boot-image
| +-- os-name? string
| +-- os-version? string
| +-- download-uri* inet:uri
| +-- image-verification* [hash-algorithm]
| +-- hash-algorithm identityref
| +-- hash-value yang:hex-string
+-- configuration-handling? enumeration
+-- pre-configuration-script? script
+-- configuration? binary
+-- post-configuration-script? script
Onboarding information must be trusted for it to be of any use to a device. There is no option for a device to process untrusted onboarding information.
必须信任入职信息，才能使其对设备有任何用途。设备没有处理不受信任的入职信息的选项。
Onboarding information is trusted whenever it is obtained via a secure connection to a trusted bootstrap server or whenever it is signed by the device's owner. In all other cases, the onboarding information is untrusted.
无论何时通过安全连接到受信任的引导服务器获取或由设备所有者签名，登录信息都是受信任的。在所有其他情况下，入职信息都是不可信的。
How devices process onboarding information is described in Section 5.6.
第5.6节描述了设备如何处理入职信息。
This document defines three artifacts that can be made available to devices while they are bootstrapping. Each source of bootstrapping data specifies how it provides the artifacts defined in this section (see Section 4).
本文档定义了三个工件，它们可以在设备引导时提供给设备。每个引导数据源都指定如何提供本节中定义的工件（参见第4节）。
The conveyed information artifact encodes the essential bootstrapping data for the device. This artifact is used to encode the redirect information and onboarding information types discussed in Section 2.
传输的信息工件对设备的基本引导数据进行编码。此工件用于对第2节中讨论的重定向信息和入职信息类型进行编码。
The conveyed information artifact is a Cryptographic Message Syntax (CMS) structure, as described in [RFC5652], encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690 [ITU.X690.2015]. The CMS structure MUST contain content conforming to the YANG module specified in Section 6.3.
传输的信息工件是[RFC5652]中描述的加密消息语法（CMS）结构，使用ITU-T X.690[ITU.X690.2015]中规定的ASN.1可分辨编码规则（DER）进行编码。CMS结构必须包含符合第6.3节规定的内容。
The conveyed information CMS structure may encode signed or unsigned bootstrapping data. When the bootstrapping data is signed, it may also be encrypted, but from a terminology perspective, it is still "signed data"; see Section 1.2.
传输的信息CMS结构可以对有符号或无符号引导数据进行编码。当引导数据被签名时，它也可能被加密，但从术语的角度来看，它仍然是“签名数据”；见第1.2节。
When the conveyed information artifact is unsigned and unencrypted, as it might be when communicated over trusted channels, the CMS structure's topmost content type MUST be one of the OIDs described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON) or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing "conveyed-information" data in the expected encoding.
当传送的信息工件未签名且未加密时，就像通过可信通道传送时一样，CMS结构的最顶层内容类型必须是第10.3节中描述的OID之一（即id ct SZTPTransferedInFoxml或id ct SZTPTransferedInFojson）或OID id数据（1.2.840.113549.1.7.1）。当使用OID id数据时，编码（JSON、XML等）应该在外部进行通信。在任何一种情况下，相关内容都是八位组字符串，其中包含预期编码中的“传送信息”数据。
When the conveyed information artifact is unsigned and encrypted, as it might be when communicated over trusted channels but, for some reason, the operator wants to ensure that only the device is able to see the contents, the CMS structure's topmost content type MUST be the OID id-envelopedData (1.2.840.113549.1.7.3). Furthermore, the encryptedContentInfo's content type MUST be one of the OIDs described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON) or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing "conveyed-information" data in the expected encoding.
当传送的信息工件未经签名和加密时，就像在可信通道上传送时一样，但由于某种原因，操作员希望确保只有设备能够看到内容，CMS结构的最顶层内容类型必须是OID id envelopedData（1.2.840.113549.1.7.3）。此外，encryptedContentInfo的内容类型必须是第10.3节中描述的OID之一（即id ct SZTPTransferedInFoxml或id ct SZTPTransferedInFojson）或OID id数据（1.2.840.113549.1.7.1）。当使用OID id数据时，编码（JSON、XML等）应该在外部进行通信。在任何一种情况下，相关内容都是八位组字符串，其中包含预期编码中的“传送信息”数据。
When the conveyed information artifact is signed and unencrypted, as it might be when communicated over untrusted channels, the CMS structure's topmost content type MUST be the OID id-signedData (1.2.840.113549.1.7.2). Furthermore, the inner eContentType MUST be one of the OIDs described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON) or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content or eContent is an octet string containing "conveyed-information" data in the expected encoding.
当传送的信息工件被签名和未加密时，就像在不受信任的通道上传送时一样，CMS结构的最顶层内容类型必须是OID id signedData（1.2.840.113549.1.7.2）。此外，内部eContentType必须是第10.3节中描述的OID之一（即id ct SZTPTransferedInFoxml或id ct SZTPTransferedInFojson）或OID id数据（1.2.840.113549.1.7.1）。当使用OID id数据时，编码（JSON、XML等）应该在外部进行通信。在任何一种情况下，关联的内容或eContent都是八位字节字符串，其中包含预期编码中的“传送的信息”数据。
When the conveyed information artifact is signed and encrypted, as it might be when communicated over untrusted channels and privacy is important, the CMS structure's topmost content type MUST be the OID id-envelopedData (1.2.840.113549.1.7.3). Furthermore, the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be one of the OIDs described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding
当传输的信息工件被签名和加密时，就像在不受信任的通道上传输时一样，隐私很重要，CMS结构的最顶层内容类型必须是OID id envelopedData（1.2.840.113549.1.7.3）。此外，encryptedContentInfo的内容类型必须是OID id signedData（1.2.840.113549.1.7.2），其eContentType必须是第10.3节中描述的OID之一（即id ct SZTPTransferedInFoxml或id ct SZTPTransferedInFojson）或OID id数据（1.2.840.113549.1.7.1）。使用OID id数据时，编码
(JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content or eContent is an octet string containing "conveyed-information" data in the expected encoding.
（JSON、XML等）应进行外部通信。在任何一种情况下，关联的内容或eContent都是八位字节字符串，其中包含预期编码中的“传送的信息”数据。
The owner certificate artifact is an X.509 certificate [RFC5280] that is used to identify an "owner" (e.g., an organization). The owner certificate can be signed by any certificate authority (CA). The owner certificate MUST have no Key Usage specified, or the Key Usage MUST, at a minimum, set the "digitalSignature" bit. The values for the owner certificate's "subject" and/or "subjectAltName" are not constrained by this document.
所有者证书工件是一个X.509证书[RFC5280]，用于标识“所有者”（例如组织）。所有者证书可以由任何证书颁发机构（CA）签署。所有者证书必须没有指定密钥用法，或者密钥用法必须至少设置“digitalSignature”位。所有者证书的“主题”和/或“主题名称”的值不受本文档的约束。
The owner certificate is used by a device to verify the signature over the conveyed information artifact (Section 3.1) that the device should have also received, as described in Section 3.5. In particular, the device verifies the signature using the public key in the owner certificate over the content contained within the conveyed information artifact.
如第3.5节所述，设备使用所有者证书来验证设备本应收到的传输信息工件（第3.1节）上的签名。具体地，该设备使用所有者证书中的公钥对所传送的信息工件中包含的内容验证签名。
The owner certificate artifact is formally a CMS structure, as specified by [RFC5652], encoded using ASN.1 DER, as specified in ITU-T X.690 [ITU.X690.2015].
所有者证书工件正式为CMS结构，如[RFC5652]所规定，使用ASN.1 DER编码，如ITU-T X.690[ITU.X690.2015]所规定。
The owner certificate CMS structure MUST contain the owner certificate itself, as well as all intermediate certificates leading to the "pinned-domain-cert" certificate specified in the ownership voucher. The owner certificate artifact MAY optionally include the "pinned-domain-cert" as well.
所有者证书CMS结构必须包含所有者证书本身，以及指向所有权凭证中指定的“固定域证书”证书的所有中间证书。所有者证书工件也可以选择性地包括“固定域证书”。
In order to support devices deployed on private networks, the owner certificate CMS structure MAY also contain suitably fresh, as determined by local policy, revocation objects (e.g., Certificate Revocation Lists (CRLs) [RFC5280] and OCSP Responses [RFC6960]). Having these revocation objects stapled to the owner certificate may obviate the need for the device to have to download them dynamically using the CRL distribution point or an Online Certificate Status Protocol (OCSP) responder specified in the associated certificates.
为了支持部署在专用网络上的设备，所有者证书CMS结构还可以包含由本地策略确定的适当的新鲜撤销对象（例如，证书撤销列表（crl）[RFC5280]和OCSP响应[RFC6960]）。将这些撤销对象装订到所有者证书可以避免设备必须使用相关证书中指定的CRL分发点或在线证书状态协议（OCSP）响应器动态下载它们。
When unencrypted, the topmost content type of the owner certificate artifact's CMS structure MUST be the OID id-signedData (1.2.840.113549.1.7.2). The inner SignedData structure is the degenerate form, whereby there are no signers, that is commonly used to disseminate certificates and revocation objects.
未加密时，所有者证书工件的CMS结构的最顶层内容类型必须是OID id signedData（1.2.840.113549.1.7.2）。内部SignedData结构是退化形式，即没有签名者，通常用于分发证书和吊销对象。
When encrypted, the topmost content type of the owner certificate artifact's CMS structure MUST be the OID id-envelopedData
加密后，所有者证书工件的CMS结构的最顶层内容类型必须是OID id envelopedData
(1.2.840.113549.1.7.3), and the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whereby the inner SignedData structure is the degenerate form that has no signers commonly used to disseminate certificates and revocation objects.
（1.2.840.113549.1.7.3），encryptedContentInfo的内容类型必须是OID id signedData（1.2.840.113549.1.7.2），其中内部signedData结构是退化形式，没有通常用于分发证书和吊销对象的签名者。
The ownership voucher artifact is used to securely identify a device's owner, as it is known to the manufacturer. The ownership voucher is signed by the device's manufacturer.
所有权凭证工件用于安全地标识设备的所有者，这是制造商所知道的。所有权凭证由设备制造商签字。
The ownership voucher is used to verify the owner certificate (Section 3.2) that the device should have also received, as described in Section 3.5. In particular, the device verifies that the owner certificate has a chain of trust leading to the trusted certificate included in the ownership voucher ("pinned-domain-cert"). Note that this relationship holds even when the owner certificate is a self-signed certificate and hence also the pinned-domain-cert.
所有权凭证用于验证设备也应收到的所有者证书（第3.2节），如第3.5节所述。具体而言，设备验证所有者证书是否具有导致所有权凭证中包括的受信任证书（“固定域证书”）的信任链。请注意，即使所有者证书是自签名证书，因此也是pinned-domain-cert，此关系仍然有效。
When unencrypted, the ownership voucher artifact is as defined in [RFC8366]. As described, it is a CMS structure whose topmost content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding.
未加密时，所有权凭证工件如[RFC8366]中所定义。如上所述，它是一种CMS结构，其最顶端的内容类型必须是OID id signedData（1.2.840.113549.1.7.2），其eContentType必须是OID id ct Animajson凭单（1.2.840.113549.1.9.16.1）或OID id数据（1.2.840.113549.1.7.1）。当使用OID id数据时，编码（JSON、XML等）应该在外部进行通信。在任何一种情况下，关联的内容都是八位字节字符串，其中包含预期编码的ietf凭证数据。
When encrypted, the topmost content type of the ownership voucher artifact's CMS structure MUST be the OID id-envelopedData (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding.
加密时，所有权凭证工件的CMS结构的最顶层内容类型必须是OID id envelopedData（1.2.840.113549.1.7.3），encryptedContentInfo的内容类型必须是OID id signedData（1.2.840.113549.1.7.2），其eContentType必须是OID id ct AnimajsonToucher（1.2.840.113549.1.9.16.1）或OID id数据（1.2.840.113549.1.7.1）。当使用OID id数据时，编码（JSON、XML等）应在外部进行通信。在任何一种情况下，相关内容都是八位字节字符串，包含预期编码的ietf凭证数据。
Each of the three artifacts MAY be individually encrypted. Encryption may be important in some environments where the content is considered sensitive.
三个工件中的每一个都可以单独加密。在某些内容被视为敏感的环境中，加密可能很重要。
Each of the three artifacts are encrypted in the same way, by the unencrypted form being encapsulated inside a CMS EnvelopedData type.
三个工件中的每一个都以相同的方式进行加密，未加密的表单被封装在CMS EnvelopedData类型中。
As a consequence, both the conveyed information and ownership voucher artifacts are signed and then encrypted; they are never encrypted and then signed.
因此，传输的信息和所有权凭证工件都被签名然后加密；它们从不加密然后签名。
This sequencing has the following advantages: shrouding the signer's certificate and ensuring that the owner knows the content being signed. This sequencing further enables the owner to inspect an unencrypted voucher obtained from a manufacturer and then encrypt the voucher later themselves, perhaps while also stapling in current revocation objects, when ready to place the artifact in an unsafe location.
这种排序具有以下优点：隐藏签名者的证书并确保所有者知道要签名的内容。这种排序进一步使所有者能够检查从制造商处获得的未加密凭证，然后自己对凭证进行加密，可能在准备将工件放置在不安全的位置时，还绑定在当前吊销对象中。
When encrypted, the CMS MUST be encrypted using a secure device identity certificate for the device. This certificate MAY be the same as the TLS-level client certificate the device uses when connecting to bootstrap servers. The owner must possess the device's identity certificate at the time of encrypting the data. How the owner comes to posses the device's identity certificate for this purpose is outside the scope of this document.
加密后，必须使用设备的安全设备身份证书对CMS进行加密。此证书可能与设备连接到引导服务器时使用的TLS级别客户端证书相同。在加密数据时，所有者必须拥有设备的身份证书。所有者为此目的持有设备的身份证书的方式不在本文档的范围内。
The previous sections discussed the bootstrapping artifacts, but only certain groupings of these artifacts make sense to return in the various bootstrapping situations described in this document. These groupings are:
前面的部分讨论了引导工件，但只有这些工件的某些分组在本文档中描述的各种引导情况下返回才有意义。这些组别包括：
Unsigned Data: This artifact grouping is useful for cases when transport-level security can be used to convey trust (e.g., HTTPS) or when the conveyed information can be processed in a provisional manner (i.e., unsigned redirect information).
未签名数据：当传输级安全性可用于传递信任（例如HTTPS）或当传递的信息可临时处理（例如，未签名重定向信息）时，此工件分组非常有用。
Signed Data, without revocations: This artifact grouping is useful when signed data is needed (i.e., because the data is obtained from an untrusted source and it cannot be processed provisionally) and revocations either are not needed or can be obtained dynamically.
签名数据，无撤销：当需要签名数据（即，因为数据来自不受信任的源，无法临时处理）且撤销不需要或可以动态获得时，此工件分组非常有用。
Signed Data, with revocations: This artifact grouping is useful when signed data is needed (i.e., because the data is obtained from an untrusted source and it cannot be processed provisionally) and when revocations are needed but the revocations cannot be obtained dynamically.
带撤销的签名数据：当需要签名数据时（即，因为数据是从不受信任的源获得的，不能临时处理），以及当需要撤销但无法动态获得撤销时，此工件分组非常有用。
The presence of each artifact and any distinguishing characteristics are identified for each artifact grouping in the table below ("yes" and "no" indicate whether or not the artifact is present in the artifact grouping):
下表中为每个工件分组确定了每个工件的存在和任何区别特征（“是”和“否”表示工件分组中是否存在工件）：
+---------------------+---------------+--------------+--------------+
| Artifact | Conveyed | Ownership | Owner |
| Grouping | Information | Voucher | Certificate |
+=====================+===============+==============+==============+
| Unsigned Data | Yes, no sig | No | No |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, without | Yes, without |
| without revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, with | Yes, with |
| with revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
+---------------------+---------------+--------------+--------------+
| Artifact | Conveyed | Ownership | Owner |
| Grouping | Information | Voucher | Certificate |
+=====================+===============+==============+==============+
| Unsigned Data | Yes, no sig | No | No |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, without | Yes, without |
| without revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, with | Yes, with |
| with revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
This section defines some sources for bootstrapping data that a device can access. The list of sources defined here is not meant to be exhaustive. It is left to future documents to define additional sources for obtaining bootstrapping data.
本节定义了一些设备可以访问的引导数据源。此处定义的来源列表并非详尽无遗。定义用于获取引导数据的其他源将留给未来的文档。
For each source of bootstrapping data defined in this section, details are given for how the three artifacts listed in Section 3 are provided.
对于本节中定义的每个引导数据源，将详细介绍如何提供第3节中列出的三个工件。
A directly attached removable storage device (e.g., a USB flash drive) MAY be used as a source of SZTP bootstrapping data.
可将直接连接的可移动存储设备（例如USB闪存驱动器）用作SZTP引导数据源。
Use of a removable storage device is compelling, as it does not require any external infrastructure to work. It is notable that the raw boot image file can also be located on the removable storage device, enabling a removable storage device to be a fully self-standing bootstrapping solution.
使用可移动存储设备很有吸引力，因为它不需要任何外部基础设施即可工作。值得注意的是，原始引导映像文件也可以位于可移动存储设备上，从而使可移动存储设备成为完全独立的引导解决方案。
To use a removable storage device as a source of bootstrapping data, a device need only detect if the removable storage device is plugged in and mount its filesystem.
要将可移动存储设备用作引导数据源，设备只需检测可移动存储设备是否已插入并装入其文件系统。
A removable storage device is an untrusted source of bootstrapping data. This means that the information stored on the removable storage device either MUST be signed or MUST be information that can be processed provisionally (e.g., unsigned redirect information).
可移动存储设备是不受信任的引导数据源。这意味着存储在可移动存储设备上的信息要么必须经过签名，要么必须是可以临时处理的信息（例如，未签名的重定向信息）。
From an artifact perspective, since a removable storage device presents itself as a filesystem, the bootstrapping artifacts need to be presented as files. The three artifacts defined in Section 3 are mapped to files below.
从工件的角度来看，由于可移动存储设备将自身呈现为文件系统，因此引导工件需要呈现为文件。第3节中定义的三个工件映射到下面的文件。
Artifact to File Mapping:
工件到文件的映射：
Conveyed Information: Mapped to a file containing the binary artifact described in Section 3.1 (e.g., conveyed-information.cms).
传送信息：映射到包含第3.1节所述二进制工件的文件（例如，传送信息.cms）。
Owner Certificate: Mapped to a file containing the binary artifact described in Section 3.2 (e.g., owner-certificate.cms).
所有者证书：映射到包含第3.2节中描述的二进制工件的文件（例如，Owner Certificate.cms）。
Ownership Voucher: Mapped to a file containing the binary artifact described in Section 3.3 (e.g., ownership-voucher.cms or ownership-voucher.vcj).
所有权凭证：映射到包含第3.3节中描述的二进制工件的文件（例如，Ownership-Voucher.cms或Ownership-Voucher.vcj）。
The format of the removable storage device's filesystem and the naming of the files are outside the scope of this document. However, in order to facilitate interoperability, it is RECOMMENDED that devices support open and/or standards-based filesystems. It is also RECOMMENDED that devices assume a file naming convention that enables more than one instance of bootstrapping data (i.e., for different devices) to exist on a removable storage device. The file naming convention SHOULD additionally be unique to the manufacturer, in order to enable bootstrapping data from multiple manufacturers to exist on a removable storage device.
可移动存储设备文件系统的格式和文件的命名不在本文档的范围内。但是，为了促进互操作性，建议设备支持开放和/或基于标准的文件系统。还建议设备采用文件命名约定，允许可移动存储设备上存在多个引导数据实例（即，对于不同设备）。此外，文件命名约定对于制造商来说应该是唯一的，以便能够在可移动存储设备上存在来自多个制造商的引导数据。
A DNS server MAY be used as a source of SZTP bootstrapping data.
DNS服务器可用作SZTP引导数据源。
Using a DNS server may be a compelling option for deployments having existing DNS infrastructure, as it enables a touchless bootstrapping option that does not entail utilizing an Internet-based resource hosted by a third party.
对于具有现有DNS基础设施的部署，使用DNS服务器可能是一个令人信服的选项，因为它支持非接触式引导选项，而不需要使用由第三方托管的基于Internet的资源。
DNS is an untrusted source of bootstrapping data. Even if DNSSEC [RFC6698] is used to authenticate the various DNS resource records (e.g., A, AAAA, CERT, TXT, and TLSA), the device cannot be sure that the domain returned to it, e.g., from a DHCP server, belongs to its rightful owner. This means that the information stored in the DNS records either MUST be signed (per this document, not DNSSEC) or MUST be information that can be processed provisionally (e.g., unsigned redirect information).
DNS是不受信任的引导数据源。即使DNSSEC[RFC6698]用于验证各种DNS资源记录（例如，A、AAAA、CERT、TXT和TLSA），设备也无法确保返回给它的域（例如，从DHCP服务器返回的域）属于其合法所有者。这意味着存储在DNS记录中的信息必须经过签名（根据本文档，而不是DNSSEC），或者必须是可以临时处理的信息（例如，未签名的重定向信息）。
Devices claiming to support DNS as a source of bootstrapping data MUST first query for device-specific DNS records and then, only if doing so does not result in a successful bootstrap, MUST query for device-independent DNS records.
声称支持DNS作为引导数据源的设备必须首先查询特定于设备的DNS记录，然后，仅当这样做不会导致成功引导时，必须查询独立于设备的DNS记录。
For each of the device-specific and device-independent queries, devices MUST first query using multicast DNS [RFC6762] and then, only if doing so does not result in a successful bootstrap, MUST query again using unicast DNS [RFC1035] [RFC7766]. This assumes the address of a DNS server is known, such as it may be using techniques similar to those described in Section 11 of [RFC6763].
对于每个特定于设备和独立于设备的查询，设备必须首先使用多播DNS[RFC6762]进行查询，然后，仅当这样做不会导致成功引导时，才必须使用单播DNS[RFC1035][RFC7766]再次进行查询。这假设DNS服务器的地址是已知的，例如它可能使用与[RFC6763]第11节中描述的技术类似的技术。
When querying for device-specific DNS records, devices MUST query for TXT records [RFC1035] under "<serial-number>._sztp", where <serial-number> is the device's serial number (the same value as in the device's secure device identity certificate), and "_sztp" is the globally scoped DNS attribute registered per this document (see Section 10.7).
查询特定于设备的DNS记录时，设备必须在“<serial number>”下查询TXT记录[RFC1035]，其中<serial number>是设备的序列号（与设备的安全设备标识证书中的值相同），“\u sztp”是根据本文档注册的全局范围DNS属性（见第10.7节）。
Example device-specific DNS record queries:
特定于设备的DNS记录查询示例：
TXT in <serial-number>._sztp.local. (multicast)
TXT in <serial-number>._sztp.<domain>. (unicast)
TXT in <serial-number>._sztp.local. (multicast)
TXT in <serial-number>._sztp.<domain>. (unicast)
When querying for device-independent DNS records, devices MUST query for SRV records [RFC2782] under "_sztp._tcp", where "_sztp" is the service name registered per this document (see Section 10.6), and "_tcp" is the globally scoped DNS attribute registered per [RFC8552].
查询独立于设备的DNS记录时，设备必须在“_sztp._tcp”下查询SRV记录[RFC2782]，其中“_sztp”是根据本文档注册的服务名称（参见第10.6节），“_tcp”是根据[RFC8552]注册的全局范围的DNS属性。
Note that a device-independent response is only able to encode unsigned data anyway, since signed data necessitates the use of a device-specific ownership voucher. Use of SRV records maximumly leverages existing DNS standards. A response containing multiple SRV records is comparable to an unsigned redirect information's list of bootstrap servers.
请注意，独立于设备的响应无论如何只能对未签名的数据进行编码，因为签名的数据需要使用特定于设备的所有权凭证。SRV记录的使用最大限度地利用了现有的DNS标准。包含多个SRV记录的响应相当于未签名重定向信息的引导服务器列表。
Example device-independent DNS record queries:
与设备无关的DNS记录查询示例：
SRV in _sztp._tcp.local. (multicast) SRV in _sztp._tcp.<domain>. (unicast)
SRV在_sztp._tcp.local中。（多播）SRV在_sztp._tcp.<domain>中。（单播）
For device-specific queries, the three bootstrapping artifacts defined in Section 3 are encoded into the TXT records using key/value pairs, similar to the technique described in Section 6.3 of [RFC6763].
对于特定于设备的查询，第3节中定义的三个引导工件使用键/值对编码到TXT记录中，类似于[RFC6763]第6.3节中描述的技术。
Artifact to TXT Record Mapping:
工件到TXT记录的映射：
Conveyed Information: Mapped to a TXT record having the key "ci" and the value being the binary artifact described in Section 3.1.
传递的信息：映射到一个TXT记录，该记录的键为“ci”，值为第3.1节中描述的二进制工件。
Owner Certificate: Mapped to a TXT record having the key "oc" and the value being the binary artifact described in Section 3.2.
所有者证书：映射到一个TXT记录，其密钥为“oc”，值为第3.2节中描述的二进制工件。
Ownership Voucher: Mapped to a TXT record having the key "ov" and the value being the binary artifact described in Section 3.3.
所有权凭证：映射到一个TXT记录，其键为“ov”，值为第3.3节中描述的二进制工件。
Devices MUST ignore any other keys that may be returned.
设备必须忽略可能返回的任何其他密钥。
Note that, despite the name, TXT records can and SHOULD (per Section 6.5 of [RFC6763]) encode binary data.
注意，尽管名称不同，TXT记录可以也应该（根据[RFC6763]第6.5节）对二进制数据进行编码。
Following is an example of a device-specific response, as it might be presented by a user agent, containing signed data. This example assumes that the device's serial number is "<serial-number>", the domain is "example.com", and "<binary data>" represents the binary artifact:
以下是特定于设备的响应示例，可能由用户代理显示，其中包含签名数据。本例假设设备的序列号为“<serial number>”，域为“example.com”，并且“<binary data>”表示二进制工件：
<serial-number>._sztp.example.com. 3600 IN TXT "ci=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "oc=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "ov=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "ci=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "oc=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "ov=<binary data>"
Note that, in the case that "ci" encodes unsigned data, the "oc" and "ov" keys would not be present in the response.
注意，在“ci”编码无符号数据的情况下，“oc”和“ov”键不会出现在响应中。
For device-independent queries, the three bootstrapping artifacts defined in Section 3 are encoded into the SVR records as follows.
对于独立于设备的查询，第3节中定义的三个引导工件被编码到SVR记录中，如下所示。
Artifact to SRV Record Mapping:
工件到SRV记录映射：
Conveyed Information: This artifact is not supported directly. Instead, the essence of unsigned redirect information is mapped to SVR records per [RFC2782].
传达的信息：不直接支持此工件。相反，根据[RFC2782]，未签名重定向信息的本质映射到SVR记录。
Owner Certificate: Not supported. Device-independent responses never encode signed data; hence, there is no need for an owner certificate artifact.
所有者证书：不支持。与设备无关的响应从不对签名数据进行编码；因此，不需要所有者证书工件。
Ownership Voucher: Not supported. Device-independent responses never encode signed data; hence, there is no need for an ownership voucher artifact.
所有权凭证：不支持。与设备无关的响应从不对签名数据进行编码；因此，不需要所有权凭证工件。
Following is an example of a device-independent response, as it might be presented by a user agent, containing (effectively) unsigned redirect information to four bootstrap servers. This example assumes that the domain is "example.com" and that there are four bootstrap servers "sztp[1-4]":
下面是一个与设备无关的响应示例，它可能由用户代理提供，包含（有效地）到四个引导服务器的未签名重定向信息。本例假设域为“example.com”，并且有四个引导服务器“sztp[1-4]”：
_sztp._tcp.example.com. 1800 IN SRV 0 0 443 sztp1.example.com. _sztp._tcp.example.com. 1800 IN SRV 1 0 443 sztp2.example.com. _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp3.example.com. _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp4.example.com.
_sztp._tcp.example.com。SRV 0 0 443 sztp1.example.com中的1800_sztp._tcp.example.com。SRV 1 0 443 sztp2.example.com中的1800_sztp._tcp.example.com。SRV 2 0 443 sztp3.example.com中的1800_sztp._tcp.example.com。SRV 2 0 443 sztp4.example.com中的1800。
Note that, in this example, "sztp3" and "sztp4" have equal priority and hence effectively represent a clustered pair of bootstrap servers. While "sztp1" and "sztp2" only have a single SRV record each, it may be that the record points to a load balancer fronting a cluster of bootstrap servers.
注意，在本例中，“sztp3”和“sztp4”具有相同的优先级，因此有效地表示一对集群引导服务器。虽然“sztp1”和“sztp2”各自只有一条SRV记录，但可能是该记录指向引导服务器集群前面的负载平衡器。
While this document does not use DNS-SD [RFC6763], per Section 12.2 of that RFC, Multicast DNS (mDNS) responses SHOULD also include all address records (type "A" and "AAAA") named in the SRV rdata.
虽然本文件未使用DNS-SD[RFC6763]，但根据该RFC第12.2节，多播DNS（MDN）响应还应包括SRV rdata中命名的所有地址记录（类型“A”和“AAAA”）。
The signed data artifacts are large by DNS conventions. In the smallest-footprint scenario, they are each a few kilobytes in size. However, onboarding information can easily be several kilobytes in size and has the potential to be many kilobytes in size.
根据DNS约定，签名数据工件很大。在占用空间最小的情况下，它们的大小都只有几千字节。但是，入职信息的大小很容易达到几千字节，并且可能达到几千字节。
All resource records, including TXT records, have an upper size limit of 65535 bytes, since "RDLENGTH" is a 16-bit field (Section 3.2.1 of [RFC1035]). If it is ever desired to encode onboarding information that exceeds this limit, the DNS records returned should instead encode redirect information, to direct the device to a bootstrap server from which the onboarding information can be obtained.
所有资源记录（包括TXT记录）的大小上限为65535字节，因为“RDLENGTH”是一个16位字段（见[RFC1035]第3.2.1节）。如果需要对超过此限制的入职信息进行编码，则返回的DNS记录应改为对重定向信息进行编码，以将设备定向到可从中获取入职信息的引导服务器。
Given the expected size of the TXT records, it is unlikely that signed data will fit into a UDP-based DNS packet, even with the Extension Mechanisms for DNS (EDNS(0)) extensions [RFC6891] enabled. Depending on content, signed data may also not fit into a multicast DNS packet, which bounds the size to 9000 bytes, per Section 17 of
鉴于TXT记录的预期大小，即使启用了DNS（EDNS（0））扩展[RFC6891]的扩展机制，签名数据也不太可能适合基于UDP的DNS数据包。根据内容的不同，签名数据也可能不适合多播DNS数据包，该数据包根据第17节将大小限制为9000字节
[RFC6762]. Thus, it is expected that DNS Transport over TCP [RFC7766] will be required in order to return signed data.
[RFC6762]。因此，预计需要通过TCP[RFC7766]进行DNS传输才能返回签名数据。
A DHCP server MAY be used as a source of SZTP bootstrapping data.
DHCP服务器可用作SZTP引导数据源。
Using a DHCP server may be a compelling option for deployments having existing DHCP infrastructure, as it enables a touchless bootstrapping option that does not entail utilizing an Internet-based resource hosted by a third party.
对于具有现有DHCP基础设施的部署，使用DHCP服务器可能是一个令人信服的选项，因为它支持非接触式引导选项，而不需要使用第三方托管的基于Internet的资源。
A DHCP server is an untrusted source of bootstrapping data. Thus, the information stored on the DHCP server either MUST be signed or MUST be information that can be processed provisionally (e.g., unsigned redirect information).
DHCP服务器是不受信任的引导数据源。因此，存储在DHCP服务器上的信息要么必须经过签名，要么必须是可以临时处理的信息（例如，未签名的重定向信息）。
However, unlike other sources of bootstrapping data described in this document, the DHCP protocol (especially DHCP for IPv4) is very limited in the amount of data that can be conveyed, to the extent that signed data cannot be communicated. This means that only unsigned redirect information can be conveyed via DHCP.
但是，与本文档中描述的其他引导数据源不同，DHCP协议（尤其是用于IPv4的DHCP）在可传输的数据量方面非常有限，以至于无法传输签名数据。这意味着只有未签名的重定向信息才能通过DHCP传输。
Since the redirect information is unsigned, it SHOULD NOT include the optional trust anchor certificate, as it takes up space in the DHCP message, and the device would have to discard it anyway. For this reason, the DHCP options defined in Section 8 do not enable the trust anchor certificate to be encoded.
因为重定向信息是未签名的，所以它不应该包括可选的信任锚证书，因为它会占用DHCP消息中的空间，并且设备无论如何都必须放弃它。因此，第8节中定义的DHCP选项不允许对信任锚证书进行编码。
From an artifact perspective, the three artifacts defined in Section 3 are mapped to the DHCP fields specified in Section 8 as follows.
从工件的角度来看，第3节中定义的三个工件映射到第8节中指定的DHCP字段，如下所示。
Artifact to DHCP Option Fields Mapping:
工件到DHCP选项字段映射：
Conveyed Information: This artifact is not supported directly. Instead, the essence of unsigned redirect information is mapped to the DHCP options described in Section 8.
传达的信息：不直接支持此工件。相反，未签名重定向信息的本质映射到第8节中描述的DHCP选项。
Owner Certificate: Not supported. There is not enough space in the DHCP packet to hold an owner certificate artifact.
所有者证书：不支持。DHCP数据包中没有足够的空间来保存所有者证书工件。
Ownership Voucher: Not supported. There is not enough space in the DHCP packet to hold an ownership voucher artifact.
所有权凭证：不支持。DHCP数据包中没有足够的空间来保存所有权凭证工件。
A bootstrap server MAY be used as a source of SZTP bootstrapping data. A bootstrap server is defined as a RESTCONF [RFC8040] server implementing the YANG module provided in Section 7.
引导服务器可用作SZTP引导数据源。引导服务器定义为一个RESTCONF[RFC8040]服务器，实现第7节中提供的YANG模块。
Using a bootstrap server as a source of bootstrapping data is a compelling option as it MAY use transport-level security, obviating the need for signed data, which may be easier to deploy in some situations.
使用引导服务器作为引导数据源是一个引人注目的选择，因为它可以使用传输级别的安全性，避免了对签名数据的需要，在某些情况下，签名数据可能更易于部署。
Unlike any other source of bootstrapping data described in this document, a bootstrap server is not only a source of data, but it can also receive data from devices using the YANG-defined "report-progress" RPC defined in the YANG module provided in Section 7.3. The "report-progress" RPC enables visibility into the bootstrapping process (e.g., warnings and errors) and provides potentially useful information upon completion (e.g., the device's Secure Shell (SSH) host keys and/or TLS trust anchor certificates).
与本文档中描述的任何其他引导数据源不同，引导服务器不仅是数据源，还可以使用第7.3节提供的YANG模块中定义的YANG定义的“报告进度”RPC从设备接收数据。“报告进度”RPC允许查看引导过程（例如警告和错误），并在完成时提供潜在有用的信息（例如，设备的安全外壳（SSH）主机密钥和/或TLS信任锚证书）。
A bootstrap server may be a trusted or an untrusted source of bootstrapping data, depending on if the device learned about the bootstrap server's trust anchor from a trusted source. When a bootstrap server is trusted, the conveyed information returned from it MAY be signed. When the bootstrap server is untrusted, the conveyed information either MUST be signed or MUST be information that can be processed provisionally (e.g., unsigned redirect information).
引导服务器可能是受信任的或不受信任的引导数据源，这取决于设备是否从受信任的源了解到引导服务器的信任锚。当引导服务器受信任时，可以对从其返回的传递信息进行签名。当引导服务器不受信任时，传递的信息必须经过签名，或者必须是可以临时处理的信息（例如，未签名的重定向信息）。
From an artifact perspective, since a bootstrap server presents data conforming to a YANG data model, the bootstrapping artifacts need to be mapped to YANG nodes. The three artifacts defined in Section 3 are mapped to "output" nodes of the "get-bootstrapping-data" RPC defined in Section 7.3.
从工件的角度来看，由于引导服务器提供符合YANG数据模型的数据，因此引导工件需要映射到YANG节点。第3节中定义的三个工件映射到第7.3节中定义的“获取引导数据”RPC的“输出”节点。
Artifact to Bootstrap Server Mapping:
工件到引导服务器的映射：
Conveyed Information: Mapped to the "conveyed-information" leaf in the output of the "get-bootstrapping-data" RPC.
传送的信息：映射到“获取引导数据”RPC输出中的“传送的信息”叶。
Owner Certificate: Mapped to the "owner-certificate" leaf in the output of the "get-bootstrapping-data" RPC.
所有者证书：映射到“获取引导数据”RPC输出中的“所有者证书”叶。
Ownership Voucher: Mapped to the "ownership-voucher" leaf in the output of the "get-bootstrapping-data" RPC.
所有权凭证：映射到“获取引导数据”RPC输出中的“所有权凭证”叶。
SZTP bootstrap servers have only two endpoints: one for the "get-bootstrapping-data" RPC and one for the "report-progress" RPC.
SZTP引导服务器只有两个端点：一个用于“获取引导数据”RPC，另一个用于“报告进度”RPC。
These RPCs use the authenticated RESTCONF username to isolate the execution of the RPC from other devices.
这些RPC使用经过身份验证的RESTCONF用户名将RPC的执行与其他设备隔离。
Devices supporting the bootstrapping strategy described in this document MUST have the pre-configured state and bootstrapping logic described in the following sections.
支持本文档中描述的引导策略的设备必须具有以下部分中描述的预配置状态和引导逻辑。
+-------------------------------------------------------------+
| <device> |
| |
| +---------------------------------------------------------+ |
| | <read/write storage> | |
| | | |
| | 1. flag to enable SZTP bootstrapping set to "true" | |
| +---------------------------------------------------------+ |
| |
| +---------------------------------------------------------+ |
| | <read-only storage> | |
| | | |
| | 2. TLS client cert & related intermediate certificates | |
| | 3. list of trusted well-known bootstrap servers | |
| | 4. list of trust anchor certs for bootstrap servers | |
| | 5. list of trust anchor certs for ownership vouchers | |
| +---------------------------------------------------------+ |
| |
| +-----------------------------------------------------+ |
| | <secure storage> | |
| | | |
| | 6. private key for TLS client certificate | |
| | 7. private key for decrypting SZTP artifacts | |
| +-----------------------------------------------------+ |
| |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| <device> |
| |
| +---------------------------------------------------------+ |
| | <read/write storage> | |
| | | |
| | 1. flag to enable SZTP bootstrapping set to "true" | |
| +---------------------------------------------------------+ |
| |
| +---------------------------------------------------------+ |
| | <read-only storage> | |
| | | |
| | 2. TLS client cert & related intermediate certificates | |
| | 3. list of trusted well-known bootstrap servers | |
| | 4. list of trust anchor certs for bootstrap servers | |
| | 5. list of trust anchor certs for ownership vouchers | |
| +---------------------------------------------------------+ |
| |
| +-----------------------------------------------------+ |
| | <secure storage> | |
| | | |
| | 6. private key for TLS client certificate | |
| | 7. private key for decrypting SZTP artifacts | |
| +-----------------------------------------------------+ |
| |
+-------------------------------------------------------------+
Each numbered item below corresponds to a numbered item in the diagram above.
下面的每个编号项目对应于上图中的一个编号项目。
1. Devices MUST have a configurable variable that is used to enable/ disable SZTP bootstrapping. This variable MUST be enabled by default in order for SZTP bootstrapping to run when the device first powers on. Because it is a goal that the configuration installed by the bootstrapping process disables SZTP bootstrapping, and because the configuration may be merged into the existing configuration, using a configuration node that
1. 设备必须具有用于启用/禁用SZTP引导的可配置变量。默认情况下，必须启用此变量，才能在设备首次通电时运行SZTP引导。因为目标是引导过程安装的配置禁用SZTP引导，并且因为可以使用以下配置节点将配置合并到现有配置中：
relies on presence is NOT RECOMMENDED, as it cannot be removed by the merging process.
不建议使用依赖状态，因为合并过程无法删除它。
2. Devices that support loading bootstrapping data from bootstrap servers (see Section 4.4) SHOULD possess a TLS-level client certificate and any intermediate certificates leading to the certificate's well-known trust anchor. The well-known trust anchor certificate may be an intermediate certificate or a self-signed root certificate. To support devices not having a client certificate, devices MAY, alternatively or in addition to, identify and authenticate themselves to the bootstrap server using an HTTP authentication scheme, as allowed by Section 2.5 of [RFC8040]; however, this document does not define a mechanism for operator input enabling, for example, the entering of a password.
2. 支持从引导服务器加载引导数据的设备（请参见第4.4节）应具有TLS级别的客户端证书和指向该证书众所周知的信任锚的任何中间证书。众所周知的信任锚证书可以是中间证书或自签名根证书。为了支持没有客户机证书的设备，设备可以使用[RFC8040]第2.5节允许的HTTP身份验证方案，或者除此之外，向引导服务器标识和验证自己；但是，本文档未定义操作员输入的机制，例如，允许输入密码。
3. Devices that support loading bootstrapping data from well-known bootstrap servers MUST possess a list of the well-known bootstrap servers. Consistent with redirect information (Section 2.1), each bootstrap server can be identified by its hostname or IP address and an optional port.
3. 支持从已知引导服务器加载引导数据的设备必须具有已知引导服务器的列表。与重定向信息（第2.1节）一致，每个引导服务器都可以通过其主机名或IP地址以及可选端口进行标识。
4. Devices that support loading bootstrapping data from well-known bootstrap servers MUST also possess a list of trust anchor certificates that can be used to authenticate the well-known bootstrap servers. For each trust anchor certificate, if it is not itself a self-signed root certificate, the device SHOULD also possess the chain of intermediate certificates leading up to and including the self-signed root certificate.
4. 支持从已知引导服务器加载引导数据的设备还必须具有可用于验证已知引导服务器的信任锚证书列表。对于每个信任锚证书，如果其本身不是自签名根证书，则设备还应拥有指向并包括自签名根证书的中间证书链。
5. Devices that support loading signed data (see Section 1.2) MUST possess the trust anchor certificates for validating ownership vouchers. For each trust anchor certificate, if it is not itself a self-signed root certificate, the device SHOULD also possess the chain of intermediate certificates leading up to and including the self-signed root certificate.
5. 支持加载签名数据的设备（参见第1.2节）必须拥有用于验证所有权凭证的信任锚证书。对于每个信任锚证书，如果其本身不是自签名根证书，则设备还应拥有指向并包括自签名根证书的中间证书链。
6. Devices that support using a TLS-level client certificate to identify and authenticate themselves to a bootstrap server MUST possess the private key that corresponds to the public key encoded in the TLS-level client certificate. This private key SHOULD be securely stored, ideally in a cryptographic processor, such as a trusted platform module (TPM) chip.
6. 支持使用TLS级别客户端证书来识别和向引导服务器验证自身的设备必须拥有与TLS级别客户端证书中编码的公钥相对应的私钥。该私钥应该安全地存储，最好是存储在加密处理器中，如可信平台模块（TPM）芯片。
7. Devices that support decrypting SZTP artifacts MUST posses the private key that corresponds to the public key encoded in the secure device identity certificate used when encrypting the artifacts. This private key SHOULD be securely stored, ideally in a cryptographic processor, such as a trusted platform module
7. 支持解密SZTP工件的设备必须拥有与加密工件时使用的安全设备标识证书中编码的公钥相对应的私钥。该私钥应该安全地存储，理想情况下存储在加密处理器中，如可信平台模块
(TPM) chip. This private key MAY be the same as the one associated to the TLS-level client certificate used when connecting to bootstrap servers.
（TPM）芯片。此私钥可能与连接到引导服务器时使用的与TLS级别客户端证书关联的私钥相同。
A YANG module representing this data is provided in Appendix A.
附录A中提供了表示该数据的模块。
A device claiming to support the bootstrapping strategy defined in this document MUST support the boot sequence described in this section.
声称支持本文档中定义的引导策略的设备必须支持本节中描述的引导顺序。
Power On
|
v No
1. SZTP bootstrapping configured ------> Boot normally
|
| Yes
v
2. For each supported source of bootstrapping data,
try to load bootstrapping data from the source
|
|
v Yes
3. Able to bootstrap from any source? -----> Run with new config
|
| No
v
4. Loop back to Step 1
Power On
|
v No
1. SZTP bootstrapping configured ------> Boot normally
|
| Yes
v
2. For each supported source of bootstrapping data,
try to load bootstrapping data from the source
|
|
v Yes
3. Able to bootstrap from any source? -----> Run with new config
|
| No
v
4. Loop back to Step 1
Note: At any time, the device MAY be configured via an alternate provisioning mechanism (e.g., command-line interface (CLI)).
注意：设备可随时通过备用配置机制（例如，命令行界面（CLI））进行配置。
Each numbered item below corresponds to a numbered item in the diagram above.
下面的每个编号项目对应于上图中的一个编号项目。
1. When the device powers on, it first checks to see if SZTP bootstrapping is configured, as is expected to be the case for the device's pre-configured initial state. If SZTP bootstrapping is not configured, then the device boots normally.
1. 当设备通电时，它首先检查是否配置了SZTP引导，这与设备预配置初始状态的情况相同。如果未配置SZTP引导，则设备将正常引导。
2. The device iterates over its list of sources for bootstrapping data (Section 4). Details for how to process a source of bootstrapping data are provided in Section 5.3.
2. 设备迭代其引导数据源列表（第4节）。第5.3节提供了有关如何处理引导数据源的详细信息。
3. If the device is able to bootstrap itself from any of the sources of bootstrapping data, it runs with the new bootstrapped configuration.
3. 如果设备能够从任何引导数据源引导自身，则它将使用新的引导配置运行。
4. Otherwise, the device MUST loop back through the list of bootstrapping sources again.
4. 否则，设备必须再次通过引导源列表进行循环。
This document does not limit the simultaneous use of alternate provisioning mechanisms. Such mechanisms may include, for instance, a CLI, a web-based user interface, or even another bootstrapping protocol. Regardless of how it is configured, the configuration SHOULD unset the flag enabling SZTP bootstrapping as discussed in Section 5.1.
本文档不限制同时使用备用资源调配机制。此类机制可包括例如CLI、基于web的用户界面或甚至另一引导协议。无论它是如何配置的，配置都应取消设置启用SZTP引导的标志，如第5.1节所述。
This section describes a recursive algorithm that devices can use to, ultimately, obtain onboarding information. The algorithm is recursive because sources of bootstrapping data may return redirect information, which causes the algorithm to run again, for the newly discovered sources of bootstrapping data. An expression that captures all possible successful sequences of bootstrapping data is: zero or more redirect information responses, followed by one onboarding information response.
本节描述了一种递归算法，设备可以使用该算法最终获取入职信息。该算法是递归的，因为对于新发现的引导数据源，引导数据源可能返回重定向信息，从而导致算法再次运行。捕获所有可能成功的引导数据序列的表达式是：零个或多个重定向信息响应，后跟一个入职信息响应。
An important aspect of the algorithm is knowing when data needs to be signed or not. The following figure provides a summary of options:
该算法的一个重要方面是知道数据何时需要签名或不需要签名。下图提供了选项摘要：
Untrusted Source Trusted Source Kind of Bootstrapping Data Can Provide? Can Provide?
不受信任的源受信任的源可以提供什么样的引导数据？你能提供什么？
Unsigned Redirect Info : Yes+ Yes
Signed Redirect Info : Yes Yes*
Unsigned Onboarding Info : No Yes
Signed Onboarding Info : Yes Yes*
Unsigned Redirect Info : Yes+ Yes
Signed Redirect Info : Yes Yes*
Unsigned Onboarding Info : No Yes
Signed Onboarding Info : Yes Yes*
The '+' above denotes that the source redirected to MUST return signed data or more unsigned redirect information.
上面的“+”表示重定向到的源必须返回有符号数据或更多无符号重定向信息。
The '*' above denotes that, while possible, it is generally unnecessary for a trusted source to return signed data.
上面的“*”表示，虽然可能，但受信任的源通常不需要返回签名数据。
The recursive algorithm uses a conceptual globally scoped variable called "trust-state". The trust-state variable is initialized to FALSE. The ultimate goal of this algorithm is for the device to process onboarding information (Section 2.2) while the trust-state variable is TRUE.
递归算法使用一个称为“信任状态”的概念性全局范围变量。信任状态变量已初始化为FALSE。该算法的最终目标是让设备在信任状态变量为真时处理入职信息（第2.2节）。
If the source of bootstrapping data (Section 4) is a bootstrap server (Section 4.4), and the device is able to authenticate the bootstrap server using X.509 certificate path validation ([RFC6125], Section 6) to one of the device's pre-configured trust anchors, or to a trust anchor that it learned from a previous step, then the device MUST set trust-state to TRUE.
如果引导数据（第4节）的源是引导服务器（第4.4节），并且设备能够使用X.509证书路径验证（[RFC6125]，第6节）对引导服务器进行身份验证，验证对象是设备的一个预配置的信任锚，或者是从上一步学到的信任锚，然后设备必须将信任状态设置为TRUE。
When establishing a connection to a bootstrap server, whether trusted or untrusted, the device MUST identify and authenticate itself to the bootstrap server using a TLS-level client certificate and/or an HTTP authentication scheme, per Section 2.5 of [RFC8040]. If both authentication mechanisms are used, they MUST both identify the same serial number.
根据[RFC8040]第2.5节，在建立与引导服务器的连接时，无论是受信任的还是不受信任的，设备都必须使用TLS级别的客户端证书和/或HTTP身份验证方案向引导服务器标识和验证自身。如果使用两种身份验证机制，则它们必须标识相同的序列号。
When sending a client certificate, the device MUST also send all of the intermediate certificates leading up to, and optionally including, the client certificate's well-known trust anchor certificate.
当发送客户机证书时，设备还必须发送所有中间证书，这些中间证书指向并可选地包括客户机证书的众所周知的信任锚证书。
For any source of bootstrapping data (e.g., Section 4), if any artifact obtained is encrypted, the device MUST first decrypt it using the private key associated with the device certificate used to encrypt the artifact.
对于任何引导数据源（例如，第4节），如果对获得的任何工件进行了加密，则设备必须首先使用与用于加密工件的设备证书相关联的私钥对其进行解密。
If the conveyed information artifact is signed, and the device is able to validate the signed data using the algorithm described in Section 5.4, then the device MUST set trust-state to TRUE; otherwise, if the device is unable to validate the signed data, the device MUST set trust-state to FALSE. Note that this is worded to cover the special case when signed data is returned even from a trusted source of bootstrapping data.
如果传送的信息工件已签名，且设备能够使用第5.4节中描述的算法验证签名数据，则设备必须将信任状态设置为TRUE；否则，如果设备无法验证已签名的数据，则设备必须将信任状态设置为FALSE。请注意，这是为了涵盖即使从受信任的引导数据源返回签名数据时的特殊情况。
If the conveyed information artifact contains redirect information, the device MUST, within limits of how many recursive loops the device allows, process the redirect information as described in Section 5.5. Implementations MUST limit the maximum number of recursive redirects allowed; the maximum number of recursive redirects allowed SHOULD be no more than ten. This is the recursion step; it will cause the device to reenter this algorithm, but this time the data source will definitely be a bootstrap server, as redirect information is only able to redirect devices to bootstrap servers.
如果传送的信息工件包含重定向信息，则设备必须在设备允许的递归循环数量限制内，按照第5.5节所述处理重定向信息。实现必须限制允许的最大递归重定向数量；允许的最大递归重定向数不应超过十个。这是递归步骤；这将导致设备重新输入此算法，但这次数据源肯定是引导服务器，因为重定向信息只能将设备重定向到引导服务器。
If the conveyed information artifact contains onboarding information, and trust-state is FALSE, the device MUST exit the recursive algorithm (as this is not allowed; see the figure above), returning to the bootstrapping sequence described in Section 5.2. Otherwise, the device MUST attempt to process the onboarding information as described in Section 5.6. Whether the processing of the onboarding
如果传送的信息工件包含入局信息，并且信任状态为FALSE，则设备必须退出递归算法（因为这是不允许的；参见上图），返回到第5.2节中描述的引导序列。否则，设备必须尝试处理第5.6节所述的入职信息。是否处理入职培训
information succeeds or fails, the device MUST exit the recursive algorithm, returning to the bootstrapping sequence described in Section 5.2; the only difference is how it responds to the "Able to bootstrap from any source?" conditional described in the figure in that section.
信息成功或失败时，设备必须退出递归算法，返回第5.2节所述的引导序列；唯一的区别是它如何响应该部分图中描述的“能够从任何源引导？”条件。
Whenever a device is presented signed data, it MUST validate the signed data as described in this section. This includes the case where the signed data is provided by a trusted source.
无论何时向设备显示签名数据，都必须按照本节所述验证签名数据。这包括签名数据由可信源提供的情况。
Whenever there is signed data, the device MUST also be provided an ownership voucher and an owner certificate. How all the needed artifacts are provided for each source of bootstrapping data is described in Section 4.
每当有签名数据时，还必须向设备提供所有权凭证和所有者证书。第4节描述了如何为每个引导数据源提供所有需要的工件。
In order to validate signed data, the device MUST first authenticate the ownership voucher by validating its signature to one of its pre-configured trust anchors (see Section 5.1), which may entail using additional intermediate certificates attached to the ownership voucher. If the device has an accurate clock, it MUST verify that the ownership voucher was created in the past (i.e., "created-on" < now), and if the "expires-on" leaf is present, the device MUST verify that the ownership voucher has not yet expired (i.e., now < "expires-on"). The device MUST verify that the ownership voucher's "assertion" value is acceptable (e.g., some devices may only accept the assertion value "verified"). The device MUST verify that the ownership voucher specifies the device's serial number in the "serial-number" leaf. If the "idevid-issuer" leaf is present, the device MUST verify that the value is set correctly. If the authentication of the ownership voucher is successful, the device extracts the "pinned-domain-cert" node, an X.509 certificate, that is needed to verify the owner certificate in the next step.
为了验证已签名的数据，设备必须首先通过验证其预配置的信任锚之一的签名来验证所有权凭证（参见第5.1节），这可能需要使用附加到所有权凭证的附加中间证书。如果设备具有准确的时钟，则必须验证所有权凭证是否在过去创建（即，“创建日期”<现在），如果“到期日期”叶存在，则设备必须验证所有权凭证是否尚未到期（即，现在<“到期日期”）。设备必须验证所有权凭证的“断言”值是否可接受（例如，某些设备可能只接受断言值“已验证”）。设备必须验证所有权凭证是否在“序列号”页中指定了设备的序列号。如果存在“idevid issuer”页，则设备必须验证该值设置是否正确。如果所有权凭证的身份验证成功，设备将提取“固定域证书”节点，即在下一步验证所有者证书所需的X.509证书。
The device MUST next authenticate the owner certificate by performing X.509 certificate path verification to the trusted certificate extracted from the ownership voucher's "pinned-domain-cert" node. This verification may entail using additional intermediate certificates attached to the owner certificate artifact. If the ownership voucher's "domain-cert-revocation-checks" node's value is set to "true", the device MUST verify the revocation status of the certificate chain used to sign the owner certificate, and if a suitably fresh revocation status is unattainable or if it is determined that a certificate has been revoked, the device MUST NOT validate the owner certificate.
设备接下来必须通过对从所有权凭证的“固定域证书”节点提取的受信任证书执行X.509证书路径验证来验证所有者证书。此验证可能需要使用附加到所有者证书工件的附加中间证书。如果所有权凭证的“域证书吊销检查”节点的值设置为“true”，则设备必须验证用于签署所有者证书的证书链的吊销状态，以及如果无法获得适当的新吊销状态，或者如果确定证书已被吊销，设备不能验证所有者证书。
Finally, the device MUST verify that the conveyed information artifact was signed by the validated owner certificate.
最后，设备必须验证传递的信息工件是否由经过验证的所有者证书签名。
If any of these steps fail, the device MUST invalidate the signed data and not perform any subsequent steps.
如果这些步骤中的任何一个失败，设备必须使签名数据无效，并且不执行任何后续步骤。
In order to process redirect information (Section 2.1), the device MUST follow the steps presented in this section.
为了处理重定向信息（第2.1节），设备必须遵循本节介绍的步骤。
Processing redirect information is straightforward; the device sequentially steps through the list of provided bootstrap servers until it can find one it can bootstrap from.
处理重定向信息很简单；设备按顺序逐步浏览提供的引导服务器列表，直到找到一个可以引导的服务器。
If a hostname is provided, and the hostname's DNS resolution is to more than one IP address, the device MUST attempt to connect to all of the DNS resolved addresses at least once, before moving on to the next bootstrap server. If the device is able to obtain bootstrapping data from any of the DNS resolved addresses, it MUST immediately process that data, without attempting to connect to any of the other DNS resolved addresses.
如果提供了主机名，并且主机名的DNS解析为多个IP地址，则设备必须尝试连接到所有DNS解析的地址至少一次，然后才能转到下一个引导服务器。如果设备能够从任何DNS解析地址获取引导数据，则必须立即处理该数据，而不尝试连接到任何其他DNS解析地址。
If the redirect information is trusted (e.g., trust-state is TRUE), and the bootstrap server entry contains a trust anchor certificate, then the device MUST authenticate the specified bootstrap server's TLS server certificate using X.509 certificate path validation ([RFC6125], Section 6) to the specified trust anchor. If the bootstrap server entry does not contain a trust anchor certificate device, the device MUST establish a provisional connection to the bootstrap server (i.e., by blindly accepting its server certificate) and set trust-state to FALSE.
如果重定向信息受信任（例如，信任状态为TRUE），并且引导服务器条目包含信任锚证书，则设备必须使用X.509证书路径验证（[RFC6125]，第6节）将指定引导服务器的TLS服务器证书验证到指定的信任锚。如果引导服务器条目不包含信任锚证书设备，则该设备必须建立到引导服务器的临时连接（即，通过盲目接受其服务器证书），并将信任状态设置为FALSE。
If the redirect information is untrusted (e.g., trust-state is FALSE), the device MUST discard any trust anchors provided by the redirect information and establish a provisional connection to the bootstrap server (i.e., by blindly accepting its TLS server certificate).
如果重定向信息不可信（例如，信任状态为FALSE），则设备必须丢弃重定向信息提供的任何信任锚，并建立到引导服务器的临时连接（即，通过盲目接受其TLS服务器证书）。
In order to process onboarding information (Section 2.2), the device MUST follow the steps presented in this section.
为了处理入职信息（第2.2节），设备必须遵循本节介绍的步骤。
When processing onboarding information, the device MUST first process the boot image information (if any), then execute the pre-configuration script (if any), then commit the initial configuration
在处理入职信息时，设备必须首先处理引导映像信息（如果有），然后执行预配置脚本（如果有），然后提交初始配置
(if any), and then execute the post-configuration script (if any), in that order.
（如果有），然后按该顺序执行配置后脚本（如果有）。
When the onboarding information is obtained from a trusted bootstrap server, the device MUST send the "bootstrap-initiated" progress report and send a terminating "boot-image-installed-rebooting", "bootstrap-complete", or error-specific progress report. If the "reporting-level" node of the bootstrap server's "get-bootstrapping-data" RPC-reply is the value "verbose", the device MUST additionally send all appropriate non-terminating progress reports (e.g., initiated, warning, complete, etc.). Regardless of the reporting level requested by the bootstrap server, the device MAY send progress reports beyond those required by the reporting level.
当从受信任的引导服务器获取启动信息时，设备必须发送“引导启动”进度报告，并发送终止的“引导映像安装重新启动”、“引导完成”或特定于错误的进度报告。如果引导服务器的“获取引导数据”RPC应答的“报告级别”节点的值为“详细”，则设备还必须发送所有适当的非终止进度报告（例如，已启动、警告、完成等）。无论引导服务器请求的报告级别如何，设备都可能发送超出报告级别要求的进度报告。
When the onboarding information is obtained from an untrusted bootstrap server, the device MUST NOT send any progress reports to the bootstrap server, even though the onboarding information was, necessarily, signed and authenticated. Please be aware that bootstrap servers are recommended to promote untrusted connections to trusted connections, in the last paragraph of Section 9.6, so as to, in part, be able to collect progress reports from devices.
当从不受信任的引导服务器获取入职信息时，设备不得向引导服务器发送任何进度报告，即使入职信息必须经过签名和验证。请注意，在第9.6节的最后一段中，建议引导服务器将不受信任的连接升级为受信任的连接，以便在一定程度上能够从设备收集进度报告。
If the device encounters an error at any step, it MUST stop processing the onboarding information and return to the bootstrapping sequence described in Section 5.2. In the context of a recursive algorithm, the device MUST return to the enclosing loop, not back to the very beginning. Some state MAY be retained from the bootstrapping process (e.g., updated boot image, logs, remnants from a script, etc.). However, the retained state MUST NOT be active in any way (e.g., no new configuration or running of software) and MUST NOT hinder the ability for the device to continue the bootstrapping sequence (i.e., process onboarding information from another bootstrap server).
如果设备在任何步骤中遇到错误，它必须停止处理载入信息，并返回到第5.2节中描述的引导序列。在递归算法的上下文中，设备必须返回到封闭循环，而不是返回到最开始的循环。引导过程中可能会保留一些状态（例如，更新的引导映像、日志、脚本的剩余部分等）。但是，保留状态不得以任何方式处于活动状态（例如，没有新的配置或软件运行），并且不得妨碍设备继续引导序列的能力（即，处理来自另一引导服务器的引导信息）。
At this point, the specific ordered sequence of actions the device MUST perform is described.
此时，描述了设备必须执行的特定有序操作序列。
If the onboarding information is obtained from a trusted bootstrap server, the device MUST send a "bootstrap-initiated" progress report. It is an error if the device does not receive back the "204 No Content" HTTP status line. If an error occurs, the device MUST try to send a "bootstrap-error" progress report before exiting.
如果从受信任的引导服务器获取入职信息，则设备必须发送“引导启动”进度报告。如果设备未接收回“204无内容”HTTP状态行，则为错误。如果发生错误，设备必须在退出前尝试发送“引导错误”进度报告。
The device MUST parse the provided onboarding information document, to extract values used in subsequent steps. Whether using a stream-based parser or not, if there is an error when parsing the onboarding
设备必须解析提供的入职信息文档，以提取后续步骤中使用的值。无论是否使用基于流的解析器，如果解析Onboard时出错
information, and the device is connected to a trusted bootstrap server, the device MUST try to send a "parsing-error" progress report before exiting.
信息，并且设备连接到受信任的引导服务器，则设备必须在退出之前尝试发送“分析错误”进度报告。
If boot image criteria are specified, the device MUST first determine if the boot image it is running satisfies the specified boot image criteria. If the device is already running the specified boot image, then it skips the remainder of this step. If the device is not running the specified boot image, then it MUST download, verify, and install, in that order, the specified boot image, and then reboot. If connected to a trusted bootstrap server, the device MAY try to send a "boot-image-mismatch" progress report. To download the boot image, the device MUST only use the URIs supplied by the onboarding information. To verify the boot image, the device MUST use either one of the verification fingerprints supplied by the onboarding information or a cryptographic signature embedded into the boot image itself using a mechanism not described by this document. Before rebooting, if connected to a trusted bootstrap server, the device MUST try to send a "boot-image-installed-rebooting" progress report. Upon rebooting, the bootstrapping process runs again, which will eventually come to this step again, but then the device will be running the specified boot image and thus will move to processing the next step. If an error occurs at any step while the device is connected to a trusted bootstrap server (i.e., before the reboot), the device MUST try to send a "boot-image-error" progress report before exiting.
如果指定了启动映像条件，则设备必须首先确定其正在运行的启动映像是否满足指定的启动映像条件。如果设备已在运行指定的启动映像，则跳过此步骤的其余部分。如果设备未运行指定的启动映像，则必须按顺序下载、验证和安装指定的启动映像，然后重新启动。如果连接到受信任的引导服务器，设备可能会尝试发送“引导映像不匹配”进度报告。要下载启动映像，设备必须仅使用由加载信息提供的URI。要验证引导映像，设备必须使用由载入信息提供的验证指纹之一，或者使用本文档未描述的机制将加密签名嵌入引导映像本身。重新启动前，如果连接到受信任的引导服务器，则设备必须尝试发送“启动映像已安装重新启动”进度报告。重新启动后，引导过程将再次运行，最终将再次进入此步骤，但随后设备将运行指定的引导映像，因此将进入下一步处理。如果设备连接到受信任的引导服务器时（即重新启动之前）在任何步骤发生错误，则设备必须在退出之前尝试发送“引导映像错误”进度报告。
If a pre-configuration script has been specified, the device MUST execute the script, capture any output emitted from the script, and check if the script had any warnings or errors. If an error occurs while the device is connected to a trusted bootstrap server, the device MUST try to send a "pre-script-error" progress report before exiting.
如果已指定预配置脚本，则设备必须执行脚本，捕获脚本发出的任何输出，并检查脚本是否有任何警告或错误。如果设备连接到受信任的引导服务器时发生错误，则设备必须在退出前尝试发送“脚本前错误”进度报告。
If an initial configuration has been specified, the device MUST atomically commit the provided initial configuration, using the approach specified by the "configuration-handling" leaf. If an error occurs while the device is connected to a trusted bootstrap server, the device MUST try to send a "config-error" progress report before exiting.
如果已指定初始配置，则设备必须使用“配置处理”叶指定的方法以原子方式提交所提供的初始配置。如果设备连接到受信任的引导服务器时发生错误，则设备必须在退出之前尝试发送“配置错误”进度报告。
If a post-configuration script has been specified, the device MUST execute the script, capture any output emitted from the script, and check if the script had any warnings or errors. If an error occurs while the device is connected to a trusted bootstrap server, the device MUST try to send a "post-script-error" progress report before exiting.
如果已指定配置后脚本，则设备必须执行脚本，捕获脚本发出的任何输出，并检查脚本是否有任何警告或错误。如果设备连接到受信任的引导服务器时发生错误，则设备必须在退出之前尝试发送“脚本后错误”进度报告。
If the onboarding information was obtained from a trusted bootstrap server, and the result of the bootstrapping process did not disable the "flag to enable SZTP bootstrapping" described in Section 5.1, the device SHOULD send an "bootstrap-warning" progress report.
如果从受信任的引导服务器获取了启动信息，并且引导过程的结果没有禁用第5.1节中描述的“启用SZTP引导的标志”，则设备应发送“引导警告”进度报告。
If the onboarding information was obtained from a trusted bootstrap server, the device MUST send a "bootstrap-complete" progress report. It is an error if the device does not receive back the "204 No Content" HTTP status line. If an error occurs, the device MUST try to send a "bootstrap-error" progress report before exiting.
如果登录信息是从受信任的引导服务器获得的，则设备必须发送“引导完成”进度报告。如果设备未接收回“204无内容”HTTP状态行，则为错误。如果发生错误，设备必须在退出前尝试发送“引导错误”进度报告。
At this point, the device has completely processed the bootstrapping data.
此时，设备已完全处理引导数据。
The device is now running its initial configuration. Notably, if NETCONF Call Home or RESTCONF Call Home [RFC8071] is configured, the device initiates trying to establish the call home connections at this time.
设备现在正在运行其初始配置。值得注意的是，如果配置了NETCONF呼叫总部或RESTCONF呼叫总部[RFC8071]，则设备此时会启动尝试建立呼叫总部连接。
Implementation Notes:
实施说明：
Implementations may vary in how to ensure no unwanted state is retained when an error occurs.
在如何确保发生错误时不保留不需要的状态方面，实现可能会有所不同。
If the implementation chooses to undo previous steps, the following guidelines apply:
如果实现选择撤消以前的步骤，则适用以下准则：
* When an error occurs, the device must rollback the current step and any previous steps.
* 发生错误时，设备必须回滚当前步骤和任何以前的步骤。
* Most steps are atomic. For example, the processing of a configuration is atomic (as specified above), and the processing of scripts is atomic (as specified in the "ietf-sztp-conveyed-info" YANG module).
* 大多数步骤是原子的。例如，配置的处理是原子的（如上所述），脚本的处理是原子的（如“ietf sztp传输信息”模块中所述）。
* In case the error occurs after the initial configuration was committed, the device must restore the configuration to the configuration that existed prior to the configuration being committed.
* 如果在提交初始配置之后发生错误，则设备必须将配置恢复到提交配置之前存在的配置。
* In case the error occurs after a script had executed successfully, it may be helpful for the implementation to define scripts as being able to take a conceptual input parameter indicating that the script should remove its previously set state.
* 如果在脚本成功执行后发生错误，那么将脚本定义为能够接受一个概念性输入参数（指示脚本应删除其先前设置的状态）可能会对实现有所帮助。
This section defines a YANG 1.1 [RFC7950] module that is used to define the data model for the conveyed information artifact described in Section 3.1. This data model uses the "yang-data" extension statement defined in [RFC8040]. Examples illustrating this data model are provided in Section 6.2.
本节定义了YANG 1.1[RFC7950]模块，该模块用于定义第3.1节所述传输信息工件的数据模型。此数据模型使用[RFC8040]中定义的“yang data”扩展语句。第6.2节提供了说明该数据模型的示例。
The following tree diagram provides an overview of the data model for the conveyed information artifact.
下面的树形图提供了传输信息工件的数据模型的概述。
module: ietf-sztp-conveyed-info
模块：ietf sztp传输信息
yang-data conveyed-information:
+-- (information-type)
+--:(redirect-information)
| +-- redirect-information
| +-- bootstrap-server* [address]
| +-- address inet:host
| +-- port? inet:port-number
| +-- trust-anchor? cms
+--:(onboarding-information)
+-- onboarding-information
+-- boot-image
| +-- os-name? string
| +-- os-version? string
| +-- download-uri* inet:uri
| +-- image-verification* [hash-algorithm]
| +-- hash-algorithm identityref
| +-- hash-value yang:hex-string
+-- configuration-handling? enumeration
+-- pre-configuration-script? script
+-- configuration? binary
+-- post-configuration-script? script
yang-data conveyed-information:
+-- (information-type)
+--:(redirect-information)
| +-- redirect-information
| +-- bootstrap-server* [address]
| +-- address inet:host
| +-- port? inet:port-number
| +-- trust-anchor? cms
+--:(onboarding-information)
+-- onboarding-information
+-- boot-image
| +-- os-name? string
| +-- os-version? string
| +-- download-uri* inet:uri
| +-- image-verification* [hash-algorithm]
| +-- hash-algorithm identityref
| +-- hash-value yang:hex-string
+-- configuration-handling? enumeration
+-- pre-configuration-script? script
+-- configuration? binary
+-- post-configuration-script? script
The following example illustrates how redirect information (Section 2.1) can be encoded using JSON [RFC8259].
以下示例说明如何使用JSON[RFC8259]对重定向信息（第2.1节）进行编码。
{
"ietf-sztp-conveyed-info:redirect-information" : {
"bootstrap-server" : [
{
"address" : "sztp1.example.com",
"port" : 8443,
{
"ietf-sztp-conveyed-info:redirect-information" : {
"bootstrap-server" : [
{
"address" : "sztp1.example.com",
"port" : 8443,
"trust-anchor" : "base64encodedvalue=="
},
{
"address" : "sztp2.example.com",
"port" : 8443,
"trust-anchor" : "base64encodedvalue=="
},
{
"address" : "sztp3.example.com",
"port" : 8443,
"trust-anchor" : "base64encodedvalue=="
}
]
}
}
"trust-anchor" : "base64encodedvalue=="
},
{
"address" : "sztp2.example.com",
"port" : 8443,
"trust-anchor" : "base64encodedvalue=="
},
{
"address" : "sztp3.example.com",
"port" : 8443,
"trust-anchor" : "base64encodedvalue=="
}
]
}
}
The following example illustrates how onboarding information (Section 2.2) can be encoded using JSON [RFC8259].
以下示例说明了如何使用JSON[RFC8259]对入职信息（第2.2节）进行编码。
[Note: '\' line wrapping for formatting only]
[注意：“\”换行仅用于格式化]
{
"ietf-sztp-conveyed-info:onboarding-information" : {
"boot-image" : {
"os-name" : "VendorOS",
"os-version" : "17.2R1.6",
"download-uri" : [ "https://example.com/path/to/image/file" ],
"image-verification" : [
{
"hash-algorithm" : "ietf-sztp-conveyed-info:sha-256",
"hash-value" : "ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:\
7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33"
}
]
},
"configuration-handling" : "merge",
"pre-configuration-script" : "base64encodedvalue==",
"configuration" : "base64encodedvalue==",
"post-configuration-script" : "base64encodedvalue=="
}
}
{
"ietf-sztp-conveyed-info:onboarding-information" : {
"boot-image" : {
"os-name" : "VendorOS",
"os-version" : "17.2R1.6",
"download-uri" : [ "https://example.com/path/to/image/file" ],
"image-verification" : [
{
"hash-algorithm" : "ietf-sztp-conveyed-info:sha-256",
"hash-value" : "ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:\
7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33"
}
]
},
"configuration-handling" : "merge",
"pre-configuration-script" : "base64encodedvalue==",
"configuration" : "base64encodedvalue==",
"post-configuration-script" : "base64encodedvalue=="
}
}
The conveyed information data model is defined by the YANG module presented in this section.
传输信息数据模型由本节介绍的YANG模块定义。
This module uses data types defined in [RFC5280], [RFC5652], [RFC6234], and [RFC6991]; an extension statement from [RFC8040]; and an encoding defined in [ITU.X690.2015].
此模块使用[RFC5280]、[RFC5652]、[RFC6234]和[RFC6991]中定义的数据类型；[RFC8040]中的扩展语句；以及[ITU.X690.2015]中定义的编码。
<CODE BEGINS> file "ietf-sztp-conveyed-info@2019-04-30.yang"
module ietf-sztp-conveyed-info {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info";
prefix sztp-info;
<CODE BEGINS> file "ietf-sztp-conveyed-info@2019-04-30.yang"
module ietf-sztp-conveyed-info {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info";
prefix sztp-info;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-restconf {
prefix rc;
reference
"RFC 8040: RESTCONF Protocol";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-restconf {
prefix rc;
reference
"RFC 8040: RESTCONF Protocol";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
description
"This module defines the data model for the conveyed
information artifact defined in RFC 8572 ('Secure Zero Touch
Provisioning (SZTP)').
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
description
"This module defines the data model for the conveyed
information artifact defined in RFC 8572 ('Secure Zero Touch
Provisioning (SZTP)').
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可能”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14（RFC 2119）（RFC 8174）所述进行解释。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8572; see the RFC itself for full legal notices.";
该模块的此版本是RFC 8572的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2019-04-30 {
description
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
revision 2019-04-30 {
description
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
// identities
//身份
identity hash-algorithm {
description
"A base identity for hash algorithm verification.";
}
identity hash-algorithm {
description
"A base identity for hash algorithm verification.";
}
identity sha-256 {
base hash-algorithm;
description
"The SHA-256 algorithm.";
reference
"RFC 6234: US Secure Hash Algorithms";
}
identity sha-256 {
base hash-algorithm;
description
"The SHA-256 algorithm.";
reference
"RFC 6234: US Secure Hash Algorithms";
}
// typedefs
//typedefs
typedef cms {
type binary;
description
"A ContentInfo structure, as specified in RFC 5652,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"RFC 5652:
Cryptographic Message Syntax (CMS)
typedef cms {
type binary;
description
"A ContentInfo structure, as specified in RFC 5652,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.";
reference
"RFC 5652:
Cryptographic Message Syntax (CMS)
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)";
}
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)";
}
// yang-data
rc:yang-data conveyed-information {
choice information-type {
mandatory true;
description
"This choice statement ensures the response contains
redirect-information or onboarding-information.";
container redirect-information {
description
"Redirect information is described in Section 2.1 of
RFC 8572. Its purpose is to redirect a device to
another bootstrap server.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
list bootstrap-server {
key "address";
min-elements 1;
description
"A bootstrap server entry.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the bootstrap server the
device should redirect to.";
}
leaf port {
type inet:port-number;
default "443";
description
"The port number the bootstrap server listens on. If no
port is specified, the IANA-assigned port for 'https'
(443) is used.";
}
leaf trust-anchor {
type cms;
description
"A CMS structure that MUST contain the chain of
X.509 certificates needed to authenticate the TLS
certificate presented by this bootstrap server.
// yang-data
rc:yang-data conveyed-information {
choice information-type {
mandatory true;
description
"This choice statement ensures the response contains
redirect-information or onboarding-information.";
container redirect-information {
description
"Redirect information is described in Section 2.1 of
RFC 8572. Its purpose is to redirect a device to
another bootstrap server.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
list bootstrap-server {
key "address";
min-elements 1;
description
"A bootstrap server entry.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the bootstrap server the
device should redirect to.";
}
leaf port {
type inet:port-number;
default "443";
description
"The port number the bootstrap server listens on. If no
port is specified, the IANA-assigned port for 'https'
(443) is used.";
}
leaf trust-anchor {
type cms;
description
"A CMS structure that MUST contain the chain of
X.509 certificates needed to authenticate the TLS
certificate presented by this bootstrap server.
The CMS MUST only contain a single chain of certificates. The bootstrap server MUST only authenticate to last intermediate CA certificate listed in the chain.
CMS必须只包含一个证书链。引导服务器必须仅对链中列出的最后一个中间CA证书进行身份验证。
In all cases, the chain MUST include a self-signed root certificate. In the case where the root certificate is itself the issuer of the bootstrap server's TLS certificate, only one certificate is present.
在所有情况下，链必须包括自签名根证书。如果根证书本身是引导服务器TLS证书的颁发者，则只存在一个证书。
If needed by the device, this CMS structure MAY also contain suitably fresh revocation objects with which the device can verify the revocation status of the certificates.
如果设备需要，该CMS结构还可以包含适当的新撤销对象，设备可以使用这些对象验证证书的撤销状态。
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile";
}
}
}
container onboarding-information {
description
"Onboarding information is described in Section 2.2 of
RFC 8572. Its purpose is to provide the device everything
it needs to bootstrap itself.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
container boot-image {
description
"Specifies criteria for the boot image the device MUST
be running, as well as information enabling the device
to install the required boot image.";
leaf os-name {
type string;
description
"The name of the operating system software the device
MUST be running in order to not require a software
image upgrade (e.g., VendorOS).";
}
leaf os-version {
type string;
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile";
}
}
}
container onboarding-information {
description
"Onboarding information is described in Section 2.2 of
RFC 8572. Its purpose is to provide the device everything
it needs to bootstrap itself.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
container boot-image {
description
"Specifies criteria for the boot image the device MUST
be running, as well as information enabling the device
to install the required boot image.";
leaf os-name {
type string;
description
"The name of the operating system software the device
MUST be running in order to not require a software
image upgrade (e.g., VendorOS).";
}
leaf os-version {
type string;
description
"The version of the operating system software the
device MUST be running in order to not require a
software image upgrade (e.g., 17.3R2.1).";
}
leaf-list download-uri {
type inet:uri;
ordered-by user;
description
"An ordered list of URIs to where the same boot image
file may be obtained. How the URI schemes (http, ftp,
etc.) a device supports are known is vendor specific.
If a secure scheme (e.g., https) is provided, a device
MAY establish an untrusted connection to the remote
server, by blindly accepting the server's end-entity
certificate, to obtain the boot image.";
}
list image-verification {
must '../download-uri' {
description
"Download URIs must be provided if an image is to
be verified.";
}
key "hash-algorithm";
description
"A list of hash values that a device can use to verify
boot image files with.";
leaf hash-algorithm {
type identityref {
base hash-algorithm;
}
description
"Identifies the hash algorithm used.";
}
leaf hash-value {
type yang:hex-string;
mandatory true;
description
"The hex-encoded value of the specified hash
algorithm over the contents of the boot image
file.";
}
}
}
leaf configuration-handling {
type enumeration {
enum merge {
description
"The version of the operating system software the
device MUST be running in order to not require a
software image upgrade (e.g., 17.3R2.1).";
}
leaf-list download-uri {
type inet:uri;
ordered-by user;
description
"An ordered list of URIs to where the same boot image
file may be obtained. How the URI schemes (http, ftp,
etc.) a device supports are known is vendor specific.
If a secure scheme (e.g., https) is provided, a device
MAY establish an untrusted connection to the remote
server, by blindly accepting the server's end-entity
certificate, to obtain the boot image.";
}
list image-verification {
must '../download-uri' {
description
"Download URIs must be provided if an image is to
be verified.";
}
key "hash-algorithm";
description
"A list of hash values that a device can use to verify
boot image files with.";
leaf hash-algorithm {
type identityref {
base hash-algorithm;
}
description
"Identifies the hash algorithm used.";
}
leaf hash-value {
type yang:hex-string;
mandatory true;
description
"The hex-encoded value of the specified hash
algorithm over the contents of the boot image
file.";
}
}
}
leaf configuration-handling {
type enumeration {
enum merge {
description
"Merge configuration into the running datastore.";
}
enum replace {
description
"Replace the existing running datastore with the
passed configuration.";
}
}
must '../configuration';
description
"This enumeration indicates how the server should process
the provided configuration.";
}
leaf pre-configuration-script {
type script;
description
"A script that, when present, is executed before the
configuration has been processed.";
}
leaf configuration {
type binary;
must '../configuration-handling';
description
"Any configuration known to the device. The use of
the 'binary' type enables content (e.g., XML) to be
embedded into a JSON document. The exact encoding
of the content, as with the scripts, is vendor
specific.";
}
leaf post-configuration-script {
type script;
description
"A script that, when present, is executed after the
configuration has been processed.";
}
}
}
}
description
"Merge configuration into the running datastore.";
}
enum replace {
description
"Replace the existing running datastore with the
passed configuration.";
}
}
must '../configuration';
description
"This enumeration indicates how the server should process
the provided configuration.";
}
leaf pre-configuration-script {
type script;
description
"A script that, when present, is executed before the
configuration has been processed.";
}
leaf configuration {
type binary;
must '../configuration-handling';
description
"Any configuration known to the device. The use of
the 'binary' type enables content (e.g., XML) to be
embedded into a JSON document. The exact encoding
of the content, as with the scripts, is vendor
specific.";
}
leaf post-configuration-script {
type script;
description
"A script that, when present, is executed after the
configuration has been processed.";
}
}
}
}
typedef script {
type binary;
description
"A device-specific script that enables the execution of
commands to perform actions not possible thru configuration
alone.
typedef script {
type binary;
description
"A device-specific script that enables the execution of
commands to perform actions not possible thru configuration
alone.
No attempt is made to standardize the contents, running context, or programming language of the script, other than that it can indicate if any warnings or errors occurred and can emit output. The contents of the script are considered specific to the vendor, product line, and/or model of the device.
未尝试标准化脚本的内容、运行上下文或编程语言，只是它可以指示是否出现任何警告或错误，并可以发出输出。脚本的内容被视为特定于设备的供应商、产品线和/或型号。
If the script execution indicates that a warning occurred, then the device MUST assume that the script had a soft error that the script believes will not affect manageability.
如果脚本执行指示出现警告，则设备必须假定脚本存在软错误，脚本认为该错误不会影响可管理性。
If the script execution indicates that an error occurred,
the device MUST assume the script had a hard error that the
script believes will affect manageability. In this case,
the script is required to gracefully exit, removing any
state that might hinder the device's ability to continue
the bootstrapping sequence (e.g., process onboarding
information obtained from another bootstrap server).";
}
}
<CODE ENDS>
If the script execution indicates that an error occurred,
the device MUST assume the script had a hard error that the
script believes will affect manageability. In this case,
the script is required to gracefully exit, removing any
state that might hinder the device's ability to continue
the bootstrapping sequence (e.g., process onboarding
information obtained from another bootstrap server).";
}
}
<CODE ENDS>
This section defines the API for bootstrap servers. The API is defined as that produced by a RESTCONF [RFC8040] server that supports the YANG 1.1 [RFC7950] module defined in this section.
本节定义了引导服务器的API。API被定义为由支持本节中定义的YANG 1.1[RFC7950]模块的RESTCONF[RFC8040]服务器生成的API。
The following tree diagram provides an overview for the bootstrap server RESTCONF API.
下面的树形图提供了引导服务器RESTCONF API的概述。
module: ietf-sztp-bootstrap-server
模块：ietf sztp引导服务器
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
| +--ro output
| +--ro reporting-level? enumeration {onboarding-server}?
| +--ro conveyed-information cms
| +--ro owner-certificate? cms
| +--ro ownership-voucher? cms
+---x report-progress {onboarding-server}?
+---w input
+---w progress-type enumeration
+---w message? string
+---w ssh-host-keys
| +---w ssh-host-key* []
| +---w algorithm string
| +---w key-data binary
+---w trust-anchor-certs
+---w trust-anchor-cert* cms
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
| +--ro output
| +--ro reporting-level? enumeration {onboarding-server}?
| +--ro conveyed-information cms
| +--ro owner-certificate? cms
| +--ro ownership-voucher? cms
+---x report-progress {onboarding-server}?
+---w input
+---w progress-type enumeration
+---w message? string
+---w ssh-host-keys
| +---w ssh-host-key* []
| +---w algorithm string
| +---w key-data binary
+---w trust-anchor-certs
+---w trust-anchor-cert* cms
This section presents three examples illustrating the bootstrap server's API. Two examples are provided for the "get-bootstrapping-data" RPC (one to an untrusted bootstrap server and the other to a trusted bootstrap server), and one example is provided for the "report-progress" RPC.
本节介绍三个示例，说明引导服务器的API。为“获取引导数据”RPC提供了两个示例（一个到不受信任的引导服务器，另一个到受信任的引导服务器），为“报告进度”RPC提供了一个示例。
The following example illustrates a device using the API to fetch its bootstrapping data from an untrusted bootstrap server. In this example, the device sends the "signed-data-preferred" input parameter and receives signed data in the response.
下面的示例演示了一个设备，该设备使用API从不受信任的引导服务器获取其引导数据。在此示例中，设备发送“首选签名数据”输入参数，并在响应中接收签名数据。
REQUEST
要求
[Note: '\' line wrapping for formatting only]
[注意：“\”换行仅用于格式化]
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<signed-data-preferred/>
</input>
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<signed-data-preferred/>
</input>
RESPONSE
回答
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<output
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<conveyed-information>base64encodedvalue==</conveyed-information>
<owner-certificate>base64encodedvalue==</owner-certificate>
<ownership-voucher>base64encodedvalue==</ownership-voucher>
</output>
<output
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<conveyed-information>base64encodedvalue==</conveyed-information>
<owner-certificate>base64encodedvalue==</owner-certificate>
<ownership-voucher>base64encodedvalue==</ownership-voucher>
</output>
The following example illustrates a device using the API to fetch its bootstrapping data from a trusted bootstrap server. In this example, the device sends additional input parameters to the bootstrap server, which it may use when formulating its response to the device.
下面的示例演示了一个设备，该设备使用API从受信任的引导服务器获取其引导数据。在本例中，设备向引导服务器发送额外的输入参数，在制定对设备的响应时可以使用这些参数。
REQUEST
要求
[Note: '\' line wrapping for formatting only]
[注意：“\”换行仅用于格式化]
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<hw-model>model-x</hw-model>
<os-name>vendor-os</os-name>
<os-version>17.3R2.1</os-version>
<nonce>extralongbase64encodedvalue=</nonce>
</input>
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<hw-model>model-x</hw-model>
<os-name>vendor-os</os-name>
<os-version>17.3R2.1</os-version>
<nonce>extralongbase64encodedvalue=</nonce>
</input>
RESPONSE
回答
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<output
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<reporting-level>verbose</reporting-level>
<conveyed-information>base64encodedvalue==</conveyed-information>
</output>
<output
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<reporting-level>verbose</reporting-level>
<conveyed-information>base64encodedvalue==</conveyed-information>
</output>
The following example illustrates a device using the API to post a progress report to a bootstrap server. Illustrated below is the "bootstrap-complete" message, but the device may send other progress reports to the server while bootstrapping. In this example, the device is sending both its SSH host keys and a TLS server certificate, which the bootstrap server may, for example, pass to an NMS, as discussed in Appendix C.3.
下面的示例演示了一个使用API将进度报告发布到引导服务器的设备。下图显示了“引导完成”消息，但设备在引导时可能会向服务器发送其他进度报告。在此示例中，设备正在发送其SSH主机密钥和TLS服务器证书，例如，引导服务器可以将其传递给NMS，如附录C.3中所述。
REQUEST
要求
[Note: '\' line wrapping for formatting only]
[注意：“\”换行仅用于格式化]
POST /restconf/operations/ietf-sztp-bootstrap-server:report-progress\
HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
POST /restconf/operations/ietf-sztp-bootstrap-server:report-progress\
HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<progress-type>bootstrap-complete</progress-type>
<message>example message</message>
<ssh-host-keys>
<ssh-host-key>
<algorithm>ssh-rsa</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
<ssh-host-key>
<algorithm>rsa-sha2-256</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
</ssh-host-keys>
<trust-anchor-certs>
<trust-anchor-cert>base64encodedvalue==</trust-anchor-cert>
</trust-anchor-certs>
</input>
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<progress-type>bootstrap-complete</progress-type>
<message>example message</message>
<ssh-host-keys>
<ssh-host-key>
<algorithm>ssh-rsa</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
<ssh-host-key>
<algorithm>rsa-sha2-256</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
</ssh-host-keys>
<trust-anchor-certs>
<trust-anchor-cert>base64encodedvalue==</trust-anchor-cert>
</trust-anchor-certs>
</input>
RESPONSE
回答
HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
The bootstrap server's device-facing API is normatively defined by the YANG module defined in this section.
引导服务器的面向设备的API由本节中定义的模块进行规范性定义。
This module uses data types defined in [RFC4253], [RFC5652],
[RFC5280], and [RFC8366]; uses an encoding defined in
[ITU.X690.2015]; and makes a reference to [RFC4250], [RFC6187], and
[Std-802.1AR].
This module uses data types defined in [RFC4253], [RFC5652],
[RFC5280], and [RFC8366]; uses an encoding defined in
[ITU.X690.2015]; and makes a reference to [RFC4250], [RFC6187], and
[Std-802.1AR].
<CODE BEGINS> file "ietf-sztp-bootstrap-server@2019-04-30.yang"
module ietf-sztp-bootstrap-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server";
prefix sztp-svr;
<CODE BEGINS> file "ietf-sztp-bootstrap-server@2019-04-30.yang"
module ietf-sztp-bootstrap-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server";
prefix sztp-svr;
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
description
"This module defines an interface for bootstrap servers, as
defined by RFC 8572 ('Secure Zero Touch Provisioning (SZTP)').
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
description
"This module defines an interface for bootstrap servers, as
defined by RFC 8572 ('Secure Zero Touch Provisioning (SZTP)').
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可能”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14（RFC 2119）（RFC 8174）所述进行解释。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8572; see the RFC itself for full legal notices.";
该模块的此版本是RFC 8572的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2019-04-30 { description
修订版2019-04-30{说明
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
// features
//特征
feature redirect-server {
description
"The server supports being a 'redirect server'.";
}
feature redirect-server {
description
"The server supports being a 'redirect server'.";
}
feature onboarding-server {
description
"The server supports being an 'onboarding server'.";
}
feature onboarding-server {
description
"The server supports being an 'onboarding server'.";
}
// typedefs
//typedefs
typedef cms {
type binary;
description
"A CMS structure, as specified in RFC 5652, encoded using
ASN.1 distinguished encoding rules (DER), as specified in
ITU-T X.690.";
reference
"RFC 5652:
Cryptographic Message Syntax (CMS)
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)";
}
typedef cms {
type binary;
description
"A CMS structure, as specified in RFC 5652, encoded using
ASN.1 distinguished encoding rules (DER), as specified in
ITU-T X.690.";
reference
"RFC 5652:
Cryptographic Message Syntax (CMS)
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)";
}
// RPCs
//放射性同位素
rpc get-bootstrapping-data {
description
"This RPC enables a device, as identified by the RESTCONF
username, to obtain bootstrapping data that has been made
available for it.";
input {
leaf signed-data-preferred {
type empty;
description
"This optional input parameter enables a device to
communicate to the bootstrap server that it prefers
rpc get-bootstrapping-data {
description
"This RPC enables a device, as identified by the RESTCONF
username, to obtain bootstrapping data that has been made
available for it.";
input {
leaf signed-data-preferred {
type empty;
description
"This optional input parameter enables a device to
communicate to the bootstrap server that it prefers
to receive signed data. Devices SHOULD always send
this parameter when the bootstrap server is untrusted.
Upon receiving this input parameter, the bootstrap
server MUST return either signed data or unsigned
redirect information; the bootstrap server MUST NOT
return unsigned onboarding information.";
}
leaf hw-model {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server its vendor-specific
hardware model number. This parameter may be needed,
for instance, when a device's IDevID certificate does
not include the 'hardwareModelName' value in its
subjectAltName field, as is allowed by 802.1AR.";
reference
"IEEE 802.1AR: IEEE Standard for Local and
metropolitan area networks - Secure
Device Identity";
}
leaf os-name {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server the name of its
operating system. This parameter may be useful if
the device, as identified by its serial number, can
run more than one type of operating system (e.g.,
on a white-box system.";
}
leaf os-version {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server the version of its
operating system. This parameter may be used by a
bootstrap server to return an operating-system-specific
response to the device, thus negating the need for a
potentially expensive boot image update.";
}
leaf nonce {
type binary {
length "16..32";
}
description
"This optional input parameter enables a device to
communicate to the bootstrap server a nonce value.
to receive signed data. Devices SHOULD always send
this parameter when the bootstrap server is untrusted.
Upon receiving this input parameter, the bootstrap
server MUST return either signed data or unsigned
redirect information; the bootstrap server MUST NOT
return unsigned onboarding information.";
}
leaf hw-model {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server its vendor-specific
hardware model number. This parameter may be needed,
for instance, when a device's IDevID certificate does
not include the 'hardwareModelName' value in its
subjectAltName field, as is allowed by 802.1AR.";
reference
"IEEE 802.1AR: IEEE Standard for Local and
metropolitan area networks - Secure
Device Identity";
}
leaf os-name {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server the name of its
operating system. This parameter may be useful if
the device, as identified by its serial number, can
run more than one type of operating system (e.g.,
on a white-box system.";
}
leaf os-version {
type string;
description
"This optional input parameter enables a device to
communicate to the bootstrap server the version of its
operating system. This parameter may be used by a
bootstrap server to return an operating-system-specific
response to the device, thus negating the need for a
potentially expensive boot image update.";
}
leaf nonce {
type binary {
length "16..32";
}
description
"This optional input parameter enables a device to
communicate to the bootstrap server a nonce value.
This may be especially useful for devices lacking
an accurate clock, as then the bootstrap server
can dynamically obtain from the manufacturer a
voucher with the nonce value in it, as described
in RFC 8366.";
reference
"RFC 8366:
A Voucher Artifact for Bootstrapping Protocols";
}
}
output {
leaf reporting-level {
if-feature "onboarding-server";
type enumeration {
enum minimal {
description
"Send just the progress reports required by RFC 8572.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
enum verbose {
description
"Send additional progress reports that might help
troubleshooting an SZTP bootstrapping issue.";
}
}
default "minimal";
description
"Specifies the reporting level for progress reports the
bootstrap server would like to receive when processing
onboarding information. Progress reports are not sent
when processing redirect information or when the
bootstrap server is untrusted (e.g., device sent the
'<signed-data-preferred>' input parameter).";
}
leaf conveyed-information {
type cms;
mandatory true;
description
"An SZTP conveyed information artifact, as described in
Section 3.1 of RFC 8572.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
leaf owner-certificate {
type cms;
must '../ownership-voucher' {
description
This may be especially useful for devices lacking
an accurate clock, as then the bootstrap server
can dynamically obtain from the manufacturer a
voucher with the nonce value in it, as described
in RFC 8366.";
reference
"RFC 8366:
A Voucher Artifact for Bootstrapping Protocols";
}
}
output {
leaf reporting-level {
if-feature "onboarding-server";
type enumeration {
enum minimal {
description
"Send just the progress reports required by RFC 8572.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
enum verbose {
description
"Send additional progress reports that might help
troubleshooting an SZTP bootstrapping issue.";
}
}
default "minimal";
description
"Specifies the reporting level for progress reports the
bootstrap server would like to receive when processing
onboarding information. Progress reports are not sent
when processing redirect information or when the
bootstrap server is untrusted (e.g., device sent the
'<signed-data-preferred>' input parameter).";
}
leaf conveyed-information {
type cms;
mandatory true;
description
"An SZTP conveyed information artifact, as described in
Section 3.1 of RFC 8572.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
leaf owner-certificate {
type cms;
must '../ownership-voucher' {
description
"An ownership voucher must be present whenever an owner
certificate is presented.";
}
description
"An owner certificate artifact, as described in Section
3.2 of RFC 8572. This leaf is optional because it is
only needed when the conveyed information artifact is
signed.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
leaf ownership-voucher {
type cms;
must '../owner-certificate' {
description
"An owner certificate must be present whenever an
ownership voucher is presented.";
}
description
"An ownership voucher artifact, as described by Section
3.3 of RFC 8572. This leaf is optional because it is
only needed when the conveyed information artifact is
signed.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
}
}
"An ownership voucher must be present whenever an owner
certificate is presented.";
}
description
"An owner certificate artifact, as described in Section
3.2 of RFC 8572. This leaf is optional because it is
only needed when the conveyed information artifact is
signed.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
leaf ownership-voucher {
type cms;
must '../owner-certificate' {
description
"An owner certificate must be present whenever an
ownership voucher is presented.";
}
description
"An ownership voucher artifact, as described by Section
3.3 of RFC 8572. This leaf is optional because it is
only needed when the conveyed information artifact is
signed.";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
}
}
rpc report-progress {
if-feature "onboarding-server";
description
"This RPC enables a device, as identified by the RESTCONF
username, to report its bootstrapping progress to the
bootstrap server. This RPC is expected to be used when
the device obtains onboarding-information from a trusted
bootstrap server.";
input {
leaf progress-type {
type enumeration {
enum bootstrap-initiated {
description
"Indicates that the device just used the
'get-bootstrapping-data' RPC. The 'message' node
below MAY contain any additional information that
the manufacturer thinks might be useful.";
}
enum parsing-initiated {
rpc report-progress {
if-feature "onboarding-server";
description
"This RPC enables a device, as identified by the RESTCONF
username, to report its bootstrapping progress to the
bootstrap server. This RPC is expected to be used when
the device obtains onboarding-information from a trusted
bootstrap server.";
input {
leaf progress-type {
type enumeration {
enum bootstrap-initiated {
description
"Indicates that the device just used the
'get-bootstrapping-data' RPC. The 'message' node
below MAY contain any additional information that
the manufacturer thinks might be useful.";
}
enum parsing-initiated {
description
"Indicates that the device is about to start parsing
the onboarding information. This progress type is
only for when parsing is implemented as a distinct
step.";
}
enum parsing-warning {
description
"Indicates that the device had a non-fatal error when
parsing the response from the bootstrap server. The
'message' node below SHOULD indicate the specific
warning that occurred.";
}
enum parsing-error {
description
"Indicates that the device encountered a fatal error
when parsing the response from the bootstrap server.
For instance, this could be due to malformed encoding,
the device expecting signed data when only unsigned
data is provided, the ownership voucher not listing
the device's serial number, or because the signature
didn't match. The 'message' node below SHOULD
indicate the specific error. This progress type
also indicates that the device has abandoned trying
to bootstrap off this bootstrap server.";
}
enum parsing-complete {
description
"Indicates that the device successfully completed
parsing the onboarding information. This progress
type is only for when parsing is implemented as a
distinct step.";
}
enum boot-image-initiated {
description
"Indicates that the device is about to start
processing the boot image information.";
}
enum boot-image-warning {
description
"Indicates that the device encountered a non-fatal
error condition when trying to install a boot image.
A possible reason might include a need to reformat a
partition causing loss of data. The 'message' node
below SHOULD indicate any warning messages that were
generated.";
}
enum boot-image-error {
description
"Indicates that the device is about to start parsing
the onboarding information. This progress type is
only for when parsing is implemented as a distinct
step.";
}
enum parsing-warning {
description
"Indicates that the device had a non-fatal error when
parsing the response from the bootstrap server. The
'message' node below SHOULD indicate the specific
warning that occurred.";
}
enum parsing-error {
description
"Indicates that the device encountered a fatal error
when parsing the response from the bootstrap server.
For instance, this could be due to malformed encoding,
the device expecting signed data when only unsigned
data is provided, the ownership voucher not listing
the device's serial number, or because the signature
didn't match. The 'message' node below SHOULD
indicate the specific error. This progress type
also indicates that the device has abandoned trying
to bootstrap off this bootstrap server.";
}
enum parsing-complete {
description
"Indicates that the device successfully completed
parsing the onboarding information. This progress
type is only for when parsing is implemented as a
distinct step.";
}
enum boot-image-initiated {
description
"Indicates that the device is about to start
processing the boot image information.";
}
enum boot-image-warning {
description
"Indicates that the device encountered a non-fatal
error condition when trying to install a boot image.
A possible reason might include a need to reformat a
partition causing loss of data. The 'message' node
below SHOULD indicate any warning messages that were
generated.";
}
enum boot-image-error {
description
"Indicates that the device encountered an error when
trying to install a boot image, which could be for
reasons such as a file server being unreachable,
file not found, signature mismatch, etc. The
'message' node SHOULD indicate the specific error
that occurred. This progress type also indicates
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum boot-image-mismatch {
description
"Indicates that the device has determined that
it is not running the correct boot image. This
message SHOULD precipitate trying to download
a boot image.";
}
enum boot-image-installed-rebooting {
description
"Indicates that the device successfully installed
a new boot image and is about to reboot. After
sending this progress type, the device is not
expected to access the bootstrap server again
for this bootstrapping attempt.";
}
enum boot-image-complete {
description
"Indicates that the device believes that it is
running the correct boot image.";
}
enum pre-script-initiated {
description
"Indicates that the device is about to execute the
'pre-configuration-script'.";
}
enum pre-script-warning {
description
"Indicates that the device obtained a warning from the
'pre-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces.";
}
enum pre-script-error {
description
"Indicates that the device obtained an error from the
'pre-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces. This progress type also indicates
description
"Indicates that the device encountered an error when
trying to install a boot image, which could be for
reasons such as a file server being unreachable,
file not found, signature mismatch, etc. The
'message' node SHOULD indicate the specific error
that occurred. This progress type also indicates
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum boot-image-mismatch {
description
"Indicates that the device has determined that
it is not running the correct boot image. This
message SHOULD precipitate trying to download
a boot image.";
}
enum boot-image-installed-rebooting {
description
"Indicates that the device successfully installed
a new boot image and is about to reboot. After
sending this progress type, the device is not
expected to access the bootstrap server again
for this bootstrapping attempt.";
}
enum boot-image-complete {
description
"Indicates that the device believes that it is
running the correct boot image.";
}
enum pre-script-initiated {
description
"Indicates that the device is about to execute the
'pre-configuration-script'.";
}
enum pre-script-warning {
description
"Indicates that the device obtained a warning from the
'pre-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces.";
}
enum pre-script-error {
description
"Indicates that the device obtained an error from the
'pre-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces. This progress type also indicates
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum pre-script-complete {
description
"Indicates that the device successfully executed the
'pre-configuration-script'.";
}
enum config-initiated {
description
"Indicates that the device is about to commit the
initial configuration.";
}
enum config-warning {
description
"Indicates that the device obtained warning messages
when it committed the initial configuration. The
'message' node below SHOULD indicate any warning
messages that were generated.";
}
enum config-error {
description
"Indicates that the device obtained error messages
when it committed the initial configuration. The
'message' node below SHOULD indicate the error
messages that were generated. This progress type
also indicates that the device has abandoned trying
to bootstrap off this bootstrap server.";
}
enum config-complete {
description
"Indicates that the device successfully committed
the initial configuration.";
}
enum post-script-initiated {
description
"Indicates that the device is about to execute the
'post-configuration-script'.";
}
enum post-script-warning {
description
"Indicates that the device obtained a warning from the
'post-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces.";
}
enum post-script-error {
description
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum pre-script-complete {
description
"Indicates that the device successfully executed the
'pre-configuration-script'.";
}
enum config-initiated {
description
"Indicates that the device is about to commit the
initial configuration.";
}
enum config-warning {
description
"Indicates that the device obtained warning messages
when it committed the initial configuration. The
'message' node below SHOULD indicate any warning
messages that were generated.";
}
enum config-error {
description
"Indicates that the device obtained error messages
when it committed the initial configuration. The
'message' node below SHOULD indicate the error
messages that were generated. This progress type
also indicates that the device has abandoned trying
to bootstrap off this bootstrap server.";
}
enum config-complete {
description
"Indicates that the device successfully committed
the initial configuration.";
}
enum post-script-initiated {
description
"Indicates that the device is about to execute the
'post-configuration-script'.";
}
enum post-script-warning {
description
"Indicates that the device obtained a warning from the
'post-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces.";
}
enum post-script-error {
description
"Indicates that the device obtained an error from the
'post-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces. This progress type also indicates
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum post-script-complete {
description
"Indicates that the device successfully executed the
'post-configuration-script'.";
}
enum bootstrap-warning {
description
"Indicates that a warning condition occurred for which
no other 'progress-type' enumeration is deemed
suitable. The 'message' node below SHOULD describe
the warning.";
}
enum bootstrap-error {
description
"Indicates that an error condition occurred for which
no other 'progress-type' enumeration is deemed
suitable. The 'message' node below SHOULD describe
the error. This progress type also indicates that
the device has abandoned trying to bootstrap off
this bootstrap server.";
}
enum bootstrap-complete {
description
"Indicates that the device successfully processed
all 'onboarding-information' provided and that it
is ready to be managed. The 'message' node below
MAY contain any additional information that the
manufacturer thinks might be useful. After sending
this progress type, the device is not expected to
access the bootstrap server again.";
}
enum informational {
description
"Indicates any additional information not captured
by any of the other progress types. For instance,
a message indicating that the device is about to
reboot after having installed a boot image could
be provided. The 'message' node below SHOULD
contain information that the manufacturer thinks
might be useful.";
}
"Indicates that the device obtained an error from the
'post-configuration-script' when it was executed. The
'message' node below SHOULD capture any output the
script produces. This progress type also indicates
that the device has abandoned trying to bootstrap
off this bootstrap server.";
}
enum post-script-complete {
description
"Indicates that the device successfully executed the
'post-configuration-script'.";
}
enum bootstrap-warning {
description
"Indicates that a warning condition occurred for which
no other 'progress-type' enumeration is deemed
suitable. The 'message' node below SHOULD describe
the warning.";
}
enum bootstrap-error {
description
"Indicates that an error condition occurred for which
no other 'progress-type' enumeration is deemed
suitable. The 'message' node below SHOULD describe
the error. This progress type also indicates that
the device has abandoned trying to bootstrap off
this bootstrap server.";
}
enum bootstrap-complete {
description
"Indicates that the device successfully processed
all 'onboarding-information' provided and that it
is ready to be managed. The 'message' node below
MAY contain any additional information that the
manufacturer thinks might be useful. After sending
this progress type, the device is not expected to
access the bootstrap server again.";
}
enum informational {
description
"Indicates any additional information not captured
by any of the other progress types. For instance,
a message indicating that the device is about to
reboot after having installed a boot image could
be provided. The 'message' node below SHOULD
contain information that the manufacturer thinks
might be useful.";
}
}
mandatory true;
description
"The type of progress report provided.";
}
leaf message {
type string;
description
"An optional arbitrary value.";
}
container ssh-host-keys {
when "../progress-type = 'bootstrap-complete'" {
description
"SSH host keys are only sent when the progress type
is 'bootstrap-complete'.";
}
description
"A list of SSH host keys an NMS may use to authenticate
subsequent SSH-based connections to this device (e.g.,
netconf-ssh, netconf-ch-ssh).";
list ssh-host-key {
description
"An SSH host key an NMS may use to authenticate
subsequent SSH-based connections to this device
(e.g., netconf-ssh and netconf-ch-ssh).";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
leaf algorithm {
type string;
mandatory true;
description
"The public key algorithm name for this SSH key.
}
mandatory true;
description
"The type of progress report provided.";
}
leaf message {
type string;
description
"An optional arbitrary value.";
}
container ssh-host-keys {
when "../progress-type = 'bootstrap-complete'" {
description
"SSH host keys are only sent when the progress type
is 'bootstrap-complete'.";
}
description
"A list of SSH host keys an NMS may use to authenticate
subsequent SSH-based connections to this device (e.g.,
netconf-ssh, netconf-ch-ssh).";
list ssh-host-key {
description
"An SSH host key an NMS may use to authenticate
subsequent SSH-based connections to this device
(e.g., netconf-ssh and netconf-ch-ssh).";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
leaf algorithm {
type string;
mandatory true;
description
"The public key algorithm name for this SSH key.
Valid values are listed in the 'Public Key Algorithm
Names' subregistry of the 'Secure Shell (SSH) Protocol
Parameters' registry maintained by IANA.";
reference
"RFC 4250: The Secure Shell (SSH) Protocol Assigned
Numbers
IANA URL: <https://www.iana.org/assignments/ssh-para\\
meters>
('\\' added for formatting reasons)";
}
leaf key-data {
type binary;
mandatory true;
description
Valid values are listed in the 'Public Key Algorithm
Names' subregistry of the 'Secure Shell (SSH) Protocol
Parameters' registry maintained by IANA.";
reference
"RFC 4250: The Secure Shell (SSH) Protocol Assigned
Numbers
IANA URL: <https://www.iana.org/assignments/ssh-para\\
meters>
('\\' added for formatting reasons)";
}
leaf key-data {
type binary;
mandatory true;
description
"The binary public key data for this SSH key, as specified by RFC 4253, Section 6.6; that is:
“此SSH密钥的二进制公钥数据，如RFC 4253第6.6节所规定；即：
string certificate or public key format
identifier
byte[n] key/certificate data.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
}
}
}
container trust-anchor-certs {
when "../progress-type = 'bootstrap-complete'" {
description
"Trust anchors are only sent when the progress type
is 'bootstrap-complete'.";
}
description
"A list of trust anchor certificates an NMS may use to
authenticate subsequent certificate-based connections
to this device (e.g., restconf-tls, netconf-tls, or
even netconf-ssh with X.509 support from RFC 6187).
In practice, trust anchors for IDevID certificates do
not need to be conveyed using this mechanism.";
reference
"RFC 6187: X.509v3 Certificates for Secure Shell
Authentication";
leaf-list trust-anchor-cert {
type cms;
description
"A CMS structure whose topmost content type MUST be the
signed-data content type, as described by Section 5 of
RFC 5652.
string certificate or public key format
identifier
byte[n] key/certificate data.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
}
}
}
container trust-anchor-certs {
when "../progress-type = 'bootstrap-complete'" {
description
"Trust anchors are only sent when the progress type
is 'bootstrap-complete'.";
}
description
"A list of trust anchor certificates an NMS may use to
authenticate subsequent certificate-based connections
to this device (e.g., restconf-tls, netconf-tls, or
even netconf-ssh with X.509 support from RFC 6187).
In practice, trust anchors for IDevID certificates do
not need to be conveyed using this mechanism.";
reference
"RFC 6187: X.509v3 Certificates for Secure Shell
Authentication";
leaf-list trust-anchor-cert {
type cms;
description
"A CMS structure whose topmost content type MUST be the
signed-data content type, as described by Section 5 of
RFC 5652.
The CMS MUST contain the chain of X.509 certificates needed to authenticate the certificate presented by the device.
CMS必须包含验证设备提供的证书所需的X.509证书链。
The CMS MUST contain only a single chain of certificates. The last certificate in the chain MUST be the issuer for the device's end-entity certificate.
CMS必须只包含一个证书链。链中的最后一个证书必须是设备的终端实体证书的颁发者。
In all cases, the chain MUST include a self-signed root certificate. In the case where the root certificate is itself the issuer of the device's end-entity certificate, only one certificate is
在所有情况下，链必须包括自签名根证书。在根证书本身是设备的终端实体证书的颁发者的情况下，只需要一个证书
present.
目前
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List
(CRL) Profile
RFC 5652: Cryptographic Message Syntax (CMS)";
}
}
}
}
}
<CODE ENDS>
This CMS encodes the degenerate form of the SignedData
structure that is commonly used to disseminate X.509
certificates and revocation objects (RFC 5280).";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List
(CRL) Profile
RFC 5652: Cryptographic Message Syntax (CMS)";
}
}
}
}
}
<CODE ENDS>
This section defines two DHCP options: one for DHCPv4 and one for DHCPv6. These two options are semantically the same, though syntactically different.
本节定义了两个DHCP选项：一个用于DHCPv4，一个用于DHCPv6。这两个选项在语义上相同，但在语法上不同。
The DHCPv4 SZTP Redirect Option is used to provision the client with one or more URIs for bootstrap servers that can be contacted to attempt further configuration.
DHCPv4 SZTP重定向选项用于为客户端提供一个或多个用于引导服务器的URI，可以联系这些URI以尝试进一步配置。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code (143) | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. bootstrap-server-list (variable length) .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code (143) | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. bootstrap-server-list (variable length) .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
* option-code: OPTION_V4_SZTP_REDIRECT (143) * option-length: The option length in octets. * bootstrap-server-list: A list of servers for the client to attempt contacting, in order to obtain further bootstrapping data, in the format shown in Section 8.3.
* 选项代码：选项4\U SZTP\U重定向（143）*选项长度：以八位字节为单位的选项长度。*引导服务器列表：客户端尝试联系的服务器列表，以获取更多引导数据，格式如第8.3节所示。
DHCPv4 SZTP Redirect Option
DHCPv4 SZTP重定向选项
DHCPv4 Client Behavior
DHCPv4客户端行为
Clients MAY request the OPTION_V4_SZTP_REDIRECT option by including its option code in the Parameter Request List (55) in DHCP request messages.
客户端可以通过在DHCP请求消息的参数请求列表（55）中包含选项代码来请求选项_V4_SZTP_重定向选项。
On receipt of a DHCPv4 Reply message that contains the OPTION_V4_SZTP_REDIRECT option, the client processes the response according to Section 5.5, with the understanding that the "address" and "port" values are encoded in the URIs.
收到包含选项_V4_SZTP_重定向选项的DHCPv4回复消息后，客户机根据第5.5节处理响应，并理解“地址”和“端口”值在URI中编码。
Any invalid URI entries received in the uri-data field are ignored by the client. If the received OPTION_V4_SZTP_REDIRECT option does not contain at least one valid URI entry in the uri-data field, then the client MUST discard the option.
客户端将忽略在URI数据字段中接收到的任何无效URI条目。如果收到的选项_V4_SZTP_REDIRECT选项在URI数据字段中不包含至少一个有效的URI条目，则客户端必须放弃该选项。
As the list of URIs may exceed the maximum allowed length of a single DHCPv4 option (255 octets), the client MUST implement the decoding agent behavior described in [RFC3396], to correctly process a URI list split across a number of received OPTION_V4_SZTP_REDIRECT option instances.
由于URI列表可能超过单个DHCPv4选项（255个八位字节）的最大允许长度，因此客户端必须实现[RFC3396]中描述的解码代理行为，以正确处理跨多个接收选项\u V4\u SZTP\u重定向选项实例拆分的URI列表。
DHCPv4 Server Behavior
DHCPv4服务器行为
The DHCPv4 server MAY include a single instance of the OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends. Servers MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT option.
DHCPv4服务器可以在其发送的DHCP消息中包含选项_V4_SZTP_重定向选项的单个实例。服务器不能发送多个选项_V4_SZTP_重定向选项的实例。
The server's DHCP message MUST contain only a single instance of the OPTION_V4_SZTP_REDIRECT's 'bootstrap-server-list' field. However, the list of URIs in this field may exceed the maximum allowed length of a single DHCPv4 option (per [RFC3396]).
服务器的DHCP消息必须仅包含选项\u V4\u SZTP\u重定向的“引导服务器列表”字段的单个实例。但是，此字段中的URI列表可能超过单个DHCPv4选项的最大允许长度（根据[RFC3396]）。
If the length of 'bootstrap-server-list' is small enough to fit into a single instance of OPTION_V4_SZTP_REDIRECT, the server MUST NOT send more than one instance of this option.
如果“引导服务器列表”的长度足够小，足以容纳OPTION_V4_SZTP_REDIRECT的单个实例，则服务器不得发送此选项的多个实例。
If the length of the 'bootstrap-server-list' field is too large to fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split into multiple instances of the option according to the process described in [RFC3396].
如果“引导服务器列表”字段的长度太大，无法容纳单个选项，则必须根据[RFC3396]中描述的过程将选项_V4_SZTP_重定向拆分为该选项的多个实例。
The DHCPv6 SZTP Redirect Option is used to provision the client with one or more URIs for bootstrap servers that can be contacted to attempt further configuration.
DHCPv6 SZTP重定向选项用于为客户端提供一个或多个用于引导服务器的URI，可以联系这些URI以尝试进一步配置。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code (136) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. bootstrap-server-list (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code (136) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. bootstrap-server-list (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* option-code: OPTION_V6_SZTP_REDIRECT (136) * option-length: The option length in octets. * bootstrap-server-list: A list of servers for the client to attempt contacting, in order to obtain further bootstrapping data, in the format shown in Section 8.3.
* 选项代码：选项6\U SZTP\U重定向（136）*选项长度：以八位字节为单位的选项长度。*引导服务器列表：客户端尝试联系的服务器列表，以获取更多引导数据，格式如第8.3节所示。
DHCPv6 SZTP Redirect Option
DHCPv6 SZTP重定向选项
DHCPv6 Client Behavior
DHCPv6客户端行为
Clients MAY request OPTION_V6_SZTP_REDIRECT using the process defined in [RFC8415], Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request option.
客户可以使用[RFC8415]第18.2.1节、第18.2.2节、第18.2.4节、第18.2.5节、第18.2.6节和第21.7节中定义的流程请求OPTION_V6_SZTP_重定向。为了方便读者，我们在这里提到，客户机在选项请求选项中包含请求的选项代码。
On receipt of a DHCPv6 Reply message that contains the OPTION_V6_SZTP_REDIRECT option, the client processes the response according to Section 5.5, with the understanding that the "address" and "port" values are encoded in the URIs.
收到包含选项_V6_SZTP_重定向选项的DHCPv6回复消息后，客户机根据第5.5节处理响应，并理解“地址”和“端口”值在URI中编码。
Any invalid URI entries received in the uri-data field are ignored by the client. If the received OPTION_V6_SZTP_REDIRECT option does not contain at least one valid URI entry in the uri-data field, then the client MUST discard the option.
客户端将忽略在URI数据字段中接收到的任何无效URI条目。如果收到的选项_V6_SZTP_REDIRECT选项在URI数据字段中不包含至少一个有效的URI条目，则客户端必须放弃该选项。
DHCPv6 Server Behavior
DHCPv6服务器行为
Section 18.3 of [RFC8415] governs server operation in regard to option assignment. As a convenience to the reader, we mention here that the server will send a particular option code only if configured with specific values for that option code and if the client requested it.
[RFC8415]第18.3节规定了与选项分配有关的服务器操作。为了方便读者，我们在这里提到，只有在为该选项代码配置了特定值并且客户端请求时，服务器才会发送特定的选项代码。
The OPTION_V6_SZTP_REDIRECT option is a singleton. Servers MUST NOT send more than one instance of this option.
选项_V6_SZTP_重定向选项是一个单例。服务器不能发送此选项的多个实例。
Both of the DHCPv4 and DHCPv6 options defined in this section encode a list of bootstrap server URIs. The "URI" structure is a DHCP option that can contain multiple URIs (see [RFC7227], Section 5.7). Each URI entry in the bootstrap-server-list is structured as follows:
本节中定义的DHCPv4和DHCPv6选项都对引导服务器URI列表进行编码。“URI”结构是一个DHCP选项，可以包含多个URI（请参阅[RFC7227]，第5.7节）。引导服务器列表中的每个URI条目的结构如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
* uri-length: 2 octets long; specifies the length of the URI data. * URI: URI of the SZTP bootstrap server.
* uri长度：2个八位字节长；指定URI数据的长度。*URI:SZTP引导服务器的URI。
The URI of the SZTP bootstrap server MUST use the "https" URI scheme defined in Section 2.7.2 of [RFC7230], and it MUST be in form "https://<ip-address-or-hostname>[:<port>]".
SZTP引导服务器的URI必须使用[RFC7230]第2.7.2节中定义的“https”URI方案，并且其格式必须为“https://<ip地址或主机名>[：<port>]”。
The solution in this document relies on TLS certificates, owner certificates, and ownership vouchers, all of which require an accurate clock in order to be processed correctly (e.g., to test validity dates and revocation status). Implementations SHOULD ensure devices have an accurate clock when shipped from manufacturing facilities and take steps to prevent clock tampering.
本文档中的解决方案依赖于TLS证书、所有者证书和所有权凭证，所有这些证书都需要精确的时钟才能正确处理（例如，测试有效日期和撤销状态）。实施时应确保设备从制造厂发货时具有准确的时钟，并采取措施防止时钟篡改。
If it is not possible to ensure clock accuracy, it is RECOMMENDED that implementations disable the aspects of the solution having clock sensitivity. In particular, such implementations should assume that TLS certificates, ownership vouchers, and owner certificates never expire and are not revocable. From an ownership voucher perspective, manufacturers SHOULD issue a single ownership voucher for the lifetime of such devices.
如果无法确保时钟精度，建议实施禁用具有时钟灵敏度的解决方案。特别是，此类实现应假定TLS证书、所有权凭证和所有者证书永不过期且不可撤销。从所有权凭证的角度来看，制造商应为此类设备的使用寿命签发一份所有权凭证。
Implementations SHOULD NOT rely on NTP for time, as NTP is not a secure protocol at this time. Note that there is an IETF document that focuses on securing NTP [NTS-NTP].
实现在时间上不应该依赖于NTP，因为NTP目前不是一个安全的协议。注意，有一份IETF文件的重点是保护NTP[NTS-NTP]。
IDevID certificates, as defined in [Std-802.1AR], are RECOMMENDED, both for the TLS-level client certificate used by devices when connecting to a bootstrap server, as well as for the device identity certificate used by owners when encrypting the SZTP bootstrapping data artifacts.
建议使用[Std-802.1AR]中定义的IDevID证书，用于连接到引导服务器时设备使用的TLS级客户端证书，以及所有者在加密SZTP引导数据工件时使用的设备标识证书。
Devices MUST ensure that all their trust anchor certificates, including those for connecting to bootstrap servers and verifying ownership vouchers, are protected from external modification.
设备必须确保其所有信任锚证书（包括用于连接引导服务器和验证所有权凭证的证书）都受到保护，不受外部修改。
It may be necessary to update these certificates over time (e.g., the manufacturer wants to delegate trust to a new CA). It is therefore expected that devices MAY update these trust anchors when needed through a verifiable process, such as a software upgrade using signed software images.
可能需要随时间更新这些证书（例如，制造商希望将信任委托给新的CA）。因此，期望设备可以在需要时通过可验证的过程（例如使用签名软件映像的软件升级）来更新这些信任锚。
Manufacturer-generated device identifiers may have very long lifetimes. For instance, [Std-802.1AR] recommends using the "notAfter" value 99991231235959Z in IDevID certificates. Given the long-lived nature of these private keys, it is paramount that they are stored so as to resist discovery, such as in a secure cryptographic processor (e.g., a trusted platform module (TPM) chip).
制造商生成的设备标识符可能有很长的使用寿命。例如，[Std-802.1AR]建议在IDevID证书中使用“notAfter”值99991231235959Z。鉴于这些私钥的长寿命性质，至关重要的是，它们的存储应能抵抗发现，例如在安全密码处理器（例如，可信平台模块（TPM）芯片）中。
This document allows a device to blindly authenticate a bootstrap server's TLS certificate. It does so to allow for cases where the redirect information may be obtained in an unsecured manner, which is desirable to support in some cases.
此文档允许设备对引导服务器的TLS证书进行盲式身份验证。这样做是为了允许以不安全的方式获得重定向信息的情况，这在某些情况下是需要支持的。
To compensate for this, this document requires that devices, when connected to an untrusted bootstrap server, assert that data downloaded from the server is signed.
为了弥补这一点，本文档要求设备在连接到不受信任的引导服务器时，声明从服务器下载的数据已签名。
This document allows devices to establish connections to untrusted bootstrap servers. However, since the bootstrap server is untrusted, it may be under the control of an adversary; therefore, devices SHOULD be cautious about the data they send to the bootstrap server in such cases.
此文档允许设备与不受信任的引导服务器建立连接。但是，由于引导服务器不受信任，它可能处于对手的控制之下；因此，在这种情况下，设备应该小心发送到引导服务器的数据。
Devices send different data to bootstrap servers at each of the protocol layers: TCP, TLS, HTTP, and RESTCONF.
设备向每个协议层的引导服务器发送不同的数据：TCP、TLS、HTTP和RESTCONF。
At the TCP protocol layer, devices may relay their IP address, subject to network translations. Disclosure of this information is not considered a security risk.
在TCP协议层，设备可以根据网络翻译中继其IP地址。披露此信息不被视为安全风险。
At the TLS protocol layer, devices may use a client certificate to identify and authenticate themselves to untrusted bootstrap servers. At a minimum, the client certificate must disclose the device's serial number and may disclose additional information such as the device's manufacturer, hardware model, public key, etc. Knowledge of this information may provide an adversary with details needed to launch an attack. It is RECOMMENDED that secrecy of the network constituency not be relied on for security.
在TLS协议层，设备可以使用客户端证书向不受信任的引导服务器标识和验证自己。至少，客户端证书必须披露设备的序列号，并可能披露其他信息，如设备制造商、硬件型号、公钥等。了解这些信息可能会向对手提供发起攻击所需的详细信息。建议不要依赖网络选区的保密性来确保安全。
At the HTTP protocol layer, devices may use an HTTP authentication scheme to identify and authenticate themselves to untrusted bootstrap servers. At a minimum, the authentication scheme must disclose the device's serial number and, concerningly, may, depending on the authentication mechanism used, reveal a secret that is only supposed to be known to the device (e.g., a password). Devices SHOULD NOT use an HTTP authentication scheme (e.g., HTTP Basic) with an untrusted bootstrap server that reveals a secret that is only supposed to be known to the device.
在HTTP协议层，设备可以使用HTTP身份验证方案向不受信任的引导服务器标识和验证自己。至少，认证方案必须披露设备的序列号，并且，根据所使用的认证机制，认证方案可能会披露仅假定设备知道的秘密（例如，密码）。设备不应将HTTP身份验证方案（例如HTTP Basic）与不受信任的引导服务器一起使用，因为该服务器会泄露仅应为设备所知的秘密。
At the RESTCONF protocol layer, devices use the "get-bootstrapping-data" RPC, but not the "report-progress" RPC, when connected to an untrusted bootstrap server. The "get-bootstrapping-data" RPC allows additional input parameters to be passed to the bootstrap server (e.g., "os-name", "os-version", and "hw-model"). It is RECOMMENDED that devices only pass the "signed-data-preferred" input parameter to an untrusted bootstrap server. While it is okay for a bootstrap server to immediately return signed onboarding information, it is RECOMMENDED that bootstrap servers instead promote the untrusted connection to a trusted connection, as described in Appendix B, thus enabling the device to use the "report-progress" RPC while processing the onboarding information.
在RESTCONF协议层，当连接到不受信任的引导服务器时，设备使用“获取引导数据”RPC，而不是“报告进度”RPC。“获取引导数据”RPC允许向引导服务器传递额外的输入参数（例如，“os名称”、“os版本”和“hw模型”）。建议设备仅将“已签名数据首选”输入参数传递给不受信任的引导服务器。虽然引导服务器可以立即返回已签名的登录信息，但建议引导服务器将不受信任的连接升级为受信任的连接，如附录B所述，从而使设备能够在处理登录信息时使用“报告进度”RPC。
For devices supporting more than one source for bootstrapping data, no particular sequencing order has to be observed for security reasons, as the solution for each source is considered equally secure. However, from a privacy perspective, it is RECOMMENDED that devices access local sources before accessing remote sources.
对于支持多个数据源的设备，由于安全原因，不必遵守特定的排序顺序，因为每个数据源的解决方案都被认为是同等安全的。但是，从隐私角度来看，建议设备在访问远程源之前访问本地源。
The solution presented in this document enables bootstrapping data to be trusted in two ways: through either transport-level security or the signing of artifacts.
本文档中提供的解决方案通过两种方式使引导数据可信：通过传输级安全性或工件签名。
When transport-level security (i.e., a trusted bootstrap server) is used, the private key for the end-entity certificate must be online in order to establish the TLS connection.
当使用传输级安全性（即受信任的引导服务器）时，终端实体证书的私钥必须在线，以便建立TLS连接。
When artifacts are signed, the signing key is required to be online only when the bootstrap server is returning a dynamically generated signed-data response. For instance, a bootstrap server, upon receiving the "signed-data-preferred" input parameter to the "get-bootstrapping-data" RPC, may dynamically generate a response that is signed.
对工件进行签名时，仅当引导服务器返回动态生成的签名数据响应时，签名密钥才需要在线。例如，引导服务器在接收到“get bootstrapping data”RPC的“signed data preferred”输入参数后，可以动态生成已签名的响应。
Bootstrap server administrators are RECOMMENDED to follow best practices to protect the private key used for any online operation. For instance, use of a hardware security module (HSM) is RECOMMENDED. If an HSM is not used, frequent private key refreshes are RECOMMENDED, assuming all bootstrapping devices have an accurate clock (see Section 9.1).
建议引导服务器管理员遵循最佳实践，以保护用于任何联机操作的私钥。例如，建议使用硬件安全模块（HSM）。如果未使用HSM，建议频繁刷新私钥，前提是所有引导设备都有准确的时钟（见第9.1节）。
For best security, it is RECOMMENDED that owners only provide bootstrapping data that has been signed (using a protected private key) and encrypted (using the device's public key from its secure device identity certificate).
为获得最佳安全性，建议所有者仅提供已签名（使用受保护的私钥）和加密（使用设备安全设备标识证书中的公钥）的引导数据。
The SZTP bootstrapping protocol presented in this document shifts some control of initial configuration away from the rightful owner of the device and towards the manufacturer and its delegates.
本文介绍的SZTP引导协议将初始配置的一些控制权从设备的合法所有者转移到制造商及其代表。
The manufacturer maintains the list of well-known bootstrap servers its devices will trust. By design, if no bootstrapping data is found via other methods first, the device will try to reach out to the well-known bootstrap servers. There is no mechanism to prevent this from occurring other than by using an external firewall to block such connections. Concerns related to trusted bootstrap servers are discussed in Section 9.10.
制造商维护其设备信任的知名引导服务器列表。根据设计，如果没有通过其他方法首先找到引导数据，设备将尝试接触知名的引导服务器。除了使用外部防火墙阻止此类连接之外，没有其他机制可以防止这种情况发生。第9.10节讨论了与可信引导服务器相关的问题。
Similarly, the manufacturer maintains the list of voucher-signing authorities its devices will trust. The voucher-signing authorities issue the vouchers that enable a device to trust an owner's domain
同样，制造商维护其设备将信任的凭证签署机构列表。凭证签署机构颁发凭证，使设备能够信任所有者的域
certificate. It is vital that manufacturers ensure the integrity of these voucher-signing authorities, so as to avoid incorrect assignments.
证明书制造商必须确保这些凭证签署机构的完整性，以避免错误的分配。
Operators should be aware that this system assumes that they trust all the pre-configured bootstrap servers and voucher-signing authorities designated by the manufacturers. While operators may use points in the network to block access to the well-known bootstrap servers, operators cannot prevent voucher-signing authorities from generating vouchers for their devices.
操作员应注意，此系统假定他们信任制造商指定的所有预配置引导服务器和凭证签署机构。虽然运营商可以使用网络中的点来阻止对众所周知的引导服务器的访问，但运营商无法阻止凭证签署机构为其设备生成凭证。
Trusted bootstrap servers, whether well-known or discovered, have the potential to cause problems, such as the following.
受信任的引导服务器，无论是已知的还是已发现的，都有可能导致以下问题。
o A trusted bootstrap server that has been compromised may be modified to return unsigned data of any sort. For instance, a bootstrap server that is only supposed to return redirect information might be modified to return onboarding information. Similarly, a bootstrap server that is only supposed to return signed data may be modified to return unsigned data. In both cases, the device will accept the response, unaware that it wasn't supposed to be any different. It is RECOMMENDED that maintainers of trusted bootstrap servers ensure that their systems are not easily compromised and, in case of compromise, have mechanisms in place to detect and remediate the compromise as expediently as possible.
o 可能会修改已受损的受信任引导服务器，以返回任何类型的未签名数据。例如，一个只应该返回重定向信息的引导服务器可能会被修改为返回入职信息。类似地，只应返回有符号数据的引导服务器可能会被修改为返回无符号数据。在这两种情况下，设备都会接受响应，而不会意识到响应应该没有任何不同。建议可信引导服务器的维护人员确保其系统不易受到危害，并且在发生危害的情况下，有适当的机制尽可能方便地检测和补救危害。
o A trusted bootstrap server hosting data that is either unsigned or signed but not encrypted may disclose information to unwanted parties (e.g., an administrator of the bootstrap server). This is a privacy issue only, but it could reveal information that might be used in a subsequent attack. Disclosure of redirect information has limited exposure (it is just a list of bootstrap servers), whereas disclosure of onboarding information could be highly revealing (e.g., network topology, firewall policies, etc.). It is RECOMMENDED that operators encrypt the bootstrapping data when its contents are considered sensitive, even to the point of hiding it from the administrators of the bootstrap server, which may be maintained by a third party.
o 托管未签名或已签名但未加密数据的受信任引导服务器可能会将信息泄露给不需要的方（例如，引导服务器的管理员）。这只是一个隐私问题，但可能会泄露可能用于后续攻击的信息。重定向信息的披露具有有限的公开性（它只是一个引导服务器列表），而登录信息的披露可能具有高度的公开性（例如，网络拓扑、防火墙策略等）。当引导数据的内容被认为是敏感的时，建议操作员对其进行加密，甚至对引导服务器的管理员隐藏，引导服务器可能由第三方维护。
The conveyed information artifact does not specify a validity period. For instance, neither redirect information nor onboarding information enable "not-before" or "not-after" values to be specified, and neither artifact alone can be revoked.
传递的信息工件没有指定有效期。例如，重定向信息和入职信息都不允许指定“notbefore”或“notbefore”值，也不允许单独撤销工件。
For unsigned data provided by an untrusted source of bootstrapping data, it is not meaningful to discuss its validity period when the information itself has no authenticity and may have come from anywhere.
对于由不受信任的引导数据源提供的未签名数据，当信息本身没有真实性且可能来自任何地方时，讨论其有效期是没有意义的。
For unsigned data provided by a trusted source of bootstrapping data (i.e., a bootstrap server), the availability of the data is the only measure of it being current. Since the untrusted data comes from a trusted source, its current availability is meaningful, and since bootstrap servers use TLS, the contents of the exchange cannot be modified or replayed.
对于由受信任的引导数据源（即引导服务器）提供的未签名数据，数据的可用性是衡量其当前状态的唯一标准。由于不受信任的数据来自受信任的源，因此其当前可用性是有意义的，并且由于引导服务器使用TLS，因此无法修改或重播exchange的内容。
For signed data, whether provided by an untrusted or trusted source of bootstrapping data, the validity is constrained by the validity of both the ownership voucher and owner certificate used to authenticate it.
对于签名数据，无论是由不受信任的还是受信任的引导数据源提供的，其有效性都受到用于对其进行身份验证的所有权凭证和所有者证书的有效性的约束。
The ownership voucher's validity is primarily constrained by the ownership voucher's "created-on" and "expires-on" nodes. While [RFC8366] recommends short-lived vouchers (see Section 6.1), the "expires-on" node may be set to any point in the future or omitted altogether to indicate that the voucher never expires. The ownership voucher's validity is secondarily constrained by the manufacturer's PKI used to sign the voucher; whilst an ownership voucher cannot be revoked directly, the PKI used to sign it may be.
所有权凭证的有效性主要受所有权凭证的“创建日期”和“到期日期”节点的约束。虽然[RFC8366]建议使用短期凭证（参见第6.1节），但“到期日”节点可设置为将来的任何时间点，或完全忽略，以表示凭证永不过期。所有权凭证的有效性其次受到制造商用于签署凭证的PKI的约束；虽然所有权凭证不能直接撤销，但用于签署该凭证的PKI可能会被撤销。
The owner certificate's validity is primarily constrained by the X.509's validity field, the "notBefore" and "notAfter" values, as specified by the certificate authority that signed it. The owner certificate's validity is secondarily constrained by the validity of the PKI used to sign the voucher. Owner certificates may be revoked directly.
所有者证书的有效性主要受X.509的有效性字段、“notBefore”和“notAfter”值的约束，这些值由签署证书的证书颁发机构指定。所有者证书的有效性其次受到用于签署凭证的PKI的有效性的约束。业主证书可直接撤销。
For owners that wish to have maximum flexibility in their ability to specify and constrain the validity of signed data, it is RECOMMENDED that a unique owner certificate be created for each signed artifact. Not only does this enable a validity period to be specified, for each artifact, but it also enables the validity of each artifact to be revoked.
对于希望在指定和约束签名数据的有效性方面具有最大灵活性的所有者，建议为每个签名工件创建唯一的所有者证书。这不仅允许为每个工件指定有效期，还允许撤销每个工件的有效期。
Redirect information (Section 2.1), by design, instructs a bootstrapping device to initiate an HTTPS connection to the specified bootstrap servers.
重定向信息（第2.1节）在设计上指示引导设备启动到指定引导服务器的HTTPS连接。
When the redirect information is trusted, the redirect information can encode a trust anchor certificate used by the device to
当重定向信息受信任时，重定向信息可以对设备使用的信任锚证书进行编码，以
authenticate the TLS end-entity certificate presented by each bootstrap server.
验证每个引导服务器提供的TLS终端实体证书。
As a result, any compromise in an interaction providing redirect information may result in compromise of all subsequent interactions.
因此，提供重定向信息的交互中的任何妥协都可能导致所有后续交互的妥协。
This document describes two uses for secure device identity certificates.
本文档描述了安全设备标识证书的两种用途。
The primary use is for when the device authenticates itself to a bootstrap server, using its private key for TLS-level client-certificate-based authentication.
主要用途是当设备向引导服务器进行身份验证时，使用其私钥进行TLS级别的客户端基于证书的身份验证。
A secondary use is for when the device needs to decrypt provided bootstrapping artifacts, using its private key to decrypt the data or, more precisely, per Section 6 of [RFC5652], decrypt a symmetric key used to decrypt the data.
第二个用途是当设备需要解密提供的引导工件时，使用其私钥解密数据，或者更准确地说，根据[RFC5652]第6节，解密用于解密数据的对称密钥。
Section 3.4 of this document allows for the possibility that the same secure device identity certificate is utilized for both uses, as [Std-802.1AR] states that a DevID certificate MAY have the "keyEncipherment" KeyUsage bit, in addition to the "digitalSignature" KeyUsage bit, set.
本文件第3.4节允许将相同的安全设备身份证书用于两种用途，因为[Std-802.1AR]规定，除设置“数字签名”密钥使用位外，device证书还可以设置“密钥加密”密钥使用位。
While it is understood that it is generally frowned upon to reuse private keys, this document views such reuse acceptable as there are not any known ways to cause a signature made in one context to be (mis)interpreted as valid in the other context.
虽然一般不赞成重用私钥，但本文档认为这种重用是可以接受的，因为没有任何已知的方法可以导致在一个上下文中生成的签名在另一个上下文中被（错误地）解释为有效。
This document specifies the encryption of signed objects, as opposed to the signing of encrypted objects, as might be expected given well-publicized oracle attacks (e.g., the padding oracle attack).
本文档规定了已签名对象的加密，而不是加密对象的签名，这可能是在公开的oracle攻击（例如，填充oracle攻击）的情况下所期望的。
This document does not view such attacks as feasible in the context of the solution because the decrypted text never leaves the device.
本文档不认为此类攻击在解决方案的上下文中是可行的，因为解密文本从未离开设备。
The "ietf-sztp-conveyed-info" module defined in this document defines a data structure that is always wrapped by a CMS structure. When accessed by a secure mechanism (e.g., protected by TLS), then the CMS structure may be unsigned. However, when accessed by an insecure mechanism (e.g., a removable storage device), the CMS structure must be signed, in order for the device to trust it.
本文件中定义的“ietf sztp传输信息”模块定义了一个始终由CMS结构包装的数据结构。当通过安全机制（例如，受TLS保护）访问时，CMS结构可能未签名。但是，当被不安全机制（例如，可移动存储设备）访问时，必须对CMS结构进行签名，以便设备信任它。
Implementations should be aware that signed bootstrapping data only protects the data from modification and that the content is still visible to others. This doesn't affect security so much as privacy. That the contents may be read by unintended parties when accessed by insecure mechanisms is considered next.
实现应该知道，经过签名的引导数据只会保护数据不被修改，并且内容对其他人仍然可见。这与其说影响安全，不如说影响隐私。下一步考虑的是，当被不安全的机制访问时，内容可能会被非预期方读取。
The "ietf-sztp-conveyed-info" module defines a top-level "choice" statement that declares the content is either redirect-information or onboarding-information. Each of these two cases are now considered.
“ietf sztp传输信息”模块定义了一个顶级“选择”语句，声明内容是重定向信息或入职信息。这两种情况现在都在考虑之中。
When the content of the CMS structure is redirect-information, an observer can learn about the bootstrap servers the device is being directed to, their IP addresses or hostnames, ports, and trust anchor certificates. Knowledge of this information could provide an observer some insight into a network's inner structure.
当CMS结构的内容是重定向信息时，观察者可以了解设备被定向到的引导服务器、它们的IP地址或主机名、端口和信任锚证书。了解这些信息可以让观察者对网络的内部结构有所了解。
When the content of the CMS structure is onboarding-information, an observer could learn considerable information about how the device is to be provisioned. This information includes the operating system version, initial configuration, and script contents. This information should be considered sensitive, and precautions should be taken to protect it (e.g., encrypt the artifact using the device's public key).
当CMS结构的内容是载入信息时，观察者可以了解关于如何配置设备的大量信息。此信息包括操作系统版本、初始配置和脚本内容。该信息应被视为敏感信息，并应采取预防措施对其进行保护（例如，使用设备的公钥加密工件）。
The "ietf-sztp-bootstrap-server" module defined in this document specifies an API for a RESTCONF [RFC8040]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
本文档中定义的“ietf sztp引导服务器”模块指定RESTCONF[RFC8040]的API。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC8446]。
The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular users to a pre-configured subset of all available protocol operations and content.
NETCONF访问控制模型（NACM）[RFC8341]提供了将特定用户的访问限制为所有可用协议操作和内容的预配置子集的方法。
This module presents no data nodes (only RPCs). There is no need to discuss the sensitivity of data nodes.
此模块不显示数据节点（仅显示RPC）。没有必要讨论数据节点的敏感性。
This module defines two RPC operations that may be considered sensitive in some network environments. These are the operations and their sensitivity/vulnerability:
此模块定义了在某些网络环境中可能被视为敏感的两个RPC操作。这些是操作及其敏感性/脆弱性：
get-bootstrapping-data: This RPC is used by devices to obtain their bootstrapping data. By design, each device, as identified by its authentication credentials (e.g., client certificate), can only obtain its own data. NACM is not needed to further constrain access to this RPC.
获取引导数据：设备使用此RPC获取其引导数据。根据设计，每个设备（由其身份验证凭据（例如，客户端证书）标识）只能获取自己的数据。不需要NACM来进一步限制对此RPC的访问。
report-progress: This RPC is used by devices to report their bootstrapping progress. By design, each device, as identified by its authentication credentials (e.g., client certificate), can only report data for itself. NACM is not needed to further constrain access to this RPC.
报告进度：设备使用此RPC报告其引导进度。根据设计，每个设备（由其身份验证凭据（例如，客户端证书）标识）只能为自己报告数据。不需要NACM来进一步限制对此RPC的访问。
IANA has registered two URIs in the "ns" subregistry of the "IETF XML Registry" [RFC3688] maintained at <https://www.iana.org/assignments/ xml-registry>. The following registrations have been made per the format in [RFC3688]:
IANA已在“IETF XML注册表”[RFC3688]的“ns”子区注册了两个URI，该注册表位于<https://www.iana.org/assignments/ xml注册表>。已按照[RFC3688]中的格式进行了以下注册：
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf sztp传达信息注册人联系人：ietf的NETCONF工作组。XML:N/A，请求的URI是一个XML名称空间。
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf sztp引导服务器注册人联系人：ietf的NETCONF工作组。XML:N/A，请求的URI是一个XML名称空间。
IANA has registered two YANG modules in the "YANG Module Names" registry [RFC6020] maintained at <https://www.iana.org/assignments/ yang-parameters>. The following registrations have been made per the format in [RFC6020]:
IANA已在位于的“YANG模块名称”注册表[RFC6020]中注册了两个YANG模块<https://www.iana.org/assignments/ 杨参数>。已按照[RFC6020]中的格式进行了以下注册：
name: ietf-sztp-conveyed-info
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info
prefix: sztp-info
reference: RFC 8572
name: ietf-sztp-conveyed-info
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info
prefix: sztp-info
reference: RFC 8572
name: ietf-sztp-bootstrap-server
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server
prefix: sztp-svr
reference: RFC 8572
name: ietf-sztp-bootstrap-server
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server
prefix: sztp-svr
reference: RFC 8572
IANA has registered two subordinate object identifiers in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry maintained at <https://www.iana.org/assignments/ smi-numbers>. The following registrations have been made per the format in Section 3.4 of [RFC7107]:
IANA已在“S/MIME CMS内容类型的SMI安全性（1.2.840.113549.1.9.16.1）”注册表中注册了两个从属对象标识符，该注册表位于<https://www.iana.org/assignments/ smi编号>。已按照[RFC7107]第3.4节中的格式进行了以下注册：
Decimal Description References
------- -------------------------- ----------
42 id-ct-sztpConveyedInfoXML RFC 8572
43 id-ct-sztpConveyedInfoJSON RFC 8572
Decimal Description References
------- -------------------------- ----------
42 id-ct-sztpConveyedInfoXML RFC 8572
43 id-ct-sztpConveyedInfoJSON RFC 8572
id-ct-sztpConveyedInfoXML indicates that the "conveyed-information" is encoded using XML. id-ct-sztpConveyedInfoJSON indicates that the "conveyed-information" is encoded using JSON.
id ct sztpconferredinfoxml表示“传递的信息”是使用XML编码的。id ct sztpconferredinfojson表示“传递的信息”是使用JSON编码的。
IANA has registered one DHCP code point in the "BOOTP Vendor Extensions and DHCP Options" registry maintained at <https://www.iana.org/assignments/bootp-dhcp-parameters>:
IANA已在位于的“BOOTP供应商扩展和DHCP选项”注册表中注册了一个DHCP代码点<https://www.iana.org/assignments/bootp-dhcp-parameters>:
Tag: 143 Name: OPTION_V4_SZTP_REDIRECT Data Length: N Meaning: This option provides a list of URIs for SZTP bootstrap servers Reference: RFC 8572
Tag:143 Name:OPTION_V4_SZTP_REDIRECT Data Length:N含义：此选项为SZTP引导服务器提供URI列表参考：RFC 8572
10.5. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry
10.5. IPv6（DHCPv6）注册表的动态主机配置协议
IANA has registered one DHCP code point in the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <https://www.iana.org/assignments/ dhcpv6-parameters>:
IANA已在维护于的“IPv6动态主机配置协议（DHCPv6）”注册表的“选项代码”子区中注册了一个DHCP代码点<https://www.iana.org/assignments/ dhcpv6参数>：
Value: 136 Description: OPTION_V6_SZTP_REDIRECT Client ORO: Yes Singleton Option: Yes Reference: RFC 8572
值：136说明：选项_V6_SZTP_重定向客户端ORO:Yes单例选项：Yes参考：RFC 8572
IANA has registered one service name in the "Service Name and Transport Protocol Port Number Registry" [RFC6335] maintained at <https://www.iana.org/assignments/service-names-port-numbers>. The following registration has been made per the format in Section 8.1.1 of [RFC6335]:
IANA已在维护于的“服务名称和传输协议端口号注册表”[RFC6335]中注册了一个服务名称<https://www.iana.org/assignments/service-names-port-numbers>. 已按照[RFC6335]第8.1.1节中的格式进行了以下登记：
Service Name: sztp Transport Protocol(s): TCP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: This service name is used to construct the SRV service label "_sztp" for discovering SZTP bootstrap servers. Reference: RFC 8572 Port Number: N/A Service Code: N/A Known Unauthorized Uses: N/A Assignment Notes: This protocol uses HTTPS as a substrate.
服务名称：sztp传输协议：TCP受让人：IESG<iesg@ietf.org>联系人：IETF主席<chair@ietf.org>描述：此服务名称用于构造用于发现sztp引导服务器的SRV服务标签“_sztp”。参考：RFC 8572端口号：不适用服务代码：不适用已知未授权使用：不适用分配说明：此协议使用HTTPS作为基底。
IANA has registered one service name in the "Underscored and Globally Scoped DNS Node Names" subregistry [RFC8552] of the "Domain Name System (DNS) Parameters" registry maintained at <https://www.iana.org/assignments/dns-parameters>. The following registration has been made per the format in Section 3 of [RFC8552]:
IANA已在维护于的“域名系统（DNS）参数”注册表的“下划线和全局范围的DNS节点名称”子区域[RFC8552]中注册了一个服务名称<https://www.iana.org/assignments/dns-parameters>. 已按照[RFC8552]第3节中的格式进行了以下注册：
RR Type: TXT _NODE NAME: _sztp Reference: RFC 8572
RR类型：TXT_节点名称：_sztp参考：RFC 8572
[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/>.
[ITU.X690.2015]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.
[RFC3396]Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，DOI 10.17487/RFC3396，2002年11月<https://www.rfc-editor.org/info/rfc3396>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<https://www.rfc-editor.org/info/rfc6762>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<https://www.rfc-editor.org/info/rfc6991>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<https://www.rfc-editor.org/info/rfc7227>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, <https://www.rfc-editor.org/info/rfc8366>.
[RFC8366]Watsen，K.，Richardson，M.，Pritikin，M.，和T.Eckert，“引导协议的凭证工件”，RFC 8366，DOI 10.17487/RFC8366，2018年5月<https://www.rfc-editor.org/info/rfc8366>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415]Mrugalski，T.，Siodelski，M.，Volz，B.，Yourtchenko，A.，Richardson，M.，Jiang，S.，Lemon，T.，和T.Winters，“IPv6动态主机配置协议（DHCPv6）”，RFC 8415，DOI 10.17487/RFC8415，2018年11月<https://www.rfc-editor.org/info/rfc8415>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
[RFC8552]Crocker，D.，“通过带下划线的“属性叶命名”对DNS资源记录的范围解释”，BCP 222，RFC 8552，DOI 10.17487/RFC8552，2019年3月<https://www.rfc-editor.org/info/rfc8552>.
[Std-802.1AR] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR.
[Std-802.1AR]IEEE，“局域网和城域网的IEEE标准-安全设备标识”，IEEE 802.1AR。
[NTS-NTP] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", Work in Progress, draft-ietf-ntp-using-nts-for-ntp-18, April 2019.
[NTS-NTP]Franke，D.，Sibold，D.，Teichel，K.，Dansarie，M.，和R.Sundblad，“网络时间协议的网络时间安全”，正在进行的工作，草案-ietf-NTP-using-NTS-for-NTP-1822019年4月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250]Lehtinen，S.和C.Lonvick，编辑，“安全外壳（SSH）协议分配编号”，RFC 4250，DOI 10.17487/RFC4250，2006年1月<https://www.rfc-editor.org/info/rfc4250>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187]Igoe，K.和D.Stebila，“用于安全外壳身份验证的X.509v3证书”，RFC 6187，DOI 10.17487/RFC6187，2011年3月<https://www.rfc-editor.org/info/rfc6187>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<https://www.rfc-editor.org/info/rfc6234>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<https://www.rfc-editor.org/info/rfc6891>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC7107] Housley, R., "Object Identifier Registry for the S/MIME Mail Security Working Group", RFC 7107, DOI 10.17487/RFC7107, January 2014, <https://www.rfc-editor.org/info/rfc7107>.
[RFC7107]Housley，R.，“S/MIME邮件安全工作组的对象标识符注册表”，RFC 7107，DOI 10.17487/RFC7107，2014年1月<https://www.rfc-editor.org/info/rfc7107>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.
[RFC7766]Dickinson，J.，Dickinson，S.，Bellis，R.，Mankin，A.，和D.Wessels，“TCP上的DNS传输-实施要求”，RFC 7766，DOI 10.17487/RFC7766，2016年3月<https://www.rfc-editor.org/info/rfc7766>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/info/rfc8071>.
[RFC8071]Watsen，K.，“NETCONF呼叫总部和RESTCONF呼叫总部”，RFC 8071，DOI 10.17487/RFC8071，2017年2月<https://www.rfc-editor.org/info/rfc8071>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341]Bierman，A.和M.Bjorklund，“网络配置访问控制模型”，STD 91，RFC 8341，DOI 10.17487/RFC8341，2018年3月<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[YANG-CRYPTO-TYPES] Watsen, K. and H. Wang, "Common YANG Data Types for Cryptography", Work in Progress, draft-ietf-netconf-crypto-types-05, March 2019.
[YANG-CRYPTO-TYPES]Watsen，K.和H.Wang，“用于加密的常见YANG数据类型”，正在进行的工作，草稿-ietf-netconf-CRYPTO-TYPES-052019年3月。
[YANG-TRUST-ANCHORS] Watsen, K., "YANG Data Model for Global Trust Anchors", Work in Progress, draft-ietf-netconf-trust-anchors-03, March 2019.
[YANG-TRUST-ANCHORS]Watsen，K.，“全球信任锚的YANG数据模型”，正在进行的工作，草稿-ietf-netconf-TRUST-ANCHORS-032019年3月。
This section defines a non-normative data model that enables the configuration of SZTP bootstrapping and the discovery of what parameters are used by a device's bootstrapping logic.
本节定义了一个非规范性数据模型，用于配置SZTP引导，并发现设备引导逻辑使用的参数。
The following tree diagram provides an overview for the SZTP device data model.
以下树形图概述了SZTP设备数据模型。
module: example-device-data-model
+--rw sztp
+--rw enabled? boolean
+--ro idevid-certificate? ct:end-entity-cert-cms
| {bootstrap-servers}?
+--ro bootstrap-servers {bootstrap-servers}?
| +--ro bootstrap-server* [address]
| +--ro address inet:host
| +--ro port? inet:port-number
+--ro bootstrap-server-trust-anchors {bootstrap-servers}?
| +--ro reference* ta:pinned-certificates-ref
+--ro voucher-trust-anchors {signed-data}?
+--ro reference* ta:pinned-certificates-ref
module: example-device-data-model
+--rw sztp
+--rw enabled? boolean
+--ro idevid-certificate? ct:end-entity-cert-cms
| {bootstrap-servers}?
+--ro bootstrap-servers {bootstrap-servers}?
| +--ro bootstrap-server* [address]
| +--ro address inet:host
| +--ro port? inet:port-number
+--ro bootstrap-server-trust-anchors {bootstrap-servers}?
| +--ro reference* ta:pinned-certificates-ref
+--ro voucher-trust-anchors {signed-data}?
+--ro reference* ta:pinned-certificates-ref
In the above diagram, notice that there is only one configurable node: "enabled". The expectation is that this node would be set to "true" in the device's factory default configuration and that it would be either set to "false" or deleted when the SZTP bootstrapping is longer needed.
在上图中，请注意只有一个可配置节点：“enabled”。我们期望该节点在设备的出厂默认配置中被设置为“true”，并且当不再需要SZTP引导时，该节点将被设置为“false”或被删除。
Following is an instance example for this data model.
下面是此数据模型的一个实例示例。
<sztp xmlns="https://example.com/sztp-device-data-model">
<enabled>true</enabled>
<idevid-certificate>base64encodedvalue==</idevid-certificate>
<bootstrap-servers>
<bootstrap-server>
<address>sztp1.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp2.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp3.example.com</address>
<port>8443</port>
</bootstrap-server>
</bootstrap-servers>
<bootstrap-server-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</bootstrap-server-trust-anchors>
<voucher-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</voucher-trust-anchors>
</sztp>
<sztp xmlns="https://example.com/sztp-device-data-model">
<enabled>true</enabled>
<idevid-certificate>base64encodedvalue==</idevid-certificate>
<bootstrap-servers>
<bootstrap-server>
<address>sztp1.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp2.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp3.example.com</address>
<port>8443</port>
</bootstrap-server>
</bootstrap-servers>
<bootstrap-server-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</bootstrap-server-trust-anchors>
<voucher-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</voucher-trust-anchors>
</sztp>
The device model is defined by the YANG module defined in this section.
设备型号由本节中定义的模块定义。
This module references [Std-802.1AR] and uses data types defined in [RFC6991], [YANG-CRYPTO-TYPES], and [YANG-TRUST-ANCHORS].
此模块参考[Std-802.1AR]，并使用[RFC6991]、[YANG-CRYPTO-types]和[YANG-TRUST-ANCHORS]中定义的数据类型。
module example-device-data-model {
yang-version 1.1;
namespace "https://example.com/sztp-device-data-model";
prefix sztp-ddm;
module example-device-data-model {
yang-version 1.1;
namespace "https://example.com/sztp-device-data-model";
prefix sztp-ddm;
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-crypto-types {
导入ietf加密类型{
prefix ct;
revision-date 2019-03-09;
description
"ietf-crypto-types is defined in
draft-ietf-netconf-crypto-types";
reference
"draft-ietf-netconf-crypto-types-05:
Common YANG Data Types for Cryptography";
}
prefix ct;
revision-date 2019-03-09;
description
"ietf-crypto-types is defined in
draft-ietf-netconf-crypto-types";
reference
"draft-ietf-netconf-crypto-types-05:
Common YANG Data Types for Cryptography";
}
import ietf-trust-anchors {
prefix ta;
revision-date 2019-03-09;
description
"ietf-trust-anchors is defined in
draft-ietf-netconf-trust-anchors.";
reference
"draft-ietf-netconf-trust-anchors-03:
YANG Data Model for Global Trust Anchors";
}
import ietf-trust-anchors {
prefix ta;
revision-date 2019-03-09;
description
"ietf-trust-anchors is defined in
draft-ietf-netconf-trust-anchors.";
reference
"draft-ietf-netconf-trust-anchors-03:
YANG Data Model for Global Trust Anchors";
}
organization "Example Corporation";
组织“示范公司”；
contact
"Author: Bootstrap Admin <mailto:admin@example.com>";
contact
"Author: Bootstrap Admin <mailto:admin@example.com>";
description "This module defines a data model to enable SZTP bootstrapping and discover what parameters are used. This module assumes the use of an IDevID certificate, as opposed to any other client certificate, or the use of an HTTP-based client authentication scheme.";
description“此模块定义一个数据模型，以启用SZTP引导并发现使用了哪些参数。此模块假定使用IDevID证书，而不是任何其他客户端证书，或者使用基于HTTP的客户端身份验证方案。”；
revision 2019-04-30 {
description
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
revision 2019-04-30 {
description
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
// features
//特征
feature bootstrap-servers {
description
"The device supports bootstrapping off bootstrap servers.";
}
feature bootstrap-servers {
description
"The device supports bootstrapping off bootstrap servers.";
}
feature signed-data {
description
"The device supports bootstrapping off signed data.";
}
feature signed-data {
description
"The device supports bootstrapping off signed data.";
}
// protocol accessible nodes
//协议可访问节点
container sztp {
description
"Top-level container for the SZTP data model.";
leaf enabled {
type boolean;
default false;
description
"The 'enabled' leaf controls if SZTP bootstrapping is
enabled or disabled. The default is 'false' so that, when
not enabled, which is most of the time, no configuration
is needed.";
}
leaf idevid-certificate {
if-feature bootstrap-servers;
type ct:end-entity-cert-cms;
config false;
description
"This CMS structure contains the IEEE 802.1AR
IDevID certificate itself and all intermediate
certificates leading up to, and optionally including,
the manufacturer's well-known trust anchor certificate
for IDevID certificates. The well-known trust anchor
does not have to be a self-signed certificate.";
reference
"IEEE 802.1AR:
IEEE Standard for Local and metropolitan area
networks - Secure Device Identity";
}
container bootstrap-servers {
if-feature bootstrap-servers;
config false;
description
"List of bootstrap servers this device will attempt
to reach out to when bootstrapping.";
list bootstrap-server {
key "address";
description
"A bootstrap server entry.";
leaf address {
type inet:host;
mandatory true;
container sztp {
description
"Top-level container for the SZTP data model.";
leaf enabled {
type boolean;
default false;
description
"The 'enabled' leaf controls if SZTP bootstrapping is
enabled or disabled. The default is 'false' so that, when
not enabled, which is most of the time, no configuration
is needed.";
}
leaf idevid-certificate {
if-feature bootstrap-servers;
type ct:end-entity-cert-cms;
config false;
description
"This CMS structure contains the IEEE 802.1AR
IDevID certificate itself and all intermediate
certificates leading up to, and optionally including,
the manufacturer's well-known trust anchor certificate
for IDevID certificates. The well-known trust anchor
does not have to be a self-signed certificate.";
reference
"IEEE 802.1AR:
IEEE Standard for Local and metropolitan area
networks - Secure Device Identity";
}
container bootstrap-servers {
if-feature bootstrap-servers;
config false;
description
"List of bootstrap servers this device will attempt
to reach out to when bootstrapping.";
list bootstrap-server {
key "address";
description
"A bootstrap server entry.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the bootstrap server the
device should redirect to.";
}
leaf port {
type inet:port-number;
default "443";
description
"The port number the bootstrap server listens on. If no
port is specified, the IANA-assigned port for 'https'
(443) is used.";
}
}
}
container bootstrap-server-trust-anchors {
if-feature bootstrap-servers;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate bootstrap
servers with.";
}
}
container voucher-trust-anchors {
if-feature signed-data;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate ownership
vouchers with.";
}
}
}
}
description
"The IP address or hostname of the bootstrap server the
device should redirect to.";
}
leaf port {
type inet:port-number;
default "443";
description
"The port number the bootstrap server listens on. If no
port is specified, the IANA-assigned port for 'https'
(443) is used.";
}
}
}
container bootstrap-server-trust-anchors {
if-feature bootstrap-servers;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate bootstrap
servers with.";
}
}
container voucher-trust-anchors {
if-feature signed-data;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate ownership
vouchers with.";
}
}
}
}
The following diagram illustrates a sequence of bootstrapping activities that promote an untrusted connection to a bootstrap server to a trusted connection to the same bootstrap server. This enables a device to limit the amount of information it might disclose to an adversary hosting an untrusted bootstrap server.
下图说明了一系列引导活动，这些活动将到引导服务器的不受信任连接提升为到同一引导服务器的受信任连接。这使设备能够限制向托管不受信任的引导服务器的对手披露的信息量。
+-----------+
|Deployment-|
| Specific |
+------+ | Bootstrap |
|Device| | Server |
+------+ +-----------+
| |
| 1. "HTTPS" Request ("signed-data-preferred", nonce) |
|------------------------------------------------------->|
| 2. "HTTPS" Response (signed redirect information) |
|<-------------------------------------------------------|
| |
| |
| 3. HTTPS Request (os-name=xyz, os-version=123, etc.) |
|------------------------------------------------------->|
| 4. HTTPS Response (unsigned onboarding information |
|<-------------------------------------------------------|
| |
+-----------+
|Deployment-|
| Specific |
+------+ | Bootstrap |
|Device| | Server |
+------+ +-----------+
| |
| 1. "HTTPS" Request ("signed-data-preferred", nonce) |
|------------------------------------------------------->|
| 2. "HTTPS" Response (signed redirect information) |
|<-------------------------------------------------------|
| |
| |
| 3. HTTPS Request (os-name=xyz, os-version=123, etc.) |
|------------------------------------------------------->|
| 4. HTTPS Response (unsigned onboarding information |
|<-------------------------------------------------------|
| |
The interactions in the above diagram are described below.
上图中的交互作用如下所述。
1. The device initiates an untrusted connection to a bootstrap server, as is indicated by putting "HTTPS" in double quotes above. It is still an HTTPS connection, but the device is unable to authenticate the bootstrap server's TLS certificate. Because the device is unable to trust the bootstrap server, it sends the "signed-data-preferred" input parameter, and optionally also the "nonce" input parameter, in the "get-bootstrapping-data" RPC. The "signed-data-preferred" parameter informs the bootstrap server that the device does not trust it and may be holding back some additional input parameters from the server (e.g., other input parameters, progress reports, etc.). The "nonce" input parameter enables the bootstrap server to dynamically obtain an ownership voucher from a Manufacturer Authorized Signing Authority (MASA), which may be important for devices that do not have a reliable clock.
1. 设备启动到引导服务器的不可信连接，如上面双引号中的“HTTPS”所示。它仍然是HTTPS连接，但设备无法验证引导服务器的TLS证书。由于设备无法信任引导服务器，因此它会在“获取引导数据”RPC中发送“已签名数据首选”输入参数，还可以选择发送“nonce”输入参数。“signed data preferred”（首选签名数据）参数通知引导服务器设备不信任它，可能会阻止服务器提供一些额外的输入参数（例如，其他输入参数、进度报告等）。“nonce”输入参数使引导服务器能够从制造商授权签名机构（MASA）动态获取所有权凭证，这对于没有可靠时钟的设备可能很重要。
2. The bootstrap server, seeing the "signed-data-preferred" input parameter, knows that it can send either unsigned redirect information or signed data of any type. But, in this case, the bootstrap server has the ability to sign data and chooses to respond with signed redirect information, not signed onboarding information as might be expected, securely redirecting the device back to it again. Not displayed but, if the "nonce" input parameter was passed, the bootstrap server could dynamically connect to a MASA and download a voucher having the nonce value in it. Details regarding a protocol enabling this integration is outside the scope of this document.
2. 引导服务器看到“signed data preferred”输入参数，知道它可以发送未签名的重定向信息或任何类型的签名数据。但是，在这种情况下，引导服务器能够对数据进行签名，并选择使用签名的重定向信息（而不是预期的登录信息）进行响应，从而安全地将设备重定向回它。未显示，但如果传递了“nonce”输入参数，则引导服务器可以动态连接到MASA并下载包含nonce值的凭证。有关支持此集成的协议的详细信息不在本文档的范围内。
3. Upon validating the signed redirect information, the device establishes a secure connection to the bootstrap server. Unbeknownst to the device, it is the same bootstrap server it was connected to previously, but because the device is able to authenticate the bootstrap server this time, it sends its normal "get-bootstrapping-data" request (i.e., with additional input parameters) as well as its progress reports (not depicted).
3. 验证签名的重定向信息后，设备将建立到引导服务器的安全连接。在设备不知道的情况下，它与之前连接的引导服务器相同，但由于设备这次能够对引导服务器进行身份验证，因此它会发送其正常的“获取引导数据”请求（即，带有附加输入参数）及其进度报告（未描述）。
4. This time, because the "signed-data-preferred" parameter was not passed, having access to all of the device's input parameters, the bootstrap server returns, in this example, unsigned onboarding information to the device. Note also that, because the bootstrap server is now trusted, the device will send progress reports to the server.
4. 这一次，由于未传递“signed data preferred”（签名数据首选）参数，无法访问设备的所有输入参数，因此在本例中，引导服务器将未签名的入职信息返回给设备。还请注意，由于引导服务器现在受信任，因此设备将向服务器发送进度报告。
The solution presented in this document is conceptualized to be composed of the non-normative workflows described in this section. Implementation details are expected to vary. Each diagram is followed by a detailed description of the steps presented in the diagram, with further explanation on how implementations may vary.
本文档中提出的解决方案概念上由本节中描述的非规范性工作流组成。实施细节预计会有所不同。每个图后面都详细描述了图中显示的步骤，并进一步解释了实现可能会如何变化。
The following diagram illustrates key interactions that may occur from when a prospective owner enrolls in a manufacturer's SZTP program to when the manufacturer ships devices for an order placed by the prospective owner.
下图说明了从潜在所有者注册制造商的SZTP计划到制造商为潜在所有者下的订单发货设备之间可能发生的关键交互。
+-----------+
+------------+ |Prospective| +---+
|Manufacturer| | Owner | |NMS|
+------------+ +-----------+ +---+
| | |
| | |
| 1. initiate enrollment | |
#<-----------------------------| |
# | |
# | |
# IDevID trust anchor | |
#-----------------------------># set IDevID trust anchor |
# #--------------------------->|
# | |
# bootstrap server | |
# account credentials | |
#-----------------------------># set credentials |
| #--------------------------->|
| | |
| | |
| 2. set owner certificate trust anchor |
|<----------------------------------------------------------|
| | |
| | |
| 3. place device order | |
|<-----------------------------# model devices |
| #--------------------------->|
| | |
| 4. ship devices and send | |
| device identifiers and | |
| ownership vouchers | |
|-----------------------------># set device identifiers |
| # and ownership vouchers |
| #--------------------------->|
| | |
+-----------+
+------------+ |Prospective| +---+
|Manufacturer| | Owner | |NMS|
+------------+ +-----------+ +---+
| | |
| | |
| 1. initiate enrollment | |
#<-----------------------------| |
# | |
# | |
# IDevID trust anchor | |
#-----------------------------># set IDevID trust anchor |
# #--------------------------->|
# | |
# bootstrap server | |
# account credentials | |
#-----------------------------># set credentials |
| #--------------------------->|
| | |
| | |
| 2. set owner certificate trust anchor |
|<----------------------------------------------------------|
| | |
| | |
| 3. place device order | |
|<-----------------------------# model devices |
| #--------------------------->|
| | |
| 4. ship devices and send | |
| device identifiers and | |
| ownership vouchers | |
|-----------------------------># set device identifiers |
| # and ownership vouchers |
| #--------------------------->|
| | |
Each numbered item below corresponds to a numbered item in the diagram above.
下面的每个编号项目对应于上图中的一个编号项目。
1. A prospective owner of a manufacturer's devices initiates an enrollment process with the manufacturer. This process includes the following:
1. 制造商设备的潜在所有者启动与制造商的注册流程。该过程包括以下内容：
* Regardless of how the prospective owner intends to bootstrap their devices, they will always obtain from the manufacturer the trust anchor certificate for the IDevID certificates. This certificate is installed on the prospective owner's NMS
* 无论潜在所有者打算如何引导其设备，他们都将始终从制造商处获得IDevID证书的信任锚证书。此证书安装在潜在所有者的NMS上
so that the NMS can authenticate the IDevID certificates when they are presented to subsequent steps.
这样，当IDevID证书呈现给后续步骤时，NMS可以对其进行身份验证。
* If the manufacturer hosts an Internet-based bootstrap server (e.g., a redirect server) such as described in Section 4.4, then credentials necessary to configure the bootstrap server would be provided to the prospective owner. If the bootstrap server is configurable through an API (outside the scope of this document), then the credentials might be installed on the prospective owner's NMS so that the NMS can subsequently configure the manufacturer-hosted bootstrap server directly.
* 如果制造商托管基于Internet的引导服务器（例如重定向服务器），如第4.4节所述，则将向潜在所有者提供配置引导服务器所需的凭据。如果引导服务器可通过API进行配置（不在本文档范围内），则可能会在潜在所有者的NMS上安装凭据，以便NMS随后可以直接配置制造商托管的引导服务器。
2. If the manufacturer's devices are able to validate signed data (Section 5.4), and assuming that the prospective owner's NMS is able to prepare and sign the bootstrapping data itself, the prospective owner's NMS might set a trust anchor certificate onto the manufacturer's bootstrap server, using the credentials provided in the previous step. This certificate is the trust anchor certificate that the prospective owner would like the manufacturer to place into the ownership vouchers it generates, thereby enabling devices to trust the owner's owner certificate. How this trust anchor certificate is used to enable devices to validate signed bootstrapping data is described in Section 5.4.
2. 如果制造商的设备能够验证已签名的数据（第5.4节），并且假设潜在所有者的NMS能够自行准备并签名引导数据，则潜在所有者的NMS可以使用上一步中提供的凭据在制造商的引导服务器上设置信任锚定证书。此证书是潜在所有者希望制造商将其放入其生成的所有权凭证中的信任锚证书，从而使设备能够信任所有者的所有者证书。第5.4节描述了如何使用此信任锚证书使设备能够验证签名的引导数据。
3. Some time later, the prospective owner places an order with the manufacturer, perhaps with a special flag checked for SZTP handling. At this time, or perhaps before placing the order, the owner may model the devices in their NMS, creating virtual objects for the devices with no real-world device associations. For instance, the model can be used to simulate the device's location in the network and the configuration it should have when fully operational.
3. 一段时间后，潜在所有者向制造商下订单，可能会检查SZTP处理的特殊标志。此时，或者可能在下订单之前，所有者可以在其NMS中对设备进行建模，为没有真实设备关联的设备创建虚拟对象。例如，该模型可用于模拟设备在网络中的位置以及完全运行时应具有的配置。
4. When the manufacturer fulfills the order, shipping the devices to their intended locations, they may notify the owner of the devices' serial numbers and shipping destinations, which the owner may use to stage the network for when the devices power on. Additionally, the manufacturer may send one or more ownership vouchers, cryptographically assigning ownership of those devices to the owner. The owner may set this information on their NMS, perhaps binding specific modeled devices to the serial numbers and ownership vouchers.
4. 当制造商完成订单，将设备运送到其预期位置时，他们可能会通知设备所有者设备的序列号和运送目的地，当设备通电时，所有者可以使用这些序列号和运送目的地搭建网络。此外，制造商可以发送一个或多个所有权凭证，以加密方式将这些设备的所有权分配给所有者。所有者可以在其NMS上设置此信息，可能会将特定的建模设备绑定到序列号和所有权凭证。
The following diagram illustrates how an owner might stage the network for bootstrapping devices.
下图说明了所有者如何为引导设备准备网络。
+-----------+ +-------------+
|Deployment-| |Manufacturer-| +------+ +------+
| Specific | | Hosted | | Local| | Local| +---------+
+---+ | Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable|
|NMS| | Server | | Server | |Server| |Server| | Storage |
+---+ +-----------+ +-------------+ +------+ +------+ +---------+
| | | | | |
1. | | | | | |
activate| | | | | |
modeled | | | | | |
device | | | | | |
------->| | | | | |
| 2. (optional) | | | |
| configure | | | |
| bootstrap | | | |
| server | | | |
|------->| | | | |
| | | | | |
| 3. (optional) configure | | |
| bootstrap server | | | |
|--------------------->| | | |
| | | | | |
| | | | | |
| 4. (optional) configure DNS server| | |
|---------------------------------->| | |
| | | | | |
| | | | | |
| 5. (optional) configure DHCP server | |
|------------------------------------------->| |
| | | | | |
| | | | | |
| 6. (optional) store bootstrapping artifacts on media |
|----------------------------------------------------->|
| | | | | |
| | | | | |
+-----------+ +-------------+
|Deployment-| |Manufacturer-| +------+ +------+
| Specific | | Hosted | | Local| | Local| +---------+
+---+ | Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable|
|NMS| | Server | | Server | |Server| |Server| | Storage |
+---+ +-----------+ +-------------+ +------+ +------+ +---------+
| | | | | |
1. | | | | | |
activate| | | | | |
modeled | | | | | |
device | | | | | |
------->| | | | | |
| 2. (optional) | | | |
| configure | | | |
| bootstrap | | | |
| server | | | |
|------->| | | | |
| | | | | |
| 3. (optional) configure | | |
| bootstrap server | | | |
|--------------------->| | | |
| | | | | |
| | | | | |
| 4. (optional) configure DNS server| | |
|---------------------------------->| | |
| | | | | |
| | | | | |
| 5. (optional) configure DHCP server | |
|------------------------------------------->| |
| | | | | |
| | | | | |
| 6. (optional) store bootstrapping artifacts on media |
|----------------------------------------------------->|
| | | | | |
| | | | | |
Each numbered item below corresponds to a numbered item in the diagram above.
下面的每个编号项目对应于上图中的一个编号项目。
1. Having previously modeled the devices, including setting their fully operational configurations and associating device serial numbers and (optionally) ownership vouchers, the owner might "activate" one or more modeled devices. That is, the owner tells
1. 在之前对设备进行建模（包括设置其完全运行的配置以及关联设备序列号和（可选）所有权凭证）后，所有者可能会“激活”一个或多个建模设备。也就是说，店主告诉我
the NMS to perform the steps necessary to prepare for when the real-world devices power up and initiate the bootstrapping process. Note that, in some deployments, this step might be combined with the last step from the previous workflow. Here, it is depicted that an NMS performs the steps, but they may be performed manually or through some other mechanism.
NMS将执行必要的步骤，以准备实际设备通电并启动引导过程。请注意，在某些部署中，此步骤可能与上一个工作流中的最后一个步骤相结合。这里，描述了NMS执行这些步骤，但是可以手动或通过一些其他机制执行这些步骤。
2. If it is desired to use a deployment-specific bootstrap server, it must be configured to provide the bootstrapping data for the specific devices. Configuring the bootstrap server may occur via a programmatic API not defined by this document. Illustrated here as an external component, the bootstrap server may be implemented as an internal component of the NMS itself.
2. 如果需要使用特定于部署的引导服务器，则必须将其配置为提供特定设备的引导数据。可以通过本文档未定义的编程API配置引导服务器。如图所示，作为外部组件，引导服务器可以实现为NMS本身的内部组件。
3. If it is desired to use a manufacturer-hosted bootstrap server, it must be configured to provide the bootstrapping data for the specific devices. The configuration must be either redirect or onboarding information. That is, the manufacturer-hosted bootstrap server will either redirect the device to another bootstrap server or provide the device with the onboarding information itself. The types of bootstrapping data the manufacturer-hosted bootstrap server supports may vary by implementation; some implementations may support only redirect information or only onboarding information, while others may support both redirect and onboarding information. Configuring the bootstrap server may occur via a programmatic API not defined by this document.
3. 如果希望使用制造商托管的引导服务器，则必须将其配置为为为特定设备提供引导数据。配置必须是重定向或入职信息。也就是说，制造商托管的引导服务器将把设备重定向到另一个引导服务器，或者为设备本身提供启动信息。制造商托管的引导服务器支持的引导数据类型可能因实现而异；一些实现可能只支持重定向信息或仅支持入职信息，而其他实现可能同时支持重定向和入职信息。可以通过本文档未定义的编程API配置引导服务器。
4. If it is desired to use a DNS server to supply bootstrapping data, a DNS server needs to be configured. If multicast DNS is desired, then the DNS server must reside on the local network; otherwise, the DNS server may reside on a remote network. Please see Section 4.2 for more information about how to configure DNS servers. Configuring the DNS server may occur via a programmatic API not defined by this document.
4. 如果希望使用DNS服务器提供引导数据，则需要配置DNS服务器。如果需要多播DNS，则DNS服务器必须驻留在本地网络上；否则，DNS服务器可能驻留在远程网络上。有关如何配置DNS服务器的更多信息，请参阅第4.2节。可以通过本文档未定义的编程API配置DNS服务器。
5. If it is desired to use a DHCP server to supply bootstrapping data, a DHCP server needs to be configured. The DHCP server may be accessed directly or via a DHCP relay. Please see Section 4.3 for more information about how to configure DHCP servers. Configuring the DHCP server may occur via a programmatic API not defined by this document.
5. 如果希望使用DHCP服务器提供引导数据，则需要配置DHCP服务器。可以直接或通过DHCP中继访问DHCP服务器。有关如何配置DHCP服务器的更多信息，请参阅第4.3节。可以通过本文档未定义的编程API配置DHCP服务器。
6. If it is desired to use a removable storage device (e.g., a USB flash drive) to supply bootstrapping data, the data would need to be placed onto it. Please see Section 4.1 for more information about how to configure a removable storage device.
6. 如果需要使用可移动存储设备（例如USB闪存驱动器）来提供引导数据，则需要将数据放在其上。有关如何配置可移动存储设备的更多信息，请参阅第4.1节。
The following diagram illustrates the sequence of activities that occur when a device powers on.
下图说明了设备通电时发生的活动顺序。
+-----------+
+-----------+ |Deployment-|
| Source of | | Specific |
+------+ | Bootstrap | | Bootstrap | +---+
|Device| | Data | | Server | |NMS|
+------+ +-----------+ +-----------+ +---+
| | | |
| | | |
| 1. if SZTP bootstrap service | | |
| is not enabled, then exit. | | |
| | | |
| 2. for each source supported, check | | |
| for bootstrapping data. | | |
|------------------------------------>| | |
| | | |
| 3. if onboarding information is | | |
| found, initialize self and, only | | |
| if source is a trusted bootstrap | | |
| server, send progress reports. | | |
|------------------------------------># | |
| # webhook | |
| #------------------------>|
| | |
| 4. else, if redirect information is found, for | |
| each bootstrap server specified, check for data.| |
|-+------------------------------------------------->| |
| | | |
| | if more redirect information is found, recurse | |
| | (not depicted); else, if onboarding information | |
| | is found, initialize self and post progress | |
| | reports. | |
| +-------------------------------------------------># |
| # webhook |
| #--------->|
|
| 5. retry sources and/or wait for manual provisioning.
|
+-----------+
+-----------+ |Deployment-|
| Source of | | Specific |
+------+ | Bootstrap | | Bootstrap | +---+
|Device| | Data | | Server | |NMS|
+------+ +-----------+ +-----------+ +---+
| | | |
| | | |
| 1. if SZTP bootstrap service | | |
| is not enabled, then exit. | | |
| | | |
| 2. for each source supported, check | | |
| for bootstrapping data. | | |
|------------------------------------>| | |
| | | |
| 3. if onboarding information is | | |
| found, initialize self and, only | | |
| if source is a trusted bootstrap | | |
| server, send progress reports. | | |
|------------------------------------># | |
| # webhook | |
| #------------------------>|
| | |
| 4. else, if redirect information is found, for | |
| each bootstrap server specified, check for data.| |
|-+------------------------------------------------->| |
| | | |
| | if more redirect information is found, recurse | |
| | (not depicted); else, if onboarding information | |
| | is found, initialize self and post progress | |
| | reports. | |
| +-------------------------------------------------># |
| # webhook |
| #--------->|
|
| 5. retry sources and/or wait for manual provisioning.
|
The interactions in the above diagram are described below.
上图中的交互作用如下所述。
1. Upon power being applied, the device checks to see if SZTP bootstrapping is configured, such as must be the case when running its "factory default" configuration. If SZTP
1. 通电后，设备检查是否配置了SZTP引导，例如运行其“出厂默认”配置时的情况。如果SZTP
bootstrapping is not configured, then the bootstrapping logic exits and none of the following interactions occur.
如果未配置引导，则会退出引导逻辑，并且不会发生以下任何交互。
2. For each source of bootstrapping data the device supports, preferably in order of closeness to the device (e.g., removable storage before Internet-based servers), the device checks to see if there is any bootstrapping data for it there.
2. 对于设备支持的每个引导数据源，最好按照与设备接近的顺序（例如，基于互联网的服务器之前的可移动存储），设备检查那里是否有任何引导数据。
3. If onboarding information is found, the device initializes itself accordingly (e.g., installing a boot image and committing an initial configuration). If the source is a bootstrap server, and the bootstrap server can be trusted (i.e., TLS-level authentication), the device also sends progress reports to the bootstrap server.
3. 如果找到启动信息，设备会相应地进行自我初始化（例如，安装启动映像并提交初始配置）。如果源是引导服务器，并且可以信任引导服务器（即TLS级身份验证），则设备还将向引导服务器发送进度报告。
* The contents of the initial configuration should configure an administrator account on the device (e.g., username, SSH public key, etc.), should configure the device to either listen for NETCONF or RESTCONF connections or initiate call home connections [RFC8071], and should disable the SZTP bootstrapping service (e.g., the "enabled" leaf in data model presented in Appendix A).
* 初始配置的内容应在设备上配置管理员帐户（例如用户名、SSH公钥等），应将设备配置为侦听NETCONF或RESTCONF连接或启动呼叫总部连接[RFC8071]，并应禁用SZTP引导服务（例如“已启用”附录A中所示的叶数据模型）。
* If the bootstrap server supports forwarding device progress reports to external systems (e.g., via a webhook), a "bootstrap-complete" progress report (Section 7.3) informs the external system to know when it can, for instance, initiate a connection to the device. To support this scenario further, the "bootstrap-complete" progress report may also relay the device's SSH host keys and/or TLS certificates, which the external system can use to authenticate subsequent connections to the device.
* 如果引导服务器支持将设备进度报告转发给外部系统（例如，通过webhook），则“引导完成”进度报告（第7.3节）会通知外部系统何时可以（例如）启动与设备的连接。为了进一步支持此场景，“引导完成”进度报告还可以中继设备的SSH主机密钥和/或TLS证书，外部系统可以使用这些密钥和/或TLS证书对设备的后续连接进行身份验证。
If the device successfully completes the bootstrapping process, it exits the bootstrapping logic without considering any additional sources of bootstrapping data.
如果设备成功完成引导过程，它将退出引导逻辑，而不考虑任何其他引导数据源。
4. Otherwise, if redirect information is found, the device iterates through the list of specified bootstrap servers, checking to see if the bootstrap server has bootstrapping data for the device. If the bootstrap server returns more redirect information, then the device processes it recursively. Otherwise, if the bootstrap server returns onboarding information, the device processes it following the description provided in (3) above.
4. 否则，如果找到重定向信息，设备将遍历指定的引导服务器列表，检查引导服务器是否具有设备的引导数据。如果引导服务器返回更多重定向信息，则设备将递归处理该信息。否则，如果引导服务器返回入职信息，设备将按照上面（3）中提供的描述进行处理。
5. After having tried all supported sources of bootstrapping data, the device may retry again all the sources and/or provide manageability interfaces for manual configuration (e.g., CLI,
5. 在尝试了所有受支持的引导数据源之后，设备可以再次重试所有源和/或提供手动配置的可管理性接口（例如CLI、，
HTTP, NETCONF, etc.). If manual configuration is allowed, and such configuration is provided, the configuration should also disable the SZTP bootstrapping service, as the need for bootstrapping would no longer be present.
HTTP、NETCONF等）。如果允许手动配置，并且提供了此类配置，则该配置还应禁用SZTP引导服务，因为不再需要引导。
Acknowledgements
致谢
The authors would like to thank the following for lively discussions on list and in the halls (ordered by last name): Michael Behringer, Martin Bjorklund, Dean Bogdanovic, Joe Clarke, Dave Crocker, Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, David Harrington, Benjamin Kaduk, Radek Krejci, Suresh Krishnan, Mirja Kuehlewind, David Mandelberg, Alexey Melnikov, Russ Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael Richardson, Adam Roach, Juergen Schoenwaelder, and Phil Shafer.
作者要感谢以下在名单上和大厅里（按姓氏排序）进行的热烈讨论：迈克尔·贝林格、马丁·比约克隆德、迪安·博格达诺维奇、乔·克拉克、戴夫·克罗克、托利斯·埃克特、斯蒂芬·法雷尔、斯蒂芬·汉纳、韦斯·哈达克、大卫·哈林顿、本杰明·卡杜克、拉迪克·克雷奇、苏雷什·克里希南、米娅·库勒温德、，David Mandelberg、Alexey Melnikov、Russ Mundy、Reinaldo Penno、Randy Presohn、Max Pritikin、Michael Richardson、Adam Roach、Juergen Schoenwaelder和Phil Shafer。
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original solution during the IETF 87 meeting in Berlin.
特别感谢Steve Hanna、Russ Mundy和Wes Hardaker在柏林IETF 87会议期间集思广益地讨论了原始解决方案。
Authors' Addresses
作者地址
Kent Watsen Watsen Networks
肯特沃特森网络公司
Email: kent+ietf@watsen.net
Email: kent+ietf@watsen.net
Ian Farrer Deutsche Telekom AG
伊恩·法雷尔德国电信公司
Email: ian.farrer@telekom.de
Email: ian.farrer@telekom.de
Mikael Abrahamsson T-Systems
Mikael Abrahamsson T-Systems公司
Email: mikael.abrahamsson@t-systems.se
Email: mikael.abrahamsson@t-systems.se