diff --git a/doc/standardisation/rfc4043.txt b/doc/standardisation/rfc4043.txt
new file mode 100644
index 000000000..c31b30d88
--- /dev/null
+++ b/doc/standardisation/rfc4043.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          D. Pinkas
+Request for Comments: 4043                                          Bull
+Category: Standards Track                                      T. Gindin
+                                                                     IBM
+                                                                May 2005
+
+
+                Internet X.509 Public Key Infrastructure
+                          Permanent Identifier
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a new form of name, called permanent
+   identifier, that may be included in the subjectAltName extension of a
+   public key certificate issued to an entity.
+
+   The permanent identifier is an optional feature that may be used by a
+   CA to indicate that two or more certificates relate to the same
+   entity, even if they contain different subject name (DNs) or
+   different names in the subjectAltName extension, or if the name or
+   the affiliation of that entity stored in the subject or another name
+   form in the subjectAltName extension has changed.
+
+   The subject name, carried in the subject field, is only unique for
+   each subject entity certified by the one CA as defined by the issuer
+   name field.  However, the new name form can carry a name that is
+   unique for each subject entity certified by a CA.
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 1]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Table of Contents
+
+   1.  Introduction..................................................  2
+   2.  Definition of a Permanent Identifier..........................  3
+   3.  IANA Considerations...........................................  6
+   4.  Security Considerations.......................................  6
+   5.  References....................................................  7
+       5.1.  Normative References....................................  7
+       5.2.  Informative References..................................  8
+   Appendix A. ASN.1 Syntax..........................................  9
+       A.1.  1988 ASN.1 Module.......................................  9
+       A.2.  1993 ASN.1 Module....................................... 10
+   Appendix B. OID's for organizations............................... 11
+       B.1.  Using IANA (Internet Assigned Numbers Authority)........ 11
+       B.2.  Using an ISO Member Body................................ 12
+       B.3.  Using an ICD (International Code Designator) From
+             British Standards Institution to Specify a New or
+             an Existing Identification Scheme....................... 12
+   Authors' Addresses................................................ 14
+   Full Copyright Statement.......................................... 15
+
+1.  Introduction
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   This specification is based on [RFC3280], which defines underlying
+   certificate formats and semantics needed for a full implementation of
+   this standard.
+
+   The subject field of a public key certificate identifies the entity
+   associated with the public key stored in the subject public key
+   field.  Names and identities of a subject may be carried in the
+   subject field and/or the subjectAltName extension.  Where subject
+   field is non-empty, it MUST contain an X.500 distinguished name (DN).
+   The DN MUST be unique for each subject entity certified by a single
+   CA as defined by the issuer name field.
+
+   The subject name changes whenever any of the components of that name
+   gets changed.  There are several reasons for such a change to happen.
+
+      For employees of a company or organization, the person may get a
+      different position within the same company and thus will move from
+      one organization unit to another one.  Including the organization
+      unit in the name may however be very useful to allow the relying
+      parties (RP's) using that certificate to identify the right
+      individual.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 2]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      For citizens, an individual may change their name by legal
+      processes, especially as a result of marriage.
+
+      Any certificate subject identified by geographical location may
+      relocate and change at least some of the location attributes
+      (e.g., country name, state or province, locality, or street).
+
+   A permanent identifier consists of an identifier value assigned
+   within a given naming space by the organization which is
+   authoritative for that naming space.  The organization assigning the
+   identifier value may be the CA that has issued the certificate or a
+   different organization called an Assigner Authority.
+
+   An Assigner Authority may be a government, a government agency, a
+   corporation, or any other sort of organization.  It MUST have a
+   unique identifier to distinguish it from any other such authority.
+   In this standard, that identifier MUST be an object identifier.
+
+   A permanent identifier may be useful in three contexts: access
+   control, non-repudiation and audit records.
+
+      For access control, the permanent identifier may be used in an ACL
+      (Access Control List) instead of the DN or any other form of name
+      and would not need to be changed, even if the subject name of the
+      entity changes.  For non-repudiation, the permanent identifier may
+      be used to link different transactions to the same entity, even
+      when the subject name of the entity changes.
+
+      For audit records, the permanent identifier may be used to link
+      different audit records to the same entity, even when the subject
+      name of the entity changes.
+
+   For two certificates which have been both verified to be valid
+   according to a given validation policy and which contain a permanent
+   identifier, those certificates relate to the same entity if their
+   permanent identifiers match, whatever the content of the DN or other
+   subjectAltName components may be.
+
+   Since the use of permanent identifiers may conflict with privacy, CAs
+   SHOULD advertise to purchasers of certificates the use of permanent
+   identifiers in certificates.
+
+2.  Definition of a Permanent Identifier
+
+   This Permanent Identifier is a name defined as a form of otherName
+   from the GeneralName structure in SubjectAltName, as defined in
+   [X.509] and [RFC3280].
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 3]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   A CA which includes a permanent identifier in a certificate is
+   certifying that any public key certificate containing the same values
+   for that identifier refers to the same entity.
+
+   The use of a permanent identifier is OPTIONAL.  The permanent
+   identifier is defined as follows:
+
+      id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+        PermanentIdentifier ::=     SEQUENCE {
+           identifierValue    UTF8String             OPTIONAL,
+                           -- if absent, use a serialNumber attribute,
+                           -- if there is such an attribute present
+                           -- in the subject DN
+           assigner           OBJECT IDENTIFIER      OPTIONAL
+                           -- if absent, the assigner is
+                           -- the certificate issuer
+   }
+
+   The identifierValue field is optional.
+
+      When the identifierValue field is present, then the
+      identifierValue supports one syntax: UTF8String.
+
+      When the identifierValue field is absent, then the value of the
+      serialNumber attribute (as defined in section 5.2.9 of [X.520])
+      from the deepest RDN of the subject DN is the value to be taken
+      for the identifierValue.  In such a case, there MUST be at least
+      one serialNumber attribute in the subject DN, otherwise the
+      PermanentIdentifier SHALL NOT be used.
+
+   The assigner field is optional.
+
+      When the assigner field is present, then it is an OID which
+      identifies a naming space, i.e., both an Assigner Authority and
+      the type of that field.  Characteristically, the prefix of the OID
+      identifies the Assigner Authority, and a suffix is used to
+      identify the type of permanent identifier.
+
+      When the assigner field is absent, then the permanent identifier
+      is locally unique to the CA.
+
+   The various combinations are detailed below:
+
+   1. Both the assigner and the identifierValue fields are present:
+
+      The identifierValue is the value for that type of identifier.  The
+      assigner field identifies the Assigner Authority and the type of
+      permanent identifier being identified.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 4]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      The permanent identifier is globally unique among all CAs.  In
+      such a case, two permanent identifiers of this type match if and
+      only if their assigner fields match and the contents of the
+      identifierValue field in the two permanent identifiers consist of
+      the same Unicode code points presented in the same order.
+
+   2. The assigner field is absent and the identifierValue field is
+      present:
+
+      The Assigner Authority is the CA that has issued the certificate.
+      The identifierValue is given by the CA and the permanent
+      identifier is only local to the CA that has issued the
+      certificate.
+
+      In such a case, two permanent identifiers of this type match if
+      and only if the issuer DN's in the certificates which contain them
+      match using the distinguishedNameMatch rule, as defined in X.501,
+      and the two values of the identifierValue field consist of the
+      same Unicode code points presented in the same order.
+
+   3. Both the assigner and the identifierValue fields are absent:
+
+      If there are one or more RDNs containing a serialNumber attribute
+      (alone or accompanied by other attributes), then the value
+      contained in the serialNumber of the deepest such RDN SHALL be
+      used as the identifierValue; otherwise, the Permanent Identifier
+      definition is invalid and the Permanent Identifier SHALL NOT be
+      used.
+
+      The permanent identifier is only local to the CA that has issued
+      the certificate.  In such a case, two permanent identifiers of
+      this type match if and only if the issuer DN's in the certificates
+      which contain them match and the serialNumber attributes within
+      the subject DN's of those same certificates also match using the
+      caseIgnoreMatch rule.
+
+   4. The assigner field is present and the identifierValue field is
+      absent:
+
+      If there are one or more RDNs containing a serialNumber attribute
+      (alone or accompanied by other attributes), then the value
+      contained in the serialNumber of the deepest such RDN SHALL be
+      used as the identifierValue; otherwise, the Permanent Identifier
+      definition is invalid and the Permanent Identifier SHALL NOT be
+      used.
+
+      The assigner field identifies the Assigner Authority and the type
+      of permanent identifier being identified.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 5]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      The permanent identifier is globally unique among all CAs.  In
+      such a case, two permanent identifiers of this type match if and
+      only if their assigner fields match and the contents of the
+      serialNumber attributes within the subject DN's of those same
+      certificates match using the caseIgnoreMatch rule.
+
+   Note: The full arc of the object identifier used to identify the
+         permanent identifier name form is derived using:
+
+      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+         dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+      id-on OBJECT IDENTIFIER ::= { id-pkix 8 }   -- other name forms
+
+3.  IANA Considerations
+
+   No IANA actions are necessary.  However, a Private Enterprise Number
+   may be used to construct an OID for the assigner field (see Annex
+   B.1.).
+
+4.  Security Considerations
+
+   A given entity may have at an instant of time or at different
+   instants of time multiple forms of identities.  If the permanent
+   identifier is locally unique to the CA (i.e., the assigner field is
+   not present), then two certificates from the same CA can be compared.
+
+   When two certificates contain identical permanent identifiers, then a
+   relying party may determine that they refer to the same entity.
+
+   If the permanent identifier is globally unique among all CAs (i.e.,
+   the assigner field is present), then two certificates from different
+   CAs can be compared.  When they contain two identical permanent
+   identifiers, then a relying party may determine that they refer to
+   the same entity.  It is the responsibility of the CA to verify that
+   the permanent identifier being included in the certificate refers to
+   the subject being certified.
+
+   The permanent identifier identifies the entity, irrespective of any
+   attribute extension.  When a public key certificate contains
+   attribute extensions, the permanent identifier, if present, should
+   not be used for access control purposes but only for audit purposes.
+   The reason is that since these attributes may change, access could be
+   granted on attributes that were originally present in a certificate
+   issued to that entity but are no longer present in the current
+   certificate.
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 6]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   Subject names in certificates are chosen by the issuing CA and are
+   mandated to be unique for each CA; so there can be no name collision
+   between subject names from the same CA.  Such a name may be an end-
+   entity name when the certificate is a leaf certificate, or a CA name,
+   when it is a CA certificate.
+
+   Since a name is only unique towards its superior CA, unless some
+   naming constraints are being used, a name would only be guaranteed to
+   be globally unique when considered to include a sequence of all the
+   names of the superior CAs.  Thus, two certificates that are issued
+   under the same issuer DN and which contain the same permanent
+   identifier extension without an assigner field do not necessarily
+   refer to the same entity.
+
+   Additional checks need to be done, e.g., to check if the public key
+   values of the two CAs which have issued the certificates to be
+   compared are identical or if the sequence of CA names in the
+   certification path from the trust anchor to the CA are identical.
+
+   When the above checks fail, the permanent identifiers may still match
+   if there has been a CA key rollover.  In such a case the checking is
+   more complicated.
+
+   The certification of different CAs with the same DN by different CAs
+   has other negative consequences in various parts of the PKI, notably
+   rendering the IssuerAndSerialNumber structure in [RFC3852] section
+   10.2.4 ambiguous.
+
+   The permanent identifier allows organizations to create links between
+   different certificates associated with an entity issued with or
+   without overlapping validity periods.  This ability to link different
+   certificates may conflict with privacy.  It is therefore important
+   that a CA clearly disclose any plans to issue certificates which
+   include a permanent identifier to potential subjects of those
+   certificates.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 7]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [X.501]    ITU-T Rec X.501 | ISO 9594-2: 2001: Information technology
+              - Open Systems Interconnection - The Directory: Models,
+              February 2001.
+
+5.2.  Informative References
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+              3852, July 2004.
+
+   [X.509]    ITU-T Recommendation X.509 (1997 E): Information
+              Technology - Open Systems Interconnection - The Directory:
+              Authentication Framework, June 1997.
+
+   [X.520]    ITU-T Recommendation X.520: Information Technology - Open
+              Systems Interconnection - The Directory: Selected
+              Attribute Types, June 1997.
+
+   [X.660]    ITU-T Recommendation X.660: Information Technology - Open
+              Systems Interconnection - Procedures for the Operation of
+              OSI Registration Authorities: General Procedures, 1992.
+
+   [X.680]    ITU-T Recommendation X.680: Information Technology -
+              Abstract Syntax Notation One, 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 8]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Appendix A.  ASN.1 Syntax
+
+   As in RFC 2459, ASN.1 modules are supplied in two different variants
+   of the ASN.1 syntax.
+
+   This section describes data objects used by conforming PKI components
+   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
+   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
+   the UNIVERSAL Type UTF8String.
+
+   The ASN.1 syntax does not permit the inclusion of type statements in
+   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+   the new UNIVERSAL types in modules using the 1988 syntax.  As a
+   result, this module does not conform to either version of the ASN.1
+   standard.
+
+   Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the
+   definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+   Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser.
+
+   In case of discrepancies between these modules, the 1988 module is
+   the normative one.
+
+Appendix A.1.  1988 ASN.1 Module
+
+  PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6)
+         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-perm-id-88(28) }
+
+  DEFINITIONS EXPLICIT TAGS ::=
+
+     BEGIN
+
+     -- EXPORTS ALL --
+
+     IMPORTS
+
+  -- UTF8String, / move hyphens before slash if UTF8String does not
+  -- resolve with your compiler
+  -- The content of this type conforms to [UTF-8].
+
+          id-pkix
+                FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+                dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+                id-mod(0) id-pkix1-explicit(18) } ;
+                -- from [RFC3280]
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 9]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+     -- Permanent identifier Object Identifier and Syntax
+
+     id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
+
+     id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+
+     PermanentIdentifier ::= SEQUENCE {
+          identifierValue    UTF8String             OPTIONAL,
+                          -- if absent, use the serialNumber attribute
+                          -- if there is a single such attribute present
+                          -- in the subject DN
+          assigner           OBJECT IDENTIFIER      OPTIONAL
+                          -- if absent, the assigner is
+                          -- the certificate issuer
+  }
+
+  END
+
+Appendix A.2.  1993 ASN.1 Module
+
+PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
+       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-perm-id-93(29) }
+
+   DEFINITIONS EXPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+
+        id-pkix
+              FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+              id-mod(0) id-pkix1-explicit(18) }
+               -- from [RFC3280]
+
+        ATTRIBUTE
+              FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
+              informationFramework(1) 4};
+               -- from [X.501]
+
+   -- Permanent identifier Object Identifiers
+
+   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
+
+   id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 10]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   -- Permanent Identifier
+
+   permanentIdentifier ATTRIBUTE ::= {
+          WITH SYNTAX     PermanentIdentifier
+          ID              id-on-permanentIdentifier }
+
+   PermanentIdentifier ::= SEQUENCE {
+        identifierValue    UTF8String             OPTIONAL,
+                        -- if absent, use the serialNumber attribute
+                        -- if there is a single such attribute present
+                        -- in the subject DN
+        assigner           OBJECT IDENTIFIER      OPTIONAL
+                        -- if absent, the assigner is
+                        -- the certificate issuer
+}
+
+END
+
+Appendix B.  OID's for Organizations
+
+   In order to construct an OID for the assigner field, organizations
+   need first to have a registered OID for themselves.  Such an OID must
+   be obtained from a registration authority following [X.660].  In some
+   cases, OID's are provided for free.  In other cases a one-time fee is
+   required.  The main difference lies in the nature of the information
+   that is collected at the time of registration and how this
+   information is verified for its accuracy.
+
+Appendix B.1.  Using IANA (Internet Assigned Numbers Authority)
+
+   The application form for a Private Enterprise Number in the IANA's
+   OID list is: http://www.iana.org/cgi-bin/enterprise.pl.
+
+   Currently, IANA assigns numbers for free.  The IANA-registered
+   Private Enterprises prefix is:
+   iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)
+
+   These numbers are used, among other things, for defining private SNMP
+   MIBs.
+
+   The official assignments under this OID are stored in the IANA file
+   "enterprise-numbers" available at:
+   http://www.iana.org/assignments/enterprise-numbers
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 11]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Appendix B.2.  Using an ISO Member Body
+
+   ISO has defined the OID structure in a such a way so that every ISO
+   member-body has its own unique OID.  Then every ISO member-body is
+   free to allocate its own arc space below.
+
+   Organizations and enterprises may contact the ISO member-body where
+   their organization or enterprise is established to obtain an
+   organization/enterprise OID.
+
+   Currently, ISO members do not assign organization/enterprise OID's
+   for free.
+
+   Most of them do not publish registries of such OID's which they have
+   assigned, sometimes restricting the access to registered
+   organizations or preferring to charge inquirers for the assignee of
+   an OID on a per-inquiry basis.  The use of OID's from an ISO member
+   organization which does not publish such a registry may impose extra
+   costs on the CA that needs to make sure that the OID corresponds to
+   the registered organization.
+
+   As an example, AFNOR (Association Francaise de Normalisation - the
+   French organization that is a member of ISO) has defined an arc to
+   allocate OID's for companies:
+
+   {iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
+
+Appendix B.3.  Using an ICD (International Code Designator) From British
+               Standards Institution to Specify a New or an Existing
+               Identification Scheme
+
+   The International Code Designator (ICD) is used to uniquely identify
+   an ISO 6523 compliant organization identification scheme.  ISO 6523
+   is a standard that defines the proper structure of an identifier and
+   the registration procedure for an ICD.  The conjunction of the ICD
+   with an identifier issued by the registration authority is worldwide
+   unique.
+
+   The basic structure of the code contains the following components:
+
+   -  the ICD value: The International Code Designator issued to the
+      identification scheme makes the identifier worldwide unique (up to
+      4 digits),
+
+   -  the Organization, usually a company or governmental body (up to 35
+      characters),
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 12]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   -  an Organization Part (OPI - Organization Part Identifier).  An
+      identifier allocated to a particular Organization Part (optional,
+      up to 35 characters)
+
+   The ICD is also equivalent to an object identifier (OID) under the
+   arc {1(iso).  3(identified organization)}.
+
+   On behalf of ISO, British Standards Institution (BSI) is the
+   Registration Authority for organizations under the arc {iso (1)
+   org(3)}.  This means BSI registers code issuing authorities
+   (organizations) by ICD values which are equivalent to OIDs of the
+   form {iso (1) org(3) icd(xxxx)}.  The corresponding IdentifierValue
+   is the code value of the scheme identified by icd(xxxx).
+
+   As an example, the ICD 0012 was allocated to European Computer
+   Manufacturers Association: ECMA.  Thus the OID for ECMA is {iso(1)
+   org(3) ecma(12)}.
+
+   For registration with BSI, a "Sponsoring Authority" has to vouch for
+   the Applying organization.  Registration is not free.  Recognized
+   "Sponsoring Authorities" are: ISO Technical Committees or
+   (Sub)Committees, Member Bodies of ISO or International Organizations
+   having a liaison status with ISO or with any of its Technical
+   (Sub)Committees.
+
+   An example of a Sponsoring Authority is the EDIRA Association (EDI/EC
+   Registration Authority, web: http://www.edira.org,
+   email:info@edira.org).
+
+   The numerical list of all ICDs that have been issued is posted on its
+   webpage: http://www.edira.org/documents.htm#icd-List
+
+   Note: IANA owns ICD code 0090, but (presumably) it isn't intending to
+   use it for the present purpose.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 13]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Authors' Addresses
+
+   Denis Pinkas
+   Bull
+   Rue Jean-Jaures BP 68
+   78340 Les Clayes-sous-Bois
+   FRANCE
+
+   EMail: Denis.Pinkas@bull.net
+
+
+   Thomas Gindin
+   IBM Corporation
+   6710 Rockledge Drive
+   Bethesda, MD 20817
+   USA
+
+   EMail: tgindin@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 14]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 15]
+
diff --git a/doc/standardisation/rfc4108.txt b/doc/standardisation/rfc4108.txt
new file mode 100644
index 000000000..8119548a9
--- /dev/null
+++ b/doc/standardisation/rfc4108.txt
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 4108                                Vigil Security
+Category: Standards Track                                    August 2005
+
+
+ Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) to protect firmware packages, which provide object code for one
+   or more hardware module components.  CMS is specified in RFC 3852.  A
+   digital signature is used to protect the firmware package from
+   undetected modification and to provide data origin authentication.
+   Encryption is optionally used to protect the firmware package from
+   disclosure, and compression is optionally used to reduce the size of
+   the protected firmware package.  A firmware package loading receipt
+   can optionally be generated to acknowledge the successful loading of
+   a firmware package.  Similarly, a firmware package load error report
+   can optionally be generated to convey the failure to load a firmware
+   package.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................5
+      1.2. Architectural Elements .....................................5
+           1.2.1. Hardware Module Requirements ........................7
+           1.2.2. Firmware Package Requirements .......................8
+           1.2.3. Bootstrap Loader Requirements .......................9
+                  1.2.3.1. Legacy Stale Version Processing ...........11
+                  1.2.3.2. Preferred Stale Version Processing ........12
+           1.2.4. Trust Anchors ......................................12
+           1.2.5. Cryptographic and Compression Algorithm
+                  Requirements .......................................13
+      1.3. Hardware Module Security Architecture .....................14
+      1.4. ASN.1 Encoding ............................................14
+      1.5. Protected Firmware Package Loading ........................15
+   2. Firmware Package Protection ....................................15
+      2.1. Firmware Package Protection CMS Content Type Profile ......18
+           2.1.1. ContentInfo ........................................18
+           2.1.2. SignedData .........................................18
+                  2.1.2.1. SignerInfo ................................19
+                  2.1.2.2. EncapsulatedContentInfo ...................20
+           2.1.3. EncryptedData ......................................20
+                  2.1.3.1. EncryptedContentInfo ......................21
+           2.1.4. CompressedData .....................................21
+                  2.1.4.1. EncapsulatedContentInfo ...................22
+           2.1.5. FirmwarePkgData ....................................22
+      2.2. Signed Attributes .........................................22
+           2.2.1. Content Type .......................................23
+           2.2.2. Message Digest .....................................24
+           2.2.3. Firmware Package Identifier ........................24
+           2.2.4. Target Hardware Module Identifiers .................25
+           2.2.5. Decrypt Key Identifier .............................26
+           2.2.6. Implemented Crypto Algorithms ......................26
+           2.2.7. Implemented Compression Algorithms .................27
+           2.2.8. Community Identifiers ..............................27
+           2.2.9. Firmware Package Information .......................29
+           2.2.10. Firmware Package Message Digest ...................30
+           2.2.11. Signing Time ......................................30
+           2.2.12. Content Hints .....................................31
+           2.2.13. Signing Certificate ...............................31
+      2.3. Unsigned Attributes .......................................32
+           2.3.1. Wrapped Firmware Decryption Key ....................33
+   3. Firmware Package Load Receipt ..................................34
+      3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
+           3.1.1. ContentInfo ........................................36
+
+
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+           3.1.2. SignedData .........................................36
+                  3.1.2.1. SignerInfo ................................37
+                  3.1.2.2. EncapsulatedContentInfo ...................38
+           3.1.3. FirmwarePackageLoadReceipt .........................38
+      3.2. Signed Attributes .........................................40
+           3.2.1. Content Type .......................................40
+           3.2.2. Message Digest .....................................40
+           3.2.3. Signing Time .......................................40
+   4. Firmware Package Load Error ....................................41
+      4.1. Firmware Package Load Error CMS Content Type Profile ......42
+           4.1.1. ContentInfo ........................................42
+           4.1.2. SignedData .........................................43
+                  4.1.2.1. SignerInfo ................................43
+                  4.1.2.2. EncapsulatedContentInfo ...................43
+           4.1.3. FirmwarePackageLoadError ...........................43
+      4.2. Signed Attributes .........................................49
+           4.2.1. Content Type .......................................49
+           4.2.2. Message Digest .....................................49
+           4.2.3. Signing Time .......................................50
+   5. Hardware Module Name ...........................................50
+   6. Security Considerations ........................................51
+      6.1. Cryptographic Keys and Algorithms .........................51
+      6.2. Random Number Generation ..................................51
+      6.3. Stale Firmware Package Version Number .....................52
+      6.4. Community Identifiers .....................................53
+   7. References .....................................................54
+      7.1. Normative References ......................................54
+      7.2. Informative References ....................................54
+   Appendix A: ASN.1 Module ..........................................56
+
+1.  Introduction
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) [CMS] to protect firmware packages.  This document also
+   describes the use of CMS for receipts and error reports for firmware
+   package loading.  The CMS is a data protection encapsulation syntax
+   that makes use of ASN.1 [X.208-88, X.209-88].  The protected firmware
+   package can be associated with any particular hardware module;
+   however, this specification was written with the requirements of
+   cryptographic hardware modules in mind, as these modules have strong
+   security requirements.
+
+   The firmware package contains object code for one or more
+   programmable components that make up the hardware module.  The
+   firmware package, which is treated as an opaque binary object, is
+   digitally signed.  Optional encryption and compression are also
+   supported.  When all three are used, the firmware package is
+   compressed, then encrypted, and then signed.  Compression simply
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   reduces the size of the firmware package, allowing more efficient
+   processing and transmission.  Encryption protects the firmware
+   package from disclosure, which allows transmission of sensitive
+   firmware packages over insecure links.  The encryption algorithm and
+   mode employed may also provide integrity, protecting the firmware
+   package from undetected modification.  The encryption protects
+   proprietary algorithms, classified algorithms, trade secrets, and
+   implementation techniques.  The digital signature protects the
+   firmware package from undetected modification and provides data
+   origin authentication.  The digital signature allows the hardware
+   module to confirm that the firmware package comes from an acceptable
+   source.
+
+   If encryption is used, the firmware-decryption key must be made
+   available to the hardware module via a secure path.  The key might be
+   delivered via physical media or via an independent electronic path.
+   One optional mechanism for distributing the firmware-decryption key
+   is specified in Section 2.3.1, but any secure key distribution
+   mechanism is acceptable.
+
+   The signature verification public key must be made available to the
+   hardware module in a manner that preserves its integrity and confirms
+   its source.  CMS supports the transfer of certificates, and this
+   facility can be used to transfer a certificate that contains the
+   signature verification public key (a firmware-signing certificate).
+   However, use of this facility introduces a level of indirection.
+   Ultimately, a trust anchor public key must be made available to the
+   hardware module.  Section 1.2 establishes a requirement that the
+   hardware module store one or more trust anchors.
+
+   Hardware modules may not be capable of accessing certificate
+   repositories or delegated path discovery (DPD) servers [DPD&DPV] to
+   acquire certificates needed to complete a certification path.  Thus,
+   it is the responsibility of the firmware package signer to include
+   sufficient certificates to enable each module to validate the
+   firmware-signer certificate (see Section 2.1.2).  Similarly, hardware
+   modules may not be capable of accessing a certificate revocation list
+   (CRL) repository, an OCSP responder [OCSP], or a delegated path
+   validation (DPV) server [DPD&DPV] to acquire revocation status
+   information.  Thus, if the firmware package signature cannot be
+   validated solely with the trust anchor public key and the hardware
+   module is not capable of performing full certification path
+   validation, then it is the responsibility of the entity loading a
+   package into a hardware module to validate the firmware-signer
+   certification path prior to loading the package into a hardware
+   module.  The means by which this external certificate revocation
+   status checking is performed is beyond the scope of this
+   specification.
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Hardware modules will only accept firmware packages with a valid
+   digital signature.  The signature is either validated directly using
+   the trust anchor public key or using a firmware-signer certification
+   path that is validated to the trust anchor public key.  Thus, the
+   trust anchors define the set of entities that can create firmware
+   packages for the hardware module.
+
+   The disposition of a previously loaded firmware package after the
+   successful validation of another firmware package is beyond the scope
+   of this specification.  The amount of memory available to the
+   hardware module will determine the range of alternatives.
+
+   In some cases, hardware modules can generate receipts to acknowledge
+   the loading of a particular firmware package.  Such receipts can be
+   used to determine which hardware modules need to receive an updated
+   firmware package whenever a flaw in an earlier firmware package is
+   discovered.  Hardware modules can also generate error reports to
+   indicate the unsuccessful firmware package loading.  To implement
+   either receipt or error report generation, the hardware module is
+   required to have a unique permanent serial number.  Receipts and
+   error reports can be either signed or unsigned.  To generate
+   digitally signed receipts or error reports, a hardware module MUST be
+   issued its own private signature key and a certificate that contains
+   the corresponding signature validation public key.  In order to save
+   memory with the hardware module, the hardware module might store a
+   certificate designator instead of the certificate itself.  The
+   private signature key requires secure storage.
+
+1.1.  Terminology
+
+   In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
+   described in [STDWORDS].
+
+1.2.  Architectural Elements
+
+   The architecture includes the hardware module, the firmware package,
+   and a bootstrap loader.  The bootstrap loader MUST have access to one
+   or more trusted public keys, called trust anchors, to validate the
+   signature on the firmware package.  If a signed firmware package load
+   receipt or error report is created on behalf of the hardware module,
+   then the bootstrap loader MUST have access to a private signature key
+   to generate the signature and the signer identifier for the
+   corresponding signature validation certificate or its designator.  A
+   signature validation certificate MAY be included to aid signature
+   validation.  To implement this optional capability, the hardware
+   module MUST have a unique serial number and a private signature key;
+   the hardware module MAY also include a certificate that contains the
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   corresponding signature validation public key.  These items MUST be
+   installed in the hardware module before it is deployed.  The private
+   key and certificate can be generated and installed as part of the
+   hardware module manufacture process.  Figure 1 illustrates these
+   architectural elements.
+
+   ASN.1 object identifiers are the preferred means of naming the
+   architectural elements.
+
+   Details of managing the trust anchors are beyond the scope of this
+   specification.  However, one or more trust anchors MUST be installed
+   in the hardware module using a secure process before it is deployed.
+   These trust anchors provide a means of controlling the acceptable
+   sources of firmware packages.  The hardware module vendor can include
+   provisions for secure, remote management of trust anchors.  One
+   approach is to include trust anchors in the firmware packages
+   themselves.  This approach is analogous to the optional capability
+   described later for updating the bootstrap loader.
+
+   In a cryptographic hardware module, the firmware package might
+   implement many different cryptographic algorithms.
+
+   When the firmware package is encrypted, the firmware-decryption key
+   and the firmware package MUST both be provided to the hardware
+   module.  The firmware-decryption key is necessary to use the
+   associated firmware package.  Generally, separate distribution
+   mechanisms will be employed for the firmware-decryption key and the
+   firmware package.  An optional mechanism for securely distributing
+   the firmware-decryption key with the firmware package is specified in
+   Section 2.3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+            +------------------------------------------------------+
+            |  Hardware Module                                     |
+            |                                                      |
+            |   +---------------+   +--------------------------+   |
+            |   |  Bootstrap    |   |  Firmware Package        |   |
+            |   |  Loader       |   |                          |   |
+            |   +---------------+   |   +------------------+   |   |
+            |                       |   : Firmware Package :   |   |
+            |   +---------------+   |   : Identifier and   :   |   |
+            |   |  Trust        |   |   : Version Number   :   |   |
+            |   |  Anchor(s)    |   |   +------------------+   |   |
+            |   +---------------+   |                          |   |
+            |                       |   +-------------+        |   |
+            |   +---------------+   |   : Algorithm 1 :        |   |
+            |   |  Serial Num.  |   |   +-+-----------+-+      |   |
+            |   +---------------+   |     : Algorithm 2 :      |   |
+            |                       |     +-+-----------+-+    |   |
+            |   +---------------+   |       : Algorithm n :    |   |
+            |   |  Hardware     |   |       +-------------+    |   |
+            |   |  Module Type  |   |                          |   |
+            |   +---------------+   +--------------------------+   |
+            |                                                      |
+            |        +------------------------------------+        |
+            |        |  Optional Private Signature Key &  |        |
+            |        |  Signature Validation Certificate  |        |
+            |        |  or the Certificate Designator     |        |
+            |        +------------------------------------+        |
+            |                                                      |
+            +------------------------------------------------------+
+
+                     Figure 1.  Architectural Elements
+
+1.2.1.  Hardware Module Requirements
+
+   Many different vendors develop hardware modules, and each vendor
+   typically identifies its modules by product type (family) and
+   revision level.  A unique object identifier MUST name each hardware
+   module type and revision.
+
+   Each hardware module within a hardware module family SHOULD have a
+   unique permanent serial number.  However, if the optional receipt or
+   error report generation capability is implemented, then the hardware
+   module MUST have a unique permanent serial number.  If the optional
+   receipt or error report signature capability is implemented, then the
+   hardware module MUST have a private signature key and a certificate
+   containing the corresponding public signature validation key or its
+   designator.  If a serial number is present, the bootstrap loader uses
+
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   it for authorization decisions (see Section 2.2.8), receipt
+   generation (see Section 3), and error report generation (see
+   Section 4).
+
+   When the hardware module includes more than one firmware-programmable
+   component, the bootstrap loader distributes components of the package
+   to the appropriate components within the hardware module after the
+   firmware package is validated.  The bootstrap loader is discussed
+   further in Section 1.2.3.
+
+1.2.2.  Firmware Package Requirements
+
+   Two approaches to naming firmware packages are supported: legacy and
+   preferred.  Firmware package names are placed in a CMS signed
+   attribute, not in the firmware package itself.
+
+   Legacy firmware package names are simply octet strings, and no
+   structure is assumed.  This firmware package name form is supported
+   in order to facilitate existing configuration management systems.  We
+   assume that the firmware signer and the bootstrap loader will
+   understand any internal structure to the octet string.  In
+   particular, given two legacy firmware package names, we assume that
+   the firmware signer and the bootstrap loader will be able to
+   determine which one represents the newer version of the firmware
+   package.  This capability is necessary to implement the stale version
+   feature.  If a firmware package with a disastrous flaw is released,
+   subsequent firmware package versions MAY designate a stale legacy
+   firmware package name in order to prevent subsequent rollback to the
+   stale version or versions earlier than the stale version.
+
+   Preferred firmware package names are a combination of the firmware
+   package object identifier and a version number.  A unique object
+   identifier MUST identify the collection of features that characterize
+   the firmware package.  For example, firmware packages for a cable
+   modem and a wireless LAN network interface card warrant distinct
+   object identifiers.  Similarly, firmware packages that implement
+   distinct suites of cryptographic algorithms and modes of operation,
+   or that emulate different (non-programmable) cryptographic devices
+   warrant distinct object identifiers.  The version number MUST
+   identify a particular build or release of the firmware package.  The
+   version number MUST be a monotonically increasing non-negative
+   integer.  Generally, an earlier version is replaced with a later one.
+   If a firmware package with a disastrous flaw is released, subsequent
+   firmware package versions MAY designate a stale version number to
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.
+
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Firmware packages are developed to run on one or more hardware module
+   type.  The firmware package digital signature MUST bind the list of
+   supported hardware module object identifiers to the firmware package.
+
+   In many cases, the firmware package signature will be validated
+   directly with the trust anchor public key, avoiding the need to
+   construct certification paths.  Alternatively, the trust anchor can
+   delegate firmware package signing to another public key through a
+   certification path.  In the latter case, the firmware package SHOULD
+   contain the certificates needed to construct the certification path
+   that begins with a certificate issued by the trust anchors and ends
+   with a certificate issued to the firmware package signer.
+
+   The firmware package MAY contain a list of community identifiers.
+   These identifiers name the hardware modules that are authorized to
+   load the firmware package.  If the firmware package contains a list
+   of community identifiers, then the bootstrap loader MUST reject the
+   firmware package if the hardware module is not a member of one of the
+   identified communities.
+
+   When a hardware module includes multiple programmable components, the
+   firmware package SHOULD contain executable code for all of the
+   components.  Internal tagging within the firmware package MUST tell
+   the bootstrap loader which portion of the overall firmware package is
+   intended for each component; however, this tagging is expected to be
+   specific to each hardware module.  Because this specification treats
+   the firmware package as an opaque binary object, the format of the
+   firmware package is beyond the scope of this specification.
+
+1.2.3.  Bootstrap Loader Requirements
+
+   The bootstrap loader MUST have access to a physical interface and any
+   related driver or protocol software necessary to obtain a firmware
+   package.  The same interface SHOULD be used to deliver receipts and
+   error reports.  Details of the physical interface as well as the
+   driver or protocol software are beyond the scope of this
+   specification.
+
+   The bootstrap loader can be a permanent part of the hardware module,
+   or it can be replaced by loading a firmware package.  In Figure 1,
+   the bootstrap loader is implemented as separate logic within the
+   hardware module.  Not all hardware modules will include the ability
+   to replace or update the bootstrap loader, and this specification
+   does not mandate such support.
+
+   If the bootstrap loader can be loaded by a firmware package, an
+   initial bootstrap loader MUST be installed in non-volatile memory
+   prior to deployment.  All bootstrap loaders, including an initial
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   bootstrap loader if one is employed, MUST meet the requirements in
+   this section.  However, the firmware package containing the bootstrap
+   loader MAY also contain other routines.
+
+   The bootstrap loader requires access to cryptographic routines.
+   These routines can be implemented specifically for the bootstrap
+   loader, or they can be shared with other hardware module features.
+   The bootstrap loader MUST have access to a one-way hash function and
+   digital signature verification routines to validate the digital
+   signature on the firmware package and to validate the certification
+   path for the firmware-signing certificate.
+
+   If firmware packages are encrypted, the bootstrap loader MUST have
+   access to a decryption routine.  Access to a corresponding encryption
+   function is not required, since hardware modules need not be capable
+   of generating firmware packages.  Because some symmetric encryption
+   algorithm implementations (such as AES [AES]) employ separate logic
+   for encryption and decryption, some hardware module savings might
+   result.
+
+   If firmware packages are compressed, the bootstrap loader MUST also
+   have access to a decompression function.  This function can be
+   implemented specifically for the bootstrap loader, or it can be
+   shared with other hardware module features.  Access to a
+   corresponding compression function is not required, since hardware
+   modules need not be capable of generating firmware packages.
+
+   If the optional receipt generation or error report capability is
+   supported, the bootstrap loader MUST have access to the hardware
+   module serial number and the object identifier for the hardware
+   module type.  If the optional signed receipt generation or signed
+   error report capability is supported, the bootstrap loader MUST also
+   have access to a one-way hash function and digital signature
+   routines, the hardware module private signing key, and the
+   corresponding signature validation certificate or its designator.
+
+   The bootstrap loader requires access to one or more trusted public
+   keys, called trust anchors, to validate the firmware package digital
+   signature.  One or more trust anchors MUST be installed in non-
+   volatile memory prior to deployment.  The bootstrap loader MUST
+   reject a firmware package if it cannot validate the signature, which
+   MAY require the construction of a valid certification path from the
+   firmware-signing certificate to one of the trust anchors [PROFILE].
+   However, in many cases, the firmware package signature will be
+   validated directly with the trust anchor public key, avoiding the
+   need to construct certification paths.
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The bootstrap loader MUST reject a firmware package if the list of
+   supported hardware module type identifiers within the firmware
+   package does not include the object identifier of the hardware
+   module.
+
+   The bootstrap loader MUST reject a firmware package if the firmware
+   package includes a list of community identifiers and the hardware
+   module is not a member of one of the listed communities.  The means
+   of determining community membership is beyond the scope of this
+   specification.
+
+   The bootstrap loader MUST reject a firmware package if it cannot
+   successfully decrypt the firmware package using the firmware-
+   decryption key available to the hardware module.  The firmware
+   package contains an identifier of the firmware-decryption key needed
+   for decryption.
+
+   When an earlier version of a firmware package is replacing a later
+   one, the bootstrap loader SHOULD generate a warning.  The manner in
+   which a warning is generated is highly dependent on the hardware
+   module and the environment in which it is being used.  If a firmware
+   package with a disastrous flaw is released and subsequent firmware
+   package versions designate a stale version, the bootstrap loader
+   SHOULD prevent loading of the stale version and versions earlier than
+   the stale version.
+
+1.2.3.1.  Legacy Stale Version Processing
+
+   In case a firmware package with a disastrous flaw is released,
+   subsequent firmware package versions that employ the legacy firmware
+   package name form MAY include a stale legacy firmware package name to
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.  As described in the Security Considerations
+   section of this document, the inclusion of a stale legacy firmware
+   package name in a firmware package cannot completely prevent
+   subsequent use of the stale firmware package.  However, many hardware
+   modules are expected to have very few firmware packages written for
+   them, allowing the stale firmware package version feature to provide
+   important protections.
+
+   Non-volatile storage for stale version numbers is needed.  The number
+   of stale legacy firmware package names that can be stored depends on
+   the amount of storage that is available.  When a firmware package is
+   loaded and it contains a stale legacy firmware package name, then it
+   SHOULD be added to a list kept in non-volatile storage.  When
+   subsequent firmware packages are loaded, the legacy firmware package
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   name of the new package is compared to the list in non-volatile
+   storage.  If the legacy firmware package name represents the same
+   version or an older version of a member of the list, then the new
+   firmware packages SHOULD be rejected.
+
+   The amount of non-volatile storage that needs to be dedicated to
+   saving legacy firmware package names and stale legacy firmware
+   packages names depends on the number of firmware packages that are
+   likely to be developed for the hardware module.
+
+1.2.3.2.  Preferred Stale Version Processing
+
+   If a firmware package with a disastrous flaw is released, subsequent
+   firmware package versions that employ preferred firmware package name
+   form MAY include a stale version number to prevent subsequent
+   rollback to the stale version or versions earlier than the stale
+   version.  As described in the Security Considerations section of this
+   document, the inclusion of a stale version number in a firmware
+   package cannot completely prevent subsequent use of the stale
+   firmware package.  However, many hardware modules are expected to
+   have very few firmware packages written for them, allowing the stale
+   firmware package version feature to provide important protections.
+
+   Non-volatile storage for stale version numbers is needed.  The number
+   of stale version numbers that can be stored depends on the amount of
+   storage that is available.  When a firmware package is loaded and it
+   contains a stale version number, then the object identifier of the
+   firmware package and the stale version number SHOULD be added to a
+   list that is kept in non-volatile storage.  When subsequent firmware
+   packages are loaded, the object identifier and version number of the
+   new package are compared to the list in non-volatile storage.  If the
+   object identifier matches and the version number is less than or
+   equal to the stale version number, then the new firmware packages
+   SHOULD be rejected.
+
+   The amount of non-volatile storage that needs to be dedicated to
+   saving firmware package identifiers and stale version numbers depends
+   on the number of firmware packages that are likely to be developed
+   for the hardware module.
+
+1.2.4.  Trust Anchors
+
+   A trust anchor MUST consist of a public key signature algorithm and
+   an associated public key, which MAY optionally include parameters.  A
+   trust anchor MUST also include a public key identifier.  A trust
+   anchor MAY also include an X.500 distinguished name.
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The trust anchor public key is used in conjunction with the signature
+   validation algorithm in two different ways.  First, the trust anchor
+   public key is used directly to validate the firmware package
+   signature.  Second, the trust anchor public key is used to validate
+   an X.509 certification path, and then the subject public key in the
+   final certificate in the certification path is used to validate the
+   firmware package signature.
+
+   The public key names the trust anchor, and each public key has a
+   public key identifier.  The public key identifier identifies the
+   trust anchor as the signer when it is used directly to validate
+   firmware package signatures.  This key identifier can be stored with
+   the trust anchor, or it can be computed from the public key whenever
+   needed.
+
+   The optional trusted X.500 distinguished name MUST be present in
+   order for the trust anchor public key to be used to validate an X.509
+   certification path.  Without an X.500 distinguished name,
+   certification path construction cannot use the trust anchor.
+
+1.2.5.  Cryptographic and Compression Algorithm Requirements
+
+   A firmware package for a cryptographic hardware module includes
+   cryptographic algorithm implementations.  In addition, a firmware
+   package for a non-cryptographic hardware module will likely include
+   cryptographic algorithm implementations to support the bootstrap
+   loader in the validation of firmware packages.
+
+   A unique algorithm object identifier MUST be assigned for each
+   cryptographic algorithm and mode implemented by a firmware package.
+   A unique algorithm object identifier MUST also be assigned for each
+   compression algorithm implemented by a firmware package.  The
+   algorithm object identifiers can be used to determine whether a
+   particular firmware package satisfies the needs of a particular
+   application.  To facilitate the development of algorithm-agile
+   applications, the cryptographic module interface SHOULD allow
+   applications to query the cryptographic module for the object
+   identifiers associated with each cryptographic algorithm contained in
+   the currently loaded firmware package.  Applications SHOULD also be
+   able to query the cryptographic module to determine attributes
+   associated with each algorithm.  Such attributes might include the
+   algorithm type (symmetric encryption, asymmetric encryption, key
+   agreement, one-way hash function, digital signature, and so on), the
+   algorithm block size or modulus size, and parameters for asymmetric
+   algorithms.  This specification does not establish the conventions
+   for the retrieval of algorithm identifiers or algorithm attributes.
+
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+1.3.  Hardware Module Security Architecture
+
+   The bootstrap loader MAY be permanently stored in read-only memory or
+   separately loaded into non-volatile memory as discussed above.
+
+   In most hardware module designs, the firmware package execution
+   environment offers a single address space.  If it does, the firmware
+   package SHOULD contain a complete firmware package load for the
+   hardware module.  In this situation, the firmware package does not
+   contain a partial or incremental set of functions.  A complete
+   firmware package load will minimize complexity and avoid potential
+   security problems.  From a complexity perspective, the incremental
+   loading of packages makes it necessary for each package to identify
+   any other packages that are required (its dependencies), and the
+   bootstrap loader needs to verify that all of the dependencies are
+   satisfied before attempting to execute the firmware package.  When a
+   hardware module is based on a general purpose processor or a digital
+   signal processor, it is dangerous to allow arbitrary packages to be
+   loaded simultaneously unless there is a reference monitor to ensure
+   that independent portions of the code cannot interfere with one
+   another.  Also, it is difficult to evaluate arbitrary combinations of
+   software modules [SECREQMTS].  For these reasons, a complete firmware
+   package load is RECOMMENDED; however, this specification allows the
+   firmware signer to identify dependencies between firmware packages in
+   order to handle all situations.
+
+   The firmware packages MAY have dependencies on routines provided by
+   other firmware packages.  To minimize the security evaluation
+   complexity of a hardware module employing such a design, the firmware
+   package MUST identify the package identifiers (and the minimum
+   version numbers when the preferred firmware package name form is
+   used) of the packages upon which it depends.  The bootstrap loader
+   MUST reject a firmware package load if it contains a dependency on a
+   firmware package that is not available.
+
+   Loading a firmware package can impact the satisfactory resolution of
+   dependencies of other firmware packages that are already part of the
+   hardware module configuration.  For this reason, the bootstrap loader
+   MUST reject the loading of a firmware package if the dependencies of
+   any firmware package in the resulting configurations will be
+   unsatisfied.
+
+1.4.  ASN.1 Encoding
+
+   The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88,
+   X.209-88].  ASN.1 is a formal notation used for describing data
+   protocols, regardless of the programming language used by the
+   implementation.  Encoding rules describe how the values defined in
+
+
+
+Housley                     Standards Track                    [Page 14]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   ASN.1 will be represented for transmission.  The Basic Encoding Rules
+   (BER) are the most widely employed rule set, but they offer more than
+   one way to represent data structures.  For example, definite length
+   encoding and indefinite length encoding are supported.  This
+   flexibility is not desirable when digital signatures are used.  As a
+   result, the Distinguished Encoding Rules (DER) [X.509-88] were
+   invented.  DER is a subset of BER that ensures a single way to
+   represent a given value.  For example, DER always employs definite
+   length encoding.
+
+   In this specification, digitally signed structures MUST be encoded
+   with DER.  Other structures do not require DER, but the use of
+   definite length encoding is strongly RECOMMENDED.  By always using
+   definite length encoding, the bootstrap loader will have fewer
+   options to implement.  In situations where there is very high
+   confidence that only definite length encoding will be used, support
+   for indefinite length decoding MAY be omitted.
+
+1.5.  Protected Firmware Package Loading
+
+   This document does not attempt to specify a physical interface, any
+   related driver software, or a protocol necessary for loading firmware
+   packages.  Many different delivery mechanisms are envisioned,
+   including portable memory devices, file transfer, and web pages.
+   Section 2 of this specification defines the format that MUST be
+   presented to the hardware module regardless of the interface that is
+   used.  This specification also specifies the format of the response
+   that MAY be generated by the hardware module.  Section 3 of this
+   specification defines the format that MAY be returned by the hardware
+   module when a firmware package loads successfully.  Section 4 of this
+   specification defines the format that MAY be returned by the hardware
+   module when a firmware package load is unsuccessful.  The firmware
+   package load receipts and firmware package load error reports can be
+   either signed or unsigned.
+
+2.  Firmware Package Protection
+
+   The Cryptographic Message Syntax (CMS) is used to protect a firmware
+   package, which is treated as an opaque binary object.  A digital
+   signature is used to protect the firmware package from undetected
+   modification and to provide data origin authentication.  Encryption
+   is optionally used to protect the firmware package from disclosure,
+   and compression is optionally used to reduce the size of the
+   protected firmware package.  The CMS ContentInfo content type MUST
+   always be present, and it MUST encapsulate the CMS SignedData content
+   type.  If the firmware package is encrypted, then the CMS SignedData
+   content type MUST encapsulate the CMS EncryptedData content type.  If
+   the firmware package is compressed, then either the CMS SignedData
+
+
+
+Housley                     Standards Track                    [Page 15]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   content type (when encryption is not used) or the CMS EncryptedData
+   content type (when encryption is used) MUST encapsulate the CMS
+   CompressedData content type.  Finally, (1) the CMS SignedData content
+   type (when neither encryption nor compression is used), (2) the CMS
+   EncryptedData content type (when encryption is used, but compression
+   is not), or (3) the CMS CompressedData content type (when compression
+   is used) MUST encapsulate the simple firmware package using the
+   FirmwarePkgData content type defined in this specification (see
+   Section 2.1.5).
+
+   The firmware package protection is summarized as follows (see [CMS]
+   for the full syntax):
+
+      ContentInfo {
+        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+        content              SignedData
+      }
+
+      SignedData {
+        version              CMSVersion, -- always set to 3
+        digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+        encapContentInfo     EncapsulatedContentInfo,
+        certificates         CertificateSet, -- Signer cert. path
+        crls                 CertificateRevocationLists, -- Optional
+        signerInfos          SET OF SignerInfo -- Only one
+      }
+
+      SignerInfo {
+        version              CMSVersion, -- always set to 3
+        sid                  SignerIdentifier,
+        digestAlgorithm      DigestAlgorithmIdentifier,
+        signedAttrs          SignedAttributes, -- Required
+        signatureAlgorithm   SignatureAlgorithmIdentifier,
+        signature            SignatureValue,
+        unsignedAttrs        UnsignedAttributes -- Optional
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 16]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      EncapsulatedContentInfo {
+        eContentType         id-encryptedData, -- (1.2.840.113549.1.7.6)
+                             -- OR --
+                             id-ct-compressedData,
+                                       -- (1.2.840.113549.1.9.16.1.9)
+                             -- OR --
+                             id-ct-firmwarePackage,
+                                       -- (1.2.840.113549.1.9.16.1.16)
+        eContent             OCTET STRING
+      }                            -- Contains EncryptedData OR
+                                   -- CompressedData OR
+                                   -- FirmwarePkgData
+
+      EncryptedData {
+        version              CMSVersion, -- Always set to 0
+        encryptedContentInfo EncryptedContentInfo,
+        unprotectedAttrs     UnprotectedAttributes -- Omit
+      }
+
+      EncryptedContentInfo {
+        contentType          id-ct-compressedData,
+                                       -- (1.2.840.113549.1.9.16.1.9)
+                             -- OR --
+                             id-ct-firmwarePackage,
+                                       -- (1.2.840.113549.1.9.16.1.16)
+        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
+        encryptedContent OCTET STRING
+      }                                -- Contains CompressedData OR
+                                       -- FirmwarePkgData
+
+      CompressedData {
+        version              CMSVersion, -- Always set to 0
+        compressionAlgorithm CompressionAlgorithmIdentifier,
+        encapContentInfo     EncapsulatedContentInfo
+      }
+
+      EncapsulatedContentInfo {
+        eContentType         id-ct-firmwarePackage,
+                                         -- (1.2.840.113549.1.9.16.1.16)
+        eContent             OCTET STRING -- Contains FirmwarePkgData
+      }
+
+      FirmwarePkgData         OCTET STRING -- Contains firmware package
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 17]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.  Firmware Package Protection CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo,
+   SignedData, EncryptedData, and CompressedData content types.  It also
+   defines the FirmwarePkgData content type.
+
+2.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+      contentType indicates the type of the associated content, and in
+         this case, the encapsulated type is always SignedData.  The
+         id-signedData (1.2.840.113549.1.7.2) object identifier MUST be
+         present in this field.
+
+      content holds the associated content, and in this case, the
+         content field MUST contain SignedData.
+
+2.1.2.  SignedData
+
+   The SignedData content type [CMS] contains the signed firmware
+   package (which might be compressed, encrypted, or compressed and then
+   encrypted prior to signature), the certificates needed to validate
+   the signature, and one digital signature value.  The fields of
+   SignedData are used as follows:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 3.
+
+   digestAlgorithms is a collection of message digest algorithm
+      identifiers, and in this case, it MUST contain a single message
+      digest algorithm identifier.  The message digest algorithm
+      employed by the firmware package signer MUST be present.
+
+   encapContentInfo contains the signed content, consisting of a content
+      type identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      2.1.2.2.
+
+   certificates is an optional collection of certificates.  If the trust
+      anchor signed the firmware package directly, then certificates
+      SHOULD be omitted.  If it did not, then certificates SHOULD
+      include the X.509 certificate of the firmware package signer.  The
+      set of certificates SHOULD be sufficient for the bootstrap loader
+      to construct a certification path from the trust anchor to the
+      firmware-signer's certificate.  PKCS#6 extended certificates
+
+
+
+
+Housley                     Standards Track                    [Page 18]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      [PKCS#6] and attribute certificates (either version 1 or
+      version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in
+      the set of certificates.
+
+   crls is an optional collection of certificate revocation lists
+      (CRLs), and in this case, CRLs SHOULD NOT be included by the
+      firmware package signer.  It is anticipated that firmware packages
+      may be generated, signed, and made available in repositories for
+      downloading into hardware modules.  In such contexts, it would be
+      difficult for the firmware package signer to include timely CRLs
+      in the firmware package.  However, because the CRLs are not
+      covered by the signature, timely CRLs MAY be inserted by some
+      other party before the firmware package is delivered to the
+      hardware module.
+
+   signerInfos is a collection of per-signer information, and in this
+      case, the collection MUST contain exactly one SignerInfo.  The use
+      of the SignerInfo type is discussed further in Section 2.1.2.1.
+
+2.1.2.1.  SignerInfo
+
+   The firmware package signer is represented in the SignerInfo type.
+   The fields of SignerInfo are used as follows:
+
+   version is the syntax version number, and it MUST be 3.
+
+   sid identifies the signer's public key.  CMS supports two
+      alternatives: issuerAndSerialNumber and subjectKeyIdentifier.
+      However, the bootstrap loader MUST support the
+      subjectKeyIdentifier alternative, which identifies the signer's
+      public key directly.  When this public key is contained in a
+      certificate, this identifier SHOULD appear in the X.509
+      subjectKeyIdentifier extension.
+
+   digestAlgorithm identifies the message digest algorithm, and any
+      associated parameters, used by the firmware package signer.  It
+      MUST contain the message digest algorithms employed by the
+      firmware package signer.  (Note that this message digest algorithm
+      identifier MUST be the same as the one carried in the
+      digestAlgorithms value in SignedData.)
+
+   signedAttrs is an optional collection of attributes that are signed
+      along with the content.  The signedAttrs are optional in the CMS,
+      but in this specification, signedAttrs are REQUIRED for the
+      firmware package; however, implementations MUST ignore
+      unrecognized signed attributes.  The SET OF attributes MUST be DER
+
+
+
+
+
+Housley                     Standards Track                    [Page 19]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      encoded [X.509-88].  Section 2.2 of this document lists the
+      attributes that MUST be included in the collection; other
+      attributes MAY be included as well.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used by the firmware package signer to
+      generate the digital signature.
+
+   signature is the digital signature value.
+
+   unsignedAttrs is an optional SET of attributes that are not signed.
+      As described in Section 2.3, this set can only contain a single
+      instance of the wrapped-firmware-decryption-key attribute and no
+      others.
+
+2.1.2.2.  EncapsulatedContentInfo
+
+   The EncapsulatedContentInfo content type encapsulates the firmware
+   package, which might be compressed, encrypted, or compressed and then
+   encrypted prior to signature.  The firmware package, in any of these
+   formats, is carried within the EncapsulatedContentInfo type.  The
+   fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, the value MUST be id-encryptedData
+      (1.2.840.113549.1.7.6), id-ct-compressedData
+      (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
+      (1.2.840.113549.1.9.16.1.16).  When eContentType contains id-
+      encryptedData, the firmware package was encrypted prior to
+      signing, and may also have been compressed prior to encryption.
+      When it contains id-ct-compressedData, the firmware package was
+      compressed prior to signing, but was not encrypted.  When it
+      contains id-ct-firmwarePackage, the firmware package was not
+      compressed or encrypted prior to signing.
+
+   eContent contains the signed firmware package, which might also be
+      encrypted, compressed, or compressed and then encrypted, prior to
+      signing.  The content is encoded as an octet string.  The eContent
+      octet string need not be DER encoded.
+
+2.1.3.  EncryptedData
+
+   The EncryptedData content type [CMS] contains the encrypted firmware
+   package (which might be compressed prior to encryption).  However, if
+   the firmware package was not encrypted, the EncryptedData content
+   type is not present.  The fields of EncryptedData are used as
+   follows:
+
+
+
+
+Housley                     Standards Track                    [Page 20]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   version is the syntax version number, and in this case, version MUST
+      be 0.
+
+   encryptedContentInfo is the encrypted content information.  The use
+      of the EncryptedContentInfo type is discussed further in Section
+      2.1.3.1.
+
+   unprotectedAttrs is an optional collection of unencrypted attributes,
+      and in this case, unprotectedAttrs MUST NOT be present.
+
+2.1.3.1.  EncryptedContentInfo
+
+   The encrypted firmware package, which might be compressed prior to
+   encryption, is encapsulated in the EncryptedContentInfo type.  The
+   fields of EncryptedContentInfo are used as follows:
+
+   contentType indicates the type of content, and in this case, it MUST
+      contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or
+      id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).  When it
+      contains id-ct-compressedData, then the firmware package was
+      compressed prior to encryption.  When it contains id-ct-
+      firmwarePackage, then the firmware package was not compressed
+      prior to encryption.
+
+   contentEncryptionAlgorithm identifies the firmware-encryption
+      algorithm, and any associated parameters, used to encrypt the
+      firmware package.
+
+   encryptedContent is the result of encrypting the firmware package.
+      The field is optional; however, in this case, it MUST be present.
+
+2.1.4.  CompressedData
+
+   The CompressedData content type [COMPRESS] contains the compressed
+   firmware package.  If the firmware package was not compressed, then
+   the CompressedData content type is not present.  The fields of
+   CompressedData are used as follows:
+
+   version is the syntax version number; in this case, it MUST be 0.
+
+   compressionAlgorithm identifies the compression algorithm, and any
+      associated parameters, used to compress the firmware package.
+
+   encapContentInfo is the compressed content, consisting of a content
+      type identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      2.1.4.1.
+
+
+
+
+Housley                     Standards Track                    [Page 21]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.4.1.  EncapsulatedContentInfo
+
+   The CompressedData content type encapsulates the compressed firmware
+   package, and it is carried within the EncapsulatedContentInfo type.
+   The fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwarePackage (1.2.840.113549.1.9.16.1.16).
+
+   eContent is the compressed firmware package, encoded as an octet
+      string.  The eContent octet string need not be DER encoded.
+
+2.1.5.  FirmwarePkgData
+
+   The FirmwarePkgData content type contains the firmware package.  It
+   is a straightforward encapsulation in an octet string, and it need
+   not be DER encoded.
+
+   The FirmwarePkgData content type is identified by the id-ct-
+   firmwarePackage object identifier:
+
+      id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 16 }
+
+   The FirmwarePkgData content type is a simple octet string:
+
+      FirmwarePkgData ::= OCTET STRING
+
+2.2.  Signed Attributes
+
+   The firmware package signer MUST digitally sign a collection of
+   attributes along with the firmware package.  Each attribute in the
+   collection MUST be DER encoded [X.509-88].  The syntax for attributes
+   is defined in [CMS], but it is repeated here for convenience:
+
+      Attribute ::= SEQUENCE {
+        attrType OBJECT IDENTIFIER,
+        attrValues SET OF AttributeValue }
+
+      AttributeValue ::= ANY
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+
+
+
+
+Housley                     Standards Track                    [Page 22]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attribute.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The firmware package signer MUST include the following four
+   attributes: content-type, message-digest, firmware-package-
+   identifier, and target-hardware-module-identifiers.
+
+   If the firmware package is encrypted, then the firmware package
+   signer MUST also include the decrypt-key-identifier attribute.
+
+   If the firmware package implements cryptographic algorithms, then the
+   firmware package signer MAY also include the implemented-crypto-
+   algorithms attribute.  Similarly, if the firmware package implements
+   compression algorithms, then the firmware package signer MAY also
+   include the implemented-compress-algorithms attribute.
+
+   If the firmware package is intended for use only by specific
+   communities, then the firmware package signer MUST also include the
+   community-identifiers attribute.
+
+   If the firmware package depends on the presence of one or more other
+   firmware packages to operate properly, then the firmware package
+   signer SHOULD also include the firmware-package-info attribute.  For
+   example, the firmware-package-info attribute dependencies field might
+   indicate that the firmware package contains a dependency on a
+   particular bootstrap loader or separation kernel.
+
+   The firmware package signer SHOULD also include the three following
+   attributes: firmware-package-message-digest, signing-time, and
+   content-hints.  Additionally, if the firmware package signer has a
+   certificate (meaning that the firmware package signer is not always
+   configured as a trust anchor), then the firmware package signer
+   SHOULD also include the signing-certificate attribute.
+
+   The firmware package signer MAY include any other attribute that it
+   deems appropriate.
+
+2.2.1.  Content Type
+
+   The firmware package signer MUST include a content-type attribute
+   with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-
+   compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
+   (1.2.840.113549.1.9.16.1.16).  When it contains id-encryptedData, the
+   firmware package was encrypted prior to signing.  When it contains
+   id-ct-compressedData, the firmware package was compressed prior to
+   signing, but was not encrypted.  When it contains
+
+
+
+
+Housley                     Standards Track                    [Page 23]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   id-ct-firmwarePackage, the firmware package was not compressed or
+   encrypted prior to signing.  Section 11.1 of [CMS] defines the
+   content-type attribute.
+
+2.2.2.  Message Digest
+
+   The firmware package signer MUST include a message-digest attribute,
+   having as its value the message digest computed on the
+   encapContentInfo eContent octet string, as defined in Section
+   2.1.2.2.  This octet string contains the firmware package, and it MAY
+   be compressed, encrypted, or both compressed and encrypted.  Section
+   11.2 of [CMS] defines the message-digest attribute.
+
+2.2.3.  Firmware Package Identifier
+
+   The firmware-package-identifier attribute names the protected
+   firmware package.  Two approaches to naming firmware packages are
+   supported:  legacy and preferred.  The firmware package signer MUST
+   include a firmware-package-identifier attribute using one of these
+   name forms.
+
+   A legacy firmware package name is an octet string, and no structure
+   within the octet string is assumed.
+
+   A preferred firmware package name is a combination of an object
+   identifier and a version number.  The object identifier names a
+   collection of functions implemented by the firmware package, and the
+   version number is a non-negative integer that identifies a particular
+   build or release of the firmware package.
+
+   If a firmware package with a disastrous flaw is released, the
+   firmware package that repairs the previously distributed flaw MAY
+   designate a stale firmware package version to prevent the reloading
+   of the flawed version.  The hardware module bootstrap loader SHOULD
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.  When the legacy firmware package name form
+   is used, the stale version is indicated by a stale legacy firmware
+   package name, which is an octet string.  We assume that the firmware
+   package signer and the bootstrap loader can determine whether a given
+   legacy firmware package name represents a version that is more recent
+   than the stale one.  When the preferred firmware package name form is
+   used, the stale version is indicated by a stale version number, which
+   is an integer.
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 24]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the firmware-package-
+   identifier attribute:
+
+      id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 35 }
+
+   The firmware-package-identifier attribute values have ASN.1 type
+   FirmwarePackageIdentifier:
+
+      FirmwarePackageIdentifier ::= SEQUENCE {
+        name PreferredOrLegacyPackageIdentifier,
+        stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+      PreferredOrLegacyPackageIdentifier ::= CHOICE {
+        preferred PreferredPackageIdentifier,
+        legacy OCTET STRING }
+
+      PreferredPackageIdentifier ::= SEQUENCE {
+        fwPkgID OBJECT IDENTIFIER,
+        verNum INTEGER (0..MAX) }
+
+      PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+        preferredStaleVerNum INTEGER (0..MAX),
+        legacyStaleVersion OCTET STRING }
+
+2.2.4.  Target Hardware Module Identifiers
+
+   The target-hardware-module-identifiers attribute names the types of
+   hardware modules that the firmware package supports.  A unique object
+   identifier names each supported hardware model type and revision.
+
+   The bootstrap loader MUST reject the firmware package if its own
+   hardware module type identifier is not listed in the target-
+   hardware-module-identifiers attribute.
+
+   The following object identifier identifies the target-hardware-
+   module-identifiers attribute:
+
+      id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 36 }
+
+   The target-hardware-module-identifiers attribute values have ASN.1
+   type TargetHardwareIdentifiers:
+
+      TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+
+
+Housley                     Standards Track                    [Page 25]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.5.  Decrypt Key Identifier
+
+   The decrypt-key-identifier attribute names the symmetric key needed
+   to decrypt the encapsulated firmware package.  The CMS EncryptedData
+   content type is used when the firmware package is encrypted.  The
+   decrypt-key-identifier signed attribute is carried in the SignedData
+   content type that encapsulates EncryptedData content type, naming the
+   symmetric key needed to decrypt the firmware package.  No particular
+   structure is imposed on the key identifier.  The means by which the
+   firmware-decryption key is securely distributed to all modules that
+   are authorized to use the associated firmware package is beyond the
+   scope of this specification; however, an optional mechanism for
+   securely distributing the firmware-decryption key with the firmware
+   package is specified in Section 2.3.1.
+
+   The following object identifier identifies the decrypt-key-identifier
+   attribute:
+
+      id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 37 }
+
+   The decrypt-key-identifier attribute values have ASN.1 type
+   DecryptKeyIdentifier:
+
+      DecryptKeyIdentifier ::= OCTET STRING
+
+2.2.6.  Implemented Crypto Algorithms
+
+   The implemented-crypto-algorithms attribute MAY be present in the
+   SignedAttributes, and it names the cryptographic algorithms that are
+   implemented by the firmware package and available to applications.
+   Only those algorithms that are made available at the interface of the
+   cryptographic module are listed.  Any cryptographic algorithm that is
+   used internally and is not accessible via the cryptographic module
+   interface MUST NOT be listed.  For example, if the firmware package
+   implements the decryption algorithm for future firmware package
+   installations and this algorithm is not made available for other
+   uses, then the firmware-decryption algorithm would not be listed.
+
+   The object identifier portion of AlgorithmIdentifier identifies an
+   algorithm and its mode of use.  No algorithm parameters are included.
+   Cryptographic algorithms include traffic-encryption algorithms, key-
+   encryption algorithms, key transport algorithms, key agreement
+   algorithms, one-way hash algorithms, and digital signature
+   algorithms.  Cryptographic algorithms do not include compression
+   algorithms.
+
+
+
+
+Housley                     Standards Track                    [Page 26]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the implemented-crypto-
+   algorithms attribute:
+
+      id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 38 }
+
+   The implemented-crypto-algorithms attribute values have ASN.1 type
+   ImplementedCryptoAlgorithms:
+
+      ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.7.  Implemented Compression Algorithms
+
+   The implemented-compress-algorithms attribute MAY be present in the
+   SignedAttributes, and it names the compression algorithms that are
+   implemented by the firmware package and available to applications.
+   Only those algorithms that are made available at the interface of the
+   hardware module are listed.  Any compression algorithm that is used
+   internally and is not accessible via the hardware module interface
+   MUST NOT be listed.  For example, if the firmware package implements
+   a decompression algorithm for future firmware package installations
+   and this algorithm is not made available for other uses, then the
+   firmware-decompression algorithm would not be listed.
+
+   The object identifier portion of AlgorithmIdentifier identifies a
+   compression algorithm.  No algorithm parameters are included.
+
+   The following object identifier identifies the implemented-compress-
+   algorithms attribute:
+
+      id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 43 }
+
+   The implemented-compress-algorithms attribute values have ASN.1 type
+   ImplementedCompressAlgorithms:
+
+      ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.8.  Community Identifiers
+
+   If present in the SignedAttributes, the community-identifiers
+   attribute names the communities that are permitted to execute the
+   firmware package.  The bootstrap loader MUST reject the firmware
+   package if the hardware module is not a member of one of the
+   identified communities.  The means of assigning community membership
+   is beyond the scope of this specification.
+
+
+
+Housley                     Standards Track                    [Page 27]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The community-identifiers attributes names the authorized communities
+   by a list of community object identifiers, by a list of specific
+   hardware modules, or by a combination of the two lists.  A specific
+   hardware module is specified by the combination of the hardware
+   module identifier (as defined in Section 2.2.4) and a serial number.
+   To facilitate compact representation of serial numbers, a contiguous
+   block can be specified by the lowest authorized serial number and the
+   highest authorized serial number.  Alternatively, all of the serial
+   numbers associated with a hardware module family identifier can be
+   specified with the NULL value.
+
+   If the bootstrap loader does not have a mechanism for obtaining a
+   list of object identifiers that identify the communities to which the
+   hardware module is a member, then the bootstrap loader MUST behave as
+   though the list is empty.  Similarly, if the bootstrap loader does
+   not have access to the hardware module serial number, then the
+   bootstrap loader MUST behave as though the hardware module is not
+   included on the list of authorized hardware modules.
+
+   The following object identifier identifies the community-identifiers
+   attribute:
+
+      id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 40 }
+
+   The community-identifiers attribute values have ASN.1 type
+   CommunityIdentifiers:
+
+      CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+      CommunityIdentifier ::= CHOICE {
+        communityOID OBJECT IDENTIFIER,
+        hwModuleList HardwareModules }
+
+      HardwareModules ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+      HardwareSerialEntry ::= CHOICE {
+        all NULL,
+        single OCTET STRING,
+        block SEQUENCE {
+          low OCTET STRING,
+          high OCTET STRING } }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 28]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.9.  Firmware Package Information
+
+   If a hardware module supports more than one type of firmware package,
+   then the firmware package signer SHOULD include the firmware-
+   package-info attribute with a populated fwPkgType field to identify
+   the firmware package type.  This value can aid the bootstrap loader
+   in the correct placement of the firmware package within the hardware
+   module.  The firmware package type is an INTEGER, and the meaning of
+   the integer value is specific to each hardware module.  For example,
+   a hardware module could assign different integer values for a
+   bootstrap loader, a separation kernel, and an application.
+
+   Some hardware module architectures permit one firmware package to use
+   routines provided by another.  If the firmware package contains a
+   dependency on another, then the firmware package signer SHOULD also
+   include the firmware-package-info attribute with a populated
+   dependencies field.  If the firmware package does not depend on any
+   other firmware packages, then the firmware package signer MUST NOT
+   include the firmware-package-info attribute with a populated
+   dependencies field.
+
+   Firmware package dependencies are identified by the firmware package
+   identifier or by information contained in the firmware package
+   itself, and in either case the bootstrap loader ensures that the
+   dependencies are met.  The bootstrap loader MUST reject a firmware
+   package load if it identifies a dependency on a firmware package that
+   is not already loaded.  Also, the bootstrap loader MUST reject a
+   firmware package load if the action will result in a configuration
+   where the dependencies of an already loaded firmware package will no
+   longer be satisfied.  As described in Section 2.2.3, two approaches
+   to naming firmware packages are supported: legacy and preferred.
+   When the legacy firmware package name form is used, the dependency is
+   indicated by a legacy firmware package name.  We assume that the
+   firmware package signer and the bootstrap loader can determine
+   whether a given legacy firmware package name represents the named
+   version of an acceptable newer version.  When the preferred firmware
+   package name form is used, an object identifier and an integer are
+   provided.  The object identifier MUST exactly match the object
+   identifier portion of a preferred firmware package name associated
+   with a firmware package that is already loaded, and the integer MUST
+   be less than or equal to the integer portion of the preferred
+   firmware package name associated with the same firmware package.
+   That is, the dependency specifies the minimum value of the version
+   that is acceptable.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 29]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the firmware-package-info
+   attribute:
+
+      id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 42 }
+
+   The firmware-package-info attribute values have ASN.1 type
+   FirmwarePackageInfo:
+
+      FirmwarePackageInfo ::= SEQUENCE {
+        fwPkgType INTEGER OPTIONAL,
+        dependencies SEQUENCE OF
+          PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+2.2.10.  Firmware Package Message Digest
+
+   The firmware package signer SHOULD include a firmware-package-
+   message-digest attribute, which provides the message digest algorithm
+   and the message digest value computed on the firmware package.  The
+   message digest is computed on the firmware package prior to any
+   compression, encryption, or signature processing.  The bootstrap
+   loader MAY use this message digest to confirm that the intended
+   firmware package has been recovered after all of the layers of
+   encapsulation are removed.
+
+   The following object identifier identifies the firmware-package-
+   message-digest attribute:
+
+      id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 41 }
+
+   The firmware-package-message-digest attribute values have ASN.1 type
+   FirmwarePackageMessageDigest:
+
+      FirmwarePackageMessageDigest ::= SEQUENCE {
+        algorithm AlgorithmIdentifier,
+        msgDigest OCTET STRING }
+
+2.2.11.  Signing Time
+
+   The firmware package signer SHOULD include a signing-time attribute,
+   specifying the time at which the signature was applied to the
+   firmware package.  Section 11.3 of [CMS] defines the signing-time
+   attribute.
+
+
+
+
+
+Housley                     Standards Track                    [Page 30]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.12.  Content Hints
+
+   The firmware package signer SHOULD include a content-hints attribute,
+   including a brief text description of the firmware package.  The text
+   is encoded in UTF-8, which supports most of the world's writing
+   systems [UTF-8].  Section 2.9 of [ESS] defines the content-hints
+   attribute.
+
+   When multiple layers of encapsulation are employed, the content-hints
+   attribute is included in the outermost SignedData to provide
+   information about the innermost content.  In this case, the content-
+   hints attribute provides a brief text description of the firmware
+   package, which can help a person select the correct firmware package
+   when more than one is available.
+
+   When the preferred firmware package name forms are used, the
+   content-hints attribute can provide a linkage to a legacy firmware
+   package name.  This is especially helpful when an existing
+   configuration management system is in use, but the features
+   associated with the preferred firmware package name are deemed
+   useful.  A firmware package name associated with such a configuration
+   management system might look something like
+   "R1234.C0(AJ11).D62.A02.11(b)."  Including these firmware package
+   names in the text description may be helpful to developers by
+   providing a clear linkage between the two name forms.
+
+   The content-hints attribute contains two fields, and in this case,
+   both fields MUST be present.  The fields of ContentHints are used as
+   follows:
+
+   contentDescription provides a brief text description of the firmware
+      package.
+
+   contentType provides the content type of the inner most content type,
+      and in this case, it MUST be id-ct-firmwarePackage
+      (1.2.840.113549.1.9.16.1.16).
+
+2.2.13.  Signing Certificate
+
+   When the firmware-signer's public key is contained in a certificate,
+   the firmware package signer SHOULD include a signing-certificate
+   attribute to identify the certificate that was employed.  However, if
+   the firmware package signature does not have a certificate (meaning
+   that the signature will only be validated with the trust anchor
+   public key), then the firmware package signer is unable to include a
+   signing-certificate attribute.  Section 5.4 of [ESS] defines this
+   attribute.
+
+
+
+
+Housley                     Standards Track                    [Page 31]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The signing-certificate attribute contains two fields: certs and
+   policies.  The certs field MUST be present, and the policies field
+   MAY be present.  The fields of SigningCertificate are used as
+   follows:
+
+   certs contains a sequence of certificate identifiers.  In this case,
+      sequence of certificate identifiers contains a single entry.  The
+      certs field MUST contain only the certificate identifier of the
+      certificate that contains the public key used to verify the
+      firmware package signature.  The certs field uses the ESSCertID
+      syntax specified in Section 5.4 of [ESS], and it is comprised of
+      the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate
+      and, optionally, the certificate issuer and the certificate serial
+      number.  The SHA-1 hash value MUST be present.  The certificate
+      issuer and the certificate serial number SHOULD be present.
+
+   policies is optional; when it is present, it contains a sequence of
+      policy information.  The policies field, when present, MUST
+      contain only one entry, and that entry MUST match one of the
+      certificate policies in the certificate policies extension of the
+      certificate that contains the public key used to verify the
+      firmware package signature.  The policies field uses the
+      PolicyInformation syntax specified in Section 4.2.1.5 of
+      [PROFILE], and it is comprised of the certificate policy object
+      identifier and, optionally, certificate policy qualifiers.  The
+      certificate policy object identifier MUST be present.  The
+      certificate policy qualifiers SHOULD NOT be present.
+
+2.3.  Unsigned Attributes
+
+   CMS allows a SET of unsigned attributes to be included; however, in
+   this specification, the set MUST be absent or include a single
+   instance of the wrapped-firmware-decryption-key attribute.  Because
+   the digital signature does not cover this attribute, it can be
+   altered at any point in the delivery path from the firmware package
+   signer to the hardware module.  This property can be employed to
+   distribute the firmware-decryption key along with an encrypted and
+   signed firmware package, allowing the firmware-decryption key to be
+   wrapped with a different key-encryption key for each link in the
+   distribution chain.
+
+   The syntax for attributes is defined in [CMS], and it is repeated at
+   the beginning of Section 2.2 of this document for convenience.  Each
+   of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+
+
+
+
+Housley                     Standards Track                    [Page 32]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The UnsignedAttributes syntax within signerInfo is defined as a SET
+   OF Attribute.  The UnsignedAttributes MUST include only one instance
+   of any particular attribute.
+
+2.3.1.  Wrapped Firmware Decryption Key
+
+   The firmware package signer, or any other party in the distribution
+   chain, MAY include a wrapped-firmware-decryption-key attribute.
+
+   The following object identifier identifies the wrapped-firmware-
+   decryption-key attribute:
+
+      id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 39 }
+
+   The wrapped-firmware-decryption-key attribute values have ASN.1 type
+   of EnvelopedData.  Section 6 of [CMS] defines the EnvelopedData
+   content type, which is used to construct the value of the attribute.
+   EnvelopedData permits the firmware-decryption key to be protected
+   using symmetric or asymmetric techniques.  The EnvelopedData does not
+   include an encrypted content; rather, the EnvelopedData feature of
+   having the encrypted content in another location is employed.  The
+   encrypted content is found in the eContent field of the EncryptedData
+   structure.  The firmware-decryption key is contained in the
+   recipientInfos field.  Section 6 of [CMS] refers to this key as the
+   content-encryption key.
+
+   The EnvelopedData syntax supports many different key management
+   algorithms.  Four general techniques are supported: key transport,
+   key agreement, symmetric key-encryption keys, and passwords.
+
+   The EnvelopedData content type is profiled for the wrapped-firmware-
+   decryption-key attribute.  The EnvelopedData fields are described
+   fully in Section 6 of [CMS].  Additional rules apply when
+   EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
+
+   Within the EnvelopedData structure, the following apply:
+
+   -  The set of certificates included in OriginatorInfo MUST NOT
+      include certificates with a type of extendedCertificate,
+      v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE].  The
+      optional crls field MAY be present.
+
+   -  The optional unprotectedAttrs field MUST NOT be present.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 33]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Within the EncryptedContentInfo structure, the following apply:
+
+   -  contentType MUST match the content type object identifier carried
+      in the contentType field within the EncryptedContentInfo structure
+      of EncryptedData as described in Section 2.1.3.1.
+
+   -  contentEncryptionAlgorithm identifies the firmware-encryption
+      algorithm, and any associated parameters, used to encrypt the
+      firmware package carried in the encryptedContent field of the
+      EncryptedContentInfo structure of EncryptedData.  Therefore, it
+      MUST exactly match the value of the EncryptedContentInfo structure
+      of EncryptedData as described in Section 2.1.3.1.
+
+   -  encryptedContent is optional, and in this case, it MUST NOT be
+      present.
+
+3.  Firmware Package Load Receipt
+
+   The Cryptographic Message Syntax (CMS) is used to indicate that a
+   firmware package loaded successfully.  Support for firmware package
+   load receipts is OPTIONAL.  However, those hardware modules that
+   choose to generate such receipts MUST follow the conventions
+   specified in this section.  Because not all hardware modules will
+   have private signature keys, the firmware package load receipt can be
+   either signed or unsigned.  Use of the signed firmware package load
+   receipt is RECOMMENDED.
+
+   Hardware modules that support receipt generation MUST have a unique
+   serial number.  Hardware modules that support signed receipt
+   generation MUST have a private signature key to sign the receipt and
+   the corresponding signature validation certificate or its designator.
+   The designator is the certificate issuer name and the certificate
+   serial number, or it is the public key identifier.  Memory-
+   constrained hardware modules will generally store the public key
+   identifier since it requires less storage.
+
+   The unsigned firmware package load receipt is encapsulated by
+   ContentInfo.  Alternatively, the signed firmware package load receipt
+   is encapsulated by SignedData, which is in turn encapsulated by
+   ContentInfo.
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 34]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt is summarized as follows (see [CMS]
+   for the full syntax):
+
+   ContentInfo {
+     contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+                          -- OR --
+                          id-ct-firmwareLoadReceipt,
+                               -- (1.2.840.113549.1.9.16.1.17)
+     content              SignedData
+                          -- OR --
+                          FirmwarePackageLoadReceipt
+   }
+
+   SignedData {
+     version              CMSVersion, -- always set to 3
+     digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+     encapContentInfo     EncapsulatedContentInfo,
+     certificates         CertificateSet, -- Optional Module certificate
+     crls                 CertificateRevocationLists, -- Optional
+     signerInfos          SET OF SignerInfo -- Only one
+   }
+
+   SignerInfo {
+     version              CMSVersion, -- either set to 1 or 3
+     sid                  SignerIdentifier,
+     digestAlgorithm      DigestAlgorithmIdentifier,
+     signedAttrs          SignedAttributes, -- Required
+     signatureAlgorithm   SignatureAlgorithmIdentifier,
+     signature            SignatureValue,
+     unsignedAttrs        UnsignedAttributes -- Omit
+   }
+
+   EncapsulatedContentInfo {
+     eContentType         id-ct-firmwareLoadReceipt,
+                               -- (1.2.840.113549.1.9.16.1.17)
+     eContent             OCTET STRING -- Contains receipt
+   }
+
+   FirmwarePackageLoadReceipt {
+     version              INTEGER, -- The DEFAULT is always used
+     hwType               OBJECT IDENTIFIER, -- Hardware module type
+     hwSerialNum          OCTET STRING, -- H/W module serial number
+     fwPkgName            PreferredOrLegacyPackageIdentifier,
+     trustAnchorKeyID     OCTET STRING, -- Optional
+     decryptKeyID         OCTET STRING -- Optional
+   }
+
+
+
+
+
+Housley                     Standards Track                    [Page 35]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+3.1.  Firmware Package Load Receipt CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo
+   and SignedData content types for firmware package load receipts.  It
+   also defines the firmware package load receipt content type.
+
+3.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   contentType indicates the type of the associated content.  If the
+      firmware package load receipt is signed, then the encapsulated
+      type MUST be SignedData, and the id-signedData
+      (1.2.840.113549.1.7.2) object identifier MUST be present in this
+      field.  If the receipt is not signed, then the encapsulated type
+      MUST be FirmwarePackageLoadReceipt, and the id-ct-
+      firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object identifier
+      MUST be present in this field.
+
+   content holds the associated content.  If the firmware package load
+      receipt is signed, then this field MUST contain the SignedData.
+      If the receipt is not signed, then this field MUST contain the
+      FirmwarePackageLoadReceipt.
+
+3.1.2.  SignedData
+
+   The SignedData content type contains the firmware package load
+   receipt and one digital signature.  If the hardware module locally
+   stores its certificate, then the certificate can be included as well.
+   The fields of SignedData are used as follows:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 3.
+
+   digestAlgorithms is a collection of message digest algorithm
+      identifiers, and in this case, it MUST contain a single message
+      digest algorithm identifier.  The message digest algorithms
+      employed by the hardware module MUST be present.
+
+   encapContentInfo is the signed content, consisting of a content type
+      identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      3.1.2.2.
+
+   certificates is an optional collection of certificates.  If the
+      hardware module locally stores its certificate, then the X.509
+      certificate of the hardware module SHOULD be included.  If the
+
+
+
+Housley                     Standards Track                    [Page 36]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      hardware module does not, then the certificates field is omitted.
+      PKCS#6 extended certificates [PKCS#6] and attribute certificates
+      (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE]
+      MUST NOT be included in the set of certificates.
+
+   crls is an optional collection of certificate revocation lists
+      (CRLs).  CRLs MAY be included, but they will normally be omitted
+      since hardware modules will not generally have access to the most
+      recent CRL.  Signed receipt recipients SHOULD be able to handle
+      the presence of the optional crls field.
+
+   signerInfos is a collection of per-signer information, and in this
+      case, the collection MUST contain exactly one SignerInfo.  The use
+      of the SignerInfo type is discussed further in Section 3.1.2.1.
+
+3.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used as follows:
+
+   version is the syntax version number, and it MUST be either 1 or 3,
+      depending on the method used to identify the hardware module's
+      public key.  The use of the subjectKeyIdentifier is RECOMMENDED,
+      which results in the use of version 3.
+
+   sid specifies the hardware module's certificate (and thereby the
+      hardware module's public key).  CMS supports two alternatives:
+      issuerAndSerialNumber and subjectKeyIdentifier.  The hardware
+      module MUST support one or both of the alternatives for receipt
+      generation; however, the support of subjectKeyIdentifier is
+      RECOMMENDED.  The issuerAndSerialNumber alternative identifies the
+      hardware module's certificate by the issuer's distinguished name
+      and the certificate serial number.  The identified certificate, in
+      turn, contains the hardware module's public key.  The
+      subjectKeyIdentifier alternative identifies the hardware module's
+      public key directly.  When this public key is contained in a
+      certificate, this identifier SHOULD appear in the X.509
+      subjectKeyIdentifier extension.
+
+   digestAlgorithm identifies the message digest algorithm, and any
+      associated parameters, used by the hardware module.  It MUST
+      contain the message digest algorithms employed to sign the
+      receipt.  (Note that this message digest algorithm identifier MUST
+      be the same as the one carried in the digestAlgorithms value in
+      SignedData.)
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 37]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   signedAttrs is an optional collection of attributes that are signed
+      along with the content.  The signedAttrs are optional in the CMS,
+      but in this specification, signedAttrs are REQUIRED for use with
+      the firmware package load receipt content.  The SET OF attributes
+      MUST be DER encoded [X.509-88].  Section 3.2 of this document
+      lists the attributes that MUST be included in the collection.
+      Other attributes MAY be included, but the recipient will ignore
+      any unrecognized signed attributes.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used to sign the receipt.
+
+   signature is the digital signature.
+
+   unsignedAttrs is an optional collection of attributes that are not
+      signed, and in this case, there MUST NOT be any unsigned
+      attributes present.
+
+3.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING,
+   and it is carried within the EncapsulatedContentInfo type.  The
+   fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
+
+   eContent is the firmware package load receipt, encapsulated in an
+      OCTET STRING.  The eContent octet string need not be DER encoded.
+
+3.1.3.  FirmwarePackageLoadReceipt
+
+   The following object identifier identifies the firmware package load
+   receipt content type:
+
+      id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 17 }
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 38]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt content type has the ASN.1 type
+   FirmwarePackageLoadReceipt:
+
+      FirmwarePackageLoadReceipt ::= SEQUENCE {
+        version FWReceiptVersion DEFAULT v1,
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING,
+        fwPkgName PreferredOrLegacyPackageIdentifier,
+        trustAnchorKeyID OCTET STRING OPTIONAL,
+        decryptKeyID [1] OCTET STRING OPTIONAL }
+
+      FWReceiptVersion ::= INTEGER { v1(1) }
+
+   The fields of the FirmwarePackageLoadReceipt type have the following
+   meanings:
+
+   version is an integer that provides the syntax version number for
+      compatibility with future revisions of this specification.
+      Implementations that conform to this specification MUST set the
+      version to the default value, which is v1.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package was loaded.
+
+   hwSerialNum is the serial number of the hardware module on which the
+      firmware package was loaded.  No particular structure is imposed
+      on the serial number; it need not be an integer.  However, the
+      combination of the hwType and hwSerialNum uniquely identifies the
+      hardware module.
+
+   fwPkgName identifies the firmware package that was loaded.  As
+      described in Section 2.2.3, two approaches to naming firmware
+      packages are supported: legacy and preferred.  A legacy firmware
+      package name is an octet string.  A preferred firmware package
+      name is a combination of the firmware package object identifier
+      and an integer version number.
+
+   trustAnchorKeyID is optional, and when it is present, it identifies
+      the trust anchor that was used to validate the firmware package
+      signature.
+
+   decryptKeyID is optional, and when it is present, it identifies the
+      firmware-decryption key that was used to decrypt the firmware
+      package.
+
+   The firmware package load receipt MUST include the version, hwType,
+   hwSerialNum, and fwPkgName fields, and it SHOULD include the
+   trustAnchorKeyID field.  The firmware package load receipt MUST NOT
+
+
+
+Housley                     Standards Track                    [Page 39]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   include the decryptKeyID, unless the firmware package associated with
+   the receipt is encrypted, the firmware-decryption key is available to
+   the hardware module, and the firmware package was successfully
+   decrypted.
+
+3.2.  Signed Attributes
+
+   The hardware module MUST digitally sign a collection of attributes
+   along with the firmware package load receipt.  Each attribute in the
+   collection MUST be DER encoded [X.509-88].  The syntax for attributes
+   is defined in [CMS], and it was repeated in Section 2.2 for
+   convenience.
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The hardware module MUST include the content-type and message-digest
+   attributes.  If the hardware module includes a real-time clock, then
+   the hardware module SHOULD also include the signing-time attribute.
+   The hardware module MAY include any other attribute that it deems
+   appropriate.
+
+3.2.1.  Content Type
+
+   The hardware module MUST include a content-type attribute with the
+   value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
+   Section 11.1 of [CMS] defines the content-type attribute.
+
+3.2.2.  Message Digest
+
+   The hardware module MUST include a message-digest attribute, having
+   as its value the message digest of the FirmwarePackageLoadReceipt
+   content.  Section 11.2 of [CMS] defines the message-digest attribute.
+
+3.2.3.  Signing Time
+
+   If the hardware module includes a real-time clock, then the hardware
+   module SHOULD include a signing-time attribute, specifying the time
+   at which the receipt was generated.  Section 11.3 of [CMS] defines
+   the signing-time attribute.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 40]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.  Firmware Package Load Error
+
+   The Cryptographic Message Syntax (CMS) is used to indicate that an
+   error has occurred while attempting to load a protected firmware
+   package.  Support for firmware package load error reports is
+   OPTIONAL.  However, those hardware modules that choose to generate
+   such error reports MUST follow the conventions specified in this
+   section.  Not all hardware modules have private signature keys;
+   therefore the firmware package load error report can be either signed
+   or unsigned.  Use of the signed firmware package error report is
+   RECOMMENDED.
+
+   Hardware modules that support error report generation MUST have a
+   unique serial number.  Hardware modules that support signed error
+   report generation MUST also have a private signature key to sign the
+   error report and the corresponding signature validation certificate
+   or its designator.  The designator is the certificate issuer name and
+   the certificate serial number, or it is the public key identifier.
+   Memory-constrained hardware modules will generally store the public
+   key identifier since it requires less storage.
+
+   The unsigned firmware package load error report is encapsulated by
+   ContentInfo.  Alternatively, the signed firmware package load error
+   report is encapsulated by SignedData, which is in turn encapsulated
+   by ContentInfo.
+
+   The firmware package load error report is summarized as follows (see
+   [CMS] for the full syntax):
+
+   ContentInfo {
+     contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+                          -- OR --
+                          id-ct-firmwareLoadError,
+                               -- (1.2.840.113549.1.9.16.1.18)
+     content              SignedData
+                          -- OR --
+                          FirmwarePackageLoadError
+   }
+
+   SignedData {
+     version              CMSVersion, -- Always set to 3
+     digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+     encapContentInfo     EncapsulatedContentInfo,
+     certificates         CertificateSet, -- Optional Module certificate
+     crls                 CertificateRevocationLists, -- Optional
+     signerInfos          SET OF SignerInfo -- Only one
+   }
+
+
+
+
+Housley                     Standards Track                    [Page 41]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   SignerInfo {
+     version              CMSVersion, -- either set to 1 or 3
+     sid                  SignerIdentifier,
+     digestAlgorithm      DigestAlgorithmIdentifier,
+     signedAttrs          SignedAttributes, -- Required
+     signatureAlgorithm   SignatureAlgorithmIdentifier,
+     signature            SignatureValue,
+     unsignedAttrs        UnsignedAttributes -- Omit
+   }
+
+   EncapsulatedContentInfo {
+     eContentType         id-ct-firmwareLoadError,
+                               -- (1.2.840.113549.1.9.16.1.18)
+     eContent             OCTET STRING -- Contains error report
+   }
+
+   FirmwarePackageLoadError {
+     version            INTEGER, -- The DEFAULT is always used
+     hwType             OBJECT IDENTIFIER, -- Hardware module type
+     hwSerialNum        OCTET STRING, -- H/W module serial number
+     errorCode          FirmwarePackageLoadErrorCode -- Error identifier
+     vendorErrorCode    VendorErrorCode, -- Optional
+     fwPkgName          PreferredOrLegacyPackageIdentifier, -- Optional
+     config             SEQUENCE OF CurrentFWConfig, -- Optional
+   }
+
+   CurrentFWConfig {      -- Repeated for each package in configuration
+     fwPkgType            INTEGER, -- Firmware package type; Optional
+     fwPkgName            PreferredOrLegacyPackageIdentifier
+   }
+
+4.1.  Firmware Package Load Error CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo
+   and SignedData content types for firmware package load error reports.
+   It also defines the firmware package load error content type.
+
+4.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   contentType indicates the type of the associated content.  If the
+      firmware package load error report is signed, then the
+      encapsulated type MUST be SignedData, and the id-signedData
+      (1.2.840.113549.1.7.2) object identifier MUST be present in this
+      field.  If the report is not signed, then the encapsulated type
+
+
+
+
+Housley                     Standards Track                    [Page 42]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      MUST be FirmwarePackageLoadError, and the id-ct-firmwareLoadError
+      (1.2.840.113549.1.9.16.1.18) object identifier MUST be present in
+      this field.
+
+   content holds the associated content.  If the firmware package load
+      error report is signed, then this field MUST contain the
+      SignedData.  If the report is not signed, then this field MUST
+      contain the FirmwarePackageLoadError.
+
+4.1.2.  SignedData
+
+   The SignedData content type contains the firmware package load error
+   report and one digital signature.  If the hardware module locally
+   stores its certificate, then the certificate can be included as well.
+   The fields of SignedData are used exactly as described in Section
+   3.1.2.
+
+4.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used exactly as described in Section
+   3.1.2.1.
+
+4.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and
+   it is carried within the EncapsulatedContentInfo type.  The fields of
+   EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwareLoadError (1.2.840.113549.1.9.16.1.18).
+
+   eContent is the firmware package load error report, encapsulated in
+      an OCTET STRING.  The eContent octet string need not be DER
+      encoded.
+
+4.1.3.  FirmwarePackageLoadError
+
+   The following object identifier identifies the firmware package load
+   error report content type:
+
+      id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 18 }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 43]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load error report content type has the ASN.1
+   type FirmwarePackageLoadError:
+
+      FirmwarePackageLoadError ::= SEQUENCE {
+        version FWErrorVersion DEFAULT v1,
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING,
+        errorCode FirmwarePackageLoadErrorCode,
+        vendorErrorCode VendorLoadErrorCode OPTIONAL,
+        fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
+        config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
+
+      FWErrorVersion ::= INTEGER { v1(1) }
+
+      CurrentFWConfig ::= SEQUENCE {
+        fwPkgType INTEGER OPTIONAL,
+        fwPkgName PreferredOrLegacyPackageIdentifier }
+
+      FirmwarePackageLoadErrorCode ::= ENUMERATED {
+        decodeFailure                (1),
+        badContentInfo               (2),
+        badSignedData                (3),
+        badEncapContent              (4),
+        badCertificate               (5),
+        badSignerInfo                (6),
+        badSignedAttrs               (7),
+        badUnsignedAttrs             (8),
+        missingContent               (9),
+        noTrustAnchor               (10),
+        notAuthorized               (11),
+        badDigestAlgorithm          (12),
+        badSignatureAlgorithm       (13),
+        unsupportedKeySize          (14),
+        signatureFailure            (15),
+        contentTypeMismatch         (16),
+        badEncryptedData            (17),
+        unprotectedAttrsPresent     (18),
+        badEncryptContent           (19),
+        badEncryptAlgorithm         (20),
+        missingCiphertext           (21),
+        noDecryptKey                (22),
+        decryptFailure              (23),
+        badCompressAlgorithm        (24),
+        missingCompressedContent    (25),
+        decompressFailure           (26),
+        wrongHardware               (27),
+        stalePackage                (28),
+        notInCommunity              (29),
+
+
+
+Housley                     Standards Track                    [Page 44]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+        unsupportedPackageType      (30),
+        missingDependency           (31),
+        wrongDependencyVersion      (32),
+        insufficientMemory          (33),
+        badFirmware                 (34),
+        unsupportedParameters       (35),
+        breaksDependency            (36),
+        otherError                  (99) }
+
+      VendorLoadErrorCode ::= INTEGER
+
+   The fields of the FirmwarePackageLoadError type have the following
+   meanings:
+
+   version is an integer, and it provides the syntax version number for
+      compatibility with future revisions of this specification.
+      Implementations that conform to this specification MUST set the
+      version to the default value, which is v1.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package load was attempted.
+
+   hwSerialNum is the serial number of the hardware module on which the
+      firmware package load was attempted.  No particular structure is
+      imposed on the serial number; it need not be an integer.  However,
+      the combination of the hwType and hwSerialNum uniquely identifies
+      the hardware module.
+
+   errorCode identifies the error that occurred.
+
+   vendorErrorCode is optional; however, it MUST be present if the
+      errorCode contains a value of otherError.  When errorCode contains
+      a value other than otherError, the vendorErrorCode can provide
+      vendor-specific supplemental information.
+
+   fwPkgName is optional.  When it is present, it identifies the
+      firmware package that was being loaded when the error occurred.
+      As described in Section 2.2.3, two approaches to naming firmware
+      packages are supported: legacy and preferred.  A legacy firmware
+      package name is an octet string.  A preferred firmware package
+      name is a combination of the firmware package object identifier
+      and an integer version number.
+
+   config identifies the current firmware configuration.  The field is
+      OPTIONAL, but support for this field is RECOMMENDED for hardware
+      modules that permit the loading of more than one firmware package.
+      One instance of CurrentFWConfig is used to provide information
+      about each firmware package in hardware module.
+
+
+
+Housley                     Standards Track                    [Page 45]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The fields of the CurrentFWConfig type have the following meanings:
+
+   fwPkgType identifies the firmware package type.  The firmware package
+      type is an INTEGER, and the meaning of the integer value is
+      specific to each hardware module.
+
+   fwPkgName identifies the firmware package.  As described in Section
+      2.2.3, two approaches to naming firmware packages are supported:
+      legacy and preferred.  A legacy firmware package name is an octet
+      string.  A preferred firmware package name is a combination of the
+      firmware package object identifier and an integer version number.
+
+   The errorCode values have the following meanings:
+
+   decodeFailure: The ASN.1 decode of the firmware package load failed.
+      The provided input did not conform to BER, or it was not ASN.1 at
+      all.
+
+   badContentInfo: Invalid ContentInfo syntax, or the contentType
+      carried within the ContentInfo is unknown or unsupported.
+
+   badSignedData: Invalid SignedData syntax, the version is unknown or
+      unsupported, or more than one entry is present in
+      digestAlgorithms.
+
+   badEncapContent: Invalid EncapsulatedContentInfo syntax, or the
+      contentType carried within the eContentType is unknown or
+      unsupported.  This error can be generated due to problems located
+      in SignedData or CompressedData.
+
+   badCertificate: Invalid syntax for one or more certificates in
+      CertificateSet.
+
+   badSignerInfo: Invalid SignerInfo syntax, or the version is unknown
+      or unsupported.
+
+   badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
+
+   badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an
+      attribute other than the wrapped-firmware-decryption-key
+      attribute, which is the only unsigned attribute supported by this
+      specification.
+
+   missingContent: The optional eContent is missing in
+      EncapsulatedContentInfo, which is required in this specification.
+      This error can be generated due to problems located in SignedData
+      or CompressedData.
+
+
+
+
+Housley                     Standards Track                    [Page 46]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   noTrustAnchor: Two situations can lead to this error.  In one case,
+      the subjectKeyIdentifier does not identify the public key of a
+      trust anchor or a certification path that terminates with an
+      installed trust anchor.  In the other case, the
+      issuerAndSerialNumber does not identify the public key of a trust
+      anchor or a certification path that terminates with an installed
+      trust anchor.
+
+   notAuthorized: The sid within SignerInfo leads to an installed trust
+      anchor, but that trust anchor is not an authorized firmware
+      package signer.
+
+   badDigestAlgorithm: The digestAlgorithm in either SignerInfo or
+      SignedData is unknown or unsupported.
+
+   badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is
+      unknown or unsupported.
+
+   unsupportedKeySize: The signatureAlgorithm in SignerInfo is known and
+      supported, but the firmware package signature could not be
+      validated because an unsupported key size was employed by the
+      signer.
+
+   signatureFailure: The signatureAlgorithm in SignerInfo is known and
+      supported, but the signature in signature in SignerInfo could not
+      be validated.
+
+   contentTypeMismatch: The contentType carried within the eContentType
+      does not match the content type carried in the signed attribute.
+
+   badEncryptedData: Invalid EncryptedData syntax; the version is
+      unknown or unsupported.
+
+   unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs,
+      which are not permitted in this specification.
+
+   badEncryptContent: Invalid EncryptedContentInfo syntax, or the
+      contentType carried within the contentType is unknown or
+      unsupported.
+
+   badEncryptAlgorithm: The firmware-encryption algorithm identified by
+      contentEncryptionAlgorithm in EncryptedContentInfo is unknown or
+      unsupported.
+
+   missingCiphertext: The optional encryptedContent is missing in
+      EncryptedContentInfo, which is required in this specification.
+
+
+
+
+
+Housley                     Standards Track                    [Page 47]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   noDecryptKey: The hardware module does not have the firmware-
+      decryption key named in the decrypt key identifier signed
+      attribute.
+
+   decryptFailure: The firmware package did not decrypt properly.
+
+   badCompressAlgorithm: The compression algorithm identified by
+      compressionAlgorithm in CompressedData is unknown or unsupported.
+
+   missingCompressedContent: The optional eContent is missing in
+      EncapsulatedContentInfo, which is required in this specification.
+
+   decompressFailure: The firmware package did not decompress properly.
+
+   wrongHardware: The processing hardware module is not listed in the
+      target hardware module identifiers signed attribute.
+
+   stalePackage: The firmware package is rejected because it is stale.
+
+   notInCommunity: The hardware module is not a member of the community
+      described in the community identifiers signed attribute.
+
+   unsupportedPackageType: The firmware package type identified in the
+      firmware package information signed attribute is not supported by
+      the combination of the hardware module and the bootstrap loader.
+
+   missingDependency: The firmware package being loaded depends on
+      routines that are part of another firmware package, but that
+      firmware package is not available.
+
+   wrongDependencyVersion: The firmware package being loaded depends on
+      routines that are part of the another firmware package, and the
+      available version of that package has an older version number than
+      is required.  The available firmware package does not fulfill the
+      dependencies.
+
+   insufficientMemory: The firmware package could not be loaded because
+      the hardware module did not have sufficient memory.
+
+   badFirmware: The signature on the firmware package was validated, but
+      the firmware package itself was not in an acceptable format.  The
+      details will be specific to each hardware module.  For example, a
+      hardware module that is composed of multiple firmware-programmable
+      components could not find the internal tagging within the firmware
+      package to distribute executable code to each of the components.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 48]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   unsupportedParameters: The signature on the firmware package could
+      not be validated because the signer used signature algorithm
+      parameters that are not supported by the hardware module signature
+      verification routines.
+
+   breaksDependency: Another firmware package has a dependency that can
+      no longer be satisfied if the firmware package being loaded is
+      accepted.
+
+   otherError: An error occurred that does not fit any of the previous
+      error codes.
+
+4.2.  Signed Attributes
+
+   The hardware module MUST digitally sign a collection of attributes
+   along with the firmware package load error report.  Each attribute in
+   the collection MUST be DER encoded [X.509-88].  The syntax for
+   attributes is defined in [CMS], and it was repeated in Section 2.2
+   for convenience.
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The hardware module MUST include the content-type and message-digest
+   attributes.  If the hardware module includes a real-time clock, then
+   the hardware module SHOULD also include the signing-time attribute.
+   The hardware module MAY include any other attribute that it deems
+   appropriate.
+
+4.2.1.  Content Type
+
+   The hardware module MUST include a content-type attribute with the
+   value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18).
+   Section 11.1 of [CMS] defines the content-type attribute.
+
+4.2.2.  Message Digest
+
+   The hardware module MUST include a message-digest attribute, having
+   as its value the message digest of the FirmwarePackageLoadError
+   content.  Section 11.2 of [CMS] defines the message-digest attribute.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 49]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.2.3.  Signing Time
+
+   If the hardware module includes a real-time clock, then hardware
+   module SHOULD include a signing-time attribute, specifying the time
+   at which the firmware package load error report was generated.
+   Section 11.3 of [CMS] defines the signing-time attribute.
+
+5.  Hardware Module Name
+
+   Support for firmware package load receipts, as discussed in Section
+   3, is OPTIONAL, and support for the firmware package load error
+   reports, as discussed in Section 4, is OPTIONAL.  Hardware modules
+   that support receipt or error report generation MUST have unique
+   serial numbers.  Further, hardware modules that support signed
+   receipt or error report generation MUST have private signature keys
+   and corresponding signature validation certificates [PROFILE] or
+   their designators.  The conventions for hardware module naming in the
+   signature validation certificates are specified in this section.
+
+   The hardware module vendor or a trusted third party MUST issue the
+   signature validation certificate prior to deployment of the hardware
+   module.  The certificate is likely to be issued at the time of
+   manufacture.  The subject alternative name in this certificate
+   identifies the hardware module.  The subject distinguished name is
+   empty, but a critical subject alternative name extension contains the
+   hardware module name, using the otherName choice within the
+   GeneralName structure.
+
+   The hardware module name form is identified by the id-on-
+   hardwareModuleName object identifier:
+
+      id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
+        iso(1) identified-organization(3) dod(6) internet(1) security(5)
+        mechanisms(5) pkix(7) on(8) 4 }
+
+   A HardwareModuleName is composed of an object identifier and an octet
+   string:
+
+      HardwareModuleName ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING }
+
+   The fields of the HardwareModuleName type have the following
+   meanings:
+
+   hwType is an object identifier that identifies the type of hardware
+      module.  A unique object identifier names a hardware model and
+      revision.
+
+
+
+Housley                     Standards Track                    [Page 50]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   hwSerialNum is the serial number of the hardware module.  No
+      particular structure is imposed on the serial number; it need not
+      be an integer.  However, the combination of the hwType and
+      hwSerialNum uniquely identifies the hardware module.
+
+6.  Security Considerations
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) to protect firmware packages; therefore, the security
+   considerations discussed in [CMS] apply to this specification as
+   well.
+
+   The conventions specified in this document raise a few security
+   considerations of their own.
+
+6.1.  Cryptographic Keys and Algorithms
+
+   Private signature keys must be protected.  Compromise of the private
+   key used to sign firmware packages permits unauthorized parties to
+   generate firmware packages that are acceptable to hardware modules.
+   Compromise of the hardware module private key allows unauthorized
+   parties to generate signed firmware package load receipts and error
+   reports.
+
+   The firmware-decryption key must be protected.  Compromise of the key
+   may result in the disclosure of the firmware package to unauthorized
+   parties.
+
+   Cryptographic algorithms become weaker with time.  As new
+   cryptanalysis techniques are developed and computing performance
+   improves, the work factor to break a particular cryptographic
+   algorithm will be reduced.  The ability to change the firmware
+   package provides an opportunity to update or replace cryptographic
+   algorithms.  Although this capability is desirable, cryptographic
+   algorithm replacement can lead to interoperability failures.
+   Therefore, the rollout of new cryptographic algorithms must be
+   managed.  Generally, the previous generation of cryptographic
+   algorithms and their replacements need to be supported at the same
+   time in order to facilitate an orderly transition.
+
+6.2.  Random Number Generation
+
+   When firmware packages are encrypted, the source of the firmware
+   package must randomly generate firmware-encryption keys.  Also, the
+   generation of public/private signature key pairs relies on a random
+   numbers.  The use of inadequate pseudo-random number generators
+   (PRNGs) to generate cryptographic keys can result in little or no
+   security.  An attacker may find it much easier to reproduce the PRNG
+
+
+
+Housley                     Standards Track                    [Page 51]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   environment that produced the keys, searching the resulting small set
+   of possibilities, rather than brute-force searching the whole key
+   space.  The generation of quality random numbers is difficult.  RFC
+   4086 [RANDOM] offers important guidance in this area.
+
+6.3.  Stale Firmware Package Version Number
+
+   The firmware signer determines whether a stale version number is
+   included.  The policy of the firmware signer needs to consider many
+   factors.  Consider the flaw found by Ian Goldberg and David Wagner in
+   the random number generator of the Netscape browser in 1996 [DDJ].
+   This flaw completely undermines confidentiality protection.  A
+   firmware signer might use the stale version number to ensure that
+   upgraded hardware modules do not resume use of the flawed firmware.
+   However, another firmware signer may not consider this an appropriate
+   situation to employ the stale version number, preferring to delegate
+   this decision to someone closer to the operation of the hardware
+   module.  Such a person is likely to be in a better position to
+   evaluate whether other bugs introduced in the newer firmware package
+   impose worse operational concerns than the confidentiality concern
+   caused by the flawed random number generator.  For example, a user
+   who never uses the encryption feature of the flawed Netscape browser
+   will determine the most appropriate version to use without
+   considering the random number flaw or its fix.
+
+   The stale version number is especially useful when the security
+   interests of the person choosing which firmware package version to
+   load into a particular hardware module do not align with the security
+   interests of the firmware package signer.  For example, stale version
+   numbers may be useful in hardware modules that provide digital rights
+   management (DRM).  Also, stale version numbers will be useful when
+   the deployment organization (as opposed to the firmware package
+   vendor) is the firmware signer.  Further, stale version numbers will
+   be useful for firmware packages that need to be trusted to implement
+   organizational (as opposed to the deployment organization) security
+   policy, regardless of whether the firmware signer is the deployment
+   organization or the vendor.  For example, hardware devices employed
+   by the military will probably make use of stale version numbers.
+
+   The use of a stale version number in a firmware package that employs
+   the preferred firmware package name form cannot completely prevent
+   subsequent use of the stale firmware package.  Despite this
+   shortcoming, the feature is included since it is useful in some
+   important situations.  By loading different types of firmware
+   packages, each with its own stale firmware package version number
+   until the internal storage for the stale version number is exceeded,
+   the user can circumvent the mechanism.  Consider a hardware module
+
+
+
+
+Housley                     Standards Track                    [Page 52]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   that has storage for two stale version numbers.  Suppose that FWPKG-A
+   version 3 is loaded, indicating that FWPKG-A version 2 is stale.  The
+   user can sequentially load the following:
+
+      - FWPKG-B version 8, indicating that FWPKG-B version 4 is stale.
+          (Note: The internal storage indicates that FWPKG-A version 2
+           and FWPKG-B version 4 are stale.)
+
+      - FWPKG-C version 5, indicating that FWPKG-C version 3 is stale.
+          (Note: The internal storage indicates that FWPKG-B version 4
+           and FWPKG-C version 3 are stale.)
+
+      - FWPKG-A version 2.
+
+   Because many hardware modules are expected to have very few firmware
+   packages written for them, the stale firmware package version feature
+   provides important protections.  The amount of non-volatile storage
+   that needs to be dedicated to saving firmware package identifiers and
+   version numbers depends on the number of firmware packages that are
+   likely to be developed for the hardware module.
+
+   The use of legacy firmware package name form does not improve this
+   situation.  In fact, the legacy firmware package names are usually
+   larger than an object identifier.  Thus, comparable stale version
+   protection requires more memory.
+
+   A firmware signer can ensure that stale version numbers are honored
+   by limiting the number of different types of firmware packages that
+   are signed.  If all of the hardware modules are able to store a stale
+   version number for each of the different types of firmware package,
+   then the hardware module will be able to provide the desired
+   protection.  This requires the firmware signer to have a deep
+   understanding of all of the hardware modules that might accept the
+   firmware package.
+
+6.4.  Community Identifiers
+
+   When a firmware package includes a community identifier, the
+   confidence that the package is only used by the intended community
+   depends on the mechanism used to configure community membership.
+   This document does not specify a mechanism for the assignment of
+   community membership to hardware modules, and the various
+   alternatives have different security properties.  Also, the authority
+   that makes community identifier assignments to hardware modules might
+   be different than the authority that generates firmware packages.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 53]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [COMPRESS]   Gutmann, P., "Compressed Data Content Type for
+                Cryptographic Message Syntax (CMS)", RFC 3274, June
+                2002.
+
+   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                3852, July 2004.
+
+   [ESS]        Hoffman, P., "Enhanced Security Services for S/MIME",
+                RFC 2634, June 1999.
+
+   [PROFILE]    Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+                X.509 Public Key Infrastructure Certificate and
+                Certificate Revocation List (CRL) Profile", RFC 3280,
+                April 2002.
+
+   [SHA1]       National Institute of Standards and Technology.  FIPS
+                Pub 180-1: Secure Hash Standard.  17 April 1995.
+
+   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [X.208-88]   CCITT.  Recommendation X.208: Specification of Abstract
+                Syntax Notation One (ASN.1).  1988.
+
+   [X.209-88]   CCITT.  Recommendation X.209: Specification of Basic
+                Encoding Rules for Abstract Syntax Notation One (ASN.1).
+                1988.
+
+   [X.509-88]   CCITT.  Recommendation X.509: The Directory -
+                Authentication Framework.  1988.
+
+7.2.  Informative References
+
+   [ACPROFILE]  Farrell, S. and R. Housley, "An Internet Attribute
+                Certificate Profile for Authorization", RFC 3281, April
+                2002.
+
+   [AES]        National Institute of Standards and Technology.  FIPS
+                Pub 197:  Advanced Encryption Standard (AES).  26
+                November 2001.
+
+
+
+
+Housley                     Standards Track                    [Page 54]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   [DDJ]        Goldberg, I. and D. Wagner.  "Randomness and the
+                Netscape Browser."  Dr. Dobb's Journal, January 1996.
+
+   [DPD&DPV]    Pinkas, D. and R. Housley, "Delegated Path Validation
+                and Delegated Path Discovery Protocol Requirements", RFC
+                3379, September 2002.
+
+   [OCSP]       Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+                Adams, "X.509 Internet Public Key Infrastructure Online
+                Certificate Status Protocol - OCSP", RFC 2560, June
+                1999.
+
+   [PKCS#6]     RSA Laboratories.  PKCS #6: Extended-Certificate Syntax
+                Standard, Version 1.5.  November 1993.
+
+   [RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                "Randomness Requirements for Security", BCP 106, RFC
+                4086, June 2005.
+
+   [SECREQMTS]  National Institute of Standards and Technology.  FIPS
+                Pub 140-2: Security Requirements for Cryptographic
+                Modules.  25 May 2001.
+
+   [X.509-97]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  1997.
+
+   [X.509-00]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 55]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Appendix A: ASN.1 Module
+
+   The ASN.1 module contained in this appendix defines the structures
+   that are needed to implement the CMS-based firmware package wrapper.
+   It is expected to be used in conjunction with the ASN.1 modules in
+   [CMS], [COMPRESS], and [PROFILE].
+
+
+   CMSFirmwareWrapper
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+         pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   IMPORTS
+       EnvelopedData
+       FROM CryptographicMessageSyntax -- [CMS]
+            { iso(1) member-body(2) us(840) rsadsi(113549)
+              pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
+
+
+   -- Firmware Package Content Type and Object Identifier
+
+   id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 16 }
+
+   FirmwarePkgData ::= OCTET STRING
+
+
+   -- Firmware Package Signed Attributes and Object Identifiers
+
+   id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 35 }
+
+   FirmwarePackageIdentifier ::= SEQUENCE {
+     name PreferredOrLegacyPackageIdentifier,
+     stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+   PreferredOrLegacyPackageIdentifier ::= CHOICE {
+     preferred PreferredPackageIdentifier,
+     legacy OCTET STRING }
+
+   PreferredPackageIdentifier ::= SEQUENCE {
+     fwPkgID OBJECT IDENTIFIER,
+     verNum INTEGER (0..MAX) }
+
+
+
+
+Housley                     Standards Track                    [Page 56]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+     preferredStaleVerNum INTEGER (0..MAX),
+     legacyStaleVersion OCTET STRING }
+
+
+   id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 36 }
+
+   TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+   id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 37 }
+
+   DecryptKeyIdentifier ::= OCTET STRING
+
+
+   id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 38 }
+
+   ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+   id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 43 }
+
+   ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+   id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 40 }
+
+   CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+   CommunityIdentifier ::= CHOICE {
+     communityOID OBJECT IDENTIFIER,
+     hwModuleList HardwareModules }
+
+   HardwareModules ::= SEQUENCE {
+     hwType OBJECT IDENTIFIER,
+     hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 57]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   HardwareSerialEntry ::= CHOICE {
+     all NULL,
+     single OCTET STRING,
+     block SEQUENCE {
+       low OCTET STRING,
+       high OCTET STRING } }
+
+
+   id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 42 }
+
+   FirmwarePackageInfo ::= SEQUENCE {
+     fwPkgType INTEGER OPTIONAL,
+     dependencies SEQUENCE OF
+       PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+
+   -- Firmware Package Unsigned Attributes and Object Identifiers
+
+   id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 39 }
+
+   WrappedFirmwareKey ::= EnvelopedData
+
+
+   -- Firmware Package Load Receipt Content Type and Object Identifier
+
+   id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 17 }
+
+   FirmwarePackageLoadReceipt ::= SEQUENCE {
+     version FWReceiptVersion DEFAULT v1,
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING,
+     fwPkgName PreferredOrLegacyPackageIdentifier,
+     trustAnchorKeyID OCTET STRING OPTIONAL,
+     decryptKeyID [1] OCTET STRING OPTIONAL }
+
+   FWReceiptVersion ::= INTEGER { v1(1) }
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 58]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   -- Firmware Package Load Error Report Content Type
+   -- and Object Identifier
+
+   id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 18 }
+
+   FirmwarePackageLoadError ::= SEQUENCE {
+     version FWErrorVersion DEFAULT v1,
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING,
+     errorCode FirmwarePackageLoadErrorCode,
+     vendorErrorCode VendorLoadErrorCode OPTIONAL,
+     fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
+     config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
+
+   FWErrorVersion ::= INTEGER { v1(1) }
+
+   CurrentFWConfig ::= SEQUENCE {
+     fwPkgType INTEGER OPTIONAL,
+     fwPkgName PreferredOrLegacyPackageIdentifier }
+
+   FirmwarePackageLoadErrorCode ::= ENUMERATED {
+     decodeFailure                (1),
+     badContentInfo               (2),
+     badSignedData                (3),
+     badEncapContent              (4),
+     badCertificate               (5),
+     badSignerInfo                (6),
+     badSignedAttrs               (7),
+     badUnsignedAttrs             (8),
+     missingContent               (9),
+     noTrustAnchor               (10),
+     notAuthorized               (11),
+     badDigestAlgorithm          (12),
+     badSignatureAlgorithm       (13),
+     unsupportedKeySize          (14),
+     signatureFailure            (15),
+     contentTypeMismatch         (16),
+     badEncryptedData            (17),
+     unprotectedAttrsPresent     (18),
+     badEncryptContent           (19),
+     badEncryptAlgorithm         (20),
+     missingCiphertext           (21),
+     noDecryptKey                (22),
+     decryptFailure              (23),
+     badCompressAlgorithm        (24),
+     missingCompressedContent    (25),
+
+
+
+Housley                     Standards Track                    [Page 59]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+     decompressFailure           (26),
+     wrongHardware               (27),
+     stalePackage                (28),
+     notInCommunity              (29),
+     unsupportedPackageType      (30),
+     missingDependency           (31),
+     wrongDependencyVersion      (32),
+     insufficientMemory          (33),
+     badFirmware                 (34),
+     unsupportedParameters       (35),
+     breaksDependency            (36),
+     otherError                  (99) }
+
+   VendorLoadErrorCode ::= INTEGER
+
+
+   -- Other Name syntax for Hardware Module Name
+
+   id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
+     iso(1) identified-organization(3) dod(6) internet(1) security(5)
+     mechanisms(5) pkix(7) on(8) 4 }
+
+   HardwareModuleName ::= SEQUENCE {
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING }
+
+
+   END
+
+Author's Address
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 60]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 61]
+
diff --git a/lib/asn1/Makefile.am b/lib/asn1/Makefile.am
index dcb9c0433..ee3702957 100644
--- a/lib/asn1/Makefile.am
+++ b/lib/asn1/Makefile.am
@@ -23,6 +23,8 @@ libasn1_la_LIBADD = \
 
 BUILT_SOURCES =				\
 	$(gen_files_rfc2459:.x=.c)	\
