doc: Add RFC documents

1 files changed, 3419 insertions, 0 deletions

diff --git a/doc/rfc/rfc4108.txt b/doc/rfc/rfc4108.txt
new file mode 100644
index 0000000..8119548
--- /dev/null
+++ b/doc/rfc/rfc4108.txt
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+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
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+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
+
+
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+           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
+
+1.  Introduction
+
+   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.
+
+   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
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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.
+
+   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.
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+1.1.  Terminology
+
+   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].
+
+1.2.  Architectural Elements
+
+   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
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   ASN.1 object identifiers are the preferred means of naming the
+   architectural elements.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+            +------------------------------------------------------+
+            |  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.2.1.  Hardware Module Requirements
+
+   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
+
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   it for authorization decisions (see Section 2.2.8), receipt
+   generation (see Section 3), and error report generation (see
+   Section 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.2.  Firmware Package Requirements
+
+   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.
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+1.2.3.  Bootstrap Loader Requirements
+
+   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.
+
+   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
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+1.2.3.1.  Legacy Stale Version Processing
+
+   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
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+1.2.3.2.  Preferred Stale Version Processing
+
+   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.
+
+1.2.4.  Trust Anchors
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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.
+
+1.2.5.  Cryptographic and Compression Algorithm Requirements
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+1.3.  Hardware Module Security Architecture
+
+   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.
+
+   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.
+
+1.4.  ASN.1 Encoding
+
+   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
+
+
+
+Housley                     Standards Track                    [Page 14]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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.
+
+1.5.  Protected Firmware Package Loading
+
+   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.  Firmware Package Protection
+
+   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
+
+
+
+Housley                     Standards Track                    [Page 15]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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).
+
+   The firmware package protection is summarized as follows (see [CMS]
+   for the full syntax):
+
+      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
+      }
+
+      SignerInfo {
+        version              CMSVersion, -- always set to 3
+        sid                  SignerIdentifier,
+        digestAlgorithm      DigestAlgorithmIdentifier,
+        signedAttrs          SignedAttributes, -- Required
+        signatureAlgorithm   SignatureAlgorithmIdentifier,
+        signature            SignatureValue,
+        unsignedAttrs        UnsignedAttributes -- Optional
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 16]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      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
+      }
+
+      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
+      }
+
+      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
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 17]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.  Firmware Package Protection CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo,
+   SignedData, EncryptedData, and CompressedData content types.  It also
+   defines the FirmwarePkgData content type.
+
+2.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+      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.
+
+      content holds the associated content, and in this case, the
+         content field MUST contain SignedData.
+
+2.1.2.  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:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 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.
+
+   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.
+
+   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
+
+
+
+
+Housley                     Standards Track                    [Page 18]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      [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.
+
+   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.
+
+   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.
+
+2.1.2.1.  SignerInfo
+
+   The firmware package signer is represented in the SignerInfo type.
+   The fields of SignerInfo are used as follows:
+
+   version is the syntax version number, and it MUST be 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.
+
+   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.)
+
+   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
+
+
+
+
+
+Housley                     Standards Track                    [Page 19]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      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.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used by the firmware package signer to
+      generate the digital signature.
+
+   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.
+
+2.1.2.2.  EncapsulatedContentInfo
+
+   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:
+
+   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.
+
+   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.
+
+2.1.3.  EncryptedData
+
+   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:
+
+
+
+
+Housley                     Standards Track                    [Page 20]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   version is the syntax version number, and in this case, version MUST
+      be 0.
+
+   encryptedContentInfo is the encrypted content information.  The use
+      of the EncryptedContentInfo type is discussed further in Section
+      2.1.3.1.
+
+   unprotectedAttrs is an optional collection of unencrypted attributes,
+      and in this case, unprotectedAttrs MUST NOT be present.
+
+2.1.3.1.  EncryptedContentInfo
+
+   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:
+
+   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.
+
+   contentEncryptionAlgorithm identifies the firmware-encryption
+      algorithm, and any associated parameters, used to encrypt the
+      firmware package.
+
+   encryptedContent is the result of encrypting the firmware package.
+      The field is optional; however, in this case, it MUST be present.
+
+2.1.4.  CompressedData
+
+   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:
+
+   version is the syntax version number; in this case, it MUST be 0.
+
+   compressionAlgorithm identifies the compression algorithm, and any
+      associated parameters, used to compress the firmware package.
+
+   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.
+
+
+
+
+Housley                     Standards Track                    [Page 21]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.4.1.  EncapsulatedContentInfo
+
+   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:
+
+   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).
+
+   eContent is the compressed firmware package, encoded as an octet
+      string.  The eContent octet string need not be DER encoded.
+
+2.1.5.  FirmwarePkgData
+
+   The FirmwarePkgData content type contains the firmware package.  It
+   is a straightforward encapsulation in an octet string, and it need
+   not be DER encoded.
+
+   The FirmwarePkgData content type is identified by the id-ct-
+   firmwarePackage 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 }
+
+   The FirmwarePkgData content type is a simple octet string:
+
+      FirmwarePkgData ::= OCTET STRING
+
+2.2.  Signed Attributes
+
+   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:
+
+      Attribute ::= SEQUENCE {
+        attrType OBJECT IDENTIFIER,
+        attrValues SET OF AttributeValue }
+
+      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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 22]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attribute.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   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.
+
+2.2.1.  Content Type
+
+   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
+
+
+
+
+Housley                     Standards Track                    [Page 23]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   id-ct-firmwarePackage, the firmware package was not compressed or
+   encrypted prior to signing.  Section 11.1 of [CMS] defines the
+   content-type attribute.
+
+2.2.2.  Message Digest
+
+   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.
+
+2.2.3.  Firmware Package Identifier
+
+   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.
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 24]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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 }
+
+   The firmware-package-identifier attribute values have ASN.1 type
+   FirmwarePackageIdentifier:
+
+      FirmwarePackageIdentifier ::= SEQUENCE {
+        name PreferredOrLegacyPackageIdentifier,
+        stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+      PreferredOrLegacyPackageIdentifier ::= CHOICE {
+        preferred PreferredPackageIdentifier,
+        legacy OCTET STRING }
+
+      PreferredPackageIdentifier ::= SEQUENCE {
+        fwPkgID OBJECT IDENTIFIER,
+        verNum INTEGER (0..MAX) }
+
+      PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+        preferredStaleVerNum INTEGER (0..MAX),
+        legacyStaleVersion OCTET STRING }
+
+2.2.4.  Target Hardware Module Identifiers
+
+   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 }
+
+   The target-hardware-module-identifiers attribute values have ASN.1
+   type TargetHardwareIdentifiers:
+
+      TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+
+
+Housley                     Standards Track                    [Page 25]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.5.  Decrypt Key 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.
+
+   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 }
+
+   The decrypt-key-identifier attribute values have ASN.1 type
+   DecryptKeyIdentifier:
+
+      DecryptKeyIdentifier ::= OCTET STRING
+
+2.2.6.  Implemented Crypto Algorithms
+
+   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.
+
+   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.
+
+
+
+
+Housley                     Standards Track                    [Page 26]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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 }
+
+   The implemented-crypto-algorithms attribute values have ASN.1 type
+   ImplementedCryptoAlgorithms:
+
+      ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.7.  Implemented Compression Algorithms
+
+   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.
+
+   The object identifier portion of AlgorithmIdentifier identifies a
+   compression algorithm.  No algorithm parameters are included.
+
+   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 }
+
+   The implemented-compress-algorithms attribute values have ASN.1 type
+   ImplementedCompressAlgorithms:
+
+      ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.8.  Community Identifiers
+
+   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.
+
+
+
+Housley                     Standards Track                    [Page 27]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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 }
+
+   The community-identifiers attribute values have ASN.1 type
+   CommunityIdentifiers:
+
+      CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+      CommunityIdentifier ::= CHOICE {
+        communityOID OBJECT IDENTIFIER,
+        hwModuleList HardwareModules }
+
+      HardwareModules ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+      HardwareSerialEntry ::= CHOICE {
+        all NULL,
+        single OCTET STRING,
+        block SEQUENCE {
+          low OCTET STRING,
+          high OCTET STRING } }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 28]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.9.  Firmware Package Information
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 29]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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 }
+
+   The firmware-package-info attribute values have ASN.1 type
+   FirmwarePackageInfo:
+
+      FirmwarePackageInfo ::= SEQUENCE {
+        fwPkgType INTEGER OPTIONAL,
+        dependencies SEQUENCE OF
+          PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+2.2.10.  Firmware Package Message Digest
+
+   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 }
+
+   The firmware-package-message-digest attribute values have ASN.1 type
+   FirmwarePackageMessageDigest:
+
+      FirmwarePackageMessageDigest ::= SEQUENCE {
+        algorithm AlgorithmIdentifier,
+        msgDigest OCTET STRING }
+
+2.2.11.  Signing Time
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 30]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.12.  Content Hints
+
+   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.
+
+   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.
+
+   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.
+
+   The content-hints attribute contains two fields, and in this case,
+   both fields MUST be present.  The fields of ContentHints are used as
+   follows:
+
+   contentDescription provides a brief text description of the firmware
+      package.
+
+   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).
+
+2.2.13.  Signing Certificate
+
+   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.
+
+
+
+
+Housley                     Standards Track                    [Page 31]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   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.
+
+2.3.  Unsigned Attributes
+
+   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.
+
+   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.
+
+
+
+
+
+Housley                     Standards Track                    [Page 32]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The UnsignedAttributes syntax within signerInfo is defined as a SET
+   OF Attribute.  The UnsignedAttributes MUST include only one instance
+   of any particular attribute.
+
+2.3.1.  Wrapped Firmware Decryption Key
+
+   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 }
+
+   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.
+
+   The EnvelopedData syntax supports many different key management
+   algorithms.  Four general techniques are supported: key transport,
+   key agreement, symmetric key-encryption keys, and passwords.
+
+   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.
+
+   Within the EnvelopedData structure, the following apply:
+
+   -  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.
+
+   -  The optional unprotectedAttrs field MUST NOT be present.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 33]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Within the EncryptedContentInfo structure, the following apply:
+
+   -  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.
+
+   -  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.
+
+   -  encryptedContent is optional, and in this case, it MUST NOT be
+      present.
+
+3.  Firmware Package Load Receipt
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 34]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt is summarized as follows (see [CMS]
+   for the full syntax):
+
+   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
+   }
+
+   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
+   }
+
+   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
+   }
+
+
+
+
+
+Housley                     Standards Track                    [Page 35]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+3.1.  Firmware Package Load Receipt CMS Content Type Profile
+
+   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.
+
+3.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   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.
+
+   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.
+
+3.1.2.  SignedData
+
+   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:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 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.
+
+   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.
+
+   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
+
+
+
+Housley                     Standards Track                    [Page 36]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      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.
+
+   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.
+
+   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.
+
+3.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used as follows:
+
+   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.
+
+   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.
+
+   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.)
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 37]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used to sign the receipt.
+
+   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.
+
+3.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING,
+   and it is carried within the EncapsulatedContentInfo type.  The
+   fields of EncapsulatedContentInfo are used as follows:
+
+   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).
+
+   eContent is the firmware package load receipt, encapsulated in an
+      OCTET STRING.  The eContent octet string need not be DER encoded.
+
+3.1.3.  FirmwarePackageLoadReceipt
+
+   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 }
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 38]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt content type has the ASN.1 type
+   FirmwarePackageLoadReceipt:
+
+      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) }
+
+   The fields of the FirmwarePackageLoadReceipt type have the following
+   meanings:
+
+   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.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package was loaded.
+
+   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.
+
+   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.
+
+   trustAnchorKeyID is optional, and when it is present, it identifies
+      the trust anchor that was used to validate the firmware package
+      signature.
+
+   decryptKeyID is optional, and when it is present, it identifies the
+      firmware-decryption key that was used to decrypt the firmware
+      package.
+
+   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
+
+
+
+Housley                     Standards Track                    [Page 39]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+3.2.  Signed Attributes
+
+   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.
+
+   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.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   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.
+
+3.2.1.  Content Type
+
+   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.
+
+3.2.2.  Message Digest
+
+   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.
+
+3.2.3.  Signing Time
+
+   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.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 40]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.  Firmware Package Load Error
+
+   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.
+
+   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.
+
+   The firmware package load error report is summarized as follows (see
+   [CMS] for the full syntax):
+
+   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
+   }
+
+
+
+
+Housley                     Standards Track                    [Page 41]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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
+   }
+
+   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
+   }
+
+4.1.  Firmware Package Load Error CMS Content Type Profile
+
+   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.
+
+4.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   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
+
+
+
+
+Housley                     Standards Track                    [Page 42]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      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.
+
+   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.
+
+4.1.2.  SignedData
+
+   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.
+
+4.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used exactly as described in Section
+   3.1.2.1.
+
+4.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and
+   it is carried within the EncapsulatedContentInfo type.  The fields of
+   EncapsulatedContentInfo are used as follows:
+
+   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).
+
+   eContent is the firmware package load error report, encapsulated in
+      an OCTET STRING.  The eContent octet string need not be DER
+      encoded.
+
+4.1.3.  FirmwarePackageLoadError
+
+   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 }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 43]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load error report content type has the ASN.1
+   type 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 }
+
+      FWErrorVersion ::= INTEGER { v1(1) }
+
+      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),
+
+
+
+Housley                     Standards Track                    [Page 44]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+        unsupportedPackageType      (30),
+        missingDependency           (31),
+        wrongDependencyVersion      (32),
+        insufficientMemory          (33),
+        badFirmware                 (34),
+        unsupportedParameters       (35),
+        breaksDependency            (36),
+        otherError                  (99) }
+
+      VendorLoadErrorCode ::= INTEGER
+
+   The fields of the FirmwarePackageLoadError type have the following
+   meanings:
+
+   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.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package load was attempted.
+
+   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.
+
+   errorCode identifies the error that occurred.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+Housley                     Standards Track                    [Page 45]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The fields of the CurrentFWConfig type have the following meanings:
+
+   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.
+
+   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.
+
+   The errorCode values have the following meanings:
+
+   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.
+
+   badContentInfo: Invalid ContentInfo syntax, or the contentType
+      carried within the ContentInfo is unknown or unsupported.
+
+   badSignedData: Invalid SignedData syntax, the version is unknown or
+      unsupported, or more than one entry is present in
+      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.
+
+   badCertificate: Invalid syntax for one or more certificates in
+      CertificateSet.
+
+   badSignerInfo: Invalid SignerInfo syntax, or the version is unknown
+      or unsupported.
+
+   badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
+
+   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.
+
+   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.
+
+
+
+
+Housley                     Standards Track                    [Page 46]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   notAuthorized: The sid within SignerInfo leads to an installed trust
+      anchor, but that trust anchor is not an authorized firmware
+      package signer.
+
+   badDigestAlgorithm: The digestAlgorithm in either SignerInfo or
+      SignedData is unknown or unsupported.
+
+   badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is
+      unknown or unsupported.
+
+   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.
+
+   signatureFailure: The signatureAlgorithm in SignerInfo is known and
+      supported, but the signature in signature in SignerInfo could not
+      be validated.
+
+   contentTypeMismatch: The contentType carried within the eContentType
+      does not match the content type carried in the signed attribute.
+
+   badEncryptedData: Invalid EncryptedData syntax; the version is
+      unknown or unsupported.
+
+   unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs,
+      which are not permitted in this specification.
+
+   badEncryptContent: Invalid EncryptedContentInfo syntax, or the
+      contentType carried within the contentType is unknown or
+      unsupported.
+
+   badEncryptAlgorithm: The firmware-encryption algorithm identified by
+      contentEncryptionAlgorithm in EncryptedContentInfo is unknown or
+      unsupported.
+
+   missingCiphertext: The optional encryptedContent is missing in
+      EncryptedContentInfo, which is required in this specification.
+
+
+
+
+
+Housley                     Standards Track                    [Page 47]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   noDecryptKey: The hardware module does not have the firmware-
+      decryption key named in the decrypt key identifier signed
+      attribute.
+
+   decryptFailure: The firmware package did not decrypt properly.
+
+   badCompressAlgorithm: The compression algorithm identified by
+      compressionAlgorithm in CompressedData is unknown or unsupported.
+
+   missingCompressedContent: The optional eContent is missing in
+      EncapsulatedContentInfo, which is required in this specification.
+
+   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.
+
+   notInCommunity: The hardware module is not a member of the community
+      described in the community identifiers signed attribute.
+
+   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.
+
+   missingDependency: The firmware package being loaded depends on
+      routines that are part of another firmware package, but that
+      firmware package is not available.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 48]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+   otherError: An error occurred that does not fit any of the previous
+      error codes.
+
+4.2.  Signed Attributes
+
+   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.
+
+   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.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   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.
+
+4.2.1.  Content Type
+
+   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.
+
+4.2.2.  Message Digest
+
+   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.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 49]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.2.3.  Signing Time
+
+   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.
+
+5.  Hardware Module Name
+
+   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.
+
+   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.
+
+   The hardware module name form is identified by the id-on-
+   hardwareModuleName object identifier:
+
+      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 ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING }
+
+   The fields of the HardwareModuleName type have the following
+   meanings:
+
+   hwType is an object identifier that identifies the type of hardware
+      module.  A unique object identifier names a hardware model and
+      revision.
+
+
+
+Housley                     Standards Track                    [Page 50]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+6.  Security Considerations
+
+   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.
+
+   The conventions specified in this document raise a few security
+   considerations of their own.
+
+6.1.  Cryptographic Keys and Algorithms
+
+   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.
+
+6.2.  Random Number Generation
+
+   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
+
+
+
+Housley                     Standards Track                    [Page 51]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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.
+
+6.3.  Stale Firmware Package Version Number
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Housley                     Standards Track                    [Page 52]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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-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-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-A version 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.
+
+6.4.  Community Identifiers
+
+   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.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 53]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [COMPRESS]   Gutmann, P., "Compressed Data Content Type for
+                Cryptographic Message Syntax (CMS)", RFC 3274, June
+                2002.
+
+   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                3852, July 2004.
+
+   [ESS]        Hoffman, P., "Enhanced Security Services for S/MIME",
+                RFC 2634, June 1999.
+
+   [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.
+
+   [SHA1]       National Institute of Standards and Technology.  FIPS
+                Pub 180-1: Secure Hash Standard.  17 April 1995.
+
+   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [X.208-88]   CCITT.  Recommendation X.208: Specification of Abstract
+                Syntax Notation One (ASN.1).  1988.
+
+   [X.209-88]   CCITT.  Recommendation X.209: Specification of Basic
+                Encoding Rules for Abstract Syntax Notation One (ASN.1).
+                1988.
+
+   [X.509-88]   CCITT.  Recommendation X.509: The Directory -
+                Authentication Framework.  1988.
+
+7.2.  Informative References
+
+   [ACPROFILE]  Farrell, S. and R. Housley, "An Internet Attribute
+                Certificate Profile for Authorization", RFC 3281, April
+                2002.
+
+   [AES]        National Institute of Standards and Technology.  FIPS
+                Pub 197:  Advanced Encryption Standard (AES).  26
+                November 2001.
+
+
+
+
+Housley                     Standards Track                    [Page 54]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   [DDJ]        Goldberg, I. and D. Wagner.  "Randomness and the
+                Netscape Browser."  Dr. Dobb's Journal, January 1996.
+
+   [DPD&DPV]    Pinkas, D. and R. Housley, "Delegated Path Validation
+                and Delegated Path Discovery Protocol Requirements", RFC
+                3379, September 2002.
+
+   [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.
+
+   [PKCS#6]     RSA Laboratories.  PKCS #6: Extended-Certificate Syntax
+                Standard, Version 1.5.  November 1993.
+
+   [RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                "Randomness Requirements for Security", BCP 106, RFC
+                4086, June 2005.
+
+   [SECREQMTS]  National Institute of Standards and Technology.  FIPS
+                Pub 140-2: Security Requirements for Cryptographic
+                Modules.  25 May 2001.
+
+   [X.509-97]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  1997.
+
+   [X.509-00]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 55]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Appendix A: ASN.1 Module
+
+   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].
+
+
+   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
+
+   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 }
+
+   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 }
+
+   FirmwarePackageIdentifier ::= SEQUENCE {
+     name PreferredOrLegacyPackageIdentifier,
+     stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+   PreferredOrLegacyPackageIdentifier ::= CHOICE {
+     preferred PreferredPackageIdentifier,
+     legacy OCTET STRING }
+
+   PreferredPackageIdentifier ::= SEQUENCE {
+     fwPkgID OBJECT IDENTIFIER,
+     verNum INTEGER (0..MAX) }
+
+
+
+
+Housley                     Standards Track                    [Page 56]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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 }
+
+   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 }
+
+   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 }
+
+   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 }
+
+   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 }
+
+   CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+   CommunityIdentifier ::= CHOICE {
+     communityOID OBJECT IDENTIFIER,
+     hwModuleList HardwareModules }
+
+   HardwareModules ::= SEQUENCE {
+     hwType OBJECT IDENTIFIER,
+     hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 57]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   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 }
+
+   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 }
+
+   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 }
+
+   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) }
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 58]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   -- 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 }
+
+   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) }
+
+   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),
+
+
+
+Housley                     Standards Track                    [Page 59]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+     decompressFailure           (26),
+     wrongHardware               (27),
+     stalePackage                (28),
+     notInCommunity              (29),
+     unsupportedPackageType      (30),
+     missingDependency           (31),
+     wrongDependencyVersion      (32),
+     insufficientMemory          (33),
+     badFirmware                 (34),
+     unsupportedParameters       (35),
+     breaksDependency            (36),
+     otherError                  (99) }
+
+   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 }
+
+   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
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 60]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (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.
+
+   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.
+
+   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.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 61]
+