idnits 2.17.1 draft-thomson-http-content-signature-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 2, 2015) is 3221 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-thomson-http-encryption-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-12) exists of draft-reschke-http-oob-encoding-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational July 2, 2015 5 Expires: January 3, 2016 7 Content-Signature Header Field for HTTP 8 draft-thomson-http-content-signature-00 10 Abstract 12 A Content-Signature header field is defined for use in HTTP. This 13 header field carries a signature of the payload body of a message. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 3, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Content-Signature Header Field . . . . . . . . . . . . . 3 53 3. Describing Signature Keys . . . . . . . . . . . . . . . . . . 4 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Content-Signature Header Field . . . . . . . . . . . . . 5 57 5.2. Content-Signature Parameter Registry . . . . . . . . . . 5 58 5.2.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2.2. p256ecdsa . . . . . . . . . . . . . . . . . . . . . . 6 60 5.3. The p256ecdsa Parameter for the Encryption-Key Header 61 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 6.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The Content-Signature header field carries a signature of the payload 70 body of an HTTP message [RFC7230]. This allows for content to be 71 protected from modification. 73 The exchange of high-value messages via intermediaries is often 74 necessary in HTTP for operational reasons. While those 75 intermediaries might be trusted with the information that they 76 forward, some clients or servers might desire greater assurances 77 about the integrity of the information they receive. 79 No protection is provided for header fields. If integrity is 80 important, only the information in the message payload can be relied 81 upon. 83 No key management mechanism is defined. Other specifications are 84 expected to describe how recipients determine what credibility is 85 attributed to any given signature key. 87 1.1. Terminology 89 RFC 2119 [RFC2119] defines the terms MUST, SHOULD, and MAY. 91 1.2. Example 93 The following HTTP/1.1 response is signed. Line wrapping is added to 94 fit formatting constraints. 96 HTTP/1.1 200 OK 97 Date: Wed, 17 Jun 2015 17:14:17 GMT 98 Content-Length: 15 99 Encryption-Key: keyid=a; 100 p256ecdsa=BDUJCg0PKtFrgI_lc5ar9qBm83cH_QJomSjXYUkIlswX 101 KTdYLlJjFEWlIThQ0Y-TFZyBbUinNp-rou13Wve_Y_A 102 Content-Signature: keyid=a; 103 p256ecdsa=Hil-_2xU6BjQcU6a8nhMCChLr-fkrek5tE6pokWlJb0 104 HkQiryW045vVpljN_xBbF8sTrsWb9MiQLCdYlP1jZtA 106 Hello, World! 108 2. The Content-Signature Header Field 110 The Content-Signature header field uses the extended ABNF syntax 111 defined in Section 1.2 of [RFC7230] and the "parameter" rule from 112 [RFC7231]. 114 Content-Signature = 1#csig_params 115 csig_params = [ parameter *( ";" parameter ) ] 117 Each content signature is separated by a comma (,) and is compromised 118 of zero or more colon-separated parameters. 120 The message payload is prefixed with the string "Content-Encryption:" 121 and a single zero-valued octet before being passed to the signature 122 algorithm. This discriminator string reduces the chances that a 123 signature is viable for reuse in other contexts. 125 The following parameters are defined: 127 keyid: This parameter identifies the key that was used to produce 128 the signature. This could identify a key that is carried in the 129 Encryption-Key header field. This parameter can always be 130 provided together with other parameters. 132 p256ecdsa: This parameter contains an ECDSA [X.692] signature on the 133 P-256 curve [FIPS186]. The signature is produced using the 134 SHA-256 hash [FIPS180-2]. The resulting signature is encoded 135 using URL-safe variant of base-64 [RFC4648]. No parameters other 136 than "keyid" can be specified along with the "p256ecdsa" 137 parameter. 139 Additional header field values can be defined and registered. The 140 parameter MUST describe how the signature is produced and encoded. 142 Though the parameter defined in this document do not contain any 143 optional or parameterized features, new signature algorithms MAY use 144 additional parameters for conveying information about optional 145 features. The definition of new parameters SHOULD describe what 146 parameters can be combined with that parameter and the resulting 147 semantics. 149 The Content-Signature header field might be most efficiently produced 150 as a trailer field. This allows for the production of the message 151 body and the signature in a single pass. 153 3. Describing Signature Keys 155 A message MAY include a signing key. This can be used to provision 156 trusted keys. 158 Providing an encryption key is typically only useful where the 159 provision of the key can be attributed a higher level of trust than 160 the signature. A message sent using out-of-band content-encoding 161 [I-D.reschke-http-oob-encoding] is one situation that benefits from 162 the use of this header field. 164 Alternatively, explicitly including a public key can allow a verifier 165 to correctly identify the key that was used if the "keyid" parameter 166 is not sufficient. 168 This document defines a new parameter for use with the "Encryption- 169 Key" header field. The "p256ecdsa" parameter conveys an uncompressed 170 P-256 public key [X.692] that is encoded using URL-safe variant of 171 base-64 [RFC4648]. 173 4. Security Considerations 175 Determining whether a signature is valid is only a small part of 176 authenticating a message. This document doesn't describe a complete 177 solution for identifying which signing keys are accepted. 179 This scheme does not authenticate header fields, or other request or 180 response metadata. A recipient of a signed payload needs to be 181 especially careful that decisions that rely on authenticating the 182 payload do not take any unauthenticated material as input. In 183 particular, the request URI and the "Content-Type" header field are 184 not authenticated by this scheme. 186 No replay protection is offered for signatures. This means that 187 valid messages can be captured and replayed. Since there is no 188 binding between the identity of a resource and the signature, the 189 content of a message can be replayed for a request or response to a 190 different resource; requests can be replayed as responses; and 191 messages can be replayed at different times. 193 Replay protection can be provided by including information in the 194 message payload itself that binds the content to a specific resource, 195 time or any other contextual information. 197 5. IANA Considerations 199 5.1. Content-Signature Header Field 201 This memo registers the "Content-Signature" HTTP header field in the 202 Permanent Message Header Registry, as detailed in Section 2. 204 o Field name: Content-Signature 206 o Protocol: HTTP 208 o Status: Standard 210 o Reference: Section 2 of this specification 212 o Notes: 214 5.2. Content-Signature Parameter Registry 216 A registry is established for parameters used by the "Content- 217 Signature" header field under the "Hypertext Transfer Protocol (HTTP) 218 Parameters" grouping. The "Hypertext Transfer Protocol (HTTP) 219 Encryption Parameters" operates under an "Specification Required" 220 policy [RFC5226]. The designated expert is advised to consider the 221 guidance in Section 2 when reviewing new registrations. 223 o Parameter Name: The name of the parameter. 225 o Purpose: A brief description of the purpose of the parameter. 227 o Reference: A reference to a specification that defines the 228 semantics of the parameter. 230 The initial contents of this registry are: 232 5.2.1. keyid 234 o Parameter Name: keyid 236 o Purpose: Identify the key that is in use. 238 o Reference: Section 2 of this document 240 5.2.2. p256ecdsa 242 o Parameter Name: p256ecdsa 244 o Purpose: Conveys a signature using P-256, ECDSA and SHA-256 as 245 described in Section 2 of this document. 247 o Reference: Section 2 of this document 249 5.3. The p256ecdsa Parameter for the Encryption-Key Header Field 251 The "p256ecdsa" parameter is registered in the "Hypertext Transfer 252 Protocol (HTTP) Encryption Parameters" registry established in 253 [I-D.thomson-http-encryption], with the following values: 255 o Parameter Name: p256ecdsa 257 o Purpose: Conveys a signing key for use with the parameter of the 258 same name on the "Content-Signature" header field. 260 o Reference: Section 3 of this document 262 6. References 264 6.1. Normative References 266 [FIPS180-2] 267 Department of Commerce, National., "NIST FIPS 180-2, 268 Secure Hash Standard", August 2002. 270 [FIPS186] National Institute of Standards and Technology (NIST), 271 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 272 2013. 274 [I-D.thomson-http-encryption] 275 Thomson, M., "Encrypted Content-Encoding for HTTP", draft- 276 thomson-http-encryption-01 (work in progress), July 2015. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 282 Encodings", RFC 4648, October 2006. 284 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 285 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 286 May 2008. 288 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 289 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 290 2014. 292 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 293 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 295 [X.692] ANSI, "Public Key Cryptography For The Financial Services 296 Industry: The Elliptic Curve Digital Signature Algorithm 297 (ECDSA)", ANSI X9.62 , 1998. 299 6.2. Informative References 301 [I-D.reschke-http-oob-encoding] 302 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 303 for HTTP", draft-reschke-http-oob-encoding-00 (work in 304 progress), June 2015. 306 Author's Address 308 Martin Thomson 309 Mozilla 311 Email: martin.thomson@gmail.com