+	$(gen_files_rfc4043:.x=.c)	\
+	$(gen_files_rfc4108:.x=.c)	\
 	$(gen_files_cms:.x=.c)		\
 	$(gen_files_krb5:.x=.c)		\
 	$(gen_files_ocsp:.x=.c)	\
@@ -38,6 +40,8 @@ gen_files_krb5 = asn1_krb5_asn1.x
 gen_files_cms = asn1_cms_asn1.x
 gen_files_crmf = asn1_crmf_asn1.x
 gen_files_rfc2459 = asn1_rfc2459_asn1.x
+gen_files_rfc4043 = asn1_rfc4043_asn1.x
+gen_files_rfc4108 = asn1_rfc4108_asn1.x
 gen_files_ocsp = asn1_ocsp_asn1.x
 gen_files_pkinit = asn1_pkinit_asn1.x
 gen_files_pkcs10 = asn1_pkcs10_asn1.x
@@ -48,6 +52,8 @@ gen_files_test_template = test_template_asn1-template.x
 gen_files_test = asn1_test_asn1.x
 gen_files_digest = asn1_digest_asn1.x
 gen_files_kx509 = asn1_kx509_asn1.x
+gen_files_rfc4043 = asn1_rfc4043_asn1.x
+gen_files_rfc4108 = asn1_rfc4108_asn1.x
 
 oid_resolution.lo: $(BUILT_SOURCES)
 
