[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4108

Network Working Group                                        R. Housley
Internet Draft                                           Vigil Security
expires in six months                                         July 2003


                 Using CMS to Protect Firmware Packages

                   <draft-housley-cms-fw-wrap-02.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document describes the use of the Cryptographic Message Syntax
   (CMS) to protect firmware packages.  A digital signature is used to
   protect the firmware package from undetected modification and provide
   data origin authentication.  Encryption is optionally used to protect
   the firmware from disclosure, and compression is optionally used to
   reduce the size of the protected firmware package.  A firmware
   package loading signed receipt can optionally be generated to
   acknowledge the successful loading of a firmware package.











Housley                                                         [Page 1]

INTERNET DRAFT                                                 July 2003


Table of Contents

   Status of this Memo ................................................  1
   Abstract ...........................................................  1
   Table of Contents ..................................................  2
   1   Introduction ...................................................  4
       1.1   Terminology ..............................................  5
       1.2   Architectural Elements ...................................  5
             1.2.1   Hardware Module Requirements .....................  7
             1.2.2   Firmware Package Requirements ....................  7
             1.2.3   Bootstrap Loader Requirements ....................  8
             1.2.4   Trust Anchors .................................... 10
             1.2.5   Cryptographic Algorithm Requirements ............. 11
       1.3   Hardware Module Security Architecture .................... 11
       1.4   ASN.1 Encoding ........................................... 12
   2   Firmware Package Protection .................................... 13
       2.1   Firmware Package Protection CMS Content Type Profile ..... 15
             2.1.1   ContentInfo ...................................... 15
             2.1.2   SignedData ....................................... 15
                     2.1.2.1   SignerInfo ............................. 16
                     2.1.2.2   EncapsulatedContentInfo ................ 17
             2.1.3   EncryptedData .................................... 17
                     2.1.3.1   EncryptedContentInfo ................... 18
             2.1.4   CompressedData ................................... 18
                     2.1.4.1   EncapsulatedContentInfo ................ 19
             2.1.5   FirmwarePkgData .................................. 19
       2.2   Signed Attributes ........................................ 19
             2.2.1   Content Type ..................................... 20
             2.2.2   Message Digest ................................... 21
             2.2.3   Firmware Package Identifier ...................... 21
             2.2.4   Target Hardware Module Identifiers ............... 21
             2.2.5   Decrypt Key Identifier ........................... 22
             2.2.6   Implemented Crypto Algorithms .................... 22
             2.2.7   Community Identifiers ............................ 23
             2.2.8   Firmware Package Information ..................... 24
             2.2.9   Firmware Package Message Digest .................. 25
             2.2.10  Signing Time ..................................... 26
             2.2.11  Content Hints .................................... 26
             2.2.12  Signing Certificate .............................. 26
       2.3   Unsigned Attributes ...................................... 27
             2.3.1   Wrapped Firmware-Decryption Key .................. 28










Housley                                                         [Page 2]

INTERNET DRAFT                                                 July 2003


   3   Firmware Package Load Receipt .................................. 29
       3.1   Firmware Package Load Receipt CMS Content Type Profile ... 30
             3.1.1   ContentInfo ...................................... 30
             3.1.2   SignedData ....................................... 30
                     3.1.2.1   SignerInfo ............................. 31
                     3.1.2.2   EncapsulatedContentInfo ................ 32
             3.1.3   FirmwarePackageLoadReceipt ....................... 32
       3.2   Signed Attributes ........................................ 33
             3.2.1   Content Type ..................................... 34
             3.2.2   Message Digest ................................... 34
             3.2.3   Signing Time ..................................... 34
   4   Hardware Module Name ........................................... 34
   5   References ..................................................... 35
       5.1   Normative References ..................................... 35
       5.2   Informative References ................................... 36
   6   Security Considerations ........................................ 37
   7   Author Address ................................................. 38
   Appendix A:  ASN.1 Module .......................................... 39
   Full Copyright Statement ........................................... 42
































Housley                                                         [Page 3]

INTERNET DRAFT                                                 July 2003


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 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 can be associated
   with any particular hardware module; however, this specification was
   written with the requirements of cryptographic hardware modules in
   mind, since such modules have strong security requirements.

   The firmware package contains object code for one or more processors
   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, and then encrypted, and
   then signed.  Compression simply reduces the size of the firmware
   package, allowing more efficient processing and transmission.
   Encryption protects the firmware 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 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.  This out-of-band
   key delivery is beyond the scope of this specification.  The key
   might be delivered via physical media or delivered via an independent
   electronic path.

   The signature verification public key must be made available to the
   module in a secure fashion.  CMS provides for 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



Housley                                                         [Page 4]

INTERNET DRAFT                                                 July 2003


   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 CRL repository, an OCSP
   responder [OCSP], or 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, 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.

   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 digitally signed
   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.  To generate digitally signed
   receipts, a hardware module is required to have a unique serial
   number, its own private signature key to sign the receipt, and a
   certificate that contains the corresponding signature validation
   public key.  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 firmware 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 firmware
   loading receipt is generated, the bootstrap loader uses the private



Housley                                                         [Page 5]

INTERNET DRAFT                                                 July 2003


   signature key to sign the receipt and includes the signature
   validation certificate to aid receipt validation.  To implement this
   optional capability, the hardware module MUST have a unique serial
   number, and the private signature key to sign the receipt and the
   certificate containing the corresponding signature validation public
   key 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 used to name the architectural elements.



         +------------------------------------------------------+
         |  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  |   |                          |   |
         |   +---------------+   +--------------------------+   |
         |                                                      |
         |        +------------------------------------+        |
         |        |  Private Signature Key and         |        |
         |        |  Signature Validation Certificate  |        |
         |        +------------------------------------+        |
         |                                                      |
         +------------------------------------------------------+

                        Figure 1.  Architectural Elements







Housley                                                         [Page 6]

INTERNET DRAFT                                                 July 2003


   Details of managing the trust anchors are outside 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 authorization to use the
   associated firmware package.  Generally, separate distribution
   mechanisms will be employed for the firmware-decryption key and the
   firmware package.

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 family of hardware modules SHOULD have
   a unique permanent serial number.  However, if the optional receipt
   generation capability is implemented, then the hardware module MUST
   have a unique permanent serial number, a private signature key, and a
   certificate containing the corresponding public signature validation
   key.  If a serial number is present, the bootstrap loader uses it for
   authorization decisions (see section 2.2.7) and receipt generation
   (see section 3).

   When the hardware module includes more than one processor, the
   bootstrap loader distributes components of the package to the
   appropriate processors 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

   Firmware packages are named by 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



Housley                                                         [Page 7]

INTERNET DRAFT                                                 July 2003


   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 which
   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.  In case
   a firmware package with a disastrous flaw is released, subsequent
   firmware package versions MAY designate a stale version number.

   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 this 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 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 processors, the firmware
   package MUST contain object code for all of the processors.  Internal
   tagging within the firmware package MUST tell the bootstrap loader
   which portion of the overall firmware package is intended for each
   processor; however, this tagging is expected to be specific to each
   hardware module.  Since 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 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.



Housley                                                         [Page 8]

INTERNET DRAFT                                                 July 2003


   If the bootstrap loader is can be loaded by a firmware package, an
   initial bootstrap loader MUST be installed in non-volatile memory
   prior to deployment.  The firmware package containing the bootstrap
   loader MAY also contain other routines.

   Regardless of how the bootstrap loader is implemented, the trust
   anchors MUST be installed in non-volatile memory prior to deployment.

   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.  Since 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 decompression function.  The decompression function
   can be implemented specifically for the bootstrap loader, or they 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.

   The bootstrap loader requires access to one or more trusted public
   keys, called trust anchors, to validate the firmware package digital
   signature.  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.

   The bootstrap loader MUST reject a firmware package if the list of
   supported hardware modules 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



Housley                                                         [Page 9]

INTERNET DRAFT                                                 July 2003


   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.  In case a
   firmware package with a disastrous flaw is released and subsequent
   firmware package versions designate a stale version number, the
   bootstrap loader SHOULD prevent loading of the stale version and
   versions earlier than the stale version.

1.2.4  Trust Anchors

   A trust anchor MUST consist of a public key signature algorithm and
   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 issuer name.

   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 identifier names the trust anchor, and it is used when
   the trust anchor is used directly to validate firmware package
   signatures.  This key identifier can be stored with the trust anchor,
   or if the recommended method of computing the key identifier is
   followed, it can be computed from the public key whenever needed.

   The key identifier is RECOMMENDED to be the 160-bit SHA-1 hash [SHA1]
   of the public key.  X.509 certificates encode public keys as a BIT
   STRING [PROFILE].  The public key is encoded in this format, and then
   the SHA-1 hash is computed on the BIT STRING value, excluding the
   tag, length, and number of unused bits.

   The trusted issuer name is used when the trust anchor public key is
   used to validate an X.509 certification path.






Housley                                                        [Page 10]

INTERNET DRAFT                                                 July 2003


1.2.5  Cryptographic Algorithm Requirements

   Firmware for cryptographic hardware modules includes cryptographic
   algorithm implementations.  However, firmware for non-cryptographic
   hardware modules will likely include cryptographic algorithm
   implementations to support the Bootstrap Loader in the validation
   firmware packages.

   A unique algorithm object identifier MUST be assigned for each
   algorithm and mode 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.

1.3  Hardware Module Security Architecture

   In most hardware module designs, the firmware execution environment
   offers a single address space.  When a single address space is
   offered, the firmware package MUST contain a complete firmware load
   for hardware module.  That is, the firmware package cannot be a
   partial or incremental set of functions.  This requirement is
   motivated by a desire to minimize complexity and avoid potential
   security problems.  From a complexity perspective, if the incremental
   loading of packages were permitted, it would be necessary for each
   package to identify any other packages that are required (its
   dependencies), and the bootstrap loader would have to verify that all
   of the dependencies were satisfied before attempting to execute the
   firmware.  Two security-relevant observations motivate this
   requirement.  First, if the hardware module were based on a general
   purpose processor or a digital signal processor, it would be
   dangerous to allow such packages to be loaded simultaneously unless
   there is a reference monitor to ensure that independent portions of
   the code cannot interfere with one another.  Second, it is difficult
   evaluate arbitrary combinations of software modules [SECREQMTS].

   Even when a single address space is offered by the execution
   environment, the hardware module MAY accommodate separate loading of



Housley                                                        [Page 11]

INTERNET DRAFT                                                 July 2003


   the bootstrap loader and the firmware package.  In this hardware
   module design, the bootstrap loader and the rest of the firmware are
   stored in separate portions of non-volatile memory.  The firmware
   package MAY depend on routines that are part of the bootstrap loader
   such as a memory manager, heap manager, one-way hash function, or
   digital signature processing.  To minimize the security evaluation
   complexity of this hardware module employing such a design, the
   firmware package MUST identify the package identifier and minimum
   version number of the bootstrap loader.  The bootstrap loader MUST
   reject a firmware package load if it contains a bootstrap loader
   identifier other than the one that is executing or the identified
   bootstrap loader version is greater than the one that is executing.

   A few hardware module architectures employ a separation kernel to
   provide more than one space for firmware execution.  In this
   architecture, the bootstrap loader is used to separately load the
   separation kernel and firmware packages.  The bootstrap loader MAY be
   permanently stored in read-only memory or separately loaded into non-
   volatile memory as discussed above.  The separation kernel and the
   other firmware packages are each stored in separate portions of non-
   volatile memory.  The firmware packages MAY have dependencies on
   routines provided by the separation kernel or the bootstrap loader.
   To minimize the security evaluation complexity of this hardware
   module employing such a design, the firmware package must identify
   the package identifiers and minimum version numbers of the separation
   kernel and bootstrap loader.  The bootstrap loader MUST reject a
   firmware package load if it contains a separation kernel identifier
   other than the one that is already loaded or the identified
   separation kernel version is greater than the one that is already
   loaded.  Likewise, the bootstrap loader MUST reject a firmware
   package load if it contains a bootstrap loader identifier other than
   the one that is executing or the identified bootstrap loader version
   is greater than the one that is executing.

1.4  ASN.1 Encoding

   The CMS makes use of 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 programming language used by the
   implementation.  Encoding rules describe how the values defined in
   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 use in a
   system.  As a result, the Distinguished Encoding Rules (DER)
   [X.509-88] were invented.  DER is a subset of BER which ensures a
   single way to represent a given value.  For example, DER always



Housley                                                        [Page 12]

INTERNET DRAFT                                                 July 2003


   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.

2  Firmware Package Protection

   The Cryptographic Message Syntax (CMS) is used to protect firmware,
   which is treated as an opaque binary object.  A digital signature is
   used to protect the firmware package from undetected modification and
   provide data origin authentication.  Encryption is optionally used to
   protect the firmware 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 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, either the CMS SignedData content type (when neither
   encryption nor compression is used) or the CMS EncryptedData content
   type (when encryption is used, but compression is not used) or 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 protection is summarized by:

      ContentInfo {
        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
        content              SignedData
      }

      SignedData {
        version              CMSVersion,
        digestAlgorithms     DigestAlgorithmIdentifiers,
        encapContentInfo     EncapsulatedContentInfo,
        certificates         CertificateSet, -- Signer certification path
        crls                 CertificateRevocationLists, -- Omit
        signerInfos          SET OF SignerInfo -- Only one
      }






Housley                                                        [Page 13]

INTERNET DRAFT                                                 July 2003


      SignerInfo {
        version              CMSVersion,
        sid                  SignerIdentifier,
        digestAlgorithm      DigestAlgorithmIdentifier,
        signedAttrs          SignedAttributes, -- Required
        signatureAlgorithm   SignatureAlgorithmIdentifier,
        signature            SignatureValue,
        unsignedAttrs        UnsignedAttributes -- Optional
      }

      EncapsulatedContentInfo {
        eContentType         id-encryptedData, -- (1.2.840.113549.1.7.6)
                             -- OR --
                             id-ct-compressedData,
                                       -- (1.2.840.113549.1.9.16.1.9)
                             -- OR --
                             id-ct-firmwarePackage,
                                       -- (1.2.840.113549.1.9.16.1.16)
        eContent             OCTET STRING
                                       -- Contains EncryptedData OR
                                       -- CompressedData OR FirmwarePkgData
      }

      EncryptedData {
        version              CMSVersion,
        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,
        compressionAlgorithm CompressionAlgorithmIdentifier,
        encapContentInfo     EncapsulatedContentInfo
      }





Housley                                                        [Page 14]

INTERNET DRAFT                                                 July 2003


      EncapsulatedContentInfo {
        eContentType         id-ct-firmwarePackage,
                                          -- (1.2.840.113549.1.9.16.1.16)
        eContent             OCTET STRING -- Contains FirmwarePkgData
      }

      FirmwarePkgData        OCTET STRING -- Contains the firmware

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 the outer most encapsulation to 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
      encapsulated SignedData MUST be present in this field.

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 signer 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
      2.1.2.2.




Housley                                                        [Page 15]

INTERNET DRAFT                                                 July 2003


      certificates is an optional collection of certificates.  If the
      trust anchor directly signed the firmware package, then
      certificates SHOULD be omitted.  If the trust anchor signed a
      certificate, then certificates MUST include the X.509 certificate
      of the firmware signer.  The set of certificates MAY 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 [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 MUST NOT be included.  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 to include
      timely CRLs in the firmware package.

      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 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.  The subjectKeyIdentifier
      alternative identifies the signer's public key directly.  When
      this public key is contained in a certificate, this identifier
      appears in the X.509 subjectKeyIdentifier extension.  Public key
      identifiers SHOULD be assigned using one of the methods specified
      in section 4.2.1.2 of RFC 3280 [PROFILE].

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the firmware signer.  It MUST
      contain the message digest algorithms employed by the signer of
      the encrypted firmware package.  (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



Housley                                                        [Page 16]

INTERNET DRAFT                                                 July 2003


      the CMS, but in this specification, signedAttrs are REQUIRED for
      the firmware package.  However, implementations MAY ignore
      unrecognized signed attributes.  The SET OF attributes MUST be DER
      encoded [X.509-88].  Section 2.2 of this document lists the
      attributes that MUST be included in the collection; other
      attributes MAY be included as well.

      signatureAlgorithm identifies the signature algorithm, and any
      associated parameters, used by the firmware 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 either 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,
      then the firmware packages was encrypted prior to signing, and the
      firmware package may also have been compressed prior to
      encryption.  When it contains id-ct-compressedData, then the
      firmware package was compressed prior to signing, but the firmware
      package was not encrypted.  When it contains id-ct-
      firmwarePackage, then the firmware package was not compressed or
      encrypted prior to signing.

      eContent is the encrypted firmware, 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



Housley                                                        [Page 17]

INTERNET DRAFT                                                 July 2003


   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 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



Housley                                                        [Page 18]

INTERNET DRAFT                                                 July 2003


      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 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, 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 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.



Housley                                                        [Page 19]

INTERNET DRAFT                                                 July 2003


   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 firmware 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 signer MUST
   also include the decrypt-key-identifier attribute.

   If the firmware package implements cryptographic algorithms, then the
   firmware signer MUST also include the implemented-crypto-algorithms
   attribute.

   If the firmware package is intended for use only by specific
   communities, then the firmware signer MUST also include the
   community-identifiers attribute.

   If the firmware package contains a bootstrap loader or a separation
   kernel, then the firmware signer MUST also include the firmware-
   package-info attribute.  Also, if the firmware package contains a
   dependency on a particular bootstrap loader or separation kernel,
   then the firmware signer MUST also include the firmware-package-info
   attribute.

   The firmware signer SHOULD also include the three following
   attributes: firmware-package-message-digest, signing-time, content-
   hints, and signing-certificate.

   The firmware signer MAY include any other attribute that it deems
   appropriate.

2.2.1  Content Type

   The firmware 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,
   then the firmware packages was encrypted prior to signing.  When it
   contains id-ct-compressedData, then the firmware package was
   compressed prior to signing, but the firmware package was not
   encrypted.  When it contains id-ct-firmwarePackage, then the firmware
   package was not compressed or encrypted prior to signing.  Section
   11.1 of [CMS] defines the content-type attribute.




Housley                                                        [Page 20]

INTERNET DRAFT                                                 July 2003


2.2.2  Message Digest

   The firmware signer MUST include a message-digest attribute, having
   as its value the message digest computed on the encapContentInfo
   eContent octet string.  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 type names the protected
   firmware package with 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.

   In case a firmware package with a disastrous flaw is released, the
   firmware package, which repairs the previously distributed flaw, MAY
   designate a stale version number 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.

   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 {
        fwPkgID OBJECT IDENTIFIER,
        verNum INTEGER (0..MAX),
        staleVerNum INTEGER (0..MAX) OPTIONAL }

2.2.4  Target Hardware Module Identifiers

   The target-hardware-module-identifiers attribute type names the types
   of hardware modules that the firmware package supports.  A unique
   object identifier names each supported hardware model and revision.

   The following object identifier identifies the target-hardware-
   module-identifiers attribute:



Housley                                                        [Page 21]

INTERNET DRAFT                                                 July 2003


      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 type names the symmetric key
   needed to decrypt the encapsulated 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.

   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 type 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 to be
   listed.  Any cryptographic algorithm that is used internally and not
   accessible via the cryptographic module interface MUST NOT be listed.
   For example, if the firmware package implements the decryption
   algorithm for future firmware installations and this algorithm is not
   made available outside the cryptographic module, then the firmware-
   decryption algorithm would not be listed.

   The object identifier portion of its AlgorithmIdentifier identifies
   each algorithm.

   The following object identifier identifies the implemented-crypto-
   algorithms attribute:



Housley                                                        [Page 22]

INTERNET DRAFT                                                 July 2003


      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  Community Identifiers

   The community-identifiers attribute type 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 attribute type names the authorized
   communities by a list of community object identifiers, by a list of
   hardware module identifiers, or by a combination of the two lists.  A
   hardware module identifier is an object identifier that names the
   hardware module type 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.

   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






Housley                                                        [Page 23]

INTERNET DRAFT                                                 July 2003


      CommunityIdentifier ::= CHOICE {
        communityOID OBJECT IDENTIFIER,
        hwModuleList HardwareModules }

      HardwareModules ::= SEQUENCE {
        hwType OBJECT IDENTIFIER,
        hwSerialEntries SEQUENCE OF HardwareSerialEntry }

      HardwareSerialEntry ::= CHOICE {
        single OCTET STRING,
        block SEQUENCE {
          low OCTET STRING,
          high OCTET STRING } }

2.2.8  Firmware Package Information

   If the firmware package contains a bootstrap loader or a separation
   kernel, then the firmware signer MUST also include the firmware-
   package-info attribute to identify the firmware package type.  Also,
   if the firmware package contains a dependency on another formware
   package, then the firmware signer MUST also include the firmware-
   package-info attribute to explicitly identify the dependencies.

   The firmware-package-info attribute identifies the firmware package
   type as a bootstrap loader, a separation kernel, or an application.

   The firmware-package-info attribute optionally identifies
   dependencies.  Bootstrap loader packages MUST NOT contain any
   dependencies.  Separation kernel packages SHOULD only contain
   dependencies on the bootstrap loader.  Application packages SHOULD
   only contain dependencies on the bootstrap loader and the separation
   kernel.  Dependencies are identified by the firmware package
   identifier, which is an object identifier, and the minimum version of
   that firmware package, which is an integer.

   The bootstrap loader MUST reject a firmware package load if it
   identifies a dependency on a bootstrap loader identifier other than
   the one that is executing or the identified bootstrap loader version
   is greater than the one that is executing.

   The bootstrap loader MUST reject a firmware package load if it
   identifies a dependency on a separation kernel identifier other than
   the one that is already loaded or the identified separation kernel
   version is greater than the one that is already loaded.







Housley                                                        [Page 24]

INTERNET DRAFT                                                 July 2003


   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 FWPackageType DEFAULT firmwarePackage,
        dependencies SEQUENCE OF FWPackageRef OPTIONAL }

      FWPackageType ::= INTEGER {
                          bootstrapLoader(1),
                          separationKernel(2),
                          application(3) }

      FWPackageRef ::= SEQUENCE {
        fwPkgID OBJECT IDENTIFIER,
        minVerNum INTEGER }

2.2.9  Firmware Package Message Digest

   The firmware 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 }





Housley                                                        [Page 25]

INTERNET DRAFT                                                 July 2003


2.2.10  Signing Time

   The firmware signer SHOULD include a signing-time attribute,
   specifying the time at which the signature was applied to the
   encrypted firmware.  Section 11.3 of [CMS] defines the signing-time
   attribute.

2.2.11  Content Hints

   The firmware 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.

   The configuration management systems employed by firmware package
   developers will probably not align with the firmware package naming
   convention required by this specification.  A firmware package name
   associated with such a configuration management system might look
   something like "R1234.C0(AJ11).D62.A02.11(b)" and these strings are
   only meaningful to the developers.  Including these firmware package
   names in the text description may be helpful to developers by
   providing a clear linkage between the two kinds of names.

   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.12  Signing Certificate

   When this firmware signer's public key is contained in a certificate,
   firmware signer SHOULD include a signing-certificate attribute to
   identify the certificate that was empolyed.  However, if the firmware
   package signature will be validated solely with the trust anchor
   public key, the firmware signer SHOULD NOT include a signing-
   certificate attribute.  Section 5.4 of [ESS] defines the signing-
   certificate 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



Housley                                                        [Page 26]

INTERNET DRAFT                                                 July 2003


   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 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, and when it is present, it contains a
      sequence of policy information.  In this case, the sequence of
      policy information contains a single entry.  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 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 MAY only include a single instance of the
   wrapped-firmware-decryption-key attribute.  Since the digital
   signature does not cover this attribute, it can be altered at any
   point in the delivery path from the firmware 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.

   The UnsignedAttributes syntax within signerInfo is defined as a SET
   OF Attributes.  The UnsignedAttributes MUST include only one instance
   of any particular attribute.




Housley                                                        [Page 27]

INTERNET DRAFT                                                 July 2003


2.3.1  Wrapped Firmware Decryption Key

   The firmware 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.
   The EnvelopedData does not include an encrypted content, as the key
   normally used to decrypt the encapsulated content is the firmware-
   decryption key.  Section 6 of [CMS] refers to this key as the
   content-encryption key.

   The EnvelopedData syntax support 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 set of certificates included in OriginatorInfo MUST NOT

        include certificates with a type of extendedCertificate or
        v1AttrCert.

      - The optional unprotectedAttrs field MUST NOT be present.

   Within the EncryptedContentInfo structure:

      - contentType MUST contain id-data (1.2.840.113549.1.7.1).

      - contentEncryptionAlgorithm identifies the firmware-encryption
        algorithm, and any associated parameters, used to encrypt the
        firmware package.

      - encryptedContent is optional, and in this case, it MUST NOT
        be present.



Housley                                                        [Page 28]

INTERNET DRAFT                                                 July 2003


3  Firmware Package Load Receipt

   The Cryptographic Message Syntax (CMS) is used to sign a receipt for
   successful firmware package loading.  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.

   Hardware modules that support receipt generation MUST have a unique
   serial number, a private signature key to sign the receipt, and a
   corresponding signature validation certificate to include in the
   receipt to aid validation.

   The firmware package load receipt is encapsulated by SignedData,
   which is in turn encapsulated by ContentInfo.

   The firmware package load receipt protection is summarized by:

      ContentInfo {
        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
        content              SignedData
      }

      SignedData {
        version              CMSVersion,
        digestAlgorithms     DigestAlgorithmIdentifiers,

        encapContentInfo     EncapsulatedContentInfo,
        certificates         CertificateSet, -- Module certificate
        crls                 CertificateRevocationLists, -- Omit
        signerInfos          SET OF SignerInfo -- Only one
      }

      SignerInfo {
        version              CMSVersion,
        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
      }



Housley                                                        [Page 29]

INTERNET DRAFT                                                 July 2003


      FirmwarePackageLoadReceipt {
        hwType                OBJECT IDENTIFIER, -- Hardware module type
        hwSerialNum           OCTET STRING, -- H/W module serial number
        fwPkgID               OBJECT IDENTIFIER, -- Package identifier
        verNum                INTEGER, -- Release or build number
        decryptKeyID          OCTET STRING -- Optional
      }

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 the outer most encapsulation to 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
      encapsulated SignedData MUST be present in this field.

3.1.2  SignedData

   The SignedData content type consists the firmware package load
   receipt, the hardware module certificate, and one digital signature.
   The fields of SignedData are used as follows:

      version is the syntax version number, and in this case, is 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, and in
      this case, it MUST include the X.509 certificate of the hardware



Housley                                                        [Page 30]

INTERNET DRAFT                                                 July 2003


      module.  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), and in this case, CRLs MUST NOT be included.  (Hardware
      modules will probably not have the ability to obtain the most
      recent CRLs for inclusion.)

      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 (resulting in a
      version of 3) is RECOMMENDED.

      sid specifies the hardware module's certificate (and thereby the
      hardware module's public key).  CMS supports two alternatives:
      issuerAndSerialNumber and subjectKeyIdentifier.  However, the
      hardware module MUST support only one of the alternatives.  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 appears in the X.509 subjectKeyIdentifier extension.
      Public key identifiers SHOULD be assigned using one of the methods
      specified in section 4.2.1.2 of RFC 3280 [PROFILE].  The use of
      the subjectKeyIdentifier by hardware modules is RECOMMENDED.

      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.)

      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



