idnits 2.17.1 draft-turner-application-firmware-media-types-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 30, 2013) is 4007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6838' is mentioned on line 165, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) S. Turner 3 Internet Draft IECA 4 Intended Status: Informational R. Housley 5 Expires: November 1, 2013 Vigil Security 6 April 30, 2013 8 The application/firmware, application/firmware-receipt, and 9 application/firmware-error media types 10 draft-turner-application-firmware-media-types-00.txt 12 Abstract 14 This document registers the application/firmware, 15 application/firmware-receipt and application/firmware-error media 16 media types for use with the corresponding CMS (Cryptographic Message 17 Syntax) content types defined in RFC 4108. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 [RFC4108] defined three CMS (Cryptographic Message Syntax) [RFC5652] 52 content types for servers to distribute Firmware packages as well as 53 clients to return receipts and errors. Three media types are 54 defined in this document to support the transfer of firmware 55 packages, firmware package receipts, and firmware package errors. 57 Firmware packages, firmware package receipts, and firmware package 58 errors are always encapsulated within ContentInfo structures 59 [RFC4108]. Firmware packages are additionally encapsulated within a 60 SignedData structure [RFC4108]. Firmware package receipts and errors 61 can be digitally signed and to indicate this option an optional 62 parameters is defined: protection=signed. 64 1.1. Requirements Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Media Type Registration Applications 72 2.1. Firmware Package Receipt 74 This section provides the media type registration application for the 75 application/firmware-receipt media type (see [RFC6838], Section 5.6). 77 Type name: application 79 Subtype name: firmware 81 Required parameters: None 83 Optional parameters: None 85 Encoding considerations: binary. 87 Security considerations: See [RFC4108]. 89 Interoperability considerations: See [RFC4108]. 91 Published specification: RFC 4108 and this specification. 93 Applications which use this media type: 95 Applications that support Firmware Package Receipts [RFC4108]. 97 Additional information: 99 Magic number(s): None 100 File extension(s): .fp 101 Macintosh File Type Code(s): 103 Person & email address to contact for further information: 105 Sean Turner 107 Restrictions on usage: none 109 Author: Sean Turner 111 Intended usage: COMMON 113 Change controller: The IESG 115 2.2. Firmware Package Receipt 117 This section provides the media type registration application for 118 the application/firmware-receipt media type (see [RFC6838], Section 119 5.6). 121 Type name: application 123 Subtype name: firmware-receipt 125 Required parameters: None 127 Optional parameters: 129 Implementations can indicate whether the firmware package was 130 signed with the following parameter: protection=signed. 132 Encoding considerations: binary. 134 Security considerations: See [RFC4108]. 136 Interoperability considerations: See [RFC4108]. 138 Published specification: RFC 4108 and this specification. 140 Applications which use this media type: 142 Applications that support Firmware Package Receipts [RFC4108]. 144 Additional information: 146 Magic number(s): None 147 File extension(s): .fpr 148 Macintosh File Type Code(s): 150 Person & email address to contact for further information: 152 Sean Turner 154 Restrictions on usage: none 156 Author: Sean Turner 158 Intended usage: COMMON 160 Change controller: The IESG 162 2.3. Firmware Package Errors 164 This section provides the media type registration application for 165 this media type (see [RFC6838], Section 5.6). 167 Type name: application 169 Subtype name: firmware-error 171 Required parameters: None 173 Optional parameters: 175 Implementations can indicate whether the firmware package was 176 signed with the following optional parameter: protection=signed. 178 Encoding considerations: binary. 180 Security considerations: See [RFC4108]. 182 Interoperability considerations: See [RFC4108]. 184 Published specification: RFC 4108 and this specification. 186 Applications which use this media type: 188 Applications that support Firmware Key Package Errors [RFC4108]. 190 Additional information: 192 Magic number(s): None 193 File extension(s): .fpe 194 Macintosh File Type Code(s): 196 Person & email address to contact for further information: 198 Sean Turner 200 Restrictions on usage: none 202 Author: Sean Turner 204 Intended usage: COMMON 206 Change controller: The IESG 208 3. IANA Considerations 210 IANA is asked to register the media type application/firmware, 211 application/firmware-receipt, and application/firmware-error in the 212 Standards tree using the applications provided in Section 2.1-2.3 of 213 this document. 215 4. Security Considerations 217 No new security considerations are introduced in additional those 218 specified in [RFC4108]. 220 5. References 222 5.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 228 Protect Firmware Packages", RFC 4108, August 2005. 230 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 231 RFC 5652, September 2009. 233 5.2. Informative References 235 None. 237 Authors' Addresses 238 Sean Turner 239 IECA, Inc. 240 3057 Nutley Street, Suite 106 241 Fairfax, VA 22031 242 USA 244 EMail: turners@ieca.com 245 Phone: +1.703.628.3180 247 Russell Housley 248 Vigil Security, LLC 249 918 Spring Knoll Drive 250 Herndon, VA 20170 251 USA 253 EMail: housley@vigilsec.com