@@ -139,6 +145,8 @@ check_ber_LDADD = $(check_gen_LDADD)
 CLEANFILES = \
 	$(BUILT_SOURCES) \
 	$(gen_files_rfc2459) \
+	$(gen_files_rfc4043) \
+	$(gen_files_rfc4108) \
 	$(gen_files_cms) \
 	$(gen_files_krb5) \
 	$(gen_files_ocsp) \
@@ -154,6 +162,8 @@ CLEANFILES = \
 	$(nodist_check_gen_SOURCES) \
 	asn1_err.c asn1_err.h \
 	rfc2459_asn1_files rfc2459_asn1*.h* \
+	rfc4043_asn1_files rfc4043_asn1*.h* \
+	rfc4108_asn1_files rfc4108_asn1*.h* \
 	cms_asn1_files cms_asn1*.h* \
 	crmf_asn1_files crmf_asn1*.h* \
 	krb5_asn1_files krb5_asn1*.h* \
@@ -179,6 +189,8 @@ nodist_include_HEADERS += pkinit_asn1.h
 nodist_include_HEADERS += cms_asn1.h
 nodist_include_HEADERS += crmf_asn1.h
 nodist_include_HEADERS += rfc2459_asn1.h
+nodist_include_HEADERS += rfc4043_asn1.h
+nodist_include_HEADERS += rfc4108_asn1.h
 nodist_include_HEADERS += ocsp_asn1.h
 nodist_include_HEADERS += pkcs8_asn1.h
 nodist_include_HEADERS += pkcs9_asn1.h