Housley                                                        [Page 31]

INTERNET DRAFT                                                 July 2003


      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.

      signatureAlgorithm identifies the signature algorithm, and any
      associated parameters, used by 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 }

   The firmware package load receipt content type has the ASN.1 type
   FirmwarePackageLoadReceipt:

      FirmwarePackageLoadReceipt ::= SEQUENCE {
        hwType OBJECT IDENTIFIER,
        hwSerialNum OCTET STRING,
        fwPkgID OBJECT IDENTIFIER,
        verNum INTEGER (0..MAX),
        trustAnchorKeyID [1] OCTET STRING OPTIONAL,
        decryptKeyID [2] OCTET STRING OPTIONAL }

   The fields of the FirmwarePackageLoadReceipt type have the following



Housley                                                        [Page 32]

INTERNET DRAFT                                                 July 2003


   meanings:

      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.

      fwPkgID identifies the type of firmware package that was loaded.

      verNum identifies the version of firmware package that was loaded.
      The combination of the fwPkgID and verNum specify a particular
      firmware package.  The version number is a non-negative integer
      that identifies a particular build or release of the firmware
      package.

      trustAnchorKeyID 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 hwType,
   hwSerialNum, fwPkgID, and verNum fields, and it SHOULD include the
   trustAnchorKeyID field.  The Firmware Package Load Receipt MUST
   include the decryptKeyID only if the firmware package associated with
   the receipt is encrypted, the firmware-decryption key is available,
   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 in 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.



