| blob | 8119548a92c38820481adaa4751dafede3cf057d |
7 Network Working Group R. Housley
8 Request for Comments: 4108 Vigil Security
9 Category: Standards Track August 2005
12 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
14 Status of This Memo
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
22 Copyright Notice
24 Copyright (C) The Internet Society (2005).
26 Abstract
28 This document describes the use of the Cryptographic Message Syntax
29 (CMS) to protect firmware packages, which provide object code for one
30 or more hardware module components. CMS is specified in RFC 3852. A
31 digital signature is used to protect the firmware package from
32 undetected modification and to provide data origin authentication.
33 Encryption is optionally used to protect the firmware package from
34 disclosure, and compression is optionally used to reduce the size of
35 the protected firmware package. A firmware package loading receipt
36 can optionally be generated to acknowledge the successful loading of
37 a firmware package. Similarly, a firmware package load error report
38 can optionally be generated to convey the failure to load a firmware
39 package.
58 Housley Standards Track [Page 1]
59 \f
60 RFC 4108 Using CMS to Protect Firmware Packages August 2005
63 Table of Contents
65 1. Introduction ....................................................3
66 1.1. Terminology ................................................5
67 1.2. Architectural Elements .....................................5
68 1.2.1. Hardware Module Requirements ........................7
69 1.2.2. Firmware Package Requirements .......................8
70 1.2.3. Bootstrap Loader Requirements .......................9
71 1.2.3.1. Legacy Stale Version Processing ...........11
72 1.2.3.2. Preferred Stale Version Processing ........12
73 1.2.4. Trust Anchors ......................................12
74 1.2.5. Cryptographic and Compression Algorithm
75 Requirements .......................................13
76 1.3. Hardware Module Security Architecture .....................14
77 1.4. ASN.1 Encoding ............................................14
78 1.5. Protected Firmware Package Loading ........................15
79 2. Firmware Package Protection ....................................15
80 2.1. Firmware Package Protection CMS Content Type Profile ......18
81 2.1.1. ContentInfo ........................................18
82 2.1.2. SignedData .........................................18
83 2.1.2.1. SignerInfo ................................19
84 2.1.2.2. EncapsulatedContentInfo ...................20
85 2.1.3. EncryptedData ......................................20
86 2.1.3.1. EncryptedContentInfo ......................21
87 2.1.4. CompressedData .....................................21
88 2.1.4.1. EncapsulatedContentInfo ...................22
89 2.1.5. FirmwarePkgData ....................................22
90 2.2. Signed Attributes .........................................22
91 2.2.1. Content Type .......................................23
92 2.2.2. Message Digest .....................................24
93 2.2.3. Firmware Package Identifier ........................24
94 2.2.4. Target Hardware Module Identifiers .................25
95 2.2.5. Decrypt Key Identifier .............................26
96 2.2.6. Implemented Crypto Algorithms ......................26
97 2.2.7. Implemented Compression Algorithms .................27
98 2.2.8. Community Identifiers ..............................27
99 2.2.9. Firmware Package Information .......................29
100 2.2.10. Firmware Package Message Digest ...................30
101 2.2.11. Signing Time ......................................30
102 2.2.12. Content Hints .....................................31
103 2.2.13. Signing Certificate ...............................31
104 2.3. Unsigned Attributes .......................................32
105 2.3.1. Wrapped Firmware Decryption Key ....................33
106 3. Firmware Package Load Receipt ..................................34
107 3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
108 3.1.1. ContentInfo ........................................36
114 Housley Standards Track [Page 2]
115 \f
116 RFC 4108 Using CMS to Protect Firmware Packages August 2005
119 3.1.2. SignedData .........................................36
120 3.1.2.1. SignerInfo ................................37
121 3.1.2.2. EncapsulatedContentInfo ...................38
122 3.1.3. FirmwarePackageLoadReceipt .........................38
123 3.2. Signed Attributes .........................................40
124 3.2.1. Content Type .......................................40
125 3.2.2. Message Digest .....................................40
126 3.2.3. Signing Time .......................................40
127 4. Firmware Package Load Error ....................................41
128 4.1. Firmware Package Load Error CMS Content Type Profile ......42
129 4.1.1. ContentInfo ........................................42
130 4.1.2. SignedData .........................................43
131 4.1.2.1. SignerInfo ................................43
132 4.1.2.2. EncapsulatedContentInfo ...................43
133 4.1.3. FirmwarePackageLoadError ...........................43
134 4.2. Signed Attributes .........................................49
135 4.2.1. Content Type .......................................49
136 4.2.2. Message Digest .....................................49
137 4.2.3. Signing Time .......................................50
138 5. Hardware Module Name ...........................................50
139 6. Security Considerations ........................................51
140 6.1. Cryptographic Keys and Algorithms .........................51
141 6.2. Random Number Generation ..................................51
142 6.3. Stale Firmware Package Version Number .....................52
143 6.4. Community Identifiers .....................................53
144 7. References .....................................................54
145 7.1. Normative References ......................................54
146 7.2. Informative References ....................................54
147 Appendix A: ASN.1 Module ..........................................56
149 1. Introduction
151 This document describes the use of the Cryptographic Message Syntax
152 (CMS) [CMS] to protect firmware packages. This document also
153 describes the use of CMS for receipts and error reports for firmware
154 package loading. The CMS is a data protection encapsulation syntax
155 that makes use of ASN.1 [X.208-88, X.209-88]. The protected firmware
156 package can be associated with any particular hardware module;
157 however, this specification was written with the requirements of
158 cryptographic hardware modules in mind, as these modules have strong
159 security requirements.
161 The firmware package contains object code for one or more
162 programmable components that make up the hardware module. The
163 firmware package, which is treated as an opaque binary object, is
164 digitally signed. Optional encryption and compression are also
165 supported. When all three are used, the firmware package is
166 compressed, then encrypted, and then signed. Compression simply
170 Housley Standards Track [Page 3]
171 \f
172 RFC 4108 Using CMS to Protect Firmware Packages August 2005
175 reduces the size of the firmware package, allowing more efficient
176 processing and transmission. Encryption protects the firmware
177 package from disclosure, which allows transmission of sensitive
178 firmware packages over insecure links. The encryption algorithm and
179 mode employed may also provide integrity, protecting the firmware
180 package from undetected modification. The encryption protects
181 proprietary algorithms, classified algorithms, trade secrets, and
182 implementation techniques. The digital signature protects the
183 firmware package from undetected modification and provides data
184 origin authentication. The digital signature allows the hardware
185 module to confirm that the firmware package comes from an acceptable
186 source.
188 If encryption is used, the firmware-decryption key must be made
189 available to the hardware module via a secure path. The key might be
190 delivered via physical media or via an independent electronic path.
191 One optional mechanism for distributing the firmware-decryption key
192 is specified in Section 2.3.1, but any secure key distribution
193 mechanism is acceptable.
195 The signature verification public key must be made available to the
196 hardware module in a manner that preserves its integrity and confirms
197 its source. CMS supports the transfer of certificates, and this
198 facility can be used to transfer a certificate that contains the
199 signature verification public key (a firmware-signing certificate).
200 However, use of this facility introduces a level of indirection.
201 Ultimately, a trust anchor public key must be made available to the
202 hardware module. Section 1.2 establishes a requirement that the
203 hardware module store one or more trust anchors.
205 Hardware modules may not be capable of accessing certificate
206 repositories or delegated path discovery (DPD) servers [DPD&DPV] to
207 acquire certificates needed to complete a certification path. Thus,
208 it is the responsibility of the firmware package signer to include
209 sufficient certificates to enable each module to validate the
210 firmware-signer certificate (see Section 2.1.2). Similarly, hardware
211 modules may not be capable of accessing a certificate revocation list
212 (CRL) repository, an OCSP responder [OCSP], or a delegated path
213 validation (DPV) server [DPD&DPV] to acquire revocation status
214 information. Thus, if the firmware package signature cannot be
215 validated solely with the trust anchor public key and the hardware
216 module is not capable of performing full certification path
217 validation, then it is the responsibility of the entity loading a
218 package into a hardware module to validate the firmware-signer
219 certification path prior to loading the package into a hardware
220 module. The means by which this external certificate revocation
221 status checking is performed is beyond the scope of this
222 specification.
226 Housley Standards Track [Page 4]
227 \f
228 RFC 4108 Using CMS to Protect Firmware Packages August 2005
231 Hardware modules will only accept firmware packages with a valid
232 digital signature. The signature is either validated directly using
233 the trust anchor public key or using a firmware-signer certification
234 path that is validated to the trust anchor public key. Thus, the
235 trust anchors define the set of entities that can create firmware
236 packages for the hardware module.
238 The disposition of a previously loaded firmware package after the
239 successful validation of another firmware package is beyond the scope
240 of this specification. The amount of memory available to the
241 hardware module will determine the range of alternatives.
243 In some cases, hardware modules can generate receipts to acknowledge
244 the loading of a particular firmware package. Such receipts can be
245 used to determine which hardware modules need to receive an updated
246 firmware package whenever a flaw in an earlier firmware package is
247 discovered. Hardware modules can also generate error reports to
248 indicate the unsuccessful firmware package loading. To implement
249 either receipt or error report generation, the hardware module is
250 required to have a unique permanent serial number. Receipts and
251 error reports can be either signed or unsigned. To generate
252 digitally signed receipts or error reports, a hardware module MUST be
253 issued its own private signature key and a certificate that contains
254 the corresponding signature validation public key. In order to save
255 memory with the hardware module, the hardware module might store a
256 certificate designator instead of the certificate itself. The
257 private signature key requires secure storage.
259 1.1. Terminology
261 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
262 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
263 described in [STDWORDS].
265 1.2. Architectural Elements
267 The architecture includes the hardware module, the firmware package,
268 and a bootstrap loader. The bootstrap loader MUST have access to one
269 or more trusted public keys, called trust anchors, to validate the
270 signature on the firmware package. If a signed firmware package load
271 receipt or error report is created on behalf of the hardware module,
272 then the bootstrap loader MUST have access to a private signature key
273 to generate the signature and the signer identifier for the
274 corresponding signature validation certificate or its designator. A
275 signature validation certificate MAY be included to aid signature
276 validation. To implement this optional capability, the hardware
277 module MUST have a unique serial number and a private signature key;
278 the hardware module MAY also include a certificate that contains the
282 Housley Standards Track [Page 5]
283 \f
284 RFC 4108 Using CMS to Protect Firmware Packages August 2005
287 corresponding signature validation public key. These items MUST be
288 installed in the hardware module before it is deployed. The private
289 key and certificate can be generated and installed as part of the
290 hardware module manufacture process. Figure 1 illustrates these
291 architectural elements.
293 ASN.1 object identifiers are the preferred means of naming the
294 architectural elements.
296 Details of managing the trust anchors are beyond the scope of this
297 specification. However, one or more trust anchors MUST be installed
298 in the hardware module using a secure process before it is deployed.
299 These trust anchors provide a means of controlling the acceptable
300 sources of firmware packages. The hardware module vendor can include
301 provisions for secure, remote management of trust anchors. One
302 approach is to include trust anchors in the firmware packages
303 themselves. This approach is analogous to the optional capability
304 described later for updating the bootstrap loader.
306 In a cryptographic hardware module, the firmware package might
307 implement many different cryptographic algorithms.
309 When the firmware package is encrypted, the firmware-decryption key
310 and the firmware package MUST both be provided to the hardware
311 module. The firmware-decryption key is necessary to use the
312 associated firmware package. Generally, separate distribution
313 mechanisms will be employed for the firmware-decryption key and the
314 firmware package. An optional mechanism for securely distributing
315 the firmware-decryption key with the firmware package is specified in
316 Section 2.3.1.
338 Housley Standards Track [Page 6]
339 \f
340 RFC 4108 Using CMS to Protect Firmware Packages August 2005
343 +------------------------------------------------------+
344 | Hardware Module |
345 | |
346 | +---------------+ +--------------------------+ |
347 | | Bootstrap | | Firmware Package | |
348 | | Loader | | | |
349 | +---------------+ | +------------------+ | |
350 | | : Firmware Package : | |
351 | +---------------+ | : Identifier and : | |
352 | | Trust | | : Version Number : | |
353 | | Anchor(s) | | +------------------+ | |
354 | +---------------+ | | |
355 | | +-------------+ | |
356 | +---------------+ | : Algorithm 1 : | |
357 | | Serial Num. | | +-+-----------+-+ | |
358 | +---------------+ | : Algorithm 2 : | |
359 | | +-+-----------+-+ | |
360 | +---------------+ | : Algorithm n : | |
361 | | Hardware | | +-------------+ | |
362 | | Module Type | | | |
363 | +---------------+ +--------------------------+ |
364 | |
365 | +------------------------------------+ |
366 | | Optional Private Signature Key & | |
367 | | Signature Validation Certificate | |
368 | | or the Certificate Designator | |
369 | +------------------------------------+ |
370 | |
371 +------------------------------------------------------+
373 Figure 1. Architectural Elements
375 1.2.1. Hardware Module Requirements
377 Many different vendors develop hardware modules, and each vendor
378 typically identifies its modules by product type (family) and
379 revision level. A unique object identifier MUST name each hardware
380 module type and revision.
382 Each hardware module within a hardware module family SHOULD have a
383 unique permanent serial number. However, if the optional receipt or
384 error report generation capability is implemented, then the hardware
385 module MUST have a unique permanent serial number. If the optional
386 receipt or error report signature capability is implemented, then the
387 hardware module MUST have a private signature key and a certificate
388 containing the corresponding public signature validation key or its
389 designator. If a serial number is present, the bootstrap loader uses
394 Housley Standards Track [Page 7]
395 \f
396 RFC 4108 Using CMS to Protect Firmware Packages August 2005
399 it for authorization decisions (see Section 2.2.8), receipt
400 generation (see Section 3), and error report generation (see
401 Section 4).
403 When the hardware module includes more than one firmware-programmable
404 component, the bootstrap loader distributes components of the package
405 to the appropriate components within the hardware module after the
406 firmware package is validated. The bootstrap loader is discussed
407 further in Section 1.2.3.
409 1.2.2. Firmware Package Requirements
411 Two approaches to naming firmware packages are supported: legacy and
412 preferred. Firmware package names are placed in a CMS signed
413 attribute, not in the firmware package itself.
415 Legacy firmware package names are simply octet strings, and no
416 structure is assumed. This firmware package name form is supported
417 in order to facilitate existing configuration management systems. We
418 assume that the firmware signer and the bootstrap loader will
419 understand any internal structure to the octet string. In
420 particular, given two legacy firmware package names, we assume that
421 the firmware signer and the bootstrap loader will be able to
422 determine which one represents the newer version of the firmware
423 package. This capability is necessary to implement the stale version
424 feature. If a firmware package with a disastrous flaw is released,
425 subsequent firmware package versions MAY designate a stale legacy
426 firmware package name in order to prevent subsequent rollback to the
427 stale version or versions earlier than the stale version.
429 Preferred firmware package names are a combination of the firmware
430 package object identifier and a version number. A unique object
431 identifier MUST identify the collection of features that characterize
432 the firmware package. For example, firmware packages for a cable
433 modem and a wireless LAN network interface card warrant distinct
434 object identifiers. Similarly, firmware packages that implement
435 distinct suites of cryptographic algorithms and modes of operation,
436 or that emulate different (non-programmable) cryptographic devices
437 warrant distinct object identifiers. The version number MUST
438 identify a particular build or release of the firmware package. The
439 version number MUST be a monotonically increasing non-negative
440 integer. Generally, an earlier version is replaced with a later one.
441 If a firmware package with a disastrous flaw is released, subsequent
442 firmware package versions MAY designate a stale version number to
443 prevent subsequent rollback to the stale version or versions earlier
444 than the stale version.
450 Housley Standards Track [Page 8]
451 \f
452 RFC 4108 Using CMS to Protect Firmware Packages August 2005
455 Firmware packages are developed to run on one or more hardware module
456 type. The firmware package digital signature MUST bind the list of
457 supported hardware module object identifiers to the firmware package.
459 In many cases, the firmware package signature will be validated
460 directly with the trust anchor public key, avoiding the need to
461 construct certification paths. Alternatively, the trust anchor can
462 delegate firmware package signing to another public key through a
463 certification path. In the latter case, the firmware package SHOULD
464 contain the certificates needed to construct the certification path
465 that begins with a certificate issued by the trust anchors and ends
466 with a certificate issued to the firmware package signer.
468 The firmware package MAY contain a list of community identifiers.
469 These identifiers name the hardware modules that are authorized to
470 load the firmware package. If the firmware package contains a list
471 of community identifiers, then the bootstrap loader MUST reject the
472 firmware package if the hardware module is not a member of one of the
473 identified communities.
475 When a hardware module includes multiple programmable components, the
476 firmware package SHOULD contain executable code for all of the
477 components. Internal tagging within the firmware package MUST tell
478 the bootstrap loader which portion of the overall firmware package is
479 intended for each component; however, this tagging is expected to be
480 specific to each hardware module. Because this specification treats
481 the firmware package as an opaque binary object, the format of the
482 firmware package is beyond the scope of this specification.
484 1.2.3. Bootstrap Loader Requirements
486 The bootstrap loader MUST have access to a physical interface and any
487 related driver or protocol software necessary to obtain a firmware
488 package. The same interface SHOULD be used to deliver receipts and
489 error reports. Details of the physical interface as well as the
490 driver or protocol software are beyond the scope of this
491 specification.
493 The bootstrap loader can be a permanent part of the hardware module,
494 or it can be replaced by loading a firmware package. In Figure 1,
495 the bootstrap loader is implemented as separate logic within the
496 hardware module. Not all hardware modules will include the ability
497 to replace or update the bootstrap loader, and this specification
498 does not mandate such support.
500 If the bootstrap loader can be loaded by a firmware package, an
501 initial bootstrap loader MUST be installed in non-volatile memory
502 prior to deployment. All bootstrap loaders, including an initial
506 Housley Standards Track [Page 9]
507 \f
508 RFC 4108 Using CMS to Protect Firmware Packages August 2005
511 bootstrap loader if one is employed, MUST meet the requirements in
512 this section. However, the firmware package containing the bootstrap
513 loader MAY also contain other routines.
515 The bootstrap loader requires access to cryptographic routines.
516 These routines can be implemented specifically for the bootstrap
517 loader, or they can be shared with other hardware module features.
518 The bootstrap loader MUST have access to a one-way hash function and
519 digital signature verification routines to validate the digital
520 signature on the firmware package and to validate the certification
521 path for the firmware-signing certificate.
523 If firmware packages are encrypted, the bootstrap loader MUST have
524 access to a decryption routine. Access to a corresponding encryption
525 function is not required, since hardware modules need not be capable
526 of generating firmware packages. Because some symmetric encryption
527 algorithm implementations (such as AES [AES]) employ separate logic
528 for encryption and decryption, some hardware module savings might
529 result.
531 If firmware packages are compressed, the bootstrap loader MUST also
532 have access to a decompression function. This function can be
533 implemented specifically for the bootstrap loader, or it can be
534 shared with other hardware module features. Access to a
535 corresponding compression function is not required, since hardware
536 modules need not be capable of generating firmware packages.
538 If the optional receipt generation or error report capability is
539 supported, the bootstrap loader MUST have access to the hardware
540 module serial number and the object identifier for the hardware
541 module type. If the optional signed receipt generation or signed
542 error report capability is supported, the bootstrap loader MUST also
543 have access to a one-way hash function and digital signature
544 routines, the hardware module private signing key, and the
545 corresponding signature validation certificate or its designator.
547 The bootstrap loader requires access to one or more trusted public
548 keys, called trust anchors, to validate the firmware package digital
549 signature. One or more trust anchors MUST be installed in non-
550 volatile memory prior to deployment. The bootstrap loader MUST
551 reject a firmware package if it cannot validate the signature, which
552 MAY require the construction of a valid certification path from the
553 firmware-signing certificate to one of the trust anchors [PROFILE].
554 However, in many cases, the firmware package signature will be
555 validated directly with the trust anchor public key, avoiding the
556 need to construct certification paths.
562 Housley Standards Track [Page 10]
563 \f
564 RFC 4108 Using CMS to Protect Firmware Packages August 2005
567 The bootstrap loader MUST reject a firmware package if the list of
568 supported hardware module type identifiers within the firmware
569 package does not include the object identifier of the hardware
570 module.
572 The bootstrap loader MUST reject a firmware package if the firmware
573 package includes a list of community identifiers and the hardware
574 module is not a member of one of the listed communities. The means
575 of determining community membership is beyond the scope of this
576 specification.
578 The bootstrap loader MUST reject a firmware package if it cannot
579 successfully decrypt the firmware package using the firmware-
580 decryption key available to the hardware module. The firmware
581 package contains an identifier of the firmware-decryption key needed
582 for decryption.
584 When an earlier version of a firmware package is replacing a later
585 one, the bootstrap loader SHOULD generate a warning. The manner in
586 which a warning is generated is highly dependent on the hardware
587 module and the environment in which it is being used. If a firmware
588 package with a disastrous flaw is released and subsequent firmware
589 package versions designate a stale version, the bootstrap loader
590 SHOULD prevent loading of the stale version and versions earlier than
591 the stale version.
593 1.2.3.1. Legacy Stale Version Processing
595 In case a firmware package with a disastrous flaw is released,
596 subsequent firmware package versions that employ the legacy firmware
597 package name form MAY include a stale legacy firmware package name to
598 prevent subsequent rollback to the stale version or versions earlier
599 than the stale version. As described in the Security Considerations
600 section of this document, the inclusion of a stale legacy firmware
601 package name in a firmware package cannot completely prevent
602 subsequent use of the stale firmware package. However, many hardware
603 modules are expected to have very few firmware packages written for
604 them, allowing the stale firmware package version feature to provide
605 important protections.
607 Non-volatile storage for stale version numbers is needed. The number
608 of stale legacy firmware package names that can be stored depends on
609 the amount of storage that is available. When a firmware package is
610 loaded and it contains a stale legacy firmware package name, then it
611 SHOULD be added to a list kept in non-volatile storage. When
612 subsequent firmware packages are loaded, the legacy firmware package
618 Housley Standards Track [Page 11]
619 \f
620 RFC 4108 Using CMS to Protect Firmware Packages August 2005
623 name of the new package is compared to the list in non-volatile
624 storage. If the legacy firmware package name represents the same
625 version or an older version of a member of the list, then the new
626 firmware packages SHOULD be rejected.
628 The amount of non-volatile storage that needs to be dedicated to
629 saving legacy firmware package names and stale legacy firmware
630 packages names depends on the number of firmware packages that are
631 likely to be developed for the hardware module.
633 1.2.3.2. Preferred Stale Version Processing
635 If a firmware package with a disastrous flaw is released, subsequent
636 firmware package versions that employ preferred firmware package name
637 form MAY include a stale version number to prevent subsequent
638 rollback to the stale version or versions earlier than the stale
639 version. As described in the Security Considerations section of this
640 document, the inclusion of a stale version number in a firmware
641 package cannot completely prevent subsequent use of the stale
642 firmware package. However, many hardware modules are expected to
643 have very few firmware packages written for them, allowing the stale
644 firmware package version feature to provide important protections.
646 Non-volatile storage for stale version numbers is needed. The number
647 of stale version numbers that can be stored depends on the amount of
648 storage that is available. When a firmware package is loaded and it
649 contains a stale version number, then the object identifier of the
650 firmware package and the stale version number SHOULD be added to a
651 list that is kept in non-volatile storage. When subsequent firmware
652 packages are loaded, the object identifier and version number of the
653 new package are compared to the list in non-volatile storage. If the
654 object identifier matches and the version number is less than or
655 equal to the stale version number, then the new firmware packages
656 SHOULD be rejected.
658 The amount of non-volatile storage that needs to be dedicated to
659 saving firmware package identifiers and stale version numbers depends
660 on the number of firmware packages that are likely to be developed
661 for the hardware module.
663 1.2.4. Trust Anchors
665 A trust anchor MUST consist of a public key signature algorithm and
666 an associated public key, which MAY optionally include parameters. A
667 trust anchor MUST also include a public key identifier. A trust
668 anchor MAY also include an X.500 distinguished name.
674 Housley Standards Track [Page 12]
675 \f
676 RFC 4108 Using CMS to Protect Firmware Packages August 2005
679 The trust anchor public key is used in conjunction with the signature
680 validation algorithm in two different ways. First, the trust anchor
681 public key is used directly to validate the firmware package
682 signature. Second, the trust anchor public key is used to validate
683 an X.509 certification path, and then the subject public key in the
684 final certificate in the certification path is used to validate the
685 firmware package signature.
687 The public key names the trust anchor, and each public key has a
688 public key identifier. The public key identifier identifies the
689 trust anchor as the signer when it is used directly to validate
690 firmware package signatures. This key identifier can be stored with
691 the trust anchor, or it can be computed from the public key whenever
692 needed.
694 The optional trusted X.500 distinguished name MUST be present in
695 order for the trust anchor public key to be used to validate an X.509
696 certification path. Without an X.500 distinguished name,
697 certification path construction cannot use the trust anchor.
699 1.2.5. Cryptographic and Compression Algorithm Requirements
701 A firmware package for a cryptographic hardware module includes
702 cryptographic algorithm implementations. In addition, a firmware
703 package for a non-cryptographic hardware module will likely include
704 cryptographic algorithm implementations to support the bootstrap
705 loader in the validation of firmware packages.
707 A unique algorithm object identifier MUST be assigned for each
708 cryptographic algorithm and mode implemented by a firmware package.
709 A unique algorithm object identifier MUST also be assigned for each
710 compression algorithm implemented by a firmware package. The
711 algorithm object identifiers can be used to determine whether a
712 particular firmware package satisfies the needs of a particular
713 application. To facilitate the development of algorithm-agile
714 applications, the cryptographic module interface SHOULD allow
715 applications to query the cryptographic module for the object
716 identifiers associated with each cryptographic algorithm contained in
717 the currently loaded firmware package. Applications SHOULD also be
718 able to query the cryptographic module to determine attributes
719 associated with each algorithm. Such attributes might include the
720 algorithm type (symmetric encryption, asymmetric encryption, key
721 agreement, one-way hash function, digital signature, and so on), the
722 algorithm block size or modulus size, and parameters for asymmetric
723 algorithms. This specification does not establish the conventions
724 for the retrieval of algorithm identifiers or algorithm attributes.
730 Housley Standards Track [Page 13]
731 \f
732 RFC 4108 Using CMS to Protect Firmware Packages August 2005
735 1.3. Hardware Module Security Architecture
737 The bootstrap loader MAY be permanently stored in read-only memory or
738 separately loaded into non-volatile memory as discussed above.
740 In most hardware module designs, the firmware package execution
741 environment offers a single address space. If it does, the firmware
742 package SHOULD contain a complete firmware package load for the
743 hardware module. In this situation, the firmware package does not
744 contain a partial or incremental set of functions. A complete
745 firmware package load will minimize complexity and avoid potential
746 security problems. From a complexity perspective, the incremental
747 loading of packages makes it necessary for each package to identify
748 any other packages that are required (its dependencies), and the
749 bootstrap loader needs to verify that all of the dependencies are
750 satisfied before attempting to execute the firmware package. When a
751 hardware module is based on a general purpose processor or a digital
752 signal processor, it is dangerous to allow arbitrary packages to be
753 loaded simultaneously unless there is a reference monitor to ensure
754 that independent portions of the code cannot interfere with one
755 another. Also, it is difficult to evaluate arbitrary combinations of
756 software modules [SECREQMTS]. For these reasons, a complete firmware
757 package load is RECOMMENDED; however, this specification allows the
758 firmware signer to identify dependencies between firmware packages in
759 order to handle all situations.
761 The firmware packages MAY have dependencies on routines provided by
762 other firmware packages. To minimize the security evaluation
763 complexity of a hardware module employing such a design, the firmware
764 package MUST identify the package identifiers (and the minimum
765 version numbers when the preferred firmware package name form is
766 used) of the packages upon which it depends. The bootstrap loader
767 MUST reject a firmware package load if it contains a dependency on a
768 firmware package that is not available.
770 Loading a firmware package can impact the satisfactory resolution of
771 dependencies of other firmware packages that are already part of the
772 hardware module configuration. For this reason, the bootstrap loader
773 MUST reject the loading of a firmware package if the dependencies of
774 any firmware package in the resulting configurations will be
775 unsatisfied.
777 1.4. ASN.1 Encoding
779 The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88,
780 X.209-88]. ASN.1 is a formal notation used for describing data
781 protocols, regardless of the programming language used by the
782 implementation. Encoding rules describe how the values defined in
786 Housley Standards Track [Page 14]
787 \f
788 RFC 4108 Using CMS to Protect Firmware Packages August 2005
791 ASN.1 will be represented for transmission. The Basic Encoding Rules
792 (BER) are the most widely employed rule set, but they offer more than
793 one way to represent data structures. For example, definite length
794 encoding and indefinite length encoding are supported. This
795 flexibility is not desirable when digital signatures are used. As a
796 result, the Distinguished Encoding Rules (DER) [X.509-88] were
797 invented. DER is a subset of BER that ensures a single way to
798 represent a given value. For example, DER always employs definite
799 length encoding.
801 In this specification, digitally signed structures MUST be encoded
802 with DER. Other structures do not require DER, but the use of
803 definite length encoding is strongly RECOMMENDED. By always using
804 definite length encoding, the bootstrap loader will have fewer
805 options to implement. In situations where there is very high
806 confidence that only definite length encoding will be used, support
807 for indefinite length decoding MAY be omitted.
809 1.5. Protected Firmware Package Loading
811 This document does not attempt to specify a physical interface, any
812 related driver software, or a protocol necessary for loading firmware
813 packages. Many different delivery mechanisms are envisioned,
814 including portable memory devices, file transfer, and web pages.
815 Section 2 of this specification defines the format that MUST be
816 presented to the hardware module regardless of the interface that is
817 used. This specification also specifies the format of the response
818 that MAY be generated by the hardware module. Section 3 of this
819 specification defines the format that MAY be returned by the hardware
820 module when a firmware package loads successfully. Section 4 of this
821 specification defines the format that MAY be returned by the hardware
822 module when a firmware package load is unsuccessful. The firmware
823 package load receipts and firmware package load error reports can be
824 either signed or unsigned.
826 2. Firmware Package Protection
828 The Cryptographic Message Syntax (CMS) is used to protect a firmware
829 package, which is treated as an opaque binary object. A digital
830 signature is used to protect the firmware package from undetected
831 modification and to provide data origin authentication. Encryption
832 is optionally used to protect the firmware package from disclosure,
833 and compression is optionally used to reduce the size of the
834 protected firmware package. The CMS ContentInfo content type MUST
835 always be present, and it MUST encapsulate the CMS SignedData content
836 type. If the firmware package is encrypted, then the CMS SignedData
837 content type MUST encapsulate the CMS EncryptedData content type. If
838 the firmware package is compressed, then either the CMS SignedData
842 Housley Standards Track [Page 15]
843 \f
844 RFC 4108 Using CMS to Protect Firmware Packages August 2005
847 content type (when encryption is not used) or the CMS EncryptedData
848 content type (when encryption is used) MUST encapsulate the CMS
849 CompressedData content type. Finally, (1) the CMS SignedData content
850 type (when neither encryption nor compression is used), (2) the CMS
851 EncryptedData content type (when encryption is used, but compression
852 is not), or (3) the CMS CompressedData content type (when compression
853 is used) MUST encapsulate the simple firmware package using the
854 FirmwarePkgData content type defined in this specification (see
855 Section 2.1.5).
857 The firmware package protection is summarized as follows (see [CMS]
858 for the full syntax):
860 ContentInfo {
861 contentType id-signedData, -- (1.2.840.113549.1.7.2)
862 content SignedData
863 }
865 SignedData {
866 version CMSVersion, -- always set to 3
867 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
868 encapContentInfo EncapsulatedContentInfo,
869 certificates CertificateSet, -- Signer cert. path
870 crls CertificateRevocationLists, -- Optional
871 signerInfos SET OF SignerInfo -- Only one
872 }
874 SignerInfo {
875 version CMSVersion, -- always set to 3
876 sid SignerIdentifier,
877 digestAlgorithm DigestAlgorithmIdentifier,
878 signedAttrs SignedAttributes, -- Required
879 signatureAlgorithm SignatureAlgorithmIdentifier,
880 signature SignatureValue,
881 unsignedAttrs UnsignedAttributes -- Optional
882 }
898 Housley Standards Track [Page 16]
899 \f
900 RFC 4108 Using CMS to Protect Firmware Packages August 2005
903 EncapsulatedContentInfo {
904 eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
905 -- OR --
906 id-ct-compressedData,
907 -- (1.2.840.113549.1.9.16.1.9)
908 -- OR --
909 id-ct-firmwarePackage,
910 -- (1.2.840.113549.1.9.16.1.16)
911 eContent OCTET STRING
912 } -- Contains EncryptedData OR
913 -- CompressedData OR
914 -- FirmwarePkgData
916 EncryptedData {
917 version CMSVersion, -- Always set to 0
918 encryptedContentInfo EncryptedContentInfo,
919 unprotectedAttrs UnprotectedAttributes -- Omit
920 }
922 EncryptedContentInfo {
923 contentType id-ct-compressedData,
924 -- (1.2.840.113549.1.9.16.1.9)
925 -- OR --
926 id-ct-firmwarePackage,
927 -- (1.2.840.113549.1.9.16.1.16)
928 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
929 encryptedContent OCTET STRING
930 } -- Contains CompressedData OR
931 -- FirmwarePkgData
933 CompressedData {
934 version CMSVersion, -- Always set to 0
935 compressionAlgorithm CompressionAlgorithmIdentifier,
936 encapContentInfo EncapsulatedContentInfo
937 }
939 EncapsulatedContentInfo {
940 eContentType id-ct-firmwarePackage,
941 -- (1.2.840.113549.1.9.16.1.16)
942 eContent OCTET STRING -- Contains FirmwarePkgData
943 }
945 FirmwarePkgData OCTET STRING -- Contains firmware package
954 Housley Standards Track [Page 17]
955 \f
956 RFC 4108 Using CMS to Protect Firmware Packages August 2005
959 2.1. Firmware Package Protection CMS Content Type Profile
961 This section specifies the conventions for using the CMS ContentInfo,
962 SignedData, EncryptedData, and CompressedData content types. It also
963 defines the FirmwarePkgData content type.
965 2.1.1. ContentInfo
967 The CMS requires that the outermost encapsulation be ContentInfo
968 [CMS]. The fields of ContentInfo are used as follows:
970 contentType indicates the type of the associated content, and in
971 this case, the encapsulated type is always SignedData. The
972 id-signedData (1.2.840.113549.1.7.2) object identifier MUST be
973 present in this field.
975 content holds the associated content, and in this case, the
976 content field MUST contain SignedData.
978 2.1.2. SignedData
980 The SignedData content type [CMS] contains the signed firmware
981 package (which might be compressed, encrypted, or compressed and then
982 encrypted prior to signature), the certificates needed to validate
983 the signature, and one digital signature value. The fields of
984 SignedData are used as follows:
986 version is the syntax version number, and in this case, it MUST be
987 set to 3.
989 digestAlgorithms is a collection of message digest algorithm
990 identifiers, and in this case, it MUST contain a single message
991 digest algorithm identifier. The message digest algorithm
992 employed by the firmware package signer MUST be present.
994 encapContentInfo contains the signed content, consisting of a content
995 type identifier and the content itself. The use of the
996 EncapsulatedContentInfo type is discussed further in Section
997 2.1.2.2.
999 certificates is an optional collection of certificates. If the trust
1000 anchor signed the firmware package directly, then certificates
1001 SHOULD be omitted. If it did not, then certificates SHOULD
1002 include the X.509 certificate of the firmware package signer. The
1003 set of certificates SHOULD be sufficient for the bootstrap loader
1004 to construct a certification path from the trust anchor to the
1005 firmware-signer's certificate. PKCS#6 extended certificates
1010 Housley Standards Track [Page 18]
1011 \f
1012 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1015 [PKCS#6] and attribute certificates (either version 1 or
1016 version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in
1017 the set of certificates.
1019 crls is an optional collection of certificate revocation lists
1020 (CRLs), and in this case, CRLs SHOULD NOT be included by the
1021 firmware package signer. It is anticipated that firmware packages
1022 may be generated, signed, and made available in repositories for
1023 downloading into hardware modules. In such contexts, it would be
1024 difficult for the firmware package signer to include timely CRLs
1025 in the firmware package. However, because the CRLs are not
1026 covered by the signature, timely CRLs MAY be inserted by some
1027 other party before the firmware package is delivered to the
1028 hardware module.
1030 signerInfos is a collection of per-signer information, and in this
1031 case, the collection MUST contain exactly one SignerInfo. The use
1032 of the SignerInfo type is discussed further in Section 2.1.2.1.
1034 2.1.2.1. SignerInfo
1036 The firmware package signer is represented in the SignerInfo type.
1037 The fields of SignerInfo are used as follows:
1039 version is the syntax version number, and it MUST be 3.
1041 sid identifies the signer's public key. CMS supports two
1042 alternatives: issuerAndSerialNumber and subjectKeyIdentifier.
1043 However, the bootstrap loader MUST support the
1044 subjectKeyIdentifier alternative, which identifies the signer's
1045 public key directly. When this public key is contained in a
1046 certificate, this identifier SHOULD appear in the X.509
1047 subjectKeyIdentifier extension.
1049 digestAlgorithm identifies the message digest algorithm, and any
1050 associated parameters, used by the firmware package signer. It
1051 MUST contain the message digest algorithms employed by the
1052 firmware package signer. (Note that this message digest algorithm
1053 identifier MUST be the same as the one carried in the
1054 digestAlgorithms value in SignedData.)
1056 signedAttrs is an optional collection of attributes that are signed
1057 along with the content. The signedAttrs are optional in the CMS,
1058 but in this specification, signedAttrs are REQUIRED for the
1059 firmware package; however, implementations MUST ignore
1060 unrecognized signed attributes. The SET OF attributes MUST be DER
1066 Housley Standards Track [Page 19]
1067 \f
1068 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1071 encoded [X.509-88]. Section 2.2 of this document lists the
1072 attributes that MUST be included in the collection; other
1073 attributes MAY be included as well.
1075 signatureAlgorithm identifies the signature algorithm, and any
1076 associated parameters, used by the firmware package signer to
1077 generate the digital signature.
1079 signature is the digital signature value.
1081 unsignedAttrs is an optional SET of attributes that are not signed.
1082 As described in Section 2.3, this set can only contain a single
1083 instance of the wrapped-firmware-decryption-key attribute and no
1084 others.
1086 2.1.2.2. EncapsulatedContentInfo
1088 The EncapsulatedContentInfo content type encapsulates the firmware
1089 package, which might be compressed, encrypted, or compressed and then
1090 encrypted prior to signature. The firmware package, in any of these
1091 formats, is carried within the EncapsulatedContentInfo type. The
1092 fields of EncapsulatedContentInfo are used as follows:
1094 eContentType is an object identifier that uniquely specifies the
1095 content type, and in this case, the value MUST be id-encryptedData
1096 (1.2.840.113549.1.7.6), id-ct-compressedData
1097 (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
1098 (1.2.840.113549.1.9.16.1.16). When eContentType contains id-
1099 encryptedData, the firmware package was encrypted prior to
1100 signing, and may also have been compressed prior to encryption.
1101 When it contains id-ct-compressedData, the firmware package was
1102 compressed prior to signing, but was not encrypted. When it
1103 contains id-ct-firmwarePackage, the firmware package was not
1104 compressed or encrypted prior to signing.
1106 eContent contains the signed firmware package, which might also be
1107 encrypted, compressed, or compressed and then encrypted, prior to
1108 signing. The content is encoded as an octet string. The eContent
1109 octet string need not be DER encoded.
1111 2.1.3. EncryptedData
1113 The EncryptedData content type [CMS] contains the encrypted firmware
1114 package (which might be compressed prior to encryption). However, if
1115 the firmware package was not encrypted, the EncryptedData content
1116 type is not present. The fields of EncryptedData are used as
1117 follows:
1122 Housley Standards Track [Page 20]
1123 \f
1124 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1127 version is the syntax version number, and in this case, version MUST
1128 be 0.
1130 encryptedContentInfo is the encrypted content information. The use
1131 of the EncryptedContentInfo type is discussed further in Section
1132 2.1.3.1.
1134 unprotectedAttrs is an optional collection of unencrypted attributes,
1135 and in this case, unprotectedAttrs MUST NOT be present.
1137 2.1.3.1. EncryptedContentInfo
1139 The encrypted firmware package, which might be compressed prior to
1140 encryption, is encapsulated in the EncryptedContentInfo type. The
1141 fields of EncryptedContentInfo are used as follows:
1143 contentType indicates the type of content, and in this case, it MUST
1144 contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or
1145 id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it
1146 contains id-ct-compressedData, then the firmware package was
1147 compressed prior to encryption. When it contains id-ct-
1148 firmwarePackage, then the firmware package was not compressed
1149 prior to encryption.
1151 contentEncryptionAlgorithm identifies the firmware-encryption
1152 algorithm, and any associated parameters, used to encrypt the
1153 firmware package.
1155 encryptedContent is the result of encrypting the firmware package.
1156 The field is optional; however, in this case, it MUST be present.
1158 2.1.4. CompressedData
1160 The CompressedData content type [COMPRESS] contains the compressed
1161 firmware package. If the firmware package was not compressed, then
1162 the CompressedData content type is not present. The fields of
1163 CompressedData are used as follows:
1165 version is the syntax version number; in this case, it MUST be 0.
1167 compressionAlgorithm identifies the compression algorithm, and any
1168 associated parameters, used to compress the firmware package.
1170 encapContentInfo is the compressed content, consisting of a content
1171 type identifier and the content itself. The use of the
1172 EncapsulatedContentInfo type is discussed further in Section
1173 2.1.4.1.
1178 Housley Standards Track [Page 21]
1179 \f
1180 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1183 2.1.4.1. EncapsulatedContentInfo
1185 The CompressedData content type encapsulates the compressed firmware
1186 package, and it is carried within the EncapsulatedContentInfo type.
1187 The fields of EncapsulatedContentInfo are used as follows:
1189 eContentType is an object identifier that uniquely specifies the
1190 content type, and in this case, it MUST be the value of id-ct-
1191 firmwarePackage (1.2.840.113549.1.9.16.1.16).
1193 eContent is the compressed firmware package, encoded as an octet
1194 string. The eContent octet string need not be DER encoded.
1196 2.1.5. FirmwarePkgData
1198 The FirmwarePkgData content type contains the firmware package. It
1199 is a straightforward encapsulation in an octet string, and it need
1200 not be DER encoded.
1202 The FirmwarePkgData content type is identified by the id-ct-
1203 firmwarePackage object identifier:
1205 id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
1206 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1207 smime(16) ct(1) 16 }
1209 The FirmwarePkgData content type is a simple octet string:
1211 FirmwarePkgData ::= OCTET STRING
1213 2.2. Signed Attributes
1215 The firmware package signer MUST digitally sign a collection of
1216 attributes along with the firmware package. Each attribute in the
1217 collection MUST be DER encoded [X.509-88]. The syntax for attributes
1218 is defined in [CMS], but it is repeated here for convenience:
1220 Attribute ::= SEQUENCE {
1221 attrType OBJECT IDENTIFIER,
1222 attrValues SET OF AttributeValue }
1224 AttributeValue ::= ANY
1226 Each of the attributes used with this profile has a single attribute
1227 value, even though the syntax is defined as a SET OF AttributeValue.
1228 There MUST be exactly one instance of AttributeValue present.
1234 Housley Standards Track [Page 22]
1235 \f
1236 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1239 The SignedAttributes syntax within signerInfo is defined as a SET OF
1240 Attribute. The SignedAttributes MUST include only one instance of
1241 any particular attribute.
1243 The firmware package signer MUST include the following four
1244 attributes: content-type, message-digest, firmware-package-
1245 identifier, and target-hardware-module-identifiers.
1247 If the firmware package is encrypted, then the firmware package
1248 signer MUST also include the decrypt-key-identifier attribute.
1250 If the firmware package implements cryptographic algorithms, then the
1251 firmware package signer MAY also include the implemented-crypto-
1252 algorithms attribute. Similarly, if the firmware package implements
1253 compression algorithms, then the firmware package signer MAY also
1254 include the implemented-compress-algorithms attribute.
1256 If the firmware package is intended for use only by specific
1257 communities, then the firmware package signer MUST also include the
1258 community-identifiers attribute.
1260 If the firmware package depends on the presence of one or more other
1261 firmware packages to operate properly, then the firmware package
1262 signer SHOULD also include the firmware-package-info attribute. For
1263 example, the firmware-package-info attribute dependencies field might
1264 indicate that the firmware package contains a dependency on a
1265 particular bootstrap loader or separation kernel.
1267 The firmware package signer SHOULD also include the three following
1268 attributes: firmware-package-message-digest, signing-time, and
1269 content-hints. Additionally, if the firmware package signer has a
1270 certificate (meaning that the firmware package signer is not always
1271 configured as a trust anchor), then the firmware package signer
1272 SHOULD also include the signing-certificate attribute.
1274 The firmware package signer MAY include any other attribute that it
1275 deems appropriate.
1277 2.2.1. Content Type
1279 The firmware package signer MUST include a content-type attribute
1280 with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-
1281 compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
1282 (1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData, the
1283 firmware package was encrypted prior to signing. When it contains
1284 id-ct-compressedData, the firmware package was compressed prior to
1285 signing, but was not encrypted. When it contains
1290 Housley Standards Track [Page 23]
1291 \f
1292 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1295 id-ct-firmwarePackage, the firmware package was not compressed or
1296 encrypted prior to signing. Section 11.1 of [CMS] defines the
1297 content-type attribute.
1299 2.2.2. Message Digest
1301 The firmware package signer MUST include a message-digest attribute,
1302 having as its value the message digest computed on the
1303 encapContentInfo eContent octet string, as defined in Section
1304 2.1.2.2. This octet string contains the firmware package, and it MAY
1305 be compressed, encrypted, or both compressed and encrypted. Section
1306 11.2 of [CMS] defines the message-digest attribute.
1308 2.2.3. Firmware Package Identifier
1310 The firmware-package-identifier attribute names the protected
1311 firmware package. Two approaches to naming firmware packages are
1312 supported: legacy and preferred. The firmware package signer MUST
1313 include a firmware-package-identifier attribute using one of these
1314 name forms.
1316 A legacy firmware package name is an octet string, and no structure
1317 within the octet string is assumed.
1319 A preferred firmware package name is a combination of an object
1320 identifier and a version number. The object identifier names a
1321 collection of functions implemented by the firmware package, and the
1322 version number is a non-negative integer that identifies a particular
1323 build or release of the firmware package.
1325 If a firmware package with a disastrous flaw is released, the
1326 firmware package that repairs the previously distributed flaw MAY
1327 designate a stale firmware package version to prevent the reloading
1328 of the flawed version. The hardware module bootstrap loader SHOULD
1329 prevent subsequent rollback to the stale version or versions earlier
1330 than the stale version. When the legacy firmware package name form
1331 is used, the stale version is indicated by a stale legacy firmware
1332 package name, which is an octet string. We assume that the firmware
1333 package signer and the bootstrap loader can determine whether a given
1334 legacy firmware package name represents a version that is more recent
1335 than the stale one. When the preferred firmware package name form is
1336 used, the stale version is indicated by a stale version number, which
1337 is an integer.
1346 Housley Standards Track [Page 24]
1347 \f
1348 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1351 The following object identifier identifies the firmware-package-
1352 identifier attribute:
1354 id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
1355 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1356 smime(16) aa(2) 35 }
1358 The firmware-package-identifier attribute values have ASN.1 type
1359 FirmwarePackageIdentifier:
1361 FirmwarePackageIdentifier ::= SEQUENCE {
1362 name PreferredOrLegacyPackageIdentifier,
1363 stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
1365 PreferredOrLegacyPackageIdentifier ::= CHOICE {
1366 preferred PreferredPackageIdentifier,
1367 legacy OCTET STRING }
1369 PreferredPackageIdentifier ::= SEQUENCE {
1370 fwPkgID OBJECT IDENTIFIER,
1371 verNum INTEGER (0..MAX) }
1373 PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
1374 preferredStaleVerNum INTEGER (0..MAX),
1375 legacyStaleVersion OCTET STRING }
1377 2.2.4. Target Hardware Module Identifiers
1379 The target-hardware-module-identifiers attribute names the types of
1380 hardware modules that the firmware package supports. A unique object
1381 identifier names each supported hardware model type and revision.
1383 The bootstrap loader MUST reject the firmware package if its own
1384 hardware module type identifier is not listed in the target-
1385 hardware-module-identifiers attribute.
1387 The following object identifier identifies the target-hardware-
1388 module-identifiers attribute:
1390 id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
1391 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1392 smime(16) aa(2) 36 }
1394 The target-hardware-module-identifiers attribute values have ASN.1
1395 type TargetHardwareIdentifiers:
1397 TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
1402 Housley Standards Track [Page 25]
1403 \f
1404 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1407 2.2.5. Decrypt Key Identifier
1409 The decrypt-key-identifier attribute names the symmetric key needed
1410 to decrypt the encapsulated firmware package. The CMS EncryptedData
1411 content type is used when the firmware package is encrypted. The
1412 decrypt-key-identifier signed attribute is carried in the SignedData
1413 content type that encapsulates EncryptedData content type, naming the
1414 symmetric key needed to decrypt the firmware package. No particular
1415 structure is imposed on the key identifier. The means by which the
1416 firmware-decryption key is securely distributed to all modules that
1417 are authorized to use the associated firmware package is beyond the
1418 scope of this specification; however, an optional mechanism for
1419 securely distributing the firmware-decryption key with the firmware
1420 package is specified in Section 2.3.1.
1422 The following object identifier identifies the decrypt-key-identifier
1423 attribute:
1425 id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
1426 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1427 smime(16) aa(2) 37 }
1429 The decrypt-key-identifier attribute values have ASN.1 type
1430 DecryptKeyIdentifier:
1432 DecryptKeyIdentifier ::= OCTET STRING
1434 2.2.6. Implemented Crypto Algorithms
1436 The implemented-crypto-algorithms attribute MAY be present in the
1437 SignedAttributes, and it names the cryptographic algorithms that are
1438 implemented by the firmware package and available to applications.
1439 Only those algorithms that are made available at the interface of the
1440 cryptographic module are listed. Any cryptographic algorithm that is
1441 used internally and is not accessible via the cryptographic module
1442 interface MUST NOT be listed. For example, if the firmware package
1443 implements the decryption algorithm for future firmware package
1444 installations and this algorithm is not made available for other
1445 uses, then the firmware-decryption algorithm would not be listed.
1447 The object identifier portion of AlgorithmIdentifier identifies an
1448 algorithm and its mode of use. No algorithm parameters are included.
1449 Cryptographic algorithms include traffic-encryption algorithms, key-
1450 encryption algorithms, key transport algorithms, key agreement
1451 algorithms, one-way hash algorithms, and digital signature
1452 algorithms. Cryptographic algorithms do not include compression
1453 algorithms.
1458 Housley Standards Track [Page 26]
1459 \f
1460 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1463 The following object identifier identifies the implemented-crypto-
1464 algorithms attribute:
1466 id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
1467 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1468 smime(16) aa(2) 38 }
1470 The implemented-crypto-algorithms attribute values have ASN.1 type
1471 ImplementedCryptoAlgorithms:
1473 ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
1475 2.2.7. Implemented Compression Algorithms
1477 The implemented-compress-algorithms attribute MAY be present in the
1478 SignedAttributes, and it names the compression algorithms that are
1479 implemented by the firmware package and available to applications.
1480 Only those algorithms that are made available at the interface of the
1481 hardware module are listed. Any compression algorithm that is used
1482 internally and is not accessible via the hardware module interface
1483 MUST NOT be listed. For example, if the firmware package implements
1484 a decompression algorithm for future firmware package installations
1485 and this algorithm is not made available for other uses, then the
1486 firmware-decompression algorithm would not be listed.
1488 The object identifier portion of AlgorithmIdentifier identifies a
1489 compression algorithm. No algorithm parameters are included.
1491 The following object identifier identifies the implemented-compress-
1492 algorithms attribute:
1494 id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
1495 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1496 smime(16) aa(2) 43 }
1498 The implemented-compress-algorithms attribute values have ASN.1 type
1499 ImplementedCompressAlgorithms:
1501 ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
1503 2.2.8. Community Identifiers
1505 If present in the SignedAttributes, the community-identifiers
1506 attribute names the communities that are permitted to execute the
1507 firmware package. The bootstrap loader MUST reject the firmware
1508 package if the hardware module is not a member of one of the
1509 identified communities. The means of assigning community membership
1510 is beyond the scope of this specification.
1514 Housley Standards Track [Page 27]
1515 \f
1516 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1519 The community-identifiers attributes names the authorized communities
1520 by a list of community object identifiers, by a list of specific
1521 hardware modules, or by a combination of the two lists. A specific
1522 hardware module is specified by the combination of the hardware
1523 module identifier (as defined in Section 2.2.4) and a serial number.
1524 To facilitate compact representation of serial numbers, a contiguous
1525 block can be specified by the lowest authorized serial number and the
1526 highest authorized serial number. Alternatively, all of the serial
1527 numbers associated with a hardware module family identifier can be
1528 specified with the NULL value.
1530 If the bootstrap loader does not have a mechanism for obtaining a
1531 list of object identifiers that identify the communities to which the
1532 hardware module is a member, then the bootstrap loader MUST behave as
1533 though the list is empty. Similarly, if the bootstrap loader does
1534 not have access to the hardware module serial number, then the
1535 bootstrap loader MUST behave as though the hardware module is not
1536 included on the list of authorized hardware modules.
1538 The following object identifier identifies the community-identifiers
1539 attribute:
1541 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
1542 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1543 smime(16) aa(2) 40 }
1545 The community-identifiers attribute values have ASN.1 type
1546 CommunityIdentifiers:
1548 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
1550 CommunityIdentifier ::= CHOICE {
1551 communityOID OBJECT IDENTIFIER,
1552 hwModuleList HardwareModules }
1554 HardwareModules ::= SEQUENCE {
1555 hwType OBJECT IDENTIFIER,
1556 hwSerialEntries SEQUENCE OF HardwareSerialEntry }
1558 HardwareSerialEntry ::= CHOICE {
1559 all NULL,
1560 single OCTET STRING,
1561 block SEQUENCE {
1562 low OCTET STRING,
1563 high OCTET STRING } }
1570 Housley Standards Track [Page 28]
1571 \f
1572 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1575 2.2.9. Firmware Package Information
1577 If a hardware module supports more than one type of firmware package,
1578 then the firmware package signer SHOULD include the firmware-
1579 package-info attribute with a populated fwPkgType field to identify
1580 the firmware package type. This value can aid the bootstrap loader
1581 in the correct placement of the firmware package within the hardware
1582 module. The firmware package type is an INTEGER, and the meaning of
1583 the integer value is specific to each hardware module. For example,
1584 a hardware module could assign different integer values for a
1585 bootstrap loader, a separation kernel, and an application.
1587 Some hardware module architectures permit one firmware package to use
1588 routines provided by another. If the firmware package contains a
1589 dependency on another, then the firmware package signer SHOULD also
1590 include the firmware-package-info attribute with a populated
1591 dependencies field. If the firmware package does not depend on any
1592 other firmware packages, then the firmware package signer MUST NOT
1593 include the firmware-package-info attribute with a populated
1594 dependencies field.
1596 Firmware package dependencies are identified by the firmware package
1597 identifier or by information contained in the firmware package
1598 itself, and in either case the bootstrap loader ensures that the
1599 dependencies are met. The bootstrap loader MUST reject a firmware
1600 package load if it identifies a dependency on a firmware package that
1601 is not already loaded. Also, the bootstrap loader MUST reject a
1602 firmware package load if the action will result in a configuration
1603 where the dependencies of an already loaded firmware package will no
1604 longer be satisfied. As described in Section 2.2.3, two approaches
1605 to naming firmware packages are supported: legacy and preferred.
1606 When the legacy firmware package name form is used, the dependency is
1607 indicated by a legacy firmware package name. We assume that the
1608 firmware package signer and the bootstrap loader can determine
1609 whether a given legacy firmware package name represents the named
1610 version of an acceptable newer version. When the preferred firmware
1611 package name form is used, an object identifier and an integer are
1612 provided. The object identifier MUST exactly match the object
1613 identifier portion of a preferred firmware package name associated
1614 with a firmware package that is already loaded, and the integer MUST
1615 be less than or equal to the integer portion of the preferred
1616 firmware package name associated with the same firmware package.
1617 That is, the dependency specifies the minimum value of the version
1618 that is acceptable.
1626 Housley Standards Track [Page 29]
1627 \f
1628 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1631 The following object identifier identifies the firmware-package-info
1632 attribute:
1634 id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
1635 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1636 smime(16) aa(2) 42 }
1638 The firmware-package-info attribute values have ASN.1 type
1639 FirmwarePackageInfo:
1641 FirmwarePackageInfo ::= SEQUENCE {
1642 fwPkgType INTEGER OPTIONAL,
1643 dependencies SEQUENCE OF
1644 PreferredOrLegacyPackageIdentifier OPTIONAL }
1646 2.2.10. Firmware Package Message Digest
1648 The firmware package signer SHOULD include a firmware-package-
1649 message-digest attribute, which provides the message digest algorithm
1650 and the message digest value computed on the firmware package. The
1651 message digest is computed on the firmware package prior to any
1652 compression, encryption, or signature processing. The bootstrap
1653 loader MAY use this message digest to confirm that the intended
1654 firmware package has been recovered after all of the layers of
1655 encapsulation are removed.
1657 The following object identifier identifies the firmware-package-
1658 message-digest attribute:
1660 id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
1661 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1662 smime(16) aa(2) 41 }
1664 The firmware-package-message-digest attribute values have ASN.1 type
1665 FirmwarePackageMessageDigest:
1667 FirmwarePackageMessageDigest ::= SEQUENCE {
1668 algorithm AlgorithmIdentifier,
1669 msgDigest OCTET STRING }
1671 2.2.11. Signing Time
1673 The firmware package signer SHOULD include a signing-time attribute,
1674 specifying the time at which the signature was applied to the
1675 firmware package. Section 11.3 of [CMS] defines the signing-time
1676 attribute.
1682 Housley Standards Track [Page 30]
1683 \f
1684 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1687 2.2.12. Content Hints
1689 The firmware package signer SHOULD include a content-hints attribute,
1690 including a brief text description of the firmware package. The text
1691 is encoded in UTF-8, which supports most of the world's writing
1692 systems [UTF-8]. Section 2.9 of [ESS] defines the content-hints
1693 attribute.
1695 When multiple layers of encapsulation are employed, the content-hints
1696 attribute is included in the outermost SignedData to provide
1697 information about the innermost content. In this case, the content-
1698 hints attribute provides a brief text description of the firmware
1699 package, which can help a person select the correct firmware package
1700 when more than one is available.
1702 When the preferred firmware package name forms are used, the
1703 content-hints attribute can provide a linkage to a legacy firmware
1704 package name. This is especially helpful when an existing
1705 configuration management system is in use, but the features
1706 associated with the preferred firmware package name are deemed
1707 useful. A firmware package name associated with such a configuration
1708 management system might look something like
1709 "R1234.C0(AJ11).D62.A02.11(b)." Including these firmware package
1710 names in the text description may be helpful to developers by
1711 providing a clear linkage between the two name forms.
1713 The content-hints attribute contains two fields, and in this case,
1714 both fields MUST be present. The fields of ContentHints are used as
1715 follows:
1717 contentDescription provides a brief text description of the firmware
1718 package.
1720 contentType provides the content type of the inner most content type,
1721 and in this case, it MUST be id-ct-firmwarePackage
1722 (1.2.840.113549.1.9.16.1.16).
1724 2.2.13. Signing Certificate
1726 When the firmware-signer's public key is contained in a certificate,
1727 the firmware package signer SHOULD include a signing-certificate
1728 attribute to identify the certificate that was employed. However, if
1729 the firmware package signature does not have a certificate (meaning
1730 that the signature will only be validated with the trust anchor
1731 public key), then the firmware package signer is unable to include a
1732 signing-certificate attribute. Section 5.4 of [ESS] defines this
1733 attribute.
1738 Housley Standards Track [Page 31]
1739 \f
1740 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1743 The signing-certificate attribute contains two fields: certs and
1744 policies. The certs field MUST be present, and the policies field
1745 MAY be present. The fields of SigningCertificate are used as
1746 follows:
1748 certs contains a sequence of certificate identifiers. In this case,
1749 sequence of certificate identifiers contains a single entry. The
1750 certs field MUST contain only the certificate identifier of the
1751 certificate that contains the public key used to verify the
1752 firmware package signature. The certs field uses the ESSCertID
1753 syntax specified in Section 5.4 of [ESS], and it is comprised of
1754 the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate
1755 and, optionally, the certificate issuer and the certificate serial
1756 number. The SHA-1 hash value MUST be present. The certificate
1757 issuer and the certificate serial number SHOULD be present.
1759 policies is optional; when it is present, it contains a sequence of
1760 policy information. The policies field, when present, MUST
1761 contain only one entry, and that entry MUST match one of the
1762 certificate policies in the certificate policies extension of the
1763 certificate that contains the public key used to verify the
1764 firmware package signature. The policies field uses the
1765 PolicyInformation syntax specified in Section 4.2.1.5 of
1766 [PROFILE], and it is comprised of the certificate policy object
1767 identifier and, optionally, certificate policy qualifiers. The
1768 certificate policy object identifier MUST be present. The
1769 certificate policy qualifiers SHOULD NOT be present.
1771 2.3. Unsigned Attributes
1773 CMS allows a SET of unsigned attributes to be included; however, in
1774 this specification, the set MUST be absent or include a single
1775 instance of the wrapped-firmware-decryption-key attribute. Because
1776 the digital signature does not cover this attribute, it can be
1777 altered at any point in the delivery path from the firmware package
1778 signer to the hardware module. This property can be employed to
1779 distribute the firmware-decryption key along with an encrypted and
1780 signed firmware package, allowing the firmware-decryption key to be
1781 wrapped with a different key-encryption key for each link in the
1782 distribution chain.
1784 The syntax for attributes is defined in [CMS], and it is repeated at
1785 the beginning of Section 2.2 of this document for convenience. Each
1786 of the attributes used with this profile has a single attribute
1787 value, even though the syntax is defined as a SET OF AttributeValue.
1788 There MUST be exactly one instance of AttributeValue present.
1794 Housley Standards Track [Page 32]
1795 \f
1796 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1799 The UnsignedAttributes syntax within signerInfo is defined as a SET
1800 OF Attribute. The UnsignedAttributes MUST include only one instance
1801 of any particular attribute.
1803 2.3.1. Wrapped Firmware Decryption Key
1805 The firmware package signer, or any other party in the distribution
1806 chain, MAY include a wrapped-firmware-decryption-key attribute.
1808 The following object identifier identifies the wrapped-firmware-
1809 decryption-key attribute:
1811 id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
1812 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1813 smime(16) aa(2) 39 }
1815 The wrapped-firmware-decryption-key attribute values have ASN.1 type
1816 of EnvelopedData. Section 6 of [CMS] defines the EnvelopedData
1817 content type, which is used to construct the value of the attribute.
1818 EnvelopedData permits the firmware-decryption key to be protected
1819 using symmetric or asymmetric techniques. The EnvelopedData does not
1820 include an encrypted content; rather, the EnvelopedData feature of
1821 having the encrypted content in another location is employed. The
1822 encrypted content is found in the eContent field of the EncryptedData
1823 structure. The firmware-decryption key is contained in the
1824 recipientInfos field. Section 6 of [CMS] refers to this key as the
1825 content-encryption key.
1827 The EnvelopedData syntax supports many different key management
1828 algorithms. Four general techniques are supported: key transport,
1829 key agreement, symmetric key-encryption keys, and passwords.
1831 The EnvelopedData content type is profiled for the wrapped-firmware-
1832 decryption-key attribute. The EnvelopedData fields are described
1833 fully in Section 6 of [CMS]. Additional rules apply when
1834 EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
1836 Within the EnvelopedData structure, the following apply:
1838 - The set of certificates included in OriginatorInfo MUST NOT
1839 include certificates with a type of extendedCertificate,
1840 v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE]. The
1841 optional crls field MAY be present.
1843 - The optional unprotectedAttrs field MUST NOT be present.
1850 Housley Standards Track [Page 33]
1851 \f
1852 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1855 Within the EncryptedContentInfo structure, the following apply:
1857 - contentType MUST match the content type object identifier carried
1858 in the contentType field within the EncryptedContentInfo structure
1859 of EncryptedData as described in Section 2.1.3.1.
1861 - contentEncryptionAlgorithm identifies the firmware-encryption
1862 algorithm, and any associated parameters, used to encrypt the
1863 firmware package carried in the encryptedContent field of the
1864 EncryptedContentInfo structure of EncryptedData. Therefore, it
1865 MUST exactly match the value of the EncryptedContentInfo structure
1866 of EncryptedData as described in Section 2.1.3.1.
1868 - encryptedContent is optional, and in this case, it MUST NOT be
1869 present.
1871 3. Firmware Package Load Receipt
1873 The Cryptographic Message Syntax (CMS) is used to indicate that a
1874 firmware package loaded successfully. Support for firmware package
1875 load receipts is OPTIONAL. However, those hardware modules that
1876 choose to generate such receipts MUST follow the conventions
1877 specified in this section. Because not all hardware modules will
1878 have private signature keys, the firmware package load receipt can be
1879 either signed or unsigned. Use of the signed firmware package load
1880 receipt is RECOMMENDED.
1882 Hardware modules that support receipt generation MUST have a unique
1883 serial number. Hardware modules that support signed receipt
1884 generation MUST have a private signature key to sign the receipt and
1885 the corresponding signature validation certificate or its designator.
1886 The designator is the certificate issuer name and the certificate
1887 serial number, or it is the public key identifier. Memory-
1888 constrained hardware modules will generally store the public key
1889 identifier since it requires less storage.
1891 The unsigned firmware package load receipt is encapsulated by
1892 ContentInfo. Alternatively, the signed firmware package load receipt
1893 is encapsulated by SignedData, which is in turn encapsulated by
1894 ContentInfo.
1906 Housley Standards Track [Page 34]
1907 \f
1908 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1911 The firmware package load receipt is summarized as follows (see [CMS]
1912 for the full syntax):
1914 ContentInfo {
1915 contentType id-signedData, -- (1.2.840.113549.1.7.2)
1916 -- OR --
1917 id-ct-firmwareLoadReceipt,
1918 -- (1.2.840.113549.1.9.16.1.17)
1919 content SignedData
1920 -- OR --
1921 FirmwarePackageLoadReceipt
1922 }
1924 SignedData {
1925 version CMSVersion, -- always set to 3
1926 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
1927 encapContentInfo EncapsulatedContentInfo,
1928 certificates CertificateSet, -- Optional Module certificate
1929 crls CertificateRevocationLists, -- Optional
1930 signerInfos SET OF SignerInfo -- Only one
1931 }
1933 SignerInfo {
1934 version CMSVersion, -- either set to 1 or 3
1935 sid SignerIdentifier,
1936 digestAlgorithm DigestAlgorithmIdentifier,
1937 signedAttrs SignedAttributes, -- Required
1938 signatureAlgorithm SignatureAlgorithmIdentifier,
1939 signature SignatureValue,
1940 unsignedAttrs UnsignedAttributes -- Omit
1941 }
1943 EncapsulatedContentInfo {
1944 eContentType id-ct-firmwareLoadReceipt,
1945 -- (1.2.840.113549.1.9.16.1.17)
1946 eContent OCTET STRING -- Contains receipt
1947 }
1949 FirmwarePackageLoadReceipt {
1950 version INTEGER, -- The DEFAULT is always used
1951 hwType OBJECT IDENTIFIER, -- Hardware module type
1952 hwSerialNum OCTET STRING, -- H/W module serial number
1953 fwPkgName PreferredOrLegacyPackageIdentifier,
1954 trustAnchorKeyID OCTET STRING, -- Optional
1955 decryptKeyID OCTET STRING -- Optional
1956 }
1962 Housley Standards Track [Page 35]
1963 \f
1964 RFC 4108 Using CMS to Protect Firmware Packages August 2005
1967 3.1. Firmware Package Load Receipt CMS Content Type Profile
1969 This section specifies the conventions for using the CMS ContentInfo
1970 and SignedData content types for firmware package load receipts. It
1971 also defines the firmware package load receipt content type.
1973 3.1.1. ContentInfo
1975 The CMS requires that the outermost encapsulation be ContentInfo
1976 [CMS]. The fields of ContentInfo are used as follows:
1978 contentType indicates the type of the associated content. If the
1979 firmware package load receipt is signed, then the encapsulated
1980 type MUST be SignedData, and the id-signedData
1981 (1.2.840.113549.1.7.2) object identifier MUST be present in this
1982 field. If the receipt is not signed, then the encapsulated type
1983 MUST be FirmwarePackageLoadReceipt, and the id-ct-
1984 firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object identifier
1985 MUST be present in this field.
1987 content holds the associated content. If the firmware package load
1988 receipt is signed, then this field MUST contain the SignedData.
1989 If the receipt is not signed, then this field MUST contain the
1990 FirmwarePackageLoadReceipt.
1992 3.1.2. SignedData
1994 The SignedData content type contains the firmware package load
1995 receipt and one digital signature. If the hardware module locally
1996 stores its certificate, then the certificate can be included as well.
1997 The fields of SignedData are used as follows:
1999 version is the syntax version number, and in this case, it MUST be
2000 set to 3.
2002 digestAlgorithms is a collection of message digest algorithm
2003 identifiers, and in this case, it MUST contain a single message
2004 digest algorithm identifier. The message digest algorithms
2005 employed by the hardware module MUST be present.
2007 encapContentInfo is the signed content, consisting of a content type
2008 identifier and the content itself. The use of the
2009 EncapsulatedContentInfo type is discussed further in Section
2010 3.1.2.2.
2012 certificates is an optional collection of certificates. If the
2013 hardware module locally stores its certificate, then the X.509
2014 certificate of the hardware module SHOULD be included. If the
2018 Housley Standards Track [Page 36]
2019 \f
2020 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2023 hardware module does not, then the certificates field is omitted.
2024 PKCS#6 extended certificates [PKCS#6] and attribute certificates
2025 (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE]
2026 MUST NOT be included in the set of certificates.
2028 crls is an optional collection of certificate revocation lists
2029 (CRLs). CRLs MAY be included, but they will normally be omitted
2030 since hardware modules will not generally have access to the most
2031 recent CRL. Signed receipt recipients SHOULD be able to handle
2032 the presence of the optional crls field.
2034 signerInfos is a collection of per-signer information, and in this
2035 case, the collection MUST contain exactly one SignerInfo. The use
2036 of the SignerInfo type is discussed further in Section 3.1.2.1.
2038 3.1.2.1. SignerInfo
2040 The hardware module is represented in the SignerInfo type. The
2041 fields of SignerInfo are used as follows:
2043 version is the syntax version number, and it MUST be either 1 or 3,
2044 depending on the method used to identify the hardware module's
2045 public key. The use of the subjectKeyIdentifier is RECOMMENDED,
2046 which results in the use of version 3.
2048 sid specifies the hardware module's certificate (and thereby the
2049 hardware module's public key). CMS supports two alternatives:
2050 issuerAndSerialNumber and subjectKeyIdentifier. The hardware
2051 module MUST support one or both of the alternatives for receipt
2052 generation; however, the support of subjectKeyIdentifier is
2053 RECOMMENDED. The issuerAndSerialNumber alternative identifies the
2054 hardware module's certificate by the issuer's distinguished name
2055 and the certificate serial number. The identified certificate, in
2056 turn, contains the hardware module's public key. The
2057 subjectKeyIdentifier alternative identifies the hardware module's
2058 public key directly. When this public key is contained in a
2059 certificate, this identifier SHOULD appear in the X.509
2060 subjectKeyIdentifier extension.
2062 digestAlgorithm identifies the message digest algorithm, and any
2063 associated parameters, used by the hardware module. It MUST
2064 contain the message digest algorithms employed to sign the
2065 receipt. (Note that this message digest algorithm identifier MUST
2066 be the same as the one carried in the digestAlgorithms value in
2067 SignedData.)
2074 Housley Standards Track [Page 37]
2075 \f
2076 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2079 signedAttrs is an optional collection of attributes that are signed
2080 along with the content. The signedAttrs are optional in the CMS,
2081 but in this specification, signedAttrs are REQUIRED for use with
2082 the firmware package load receipt content. The SET OF attributes
2083 MUST be DER encoded [X.509-88]. Section 3.2 of this document
2084 lists the attributes that MUST be included in the collection.
2085 Other attributes MAY be included, but the recipient will ignore
2086 any unrecognized signed attributes.
2088 signatureAlgorithm identifies the signature algorithm, and any
2089 associated parameters, used to sign the receipt.
2091 signature is the digital signature.
2093 unsignedAttrs is an optional collection of attributes that are not
2094 signed, and in this case, there MUST NOT be any unsigned
2095 attributes present.
2097 3.1.2.2. EncapsulatedContentInfo
2099 The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING,
2100 and it is carried within the EncapsulatedContentInfo type. The
2101 fields of EncapsulatedContentInfo are used as follows:
2103 eContentType is an object identifier that uniquely specifies the
2104 content type, and in this case, it MUST be the value of id-ct-
2105 firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
2107 eContent is the firmware package load receipt, encapsulated in an
2108 OCTET STRING. The eContent octet string need not be DER encoded.
2110 3.1.3. FirmwarePackageLoadReceipt
2112 The following object identifier identifies the firmware package load
2113 receipt content type:
2115 id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
2116 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
2117 smime(16) ct(1) 17 }
2130 Housley Standards Track [Page 38]
2131 \f
2132 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2135 The firmware package load receipt content type has the ASN.1 type
2136 FirmwarePackageLoadReceipt:
2138 FirmwarePackageLoadReceipt ::= SEQUENCE {
2139 version FWReceiptVersion DEFAULT v1,
2140 hwType OBJECT IDENTIFIER,
2141 hwSerialNum OCTET STRING,
2142 fwPkgName PreferredOrLegacyPackageIdentifier,
2143 trustAnchorKeyID OCTET STRING OPTIONAL,
2144 decryptKeyID [1] OCTET STRING OPTIONAL }
2146 FWReceiptVersion ::= INTEGER { v1(1) }
2148 The fields of the FirmwarePackageLoadReceipt type have the following
2149 meanings:
2151 version is an integer that provides the syntax version number for
2152 compatibility with future revisions of this specification.
2153 Implementations that conform to this specification MUST set the
2154 version to the default value, which is v1.
2156 hwType is an object identifier that identifies the type of hardware
2157 module on which the firmware package was loaded.
2159 hwSerialNum is the serial number of the hardware module on which the
2160 firmware package was loaded. No particular structure is imposed
2161 on the serial number; it need not be an integer. However, the
2162 combination of the hwType and hwSerialNum uniquely identifies the
2163 hardware module.
2165 fwPkgName identifies the firmware package that was loaded. As
2166 described in Section 2.2.3, two approaches to naming firmware
2167 packages are supported: legacy and preferred. A legacy firmware
2168 package name is an octet string. A preferred firmware package
2169 name is a combination of the firmware package object identifier
2170 and an integer version number.
2172 trustAnchorKeyID is optional, and when it is present, it identifies
2173 the trust anchor that was used to validate the firmware package
2174 signature.
2176 decryptKeyID is optional, and when it is present, it identifies the
2177 firmware-decryption key that was used to decrypt the firmware
2178 package.
2180 The firmware package load receipt MUST include the version, hwType,
2181 hwSerialNum, and fwPkgName fields, and it SHOULD include the
2182 trustAnchorKeyID field. The firmware package load receipt MUST NOT
2186 Housley Standards Track [Page 39]
2187 \f
2188 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2191 include the decryptKeyID, unless the firmware package associated with
2192 the receipt is encrypted, the firmware-decryption key is available to
2193 the hardware module, and the firmware package was successfully
2194 decrypted.
2196 3.2. Signed Attributes
2198 The hardware module MUST digitally sign a collection of attributes
2199 along with the firmware package load receipt. Each attribute in the
2200 collection MUST be DER encoded [X.509-88]. The syntax for attributes
2201 is defined in [CMS], and it was repeated in Section 2.2 for
2202 convenience.
2204 Each of the attributes used with this profile has a single attribute
2205 value, even though the syntax is defined as a SET OF AttributeValue.
2206 There MUST be exactly one instance of AttributeValue present.
2208 The SignedAttributes syntax within signerInfo is defined as a SET OF
2209 Attributes. The SignedAttributes MUST include only one instance of
2210 any particular attribute.
2212 The hardware module MUST include the content-type and message-digest
2213 attributes. If the hardware module includes a real-time clock, then
2214 the hardware module SHOULD also include the signing-time attribute.
2215 The hardware module MAY include any other attribute that it deems
2216 appropriate.
2218 3.2.1. Content Type
2220 The hardware module MUST include a content-type attribute with the
2221 value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
2222 Section 11.1 of [CMS] defines the content-type attribute.
2224 3.2.2. Message Digest
2226 The hardware module MUST include a message-digest attribute, having
2227 as its value the message digest of the FirmwarePackageLoadReceipt
2228 content. Section 11.2 of [CMS] defines the message-digest attribute.
2230 3.2.3. Signing Time
2232 If the hardware module includes a real-time clock, then the hardware
2233 module SHOULD include a signing-time attribute, specifying the time
2234 at which the receipt was generated. Section 11.3 of [CMS] defines
2235 the signing-time attribute.
2242 Housley Standards Track [Page 40]
2243 \f
2244 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2247 4. Firmware Package Load Error
2249 The Cryptographic Message Syntax (CMS) is used to indicate that an
2250 error has occurred while attempting to load a protected firmware
2251 package. Support for firmware package load error reports is
2252 OPTIONAL. However, those hardware modules that choose to generate
2253 such error reports MUST follow the conventions specified in this
2254 section. Not all hardware modules have private signature keys;
2255 therefore the firmware package load error report can be either signed
2256 or unsigned. Use of the signed firmware package error report is
2257 RECOMMENDED.
2259 Hardware modules that support error report generation MUST have a
2260 unique serial number. Hardware modules that support signed error
2261 report generation MUST also have a private signature key to sign the
2262 error report and the corresponding signature validation certificate
2263 or its designator. The designator is the certificate issuer name and
2264 the certificate serial number, or it is the public key identifier.
2265 Memory-constrained hardware modules will generally store the public
2266 key identifier since it requires less storage.
2268 The unsigned firmware package load error report is encapsulated by
2269 ContentInfo. Alternatively, the signed firmware package load error
2270 report is encapsulated by SignedData, which is in turn encapsulated
2271 by ContentInfo.
2273 The firmware package load error report is summarized as follows (see
2274 [CMS] for the full syntax):
2276 ContentInfo {
2277 contentType id-signedData, -- (1.2.840.113549.1.7.2)
2278 -- OR --
2279 id-ct-firmwareLoadError,
2280 -- (1.2.840.113549.1.9.16.1.18)
2281 content SignedData
2282 -- OR --
2283 FirmwarePackageLoadError
2284 }
2286 SignedData {
2287 version CMSVersion, -- Always set to 3
2288 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
2289 encapContentInfo EncapsulatedContentInfo,
2290 certificates CertificateSet, -- Optional Module certificate
2291 crls CertificateRevocationLists, -- Optional
2292 signerInfos SET OF SignerInfo -- Only one
2293 }
2298 Housley Standards Track [Page 41]
2299 \f
2300 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2303 SignerInfo {
2304 version CMSVersion, -- either set to 1 or 3
2305 sid SignerIdentifier,
2306 digestAlgorithm DigestAlgorithmIdentifier,
2307 signedAttrs SignedAttributes, -- Required
2308 signatureAlgorithm SignatureAlgorithmIdentifier,
2309 signature SignatureValue,
2310 unsignedAttrs UnsignedAttributes -- Omit
2311 }
2313 EncapsulatedContentInfo {
2314 eContentType id-ct-firmwareLoadError,
2315 -- (1.2.840.113549.1.9.16.1.18)
2316 eContent OCTET STRING -- Contains error report
2317 }
2319 FirmwarePackageLoadError {
2320 version INTEGER, -- The DEFAULT is always used
2321 hwType OBJECT IDENTIFIER, -- Hardware module type
2322 hwSerialNum OCTET STRING, -- H/W module serial number
2323 errorCode FirmwarePackageLoadErrorCode -- Error identifier
2324 vendorErrorCode VendorErrorCode, -- Optional
2325 fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
2326 config SEQUENCE OF CurrentFWConfig, -- Optional
2327 }
2329 CurrentFWConfig { -- Repeated for each package in configuration
2330 fwPkgType INTEGER, -- Firmware package type; Optional
2331 fwPkgName PreferredOrLegacyPackageIdentifier
2332 }
2334 4.1. Firmware Package Load Error CMS Content Type Profile
2336 This section specifies the conventions for using the CMS ContentInfo
2337 and SignedData content types for firmware package load error reports.
2338 It also defines the firmware package load error content type.
2340 4.1.1. ContentInfo
2342 The CMS requires that the outermost encapsulation be ContentInfo
2343 [CMS]. The fields of ContentInfo are used as follows:
2345 contentType indicates the type of the associated content. If the
2346 firmware package load error report is signed, then the
2347 encapsulated type MUST be SignedData, and the id-signedData
2348 (1.2.840.113549.1.7.2) object identifier MUST be present in this
2349 field. If the report is not signed, then the encapsulated type
2354 Housley Standards Track [Page 42]
2355 \f
2356 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2359 MUST be FirmwarePackageLoadError, and the id-ct-firmwareLoadError
2360 (1.2.840.113549.1.9.16.1.18) object identifier MUST be present in
2361 this field.
2363 content holds the associated content. If the firmware package load
2364 error report is signed, then this field MUST contain the
2365 SignedData. If the report is not signed, then this field MUST
2366 contain the FirmwarePackageLoadError.
2368 4.1.2. SignedData
2370 The SignedData content type contains the firmware package load error
2371 report and one digital signature. If the hardware module locally
2372 stores its certificate, then the certificate can be included as well.
2373 The fields of SignedData are used exactly as described in Section
2374 3.1.2.
2376 4.1.2.1. SignerInfo
2378 The hardware module is represented in the SignerInfo type. The
2379 fields of SignerInfo are used exactly as described in Section
2380 3.1.2.1.
2382 4.1.2.2. EncapsulatedContentInfo
2384 The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and
2385 it is carried within the EncapsulatedContentInfo type. The fields of
2386 EncapsulatedContentInfo are used as follows:
2388 eContentType is an object identifier that uniquely specifies the
2389 content type, and in this case, it MUST be the value of id-ct-
2390 firmwareLoadError (1.2.840.113549.1.9.16.1.18).
2392 eContent is the firmware package load error report, encapsulated in
2393 an OCTET STRING. The eContent octet string need not be DER
2394 encoded.
2396 4.1.3. FirmwarePackageLoadError
2398 The following object identifier identifies the firmware package load
2399 error report content type:
2401 id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
2402 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
2403 smime(16) ct(1) 18 }
2410 Housley Standards Track [Page 43]
2411 \f
2412 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2415 The firmware package load error report content type has the ASN.1
2416 type FirmwarePackageLoadError:
2418 FirmwarePackageLoadError ::= SEQUENCE {
2419 version FWErrorVersion DEFAULT v1,
2420 hwType OBJECT IDENTIFIER,
2421 hwSerialNum OCTET STRING,
2422 errorCode FirmwarePackageLoadErrorCode,
2423 vendorErrorCode VendorLoadErrorCode OPTIONAL,
2424 fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
2425 config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
2427 FWErrorVersion ::= INTEGER { v1(1) }
2429 CurrentFWConfig ::= SEQUENCE {
2430 fwPkgType INTEGER OPTIONAL,
2431 fwPkgName PreferredOrLegacyPackageIdentifier }
2433 FirmwarePackageLoadErrorCode ::= ENUMERATED {
2434 decodeFailure (1),
2435 badContentInfo (2),
2436 badSignedData (3),
2437 badEncapContent (4),
2438 badCertificate (5),
2439 badSignerInfo (6),
2440 badSignedAttrs (7),
2441 badUnsignedAttrs (8),
2442 missingContent (9),
2443 noTrustAnchor (10),
2444 notAuthorized (11),
2445 badDigestAlgorithm (12),
2446 badSignatureAlgorithm (13),
2447 unsupportedKeySize (14),
2448 signatureFailure (15),
2449 contentTypeMismatch (16),
2450 badEncryptedData (17),
2451 unprotectedAttrsPresent (18),
2452 badEncryptContent (19),
2453 badEncryptAlgorithm (20),
2454 missingCiphertext (21),
2455 noDecryptKey (22),
2456 decryptFailure (23),
2457 badCompressAlgorithm (24),
2458 missingCompressedContent (25),
2459 decompressFailure (26),
2460 wrongHardware (27),
2461 stalePackage (28),
2462 notInCommunity (29),
2466 Housley Standards Track [Page 44]
2467 \f
2468 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2471 unsupportedPackageType (30),
2472 missingDependency (31),
2473 wrongDependencyVersion (32),
2474 insufficientMemory (33),
2475 badFirmware (34),
2476 unsupportedParameters (35),
2477 breaksDependency (36),
2478 otherError (99) }
2480 VendorLoadErrorCode ::= INTEGER
2482 The fields of the FirmwarePackageLoadError type have the following
2483 meanings:
2485 version is an integer, and it provides the syntax version number for
2486 compatibility with future revisions of this specification.
2487 Implementations that conform to this specification MUST set the
2488 version to the default value, which is v1.
2490 hwType is an object identifier that identifies the type of hardware
2491 module on which the firmware package load was attempted.
2493 hwSerialNum is the serial number of the hardware module on which the
2494 firmware package load was attempted. No particular structure is
2495 imposed on the serial number; it need not be an integer. However,
2496 the combination of the hwType and hwSerialNum uniquely identifies
2497 the hardware module.
2499 errorCode identifies the error that occurred.
2501 vendorErrorCode is optional; however, it MUST be present if the
2502 errorCode contains a value of otherError. When errorCode contains
2503 a value other than otherError, the vendorErrorCode can provide
2504 vendor-specific supplemental information.
2506 fwPkgName is optional. When it is present, it identifies the
2507 firmware package that was being loaded when the error occurred.
2508 As described in Section 2.2.3, two approaches to naming firmware
2509 packages are supported: legacy and preferred. A legacy firmware
2510 package name is an octet string. A preferred firmware package
2511 name is a combination of the firmware package object identifier
2512 and an integer version number.
2514 config identifies the current firmware configuration. The field is
2515 OPTIONAL, but support for this field is RECOMMENDED for hardware
2516 modules that permit the loading of more than one firmware package.
2517 One instance of CurrentFWConfig is used to provide information
2518 about each firmware package in hardware module.
2522 Housley Standards Track [Page 45]
2523 \f
2524 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2527 The fields of the CurrentFWConfig type have the following meanings:
2529 fwPkgType identifies the firmware package type. The firmware package
2530 type is an INTEGER, and the meaning of the integer value is
2531 specific to each hardware module.
2533 fwPkgName identifies the firmware package. As described in Section
2534 2.2.3, two approaches to naming firmware packages are supported:
2535 legacy and preferred. A legacy firmware package name is an octet
2536 string. A preferred firmware package name is a combination of the
2537 firmware package object identifier and an integer version number.
2539 The errorCode values have the following meanings:
2541 decodeFailure: The ASN.1 decode of the firmware package load failed.
2542 The provided input did not conform to BER, or it was not ASN.1 at
2543 all.
2545 badContentInfo: Invalid ContentInfo syntax, or the contentType
2546 carried within the ContentInfo is unknown or unsupported.
2548 badSignedData: Invalid SignedData syntax, the version is unknown or
2549 unsupported, or more than one entry is present in
2550 digestAlgorithms.
2552 badEncapContent: Invalid EncapsulatedContentInfo syntax, or the
2553 contentType carried within the eContentType is unknown or
2554 unsupported. This error can be generated due to problems located
2555 in SignedData or CompressedData.
2557 badCertificate: Invalid syntax for one or more certificates in
2558 CertificateSet.
2560 badSignerInfo: Invalid SignerInfo syntax, or the version is unknown
2561 or unsupported.
2563 badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
2565 badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an
2566 attribute other than the wrapped-firmware-decryption-key
2567 attribute, which is the only unsigned attribute supported by this
2568 specification.
2570 missingContent: The optional eContent is missing in
2571 EncapsulatedContentInfo, which is required in this specification.
2572 This error can be generated due to problems located in SignedData
2573 or CompressedData.
2578 Housley Standards Track [Page 46]
2579 \f
2580 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2583 noTrustAnchor: Two situations can lead to this error. In one case,
2584 the subjectKeyIdentifier does not identify the public key of a
2585 trust anchor or a certification path that terminates with an
2586 installed trust anchor. In the other case, the
2587 issuerAndSerialNumber does not identify the public key of a trust
2588 anchor or a certification path that terminates with an installed
2589 trust anchor.
2591 notAuthorized: The sid within SignerInfo leads to an installed trust
2592 anchor, but that trust anchor is not an authorized firmware
2593 package signer.
2595 badDigestAlgorithm: The digestAlgorithm in either SignerInfo or
2596 SignedData is unknown or unsupported.
2598 badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is
2599 unknown or unsupported.
2601 unsupportedKeySize: The signatureAlgorithm in SignerInfo is known and
2602 supported, but the firmware package signature could not be
2603 validated because an unsupported key size was employed by the
2604 signer.
2606 signatureFailure: The signatureAlgorithm in SignerInfo is known and
2607 supported, but the signature in signature in SignerInfo could not
2608 be validated.
2610 contentTypeMismatch: The contentType carried within the eContentType
2611 does not match the content type carried in the signed attribute.
2613 badEncryptedData: Invalid EncryptedData syntax; the version is
2614 unknown or unsupported.
2616 unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs,
2617 which are not permitted in this specification.
2619 badEncryptContent: Invalid EncryptedContentInfo syntax, or the
2620 contentType carried within the contentType is unknown or
2621 unsupported.
2623 badEncryptAlgorithm: The firmware-encryption algorithm identified by
2624 contentEncryptionAlgorithm in EncryptedContentInfo is unknown or
2625 unsupported.
2627 missingCiphertext: The optional encryptedContent is missing in
2628 EncryptedContentInfo, which is required in this specification.
2634 Housley Standards Track [Page 47]
2635 \f
2636 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2639 noDecryptKey: The hardware module does not have the firmware-
2640 decryption key named in the decrypt key identifier signed
2641 attribute.
2643 decryptFailure: The firmware package did not decrypt properly.
2645 badCompressAlgorithm: The compression algorithm identified by
2646 compressionAlgorithm in CompressedData is unknown or unsupported.
2648 missingCompressedContent: The optional eContent is missing in
2649 EncapsulatedContentInfo, which is required in this specification.
2651 decompressFailure: The firmware package did not decompress properly.
2653 wrongHardware: The processing hardware module is not listed in the
2654 target hardware module identifiers signed attribute.
2656 stalePackage: The firmware package is rejected because it is stale.
2658 notInCommunity: The hardware module is not a member of the community
2659 described in the community identifiers signed attribute.
2661 unsupportedPackageType: The firmware package type identified in the
2662 firmware package information signed attribute is not supported by
2663 the combination of the hardware module and the bootstrap loader.
2665 missingDependency: The firmware package being loaded depends on
2666 routines that are part of another firmware package, but that
2667 firmware package is not available.
2669 wrongDependencyVersion: The firmware package being loaded depends on
2670 routines that are part of the another firmware package, and the
2671 available version of that package has an older version number than
2672 is required. The available firmware package does not fulfill the
2673 dependencies.
2675 insufficientMemory: The firmware package could not be loaded because
2676 the hardware module did not have sufficient memory.
2678 badFirmware: The signature on the firmware package was validated, but
2679 the firmware package itself was not in an acceptable format. The
2680 details will be specific to each hardware module. For example, a
2681 hardware module that is composed of multiple firmware-programmable
2682 components could not find the internal tagging within the firmware
2683 package to distribute executable code to each of the components.
2690 Housley Standards Track [Page 48]
2691 \f
2692 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2695 unsupportedParameters: The signature on the firmware package could
2696 not be validated because the signer used signature algorithm
2697 parameters that are not supported by the hardware module signature
2698 verification routines.
2700 breaksDependency: Another firmware package has a dependency that can
2701 no longer be satisfied if the firmware package being loaded is
2702 accepted.
2704 otherError: An error occurred that does not fit any of the previous
2705 error codes.
2707 4.2. Signed Attributes
2709 The hardware module MUST digitally sign a collection of attributes
2710 along with the firmware package load error report. Each attribute in
2711 the collection MUST be DER encoded [X.509-88]. The syntax for
2712 attributes is defined in [CMS], and it was repeated in Section 2.2
2713 for convenience.
2715 Each of the attributes used with this profile has a single attribute
2716 value, even though the syntax is defined as a SET OF AttributeValue.
2717 There MUST be exactly one instance of AttributeValue present.
2719 The SignedAttributes syntax within signerInfo is defined as a SET OF
2720 Attributes. The SignedAttributes MUST include only one instance of
2721 any particular attribute.
2723 The hardware module MUST include the content-type and message-digest
2724 attributes. If the hardware module includes a real-time clock, then
2725 the hardware module SHOULD also include the signing-time attribute.
2726 The hardware module MAY include any other attribute that it deems
2727 appropriate.
2729 4.2.1. Content Type
2731 The hardware module MUST include a content-type attribute with the
2732 value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18).
2733 Section 11.1 of [CMS] defines the content-type attribute.
2735 4.2.2. Message Digest
2737 The hardware module MUST include a message-digest attribute, having
2738 as its value the message digest of the FirmwarePackageLoadError
2739 content. Section 11.2 of [CMS] defines the message-digest attribute.
2746 Housley Standards Track [Page 49]
2747 \f
2748 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2751 4.2.3. Signing Time
2753 If the hardware module includes a real-time clock, then hardware
2754 module SHOULD include a signing-time attribute, specifying the time
2755 at which the firmware package load error report was generated.
2756 Section 11.3 of [CMS] defines the signing-time attribute.
2758 5. Hardware Module Name
2760 Support for firmware package load receipts, as discussed in Section
2761 3, is OPTIONAL, and support for the firmware package load error
2762 reports, as discussed in Section 4, is OPTIONAL. Hardware modules
2763 that support receipt or error report generation MUST have unique
2764 serial numbers. Further, hardware modules that support signed
2765 receipt or error report generation MUST have private signature keys
2766 and corresponding signature validation certificates [PROFILE] or
2767 their designators. The conventions for hardware module naming in the
2768 signature validation certificates are specified in this section.
2770 The hardware module vendor or a trusted third party MUST issue the
2771 signature validation certificate prior to deployment of the hardware
2772 module. The certificate is likely to be issued at the time of
2773 manufacture. The subject alternative name in this certificate
2774 identifies the hardware module. The subject distinguished name is
2775 empty, but a critical subject alternative name extension contains the
2776 hardware module name, using the otherName choice within the
2777 GeneralName structure.
2779 The hardware module name form is identified by the id-on-
2780 hardwareModuleName object identifier:
2782 id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
2783 iso(1) identified-organization(3) dod(6) internet(1) security(5)
2784 mechanisms(5) pkix(7) on(8) 4 }
2786 A HardwareModuleName is composed of an object identifier and an octet
2787 string:
2789 HardwareModuleName ::= SEQUENCE {
2790 hwType OBJECT IDENTIFIER,
2791 hwSerialNum OCTET STRING }
2793 The fields of the HardwareModuleName type have the following
2794 meanings:
2796 hwType is an object identifier that identifies the type of hardware
2797 module. A unique object identifier names a hardware model and
2798 revision.
2802 Housley Standards Track [Page 50]
2803 \f
2804 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2807 hwSerialNum is the serial number of the hardware module. No
2808 particular structure is imposed on the serial number; it need not
2809 be an integer. However, the combination of the hwType and
2810 hwSerialNum uniquely identifies the hardware module.
2812 6. Security Considerations
2814 This document describes the use of the Cryptographic Message Syntax
2815 (CMS) to protect firmware packages; therefore, the security
2816 considerations discussed in [CMS] apply to this specification as
2817 well.
2819 The conventions specified in this document raise a few security
2820 considerations of their own.
2822 6.1. Cryptographic Keys and Algorithms
2824 Private signature keys must be protected. Compromise of the private
2825 key used to sign firmware packages permits unauthorized parties to
2826 generate firmware packages that are acceptable to hardware modules.
2827 Compromise of the hardware module private key allows unauthorized
2828 parties to generate signed firmware package load receipts and error
2829 reports.
2831 The firmware-decryption key must be protected. Compromise of the key
2832 may result in the disclosure of the firmware package to unauthorized
2833 parties.
2835 Cryptographic algorithms become weaker with time. As new
2836 cryptanalysis techniques are developed and computing performance
2837 improves, the work factor to break a particular cryptographic
2838 algorithm will be reduced. The ability to change the firmware
2839 package provides an opportunity to update or replace cryptographic
2840 algorithms. Although this capability is desirable, cryptographic
2841 algorithm replacement can lead to interoperability failures.
2842 Therefore, the rollout of new cryptographic algorithms must be
2843 managed. Generally, the previous generation of cryptographic
2844 algorithms and their replacements need to be supported at the same
2845 time in order to facilitate an orderly transition.
2847 6.2. Random Number Generation
2849 When firmware packages are encrypted, the source of the firmware
2850 package must randomly generate firmware-encryption keys. Also, the
2851 generation of public/private signature key pairs relies on a random
2852 numbers. The use of inadequate pseudo-random number generators
2853 (PRNGs) to generate cryptographic keys can result in little or no
2854 security. An attacker may find it much easier to reproduce the PRNG
2858 Housley Standards Track [Page 51]
2859 \f
2860 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2863 environment that produced the keys, searching the resulting small set
2864 of possibilities, rather than brute-force searching the whole key
2865 space. The generation of quality random numbers is difficult. RFC
2866 4086 [RANDOM] offers important guidance in this area.
2868 6.3. Stale Firmware Package Version Number
2870 The firmware signer determines whether a stale version number is
2871 included. The policy of the firmware signer needs to consider many
2872 factors. Consider the flaw found by Ian Goldberg and David Wagner in
2873 the random number generator of the Netscape browser in 1996 [DDJ].
2874 This flaw completely undermines confidentiality protection. A
2875 firmware signer might use the stale version number to ensure that
2876 upgraded hardware modules do not resume use of the flawed firmware.
2877 However, another firmware signer may not consider this an appropriate
2878 situation to employ the stale version number, preferring to delegate
2879 this decision to someone closer to the operation of the hardware
2880 module. Such a person is likely to be in a better position to
2881 evaluate whether other bugs introduced in the newer firmware package
2882 impose worse operational concerns than the confidentiality concern
2883 caused by the flawed random number generator. For example, a user
2884 who never uses the encryption feature of the flawed Netscape browser
2885 will determine the most appropriate version to use without
2886 considering the random number flaw or its fix.
2888 The stale version number is especially useful when the security
2889 interests of the person choosing which firmware package version to
2890 load into a particular hardware module do not align with the security
2891 interests of the firmware package signer. For example, stale version
2892 numbers may be useful in hardware modules that provide digital rights
2893 management (DRM). Also, stale version numbers will be useful when
2894 the deployment organization (as opposed to the firmware package
2895 vendor) is the firmware signer. Further, stale version numbers will
2896 be useful for firmware packages that need to be trusted to implement
2897 organizational (as opposed to the deployment organization) security
2898 policy, regardless of whether the firmware signer is the deployment
2899 organization or the vendor. For example, hardware devices employed
2900 by the military will probably make use of stale version numbers.
2902 The use of a stale version number in a firmware package that employs
2903 the preferred firmware package name form cannot completely prevent
2904 subsequent use of the stale firmware package. Despite this
2905 shortcoming, the feature is included since it is useful in some
2906 important situations. By loading different types of firmware
2907 packages, each with its own stale firmware package version number
2908 until the internal storage for the stale version number is exceeded,
2909 the user can circumvent the mechanism. Consider a hardware module
2914 Housley Standards Track [Page 52]
2915 \f
2916 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2919 that has storage for two stale version numbers. Suppose that FWPKG-A
2920 version 3 is loaded, indicating that FWPKG-A version 2 is stale. The
2921 user can sequentially load the following:
2923 - FWPKG-B version 8, indicating that FWPKG-B version 4 is stale.
2924 (Note: The internal storage indicates that FWPKG-A version 2
2925 and FWPKG-B version 4 are stale.)
2927 - FWPKG-C version 5, indicating that FWPKG-C version 3 is stale.
2928 (Note: The internal storage indicates that FWPKG-B version 4
2929 and FWPKG-C version 3 are stale.)
2931 - FWPKG-A version 2.
2933 Because many hardware modules are expected to have very few firmware
2934 packages written for them, the stale firmware package version feature
2935 provides important protections. The amount of non-volatile storage
2936 that needs to be dedicated to saving firmware package identifiers and
2937 version numbers depends on the number of firmware packages that are
2938 likely to be developed for the hardware module.
2940 The use of legacy firmware package name form does not improve this
2941 situation. In fact, the legacy firmware package names are usually
2942 larger than an object identifier. Thus, comparable stale version
2943 protection requires more memory.
2945 A firmware signer can ensure that stale version numbers are honored
2946 by limiting the number of different types of firmware packages that
2947 are signed. If all of the hardware modules are able to store a stale
2948 version number for each of the different types of firmware package,
2949 then the hardware module will be able to provide the desired
2950 protection. This requires the firmware signer to have a deep
2951 understanding of all of the hardware modules that might accept the
2952 firmware package.
2954 6.4. Community Identifiers
2956 When a firmware package includes a community identifier, the
2957 confidence that the package is only used by the intended community
2958 depends on the mechanism used to configure community membership.
2959 This document does not specify a mechanism for the assignment of
2960 community membership to hardware modules, and the various
2961 alternatives have different security properties. Also, the authority
2962 that makes community identifier assignments to hardware modules might
2963 be different than the authority that generates firmware packages.
2970 Housley Standards Track [Page 53]
2971 \f
2972 RFC 4108 Using CMS to Protect Firmware Packages August 2005
2975 7. References
2977 7.1. Normative References
2979 [COMPRESS] Gutmann, P., "Compressed Data Content Type for
2980 Cryptographic Message Syntax (CMS)", RFC 3274, June
2981 2002.
2983 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
2984 3852, July 2004.
2986 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
2987 RFC 2634, June 1999.
2989 [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
2990 X.509 Public Key Infrastructure Certificate and
2991 Certificate Revocation List (CRL) Profile", RFC 3280,
2992 April 2002.
2994 [SHA1] National Institute of Standards and Technology. FIPS
2995 Pub 180-1: Secure Hash Standard. 17 April 1995.
2997 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
2998 Requirement Levels", BCP 14, RFC 2119, March 1997.
3000 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
3001 10646", STD 63, RFC 3629, November 2003.
3003 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
3004 Syntax Notation One (ASN.1). 1988.
3006 [X.209-88] CCITT. Recommendation X.209: Specification of Basic
3007 Encoding Rules for Abstract Syntax Notation One (ASN.1).
3008 1988.
3010 [X.509-88] CCITT. Recommendation X.509: The Directory -
3011 Authentication Framework. 1988.
3013 7.2. Informative References
3015 [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute
3016 Certificate Profile for Authorization", RFC 3281, April
3017 2002.
3019 [AES] National Institute of Standards and Technology. FIPS
3020 Pub 197: Advanced Encryption Standard (AES). 26
3021 November 2001.
3026 Housley Standards Track [Page 54]
3027 \f
3028 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3031 [DDJ] Goldberg, I. and D. Wagner. "Randomness and the
3032 Netscape Browser." Dr. Dobb's Journal, January 1996.
3034 [DPD&DPV] Pinkas, D. and R. Housley, "Delegated Path Validation
3035 and Delegated Path Discovery Protocol Requirements", RFC
3036 3379, September 2002.
3038 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
3039 Adams, "X.509 Internet Public Key Infrastructure Online
3040 Certificate Status Protocol - OCSP", RFC 2560, June
3041 1999.
3043 [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax
3044 Standard, Version 1.5. November 1993.
3046 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
3047 "Randomness Requirements for Security", BCP 106, RFC
3048 4086, June 2005.
3050 [SECREQMTS] National Institute of Standards and Technology. FIPS
3051 Pub 140-2: Security Requirements for Cryptographic
3052 Modules. 25 May 2001.
3054 [X.509-97] ITU-T. Recommendation X.509: The Directory -
3055 Authentication Framework. 1997.
3057 [X.509-00] ITU-T. Recommendation X.509: The Directory -
3058 Authentication Framework. 2000.
3082 Housley Standards Track [Page 55]
3083 \f
3084 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3087 Appendix A: ASN.1 Module
3089 The ASN.1 module contained in this appendix defines the structures
3090 that are needed to implement the CMS-based firmware package wrapper.
3091 It is expected to be used in conjunction with the ASN.1 modules in
3092 [CMS], [COMPRESS], and [PROFILE].
3095 CMSFirmwareWrapper
3096 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
3097 pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
3099 DEFINITIONS IMPLICIT TAGS ::= BEGIN
3101 IMPORTS
3102 EnvelopedData
3103 FROM CryptographicMessageSyntax -- [CMS]
3104 { iso(1) member-body(2) us(840) rsadsi(113549)
3105 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
3108 -- Firmware Package Content Type and Object Identifier
3110 id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
3111 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3112 smime(16) ct(1) 16 }
3114 FirmwarePkgData ::= OCTET STRING
3117 -- Firmware Package Signed Attributes and Object Identifiers
3119 id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
3120 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3121 smime(16) aa(2) 35 }
3123 FirmwarePackageIdentifier ::= SEQUENCE {
3124 name PreferredOrLegacyPackageIdentifier,
3125 stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
3127 PreferredOrLegacyPackageIdentifier ::= CHOICE {
3128 preferred PreferredPackageIdentifier,
3129 legacy OCTET STRING }
3131 PreferredPackageIdentifier ::= SEQUENCE {
3132 fwPkgID OBJECT IDENTIFIER,
3133 verNum INTEGER (0..MAX) }
3138 Housley Standards Track [Page 56]
3139 \f
3140 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3143 PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
3144 preferredStaleVerNum INTEGER (0..MAX),
3145 legacyStaleVersion OCTET STRING }
3148 id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
3149 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3150 smime(16) aa(2) 36 }
3152 TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
3155 id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
3156 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3157 smime(16) aa(2) 37 }
3159 DecryptKeyIdentifier ::= OCTET STRING
3162 id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
3163 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3164 smime(16) aa(2) 38 }
3166 ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
3168 id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
3169 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3170 smime(16) aa(2) 43 }
3172 ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
3175 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
3176 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3177 smime(16) aa(2) 40 }
3179 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
3181 CommunityIdentifier ::= CHOICE {
3182 communityOID OBJECT IDENTIFIER,
3183 hwModuleList HardwareModules }
3185 HardwareModules ::= SEQUENCE {
3186 hwType OBJECT IDENTIFIER,
3187 hwSerialEntries SEQUENCE OF HardwareSerialEntry }
3194 Housley Standards Track [Page 57]
3195 \f
3196 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3199 HardwareSerialEntry ::= CHOICE {
3200 all NULL,
3201 single OCTET STRING,
3202 block SEQUENCE {
3203 low OCTET STRING,
3204 high OCTET STRING } }
3207 id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
3208 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3209 smime(16) aa(2) 42 }
3211 FirmwarePackageInfo ::= SEQUENCE {
3212 fwPkgType INTEGER OPTIONAL,
3213 dependencies SEQUENCE OF
3214 PreferredOrLegacyPackageIdentifier OPTIONAL }
3217 -- Firmware Package Unsigned Attributes and Object Identifiers
3219 id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
3220 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3221 smime(16) aa(2) 39 }
3223 WrappedFirmwareKey ::= EnvelopedData
3226 -- Firmware Package Load Receipt Content Type and Object Identifier
3228 id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
3229 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3230 smime(16) ct(1) 17 }
3232 FirmwarePackageLoadReceipt ::= SEQUENCE {
3233 version FWReceiptVersion DEFAULT v1,
3234 hwType OBJECT IDENTIFIER,
3235 hwSerialNum OCTET STRING,
3236 fwPkgName PreferredOrLegacyPackageIdentifier,
3237 trustAnchorKeyID OCTET STRING OPTIONAL,
3238 decryptKeyID [1] OCTET STRING OPTIONAL }
3240 FWReceiptVersion ::= INTEGER { v1(1) }
3250 Housley Standards Track [Page 58]
3251 \f
3252 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3255 -- Firmware Package Load Error Report Content Type
3256 -- and Object Identifier
3258 id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
3259 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
3260 smime(16) ct(1) 18 }
3262 FirmwarePackageLoadError ::= SEQUENCE {
3263 version FWErrorVersion DEFAULT v1,
3264 hwType OBJECT IDENTIFIER,
3265 hwSerialNum OCTET STRING,
3266 errorCode FirmwarePackageLoadErrorCode,
3267 vendorErrorCode VendorLoadErrorCode OPTIONAL,
3268 fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
3269 config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
3271 FWErrorVersion ::= INTEGER { v1(1) }
3273 CurrentFWConfig ::= SEQUENCE {
3274 fwPkgType INTEGER OPTIONAL,
3275 fwPkgName PreferredOrLegacyPackageIdentifier }
3277 FirmwarePackageLoadErrorCode ::= ENUMERATED {
3278 decodeFailure (1),
3279 badContentInfo (2),
3280 badSignedData (3),
3281 badEncapContent (4),
3282 badCertificate (5),
3283 badSignerInfo (6),
3284 badSignedAttrs (7),
3285 badUnsignedAttrs (8),
3286 missingContent (9),
3287 noTrustAnchor (10),
3288 notAuthorized (11),
3289 badDigestAlgorithm (12),
3290 badSignatureAlgorithm (13),
3291 unsupportedKeySize (14),
3292 signatureFailure (15),
3293 contentTypeMismatch (16),
3294 badEncryptedData (17),
3295 unprotectedAttrsPresent (18),
3296 badEncryptContent (19),
3297 badEncryptAlgorithm (20),
3298 missingCiphertext (21),
3299 noDecryptKey (22),
3300 decryptFailure (23),
3301 badCompressAlgorithm (24),
3302 missingCompressedContent (25),
3306 Housley Standards Track [Page 59]
3307 \f
3308 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3311 decompressFailure (26),
3312 wrongHardware (27),
3313 stalePackage (28),
3314 notInCommunity (29),
3315 unsupportedPackageType (30),
3316 missingDependency (31),
3317 wrongDependencyVersion (32),
3318 insufficientMemory (33),
3319 badFirmware (34),
3320 unsupportedParameters (35),
3321 breaksDependency (36),
3322 otherError (99) }
3324 VendorLoadErrorCode ::= INTEGER
3327 -- Other Name syntax for Hardware Module Name
3329 id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
3330 iso(1) identified-organization(3) dod(6) internet(1) security(5)
3331 mechanisms(5) pkix(7) on(8) 4 }
3333 HardwareModuleName ::= SEQUENCE {
3334 hwType OBJECT IDENTIFIER,
3335 hwSerialNum OCTET STRING }
3338 END
3340 Author's Address
3342 Russell Housley
3343 Vigil Security, LLC
3344 918 Spring Knoll Drive
3345 Herndon, VA 20170
3346 USA
3348 EMail: housley@vigilsec.com
3362 Housley Standards Track [Page 60]
3363 \f
3364 RFC 4108 Using CMS to Protect Firmware Packages August 2005
3367 Full Copyright Statement
3369 Copyright (C) The Internet Society (2005).
3371 This document is subject to the rights, licenses and restrictions
3372 contained in BCP 78, and except as set forth therein, the authors
3373 retain all their rights.
3375 This document and the information contained herein are provided on an
3376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3378 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3379 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3380 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3383 Intellectual Property
3385 The IETF takes no position regarding the validity or scope of any
3386 Intellectual Property Rights or other rights that might be claimed to
3387 pertain to the implementation or use of the technology described in
3388 this document or the extent to which any license under such rights
3389 might or might not be available; nor does it represent that it has
3390 made any independent effort to identify any such rights. Information
3391 on the procedures with respect to rights in RFC documents can be
3392 found in BCP 78 and BCP 79.
3394 Copies of IPR disclosures made to the IETF Secretariat and any
3395 assurances of licenses to be made available, or the result of an
3396 attempt made to obtain a general license or permission for the use of
3397 such proprietary rights by implementers or users of this
3398 specification can be obtained from the IETF on-line IPR repository at
3399 http://www.ietf.org/ipr.
3401 The IETF invites any interested party to bring to its attention any
3402 copyrights, patents or patent applications, or other proprietary
3403 rights that may cover technology that may be required to implement
3404 this standard. Please address the information to the IETF at ietf-
3405 ipr@ietf.org.
3407 Acknowledgement
3409 Funding for the RFC Editor function is currently provided by the
3410 Internet Society.
3418 Housley Standards Track [Page 61]
3419 \f