@@ -192,6 +204,8 @@ priv_headers += pkinit_asn1-priv.h
 priv_headers += cms_asn1-priv.h
 priv_headers += crmf_asn1-priv.h
 priv_headers += rfc2459_asn1-priv.h
+priv_headers += rfc4043_asn1-priv.h
+priv_headers += rfc4108_asn1-priv.h
 priv_headers += ocsp_asn1-priv.h
 priv_headers += pkcs8_asn1-priv.h
 priv_headers += pkcs9_asn1-priv.h
@@ -223,6 +237,8 @@ $(gen_files_pkcs12) pkcs12_asn1.hx pkcs12_asn1-priv.hx: pkcs12_asn1_files
 $(gen_files_digest) digest_asn1.hx digest_asn1-priv.hx: digest_asn1_files
 $(gen_files_kx509) kx509_asn1.hx kx509_asn1-priv.hx: kx509_asn1_files
 $(gen_files_rfc2459) rfc2459_asn1.hx rfc2459_asn1-priv.hx: rfc2459_asn1_files
+$(gen_files_rfc4043) rfc4043_asn1.hx rfc4043_asn1-priv.hx: rfc4043_asn1_files
+$(gen_files_rfc4108) rfc4108_asn1.hx rfc4108_asn1-priv.hx: rfc4108_asn1_files
 $(gen_files_cms) cms_asn1.hx cms_asn1-priv.hx: cms_asn1_files
 $(gen_files_crmf) crmf_asn1.hx crmf_asn1-priv.hx: crmf_asn1_files
 $(gen_files_test) test_asn1.hx test_asn1-priv.hx: test_asn1_files