Housley                                                        [Page 33]

INTERNET DRAFT                                                 July 2003


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

4  Hardware Module Name

   Support for firmware package load receipts, as discussed in section
   3, is OPTIONAL.  Hardware modules that support receipt generation
   MUST have a unique serial number, a private signature key to sign the
   receipt, and a corresponding signature validation certificate
   [PROFILE] to include in the receipt to aid validation.  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.  The otherName choice within the GeneralName
   structure is used.








Housley                                                        [Page 34]

INTERNET DRAFT                                                 July 2003


   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.

      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.

5  References

   This section provides normative and informative references.

5.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.
              RFC 3369.  August 2002.

   ESS        Hoffman, P.  Enhanced Security Services for S/MIME.
              RFC 2634.  June 1999.

   PROFILE    Housley, R., W. Polk, W. Ford, and D. Solo.  Internet
              X.509 Public Key Infrastructure Certificate and

              Certificate Revocation List (CRL) Profile.  RFC 3280.
              April 2002.




Housley                                                        [Page 35]

INTERNET DRAFT                                                 July 2003


   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.  RFC 2119.  March 1997.

   UTF-8      Yergeau, F.  UTF-8, a transformation format of ISO 10646.
              RFC 2279.  January 1998.

   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.

5.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.

   DPD&DPV    Pinkas, D., and R. Housley.  Delegated Path Validation
              and Delegated Path Discovery Protocol Requirements.
              RFC 3379.  September 2002.

   DSS        National Institute of Standards and Technology.
              FIPS Pub 186: Digital Signature Standard.  19 May 1994.

   OCSP       Myers, M., R. Ankney, A. Malpani, S. Galperin, 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., S. Crocker, and J. Schiller.  Randomness
              Recommendations for Security.  RFC 1750.  December 1994.





