Network Working Group R. Housley
Request for Comments: 4108 Vigil Security
Category: Standards Track August 2005
Network Working Group R. Housley
Request for Comments: 4108 Vigil Security
Category: Standards Track August 2005
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
使用加密消息语法（CMS）保护固件包
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.
本文档描述了使用加密消息语法（CMS）保护固件包，固件包为一个或多个硬件模块组件提供目标代码。RFC 3852中规定了CMS。数字签名用于保护固件包免受未检测到的修改，并提供数据源身份验证。加密可选地用于保护固件包不被泄露，压缩可选地用于减小受保护固件包的大小。可以选择生成固件包加载回执，以确认固件包加载成功。类似地，可以选择性地生成固件包加载错误报告，以传达加载固件包的失败。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Architectural Elements .....................................5
1.2.1. Hardware Module Requirements ........................7
1.2.2. Firmware Package Requirements .......................8
1.2.3. Bootstrap Loader Requirements .......................9
1.2.3.1. Legacy Stale Version Processing ...........11
1.2.3.2. Preferred Stale Version Processing ........12
1.2.4. Trust Anchors ......................................12
1.2.5. Cryptographic and Compression Algorithm
Requirements .......................................13
1.3. Hardware Module Security Architecture .....................14
1.4. ASN.1 Encoding ............................................14
1.5. Protected Firmware Package Loading ........................15
2. Firmware Package Protection ....................................15
2.1. Firmware Package Protection CMS Content Type Profile ......18
2.1.1. ContentInfo ........................................18
2.1.2. SignedData .........................................18
2.1.2.1. SignerInfo ................................19
2.1.2.2. EncapsulatedContentInfo ...................20
2.1.3. EncryptedData ......................................20
2.1.3.1. EncryptedContentInfo ......................21
2.1.4. CompressedData .....................................21
2.1.4.1. EncapsulatedContentInfo ...................22
2.1.5. FirmwarePkgData ....................................22
2.2. Signed Attributes .........................................22
2.2.1. Content Type .......................................23
2.2.2. Message Digest .....................................24
2.2.3. Firmware Package Identifier ........................24
2.2.4. Target Hardware Module Identifiers .................25
2.2.5. Decrypt Key Identifier .............................26
2.2.6. Implemented Crypto Algorithms ......................26
2.2.7. Implemented Compression Algorithms .................27
2.2.8. Community Identifiers ..............................27
2.2.9. Firmware Package Information .......................29
2.2.10. Firmware Package Message Digest ...................30
2.2.11. Signing Time ......................................30
2.2.12. Content Hints .....................................31
2.2.13. Signing Certificate ...............................31
2.3. Unsigned Attributes .......................................32
2.3.1. Wrapped Firmware Decryption Key ....................33
3. Firmware Package Load Receipt ..................................34
3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
3.1.1. ContentInfo ........................................36
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Architectural Elements .....................................5
1.2.1. Hardware Module Requirements ........................7
1.2.2. Firmware Package Requirements .......................8
1.2.3. Bootstrap Loader Requirements .......................9
1.2.3.1. Legacy Stale Version Processing ...........11
1.2.3.2. Preferred Stale Version Processing ........12
1.2.4. Trust Anchors ......................................12
1.2.5. Cryptographic and Compression Algorithm
Requirements .......................................13
1.3. Hardware Module Security Architecture .....................14
1.4. ASN.1 Encoding ............................................14
1.5. Protected Firmware Package Loading ........................15
2. Firmware Package Protection ....................................15
2.1. Firmware Package Protection CMS Content Type Profile ......18
2.1.1. ContentInfo ........................................18
2.1.2. SignedData .........................................18
2.1.2.1. SignerInfo ................................19
2.1.2.2. EncapsulatedContentInfo ...................20
2.1.3. EncryptedData ......................................20
2.1.3.1. EncryptedContentInfo ......................21
2.1.4. CompressedData .....................................21
2.1.4.1. EncapsulatedContentInfo ...................22
2.1.5. FirmwarePkgData ....................................22
2.2. Signed Attributes .........................................22
2.2.1. Content Type .......................................23
2.2.2. Message Digest .....................................24
2.2.3. Firmware Package Identifier ........................24
2.2.4. Target Hardware Module Identifiers .................25
2.2.5. Decrypt Key Identifier .............................26
2.2.6. Implemented Crypto Algorithms ......................26
2.2.7. Implemented Compression Algorithms .................27
2.2.8. Community Identifiers ..............................27
2.2.9. Firmware Package Information .......................29
2.2.10. Firmware Package Message Digest ...................30
2.2.11. Signing Time ......................................30
2.2.12. Content Hints .....................................31
2.2.13. Signing Certificate ...............................31
2.3. Unsigned Attributes .......................................32
2.3.1. Wrapped Firmware Decryption Key ....................33
3. Firmware Package Load Receipt ..................................34
3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
3.1.1. ContentInfo ........................................36
3.1.2. SignedData .........................................36
3.1.2.1. SignerInfo ................................37
3.1.2.2. EncapsulatedContentInfo ...................38
3.1.3. FirmwarePackageLoadReceipt .........................38
3.2. Signed Attributes .........................................40
3.2.1. Content Type .......................................40
3.2.2. Message Digest .....................................40
3.2.3. Signing Time .......................................40
4. Firmware Package Load Error ....................................41
4.1. Firmware Package Load Error CMS Content Type Profile ......42
4.1.1. ContentInfo ........................................42
4.1.2. SignedData .........................................43
4.1.2.1. SignerInfo ................................43
4.1.2.2. EncapsulatedContentInfo ...................43
4.1.3. FirmwarePackageLoadError ...........................43
4.2. Signed Attributes .........................................49
4.2.1. Content Type .......................................49
4.2.2. Message Digest .....................................49
4.2.3. Signing Time .......................................50
5. Hardware Module Name ...........................................50
6. Security Considerations ........................................51
6.1. Cryptographic Keys and Algorithms .........................51
6.2. Random Number Generation ..................................51
6.3. Stale Firmware Package Version Number .....................52
6.4. Community Identifiers .....................................53
7. References .....................................................54
7.1. Normative References ......................................54
7.2. Informative References ....................................54
Appendix A: ASN.1 Module ..........................................56
3.1.2. SignedData .........................................36
3.1.2.1. SignerInfo ................................37
3.1.2.2. EncapsulatedContentInfo ...................38
3.1.3. FirmwarePackageLoadReceipt .........................38
3.2. Signed Attributes .........................................40
3.2.1. Content Type .......................................40
3.2.2. Message Digest .....................................40
3.2.3. Signing Time .......................................40
4. Firmware Package Load Error ....................................41
4.1. Firmware Package Load Error CMS Content Type Profile ......42
4.1.1. ContentInfo ........................................42
4.1.2. SignedData .........................................43
4.1.2.1. SignerInfo ................................43
4.1.2.2. EncapsulatedContentInfo ...................43
4.1.3. FirmwarePackageLoadError ...........................43
4.2. Signed Attributes .........................................49
4.2.1. Content Type .......................................49
4.2.2. Message Digest .....................................49
4.2.3. Signing Time .......................................50
5. Hardware Module Name ...........................................50
6. Security Considerations ........................................51
6.1. Cryptographic Keys and Algorithms .........................51
6.2. Random Number Generation ..................................51
6.3. Stale Firmware Package Version Number .....................52
6.4. Community Identifiers .....................................53
7. References .....................................................54
7.1. Normative References ......................................54
7.2. Informative References ....................................54
Appendix A: ASN.1 Module ..........................................56
This document describes the use of the Cryptographic Message Syntax (CMS) [CMS] to protect firmware packages. This document also describes the use of CMS for receipts and error reports for firmware package loading. The CMS is a data protection encapsulation syntax that makes use of ASN.1 [X.208-88, X.209-88]. The protected firmware package can be associated with any particular hardware module; however, this specification was written with the requirements of cryptographic hardware modules in mind, as these modules have strong security requirements.
本文档描述了使用加密消息语法（CMS）[CMS]保护固件软件包。本文档还描述了CMS用于固件包加载的收据和错误报告。CMS是一种使用ASN.1[X.208-88，X.209-88]的数据保护封装语法。受保护固件包可与任何特定硬件模块相关联；然而，编写本规范时考虑到了加密硬件模块的要求，因为这些模块具有很强的安全性要求。
The firmware package contains object code for one or more programmable components that make up the hardware module. The firmware package, which is treated as an opaque binary object, is digitally signed. Optional encryption and compression are also supported. When all three are used, the firmware package is compressed, then encrypted, and then signed. Compression simply
固件包包含组成硬件模块的一个或多个可编程组件的目标代码。固件包被视为不透明的二进制对象，并进行数字签名。还支持可选的加密和压缩。当这三个都被使用时，固件包将被压缩，然后加密，然后签名。简单压缩
reduces the size of the firmware package, allowing more efficient processing and transmission. Encryption protects the firmware package from disclosure, which allows transmission of sensitive firmware packages over insecure links. The encryption algorithm and mode employed may also provide integrity, protecting the firmware package from undetected modification. The encryption protects proprietary algorithms, classified algorithms, trade secrets, and implementation techniques. The digital signature protects the firmware package from undetected modification and provides data origin authentication. The digital signature allows the hardware module to confirm that the firmware package comes from an acceptable source.
减小固件包的大小，从而实现更高效的处理和传输。加密保护固件包不被泄露，从而允许通过不安全的链路传输敏感固件包。所采用的加密算法和模式也可提供完整性，保护固件包不受未检测到的修改。加密保护专有算法、机密算法、商业秘密和实现技术。数字签名保护固件包不受未检测到的修改，并提供数据源身份验证。数字签名允许硬件模块确认固件包来自可接受的来源。
If encryption is used, the firmware-decryption key must be made available to the hardware module via a secure path. The key might be delivered via physical media or via an independent electronic path. One optional mechanism for distributing the firmware-decryption key is specified in Section 2.3.1, but any secure key distribution mechanism is acceptable.
如果使用加密，则必须通过安全路径将固件解密密钥提供给硬件模块。密钥可以通过物理介质或独立的电子路径传递。第2.3.1节规定了一种用于分发固件解密密钥的可选机制，但可接受任何安全密钥分发机制。
The signature verification public key must be made available to the hardware module in a manner that preserves its integrity and confirms its source. CMS supports the transfer of certificates, and this facility can be used to transfer a certificate that contains the signature verification public key (a firmware-signing certificate). However, use of this facility introduces a level of indirection. Ultimately, a trust anchor public key must be made available to the hardware module. Section 1.2 establishes a requirement that the hardware module store one or more trust anchors.
签名验证公钥必须以保持其完整性并确认其来源的方式提供给硬件模块。CMS支持证书传输，此功能可用于传输包含签名验证公钥的证书（固件签名证书）。但是，使用此功能会引入一定程度的间接性。最终，必须向硬件模块提供信任锚公钥。第1.2节规定了硬件模块存储一个或多个信任锚的要求。
Hardware modules may not be capable of accessing certificate repositories or delegated path discovery (DPD) servers [DPD&DPV] to acquire certificates needed to complete a certification path. Thus, it is the responsibility of the firmware package signer to include sufficient certificates to enable each module to validate the firmware-signer certificate (see Section 2.1.2). Similarly, hardware modules may not be capable of accessing a certificate revocation list (CRL) repository, an OCSP responder [OCSP], or a delegated path validation (DPV) server [DPD&DPV] to acquire revocation status information. Thus, if the firmware package signature cannot be validated solely with the trust anchor public key and the hardware module is not capable of performing full certification path validation, then it is the responsibility of the entity loading a package into a hardware module to validate the firmware-signer certification path prior to loading the package into a hardware module. The means by which this external certificate revocation status checking is performed is beyond the scope of this specification.
硬件模块可能无法访问证书存储库或委托路径发现（DPD）服务器[DPD&DPV]，以获取完成证书路径所需的证书。因此，固件包签名者有责任包括足够的证书，以使每个模块能够验证固件签名者证书（见第2.1.2节）。类似地，硬件模块可能无法访问证书吊销列表（CRL）存储库、OCSP响应程序[OCSP]或委托路径验证（DPV）服务器[DPD&DPV]以获取吊销状态信息。因此，如果固件包签名不能仅使用信任锚公钥进行验证，并且硬件模块不能执行完整的认证路径验证，然后，实体在将包加载到硬件模块之前，负责验证固件签名者认证路径。执行此外部证书吊销状态检查的方法超出了本规范的范围。
Hardware modules will only accept firmware packages with a valid digital signature. The signature is either validated directly using the trust anchor public key or using a firmware-signer certification path that is validated to the trust anchor public key. Thus, the trust anchors define the set of entities that can create firmware packages for the hardware module.
硬件模块将仅接受具有有效数字签名的固件包。签名可以直接使用信任锚公钥进行验证，也可以使用验证为信任锚公钥的固件签名者认证路径进行验证。因此，信任锚定义了可以为硬件模块创建固件包的一组实体。
The disposition of a previously loaded firmware package after the successful validation of another firmware package is beyond the scope of this specification. The amount of memory available to the hardware module will determine the range of alternatives.
在成功验证另一个固件包后，对先前加载的固件包的处置超出了本规范的范围。硬件模块可用的内存量将决定备选方案的范围。
In some cases, hardware modules can generate receipts to acknowledge the loading of a particular firmware package. Such receipts can be used to determine which hardware modules need to receive an updated firmware package whenever a flaw in an earlier firmware package is discovered. Hardware modules can also generate error reports to indicate the unsuccessful firmware package loading. To implement either receipt or error report generation, the hardware module is required to have a unique permanent serial number. Receipts and error reports can be either signed or unsigned. To generate digitally signed receipts or error reports, a hardware module MUST be issued its own private signature key and a certificate that contains the corresponding signature validation public key. In order to save memory with the hardware module, the hardware module might store a certificate designator instead of the certificate itself. The private signature key requires secure storage.
在某些情况下，硬件模块可以生成收据以确认特定固件包的加载。此类收据可用于确定在发现早期固件包中的缺陷时，哪些硬件模块需要接收更新的固件包。硬件模块还可以生成错误报告，以指示固件包加载失败。要实现接收或错误报告生成，硬件模块需要具有唯一的永久序列号。收据和错误报告可以是已签名的，也可以是未签名的。要生成数字签名收据或错误报告，必须向硬件模块颁发其自己的私有签名密钥和包含相应签名验证公钥的证书。为了节省硬件模块的内存，硬件模块可能存储证书指示符，而不是证书本身。私人签名密钥需要安全存储。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS].
在本文件中，关键字“必须”、“不得”、“必需”、“应当”、“不应当”、“建议”、“可以”和“可选”应按照[STDOWORDS]中的说明进行解释。
The architecture includes the hardware module, the firmware package, and a bootstrap loader. The bootstrap loader MUST have access to one or more trusted public keys, called trust anchors, to validate the signature on the firmware package. If a signed firmware package load receipt or error report is created on behalf of the hardware module, then the bootstrap loader MUST have access to a private signature key to generate the signature and the signer identifier for the corresponding signature validation certificate or its designator. A signature validation certificate MAY be included to aid signature validation. To implement this optional capability, the hardware module MUST have a unique serial number and a private signature key; the hardware module MAY also include a certificate that contains the
该体系结构包括硬件模块、固件包和引导加载程序。引导加载程序必须能够访问一个或多个受信任的公钥（称为信任锚），以验证固件包上的签名。如果代表硬件模块创建了签名固件包加载收据或错误报告，则引导加载程序必须能够访问私有签名密钥，以生成相应签名验证证书或其标识符的签名和签名者标识符。可以包括签名验证证书以帮助签名验证。要实现此可选功能，硬件模块必须具有唯一的序列号和私有签名密钥；硬件模块还可以包括包含以下内容的证书：
corresponding signature validation public key. These items MUST be installed in the hardware module before it is deployed. The private key and certificate can be generated and installed as part of the hardware module manufacture process. Figure 1 illustrates these architectural elements.
相应的签名验证公钥。在部署硬件模块之前，必须将这些项目安装在硬件模块中。私钥和证书可以作为硬件模块制造过程的一部分生成和安装。图1展示了这些架构元素。
ASN.1 object identifiers are the preferred means of naming the architectural elements.
ASN.1对象标识符是命名架构元素的首选方法。
Details of managing the trust anchors are beyond the scope of this specification. However, one or more trust anchors MUST be installed in the hardware module using a secure process before it is deployed. These trust anchors provide a means of controlling the acceptable sources of firmware packages. The hardware module vendor can include provisions for secure, remote management of trust anchors. One approach is to include trust anchors in the firmware packages themselves. This approach is analogous to the optional capability described later for updating the bootstrap loader.
管理信任锚的详细信息超出了本规范的范围。但是，在部署硬件模块之前，必须使用安全进程在硬件模块中安装一个或多个信任锚。这些信任锚提供了一种控制固件包的可接受来源的方法。硬件模块供应商可以提供对信任锚的安全远程管理。一种方法是在固件包中包含信任锚。这种方法类似于后面描述的用于更新引导加载程序的可选功能。
In a cryptographic hardware module, the firmware package might implement many different cryptographic algorithms.
在加密硬件模块中，固件包可能实现许多不同的加密算法。
When the firmware package is encrypted, the firmware-decryption key and the firmware package MUST both be provided to the hardware module. The firmware-decryption key is necessary to use the associated firmware package. Generally, separate distribution mechanisms will be employed for the firmware-decryption key and the firmware package. An optional mechanism for securely distributing the firmware-decryption key with the firmware package is specified in Section 2.3.1.
加密固件包时，必须向硬件模块提供固件解密密钥和固件包。固件解密密钥是使用相关固件包所必需的。通常，固件解密密钥和固件包将采用单独的分发机制。第2.3.1节规定了用于安全分发固件解密密钥和固件包的可选机制。
+------------------------------------------------------+
| Hardware Module |
| |
| +---------------+ +--------------------------+ |
| | Bootstrap | | Firmware Package | |
| | Loader | | | |
| +---------------+ | +------------------+ | |
| | : Firmware Package : | |
| +---------------+ | : Identifier and : | |
| | Trust | | : Version Number : | |
| | Anchor(s) | | +------------------+ | |
| +---------------+ | | |
| | +-------------+ | |
| +---------------+ | : Algorithm 1 : | |
| | Serial Num. | | +-+-----------+-+ | |
| +---------------+ | : Algorithm 2 : | |
| | +-+-----------+-+ | |
| +---------------+ | : Algorithm n : | |
| | Hardware | | +-------------+ | |
| | Module Type | | | |
| +---------------+ +--------------------------+ |
| |
| +------------------------------------+ |
| | Optional Private Signature Key & | |
| | Signature Validation Certificate | |
| | or the Certificate Designator | |
| +------------------------------------+ |
| |
+------------------------------------------------------+
+------------------------------------------------------+
| Hardware Module |
| |
| +---------------+ +--------------------------+ |
| | Bootstrap | | Firmware Package | |
| | Loader | | | |
| +---------------+ | +------------------+ | |
| | : Firmware Package : | |
| +---------------+ | : Identifier and : | |
| | Trust | | : Version Number : | |
| | Anchor(s) | | +------------------+ | |
| +---------------+ | | |
| | +-------------+ | |
| +---------------+ | : Algorithm 1 : | |
| | Serial Num. | | +-+-----------+-+ | |
| +---------------+ | : Algorithm 2 : | |
| | +-+-----------+-+ | |
| +---------------+ | : Algorithm n : | |
| | Hardware | | +-------------+ | |
| | Module Type | | | |
| +---------------+ +--------------------------+ |
| |
| +------------------------------------+ |
| | Optional Private Signature Key & | |
| | Signature Validation Certificate | |
| | or the Certificate Designator | |
| +------------------------------------+ |
| |
+------------------------------------------------------+
Figure 1. Architectural Elements
图1。建筑元素
Many different vendors develop hardware modules, and each vendor typically identifies its modules by product type (family) and revision level. A unique object identifier MUST name each hardware module type and revision.
许多不同的供应商开发硬件模块，每个供应商通常根据产品类型（系列）和版本级别确定其模块。必须使用唯一的对象标识符命名每个硬件模块类型和版本。
Each hardware module within a hardware module family SHOULD have a unique permanent serial number. However, if the optional receipt or error report generation capability is implemented, then the hardware module MUST have a unique permanent serial number. If the optional receipt or error report signature capability is implemented, then the hardware module MUST have a private signature key and a certificate containing the corresponding public signature validation key or its designator. If a serial number is present, the bootstrap loader uses
硬件模块系列中的每个硬件模块应具有唯一的永久序列号。但是，如果实现了可选的接收或错误报告生成功能，则硬件模块必须具有唯一的永久序列号。如果实现了可选的接收或错误报告签名功能，则硬件模块必须具有私有签名密钥和包含相应公共签名验证密钥或其标识符的证书。如果存在序列号，引导加载程序将使用
it for authorization decisions (see Section 2.2.8), receipt generation (see Section 3), and error report generation (see Section 4).
它用于授权决策（参见第2.2.8节）、收据生成（参见第3节）和错误报告生成（参见第4节）。
When the hardware module includes more than one firmware-programmable component, the bootstrap loader distributes components of the package to the appropriate components within the hardware module after the firmware package is validated. The bootstrap loader is discussed further in Section 1.2.3.
当硬件模块包括多个固件可编程组件时，引导加载程序在验证固件包后将包的组件分发到硬件模块内的适当组件。引导加载程序将在第1.2.3节中进一步讨论。
Two approaches to naming firmware packages are supported: legacy and preferred. Firmware package names are placed in a CMS signed attribute, not in the firmware package itself.
支持两种命名固件包的方法：传统和首选。固件包名称位于CMS签名属性中，而不是固件包本身。
Legacy firmware package names are simply octet strings, and no structure is assumed. This firmware package name form is supported in order to facilitate existing configuration management systems. We assume that the firmware signer and the bootstrap loader will understand any internal structure to the octet string. In particular, given two legacy firmware package names, we assume that the firmware signer and the bootstrap loader will be able to determine which one represents the newer version of the firmware package. This capability is necessary to implement the stale version feature. If a firmware package with a disastrous flaw is released, subsequent firmware package versions MAY designate a stale legacy firmware package name in order to prevent subsequent rollback to the stale version or versions earlier than the stale version.
传统固件包名称只是八位字节字符串，不采用任何结构。支持此固件包名称表单，以方便现有配置管理系统。我们假设固件签名者和引导加载程序将理解八位字节字符串的任何内部结构。特别是，给定两个旧固件包名称，我们假设固件签名者和引导加载程序将能够确定哪一个代表固件包的较新版本。此功能是实现过时版本功能所必需的。如果发布了具有灾难性缺陷的固件包，后续固件包版本可能会指定陈旧的旧固件包名称，以防止后续回滚到陈旧版本或早于陈旧版本的版本。
Preferred firmware package names are a combination of the firmware package object identifier and a version number. A unique object identifier MUST identify the collection of features that characterize the firmware package. For example, firmware packages for a cable modem and a wireless LAN network interface card warrant distinct object identifiers. Similarly, firmware packages that implement distinct suites of cryptographic algorithms and modes of operation, or that emulate different (non-programmable) cryptographic devices warrant distinct object identifiers. The version number MUST identify a particular build or release of the firmware package. The version number MUST be a monotonically increasing non-negative integer. Generally, an earlier version is replaced with a later one. If a firmware package with a disastrous flaw is released, subsequent firmware package versions MAY designate a stale version number to prevent subsequent rollback to the stale version or versions earlier than the stale version.
首选固件包名称是固件包对象标识符和版本号的组合。唯一的对象标识符必须标识表征固件包的功能集合。例如，电缆调制解调器和无线LAN网络接口卡的固件包保证不同的对象标识符。类似地，实现不同密码算法和操作模式套件的固件包，或模拟不同（不可编程）密码设备的固件包保证了不同的对象标识符。版本号必须标识固件包的特定版本或版本。版本号必须是单调递增的非负整数。通常，较早的版本会被较新的版本替换。如果发布了具有灾难性缺陷的固件包，后续固件包版本可能会指定一个过时版本号，以防止后续回滚到过时版本或早于过时版本的版本。
Firmware packages are developed to run on one or more hardware module type. The firmware package digital signature MUST bind the list of supported hardware module object identifiers to the firmware package.
固件包开发为在一个或多个硬件模块类型上运行。固件包数字签名必须将支持的硬件模块对象标识符列表绑定到固件包。
In many cases, the firmware package signature will be validated directly with the trust anchor public key, avoiding the need to construct certification paths. Alternatively, the trust anchor can delegate firmware package signing to another public key through a certification path. In the latter case, the firmware package SHOULD contain the certificates needed to construct the certification path that begins with a certificate issued by the trust anchors and ends with a certificate issued to the firmware package signer.
在许多情况下，固件包签名将直接使用信任锚公钥进行验证，从而避免了构建认证路径的需要。或者，信任锚可以通过认证路径将固件包签名委托给另一个公钥。在后一种情况下，固件包应包含构建证书路径所需的证书，该路径以信任锚颁发的证书开始，以颁发给固件包签名者的证书结束。
The firmware package MAY contain a list of community identifiers. These identifiers name the hardware modules that are authorized to load the firmware package. If the firmware package contains a list of community identifiers, then the bootstrap loader MUST reject the firmware package if the hardware module is not a member of one of the identified communities.
固件包可以包含社区标识符的列表。这些标识符命名授权加载固件包的硬件模块。如果固件包包含社区标识符列表，则如果硬件模块不是已标识社区之一的成员，则引导加载程序必须拒绝固件包。
When a hardware module includes multiple programmable components, the firmware package SHOULD contain executable code for all of the components. Internal tagging within the firmware package MUST tell the bootstrap loader which portion of the overall firmware package is intended for each component; however, this tagging is expected to be specific to each hardware module. Because this specification treats the firmware package as an opaque binary object, the format of the firmware package is beyond the scope of this specification.
当硬件模块包括多个可编程组件时，固件包应包含所有组件的可执行代码。固件包内的内部标记必须告诉引导加载程序整个固件包的哪个部分用于每个组件；但是，该标记预期特定于每个硬件模块。由于本规范将固件包视为不透明的二进制对象，固件包的格式超出了本规范的范围。
The bootstrap loader MUST have access to a physical interface and any related driver or protocol software necessary to obtain a firmware package. The same interface SHOULD be used to deliver receipts and error reports. Details of the physical interface as well as the driver or protocol software are beyond the scope of this specification.
引导加载程序必须能够访问物理接口以及获取固件包所需的任何相关驱动程序或协议软件。应使用相同的界面交付收据和错误报告。物理接口以及驱动程序或协议软件的详细信息超出本规范的范围。
The bootstrap loader can be a permanent part of the hardware module, or it can be replaced by loading a firmware package. In Figure 1, the bootstrap loader is implemented as separate logic within the hardware module. Not all hardware modules will include the ability to replace or update the bootstrap loader, and this specification does not mandate such support.
引导加载程序可以是硬件模块的永久部分，也可以通过加载固件包来替换。在图1中，引导加载程序作为硬件模块内的独立逻辑实现。并非所有的硬件模块都能够更换或更新引导加载程序，本规范并不强制要求提供此类支持。
If the bootstrap loader can be loaded by a firmware package, an initial bootstrap loader MUST be installed in non-volatile memory prior to deployment. All bootstrap loaders, including an initial
如果引导加载程序可以通过固件包加载，则在部署之前，必须在非易失性内存中安装初始引导加载程序。所有引导加载程序，包括初始
bootstrap loader if one is employed, MUST meet the requirements in this section. However, the firmware package containing the bootstrap loader MAY also contain other routines.
如果使用引导加载程序，则必须满足本节中的要求。但是，包含引导加载程序的固件包也可能包含其他例程。
The bootstrap loader requires access to cryptographic routines. These routines can be implemented specifically for the bootstrap loader, or they can be shared with other hardware module features. The bootstrap loader MUST have access to a one-way hash function and digital signature verification routines to validate the digital signature on the firmware package and to validate the certification path for the firmware-signing certificate.
引导加载程序需要访问加密例程。这些例程可以专门为引导加载程序实现，也可以与其他硬件模块功能共享。引导加载程序必须能够访问单向散列函数和数字签名验证例程，以验证固件包上的数字签名，并验证固件签名证书的认证路径。
If firmware packages are encrypted, the bootstrap loader MUST have access to a decryption routine. Access to a corresponding encryption function is not required, since hardware modules need not be capable of generating firmware packages. Because some symmetric encryption algorithm implementations (such as AES [AES]) employ separate logic for encryption and decryption, some hardware module savings might result.
如果固件包已加密，则引导加载程序必须能够访问解密例程。不需要访问相应的加密功能，因为硬件模块不需要能够生成固件包。由于某些对称加密算法实现（如AES[AES]）采用单独的加密和解密逻辑，因此可能会节省一些硬件模块。
If firmware packages are compressed, the bootstrap loader MUST also have access to a decompression function. This function can be implemented specifically for the bootstrap loader, or it can be shared with other hardware module features. Access to a corresponding compression function is not required, since hardware modules need not be capable of generating firmware packages.
如果固件包被压缩，引导加载程序还必须能够访问解压缩功能。此功能可以专门为引导加载程序实现，也可以与其他硬件模块功能共享。不需要访问相应的压缩功能，因为硬件模块不需要能够生成固件包。
If the optional receipt generation or error report capability is supported, the bootstrap loader MUST have access to the hardware module serial number and the object identifier for the hardware module type. If the optional signed receipt generation or signed error report capability is supported, the bootstrap loader MUST also have access to a one-way hash function and digital signature routines, the hardware module private signing key, and the corresponding signature validation certificate or its designator.
如果支持可选的收据生成或错误报告功能，则引导加载程序必须能够访问硬件模块序列号和硬件模块类型的对象标识符。如果支持可选的签名收据生成或签名错误报告功能，则引导加载程序还必须能够访问单向散列函数和数字签名例程、硬件模块私有签名密钥以及相应的签名验证证书或其标识符。
The bootstrap loader requires access to one or more trusted public keys, called trust anchors, to validate the firmware package digital signature. One or more trust anchors MUST be installed in non-volatile memory prior to deployment. The bootstrap loader MUST reject a firmware package if it cannot validate the signature, which MAY require the construction of a valid certification path from the firmware-signing certificate to one of the trust anchors [PROFILE]. However, in many cases, the firmware package signature will be validated directly with the trust anchor public key, avoiding the need to construct certification paths.
引导加载程序需要访问一个或多个受信任的公钥（称为信任锚），以验证固件包数字签名。在部署之前，必须在非易失性内存中安装一个或多个信任锚点。如果引导加载程序无法验证签名，则必须拒绝固件包，这可能需要构造从固件签名证书到信任锚之一的有效认证路径[PROFILE]。然而，在许多情况下，固件包签名将直接使用信任锚公钥进行验证，从而避免了构建认证路径的需要。
The bootstrap loader MUST reject a firmware package if the list of supported hardware module type identifiers within the firmware package does not include the object identifier of the hardware module.
如果固件包中支持的硬件模块类型标识符列表不包括硬件模块的对象标识符，则引导加载程序必须拒绝固件包。
The bootstrap loader MUST reject a firmware package if the firmware package includes a list of community identifiers and the hardware module is not a member of one of the listed communities. The means of determining community membership is beyond the scope of this specification.
如果固件包包含社区标识符列表且硬件模块不是所列社区之一的成员，则引导加载程序必须拒绝固件包。确定社区成员资格的方法超出了本规范的范围。
The bootstrap loader MUST reject a firmware package if it cannot successfully decrypt the firmware package using the firmware-decryption key available to the hardware module. The firmware package contains an identifier of the firmware-decryption key needed for decryption.
如果引导加载程序无法使用硬件模块可用的固件解密密钥成功解密固件包，则引导加载程序必须拒绝固件包。固件包包含解密所需的固件解密密钥的标识符。
When an earlier version of a firmware package is replacing a later one, the bootstrap loader SHOULD generate a warning. The manner in which a warning is generated is highly dependent on the hardware module and the environment in which it is being used. If a firmware package with a disastrous flaw is released and subsequent firmware package versions designate a stale version, the bootstrap loader SHOULD prevent loading of the stale version and versions earlier than the stale version.
当固件包的早期版本替换较新版本时，引导加载程序应生成警告。产生警告的方式在很大程度上取决于硬件模块及其使用环境。如果发布了具有灾难性缺陷的固件包，并且后续固件包版本指定了过时版本，则引导加载程序应防止加载过时版本和早于过时版本的版本。
In case a firmware package with a disastrous flaw is released, subsequent firmware package versions that employ the legacy firmware package name form MAY include a stale legacy firmware package name to prevent subsequent rollback to the stale version or versions earlier than the stale version. As described in the Security Considerations section of this document, the inclusion of a stale legacy firmware package name in a firmware package cannot completely prevent subsequent use of the stale firmware package. However, many hardware modules are expected to have very few firmware packages written for them, allowing the stale firmware package version feature to provide important protections.
如果发布了具有灾难性缺陷的固件包，则采用旧固件包名称表单的后续固件包版本可能包括旧固件包名称，以防止后续回滚到旧版本或早于旧版本的版本。如本文档“安全注意事项”部分所述，在固件包中包含陈旧的旧固件包名称不能完全阻止后续使用陈旧的固件包。然而，许多硬件模块预计很少有为它们编写的固件包，这使得陈旧的固件包版本功能能够提供重要的保护。
Non-volatile storage for stale version numbers is needed. The number of stale legacy firmware package names that can be stored depends on the amount of storage that is available. When a firmware package is loaded and it contains a stale legacy firmware package name, then it SHOULD be added to a list kept in non-volatile storage. When subsequent firmware packages are loaded, the legacy firmware package
需要用于过时版本号的非易失性存储。可以存储的陈旧旧固件包名称的数量取决于可用的存储量。加载固件包时，如果该固件包包含过时的旧固件包名称，则应将其添加到保存在非易失性存储器中的列表中。加载后续固件包时，旧固件包
name of the new package is compared to the list in non-volatile storage. If the legacy firmware package name represents the same version or an older version of a member of the list, then the new firmware packages SHOULD be rejected.
将新包的名称与非易失性存储器中的列表进行比较。如果旧固件包名称表示列表成员的相同版本或旧版本，则应拒绝新固件包。
The amount of non-volatile storage that needs to be dedicated to saving legacy firmware package names and stale legacy firmware packages names depends on the number of firmware packages that are likely to be developed for the hardware module.
需要专用于保存旧固件软件包名称和过时旧固件软件包名称的非易失性存储量取决于可能为硬件模块开发的固件软件包数量。
If a firmware package with a disastrous flaw is released, subsequent firmware package versions that employ preferred firmware package name form MAY include a stale version number to prevent subsequent rollback to the stale version or versions earlier than the stale version. As described in the Security Considerations section of this document, the inclusion of a stale version number in a firmware package cannot completely prevent subsequent use of the stale firmware package. However, many hardware modules are expected to have very few firmware packages written for them, allowing the stale firmware package version feature to provide important protections.
如果发布了具有灾难性缺陷的固件软件包，则采用首选固件软件包名称形式的后续固件软件包版本可能包括过时版本号，以防止后续回滚到过时版本或早于过时版本的版本。如本文档安全注意事项部分所述，在固件包中包含过时版本号不能完全阻止后续使用过时固件包。然而，许多硬件模块预计很少有为它们编写的固件包，这使得陈旧的固件包版本功能能够提供重要的保护。
Non-volatile storage for stale version numbers is needed. The number of stale version numbers that can be stored depends on the amount of storage that is available. When a firmware package is loaded and it contains a stale version number, then the object identifier of the firmware package and the stale version number SHOULD be added to a list that is kept in non-volatile storage. When subsequent firmware packages are loaded, the object identifier and version number of the new package are compared to the list in non-volatile storage. If the object identifier matches and the version number is less than or equal to the stale version number, then the new firmware packages SHOULD be rejected.
需要用于过时版本号的非易失性存储。可以存储的过时版本号的数量取决于可用的存储量。加载固件软件包且其包含过时版本号时，应将固件软件包的对象标识符和过时版本号添加到保存在非易失性存储器中的列表中。加载后续固件包时，将新包的对象标识符和版本号与非易失性存储器中的列表进行比较。如果对象标识符匹配且版本号小于或等于过时版本号，则应拒绝新固件包。
The amount of non-volatile storage that needs to be dedicated to saving firmware package identifiers and stale version numbers depends on the number of firmware packages that are likely to be developed for the hardware module.
需要专用于保存固件包标识符和过时版本号的非易失性存储器的数量取决于可能为硬件模块开发的固件包的数量。
A trust anchor MUST consist of a public key signature algorithm and an associated public key, which MAY optionally include parameters. A trust anchor MUST also include a public key identifier. A trust anchor MAY also include an X.500 distinguished name.
信任锚点必须由公钥签名算法和关联公钥组成，该公钥可以选择包含参数。信任锚还必须包括公钥标识符。信任锚还可以包括X.500可分辨名称。
The trust anchor public key is used in conjunction with the signature validation algorithm in two different ways. First, the trust anchor public key is used directly to validate the firmware package signature. Second, the trust anchor public key is used to validate an X.509 certification path, and then the subject public key in the final certificate in the certification path is used to validate the firmware package signature.
信任锚公钥以两种不同的方式与签名验证算法结合使用。首先，信任锚公钥直接用于验证固件包签名。其次，使用信任锚公钥验证X.509证书路径，然后使用证书路径中最终证书中的主题公钥验证固件包签名。
The public key names the trust anchor, and each public key has a public key identifier. The public key identifier identifies the trust anchor as the signer when it is used directly to validate firmware package signatures. This key identifier can be stored with the trust anchor, or it can be computed from the public key whenever needed.
公钥命名信任锚，每个公钥都有一个公钥标识符。公钥标识符在直接用于验证固件包签名时将信任锚标识为签名者。该密钥标识符可以与信任锚一起存储，也可以在需要时从公钥计算。
The optional trusted X.500 distinguished name MUST be present in order for the trust anchor public key to be used to validate an X.509 certification path. Without an X.500 distinguished name, certification path construction cannot use the trust anchor.
必须存在可选的受信任X.500可分辨名称，才能使用信任锚公钥验证X.509证书路径。如果没有X.500可分辨名称，则证书路径构造无法使用信任锚点。
A firmware package for a cryptographic hardware module includes cryptographic algorithm implementations. In addition, a firmware package for a non-cryptographic hardware module will likely include cryptographic algorithm implementations to support the bootstrap loader in the validation of firmware packages.
加密硬件模块的固件包包括加密算法实现。此外，非加密硬件模块的固件包可能包括加密算法实现，以支持固件包验证中的引导加载程序。
A unique algorithm object identifier MUST be assigned for each cryptographic algorithm and mode implemented by a firmware package. A unique algorithm object identifier MUST also be assigned for each compression algorithm implemented by a firmware package. The algorithm object identifiers can be used to determine whether a particular firmware package satisfies the needs of a particular application. To facilitate the development of algorithm-agile applications, the cryptographic module interface SHOULD allow applications to query the cryptographic module for the object identifiers associated with each cryptographic algorithm contained in the currently loaded firmware package. Applications SHOULD also be able to query the cryptographic module to determine attributes associated with each algorithm. Such attributes might include the algorithm type (symmetric encryption, asymmetric encryption, key agreement, one-way hash function, digital signature, and so on), the algorithm block size or modulus size, and parameters for asymmetric algorithms. This specification does not establish the conventions for the retrieval of algorithm identifiers or algorithm attributes.
必须为固件包实现的每个加密算法和模式分配唯一的算法对象标识符。还必须为固件包实现的每个压缩算法分配唯一的算法对象标识符。算法对象标识符可用于确定特定固件包是否满足特定应用程序的需要。为了促进算法敏捷应用程序的开发，加密模块接口应允许应用程序查询加密模块，以获取与当前加载的固件包中包含的每个加密算法相关联的对象标识符。应用程序还应该能够查询加密模块，以确定与每个算法关联的属性。这些属性可能包括算法类型（对称加密、非对称加密、密钥协商、单向散列函数、数字签名等）、算法块大小或模大小以及非对称算法的参数。本规范未建立检索算法标识符或算法属性的约定。
The bootstrap loader MAY be permanently stored in read-only memory or separately loaded into non-volatile memory as discussed above.
引导加载程序可以永久存储在只读存储器中，或者如上所述单独加载到非易失性存储器中。
In most hardware module designs, the firmware package execution environment offers a single address space. If it does, the firmware package SHOULD contain a complete firmware package load for the hardware module. In this situation, the firmware package does not contain a partial or incremental set of functions. A complete firmware package load will minimize complexity and avoid potential security problems. From a complexity perspective, the incremental loading of packages makes it necessary for each package to identify any other packages that are required (its dependencies), and the bootstrap loader needs to verify that all of the dependencies are satisfied before attempting to execute the firmware package. When a hardware module is based on a general purpose processor or a digital signal processor, it is dangerous to allow arbitrary packages to be loaded simultaneously unless there is a reference monitor to ensure that independent portions of the code cannot interfere with one another. Also, it is difficult to evaluate arbitrary combinations of software modules [SECREQMTS]. For these reasons, a complete firmware package load is RECOMMENDED; however, this specification allows the firmware signer to identify dependencies between firmware packages in order to handle all situations.
在大多数硬件模块设计中，固件包执行环境提供单个地址空间。如果有，固件包应包含硬件模块的完整固件包负载。在这种情况下，固件包不包含部分或增量功能集。完整的固件包加载将最小化复杂性并避免潜在的安全问题。从复杂性的角度来看，包的增量加载使得每个包都有必要识别所需的任何其他包（其依赖项），引导加载程序需要在尝试执行固件包之前验证是否满足所有依赖项。当硬件模块基于通用处理器或数字信号处理器时，允许同时加载任意包是危险的，除非有参考监视器以确保代码的独立部分不会相互干扰。此外，很难评估软件模块的任意组合[SECREQMTS]。出于这些原因，建议加载完整的固件包；但是，该规范允许固件签名者识别固件包之间的依赖关系，以便处理所有情况。
The firmware packages MAY have dependencies on routines provided by other firmware packages. To minimize the security evaluation complexity of a hardware module employing such a design, the firmware package MUST identify the package identifiers (and the minimum version numbers when the preferred firmware package name form is used) of the packages upon which it depends. The bootstrap loader MUST reject a firmware package load if it contains a dependency on a firmware package that is not available.
固件包可能依赖于其他固件包提供的例程。为了最小化采用这种设计的硬件模块的安全评估复杂性，固件包必须识别其所依赖的包的包标识符（以及使用首选固件包名称形式时的最小版本号）。如果引导加载程序包含对不可用固件包的依赖项，则引导加载程序必须拒绝固件包加载。
Loading a firmware package can impact the satisfactory resolution of dependencies of other firmware packages that are already part of the hardware module configuration. For this reason, the bootstrap loader MUST reject the loading of a firmware package if the dependencies of any firmware package in the resulting configurations will be unsatisfied.
加载固件包可能会影响已作为硬件模块配置一部分的其他固件包的依赖关系的满意解决方案。因此，如果结果配置中的任何固件包的依赖关系不满足，引导加载程序必须拒绝加载固件包。
The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88, X.209-88]. ASN.1 is a formal notation used for describing data protocols, regardless of the programming language used by the implementation. Encoding rules describe how the values defined in
CMS使用抽象语法符号1（ASN.1）[X.208-88，X.209-88]。ASN.1是一种用于描述数据协议的正式符号，与实现所使用的编程语言无关。编码规则描述如何在中定义值
ASN.1 will be represented for transmission. The Basic Encoding Rules (BER) are the most widely employed rule set, but they offer more than one way to represent data structures. For example, definite length encoding and indefinite length encoding are supported. This flexibility is not desirable when digital signatures are used. As a result, the Distinguished Encoding Rules (DER) [X.509-88] were invented. DER is a subset of BER that ensures a single way to represent a given value. For example, DER always employs definite length encoding.
ASN.1将用于传输。基本编码规则（BER）是应用最广泛的规则集，但它们提供了多种表示数据结构的方法。例如，支持定长编码和定长编码。当使用数字签名时，这种灵活性是不可取的。因此，发明了区分编码规则（DER）[X.509-88]。DER是BER的一个子集，确保以单一方式表示给定值。例如，DER总是采用定长编码。
In this specification, digitally signed structures MUST be encoded with DER. Other structures do not require DER, but the use of definite length encoding is strongly RECOMMENDED. By always using definite length encoding, the bootstrap loader will have fewer options to implement. In situations where there is very high confidence that only definite length encoding will be used, support for indefinite length decoding MAY be omitted.
在本规范中，数字签名结构必须使用DER编码。其他结构不需要DER，但强烈建议使用定长编码。通过始终使用定长编码，引导加载程序将有更少的选项来实现。在仅使用定长编码的置信度非常高的情况下，可以省略对定长解码的支持。
This document does not attempt to specify a physical interface, any related driver software, or a protocol necessary for loading firmware packages. Many different delivery mechanisms are envisioned, including portable memory devices, file transfer, and web pages. Section 2 of this specification defines the format that MUST be presented to the hardware module regardless of the interface that is used. This specification also specifies the format of the response that MAY be generated by the hardware module. Section 3 of this specification defines the format that MAY be returned by the hardware module when a firmware package loads successfully. Section 4 of this specification defines the format that MAY be returned by the hardware module when a firmware package load is unsuccessful. The firmware package load receipts and firmware package load error reports can be either signed or unsigned.
本文档不试图指定加载固件包所需的物理接口、任何相关驱动程序软件或协议。设想了许多不同的交付机制，包括便携式存储设备、文件传输和网页。本规范第2节定义了无论使用何种接口，必须呈现给硬件模块的格式。本规范还规定了硬件模块可能生成的响应格式。本规范第3节定义了固件包成功加载时硬件模块可能返回的格式。本规范第4节定义了固件包加载失败时硬件模块可能返回的格式。固件包加载回执和固件包加载错误报告可以是已签名或未签名的。
The Cryptographic Message Syntax (CMS) is used to protect a firmware package, which is treated as an opaque binary object. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. The CMS ContentInfo content type MUST always be present, and it MUST encapsulate the CMS SignedData content type. If the firmware package is encrypted, then the CMS SignedData content type MUST encapsulate the CMS EncryptedData content type. If the firmware package is compressed, then either the CMS SignedData
加密消息语法（CMS）用于保护固件包，固件包被视为不透明的二进制对象。数字签名用于保护固件包免受未检测到的修改，并提供数据源身份验证。加密可选地用于保护固件包不被泄露，压缩可选地用于减小受保护固件包的大小。CMS ContentInfo内容类型必须始终存在，并且必须封装CMS SignedData内容类型。如果固件包已加密，则CMS SignedData内容类型必须封装CMS EncryptedData内容类型。如果固件包已压缩，则CMS SignedData
content type (when encryption is not used) or the CMS EncryptedData content type (when encryption is used) MUST encapsulate the CMS CompressedData content type. Finally, (1) the CMS SignedData content type (when neither encryption nor compression is used), (2) the CMS EncryptedData content type (when encryption is used, but compression is not), or (3) the CMS CompressedData content type (when compression is used) MUST encapsulate the simple firmware package using the FirmwarePkgData content type defined in this specification (see Section 2.1.5).
内容类型（未使用加密时）或CMS EncryptedData内容类型（使用加密时）必须封装CMS CompressedData内容类型。最后，（1）CMS SignedData内容类型（不使用加密或压缩时），（2）CMS EncryptedData内容类型（使用加密但不使用压缩时），或（3）CMS CompressedData内容类型（使用压缩时）必须使用本规范中定义的FirmwarePkgData内容类型封装简单固件包（见第2.1.5节）。
The firmware package protection is summarized as follows (see [CMS] for the full syntax):
固件包保护概述如下（完整语法见[CMS]：
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer cert. path
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer cert. path
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
-- OR --
id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING
} -- Contains EncryptedData OR
-- CompressedData OR
-- FirmwarePkgData
EncapsulatedContentInfo {
eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
-- OR --
id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING
} -- Contains EncryptedData OR
-- CompressedData OR
-- FirmwarePkgData
EncryptedData {
version CMSVersion, -- Always set to 0
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs UnprotectedAttributes -- Omit
}
EncryptedData {
version CMSVersion, -- Always set to 0
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs UnprotectedAttributes -- Omit
}
EncryptedContentInfo {
contentType id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent OCTET STRING
} -- Contains CompressedData OR
-- FirmwarePkgData
EncryptedContentInfo {
contentType id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent OCTET STRING
} -- Contains CompressedData OR
-- FirmwarePkgData
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
FirmwarePkgData OCTET STRING -- Contains firmware package
FirmwarePkgData八位字节字符串--包含固件包
This section specifies the conventions for using the CMS ContentInfo, SignedData, EncryptedData, and CompressedData content types. It also defines the FirmwarePkgData content type.
本节指定使用CMS ContentInfo、SignedData、EncryptedData和CompressedData内容类型的约定。它还定义了FirmwarePkgData内容类型。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMS要求最外层的封装是ContentInfo[CMS]。ContentInfo的字段使用如下：
contentType indicates the type of the associated content, and in this case, the encapsulated type is always SignedData. The id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
contentType指示关联内容的类型，在本例中，封装的类型始终为SignedData。id signedData（1.2.840.113549.1.7.2）对象标识符必须存在于该字段中。
content holds the associated content, and in this case, the content field MUST contain SignedData.
内容包含关联的内容，在这种情况下，内容字段必须包含SignedData。
The SignedData content type [CMS] contains the signed firmware package (which might be compressed, encrypted, or compressed and then encrypted prior to signature), the certificates needed to validate the signature, and one digital signature value. The fields of SignedData are used as follows:
SignedData内容类型[CMS]包含已签名的固件包（可能经过压缩、加密或压缩，然后在签名之前进行加密）、验证签名所需的证书以及一个数字签名值。SignedData的字段使用如下：
version is the syntax version number, and in this case, it MUST be set to 3.
version是语法版本号，在本例中，它必须设置为3。
digestAlgorithms is a collection of message digest algorithm identifiers, and in this case, it MUST contain a single message digest algorithm identifier. The message digest algorithm employed by the firmware package signer MUST be present.
digestAlgorithms是消息摘要算法标识符的集合，在这种情况下，它必须包含单个消息摘要算法标识符。固件包签名者使用的消息摘要算法必须存在。
encapContentInfo contains the signed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 2.1.2.2.
encapContentInfo包含已签名的内容，由内容类型标识符和内容本身组成。第2.1.2.2节将进一步讨论封装ContentInfo类型的使用。
certificates is an optional collection of certificates. If the trust anchor signed the firmware package directly, then certificates SHOULD be omitted. If it did not, then certificates SHOULD include the X.509 certificate of the firmware package signer. The set of certificates SHOULD be sufficient for the bootstrap loader to construct a certification path from the trust anchor to the firmware-signer's certificate. PKCS#6 extended certificates
证书是证书的可选集合。如果信任锚直接签署固件包，则应忽略证书。如果没有，则证书应包括固件包签名者的X.509证书。证书集应足以让引导加载程序构建从信任锚点到固件签名者证书的证书路径。PKCS#6扩展证书
[PKCS#6] and attribute certificates (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set of certificates.
[PKCS#6]和属性证书（版本1或版本2）[X.509-97，X.509-00，ACPROFILE]不得包含在证书集中。
crls is an optional collection of certificate revocation lists (CRLs), and in this case, CRLs SHOULD NOT be included by the firmware package signer. It is anticipated that firmware packages may be generated, signed, and made available in repositories for downloading into hardware modules. In such contexts, it would be difficult for the firmware package signer to include timely CRLs in the firmware package. However, because the CRLs are not covered by the signature, timely CRLs MAY be inserted by some other party before the firmware package is delivered to the hardware module.
CRL是证书吊销列表（CRL）的可选集合，在这种情况下，固件包签名者不应包括CRL。预计固件包可能会生成、签名并在存储库中提供，以便下载到硬件模块中。在这种情况下，固件包签名者很难在固件包中及时包含CRL。但是，由于CRL不在签名范围内，因此在固件包交付到硬件模块之前，其他方可能会及时插入CRL。
signerInfos is a collection of per-signer information, and in this case, the collection MUST contain exactly one SignerInfo. The use of the SignerInfo type is discussed further in Section 2.1.2.1.
signerInfos是每个签名者信息的集合，在这种情况下，集合必须仅包含一个signerInfos。第2.1.2.1节将进一步讨论SignerInfo类型的使用。
The firmware package signer is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
固件包签名者以SignerInfo类型表示。SignerInfo的字段使用如下：
version is the syntax version number, and it MUST be 3.
version是语法版本号，必须为3。
sid identifies the signer's public key. CMS supports two alternatives: issuerAndSerialNumber and subjectKeyIdentifier. However, the bootstrap loader MUST support the subjectKeyIdentifier alternative, which identifies the signer's public key directly. When this public key is contained in a certificate, this identifier SHOULD appear in the X.509 subjectKeyIdentifier extension.
sid标识签名者的公钥。CMS支持两种选择：issuerAndSerialNumber和subjectKeyIdentifier。但是，引导加载程序必须支持subjectKeyIdentifier替代方案，它直接标识签名者的公钥。当此公钥包含在证书中时，此标识符应出现在X.509 subjectKeyIdentifier扩展中。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the firmware package signer. It MUST contain the message digest algorithms employed by the firmware package signer. (Note that this message digest algorithm identifier MUST be the same as the one carried in the digestAlgorithms value in SignedData.)
digestAlgorithm标识固件包签名者使用的消息摘要算法和任何相关参数。它必须包含固件包签名者使用的消息摘要算法。（请注意，此消息摘要算法标识符必须与SignedData中digestAlgorithms值中携带的标识符相同。）
signedAttrs is an optional collection of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED for the firmware package; however, implementations MUST ignore unrecognized signed attributes. The SET OF attributes MUST be DER
signedAttrs是随内容一起签名的属性的可选集合。SignedAttr在CMS中是可选的，但在本规范中，固件包需要SignedAttr；但是，实现必须忽略无法识别的签名属性。属性集必须为DER
encoded [X.509-88]. Section 2.2 of this document lists the attributes that MUST be included in the collection; other attributes MAY be included as well.
编码的[X.509-88]。本文件第2.2节列出了集合中必须包含的属性；还可以包括其他属性。
signatureAlgorithm identifies the signature algorithm, and any associated parameters, used by the firmware package signer to generate the digital signature.
signatureAlgorithm标识固件包签名者用于生成数字签名的签名算法和任何相关参数。
signature is the digital signature value.
签名是数字签名值。
unsignedAttrs is an optional SET of attributes that are not signed. As described in Section 2.3, this set can only contain a single instance of the wrapped-firmware-decryption-key attribute and no others.
unsignedAttrs是一组可选的未签名属性。如第2.3节所述，此集合只能包含包装固件解密密钥属性的单个实例，而不能包含其他实例。
The EncapsulatedContentInfo content type encapsulates the firmware package, which might be compressed, encrypted, or compressed and then encrypted prior to signature. The firmware package, in any of these formats, is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
封装的ContentInfo内容类型封装固件包，固件包可能经过压缩、加密或压缩，然后在签名之前进行加密。这些格式的固件包都包含在封装的ContentInfo类型中。封装的ContentInfo字段的使用方式如下：
eContentType is an object identifier that uniquely specifies the content type, and in this case, the value MUST be id-encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When eContentType contains id-encryptedData, the firmware package was encrypted prior to signing, and may also have been compressed prior to encryption. When it contains id-ct-compressedData, the firmware package was compressed prior to signing, but was not encrypted. When it contains id-ct-firmwarePackage, the firmware package was not compressed or encrypted prior to signing.
eContentType是唯一指定内容类型的对象标识符，在本例中，该值必须是id encryptedData（1.2.840.113549.1.7.6）、id ct compressedData（1.2.840.113549.1.9.16.1.9）或id ct firmwarePackage（1.2.840.113549.1.9.16.16）。当eContentType包含id encryptedData时，固件包在签名之前已加密，并且可能在加密之前已压缩。当它包含id ct compressedData时，固件包在签名之前已压缩，但未加密。当它包含id ct firmwarePackage时，固件包在签名之前未被压缩或加密。
eContent contains the signed firmware package, which might also be encrypted, compressed, or compressed and then encrypted, prior to signing. The content is encoded as an octet string. The eContent octet string need not be DER encoded.
eContent包含签名的固件包，该固件包也可能在签名之前进行加密、压缩或压缩然后加密。内容被编码为八位字节字符串。eContent八位字节字符串不需要进行DER编码。
The EncryptedData content type [CMS] contains the encrypted firmware package (which might be compressed prior to encryption). However, if the firmware package was not encrypted, the EncryptedData content type is not present. The fields of EncryptedData are used as follows:
EncryptedData内容类型[CMS]包含加密固件包（可能在加密之前进行压缩）。但是，如果固件包未加密，则EncryptedData内容类型不存在。EncryptedData的字段使用如下：
version is the syntax version number, and in this case, version MUST be 0.
version是语法版本号，在本例中，version必须为0。
encryptedContentInfo is the encrypted content information. The use of the EncryptedContentInfo type is discussed further in Section 2.1.3.1.
encryptedContentInfo是加密的内容信息。第2.1.3.1节将进一步讨论EncryptedContentInfo类型的使用。
unprotectedAttrs is an optional collection of unencrypted attributes, and in this case, unprotectedAttrs MUST NOT be present.
unprotectedAttrs是未加密属性的可选集合，在这种情况下，unprotectedAttrs不得存在。
The encrypted firmware package, which might be compressed prior to encryption, is encapsulated in the EncryptedContentInfo type. The fields of EncryptedContentInfo are used as follows:
加密固件包（可能在加密之前进行压缩）封装在EncryptedContentInfo类型中。EncryptedContentInfo的字段使用如下：
contentType indicates the type of content, and in this case, it MUST contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it contains id-ct-compressedData, then the firmware package was compressed prior to encryption. When it contains id-ct-firmwarePackage, then the firmware package was not compressed prior to encryption.
contentType表示内容的类型，在这种情况下，它必须包含id ct compressedData（1.2.840.113549.1.9.16.1.9）或id ct firmwarePackage（1.2.840.113549.1.9.16.1.16）。当它包含id ct compressedData时，固件包在加密之前被压缩。当它包含id ct firmwarePackage时，固件包在加密之前未被压缩。
contentEncryptionAlgorithm identifies the firmware-encryption algorithm, and any associated parameters, used to encrypt the firmware package.
contentEncryptionAlgorithm标识用于加密固件包的固件加密算法和任何相关参数。
encryptedContent is the result of encrypting the firmware package. The field is optional; however, in this case, it MUST be present.
encryptedContent是加密固件包的结果。该字段是可选的；然而，在这种情况下，它必须存在。
The CompressedData content type [COMPRESS] contains the compressed firmware package. If the firmware package was not compressed, then the CompressedData content type is not present. The fields of CompressedData are used as follows:
CompressedData内容类型[COMPRESS]包含压缩固件包。如果固件包未压缩，则CompressedData内容类型不存在。CompressedData字段的使用方式如下：
version is the syntax version number; in this case, it MUST be 0.
版本是语法版本号；在这种情况下，它必须是0。
compressionAlgorithm identifies the compression algorithm, and any associated parameters, used to compress the firmware package.
compressionAlgorithm标识用于压缩固件包的压缩算法和任何相关参数。
encapContentInfo is the compressed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 2.1.4.1.
encapContentInfo是压缩内容，由内容类型标识符和内容本身组成。第2.1.4.1节将进一步讨论封装ContentInfo类型的使用。
The CompressedData content type encapsulates the compressed firmware package, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
CompressedData内容类型封装了压缩的固件包，它包含在封装的ContentInfo类型中。封装的ContentInfo字段的使用方式如下：
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).
eContentType是唯一指定内容类型的对象标识符，在本例中，它必须是id ct firmwarePackage（1.2.840.113549.1.9.16.1.16）的值。
eContent is the compressed firmware package, encoded as an octet string. The eContent octet string need not be DER encoded.
eContent是压缩固件包，编码为八位字节字符串。eContent八位字节字符串不需要进行DER编码。
The FirmwarePkgData content type contains the firmware package. It is a straightforward encapsulation in an octet string, and it need not be DER encoded.
FirmwarePkgData内容类型包含固件包。它是一个八位字节字符串中的简单封装，不需要进行DER编码。
The FirmwarePkgData content type is identified by the id-ct-firmwarePackage object identifier:
FirmwarePkgData内容类型由id ct firmwarePackage对象标识符标识：
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
The FirmwarePkgData content type is a simple octet string:
FirmwarePkgData内容类型是一个简单的八位字节字符串：
FirmwarePkgData ::= OCTET STRING
FirmwarePkgData ::= OCTET STRING
The firmware package signer MUST digitally sign a collection of attributes along with the firmware package. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], but it is repeated here for convenience:
固件包签名者必须对一组属性以及固件包进行数字签名。集合中的每个属性都必须进行DER编码[X.509-88]。属性的语法在[CMS]中定义，但为方便起见，此处重复此语法：
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
AttributeValue ::= ANY
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
此配置文件使用的每个属性都有一个属性值，即使语法定义为一组AttributeValue。必须仅存在一个AttributeValue实例。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo中的SignedAttributes语法定义为一组属性。SignedAttribute只能包含任何特定属性的一个实例。
The firmware package signer MUST include the following four attributes: content-type, message-digest, firmware-package-identifier, and target-hardware-module-identifiers.
固件包签名者必须包括以下四个属性：内容类型、消息摘要、固件包标识符和目标硬件模块标识符。
If the firmware package is encrypted, then the firmware package signer MUST also include the decrypt-key-identifier attribute.
如果固件包已加密，则固件包签名者还必须包括解密密钥标识符属性。
If the firmware package implements cryptographic algorithms, then the firmware package signer MAY also include the implemented-crypto-algorithms attribute. Similarly, if the firmware package implements compression algorithms, then the firmware package signer MAY also include the implemented-compress-algorithms attribute.
如果固件包实现加密算法，那么固件包签名者还可以包括实现的加密算法属性。类似地，如果固件包实现压缩算法，则固件包签名者还可以包括实现的压缩算法属性。
If the firmware package is intended for use only by specific communities, then the firmware package signer MUST also include the community-identifiers attribute.
如果固件包仅用于特定社区，则固件包签名者还必须包括社区标识符属性。
If the firmware package depends on the presence of one or more other firmware packages to operate properly, then the firmware package signer SHOULD also include the firmware-package-info attribute. For example, the firmware-package-info attribute dependencies field might indicate that the firmware package contains a dependency on a particular bootstrap loader or separation kernel.
如果固件包取决于是否存在一个或多个其他固件包才能正常运行，则固件包签名者还应包括固件包信息属性。例如，固件包信息属性依赖项字段可能指示固件包包含对特定引导加载程序或分离内核的依赖项。
The firmware package signer SHOULD also include the three following attributes: firmware-package-message-digest, signing-time, and content-hints. Additionally, if the firmware package signer has a certificate (meaning that the firmware package signer is not always configured as a trust anchor), then the firmware package signer SHOULD also include the signing-certificate attribute.
固件包签名者还应包括以下三个属性：固件包消息摘要、签名时间和内容提示。此外，如果固件包签名者具有证书（意味着固件包签名者并不总是配置为信任锚点），则固件包签名者还应包括签名证书属性。
The firmware package signer MAY include any other attribute that it deems appropriate.
固件包签名者可以包括其认为适当的任何其他属性。
The firmware package signer MUST include a content-type attribute with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData, the firmware package was encrypted prior to signing. When it contains id-ct-compressedData, the firmware package was compressed prior to signing, but was not encrypted. When it contains
固件包签名者必须包含一个值为id encryptedData（1.2.840.113549.1.7.6）、id ct compressedData（1.2.840.113549.1.9.16.1.9）或id ct firmwarePackage（1.2.840.113549.1.9.16.16）的内容类型属性。当它包含id encryptedData时，固件包在签名之前已加密。当它包含id ct compressedData时，固件包在签名之前已压缩，但未加密。当它包含
id-ct-firmwarePackage, the firmware package was not compressed or encrypted prior to signing. Section 11.1 of [CMS] defines the content-type attribute.
id ct firmwarePackage，固件包在签名之前未压缩或加密。[CMS]第11.1节定义了内容类型属性。
The firmware package signer MUST include a message-digest attribute, having as its value the message digest computed on the encapContentInfo eContent octet string, as defined in Section 2.1.2.2. This octet string contains the firmware package, and it MAY be compressed, encrypted, or both compressed and encrypted. Section 11.2 of [CMS] defines the message-digest attribute.
固件包签名者必须包含消息摘要属性，其值为根据encapContentInfo eContent八位字节字符串计算的消息摘要，如第2.1.2.2节所定义。此八位字节字符串包含固件包，它可以是压缩的、加密的，也可以是压缩和加密的。[CMS]第11.2节定义了消息摘要属性。
The firmware-package-identifier attribute names the protected firmware package. Two approaches to naming firmware packages are supported: legacy and preferred. The firmware package signer MUST include a firmware-package-identifier attribute using one of these name forms.
固件包标识符属性命名受保护的固件包。支持两种命名固件包的方法：传统和首选。固件包签名者必须使用以下名称表单之一包含固件包标识符属性。
A legacy firmware package name is an octet string, and no structure within the octet string is assumed.
传统固件包名称是八位字节字符串，并且假定八位字节字符串中没有结构。
A preferred firmware package name is a combination of an object identifier and a version number. The object identifier names a collection of functions implemented by the firmware package, and the version number is a non-negative integer that identifies a particular build or release of the firmware package.
首选固件包名称是对象标识符和版本号的组合。对象标识符命名由固件包实现的功能集合，版本号是非负整数，用于标识固件包的特定构建或发布。
If a firmware package with a disastrous flaw is released, the firmware package that repairs the previously distributed flaw MAY designate a stale firmware package version to prevent the reloading of the flawed version. The hardware module bootstrap loader SHOULD prevent subsequent rollback to the stale version or versions earlier than the stale version. When the legacy firmware package name form is used, the stale version is indicated by a stale legacy firmware package name, which is an octet string. We assume that the firmware package signer and the bootstrap loader can determine whether a given legacy firmware package name represents a version that is more recent than the stale one. When the preferred firmware package name form is used, the stale version is indicated by a stale version number, which is an integer.
如果发布了具有灾难性缺陷的固件包，则修复先前分发的缺陷的固件包可能会指定一个过时的固件包版本，以防止重新加载有缺陷的版本。硬件模块引导加载程序应防止随后回滚到过时版本或早于过时版本的版本。使用旧版固件软件包名称表单时，旧版本由旧版旧版固件软件包名称表示，该名称为八位字节字符串。我们假设固件包签名者和引导加载程序可以确定给定的旧固件包名称是否代表比旧固件包更新的版本。使用首选固件包名称形式时，过时版本由过时版本号表示，该编号为整数。
The following object identifier identifies the firmware-package-identifier attribute:
以下对象标识符标识固件包标识符属性：
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
The firmware-package-identifier attribute values have ASN.1 type FirmwarePackageIdentifier:
固件包标识符属性值具有ASN.1类型FirmwarePackageIdentifier：
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
The target-hardware-module-identifiers attribute names the types of hardware modules that the firmware package supports. A unique object identifier names each supported hardware model type and revision.
目标硬件模块标识符属性指定固件包支持的硬件模块类型。唯一的对象标识符命名每个受支持的硬件型号类型和版本。
The bootstrap loader MUST reject the firmware package if its own hardware module type identifier is not listed in the target-hardware-module-identifiers attribute.
如果目标硬件模块标识符属性中未列出自己的硬件模块类型标识符，则引导加载程序必须拒绝固件包。
The following object identifier identifies the target-hardware-module-identifiers attribute:
以下对象标识符标识目标硬件模块标识符属性：
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
The target-hardware-module-identifiers attribute values have ASN.1 type TargetHardwareIdentifiers:
目标硬件模块标识符属性值具有ASN.1类型的TargetHardwareIdentifier：
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
The decrypt-key-identifier attribute names the symmetric key needed to decrypt the encapsulated firmware package. The CMS EncryptedData content type is used when the firmware package is encrypted. The decrypt-key-identifier signed attribute is carried in the SignedData content type that encapsulates EncryptedData content type, naming the symmetric key needed to decrypt the firmware package. No particular structure is imposed on the key identifier. The means by which the firmware-decryption key is securely distributed to all modules that are authorized to use the associated firmware package is beyond the scope of this specification; however, an optional mechanism for securely distributing the firmware-decryption key with the firmware package is specified in Section 2.3.1.
decrypt key identifier属性指定解密封装的固件包所需的对称密钥。加密固件包时使用CMS EncryptedData内容类型。解密密钥标识符signed属性包含在封装EncryptedData内容类型的SignedData内容类型中，命名解密固件包所需的对称密钥。密钥标识符上没有特定的结构。将固件解密密钥安全分发给授权使用相关固件包的所有模块的方式超出了本规范的范围；但是，第2.3.1节规定了一种可选机制，用于安全分发固件解密密钥和固件包。
The following object identifier identifies the decrypt-key-identifier attribute:
以下对象标识符标识解密密钥标识符属性：
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
The decrypt-key-identifier attribute values have ASN.1 type DecryptKeyIdentifier:
解密密钥标识符属性值具有ASN.1类型的解密密钥标识符：
DecryptKeyIdentifier ::= OCTET STRING
DecryptKeyIdentifier ::= OCTET STRING
The implemented-crypto-algorithms attribute MAY be present in the SignedAttributes, and it names the cryptographic algorithms that are implemented by the firmware package and available to applications. Only those algorithms that are made available at the interface of the cryptographic module are listed. Any cryptographic algorithm that is used internally and is not accessible via the cryptographic module interface MUST NOT be listed. For example, if the firmware package implements the decryption algorithm for future firmware package installations and this algorithm is not made available for other uses, then the firmware-decryption algorithm would not be listed.
已实现的加密算法属性可能存在于SignedAttribute中，它命名由固件包实现并可供应用程序使用的加密算法。仅列出加密模块接口上可用的算法。不得列出任何内部使用且无法通过加密模块接口访问的加密算法。例如，如果固件包为将来的固件包安装实现了解密算法，并且该算法不可用于其他用途，则固件解密算法将不会列出。
The object identifier portion of AlgorithmIdentifier identifies an algorithm and its mode of use. No algorithm parameters are included. Cryptographic algorithms include traffic-encryption algorithms, key-encryption algorithms, key transport algorithms, key agreement algorithms, one-way hash algorithms, and digital signature algorithms. Cryptographic algorithms do not include compression algorithms.
AlgorithmIdentifier的对象标识符部分标识算法及其使用模式。不包括任何算法参数。密码算法包括流量加密算法、密钥加密算法、密钥传输算法、密钥协商算法、单向散列算法和数字签名算法。加密算法不包括压缩算法。
The following object identifier identifies the implemented-crypto-algorithms attribute:
以下对象标识符标识已实现的加密算法属性：
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
The implemented-crypto-algorithms attribute values have ASN.1 type ImplementedCryptoAlgorithms:
实现的加密算法属性值具有ASN.1类型的实现的加密算法：
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
The implemented-compress-algorithms attribute MAY be present in the SignedAttributes, and it names the compression algorithms that are implemented by the firmware package and available to applications. Only those algorithms that are made available at the interface of the hardware module are listed. Any compression algorithm that is used internally and is not accessible via the hardware module interface MUST NOT be listed. For example, if the firmware package implements a decompression algorithm for future firmware package installations and this algorithm is not made available for other uses, then the firmware-decompression algorithm would not be listed.
已实现的压缩算法属性可能存在于SignedAttribute中，它命名了由固件包实现并可供应用程序使用的压缩算法。仅列出在硬件模块接口处可用的算法。不得列出任何内部使用且无法通过硬件模块接口访问的压缩算法。例如，如果固件包为将来的固件包安装实现了解压缩算法，并且该算法不可用于其他用途，则固件解压缩算法将不会列出。
The object identifier portion of AlgorithmIdentifier identifies a compression algorithm. No algorithm parameters are included.
AlgorithmIdentifier的对象标识符部分标识压缩算法。不包括任何算法参数。
The following object identifier identifies the implemented-compress-algorithms attribute:
以下对象标识符标识实现的压缩算法属性：
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
The implemented-compress-algorithms attribute values have ASN.1 type ImplementedCompressAlgorithms:
“实现的压缩算法”属性值具有ASN.1类型的“实现的压缩算法”：
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
If present in the SignedAttributes, the community-identifiers attribute names the communities that are permitted to execute the firmware package. The bootstrap loader MUST reject the firmware package if the hardware module is not a member of one of the identified communities. The means of assigning community membership is beyond the scope of this specification.
如果存在于SignedAttribute中，community identifiers属性将命名允许执行固件包的社区。如果硬件模块不是已标识社区之一的成员，则引导加载程序必须拒绝固件包。分配社区成员资格的方法超出了本规范的范围。
The community-identifiers attributes names the authorized communities by a list of community object identifiers, by a list of specific hardware modules, or by a combination of the two lists. A specific hardware module is specified by the combination of the hardware module identifier (as defined in Section 2.2.4) and a serial number. To facilitate compact representation of serial numbers, a contiguous block can be specified by the lowest authorized serial number and the highest authorized serial number. Alternatively, all of the serial numbers associated with a hardware module family identifier can be specified with the NULL value.
社区标识符属性通过社区对象标识符列表、特定硬件模块列表或两个列表的组合来命名授权社区。特定硬件模块由硬件模块标识符（如第2.2.4节所定义）和序列号的组合指定。为了便于序列号的紧凑表示，可以通过最低授权序列号和最高授权序列号指定连续块。或者，可以使用空值指定与硬件模块系列标识符关联的所有序列号。
If the bootstrap loader does not have a mechanism for obtaining a list of object identifiers that identify the communities to which the hardware module is a member, then the bootstrap loader MUST behave as though the list is empty. Similarly, if the bootstrap loader does not have access to the hardware module serial number, then the bootstrap loader MUST behave as though the hardware module is not included on the list of authorized hardware modules.
如果引导加载程序没有获取标识硬件模块所属社区的对象标识符列表的机制，则引导加载程序的行为必须与该列表为空一样。类似地，如果引导加载程序无法访问硬件模块序列号，则引导加载程序的行为必须与授权硬件模块列表中未包含硬件模块一样。
The following object identifier identifies the community-identifiers attribute:
以下对象标识符标识社区标识符属性：
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
The community-identifiers attribute values have ASN.1 type CommunityIdentifiers:
社区标识符属性值具有ASN.1类型的社区标识符：
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
If a hardware module supports more than one type of firmware package, then the firmware package signer SHOULD include the firmware-package-info attribute with a populated fwPkgType field to identify the firmware package type. This value can aid the bootstrap loader in the correct placement of the firmware package within the hardware module. The firmware package type is an INTEGER, and the meaning of the integer value is specific to each hardware module. For example, a hardware module could assign different integer values for a bootstrap loader, a separation kernel, and an application.
如果硬件模块支持多种类型的固件软件包，则固件软件包签名者应包括固件软件包信息属性和填充的fwPkgType字段，以标识固件软件包类型。此值有助于引导加载程序在硬件模块中正确放置固件包。固件包类型为整数，整数值的含义特定于每个硬件模块。例如，硬件模块可以为引导加载程序、分离内核和应用程序分配不同的整数值。
Some hardware module architectures permit one firmware package to use routines provided by another. If the firmware package contains a dependency on another, then the firmware package signer SHOULD also include the firmware-package-info attribute with a populated dependencies field. If the firmware package does not depend on any other firmware packages, then the firmware package signer MUST NOT include the firmware-package-info attribute with a populated dependencies field.
一些硬件模块架构允许一个固件包使用另一个固件包提供的例程。如果固件包包含对另一个的依赖项，则固件包签名者还应包括固件包信息属性和填充的依赖项字段。如果固件软件包不依赖于任何其他固件软件包，则固件软件包签名者不得将固件软件包信息属性包含在已填充的依赖项字段中。
Firmware package dependencies are identified by the firmware package identifier or by information contained in the firmware package itself, and in either case the bootstrap loader ensures that the dependencies are met. The bootstrap loader MUST reject a firmware package load if it identifies a dependency on a firmware package that is not already loaded. Also, the bootstrap loader MUST reject a firmware package load if the action will result in a configuration where the dependencies of an already loaded firmware package will no longer be satisfied. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. When the legacy firmware package name form is used, the dependency is indicated by a legacy firmware package name. We assume that the firmware package signer and the bootstrap loader can determine whether a given legacy firmware package name represents the named version of an acceptable newer version. When the preferred firmware package name form is used, an object identifier and an integer are provided. The object identifier MUST exactly match the object identifier portion of a preferred firmware package name associated with a firmware package that is already loaded, and the integer MUST be less than or equal to the integer portion of the preferred firmware package name associated with the same firmware package. That is, the dependency specifies the minimum value of the version that is acceptable.
固件包依赖项由固件包标识符或固件包本身中包含的信息标识，在这两种情况下，引导加载程序都确保满足依赖项。如果引导加载程序识别出对尚未加载的固件包的依赖，则必须拒绝固件包加载。此外，如果操作将导致配置不再满足已加载固件包的依赖关系，则引导加载程序必须拒绝固件包加载。如第2.2.3节所述，支持两种命名固件包的方法：传统和首选。使用传统固件包名称表单时，依赖项由传统固件包名称指示。我们假设固件包签名者和引导加载程序可以确定给定的旧固件包名称是否表示可接受的较新版本的命名版本。使用首选固件包名称形式时，将提供对象标识符和整数。对象标识符必须与已加载固件包关联的首选固件包名称的对象标识符部分完全匹配，且整数必须小于或等于与同一固件包关联的首选固件包名称的整数部分。也就是说，依赖项指定可接受的版本的最小值。
The following object identifier identifies the firmware-package-info attribute:
以下对象标识符标识固件包信息属性：
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
The firmware-package-info attribute values have ASN.1 type FirmwarePackageInfo:
固件包信息属性值具有ASN.1类型FirmwarePackageInfo:
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
The firmware package signer SHOULD include a firmware-package-message-digest attribute, which provides the message digest algorithm and the message digest value computed on the firmware package. The message digest is computed on the firmware package prior to any compression, encryption, or signature processing. The bootstrap loader MAY use this message digest to confirm that the intended firmware package has been recovered after all of the layers of encapsulation are removed.
固件包签名者应包括固件包消息摘要属性，该属性提供消息摘要算法和固件包上计算的消息摘要值。在进行任何压缩、加密或签名处理之前，在固件包上计算消息摘要。引导加载程序可使用此消息摘要确认在移除所有封装层后已恢复预期固件包。
The following object identifier identifies the firmware-package-message-digest attribute:
以下对象标识符标识固件包消息摘要属性：
id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 41 }
id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 41 }
The firmware-package-message-digest attribute values have ASN.1 type FirmwarePackageMessageDigest:
固件包消息摘要属性值具有ASN.1类型FirmwarePackageMessageDigest：
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
msgDigest OCTET STRING }
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
msgDigest OCTET STRING }
The firmware package signer SHOULD include a signing-time attribute, specifying the time at which the signature was applied to the firmware package. Section 11.3 of [CMS] defines the signing-time attribute.
固件包签名者应包括签名时间属性，指定将签名应用于固件包的时间。[CMS]第11.3节定义了签名时间属性。
The firmware package signer SHOULD include a content-hints attribute, including a brief text description of the firmware package. The text is encoded in UTF-8, which supports most of the world's writing systems [UTF-8]. Section 2.9 of [ESS] defines the content-hints attribute.
固件包签名者应包括内容提示属性，包括固件包的简短文本说明。文本以UTF-8编码，它支持世界上大多数的书写系统[UTF-8]。[ESS]的第2.9节定义了内容提示属性。
When multiple layers of encapsulation are employed, the content-hints attribute is included in the outermost SignedData to provide information about the innermost content. In this case, the content-hints attribute provides a brief text description of the firmware package, which can help a person select the correct firmware package when more than one is available.
当采用多层封装时，最外层的SignedData中包含content Hits属性，以提供有关最内层内容的信息。在这种情况下，“内容提示”属性提供固件软件包的简短文本说明，当有多个固件软件包可用时，可帮助用户选择正确的固件软件包。
When the preferred firmware package name forms are used, the content-hints attribute can provide a linkage to a legacy firmware package name. This is especially helpful when an existing configuration management system is in use, but the features associated with the preferred firmware package name are deemed useful. A firmware package name associated with such a configuration management system might look something like "R1234.C0(AJ11).D62.A02.11(b)." Including these firmware package names in the text description may be helpful to developers by providing a clear linkage between the two name forms.
使用首选固件包名称表单时，“内容提示”属性可以提供到旧固件包名称的链接。这在使用现有配置管理系统时特别有用，但与首选固件包名称相关的功能被认为是有用的。与此类配置管理系统相关联的固件包名称可能类似于“R1234.C0（AJ11）.D62.A02.11（b）”。将这些固件包名称包含在文本描述中可能有助于开发人员在两个名称表单之间提供清晰的链接。
The content-hints attribute contains two fields, and in this case, both fields MUST be present. The fields of ContentHints are used as follows:
“内容提示”属性包含两个字段，在本例中，两个字段都必须存在。ContentHits的字段使用如下：
contentDescription provides a brief text description of the firmware package.
contentDescription提供固件包的简要文本说明。
contentType provides the content type of the inner most content type, and in this case, it MUST be id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).
contentType提供最内部内容类型的内容类型，在本例中，它必须是id ct firmwarePackage（1.2.840.113549.1.9.16.1.16）。
When the firmware-signer's public key is contained in a certificate, the firmware package signer SHOULD include a signing-certificate attribute to identify the certificate that was employed. However, if the firmware package signature does not have a certificate (meaning that the signature will only be validated with the trust anchor public key), then the firmware package signer is unable to include a signing-certificate attribute. Section 5.4 of [ESS] defines this attribute.
当固件签名者的公钥包含在证书中时，固件包签名者应包括签名证书属性，以标识所使用的证书。但是，如果固件包签名没有证书（意味着签名将仅使用信任锚公钥进行验证），则固件包签名者无法包含签名证书属性。[ESS]第5.4节定义了该属性。
The signing-certificate attribute contains two fields: certs and policies. The certs field MUST be present, and the policies field MAY be present. The fields of SigningCertificate are used as follows:
签名证书属性包含两个字段：证书和策略。证书字段必须存在，策略字段可能存在。签名证书的字段使用如下：
certs contains a sequence of certificate identifiers. In this case, sequence of certificate identifiers contains a single entry. The certs field MUST contain only the certificate identifier of the certificate that contains the public key used to verify the firmware package signature. The certs field uses the ESSCertID syntax specified in Section 5.4 of [ESS], and it is comprised of the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate and, optionally, the certificate issuer and the certificate serial number. The SHA-1 hash value MUST be present. The certificate issuer and the certificate serial number SHOULD be present.
证书包含一系列证书标识符。在这种情况下，证书标识符序列包含一个条目。certs字段必须仅包含包含用于验证固件包签名的公钥的证书的证书标识符。certs字段使用[ESS]第5.4节中指定的ESSCertID语法，它由整个ASN.1 DER编码证书的SHA-1哈希[SHA1]以及证书颁发者和证书序列号（可选）组成。SHA-1哈希值必须存在。应提供证书颁发者和证书序列号。
policies is optional; when it is present, it contains a sequence of policy information. The policies field, when present, MUST contain only one entry, and that entry MUST match one of the certificate policies in the certificate policies extension of the certificate that contains the public key used to verify the firmware package signature. The policies field uses the PolicyInformation syntax specified in Section 4.2.1.5 of [PROFILE], and it is comprised of the certificate policy object identifier and, optionally, certificate policy qualifiers. The certificate policy object identifier MUST be present. The certificate policy qualifiers SHOULD NOT be present.
政策是可选的；当它存在时，它包含一系列策略信息。“策略”字段（如果存在）必须仅包含一个条目，并且该条目必须与证书的证书策略扩展中的一个证书策略相匹配，该证书包含用于验证固件包签名的公钥。策略字段使用[PROFILE]第4.2.1.5节中指定的PolicyInformation语法，它由证书策略对象标识符和证书策略限定符（可选）组成。证书策略对象标识符必须存在。证书策略限定符不应存在。
CMS allows a SET of unsigned attributes to be included; however, in this specification, the set MUST be absent or include a single instance of the wrapped-firmware-decryption-key attribute. Because the digital signature does not cover this attribute, it can be altered at any point in the delivery path from the firmware package signer to the hardware module. This property can be employed to distribute the firmware-decryption key along with an encrypted and signed firmware package, allowing the firmware-decryption key to be wrapped with a different key-encryption key for each link in the distribution chain.
CMS允许包含一组未签名的属性；但是，在本规范中，集合必须不存在或包含包装固件解密密钥属性的单个实例。由于数字签名不包含此属性，因此可以在从固件包签名者到硬件模块的传递路径中的任何点对其进行更改。此属性可用于分发固件解密密钥以及加密和签名的固件包，从而允许使用不同的密钥加密密钥为分发链中的每个链路包装固件解密密钥。
The syntax for attributes is defined in [CMS], and it is repeated at the beginning of Section 2.2 of this document for convenience. Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
[CMS]中定义了属性的语法，为了方便起见，在本文件第2.2节开头重复了该语法。此配置文件使用的每个属性都有一个属性值，即使语法定义为一组AttributeValue。必须仅存在一个AttributeValue实例。
The UnsignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The UnsignedAttributes MUST include only one instance of any particular attribute.
signerInfo中的UnsignedAttributes语法定义为一组属性。unsignedAttribute只能包含任何特定属性的一个实例。
The firmware package signer, or any other party in the distribution chain, MAY include a wrapped-firmware-decryption-key attribute.
固件包签名者或分发链中的任何其他方可以包括包装的固件解密密钥属性。
The following object identifier identifies the wrapped-firmware-decryption-key attribute:
以下对象标识符标识包装的固件解密密钥属性：
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
The wrapped-firmware-decryption-key attribute values have ASN.1 type of EnvelopedData. Section 6 of [CMS] defines the EnvelopedData content type, which is used to construct the value of the attribute. EnvelopedData permits the firmware-decryption key to be protected using symmetric or asymmetric techniques. The EnvelopedData does not include an encrypted content; rather, the EnvelopedData feature of having the encrypted content in another location is employed. The encrypted content is found in the eContent field of the EncryptedData structure. The firmware-decryption key is contained in the recipientInfos field. Section 6 of [CMS] refers to this key as the content-encryption key.
包装的固件解密密钥属性值具有ASN.1类型的EnvelopedData。[CMS]的第6节定义了用于构造属性值的EnvelopedData内容类型。EnvelopedData允许使用对称或非对称技术保护固件解密密钥。信封数据不包括加密内容；相反，采用了在另一个位置具有加密内容的信封数据特性。加密内容位于EncryptedData结构的eContent字段中。固件解密密钥包含在recipientInfos字段中。[CMS]第6节将此密钥称为内容加密密钥。
The EnvelopedData syntax supports many different key management algorithms. Four general techniques are supported: key transport, key agreement, symmetric key-encryption keys, and passwords.
EnvelopedData语法支持许多不同的密钥管理算法。支持四种通用技术：密钥传输、密钥协商、对称密钥加密密钥和密码。
The EnvelopedData content type is profiled for the wrapped-firmware-decryption-key attribute. The EnvelopedData fields are described fully in Section 6 of [CMS]. Additional rules apply when EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
已为包装的固件解密密钥属性分析EnvelopedData内容类型。[CMS]第6节对包络数据字段进行了详细描述。当EnvelopedData用作包装固件解密密钥属性时，将应用其他规则。
Within the EnvelopedData structure, the following apply:
在EnvelopedData结构中，以下内容适用：
- The set of certificates included in OriginatorInfo MUST NOT include certificates with a type of extendedCertificate, v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE]. The optional crls field MAY be present.
- OriginatorInfo中包含的一组证书不得包含具有extendedCertificate、v1AttrCert或v2AttrCert[X.509-97、X.509-00、ACPROFILE]类型的证书。可能存在可选的crls字段。
- The optional unprotectedAttrs field MUST NOT be present.
- 可选的unprotectedAttrs字段不得存在。
Within the EncryptedContentInfo structure, the following apply:
在EncryptedContentInfo结构中，以下内容适用：
- contentType MUST match the content type object identifier carried in the contentType field within the EncryptedContentInfo structure of EncryptedData as described in Section 2.1.3.1.
- contentType必须与第2.1.3.1节所述EncryptedData的EncryptedContentInfo结构中contentType字段中携带的内容类型对象标识符相匹配。
- contentEncryptionAlgorithm identifies the firmware-encryption algorithm, and any associated parameters, used to encrypt the firmware package carried in the encryptedContent field of the EncryptedContentInfo structure of EncryptedData. Therefore, it MUST exactly match the value of the EncryptedContentInfo structure of EncryptedData as described in Section 2.1.3.1.
- contentEncryptionAlgorithm标识固件加密算法和任何相关参数，用于加密EncryptedData的EncryptedContentInfo结构的encryptedContent字段中携带的固件包。因此，它必须与EncryptedData的EncryptedContentInfo结构的值完全匹配，如第2.1.3.1节所述。
- encryptedContent is optional, and in this case, it MUST NOT be present.
- encryptedContent是可选的，在这种情况下，它不能存在。
The Cryptographic Message Syntax (CMS) is used to indicate that a firmware package loaded successfully. Support for firmware package load receipts is OPTIONAL. However, those hardware modules that choose to generate such receipts MUST follow the conventions specified in this section. Because not all hardware modules will have private signature keys, the firmware package load receipt can be either signed or unsigned. Use of the signed firmware package load receipt is RECOMMENDED.
加密消息语法（CMS）用于指示固件包已成功加载。支持固件包加载收据是可选的。但是，选择生成此类收据的硬件模块必须遵循本节中指定的约定。由于并非所有硬件模块都具有私有签名密钥，因此固件包加载收据可以是已签名的，也可以是未签名的。建议使用已签名的固件包加载收据。
Hardware modules that support receipt generation MUST have a unique serial number. Hardware modules that support signed receipt generation MUST have a private signature key to sign the receipt and the corresponding signature validation certificate or its designator. The designator is the certificate issuer name and the certificate serial number, or it is the public key identifier. Memory-constrained hardware modules will generally store the public key identifier since it requires less storage.
支持收据生成的硬件模块必须具有唯一的序列号。支持签名收据生成的硬件模块必须具有用于签名收据的私有签名密钥以及相应的签名验证证书或其标识符。标识符是证书颁发者名称和证书序列号，或者是公钥标识符。内存受限的硬件模块通常会存储公钥标识符，因为它需要较少的存储空间。
The unsigned firmware package load receipt is encapsulated by ContentInfo. Alternatively, the signed firmware package load receipt is encapsulated by SignedData, which is in turn encapsulated by ContentInfo.
未签名的固件包加载回执由ContentInfo封装。或者，签名的固件包加载收据由SignedData封装，SignedData又由ContentInfo封装。
The firmware package load receipt is summarized as follows (see [CMS] for the full syntax):
固件包加载接收总结如下（完整语法见[CMS]：
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
content SignedData
-- OR --
FirmwarePackageLoadReceipt
}
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
content SignedData
-- OR --
FirmwarePackageLoadReceipt
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
eContent OCTET STRING -- Contains receipt
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
eContent OCTET STRING -- Contains receipt
}
FirmwarePackageLoadReceipt {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING, -- Optional
decryptKeyID OCTET STRING -- Optional
}
FirmwarePackageLoadReceipt {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING, -- Optional
decryptKeyID OCTET STRING -- Optional
}
This section specifies the conventions for using the CMS ContentInfo and SignedData content types for firmware package load receipts. It also defines the firmware package load receipt content type.
本节规定了固件包加载收据使用CMS ContentInfo和SignedData内容类型的约定。它还定义固件包加载接收内容类型。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMS要求最外层的封装是ContentInfo[CMS]。ContentInfo的字段使用如下：
contentType indicates the type of the associated content. If the firmware package load receipt is signed, then the encapsulated type MUST be SignedData, and the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field. If the receipt is not signed, then the encapsulated type MUST be FirmwarePackageLoadReceipt, and the id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object identifier MUST be present in this field.
contentType指示关联内容的类型。如果固件包加载收据已签名，则封装类型必须为SignedData，并且id SignedData（1.2.840.113549.1.7.2）对象标识符必须存在于该字段中。如果收据未签名，则封装类型必须为FirmwarePackageLoadReceipt，并且id ct firmwareLoadReceipt（1.2.840.113549.1.9.16.1.17）对象标识符必须存在于该字段中。
content holds the associated content. If the firmware package load receipt is signed, then this field MUST contain the SignedData. If the receipt is not signed, then this field MUST contain the FirmwarePackageLoadReceipt.
内容保存关联的内容。如果固件包加载收据已签名，则此字段必须包含签名数据。如果收据未签名，则此字段必须包含FirmwarePackageLoadReceipt。
The SignedData content type contains the firmware package load receipt and one digital signature. If the hardware module locally stores its certificate, then the certificate can be included as well. The fields of SignedData are used as follows:
SignedData内容类型包含固件包加载回执和一个数字签名。如果硬件模块本地存储其证书，那么也可以包括该证书。SignedData的字段使用如下：
version is the syntax version number, and in this case, it MUST be set to 3.
version是语法版本号，在本例中，它必须设置为3。
digestAlgorithms is a collection of message digest algorithm identifiers, and in this case, it MUST contain a single message digest algorithm identifier. The message digest algorithms employed by the hardware module MUST be present.
digestAlgorithms是消息摘要算法标识符的集合，在这种情况下，它必须包含单个消息摘要算法标识符。必须提供硬件模块使用的消息摘要算法。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 3.1.2.2.
encapContentInfo是已签名的内容，由内容类型标识符和内容本身组成。第3.1.2.2节将进一步讨论封装ContentInfo类型的使用。
certificates is an optional collection of certificates. If the hardware module locally stores its certificate, then the X.509 certificate of the hardware module SHOULD be included. If the
证书是证书的可选集合。如果硬件模块本地存储其证书，则应包括硬件模块的X.509证书。如果
hardware module does not, then the certificates field is omitted. PKCS#6 extended certificates [PKCS#6] and attribute certificates (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set of certificates.
硬件模块没有，则省略证书字段。PKCS#6扩展证书[PKCS#6]和属性证书（版本1或版本2）[X.509-97，X.509-00，ACPROFILE]不得包含在证书集中。
crls is an optional collection of certificate revocation lists (CRLs). CRLs MAY be included, but they will normally be omitted since hardware modules will not generally have access to the most recent CRL. Signed receipt recipients SHOULD be able to handle the presence of the optional crls field.
crls是证书吊销列表（CRL）的可选集合。可以包括CRL，但通常会忽略它们，因为硬件模块通常无法访问最新的CRL。签名收据收件人应能够处理可选crls字段的存在。
signerInfos is a collection of per-signer information, and in this case, the collection MUST contain exactly one SignerInfo. The use of the SignerInfo type is discussed further in Section 3.1.2.1.
signerInfos是每个签名者信息的集合，在这种情况下，集合必须仅包含一个signerInfos。第3.1.2.1节将进一步讨论SignerInfo类型的使用。
The hardware module is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
硬件模块以SignerInfo类型表示。SignerInfo的字段使用如下：
version is the syntax version number, and it MUST be either 1 or 3, depending on the method used to identify the hardware module's public key. The use of the subjectKeyIdentifier is RECOMMENDED, which results in the use of version 3.
version是语法版本号，它必须为1或3，具体取决于用于标识硬件模块公钥的方法。建议使用subjectKeyIdentifier，从而使用版本3。
sid specifies the hardware module's certificate (and thereby the hardware module's public key). CMS supports two alternatives: issuerAndSerialNumber and subjectKeyIdentifier. The hardware module MUST support one or both of the alternatives for receipt generation; however, the support of subjectKeyIdentifier is RECOMMENDED. The issuerAndSerialNumber alternative identifies the hardware module's certificate by the issuer's distinguished name and the certificate serial number. The identified certificate, in turn, contains the hardware module's public key. The subjectKeyIdentifier alternative identifies the hardware module's public key directly. When this public key is contained in a certificate, this identifier SHOULD appear in the X.509 subjectKeyIdentifier extension.
sid指定硬件模块的证书（从而指定硬件模块的公钥）。CMS支持两种选择：issuerAndSerialNumber和subjectKeyIdentifier。硬件模块必须支持收据生成的一个或两个备选方案；但是，建议支持subjectKeyIdentifier。issuerAndSerialNumber替代方案通过颁发者的可分辨名称和证书序列号标识硬件模块的证书。标识的证书依次包含硬件模块的公钥。subjectKeyIdentifier选项直接标识硬件模块的公钥。当此公钥包含在证书中时，此标识符应出现在X.509 subjectKeyIdentifier扩展中。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the hardware module. It MUST contain the message digest algorithms employed to sign the receipt. (Note that this message digest algorithm identifier MUST be the same as the one carried in the digestAlgorithms value in SignedData.)
digestAlgorithm标识硬件模块使用的消息摘要算法和任何相关参数。它必须包含用于签署收据的消息摘要算法。（请注意，此消息摘要算法标识符必须与SignedData中digestAlgorithms值中携带的标识符相同。）
signedAttrs is an optional collection of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED for use with the firmware package load receipt content. The SET OF attributes MUST be DER encoded [X.509-88]. Section 3.2 of this document lists the attributes that MUST be included in the collection. Other attributes MAY be included, but the recipient will ignore any unrecognized signed attributes.
signedAttrs是随内容一起签名的属性的可选集合。SignedAttr在CMS中是可选的，但在本规范中，SignedAttr需要与固件包加载接收内容一起使用。属性集必须进行DER编码[X.509-88]。本文档第3.2节列出了集合中必须包含的属性。可以包括其他属性，但收件人将忽略任何未识别的签名属性。
signatureAlgorithm identifies the signature algorithm, and any associated parameters, used to sign the receipt.
signatureAlgorithm标识用于签署收据的签名算法和任何相关参数。
signature is the digital signature.
签名就是数字签名。
unsignedAttrs is an optional collection of attributes that are not signed, and in this case, there MUST NOT be any unsigned attributes present.
unsignedAttrs是未签名属性的可选集合，在本例中，不能存在任何未签名属性。
The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
FirmwarePackageLoadReceive封装在八位字节字符串中，它包含在封装的ContentInfo类型中。封装的ContentInfo字段的使用方式如下：
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
eContentType是唯一指定内容类型的对象标识符，在本例中，它必须是id ct FirmwareLodAccept（1.2.840.113549.1.9.16.1.17）的值。
eContent is the firmware package load receipt, encapsulated in an OCTET STRING. The eContent octet string need not be DER encoded.
eContent是固件包加载收据，封装在八位字节字符串中。eContent八位字节字符串不需要进行DER编码。
The following object identifier identifies the firmware package load receipt content type:
以下对象标识符标识固件包加载接收内容类型：
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
The firmware package load receipt content type has the ASN.1 type FirmwarePackageLoadReceipt:
固件包加载回执内容类型为ASN.1类型FirmwarePackageLoadReceive：
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
FWReceiptVersion ::= INTEGER { v1(1) }
The fields of the FirmwarePackageLoadReceipt type have the following meanings:
FirmwarePackageLoadReceipt类型的字段具有以下含义：
version is an integer that provides the syntax version number for compatibility with future revisions of this specification. Implementations that conform to this specification MUST set the version to the default value, which is v1.
version是一个整数，它提供语法版本号，以便与本规范的未来版本兼容。符合此规范的实现必须将版本设置为默认值，即v1。
hwType is an object identifier that identifies the type of hardware module on which the firmware package was loaded.
hwType是一个对象标识符，用于标识加载固件包的硬件模块的类型。
hwSerialNum is the serial number of the hardware module on which the firmware package was loaded. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNum是加载固件包的硬件模块的序列号。序列号无特殊结构；它不必是整数。但是，hwType和hwSerialNum的组合唯一标识硬件模块。
fwPkgName identifies the firmware package that was loaded. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgName标识已加载的固件包。如第2.2.3节所述，支持两种命名固件包的方法：传统和首选。旧固件包名称是八位字节字符串。首选固件包名称是固件包对象标识符和整数版本号的组合。
trustAnchorKeyID is optional, and when it is present, it identifies the trust anchor that was used to validate the firmware package signature.
TrustAnchorkeId是可选的，当它存在时，它标识用于验证固件包签名的信任锚点。
decryptKeyID is optional, and when it is present, it identifies the firmware-decryption key that was used to decrypt the firmware package.
decryptKeyID是可选的，当它存在时，它标识用于解密固件包的固件解密密钥。
The firmware package load receipt MUST include the version, hwType, hwSerialNum, and fwPkgName fields, and it SHOULD include the trustAnchorKeyID field. The firmware package load receipt MUST NOT
固件包加载回执必须包括版本、hwType、hwSerialNum和fwPkgName字段，并且应包括trustAnchorKeyID字段。固件包加载回执不能为空
include the decryptKeyID, unless the firmware package associated with the receipt is encrypted, the firmware-decryption key is available to the hardware module, and the firmware package was successfully decrypted.
包括decryptKeyID，除非与收据关联的固件包已加密，否则固件解密密钥可用于硬件模块，并且固件包已成功解密。
The hardware module MUST digitally sign a collection of attributes along with the firmware package load receipt. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], and it was repeated in Section 2.2 for convenience.
硬件模块必须对属性集合以及固件包加载收据进行数字签名。集合中的每个属性都必须进行DER编码[X.509-88]。[CMS]中定义了属性的语法，为了方便起见，在第2.2节中重复了该语法。
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
此配置文件使用的每个属性都有一个属性值，即使语法定义为一组AttributeValue。必须仅存在一个AttributeValue实例。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attributes. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo中的SignedAttribute语法定义为一组属性。SignedAttribute只能包含任何特定属性的一个实例。
The hardware module MUST include the content-type and message-digest attributes. If the hardware module includes a real-time clock, then the hardware module SHOULD also include the signing-time attribute. The hardware module MAY include any other attribute that it deems appropriate.
硬件模块必须包括内容类型和消息摘要属性。如果硬件模块包括实时时钟，则硬件模块还应包括签名时间属性。硬件模块可包括其认为适当的任何其他属性。
The hardware module MUST include a content-type attribute with the value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17). Section 11.1 of [CMS] defines the content-type attribute.
硬件模块必须包括id为ct firmwareLodAccept（1.2.840.113549.1.9.16.1.17）的内容类型属性。[CMS]第11.1节定义了内容类型属性。
The hardware module MUST include a message-digest attribute, having as its value the message digest of the FirmwarePackageLoadReceipt content. Section 11.2 of [CMS] defines the message-digest attribute.
硬件模块必须包含消息摘要属性，其值为FirmwarePackageLoadReceipt内容的消息摘要。[CMS]第11.2节定义了消息摘要属性。
If the hardware module includes a real-time clock, then the hardware module SHOULD include a signing-time attribute, specifying the time at which the receipt was generated. Section 11.3 of [CMS] defines the signing-time attribute.
如果硬件模块包括实时时钟，则硬件模块应包括签名时间属性，指定生成收据的时间。[CMS]第11.3节定义了签名时间属性。
The Cryptographic Message Syntax (CMS) is used to indicate that an error has occurred while attempting to load a protected firmware package. Support for firmware package load error reports is OPTIONAL. However, those hardware modules that choose to generate such error reports MUST follow the conventions specified in this section. Not all hardware modules have private signature keys; therefore the firmware package load error report can be either signed or unsigned. Use of the signed firmware package error report is RECOMMENDED.
加密消息语法（CMS）用于指示尝试加载受保护固件包时发生错误。支持固件包加载错误报告是可选的。但是，选择生成此类错误报告的硬件模块必须遵循本节中指定的约定。并非所有硬件模块都有私有签名密钥；因此，固件包加载错误报告可以是有符号的，也可以是无符号的。建议使用签名固件包错误报告。
Hardware modules that support error report generation MUST have a unique serial number. Hardware modules that support signed error report generation MUST also have a private signature key to sign the error report and the corresponding signature validation certificate or its designator. The designator is the certificate issuer name and the certificate serial number, or it is the public key identifier. Memory-constrained hardware modules will generally store the public key identifier since it requires less storage.
支持错误报告生成的硬件模块必须具有唯一的序列号。支持生成签名错误报告的硬件模块还必须具有用于签名错误报告的私有签名密钥以及相应的签名验证证书或其标识符。标识符是证书颁发者名称和证书序列号，或者是公钥标识符。内存受限的硬件模块通常会存储公钥标识符，因为它需要较少的存储空间。
The unsigned firmware package load error report is encapsulated by ContentInfo. Alternatively, the signed firmware package load error report is encapsulated by SignedData, which is in turn encapsulated by ContentInfo.
未签名固件包加载错误报告由ContentInfo封装。或者，签名固件包加载错误报告由SignedData封装，SignedData又由ContentInfo封装。
The firmware package load error report is summarized as follows (see [CMS] for the full syntax):
固件包加载错误报告总结如下（完整语法见[CMS]：
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
content SignedData
-- OR --
FirmwarePackageLoadError
}
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
content SignedData
-- OR --
FirmwarePackageLoadError
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
eContent OCTET STRING -- Contains error report
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
eContent OCTET STRING -- Contains error report
}
FirmwarePackageLoadError {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
errorCode FirmwarePackageLoadErrorCode -- Error identifier
vendorErrorCode VendorErrorCode, -- Optional
fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
config SEQUENCE OF CurrentFWConfig, -- Optional
}
FirmwarePackageLoadError {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
errorCode FirmwarePackageLoadErrorCode -- Error identifier
vendorErrorCode VendorErrorCode, -- Optional
fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
config SEQUENCE OF CurrentFWConfig, -- Optional
}
CurrentFWConfig { -- Repeated for each package in configuration fwPkgType INTEGER, -- Firmware package type; Optional fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig{--在配置fwPkgType INTEGER中对每个包重复，--固件包类型；可选的fwPkgName PreferredorleGacPackageIdentifier}
This section specifies the conventions for using the CMS ContentInfo and SignedData content types for firmware package load error reports. It also defines the firmware package load error content type.
本节指定在固件包加载错误报告中使用CMS ContentInfo和SignedData内容类型的约定。它还定义固件包加载错误内容类型。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMS要求最外层的封装是ContentInfo[CMS]。ContentInfo的字段使用如下：
contentType indicates the type of the associated content. If the firmware package load error report is signed, then the encapsulated type MUST be SignedData, and the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field. If the report is not signed, then the encapsulated type
contentType指示关联内容的类型。如果固件包加载错误报告已签名，则封装类型必须为SignedData，并且id SignedData（1.2.840.113549.1.7.2）对象标识符必须存在于该字段中。如果报告未签名，则封装的类型
MUST be FirmwarePackageLoadError, and the id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18) object identifier MUST be present in this field.
必须是FirmwarePackageLoadError，并且id ct firmwareLoadError（1.2.840.113549.1.9.16.1.18）对象标识符必须存在于该字段中。
content holds the associated content. If the firmware package load error report is signed, then this field MUST contain the SignedData. If the report is not signed, then this field MUST contain the FirmwarePackageLoadError.
内容保存关联的内容。如果固件包加载错误报告已签名，则此字段必须包含签名数据。如果报告未签名，则此字段必须包含FirmwarePackageLoadError。
The SignedData content type contains the firmware package load error report and one digital signature. If the hardware module locally stores its certificate, then the certificate can be included as well. The fields of SignedData are used exactly as described in Section 3.1.2.
SignedData内容类型包含固件包加载错误报告和一个数字签名。如果硬件模块本地存储其证书，那么也可以包括该证书。SignedData字段的使用与第3.1.2节所述完全一致。
The hardware module is represented in the SignerInfo type. The fields of SignerInfo are used exactly as described in Section 3.1.2.1.
硬件模块以SignerInfo类型表示。SignerInfo字段的使用与第3.1.2.1节所述完全相同。
The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
FirmwarePackageLoadError封装在一个八位字节字符串中，并在封装的ContentInfo类型中携带。封装的ContentInfo字段的使用方式如下：
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18).
eContentType是唯一指定内容类型的对象标识符，在本例中，它必须是id ct firmwareLoadError（1.2.840.113549.1.9.16.1.18）的值。
eContent is the firmware package load error report, encapsulated in an OCTET STRING. The eContent octet string need not be DER encoded.
eContent是固件包加载错误报告，封装在八位字节字符串中。eContent八位字节字符串不需要进行DER编码。
The following object identifier identifies the firmware package load error report content type:
以下对象标识符标识固件包加载错误报告内容类型：
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
The firmware package load error report content type has the ASN.1 type FirmwarePackageLoadError:
固件包加载错误报告内容类型具有ASN.1类型FirmwarePackageLoadError：
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30), missingDependency (31), wrongDependencyVersion (32), insufficientMemory (33), badFirmware (34), unsupportedParameters (35), breaksDependency (36), otherError (99) }
不支持的包类型（30）、缺少依赖项（31）、错误依赖项版本（32）、内存不足（33）、固件错误（34）、不支持的参数（35）、中断依赖项（36）、其他错误（99）}
VendorLoadErrorCode ::= INTEGER
VendorLoadErrorCode ::= INTEGER
The fields of the FirmwarePackageLoadError type have the following meanings:
FirmwarePackageLoadError类型的字段具有以下含义：
version is an integer, and it provides the syntax version number for compatibility with future revisions of this specification. Implementations that conform to this specification MUST set the version to the default value, which is v1.
version是一个整数，它提供语法版本号，以便与本规范的未来版本兼容。符合此规范的实现必须将版本设置为默认值，即v1。
hwType is an object identifier that identifies the type of hardware module on which the firmware package load was attempted.
hwType是一个对象标识符，用于标识尝试加载固件包的硬件模块的类型。
hwSerialNum is the serial number of the hardware module on which the firmware package load was attempted. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNum是尝试加载固件包的硬件模块的序列号。序列号无特殊结构；它不必是整数。但是，hwType和hwSerialNum的组合唯一标识硬件模块。
errorCode identifies the error that occurred.
errorCode标识发生的错误。
vendorErrorCode is optional; however, it MUST be present if the errorCode contains a value of otherError. When errorCode contains a value other than otherError, the vendorErrorCode can provide vendor-specific supplemental information.
vendorErrorCode是可选的；但是，如果errorCode包含值otherError，则必须存在该错误。当errorCode包含除otherError以外的值时，vendorErrorCode可以提供特定于供应商的补充信息。
fwPkgName is optional. When it is present, it identifies the firmware package that was being loaded when the error occurred. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgName是可选的。当它存在时，它会标识发生错误时正在加载的固件包。如第2.2.3节所述，支持两种命名固件包的方法：传统和首选。旧固件包名称是八位字节字符串。首选固件包名称是固件包对象标识符和整数版本号的组合。
config identifies the current firmware configuration. The field is OPTIONAL, but support for this field is RECOMMENDED for hardware modules that permit the loading of more than one firmware package. One instance of CurrentFWConfig is used to provide information about each firmware package in hardware module.
配置标识当前固件配置。该字段是可选的，但建议允许加载多个固件包的硬件模块支持该字段。CurrentFWConfig的一个实例用于提供有关硬件模块中每个固件包的信息。
The fields of the CurrentFWConfig type have the following meanings:
CurrentFWConfig类型的字段具有以下含义：
fwPkgType identifies the firmware package type. The firmware package type is an INTEGER, and the meaning of the integer value is specific to each hardware module.
fwPkgType标识固件包类型。固件包类型为整数，整数值的含义特定于每个硬件模块。
fwPkgName identifies the firmware package. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgName标识固件包。如第2.2.3节所述，支持两种命名固件包的方法：传统和首选。旧固件包名称是八位字节字符串。首选固件包名称是固件包对象标识符和整数版本号的组合。
The errorCode values have the following meanings:
errorCode值具有以下含义：
decodeFailure: The ASN.1 decode of the firmware package load failed. The provided input did not conform to BER, or it was not ASN.1 at all.
解码失败：固件包加载的ASN.1解码失败。提供的输入不符合BER，或者根本不是ASN.1。
badContentInfo: Invalid ContentInfo syntax, or the contentType carried within the ContentInfo is unknown or unsupported.
badContentInfo:无效的ContentInfo语法，或者ContentInfo中包含的contentType未知或不受支持。
badSignedData: Invalid SignedData syntax, the version is unknown or unsupported, or more than one entry is present in digestAlgorithms.
badSignedData:无效的SignedData语法，版本未知或不受支持，或者digestAlgorithms中存在多个条目。
badEncapContent: Invalid EncapsulatedContentInfo syntax, or the contentType carried within the eContentType is unknown or unsupported. This error can be generated due to problems located in SignedData or CompressedData.
badEncapContent:无效的封装ContentInfo语法，或者eContentType中携带的contentType未知或不受支持。由于SignedData或CompressedData中存在的问题，可能会生成此错误。
badCertificate: Invalid syntax for one or more certificates in CertificateSet.
badCertificate:CertificateSet中的一个或多个证书的语法无效。
badSignerInfo: Invalid SignerInfo syntax, or the version is unknown or unsupported.
badSignerInfo:无效的SignerInfo语法，或者版本未知或不受支持。
badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
badSignedAttrs:SignerInfo中的signedAttrs语法无效。
badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an attribute other than the wrapped-firmware-decryption-key attribute, which is the only unsigned attribute supported by this specification.
badUnsignedAttrs:SignerInfo中的unsignedAttrs包含包装固件解密密钥属性以外的属性，包装固件解密密钥属性是此规范支持的唯一未签名属性。
missingContent: The optional eContent is missing in EncapsulatedContentInfo, which is required in this specification. This error can be generated due to problems located in SignedData or CompressedData.
missingContent:封装的ContentInfo中缺少可选的eContent，这在本规范中是必需的。由于SignedData或CompressedData中存在的问题，可能会生成此错误。
noTrustAnchor: Two situations can lead to this error. In one case, the subjectKeyIdentifier does not identify the public key of a trust anchor or a certification path that terminates with an installed trust anchor. In the other case, the issuerAndSerialNumber does not identify the public key of a trust anchor or a certification path that terminates with an installed trust anchor.
noTrustAnchor：有两种情况会导致此错误。在一种情况下，subjectKeyIdentifier不标识以安装的信任锚点终止的信任锚点或证书路径的公钥。在另一种情况下，issuerAndSerialNumber不标识以已安装的信任锚点终止的信任锚点或证书路径的公钥。
notAuthorized: The sid within SignerInfo leads to an installed trust anchor, but that trust anchor is not an authorized firmware package signer.
notAuthorized:SignerInfo中的sid指向已安装的信任锚点，但该信任锚点不是经授权的固件包签名者。
badDigestAlgorithm: The digestAlgorithm in either SignerInfo or SignedData is unknown or unsupported.
badDigestAlgorithm:SignerInfo或SignedData中的digestAlgorithm未知或不受支持。
badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is unknown or unsupported.
badSignatureAlgorithm:SignerInfo中的signatureAlgorithm未知或不受支持。
unsupportedKeySize: The signatureAlgorithm in SignerInfo is known and supported, but the firmware package signature could not be validated because an unsupported key size was employed by the signer.
unsupportedKeySize:SignerInfo中的signatureAlgorithm已知并受支持，但无法验证固件包签名，因为签名者使用了不受支持的密钥大小。
signatureFailure: The signatureAlgorithm in SignerInfo is known and supported, but the signature in signature in SignerInfo could not be validated.
signatureFailure:SignerInfo中的signatureAlgorithm已知并受支持，但无法验证SignerInfo中signature中的签名。
contentTypeMismatch: The contentType carried within the eContentType does not match the content type carried in the signed attribute.
contentTypeMismatch:eContentType中包含的contentType与签名属性中包含的内容类型不匹配。
badEncryptedData: Invalid EncryptedData syntax; the version is unknown or unsupported.
badEncryptedData:EncryptedData语法无效；版本未知或不受支持。
unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs, which are not permitted in this specification.
unprotectedAttrsPresent:EncryptedData包含未受保护的TTR，这在本规范中是不允许的。
badEncryptContent: Invalid EncryptedContentInfo syntax, or the contentType carried within the contentType is unknown or unsupported.
badEncryptContent:EncryptedContentInfo语法无效，或者contentType中包含的contentType未知或不受支持。
badEncryptAlgorithm: The firmware-encryption algorithm identified by contentEncryptionAlgorithm in EncryptedContentInfo is unknown or unsupported.
badEncryptAlgorithm:EncryptedContentInfo中contentEncryptionAlgorithm标识的固件加密算法未知或不受支持。
missingCiphertext: The optional encryptedContent is missing in EncryptedContentInfo, which is required in this specification.
missingCiphertext:EncryptedContentInfo中缺少可选encryptedContent，这是本规范所要求的。
noDecryptKey: The hardware module does not have the firmware-decryption key named in the decrypt key identifier signed attribute.
noDecryptKey:硬件模块没有解密密钥标识符签名属性中指定的固件解密密钥。
decryptFailure: The firmware package did not decrypt properly.
解密失败：固件包未正确解密。
badCompressAlgorithm: The compression algorithm identified by compressionAlgorithm in CompressedData is unknown or unsupported.
badCompressAlgorithm：CompressedData中compressionAlgorithm标识的压缩算法未知或不受支持。
missingCompressedContent: The optional eContent is missing in EncapsulatedContentInfo, which is required in this specification.
missingCompressedContent:此规范中要求的封装内容信息中缺少可选的eContent。
decompressFailure: The firmware package did not decompress properly.
解压缩失败：固件包未正确解压缩。
wrongHardware: The processing hardware module is not listed in the target hardware module identifiers signed attribute.
错误硬件：处理硬件模块未在目标硬件模块标识符签名属性中列出。
stalePackage: The firmware package is rejected because it is stale.
stalePackage: The firmware package is rejected because it is stale.translate error, please retry
notInCommunity: The hardware module is not a member of the community described in the community identifiers signed attribute.
notInCommunity：硬件模块不是community identifiers signed属性中描述的社区的成员。
unsupportedPackageType: The firmware package type identified in the firmware package information signed attribute is not supported by the combination of the hardware module and the bootstrap loader.
unsupportedPackageType：硬件模块和引导加载程序的组合不支持固件包信息签名属性中标识的固件包类型。
missingDependency: The firmware package being loaded depends on routines that are part of another firmware package, but that firmware package is not available.
missingDependency：正在加载的固件包取决于属于另一个固件包的例程，但该固件包不可用。
wrongDependencyVersion: The firmware package being loaded depends on routines that are part of the another firmware package, and the available version of that package has an older version number than is required. The available firmware package does not fulfill the dependencies.
ErrorDependencyVersion：正在加载的固件包取决于属于另一个固件包的例程，并且该包的可用版本的版本号比所需版本号旧。可用固件包不满足依赖关系。
insufficientMemory: The firmware package could not be loaded because the hardware module did not have sufficient memory.
内存不足：无法加载固件包，因为硬件模块内存不足。
badFirmware: The signature on the firmware package was validated, but the firmware package itself was not in an acceptable format. The details will be specific to each hardware module. For example, a hardware module that is composed of multiple firmware-programmable components could not find the internal tagging within the firmware package to distribute executable code to each of the components.
坏固件：固件包上的签名已验证，但固件包本身的格式不可接受。详细信息将针对每个硬件模块。例如，由多个固件可编程组件组成的硬件模块在固件包中找不到内部标记，无法将可执行代码分发到每个组件。
unsupportedParameters: The signature on the firmware package could not be validated because the signer used signature algorithm parameters that are not supported by the hardware module signature verification routines.
不支持参数：无法验证固件包上的签名，因为签名者使用了硬件模块签名验证例程不支持的签名算法参数。
breaksDependency: Another firmware package has a dependency that can no longer be satisfied if the firmware package being loaded is accepted.
breaksDependency：如果正在加载的固件包被接受，则无法再满足另一个固件包的依赖关系。
otherError: An error occurred that does not fit any of the previous error codes.
otherError：发生的错误不符合以前的任何错误代码。
The hardware module MUST digitally sign a collection of attributes along with the firmware package load error report. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], and it was repeated in Section 2.2 for convenience.
硬件模块必须对属性集合以及固件包加载错误报告进行数字签名。集合中的每个属性都必须进行DER编码[X.509-88]。[CMS]中定义了属性的语法，为了方便起见，在第2.2节中重复了该语法。
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
此配置文件使用的每个属性都有一个属性值，即使语法定义为一组AttributeValue。必须仅存在一个AttributeValue实例。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attributes. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo中的SignedAttribute语法定义为一组属性。SignedAttribute只能包含任何特定属性的一个实例。
The hardware module MUST include the content-type and message-digest attributes. If the hardware module includes a real-time clock, then the hardware module SHOULD also include the signing-time attribute. The hardware module MAY include any other attribute that it deems appropriate.
硬件模块必须包括内容类型和消息摘要属性。如果硬件模块包括实时时钟，则硬件模块还应包括签名时间属性。硬件模块可包括其认为适当的任何其他属性。
The hardware module MUST include a content-type attribute with the value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18). Section 11.1 of [CMS] defines the content-type attribute.
硬件模块必须包括id为ct FirmwareLoader（1.2.840.113549.1.9.16.1.18）的内容类型属性。[CMS]第11.1节定义了内容类型属性。
The hardware module MUST include a message-digest attribute, having as its value the message digest of the FirmwarePackageLoadError content. Section 11.2 of [CMS] defines the message-digest attribute.
硬件模块必须包含消息摘要属性，其值为FirmwarePackageLoadError内容的消息摘要。[CMS]第11.2节定义了消息摘要属性。
If the hardware module includes a real-time clock, then hardware module SHOULD include a signing-time attribute, specifying the time at which the firmware package load error report was generated. Section 11.3 of [CMS] defines the signing-time attribute.
如果硬件模块包括实时时钟，则硬件模块应包括签名时间属性，指定生成固件包加载错误报告的时间。[CMS]第11.3节定义了签名时间属性。
Support for firmware package load receipts, as discussed in Section 3, is OPTIONAL, and support for the firmware package load error reports, as discussed in Section 4, is OPTIONAL. Hardware modules that support receipt or error report generation MUST have unique serial numbers. Further, hardware modules that support signed receipt or error report generation MUST have private signature keys and corresponding signature validation certificates [PROFILE] or their designators. The conventions for hardware module naming in the signature validation certificates are specified in this section.
支持固件包加载接收（如第3节所述）是可选的，支持固件包加载错误报告（如第4节所述）是可选的。支持接收或错误报告生成的硬件模块必须具有唯一的序列号。此外，支持签名收据或错误报告生成的硬件模块必须具有私有签名密钥和相应的签名验证证书[PROFILE]或其标识符。本节规定了签名验证证书中硬件模块命名的约定。
The hardware module vendor or a trusted third party MUST issue the signature validation certificate prior to deployment of the hardware module. The certificate is likely to be issued at the time of manufacture. The subject alternative name in this certificate identifies the hardware module. The subject distinguished name is empty, but a critical subject alternative name extension contains the hardware module name, using the otherName choice within the GeneralName structure.
硬件模块供应商或受信任的第三方必须在部署硬件模块之前颁发签名验证证书。证书可能在制造时签发。此证书中的使用者替代名称标识硬件模块。主题可分辨名称为空，但关键主题备选名称扩展名包含硬件模块名称，使用GeneralName结构中的otherName选项。
The hardware module name form is identified by the id-on-hardwareModuleName object identifier:
硬件模块名称表单由hardwareModuleName对象标识符上的id标识：
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
A HardwareModuleName is composed of an object identifier and an octet string:
HardwareModuleName由对象标识符和八位字节字符串组成：
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The fields of the HardwareModuleName type have the following meanings:
HardwareModuleName类型的字段具有以下含义：
hwType is an object identifier that identifies the type of hardware module. A unique object identifier names a hardware model and revision.
hwType是标识硬件模块类型的对象标识符。唯一的对象标识符命名硬件型号和版本。
hwSerialNum is the serial number of the hardware module. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNum是硬件模块的序列号。序列号无特殊结构；它不必是整数。但是，hwType和hwSerialNum的组合唯一标识硬件模块。
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages; therefore, the security considerations discussed in [CMS] apply to this specification as well.
本文件描述了使用加密消息语法（CMS）保护固件包；因此，[CMS]中讨论的安全注意事项也适用于本规范。
The conventions specified in this document raise a few security considerations of their own.
本文件中规定的公约本身也提出了一些安全方面的考虑。
Private signature keys must be protected. Compromise of the private key used to sign firmware packages permits unauthorized parties to generate firmware packages that are acceptable to hardware modules. Compromise of the hardware module private key allows unauthorized parties to generate signed firmware package load receipts and error reports.
必须保护私有签名密钥。用于签署固件包的私钥泄露允许未经授权方生成硬件模块可接受的固件包。硬件模块私钥泄露允许未经授权的各方生成已签名的固件包加载收据和错误报告。
The firmware-decryption key must be protected. Compromise of the key may result in the disclosure of the firmware package to unauthorized parties.
固件解密密钥必须受到保护。密钥泄露可能导致固件包泄露给未经授权方。
Cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. The ability to change the firmware package provides an opportunity to update or replace cryptographic algorithms. Although this capability is desirable, cryptographic algorithm replacement can lead to interoperability failures. Therefore, the rollout of new cryptographic algorithms must be managed. Generally, the previous generation of cryptographic algorithms and their replacements need to be supported at the same time in order to facilitate an orderly transition.
随着时间的推移，加密算法变得越来越弱。随着新密码分析技术的发展和计算性能的提高，破坏特定密码算法的工作因素将减少。更改固件包的能力提供了更新或替换加密算法的机会。尽管这种能力是可取的，但替换加密算法可能会导致互操作性失败。因此，必须管理新加密算法的推出。通常，需要同时支持上一代加密算法及其替代算法，以促进有序过渡。
When firmware packages are encrypted, the source of the firmware package must randomly generate firmware-encryption keys. Also, the generation of public/private signature key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG
加密固件包时，固件包的源必须随机生成固件加密密钥。此外，公共/私有签名密钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现复制PRNG要容易得多
environment that produced the keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
生成密钥的环境，搜索生成的一小部分可能性，而不是暴力搜索整个密钥空间。生成高质量的随机数是困难的。RFC 4086[随机]在这方面提供了重要的指导。
The firmware signer determines whether a stale version number is included. The policy of the firmware signer needs to consider many factors. Consider the flaw found by Ian Goldberg and David Wagner in the random number generator of the Netscape browser in 1996 [DDJ]. This flaw completely undermines confidentiality protection. A firmware signer might use the stale version number to ensure that upgraded hardware modules do not resume use of the flawed firmware. However, another firmware signer may not consider this an appropriate situation to employ the stale version number, preferring to delegate this decision to someone closer to the operation of the hardware module. Such a person is likely to be in a better position to evaluate whether other bugs introduced in the newer firmware package impose worse operational concerns than the confidentiality concern caused by the flawed random number generator. For example, a user who never uses the encryption feature of the flawed Netscape browser will determine the most appropriate version to use without considering the random number flaw or its fix.
固件签名者确定是否包含过时的版本号。固件签名者的策略需要考虑很多因素。考虑Ian Goldberg和大卫瓦戈尔在Netscape浏览器的随机数生成器中发现的缺陷[DDJ]。此漏洞完全破坏了机密性保护。固件签名者可能会使用过时的版本号，以确保升级的硬件模块不会恢复使用有缺陷的固件。然而，另一个固件签名者可能不认为这是使用陈旧版本号的适当情况，更倾向于将此决定委托给更接近硬件模块操作的人。这样的人很可能能够更好地评估新固件包中引入的其他bug是否比有缺陷的随机数生成器引起的机密性问题带来更严重的操作问题。例如，从不使用有缺陷的Netscape浏览器的加密功能的用户将在不考虑随机数缺陷或其修复的情况下确定最合适的版本。
The stale version number is especially useful when the security interests of the person choosing which firmware package version to load into a particular hardware module do not align with the security interests of the firmware package signer. For example, stale version numbers may be useful in hardware modules that provide digital rights management (DRM). Also, stale version numbers will be useful when the deployment organization (as opposed to the firmware package vendor) is the firmware signer. Further, stale version numbers will be useful for firmware packages that need to be trusted to implement organizational (as opposed to the deployment organization) security policy, regardless of whether the firmware signer is the deployment organization or the vendor. For example, hardware devices employed by the military will probably make use of stale version numbers.
当选择加载到特定硬件模块的固件包版本的人员的安全利益与固件包签名者的安全利益不一致时，过时版本号特别有用。例如，过时的版本号在提供数字版权管理（DRM）的硬件模块中可能很有用。此外，当部署组织（与固件包供应商相反）是固件签名者时，过时的版本号也很有用。此外，过时的版本号对于需要信任以实施组织（而不是部署组织）安全策略的固件包非常有用，无论固件签名者是部署组织还是供应商。例如，军方使用的硬件设备可能会使用过时的版本号。
The use of a stale version number in a firmware package that employs the preferred firmware package name form cannot completely prevent subsequent use of the stale firmware package. Despite this shortcoming, the feature is included since it is useful in some important situations. By loading different types of firmware packages, each with its own stale firmware package version number until the internal storage for the stale version number is exceeded, the user can circumvent the mechanism. Consider a hardware module
在采用首选固件包名称形式的固件包中使用陈旧版本号不能完全阻止后续使用陈旧固件包。尽管存在这一缺点，但由于该功能在某些重要情况下非常有用，因此将其包括在内。通过加载不同类型的固件包，每个固件包都有自己的陈旧固件包版本号，直到超出陈旧版本号的内部存储空间，用户可以绕过该机制。考虑硬件模块
that has storage for two stale version numbers. Suppose that FWPKG-A version 3 is loaded, indicating that FWPKG-A version 2 is stale. The user can sequentially load the following:
它有两个过时版本号的存储空间。假设加载了FWPKG-A版本3，表示FWPKG-A版本2已过时。用户可以按顺序加载以下内容：
- FWPKG-B version 8, indicating that FWPKG-B version 4 is stale. (Note: The internal storage indicates that FWPKG-A version 2 and FWPKG-B version 4 are stale.)
- FWPKG-B版本8，表示FWPKG-B版本4已过时。（注意：内部存储器表明FWPKG-A版本2和FWPKG-B版本4已过时。）
- FWPKG-C version 5, indicating that FWPKG-C version 3 is stale. (Note: The internal storage indicates that FWPKG-B version 4 and FWPKG-C version 3 are stale.)
- FWPKG-C版本5，表示FWPKG-C版本3已过时。（注意：内部存储器表明FWPKG-B版本4和FWPKG-C版本3已过时。）
- FWPKG-A version 2.
- FWPKG-A版本2。
Because many hardware modules are expected to have very few firmware packages written for them, the stale firmware package version feature provides important protections. The amount of non-volatile storage that needs to be dedicated to saving firmware package identifiers and version numbers depends on the number of firmware packages that are likely to be developed for the hardware module.
由于许多硬件模块预期为其编写的固件包很少，因此陈旧固件包版本功能提供了重要的保护。需要专用于保存固件包标识符和版本号的非易失性存储器的数量取决于可能为硬件模块开发的固件包的数量。
The use of legacy firmware package name form does not improve this situation. In fact, the legacy firmware package names are usually larger than an object identifier. Thus, comparable stale version protection requires more memory.
使用旧固件包名称表单并不能改善这种情况。事实上，传统固件包名称通常大于对象标识符。因此，类似的过时版本保护需要更多内存。
A firmware signer can ensure that stale version numbers are honored by limiting the number of different types of firmware packages that are signed. If all of the hardware modules are able to store a stale version number for each of the different types of firmware package, then the hardware module will be able to provide the desired protection. This requires the firmware signer to have a deep understanding of all of the hardware modules that might accept the firmware package.
固件签名者可以通过限制已签名的不同类型固件包的数量来确保遵守过时的版本号。如果所有硬件模块都能够为每种不同类型的固件包存储过时的版本号，则硬件模块将能够提供所需的保护。这要求固件签名者对可能接受固件包的所有硬件模块有深入的了解。
When a firmware package includes a community identifier, the confidence that the package is only used by the intended community depends on the mechanism used to configure community membership. This document does not specify a mechanism for the assignment of community membership to hardware modules, and the various alternatives have different security properties. Also, the authority that makes community identifier assignments to hardware modules might be different than the authority that generates firmware packages.
当固件包包含社区标识符时，该包仅由预期社区使用的可信度取决于用于配置社区成员资格的机制。本文档未指定将社区成员资格分配给硬件模块的机制，并且各种备选方案具有不同的安全属性。此外，向硬件模块分配社区标识符的权限可能不同于生成固件包的权限。
[COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[COMPRESS]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[简介]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 32802002年4月。
[SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
[SHA1]国家标准与技术研究所。FIPS Pub 180-1：安全哈希标准。1995年4月17日。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88]CCITT。建议X.209：抽象语法符号1（ASN.1）的基本编码规则规范。1988
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88]CCITT。建议X.509：目录认证框架。1988
[ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ACPROFILE]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]国家标准与技术研究所。FIPS Pub 197：高级加密标准（AES）。2001年11月26日。
[DDJ] Goldberg, I. and D. Wagner. "Randomness and the Netscape Browser." Dr. Dobb's Journal, January 1996.
[DDJ]戈德伯格，I.和D.瓦格纳。“随机性与网景浏览器”，《多布博士期刊》，1996年1月。
[DPD&DPV] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002.
[DPD&DPV]Pinkas，D.和R.Housley，“委托路径验证和委托路径发现协议要求”，RFC 3379，2002年9月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.
[PKCS#6]RSA实验室。PKCS#6：扩展证书语法标准，版本1.5。1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[SECREQMTS] National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001.
[SECREQMTS]国家标准与技术研究所。FIPS Pub 140-2：加密模块的安全要求。2001年5月25日。
[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 1997.
[X.509-97]ITU-T.建议X.509：目录认证框架。1997
[X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000.
[X.509-00]ITU-T.建议X.509：目录认证框架。2000
Appendix A: ASN.1 Module
附录A:ASN.1模块
The ASN.1 module contained in this appendix defines the structures that are needed to implement the CMS-based firmware package wrapper. It is expected to be used in conjunction with the ASN.1 modules in [CMS], [COMPRESS], and [PROFILE].
本附录中包含的ASN.1模块定义了实现基于CMS的固件包包装所需的结构。它预计将与[CMS]、[COMPRESS]和[PROFILE]中的ASN.1模块一起使用。
CMSFirmwareWrapper
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
CMSFirmwareWrapper
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
EnvelopedData
FROM CryptographicMessageSyntax -- [CMS]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
IMPORTS
EnvelopedData
FROM CryptographicMessageSyntax -- [CMS]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
-- Firmware Package Content Type and Object Identifier
--固件包内容类型和对象标识符
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
FirmwarePkgData ::= OCTET STRING
FirmwarePkgData ::= OCTET STRING
-- Firmware Package Signed Attributes and Object Identifiers
--固件包签名属性和对象标识符
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
DecryptKeyIdentifier ::= OCTET STRING
DecryptKeyIdentifier ::= OCTET STRING
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
-- Firmware Package Unsigned Attributes and Object Identifiers
--固件包未签名属性和对象标识符
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
WrappedFirmwareKey ::= EnvelopedData
WrappedFirmwareKey ::= EnvelopedData
-- Firmware Package Load Receipt Content Type and Object Identifier
--固件包加载接收内容类型和对象标识符
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
FWReceiptVersion ::= INTEGER { v1(1) }
-- Firmware Package Load Error Report Content Type
-- and Object Identifier
-- Firmware Package Load Error Report Content Type
-- and Object Identifier
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26), wrongHardware (27), stalePackage (28), notInCommunity (29), unsupportedPackageType (30), missingDependency (31), wrongDependencyVersion (32), insufficientMemory (33), badFirmware (34), unsupportedParameters (35), breaksDependency (36), otherError (99) }
解压缩失败（26）、错误的硬件（27）、陈旧的软件包（28）、非独立通信（29）、不受支持的软件包类型（30）、丢失依赖项（31）、错误依赖项版本（32）、内存不足（33）、坏固件（34）、不受支持的参数（35）、中断依赖项（36）、其他错误（99）}
VendorLoadErrorCode ::= INTEGER
VendorLoadErrorCode ::= INTEGER
-- Other Name syntax for Hardware Module Name
--硬件模块名称的其他名称语法
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
END
终止
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。