@@ -231,6 +247,12 @@ $(gen_files_test_template) test_template_asn1.hx test_template_asn1-priv.hx: tes
 rfc2459_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/rfc2459.asn1
 	$(ASN1_COMPILE) --one-code-file --option-file=$(srcdir)/rfc2459.opt $(srcdir)/rfc2459.asn1 rfc2459_asn1 || (rm -f rfc2459_asn1_files ; exit 1)
 
+rfc4043_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/rfc4043.asn1
+	$(ASN1_COMPILE) --one-code-file $(srcdir)/rfc4043.asn1 rfc4043_asn1 || (rm -f rfc4043_asn1_files ; exit 1)
+
+rfc4108_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/rfc4108.asn1
+	$(ASN1_COMPILE) --one-code-file $(srcdir)/rfc4108.asn1 rfc4108_asn1 || (rm -f rfc4108_asn1_files ; exit 1)
+
 cms_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/cms.asn1 $(srcdir)/cms.opt
 	$(ASN1_COMPILE) --one-code-file --option-file=$(srcdir)/cms.opt $(srcdir)/cms.asn1 cms_asn1 || (rm -f cms_asn1_files ; exit 1)
 
@@ -293,6 +315,8 @@ EXTRA_DIST =		\
 	pkcs10.asn1	\
 	pkinit.asn1	\
 	rfc2459.asn1	\