Housley                                                        [Page 36]

INTERNET DRAFT                                                 July 2003


   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.

6  Security Considerations

   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 permits unauthorized
   parties to generate firmware package load receipts.

   The firmware-decryption key must be protected.  Compromise of the key
   may result in the disclosure of the firmware 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.  While this capability is desirable, cryptographic
   algorithm replacement can lead to interoperability failures.
   Therefore, the roll out of new cryptographic algorithms must be
   managed.  Generally, the previous generation of cryptographic
   algorithms needs to be supported at the same time as their
   replacements to facilitate an orderly transition.

   The use of a stale version number in a firmware package 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 their own stale firmware version number, until
   the internal storage for the stale version number is exceeded, the
   user can circumvent the mechanism.  Consider a hardware module that
   has storage for two stale version numbers.  Suppose that FWPKG-A
   version 3 is loaded, indicating that FWPKG-A version 2 is stale.  The
   user can sequentially load the following:

      - FWPKG-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.)




Housley                                                        [Page 37]

INTERNET DRAFT                                                 July 2003


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

   Since many hardware modules are expected to have very few firmware
   packages written for them, the stale firmware 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 with
   common trust anchors that are likely to be developed for the hardware
   module.

   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
   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
   1750 [RANDOM] offers important guidance in this area, and Appendix 3
   of FIPS Pub 186 [DSS] provides one quality PRNG technique.

