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:
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.
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.
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
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.
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
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.
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.
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 } }
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.
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.
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.
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