+	rfc4043.asn1	\
+	rfc4108.asn1	\
 	setchgpw2.asn1	\
 	test.asn1	\
 	test.gen	\
diff --git a/lib/asn1/NTMakefile b/lib/asn1/NTMakefile
index 695c9019d..c45436b9e 100644
--- a/lib/asn1/NTMakefile
+++ b/lib/asn1/NTMakefile
@@ -43,6 +43,10 @@ gen_files_crmf		= $(OBJ)\asn1_crmf_asn1.x
 
 gen_files_rfc2459	= $(OBJ)\asn1_rfc2459_asn1.x
 
+gen_files_rfc4043	= $(OBJ)\asn1_rfc4043_asn1.x
+
+gen_files_rfc4108	= $(OBJ)\asn1_rfc4108_asn1.x
+
 gen_files_ocsp		= $(OBJ)\asn1_ocsp_asn1.x
 
 gen_files_pkinit	= $(OBJ)\asn1_pkinit_asn1.x
@@ -117,6 +121,8 @@ LIBASN1_OBJS=	\
 	$(OBJ)\extra.obj		\
 	$(OBJ)\timegm.obj		\
 	$(gen_files_rfc2459:.x=.obj)	\
+	$(gen_files_rfc4043:.x=.obj)	\
+	$(gen_files_rfc4108:.x=.obj)	\
 	$(gen_files_cms:.x=.obj)	\
 	$(gen_files_crmf:.x=.obj)	\
 	$(gen_files_krb5:.x=.obj)		\