7  Author Address

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   housley@vigilsec.com
















Housley                                                        [Page 38]

INTERNET DRAFT                                                 July 2003


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, id-data
       FROM CryptographicMessageSyntax
            { iso(1) member-body(2) us(840) rsadsi(113549)
              pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };


   -- 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 {
     fwPkgID OBJECT IDENTIFIER,
     verNum INTEGER (0..MAX),
     staleVerNum INTEGER (0..MAX) OPTIONAL }


   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



Housley                                                        [Page 39]

INTERNET DRAFT                                                 July 2003


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

   HardwareSerialEntry ::= CHOICE {
     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 FWPackageType DEFAULT application,
     dependencies SEQUENCE OF FWPackageRef OPTIONAL }

   FWPackageType ::= INTEGER {
                       bootstrapLoader(1),
                       separationKernel(2),
                       application(3) }




Housley                                                        [Page 40]

INTERNET DRAFT                                                 July 2003


   FWPackageRef ::= SEQUENCE {
     fwPkgID OBJECT IDENTIFIER,
     minVerNum INTEGER }


   -- 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 {
     hwType OBJECT IDENTIFIER,
     hwSerialNum OCTET STRING,
     fwPkgID OBJECT IDENTIFIER,
     verNum INTEGER (0..MAX),
     decryptKeyID OCTET STRING OPTIONAL }


   -- 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










Housley                                                        [Page 41]

INTERNET DRAFT                                                 July 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  In addition, the
   ASN.1 module presented in Appendix A may be used in whole or in part
   without inclusion of the copyright notice.  However, this document
   itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process shall be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS 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.























Housley                                                        [Page 42]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/