tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4108

 
 
 

Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages

Part 3 of 3, p. 41 to 61
Prev RFC Part

 


prevText      Top      Up      ToC       Page 41 
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
   }

Top      Up      ToC       Page 42 
   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

Top      Up      ToC       Page 43 
      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 }

Top      Up      ToC       Page 44 
   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),

Top      Up      ToC       Page 45 
        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.

Top      Up      ToC       Page 46 
   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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
   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.

Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
   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

Top      Up      ToC       Page 52 
   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

Top      Up      ToC       Page 53 
   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.

Top      Up      ToC       Page 54 
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.

Top      Up      ToC       Page 55 
   [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.

Top      Up      ToC       Page 56 
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) }

Top      Up      ToC       Page 57 
   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 }

Top      Up      ToC       Page 58 
   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) }

Top      Up      ToC       Page 59 
   -- 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),

Top      Up      ToC       Page 60 
     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

Top      Up      ToC       Page 61 
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.