@@ -175,6 +181,10 @@ $(gen_files_kx509:.x=.c)    : $$(@R).x
 
 $(gen_files_rfc2459:.x=.c)  : $$(@R).x
 
+$(gen_files_rfc4043:.x=.c)  : $$(@R).x
+
+$(gen_files_rfc4108:.x=.c)  : $$(@R).x
+
 $(gen_files_cms:.x=.c)	    : $$(@R).x
 
 $(gen_files_crmf:.x=.c)	    : $$(@R).x
@@ -255,6 +265,22 @@ $(gen_files_rfc2459) $(OBJ)\rfc2459_asn1.hx: $(BINDIR)\asn1_compile.exe rfc2459.
 	|| ($(RM) $(OBJ)\rfc2459_asn1.h ; exit /b 1)
 	cd $(SRCDIR)
 
+$(gen_files_rfc4043) $(OBJ)\rfc4043_asn1.hx: $(BINDIR)\asn1_compile.exe rfc4043.asn1
+	cd $(OBJ)
+	$(BINDIR)\asn1_compile.exe \
+		--one-code-file \
+		$(SRCDIR)\rfc4043.asn1 rfc4043_asn1 \
+	|| ($(RM) $(OBJ)\rfc4043_asn1.h ; exit /b 1)
+	cd $(SRCDIR)
+
+$(gen_files_rfc4108) $(OBJ)\rfc4108_asn1.hx: $(BINDIR)\asn1_compile.exe rfc4108.asn1
+	cd $(OBJ)
+	$(BINDIR)\asn1_compile.exe \
+		--one-code-file \
+		$(SRCDIR)\rfc4108.asn1 rfc4108_asn1 \
+	|| ($(RM) $(OBJ)\rfc4108_asn1.h ; exit /b 1)
+	cd $(SRCDIR)
+
 $(gen_files_cms) $(OBJ)\cms_asn1.hx: $(BINDIR)\asn1_compile.exe cms.asn1 cms.opt
 	cd $(OBJ)
 	$(BINDIR)\asn1_compile.exe \
@@ -304,12 +330,16 @@ GENINCFILES=			    \
 	$(INCDIR)\pkcs10_asn1.h	    \
 	$(INCDIR)\pkinit_asn1.h	    \
 	$(INCDIR)\rfc2459_asn1.h    \
+	$(INCDIR)\rfc4043_asn1.h    \
+	$(INCDIR)\rfc4108_asn1.h    \
 	$(OBJ)\krb5_asn1-priv.h	    \
 	$(OBJ)\ocsp_asn1-priv.h     \
 	$(OBJ)\pkinit_asn1-priv.h   \
 	$(OBJ)\cms_asn1-priv.h	    \
 	$(OBJ)\crmf_asn1-priv.h	    \
 	$(OBJ)\rfc2459_asn1-priv.h  \
+	$(OBJ)\rfc4043_asn1-priv.h  \
+	$(OBJ)\rfc4108_asn1-priv.h  \
 	$(OBJ)\pkcs8_asn1-priv.h    \
 	$(OBJ)\pkcs9_asn1-priv.h    \
 	$(OBJ)\pkcs10_asn1-priv.h   \
diff --git a/lib/asn1/libasn1-exports.def b/lib/asn1/libasn1-exports.def
index 30bad8ff0..d0fcae4e3 100644
--- a/lib/asn1/libasn1-exports.def
+++ b/lib/asn1/libasn1-exports.def
@@ -19,6 +19,14 @@ EXPORTS
 	asn1_KDCFastFlags_units
 	asn1_KDCOptions_units
 	asn1_KeyUsage_units
+	asn1_oid_id_aa_communityIdentifiers	DATA
+	asn1_oid_id_aa_decryptKeyID	DATA
+	asn1_oid_id_aa_firmwarePackageID	DATA
+	asn1_oid_id_aa_firmwarePackageInfo	DATA
+	asn1_oid_id_aa_implCompressAlgs	DATA
+	asn1_oid_id_aa_implCryptoAlgs	DATA
+	asn1_oid_id_aa_targetHardwareIDs	DATA
+	asn1_oid_id_aa_wrappedFirmwareKey	DATA
 	asn1_oid_id_aes_128_cbc	DATA
 	asn1_oid_id_aes_192_cbc	DATA
 	asn1_oid_id_aes_256_cbc	DATA
@@ -40,6 +48,9 @@ EXPORTS
 	asn1_oid_id_at_streetAddress	DATA
 	asn1_oid_id_at_surname	DATA
 	asn1_oid_id_at_title	DATA
+	asn1_oid_id_ct_firmwareLoadError	DATA
+	asn1_oid_id_ct_firmwareLoadReceipt	DATA
+	asn1_oid_id_ct_firmwarePackage	DATA
 	asn1_oid_id_dhpublicnumber	DATA
 	asn1_oid_id_domainComponent	DATA
 	asn1_oid_id_dsa	DATA
@@ -73,6 +84,9 @@ EXPORTS
 	asn1_oid_id_nist_aes_algs	DATA
 	asn1_oid_id_nistAlgorithm	DATA
 	asn1_oid_id_nist_sha_algs	DATA
+	asn1_oid_id_on	DATA
+	asn1_oid_id_on_hardwareModuleName	DATA
+	asn1_oid_id_on_permanentIdentifier	DATA
 	asn1_oid_id_pbeWithSHAAnd128BitRC2_CBC	DATA
 	asn1_oid_id_pbeWithSHAAnd128BitRC4	DATA
 	asn1_oid_id_pbeWithSHAAnd2_KeyTripleDES_CBC	DATA
@@ -274,12 +288,16 @@ EXPORTS
 	copy_CMSIdentifier
 	copy_CMSRC2CBCParameter
 	copy_CMSVersion
+	copy_CommunityIdentifier
+	copy_CommunityIdentifiers
 	copy_ContentEncryptionAlgorithmIdentifier
 	copy_ContentInfo
 	copy_ContentType
 	copy_CRLCertificateList
 	copy_CRLDistributionPoints
 	copy_CRLReason
+	copy_CurrentFWConfig
+	copy_DecryptKeyIdentifier
 	copy_DHNonce
 	copy_DHParameter
 	copy_DHPublicKey
@@ -334,14 +352,27 @@ EXPORTS
 	copy_ExternalPrincipalIdentifiers
 	copy_ExtKeyUsage
 	copy_FastOptions
+	copy_FirmwarePackageIdentifier
+	copy_FirmwarePackageInfo
+	copy_FirmwarePackageLoadError
+	copy_FirmwarePackageLoadErrorCode
+	copy_FirmwarePackageLoadReceipt
+	copy_FirmwarePkgData
+	copy_FWErrorVersion
+	copy_FWReceiptVersion
 	copy_GeneralName
 	copy_GeneralNames
 	copy_GeneralSubtree
 	copy_GeneralSubtrees
+	copy_HardwareModuleName
+	copy_HardwareModules
+	copy_HardwareSerialEntry
 	copy_heim_any
 	copy_heim_any_set
 	copy_HostAddress
 	copy_HostAddresses
+	copy_ImplementedCompressAlgorithms
+	copy_ImplementedCryptoAlgorithms
 	copy_IssuerAndSerialNumber
 	copy_KDCDHKeyInfo
 	copy_KDCDHKeyInfo_Win2k
@@ -442,6 +473,7 @@ EXPORTS
 	copy_PA_ServerReferralData
 	copy_PA_SERVER_REFERRAL_DATA
 	copy_PA_SvrReferralData
+	copy_PermanentIdentifier
 	copy_PKAuthenticator
 	copy_PKAuthenticator_Win2k
 	copy_PKCS12_Attribute
@@ -465,6 +497,9 @@ EXPORTS
 	copy_PkinitSP80056AOtherInfo
 	copy_PkinitSuppPubInfo
 	copy_PKIXXmppAddr
+	copy_PreferredOrLegacyPackageIdentifier
+	copy_PreferredOrLegacyStalePackageIdentifier
+	copy_PreferredPackageIdentifier
 	copy_Principal
 	copy_PrincipalName
 	copy_Principals
@@ -491,6 +526,7 @@ EXPORTS
 	copy_SubjectInfoAccessSyntax
 	copy_SubjectKeyIdentifier
 	copy_SubjectPublicKeyInfo
+	copy_TargetHardwareIdentifiers
 	copy_TBSCertificate
 	copy_TBSCRLCertList
 	copy_TD_DH_PARAMETERS
@@ -510,7 +546,9 @@ EXPORTS
 	copy_UnprotectedAttributes
 	copy_ValidationParms
 	copy_Validity
+	copy_VendorLoadErrorCode
 	copy_Version
+	copy_WrappedFirmwareKey
 	decode_AccessDescription
 	decode_AD_AND_OR
 	decode_AD_IF_RELEVANT
@@ -556,12 +594,16 @@ EXPORTS
 	decode_CMSIdentifier
 	decode_CMSRC2CBCParameter
 	decode_CMSVersion
+	decode_CommunityIdentifier
+	decode_CommunityIdentifiers
 	decode_ContentEncryptionAlgorithmIdentifier
 	decode_ContentInfo
 	decode_ContentType
 	decode_CRLCertificateList
 	decode_CRLDistributionPoints
 	decode_CRLReason
+	decode_CurrentFWConfig
+	decode_DecryptKeyIdentifier
 	decode_DHNonce
 	decode_DHParameter
 	decode_DHPublicKey
@@ -616,14 +658,27 @@ EXPORTS
 	decode_ExternalPrincipalIdentifiers
 	decode_ExtKeyUsage
 	decode_FastOptions
+	decode_FirmwarePackageIdentifier
+	decode_FirmwarePackageInfo
+	decode_FirmwarePackageLoadError
+	decode_FirmwarePackageLoadErrorCode
+	decode_FirmwarePackageLoadReceipt
+	decode_FirmwarePkgData
+	decode_FWErrorVersion
+	decode_FWReceiptVersion
 	decode_GeneralName
 	decode_GeneralNames
 	decode_GeneralSubtree
 	decode_GeneralSubtrees
+	decode_HardwareModuleName
+	decode_HardwareModules
+	decode_HardwareSerialEntry
 	decode_heim_any
 	decode_heim_any_set
 	decode_HostAddress
 	decode_HostAddresses
+	decode_ImplementedCompressAlgorithms
+	decode_ImplementedCryptoAlgorithms
 	decode_IssuerAndSerialNumber
 	decode_KDCDHKeyInfo
 	decode_KDCDHKeyInfo_Win2k
@@ -724,6 +779,7 @@ EXPORTS
 	decode_PA_ServerReferralData
 	decode_PA_SERVER_REFERRAL_DATA
 	decode_PA_SvrReferralData
+	decode_PermanentIdentifier
 	decode_PKAuthenticator
 	decode_PKAuthenticator_Win2k
 	decode_PKCS12_Attribute
@@ -747,6 +803,9 @@ EXPORTS
 	decode_PkinitSP80056AOtherInfo
 	decode_PkinitSuppPubInfo
 	decode_PKIXXmppAddr
+	decode_PreferredOrLegacyPackageIdentifier
+	decode_PreferredOrLegacyStalePackageIdentifier
+	decode_PreferredPackageIdentifier
 	decode_Principal
 	decode_PrincipalName
 	decode_Principals
@@ -773,6 +832,7 @@ EXPORTS
 	decode_SubjectInfoAccessSyntax
 	decode_SubjectKeyIdentifier
 	decode_SubjectPublicKeyInfo
+	decode_TargetHardwareIdentifiers
 	decode_TBSCertificate
 	decode_TBSCRLCertList
 	decode_TD_DH_PARAMETERS
@@ -792,7 +852,9 @@ EXPORTS
 	decode_UnprotectedAttributes
 	decode_ValidationParms
 	decode_Validity
+	decode_VendorLoadErrorCode
 	decode_Version
+	decode_WrappedFirmwareKey
 	der_copy_bit_string
 	der_copy_bmp_string
 	der_copy_generalized_time
@@ -965,12 +1027,16 @@ EXPORTS
 	encode_CMSIdentifier
 	encode_CMSRC2CBCParameter
 	encode_CMSVersion
+	encode_CommunityIdentifier
+	encode_CommunityIdentifiers
 	encode_ContentEncryptionAlgorithmIdentifier
 	encode_ContentInfo
 	encode_ContentType
 	encode_CRLCertificateList
 	encode_CRLDistributionPoints
 	encode_CRLReason
+	encode_CurrentFWConfig
+	encode_DecryptKeyIdentifier
 	encode_DHNonce
 	encode_DHParameter
 	encode_DHPublicKey
@@ -1025,14 +1091,27 @@ EXPORTS
 	encode_ExternalPrincipalIdentifiers
 	encode_ExtKeyUsage
 	encode_FastOptions
+	encode_FirmwarePackageIdentifier
+	encode_FirmwarePackageInfo
+	encode_FirmwarePackageLoadError
+	encode_FirmwarePackageLoadErrorCode
+	encode_FirmwarePackageLoadReceipt
+	encode_FirmwarePkgData
+	encode_FWErrorVersion
+	encode_FWReceiptVersion
 	encode_GeneralName
 	encode_GeneralNames
 	encode_GeneralSubtree
 	encode_GeneralSubtrees
+	encode_HardwareModuleName
+	encode_HardwareModules
+	encode_HardwareSerialEntry
 	encode_heim_any
 	encode_heim_any_set
 	encode_HostAddress
 	encode_HostAddresses
+	encode_ImplementedCompressAlgorithms
+	encode_ImplementedCryptoAlgorithms
 	encode_IssuerAndSerialNumber
 	encode_KDCDHKeyInfo
 	encode_KDCDHKeyInfo_Win2k
@@ -1133,6 +1212,7 @@ EXPORTS
 	encode_PA_ServerReferralData
 	encode_PA_SERVER_REFERRAL_DATA
 	encode_PA_SvrReferralData
+	encode_PermanentIdentifier
 	encode_PKAuthenticator
 	encode_PKAuthenticator_Win2k
 	encode_PKCS12_Attribute
@@ -1156,6 +1236,9 @@ EXPORTS
 	encode_PkinitSP80056AOtherInfo
 	encode_PkinitSuppPubInfo
 	encode_PKIXXmppAddr
+	encode_PreferredOrLegacyPackageIdentifier
+	encode_PreferredOrLegacyStalePackageIdentifier
+	encode_PreferredPackageIdentifier
 	encode_Principal
 	encode_PrincipalName
 	encode_Principals
@@ -1182,6 +1265,7 @@ EXPORTS
 	encode_SubjectInfoAccessSyntax
 	encode_SubjectKeyIdentifier
 	encode_SubjectPublicKeyInfo
+	encode_TargetHardwareIdentifiers
 	encode_TBSCertificate
 	encode_TBSCRLCertList
 	encode_TD_DH_PARAMETERS
@@ -1201,7 +1285,9 @@ EXPORTS
 	encode_UnprotectedAttributes
 	encode_ValidationParms
 	encode_Validity
+	encode_VendorLoadErrorCode
 	encode_Version
+	encode_WrappedFirmwareKey
 	FastOptions2int
 	free_AccessDescription
 	free_AD_AND_OR
@@ -1248,12 +1334,16 @@ EXPORTS
 	free_CMSIdentifier
 	free_CMSRC2CBCParameter
 	free_CMSVersion
+	free_CommunityIdentifier
+	free_CommunityIdentifiers
 	free_ContentEncryptionAlgorithmIdentifier
 	free_ContentInfo
 	free_ContentType
 	free_CRLCertificateList
 	free_CRLDistributionPoints
 	free_CRLReason
+	free_CurrentFWConfig
+	free_DecryptKeyIdentifier
 	free_DHNonce
 	free_DHParameter
 	free_DHPublicKey
@@ -1308,14 +1398,27 @@ EXPORTS
 	free_ExternalPrincipalIdentifiers
 	free_ExtKeyUsage
 	free_FastOptions
+	free_FirmwarePackageIdentifier
+	free_FirmwarePackageInfo
+	free_FirmwarePackageLoadError
+	free_FirmwarePackageLoadErrorCode
+	free_FirmwarePackageLoadReceipt
+	free_FirmwarePkgData
+	free_FWErrorVersion
+	free_FWReceiptVersion
 	free_GeneralName
 	free_GeneralNames
 	free_GeneralSubtree
 	free_GeneralSubtrees
+	free_HardwareModuleName
+	free_HardwareModules
+	free_HardwareSerialEntry
 	free_heim_any
 	free_heim_any_set
 	free_HostAddress
 	free_HostAddresses
+	free_ImplementedCompressAlgorithms
+	free_ImplementedCryptoAlgorithms
 	free_IssuerAndSerialNumber
 	free_KDCDHKeyInfo
 	free_KDCDHKeyInfo_Win2k
@@ -1416,6 +1519,7 @@ EXPORTS
 	free_PA_ServerReferralData
 	free_PA_SERVER_REFERRAL_DATA
 	free_PA_SvrReferralData
+	free_PermanentIdentifier
 	free_PKAuthenticator
 	free_PKAuthenticator_Win2k
 	free_PKCS12_Attribute
@@ -1439,6 +1543,9 @@ EXPORTS
 	free_PkinitSP80056AOtherInfo
 	free_PkinitSuppPubInfo
 	free_PKIXXmppAddr
+	free_PreferredOrLegacyPackageIdentifier
+	free_PreferredOrLegacyStalePackageIdentifier
+	free_PreferredPackageIdentifier
 	free_Principal
 	free_PrincipalName
 	free_Principals
@@ -1465,6 +1572,7 @@ EXPORTS
 	free_SubjectInfoAccessSyntax
 	free_SubjectKeyIdentifier
 	free_SubjectPublicKeyInfo
+	free_TargetHardwareIdentifiers
 	free_TBSCertificate
 	free_TBSCRLCertList
 	free_TD_DH_PARAMETERS
@@ -1484,7 +1592,9 @@ EXPORTS
 	free_UnprotectedAttributes
 	free_ValidationParms
 	free_Validity
+	free_VendorLoadErrorCode
 	free_Version
+	free_WrappedFirmwareKey
 	heim_any_cmp
 	_heim_der_set_sort
 	_heim_fix_dce
@@ -1552,12 +1662,16 @@ EXPORTS
 	length_CMSIdentifier
 	length_CMSRC2CBCParameter
 	length_CMSVersion
+	length_CommunityIdentifier
+	length_CommunityIdentifiers
 	length_ContentEncryptionAlgorithmIdentifier
 	length_ContentInfo
 	length_ContentType
 	length_CRLCertificateList
 	length_CRLDistributionPoints
 	length_CRLReason
+	length_CurrentFWConfig
+	length_DecryptKeyIdentifier
 	length_DHNonce
 	length_DHParameter
 	length_DHPublicKey
@@ -1612,14 +1726,27 @@ EXPORTS
 	length_ExternalPrincipalIdentifiers
 	length_ExtKeyUsage
 	length_FastOptions
+	length_FirmwarePackageIdentifier
+	length_FirmwarePackageInfo
+	length_FirmwarePackageLoadError
+	length_FirmwarePackageLoadErrorCode
+	length_FirmwarePackageLoadReceipt
+	length_FirmwarePkgData
+	length_FWErrorVersion
+	length_FWReceiptVersion
 	length_GeneralName
 	length_GeneralNames
 	length_GeneralSubtree
 	length_GeneralSubtrees
+	length_HardwareModuleName
+	length_HardwareModules
+	length_HardwareSerialEntry
 	length_heim_any
 	length_heim_any_set
 	length_HostAddress
 	length_HostAddresses
+	length_ImplementedCompressAlgorithms
+	length_ImplementedCryptoAlgorithms
 	length_IssuerAndSerialNumber
 	length_KDCDHKeyInfo
 	length_KDCDHKeyInfo_Win2k
@@ -1720,6 +1847,7 @@ EXPORTS
 	length_PA_ServerReferralData
 	length_PA_SERVER_REFERRAL_DATA
 	length_PA_SvrReferralData
+	length_PermanentIdentifier
 	length_PKAuthenticator
 	length_PKAuthenticator_Win2k
 	length_PKCS12_Attribute
@@ -1743,6 +1871,9 @@ EXPORTS
 	length_PkinitSP80056AOtherInfo
 	length_PkinitSuppPubInfo
 	length_PKIXXmppAddr
+	length_PreferredOrLegacyPackageIdentifier
+	length_PreferredOrLegacyStalePackageIdentifier
+	length_PreferredPackageIdentifier
 	length_Principal
 	length_PrincipalName
 	length_Principals
@@ -1769,6 +1900,7 @@ EXPORTS
 	length_SubjectInfoAccessSyntax
 	length_SubjectKeyIdentifier
 	length_SubjectPublicKeyInfo
+	length_TargetHardwareIdentifiers
 	length_TBSCertificate
 	length_TBSCRLCertList
 	length_TD_DH_PARAMETERS
@@ -1788,7 +1920,9 @@ EXPORTS
 	length_UnprotectedAttributes
 	length_ValidationParms
 	length_Validity
+	length_VendorLoadErrorCode
 	length_Version
+	length_WrappedFirmwareKey
 	remove_AttributeValues
 	remove_AuthorizationData
 	remove_Certificates
diff --git a/lib/asn1/rfc4043.asn1 b/lib/asn1/rfc4043.asn1
new file mode 100644
index 000000000..5e85c59cc
--- /dev/null
+++ b/lib/asn1/rfc4043.asn1
@@ -0,0 +1,30 @@
+PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6)
+       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-perm-id-88(28) }
+
+DEFINITIONS EXPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+   -- IMPORTS id-pkix FROM rfc2459; but asn1_compile doesn't handle this
+
+
+   -- Permanent identifier Object Identifier and Syntax
+
+   id-on   OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+               dod(6) internet(1) security(5) mechanisms(5) pkix(7) 8 }
+
+   id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+
+   PermanentIdentifier ::= SEQUENCE {
+        identifierValue    UTF8String             OPTIONAL,
+                        -- if absent, use the serialNumber attribute
+                        -- if there is a single such attribute present
+                        -- in the subject DN
+        assigner           OBJECT IDENTIFIER      OPTIONAL
+                        -- if absent, the assigner is
+                        -- the certificate issuer
+}
+
+END
diff --git a/lib/asn1/rfc4108.asn1 b/lib/asn1/rfc4108.asn1
new file mode 100644
index 000000000..29405acaf
--- /dev/null
+++ b/lib/asn1/rfc4108.asn1
@@ -0,0 +1,202 @@
+CMSFirmwareWrapper
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+      pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
+
+DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+IMPORTS
+    EnvelopedData
+    FROM cms -- [CMS]
+         { iso(1) member-body(2) us(840) rsadsi(113549)
+           pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
+
+
+-- Firmware Package Content Type and Object Identifier
+
+id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) ct(1) 16 }
+
+FirmwarePkgData ::= OCTET STRING
+
+
+-- Firmware Package Signed Attributes and Object Identifiers
+
+id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 35 }
+
+PreferredPackageIdentifier ::= SEQUENCE {
+  fwPkgID OBJECT IDENTIFIER,
+  verNum INTEGER (0..MAX) }
+
+PreferredOrLegacyPackageIdentifier ::= CHOICE {
+  preferred PreferredPackageIdentifier,
+  legacy OCTET STRING }
+
+PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+  preferredStaleVerNum INTEGER (0..MAX),
+  legacyStaleVersion OCTET STRING }
+
+FirmwarePackageIdentifier ::= SEQUENCE {
+  name PreferredOrLegacyPackageIdentifier,
+  stale PreferredOrLegacyStalePackageIdentifier 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
+
+
+id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 37 }
+
+DecryptKeyIdentifier ::= OCTET STRING
+
+
+id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 38 }
+
+ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 43 }
+
+ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 40 }
+
+HardwareSerialEntry ::= CHOICE {
+  all NULL,
+  single OCTET STRING,
+  block SEQUENCE {
+    low OCTET STRING,
+    high OCTET STRING } }
+
+HardwareModules ::= SEQUENCE {
+  hwType OBJECT IDENTIFIER,
+  hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+CommunityIdentifier ::= CHOICE {
+  communityOID OBJECT IDENTIFIER,
+  hwModuleList HardwareModules }
+
+CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 42 }
+
+FirmwarePackageInfo ::= SEQUENCE {
+  fwPkgType INTEGER OPTIONAL,
+  dependencies SEQUENCE OF
+    PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+
+-- Firmware Package Unsigned Attributes and Object Identifiers
+
+id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) aa(2) 39 }
+
+WrappedFirmwareKey ::= EnvelopedData
+
+
+-- Firmware Package Load Receipt Content Type and Object Identifier
+
+id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) ct(1) 17 }
+
+FWReceiptVersion ::= INTEGER { v1(1) }
+
+FirmwarePackageLoadReceipt ::= SEQUENCE {
+  version FWReceiptVersion DEFAULT 1, -- v1, but asn1_compile doesn't handle this
+  hwType OBJECT IDENTIFIER,
+  hwSerialNum OCTET STRING,
+  fwPkgName PreferredOrLegacyPackageIdentifier,
+  trustAnchorKeyID OCTET STRING OPTIONAL,
+  decryptKeyID [1] OCTET STRING OPTIONAL }
+
+-- Firmware Package Load Error Report Content Type
+-- and Object Identifier
+
+id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+  smime(16) ct(1) 18 }
+
+FWErrorVersion ::= FWReceiptVersion
+
+FirmwarePackageLoadErrorCode ::= ENUMERATED {
+  decodeFailure                (1),
+  badContentInfo               (2),
+  badSignedData                (3),
+  badEncapContent              (4),
+  badCertificate               (5),
+  badSignerInfo                (6),
+  badSignedAttrs               (7),
+  badUnsignedAttrs             (8),
+  missingContent               (9),
+  noTrustAnchor               (10),
+  notAuthorized               (11),
+  badDigestAlgorithm          (12),
+  badSignatureAlgorithm       (13),
+  unsupportedKeySize          (14),
+  signatureFailure            (15),
+  contentTypeMismatch         (16),
+  badEncryptedData            (17),
+  unprotectedAttrsPresent     (18),
+  badEncryptContent           (19),
+  badEncryptAlgorithm         (20),
+  missingCiphertext           (21),
+  noDecryptKey                (22),
+  decryptFailure              (23),
+  badCompressAlgorithm        (24),
+  missingCompressedContent    (25),
+  decompressFailure           (26),
+  wrongHardware               (27),
+  stalePackage                (28),
+  notInCommunity              (29),
+  unsupportedPackageType      (30),
+  missingDependency           (31),
+  wrongDependencyVersion      (32),
+  insufficientMemory          (33),
+  badFirmware                 (34),
+  unsupportedParameters       (35),
+  breaksDependency            (36),
+  otherError                  (99) }
+
+VendorLoadErrorCode ::= INTEGER
+
+CurrentFWConfig ::= SEQUENCE {
+  fwPkgType INTEGER OPTIONAL,
+  fwPkgName PreferredOrLegacyPackageIdentifier }
+
+FirmwarePackageLoadError ::= SEQUENCE {
+  version FWErrorVersion DEFAULT 1, -- v1, but see above
+  hwType OBJECT IDENTIFIER,
+  hwSerialNum OCTET STRING,
+  errorCode FirmwarePackageLoadErrorCode,
+  vendorErrorCode VendorLoadErrorCode OPTIONAL,
+  fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
+  config [1] SEQUENCE OF CurrentFWConfig 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