idnits 2.17.1 draft-richanna-http-message-signatures-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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (12 December 2019) is 1597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group A. Backman, Ed. 3 Internet-Draft Amazon 4 Intended status: Standards Track J. Richer 5 Expires: 14 June 2020 Bespoke Engineering 6 M. Sporny 7 Digital Bazaar 8 12 December 2019 10 Signing HTTP Messages 11 draft-richanna-http-message-signatures-00 13 Abstract 15 This document describes a mechanism for creating, encoding, and 16 verifying digital signatures or message authentication codes over 17 content within an HTTP message. This mechanism supports use cases 18 where the full HTTP message may not be known to the signer, and where 19 the message may be transformed (e.g., by intermediaries) before 20 reaching the verifier. 22 Note 24 This draft is based on draft-cavage-http-signatures-12. The 25 community (https://github.com/w3c-dvcg/http-signatures/ 26 issues?page=2&q=is%3Aissue+is%3Aopen) and the authors have identified 27 several issues with the current text. Additionally, the authors have 28 identified a number of features that are required in order to support 29 additional use cases. In order to preserve continuity with the 30 effort that has been put into draft-cavage-http-signatures-12, this 31 draft maintains normative compatibility with it, and thus does not 32 address these issues or include these features, as doing so requires 33 making backwards-incompatible changes to normative requirements. 34 While such changes are inevitable, the editor recommends that they be 35 driven by working group discussion following adoption of the draft 36 (see Topics for Working Group Discussion). The editor requests that 37 the working group recognize the intent of this initial draft and this 38 recommendation when considering adoption of this draft. 40 This note is to be removed before publishing as an RFC. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 14 June 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Simplified BSD License text 70 as described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements Discussion . . . . . . . . . . . . . . . . . 4 77 1.2. HTTP Message Transformations . . . . . . . . . . . . . . 5 78 1.3. Safe Transformations . . . . . . . . . . . . . . . . . . 5 79 1.4. Conventions and Terminology . . . . . . . . . . . . . . . 6 80 2. Identifying and Canonicalizing Content . . . . . . . . . . . 7 81 2.1. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 7 82 2.2. Signature Creation Time . . . . . . . . . . . . . . . . . 8 83 2.3. Signature Expiration Time . . . . . . . . . . . . . . . . 9 84 2.4. Target Endpoint . . . . . . . . . . . . . . . . . . . . . 9 85 3. HTTP Message Signatures . . . . . . . . . . . . . . . . . . . 10 86 3.1. Signature Metadata . . . . . . . . . . . . . . . . . . . 10 87 3.2. Creating a Signature . . . . . . . . . . . . . . . . . . 11 88 3.2.1. Choose and Set Signature Metadata Properties . . . . 11 89 3.2.2. Create the Signature Input . . . . . . . . . . . . . 13 90 3.2.3. Sign the Signature Input . . . . . . . . . . . . . . 14 91 3.3. Verifying a Signature . . . . . . . . . . . . . . . . . . 14 92 3.3.1. Enforcing Application Requirements . . . . . . . . . 15 93 4. The 'Signature' HTTP Header . . . . . . . . . . . . . . . . . 15 94 4.1. Signature Header Parameters . . . . . . . . . . . . . . . 16 95 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 5.1. HTTP Signature Algorithms Registry . . . . . . . . . . . 17 98 5.1.1. Registration Template . . . . . . . . . . . . . . . . 17 99 5.1.2. Initial Contents . . . . . . . . . . . . . . . . . . 18 100 5.2. HTTP Signature Parameters Registry . . . . . . . . . . . 20 101 5.2.1. Registration Template . . . . . . . . . . . . . . . . 20 102 5.2.2. Initial Contents . . . . . . . . . . . . . . . . . . 20 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 106 7.2. Informative References . . . . . . . . . . . . . . . . . 22 107 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 108 A.1. Example Keys . . . . . . . . . . . . . . . . . . . . . . 23 109 A.1.1. "rsa-test" . . . . . . . . . . . . . . . . . . . . . 23 110 A.2. Example "keyId" Values . . . . . . . . . . . . . . . . . 24 111 A.3. Test Cases . . . . . . . . . . . . . . . . . . . . . . . 25 112 A.3.1. Signature Generation . . . . . . . . . . . . . . . . 25 113 A.3.2. Signature Verification . . . . . . . . . . . . . . . 27 114 Appendix B. Topics for Working Group Discussion . . . . . . . . 30 115 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 116 Document History . . . . . . . . . . . . . . . . . . . . . . . . 37 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 119 1. Introduction 121 Message integrity and authenticity are important security properties 122 that are critical to the secure operation of many [HTTP] 123 applications. Application developers typically rely on the transport 124 layer to provide these properties, by operating their application 125 over TLS [RFC8446]. However, TLS only guarantees these properties 126 over a single TLS connection, and the path between client and 127 application may be composed of multiple independent TLS connections 128 (for example, if the application is hosted behind a TLS-terminating 129 gateway or if the client is behind a TLS Inspection appliance). In 130 such cases, TLS cannot guarantee end-to-end message integrity or 131 authenticity between the client and application. Additionally, some 132 operating environments present obstacles that make it impractical to 133 use TLS, or to use features necessary to provide message 134 authenticity. Furthermore, some applications require the binding of 135 an application-level key to the HTTP message, separate from any TLS 136 certificates in use. Consequently, while TLS can meet message 137 integrity and authenticity needs for many HTTP-based applications, it 138 is not a universal solution. 140 This document defines a mechanism for providing end-to-end integrity 141 and authenticity for content within an HTTP message. The mechanism 142 allows applications to create digital signatures or message 143 authentication codes (MACs) over only that content within the message 144 that is meaningful and appropriate for the application. Strict 145 canonicalization rules ensure that the verifier can verify the 146 signature even if the message has been transformed in any of the many 147 ways permitted by HTTP. 149 The mechanism described in this document consists of three parts: 151 * A common nomenclature and canonicalization rule set for the 152 different protocol elements and other content within HTTP 153 messages. 155 * Algorithms for generating and verifying signatures over HTTP 156 message content using this nomenclature and rule set. 158 * A mechanism for attaching a signature and related metadata to an 159 HTTP message. 161 1.1. Requirements Discussion 163 HTTP permits and sometimes requires intermediaries to transform 164 messages in a variety of ways. This may result in a recipient 165 receiving a message that is not bitwise equivalent to the message 166 that was oringally sent. In such a case, the recipient will be 167 unable to verify a signature over the raw bytes of the sender's HTTP 168 message, as verifying digital signatures or MACs requires both signer 169 and verifier to have the exact same signed content. Since the raw 170 bytes of the message cannot be relied upon as signed content, the 171 signer and verifier must derive the signed content from their 172 respective versions of the message, via a mechanism that is resilient 173 to safe changes that do not alter the meaning of the message. 175 For a variety of reasons, it is impractical to strictly define what 176 constitutes a safe change versus an unsafe one. Applications use 177 HTTP in a wide variety of ways, and may disagree on whether a 178 particular piece of information in a message (e.g., the body, or the 179 Date header field) is relevant. Thus a general purpose solution must 180 provide signers with some degree of control over which message 181 content is signed. 183 HTTP applications may be running in environments that do not provide 184 complete access to or control over HTTP messages (such as a web 185 browser's JavaScript environment), or may be using libraries that 186 abstract away the details of the protocol (such as the Java 187 HTTPClient library (https://openjdk.java.net/groups/net/httpclient/ 188 intro.html)). These applications need to be able to generate and 189 verify signatures despite incomplete knowledge of the HTTP message. 191 1.2. HTTP Message Transformations 193 As mentioned earlier, HTTP explicitly permits and in some cases 194 requires implementations to transform messages in a variety of ways. 195 Implementations are required to tolerate many of these 196 transformations. What follows is a non-normative and non-exhaustive 197 list of transformations that may occur under HTTP, provided as 198 context: 200 * Re-ordering of header fields with different header field names 201 ([HTTP], Section 3.2.2). 203 * Combination of header fields with the same field name ([HTTP], 204 Section 3.2.2). 206 * Removal of header fields listed in the "Connection" header field 207 ([HTTP], Section 6.1). 209 * Addition of header fields that indicate control options ([HTTP], 210 Section 6.1). 212 * Addition or removal of a transfer coding ([HTTP], Section 5.7.2). 214 * Addition of header fields such as "Via" ([HTTP], Section 5.7.1) 215 and "Forwarded" ([RFC7239], Section 4). 217 1.3. Safe Transformations 219 Based on the definition of HTTP and the requirements described above, 220 we can identify certain types of transformations that should not 221 prevent signature verification, even when performed on content 222 covered by the signature. The following list describes those 223 transformations: 225 * Combination of header fields with the same field name. 227 * Reordering of header fields with different names. 229 * Conversion between HTTP/1.x and HTTP/2, or vice-versa. 231 * Changes in casing (e.g., "Origin" to "origin") of any case- 232 insensitive content such as header field names, request URI 233 scheme, or host. 235 * Addition or removal of leading or trailing whitespace to a header 236 field value. 238 * Addition or removal of "obs-fold"s. 240 * Changes to the request-target and Host header field that when 241 applied together do not result in a change to the message's 242 effective request URI, as defined in Section 5.5 of [HTTP]. 244 Additionally, all changes to content not covered by the signature are 245 considered safe. 247 1.4. Conventions and Terminology 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 251 "OPTIONAL" in this document are to be interpreted as described in 252 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 253 capitals, as shown here. 255 The terms "HTTP message", "HTTP method", "HTTP request", "HTTP 256 response", "absolute-form", "absolute-path", "effective request URI", 257 "gateway", "header field", "intermediary", "request-target", 258 "sender", and "recipient" are used as defined in [HTTP]. 260 For brevity, the term "signature" on its own is used in this document 261 to refer to both digital signatures and keyed MACs. Similarly, the 262 verb "sign" refers to the generation of either a digital signature or 263 keyed MAC over a given input string. The qualified term "digital 264 signature" refers specifically to the output of an asymmetric 265 cryptographic signing operation. 267 In addition to those listed above, this document uses the following 268 terms: 270 Decimal String 271 An Integer String optionally concatenated with a period ""."" 272 followed by a second Integer String, representing a positive real 273 number expressed in base 10. The first Integer String represents 274 the integral portion of the number, while the optional second 275 Integer String represents the fractional portion of the number. [[ 276 Editor's note: There's got to be a definition for this that we can 277 reference. ]] 279 Integer String 280 A US-ASCII string of one or more digits ""0-9"", representing a 281 positive integer in base 10. [[ Editor's note: There's got to be a 282 definition for this that we can reference. ]] 284 Signer 285 The entity that is generating or has generated an HTTP Message 286 Signature. 288 Verifier 289 An entity that is verifying or has verified an HTTP Message 290 Signature against an HTTP Message. Note that an HTTP Message 291 Signature may be verified multiple times, potentially by different 292 entities. 294 This document contains non-normative examples of partial and complete 295 HTTP messages. To improve readability, header fields may be split 296 into multiple lines, using the "obs-fold" syntax. This syntax is 297 deprecated in [HTTP], and senders MUST NOT generate messages that 298 include it. 300 2. Identifying and Canonicalizing Content 302 In order to allow signers and verifiers to establish which content is 303 covered by a signature, this document defines content identifiers for 304 signature metadata and discrete pieces of message content that may be 305 covered by an HTTP Message Signature. 307 Some content within HTTP messages may undergo transformations that 308 change the bitwise value without altering meaning of the content (for 309 example, the merging together of header fields with the same name). 310 Message content must therefore be canonicalized before it is signed, 311 to ensure that a signature can be verified despite such innocuous 312 transformations. This document defines rules for each content 313 identifier that transform the identifier's associated content into 314 such a canonical form. 316 The following sections define content identifiers, their associated 317 content, and their canonicalization rules. 319 2.1. HTTP Header Fields 321 An HTTP header field value is identified by its header field name. 322 While HTTP header field names are case-insensitive, implementations 323 SHOULD use lowercased field names (e.g., "content-type", "date", 324 "etag") when using them as content identifiers. 326 An HTTP header field value is canonicalized as follows: 328 1. Create an ordered list of the field values of each instance of 329 the header field in the message, in the order that they occur (or 330 will occur) in the message. 332 2. Strip leading and trailing whitespace from each item in the list. 334 3. Concatenate the list items together, with a comma "","" and space 335 "" "" between each item. The resulting string is the 336 canonicalized value. 338 2.1.1. Canonicalization Examples 340 This section contains non-normative examples of canonicalized values 341 for header fields, given the following example HTTP message: 343 HTTP/1.1 200 OK 344 Server: www.example.com 345 Date: Tue, 07 Jun 2014 20:51:35 GMT 346 X-OWS-Header: Leading and trailing whitespace. 347 X-Obs-Fold-Header: Obsolete 348 line folding. 349 X-Empty-Header: 350 Cache-Control: max-age=60 351 Cache-Control: must-revalidate 353 The following table shows example canonicalized values for header 354 fields, given that message: 356 +-----------------------+------------------------------------+ 357 | Header Field | Canonicalized Value | 358 +=======================+====================================+ 359 | "(cache-control)" | "max-age=60, must-revalidate" | 360 +-----------------------+------------------------------------+ 361 | "(date)" | "Tue, 07 Jun 2014 20:51:35 GMT" | 362 +-----------------------+------------------------------------+ 363 | "(server)" | "www.example.com" | 364 +-----------------------+------------------------------------+ 365 | "(x-empty-header)" | "" | 366 +-----------------------+------------------------------------+ 367 | "(x-obs-fold-header)" | "Obsolete line folding." | 368 +-----------------------+------------------------------------+ 369 | "(x-ows-header)" | "Leading and trailing whitespace." | 370 +-----------------------+------------------------------------+ 372 Table 1: Non-normative examples of header field 373 canonicalization. 375 2.2. Signature Creation Time 377 The signature's Creation Time (Section 3.1) is identified by the 378 "(created)" identifier. 380 Its canonicalized value is an Integer String containing the 381 signature's Creation Time expressed as the number of seconds since 382 the Epoch, as defined in Section 4.16 383 (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ 384 V1_chap04.html#tag_04_16) of [POSIX.1]. 386 | The use of seconds since the Epoch to canonicalize a timestamp 387 | simplifies processing and avoids timezone management required 388 | by specifications such as [RFC3339]. 390 2.3. Signature Expiration Time 392 The signature's Expiration Time (Section 3.1) is identified by the 393 "(expired)" identifier. 395 Its canonicalized value is a Decimal String containing the 396 signature's Expiration Time expressed as the number of seconds since 397 the Epoch, as defined in Section 4.16 398 (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ 399 V1_chap04.html#tag_04_16) of [POSIX.1]. 401 2.4. Target Endpoint 403 The request target endpoint, consisting of the request method and the 404 path and query of the effective request URI, is identified by the 405 "(request-target)" identifier. 407 Its value is canonicalized as follows: 409 1. Take the lowercased HTTP method of the message. 411 2. Append a space "" "". 413 3. Append the path and query of the request target of the message, 414 formatted according to the rules defined for the ":path" pseudo- 415 header in [HTTP2], Section 8.1.2.3. The resulting string is the 416 canonicalized value. 418 2.4.1. Canonicalization Examples 420 The following table contains non-normative example HTTP messages and 421 their canonicalized "(request-target)" values. 423 +-------------------------------------------+----------------------+ 424 | HTTP Message | "(request-target)" | 425 +===========================================+======================+ 426 | POST /?param=value HTTP/1.1 | "post /?param=value" | 427 | Host: www.example.com | | 428 +-------------------------------------------+----------------------+ 429 | POST /a/b HTTP/1.1 | "post /a/b" | 430 | Host: www.example.com | | 431 +-------------------------------------------+----------------------+ 432 | GET http://www.example.com/a/ HTTP/1.1 | "get /a/" | 433 +-------------------------------------------+----------------------+ 434 | GET http://www.example.com HTTP/1.1 | "get /" | 435 +-------------------------------------------+----------------------+ 436 | CONNECT server.example.com:80 HTTP/1.1 | "connect /" | 437 | Host: server.example.com | | 438 +-------------------------------------------+----------------------+ 439 | OPTIONS * HTTP/1.1 | "options *" | 440 | Host: server.example.com | | 441 +-------------------------------------------+----------------------+ 443 Table 2: Non-normative examples of "(request-target)" 444 canonicalization. 446 3. HTTP Message Signatures 448 An HTTP Message Signature is a signature over a string generated from 449 a subset of the content in an HTTP message and metadata about the 450 signature itself. When successfully verified against an HTTP 451 message, it provides cryptographic proof that with respect to the 452 subset of content that was signed, the message is semantically 453 equivalent to the message for which the signature was generated. 455 3.1. Signature Metadata 457 HTTP Message Signatures have metadata properties that provide 458 information regarding the signature's generation and/or verification. 459 The following metadata properties are defined: 461 Algorithm 462 An HTTP Signature Algorithm defined in the HTTP Signature 463 Algorithms Registry defined in this document. It describes the 464 signing and verification algorithms for the signature. 466 Creation Time 467 A timestamp representing the point in time that the signature was 468 generated. Sub-second precision is not supported. A signature's 469 Creation Time MAY be undefined, indicating that it is unknown. 471 Covered Content 472 An ordered list of content identifiers (Section 2) that indicates 473 the metadata and message content that is covered by the signature. 474 The order of identifiers in this list affects signature generation 475 and verification, and therefore MUST be preserved. 477 Expiration Time 478 A timestamp representing the point in time at which the signature 479 expires. An expired signature always fails verification. A 480 signature's Expiration Time MAY be undefined, indicating that the 481 signature does not expire. 483 Verification Key Material 484 The key material required to verify the signature. 486 3.2. Creating a Signature 488 In order to create a signature, a signer completes the following 489 process: 491 1. Choose key material and algorithm, and set metadata properties 492 (Section 3.2.1) 494 2. Create the Signature Input (Section 3.2.2) 496 3. Sign the Signature Input (Section 3.2.3) 498 The following sections describe each of these steps in detail. 500 3.2.1. Choose and Set Signature Metadata Properties 502 1. The signer chooses an HTTP Signature Algorithm from those 503 registered in the HTTP Signature Algorithms Registry defined by 504 this document, and sets the signature's Algorithm property to 505 that value. The signer MUST NOT choose an algorithm marked 506 "Deprecated". The mechanism by which the signer chooses an 507 algorithm is out of scope for this document. 509 2. The signer chooses key material to use for signing and 510 verification, and sets the signature's Verification Key Material 511 property to the key material required for verification. The 512 signer MUST choose key material that is appropriate for the 513 signature's Algorithm, and that conforms to any requirements 514 defined by the Algorithm, such as key size or format. The 515 mechanism by which the signer chooses key material is out of 516 scope for this document. 518 3. The signer sets the signature's Creation Time property to the 519 current time. 521 4. The signer sets the signature's Expiration Time property to the 522 time at which the signature is to expire, or to undefined if the 523 signature will not expire. 525 5. The signer creates an ordered list of content identifiers 526 representing the message content and signature metadata to be 527 covered by the signature, and assigns this list as the 528 signature's Covered Content. Each identifier MUST be one of 529 those defined in Section 2. This list MUST NOT be empty, as this 530 would result in creating a signature over the empty string. If 531 the signature's Algorithm name does not start with "rsa", "hmac", 532 or "ecdsa", signers SHOULD include "(created)" and "(request- 533 target)" in the list. If the signature's Algorithm starts with 534 "rsa", "hmac", or "ecdsa", signers SHOULD include "date" and 535 "(request-target)" in the list. Further guidance on what to 536 include in this list and in what order is out of scope for this 537 document. However, the list order is significant and once 538 established for a given signature it MUST be preserved for that 539 signature. 541 For example, given the following HTTP message: 543 GET /foo HTTP/1.1 544 Host: example.org 545 Date: Tue, 07 Jun 2014 20:51:35 GMT 546 X-Example: Example header 547 with some whitespace. 548 X-EmptyHeader: 549 Cache-Control: max-age=60 550 Cache-Control: must-revalidate 552 The following table presents a non-normative example of metadata 553 values that a signer may choose: 555 +--------------+--------------------------------------------------+ 556 | Property | Value | 557 +==============+==================================================+ 558 | Algorithm | "rsa-256" | 559 +--------------+--------------------------------------------------+ 560 | Covered | "(request-target)", "(created)", "host", "date", | 561 | Content | "cache-contol", "x-emptyheader", "x-example" | 562 +--------------+--------------------------------------------------+ 563 | Creation | Equal to the value specified in the Date header | 564 | Time | field. | 565 +--------------+--------------------------------------------------+ 566 | Expiration | Equal to the Creation Time plus five minutes. | 567 | Time | | 568 +--------------+--------------------------------------------------+ 569 | Verification | The public key provided in Appendix A.1.1 and | 570 | Key Material | identified by the "keyId" value "test-key-b". | 571 +--------------+--------------------------------------------------+ 573 Table 3: Non-normative example metadata values 575 3.2.2. Create the Signature Input 577 The Signature Input is a US-ASCII string containing the content that 578 will be signed. To create it, the signer concatenates together 579 entries for each identifier in the signature's Covered Content in the 580 order it occurs in the list, with each entry separated by a newline 581 ""\n"". An identifier's entry is a US-ASCII string consisting of the 582 lowercased identifier followed with a colon "":"", a space "" "", and 583 the identifier's canonicalized value (described below). 585 If Covered Content contains "(created)" and the signature's Creation 586 Time is undefined or the signature's Algorithm name starts with 587 "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. 589 If Covered Content contains "(expires)" and the signature does not 590 have an Expiration Time or the signature's Algorithm name starts with 591 "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. 593 If Covered Content contains an identifier for a header field that is 594 not present or malformed in the message, the implementation MUST 595 produce an error. 597 For the non-normative example Signature metadata in Table 3, the 598 corresponding Signature Input is: 600 (request-target): get /foo 601 (created): 1402170695 602 host: example.org 603 date: Tue, 07 Jun 2014 20:51:35 GMT 604 cache-control: max-age=60, must-revalidate 605 x-emptyheader: 606 x-example: Example header with some whitespace. 608 Figure 1: Non-normative example Signature Input 610 3.2.3. Sign the Signature Input 612 The signer signs the Signature Input using the signing algorithm 613 described by the signature's Algorithm property, and the key material 614 chosen by the signer. The signer then encodes the result of that 615 operation as a base 64-encoded string [RFC4648]. This string is the 616 signature value. 618 For the non-normative example Signature metadata in Section 3.2.1 and 619 Signature Input in Figure 1, the corresponding signature value is: 621 T1l3tWH2cSP31nfuvc3nVaHQ6IAu9YLEXg2pCeEOJETXnlWbgKtBTaXV6LNQWtf4O42V2 622 DZwDZbmVZ8xW3TFW80RrfrY0+fyjD4OLN7/zV6L6d2v7uBpuWZ8QzKuHYFaRNVXgFBXN3 623 VJnsIOUjv20pqZMKO3phLCKX2/zQzJLCBQvF/5UKtnJiMp1ACNhG8LF0Q0FPWfe86YZBB 624 xqrQr5WfjMu0LOO52ZAxi9KTWSlceJ2U361gDb7S5Deub8MaDrjUEpluphQeo8xyvHBoN 625 Xsqeax/WaHyRYOgaW6krxEGVaBQAfA2czYZhEA05Tb38ahq/gwDQ1bagd9rGnCHtAg== 627 Figure 2: Non-normative example signature value 629 3.3. Verifying a Signature 631 In order to verify a signature, a verifier MUST: 633 1. Examine the signature's metadata to confirm that the signature 634 meets the requirements described in this document, as well as any 635 additional requirements defined by the application such as which 636 header fields or other content are required to be covered by the 637 signature. 639 2. Use the received HTTP message and the signature's metadata to 640 recreate the Signature Input, using the process described in 641 Section 3.2.2. 643 3. Use the signature's Algorithm and Verification Key Material with 644 the recreated Signing Input to verify the signature value. 646 A signature with a Creation Time that is in the future or an 647 Expiration Time that is in the past MUST NOT be processed. 649 The verifier MUST ensure that a signature's Algorithm is appropriate 650 for the key material the verifier will use to verify the signature. 651 If the Algorithm is not appropriate for the key material (for 652 example, if it is the wrong size, or in the wrong format), the 653 signature MUST NOT be processed. 655 3.3.1. Enforcing Application Requirements 657 The verification requirements specified in this document are intended 658 as a baseline set of restrictions that are generally applicable to 659 all use cases. Applications using HTTP Message Signatures MAY impose 660 requirements above and beyond those specified by this document, as 661 appropriate for their use case. 663 Some non-normative examples of additional requirements an application 664 might define are: 666 * Requiring a specific set of header fields to be signed (e.g., 667 Authorization, Digest). 669 * Enforcing a maximum signature age. 671 * Prohibiting the use of certain algorithms, or mandating the use of 672 an algorithm. 674 * Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 675 bits). 677 Application-specific requirements are expected and encouraged. When 678 an application defines additional requirements, it MUST enforce them 679 during the signature verification process, and signature verification 680 MUST fail if the signature does not conform to the application's 681 requirements. 683 Applications MUST enforce the requirements defined in this document. 684 Regardless of use case, applications MUST NOT accept signatures that 685 do not conform to these requirements. 687 4. The 'Signature' HTTP Header 689 The "Signature" HTTP header provides a mechanism to attach a 690 signature to the HTTP message from which it was generated. The 691 header field name is "Signature" and its value is a list of 692 parameters and values, formatted according to the "signature" syntax 693 defined below, using the extended Augmented Backus-Naur Form (ABNF) 694 notation used in [HTTP]. 696 signature = #( sig-param ) 698 sig-param = token BWS "=" BWS ( token / quoted-string ) 700 Each "sig-param" is the name of a parameter defined in the 701 Section 5.2 defined in this document. The initial contents of this 702 registry are described in Section 4.1. 704 4.1. Signature Header Parameters 706 The Signature header's parameters contain the signature value itself 707 and the signature metadata properties required to verify the 708 signature. Unless otherwise specified, parameters MUST NOT occur 709 multiple times in one header, whether with the same or different 710 values. The following parameters are defined: 712 "algorithm" 713 RECOMMENDED. The "algorithm" parameter contains the name of the 714 signature's Algorithm, as registered in the HTTP Signature 715 Algorithms Registry defined by this document. Verifiers MUST 716 determine the signature's Algorithm from the "keyId" parameter 717 rather than from "algorithm". If "algorithm" is provided and 718 differs from or is incompatible with the algorithm or key material 719 identified by "keyId" (for example, "algorithm" has a value of 720 "rsa-sha256" but "keyId" identifies an EdDSA key), then 721 implementations MUST produce an error. Implementers should note 722 that previous versions of this specification determined the 723 signature's Algorithm using the "algorithm" parameter only, and 724 thus could be utilized by attackers to expose security 725 vulnerabilities. The default value for this parameter is 726 "hs2019". 728 "created" 729 RECOMMENDED. The "created" parameter contains the signature's 730 Creation Time, expressed as the canonicalized value of the 731 "(created)" content identifier, as defined in Section 2. If not 732 specified, the signature's Creation Time is undefined. This 733 parameter is useful when signers are not capable of controlling 734 the "Date" HTTP Header such as when operating in certain web 735 browser environments. 737 "expires" 738 OPTIONAL. The "expires" parameter contains the signature's 739 Expiration Time, expressed as the canonicalized value of the 740 "(expires)" content identifier, as defined in Section 2. If the 741 signature does not have an Expiration Time, this parameter "MUST" 742 be omitted. If not specified, the signature's Expiration Time is 743 undefined. 745 "headers" 746 OPTIONAL. The "headers" parameter contains the signature's 747 Covered Content, expressed as a string containing a quoted list of 748 the identifiers in the list, in the order they occur in the list, 749 with a space "" "" between each identifier. If specified, 750 identifiers for header fields SHOULD be lowercased and all others 751 MUST be lowercased. The default value for this parameter is 752 "(created)". 754 "keyId" 755 REQUIRED. The "keyId" parameter is a US-ASCII string whose value 756 can be used by a verifier to identify and/or obtain the 757 signature's "Verification Key Material". The format and semantics 758 of this value are out of scope for this document. 760 "signature" 761 REQUIRED. The "signature" parameter contains the signature value, 762 as described in Section 3.2.3. 764 4.2. Example 766 The following is a non-normative example Signature header field 767 representing the signature in Figure 2: 769 Signature: keyId="test-key-b", algorithm="rsa-sha256", 770 created=1402170695, expires=1402170995, 771 headers="(request-target) (created) host date cache-control 772 x-emptyheader x-example", 773 signature="T1l3tWH2cSP31nfuvc3nVaHQ6IAu9YLEXg2pCeEOJETXnlWbgKtBTa 774 XV6LNQWtf4O42V2DZwDZbmVZ8xW3TFW80RrfrY0+fyjD4OLN7/zV6L6d2v7uB 775 puWZ8QzKuHYFaRNVXgFBXN3VJnsIOUjv20pqZMKO3phLCKX2/zQzJLCBQvF/5 776 UKtnJiMp1ACNhG8LF0Q0FPWfe86YZBBxqrQr5WfjMu0LOO52ZAxi9KTWSlceJ 777 2U361gDb7S5Deub8MaDrjUEpluphQeo8xyvHBoNXsqeax/WaHyRYOgaW6krxE 778 GVaBQAfA2czYZhEA05Tb38ahq/gwDQ1bagd9rGnCHtAg==" 780 5. IANA Considerations 782 5.1. HTTP Signature Algorithms Registry 784 This document defines HTTP Signature Algorithms, for which IANA is 785 asked to create and maintain a new registry titled "HTTP Signature 786 Algorithms". Initial values for this registry are given in 787 Section 5.1.2. Future assignments and modifications to existing 788 assignment are to be made through the Expert Review registration 789 policy [BCP 26] and shall follow the template presented in 790 Section 5.1.1. 792 5.1.1. Registration Template 794 Algorithm Name 795 An identifier for the HTTP Signature Algorithm. The name MUST be 796 an ASCII string consisting only of lower-case characters (""a"" - 797 ""z""), digits (""0"" - ""9""), and hyphens (""-""), and SHOULD 798 NOT exceed 20 characters in length. The identifier MUST be unique 799 within the context of the registry. 801 Status 802 A brief text description of the status of the algorithm. The 803 description MUST begin with one of "Active" or "Deprecated", and 804 MAY provide further context or explanation as to the reason for 805 the status. 807 Description 808 A description of the algorithm used to sign the signing string 809 when generating an HTTP Message Signature, or instructions on how 810 to determine that algorithm. When the description specifies an 811 algorithm, it MUST include a reference to the document or 812 documents that define the algorithm. 814 5.1.2. Initial Contents 816 [[ MS: The references in this section are problematic as many of the 817 specifications that they refer to are too implementation specific, 818 rather than just pointing to the proper signature and hashing 819 specifications. A better approach might be just specifying the 820 signature and hashing function specifications, leaving implementers 821 to connect the dots (which are not that hard to connect). ]] 823 "hs2019" 825 Algorithm Name 826 "hs2019" 828 Status 829 active 831 Description 832 Derived from metadata associated with "keyId". Recommend support 833 for: 835 * RSASSA-PSS [RFC8017] using SHA-512 [RFC6234] 837 * HMAC [RFC2104] using SHA-512 [RFC6234] 839 * ECDSA using curve P-256 [DSS] and SHA-512 [RFC6234] 841 * Ed25519ph, Ed25519ctx, and Ed25519 [RFC8032] 843 "rsa-sha1" 844 Algorithm Name 845 "rsa-sha1" 847 Status 848 Deprecated; SHA-1 not secure. 850 Description 851 RSASSA-PKCS1-v1_5 [RFC8017] using SHA-1 [RFC6234] 853 "rsa-sha256" 855 Algorithm Name 856 "rsa-sha256" 858 Status 859 Deprecated; specifying signature algorithm enables attack vector. 861 Description 862 RSASSA-PKCS1-v1_5 [RFC8017] using SHA-256 [RFC6234] 864 "hmac-sha256" 866 Algorithm Name 867 "hmac-sha256" 869 Status 870 Deprecated; specifying signature algorithm enables attack vector. 872 Description 873 HMAC [RFC2104] using SHA-256 [RFC6234] 875 "ecdsa-sha256" 877 Algorithm Name 878 "ecdsa-sha256" 880 Status 881 Deprecated; specifying signature algorithm enables attack vector. 883 Description 884 ECDSA using curve P-256 [DSS] and SHA-256 [RFC6234] 886 5.2. HTTP Signature Parameters Registry 888 This document defines the Signature header field, whose value 889 contains a list of named parameters. IANA is asked to create and 890 maintain a new registry titled "HTTP Signature Parameters" to record 891 and maintain the set of named parameters defined for use within the 892 Signature header field. Initial values for this registry are given 893 in Section 5.2.2. Future assignments and modifications to existing 894 assignment are to be made through the Expert Review registration 895 policy [BCP 26] and shall follow the template presented in 896 Section 5.2.1. 898 5.2.1. Registration Template 900 Name 901 An identifier for the parameter. The name MUST be an ASCII string 902 consisting only of lower-case characters (""a"" - ""z""), digits 903 (""0"" - ""9""), and hyphens (""-""), and SHOULD NOT exceed 20 904 characters in length. The identifier MUST be unique within the 905 context of the registry. 907 Status 908 A value indicating the status of the parameter definition. 909 Allowed values are "Active" and "Deprecated". Active parameter 910 definitions are available for general use. Deprecated parameter 911 definitions may be in use by existing implementations, but SHOULD 912 NOT be used by new implementations. 914 Reference(s) 915 A reference or list of references to the documents that define the 916 purpose, content, and usage of the parameter. The parameter 917 definition MUST define the format of the parameter's value using 918 the extended ABNF notation used in [HTTP], or by referencing one 919 or more standard formats such as base 64 or URI. The parameter 920 definition MUST also specify the normative requirements for when 921 and how the parameter may be used. Value formats MUST NOT allow 922 values that would break the parameter list syntax used by the 923 Signature header. 925 5.2.2. Initial Contents 927 The table below contains the initial contents of the HTTP Signature 928 Parameters Registry. Each row in the table represents a distinct 929 entry in the registry. 931 +-------------+--------+------------------------------+ 932 | Name | Status | Reference(s) | 933 +=============+========+==============================+ 934 | "algorithm" | Active | Section 4.1 of this document | 935 +-------------+--------+------------------------------+ 936 | "created" | Active | Section 4.1 of this document | 937 +-------------+--------+------------------------------+ 938 | "expires" | Active | Section 4.1 of this document | 939 +-------------+--------+------------------------------+ 940 | "headers" | Active | Section 4.1 of this document | 941 +-------------+--------+------------------------------+ 942 | "keyId" | Active | Section 4.1 of this document | 943 +-------------+--------+------------------------------+ 944 | "signature" | Active | Section 4.1 of this document | 945 +-------------+--------+------------------------------+ 947 Table 4: Initial contents of the HTTP Signature 948 Parameters Registry. 950 6. Security Considerations 952 [[ TODO: need to dive deeper on this section; not sure how much of 953 what's referenced below is actually applicable, or if it covers 954 everything we need to worry about. ]] 956 [[ TODO: Should provide some recommendations on how to determine what 957 content needs to be signed for a given use case. ]] 959 There are a number of security considerations to take into account 960 when implementing or utilizing this specification. A thorough 961 security analysis of this protocol, including its strengths and 962 weaknesses, can be found in Security Considerations for HTTP 963 Signatures [WP-HTTP-Sig-Audit]. 965 7. References 967 7.1. Normative References 969 [BCP 26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 970 Writing an IANA Considerations Section in RFCs", BCP 26, 971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 972 . 974 [DSS] NIST, "Digital Signature Standard (DSS)", FIPS 186-4, 975 DOI 10.6028/NIST.FIPS.186-4, July 2013, 976 . 979 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 980 Protocol (HTTP/1.1): Message Syntax and Routing", 981 RFC 7230, DOI 10.17487/RFC7230, June 2014, 982 . 984 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 985 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 986 DOI 10.17487/RFC7540, May 2015, 987 . 989 [POSIX.1] IEEE and The Open Group, "The Open Group Base 990 Specifications Issue 7, 2018 edition", IEEE 991 Std 1003.1-2017, 2018, 992 . 994 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 995 Hashing for Message Authentication", RFC 2104, 996 DOI 10.17487/RFC2104, February 1997, 997 . 999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", BCP 14, RFC 2119, 1001 DOI 10.17487/RFC2119, March 1997, 1002 . 1004 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1005 Resource Identifier (URI): Generic Syntax", STD 66, 1006 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1007 . 1009 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1010 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1011 . 1013 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1014 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1015 . 1017 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1018 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1019 May 2017, . 1021 7.2. Informative References 1023 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1024 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1025 . 1027 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1028 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1029 DOI 10.17487/RFC6234, May 2011, 1030 . 1032 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1033 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1034 . 1036 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1037 DOI 10.17487/RFC7518, May 2015, 1038 . 1040 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1041 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1042 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1043 . 1045 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1046 Signature Algorithm (EdDSA)", RFC 8032, 1047 DOI 10.17487/RFC8032, January 2017, 1048 . 1050 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1051 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1052 . 1054 [WP-HTTP-Sig-Audit] 1055 Sporny, M., "Security Considerations for HTTP Signatures", 1056 June 2013, . 1059 Appendix A. Examples 1061 A.1. Example Keys 1063 This section provides cryptographic keys that are referenced in 1064 example signatures throughout this document. These keys MUST NOT be 1065 used for any purpose other than testing. 1067 A.1.1. "rsa-test" 1069 The following key is a 2048-bit RSA public and private key pair: 1071 -----BEGIN RSA PUBLIC KEY----- 1072 MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw 1073 WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq 1074 MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg 1075 kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P 1076 uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ 1077 PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB 1078 -----END RSA PUBLIC KEY----- 1080 -----BEGIN RSA PRIVATE KEY----- 1081 MIIEqAIBAAKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsP 1082 BRrwWEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsd 1083 JKFqMGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75 1084 jfZgkne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKI 1085 lE0PuKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZ 1086 SFlQPSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQABAoIBAG/JZuSWdoVHbi56 1087 vjgCgkjg3lkO1KrO3nrdm6nrgA9P9qaPjxuKoWaKO1cBQlE1pSWp/cKncYgD5WxE 1088 CpAnRUXG2pG4zdkzCYzAh1i+c34L6oZoHsirK6oNcEnHveydfzJL5934egm6p8DW 1089 +m1RQ70yUt4uRc0YSor+q1LGJvGQHReF0WmJBZHrhz5e63Pq7lE0gIwuBqL8SMaA 1090 yRXtK+JGxZpImTq+NHvEWWCu09SCq0r838ceQI55SvzmTkwqtC+8AT2zFviMZkKR 1091 Qo6SPsrqItxZWRty2izawTF0Bf5S2VAx7O+6t3wBsQ1sLptoSgX3QblELY5asI0J 1092 YFz7LJECgYkAsqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOM 1093 cCNq8SyYbTqgnWlB9ZfcAm/cFpA8tYci9m5vYK8HNxQr+8FS3Qo8N9RJ8d0U5Csw 1094 DzMYfRghAfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1 1095 mwJ5AL0pYF0G7x81prlARURwHo0Yf52kEw1dxpx+JXER7hQRWQki5/NsUEtv+8RT 1096 qn2m6qte5DXLyn83b1qRscSdnCCwKtKWUug5q2ZbwVOCJCtmRwmnP131lWRYfj67 1097 B/xJ1ZA6X3GEf4sNReNAtaucPEelgR2nsN0gKQKBiGoqHWbK1qYvBxX2X3kbPDkv 1098 9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn 1099 f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo 1100 81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa 1101 /2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG 1102 IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m 1103 qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P 1104 WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ 1105 EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0= 1106 -----END RSA PRIVATE KEY----- 1108 A.2. Example "keyId" Values 1110 The table below maps example "keyId" values to associated algorithms 1111 and/or keys. These are example mappings that are valid only within 1112 the context of examples in examples within this and future documents 1113 that reference this section. Unless otherwise specified, within the 1114 context of examples it should be assumed that the signer and verifier 1115 understand these "keyId" mappings. These "keyId" values are not 1116 reserved, and deployments are free to use them, with these 1117 associations or others. 1119 +--------------+---------------------------------+-----------------+ 1120 | "keyId" | Algorithm | Verification | 1121 | | | Key | 1122 +==============+=================================+=================+ 1123 | "test-key-a" | "hs2019", using RSASSA-PSS | The public key | 1124 | | [RFC8017] and SHA-512 [RFC6234] | specified in | 1125 | | | Appendix A.1.1. | 1126 +--------------+---------------------------------+-----------------+ 1127 | "test-key-b" | "rsa-256" | The public key | 1128 | | | specified in | 1129 | | | Appendix A.1.1. | 1130 +--------------+---------------------------------+-----------------+ 1132 Table 5 1134 A.3. Test Cases 1136 This section provides non-normative examples that may be used as test 1137 cases to validate implementation correctness. These examples are 1138 based on the following HTTP message: 1140 POST /foo?param=value&pet=dog HTTP/1.1 1141 Host: example.com 1142 Date: Tue, 07 Jun 2014 20:51:35 GMT 1143 Content-Type: application/json 1144 Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 1145 Content-Length: 18 1147 {"hello": "world"} 1149 A.3.1. Signature Generation 1151 A.3.1.1. "hs2019" signature over minimal recommended content 1153 This presents metadata for a Signature using "hs2019", over minimum 1154 recommended data to sign: 1156 +--------------+-----------------------------------+ 1157 | Property | Value | 1158 +==============+===================================+ 1159 | Algorithm | "hs2019", using RSASSA-PSS | 1160 | | [RFC8017] using SHA-512 [RFC6234] | 1161 +--------------+-----------------------------------+ 1162 | Covered | "(created) (request-target)" | 1163 | Content | | 1164 +--------------+-----------------------------------+ 1165 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1166 | Time | | 1167 +--------------+-----------------------------------+ 1168 | Expiration | Undefined | 1169 | Time | | 1170 +--------------+-----------------------------------+ 1171 | Verification | The public key specified in | 1172 | Key Material | Appendix A.1.1. | 1173 +--------------+-----------------------------------+ 1175 Table 6 1177 The Signature Input is: 1179 (created): 1402170695 1180 (request-target): post /foo?param=value&pet=dog 1182 The signature value is: 1184 e3y37nxAoeuXw2KbaIxE2d9jpE7Z9okgizg6QbD2Z7fUVUvog+ZTKKLRBnhNglVIY6fAa 1185 YlHwx7ZAXXdBVF8gjWBPL6U9zRrB4PFzjoLSxHaqsvS0ZK9FRxpenptgukaVQ1aeva3PE 1186 1aD6zZ93df2lFIFXGDefYCQ+M/SrDGQOFvaVykEkte5mO6zQZ/HpokjMKvilfSMJS+vbv 1187 C1GJItQpjs636Db+7zB2W1BurkGxtQdCLDXuIDg4S8pPSDihkch/dUzL2BpML3PXGKVXw 1188 HOUkVG6Q2ge07IYdzya6N1fIVA9eKI1Y47HT35QliVAxZgE0EZLo8mxq19ReIVvuFg== 1190 A possible Signature header for this signature is: 1192 Signature: keyId="test-key-a", created=1402170695, 1193 headers="(created) (request-target)", 1194 signature="e3y37nxAoeuXw2KbaIxE2d9jpE7Z9okgizg6QbD2Z7fUVUvog+ZTKK 1195 LRBnhNglVIY6fAaYlHwx7ZAXXdBVF8gjWBPL6U9zRrB4PFzjoLSxHaqsvS0ZK 1196 9FRxpenptgukaVQ1aeva3PE1aD6zZ93df2lFIFXGDefYCQ+M/SrDGQOFvaVyk 1197 Ekte5mO6zQZ/HpokjMKvilfSMJS+vbvC1GJItQpjs636Db+7zB2W1BurkGxtQ 1198 dCLDXuIDg4S8pPSDihkch/dUzL2BpML3PXGKVXwHOUkVG6Q2ge07IYdzya6N1 1199 fIVA9eKI1Y47HT35QliVAxZgE0EZLo8mxq19ReIVvuFg==" 1201 A.3.1.2. "hs2019" signature covering all header fields 1203 This presents metadata for a Signature using "hs2019" that covers all 1204 header fields in the request: 1206 +--------------+--------------------------------------------------+ 1207 | Property | Value | 1208 +==============+==================================================+ 1209 | Algorithm | "hs2019", using RSASSA-PSS [RFC8017] using | 1210 | | SHA-512 [RFC6234] | 1211 +--------------+--------------------------------------------------+ 1212 | Covered | "(created)", "(request-target)", "host", "date", | 1213 | Content | "content-type", "digest", "content-length" | 1214 +--------------+--------------------------------------------------+ 1215 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1216 | Time | | 1217 +--------------+--------------------------------------------------+ 1218 | Expiration | Undefined | 1219 | Time | | 1220 +--------------+--------------------------------------------------+ 1221 | Verification | The public key specified in Appendix A.1.1. | 1222 | Key Material | | 1223 +--------------+--------------------------------------------------+ 1225 Table 7 1227 The Signature Input is: 1229 (created): 1402170695 1230 (request-target): post /foo?param=value&pet=dog 1231 host: example.com 1232 date: Tue, 07 Jun 2014 20:51:35 GMT 1233 content-type: application/json 1234 digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 1235 content-length: 18 1237 The signature value is: 1239 KXUj1H3ZOhv3Nk4xlRLTn4bOMlMOmFiud3VXrMa9MaLCxnVmrqOX5BulRvB65YW/wQp0o 1240 T/nNQpXgOYeY8ovmHlpkRyz5buNDqoOpRsCpLGxsIJ9cX8XVsM9jy+Q1+RIlD9wfWoPHh 1241 qhoXt35ZkasuIDPF/AETuObs9QydlsqONwbK+TdQguDK/8Va1Pocl6wK1uLwqcXlxhPEb 1242 55EmdYB9pddDyHTADING7K4qMwof2mC3t8Pb0yoLZoZX5a4Or4FrCCKK/9BHAhq/RsVk0 1243 dTENMbTB4i7cHvKQu+o9xuYWuxyvBa0Z6NdOb0di70cdrSDEsL5Gz7LBY5J2N9KdGg== 1245 A possible Signature header for this signature is: 1247 Signature: keyId="test-key-a", algorithm="hs2019", 1248 created=1402170695, 1249 headers="(request-target) (created) host date content-type digest 1250 content-length", 1251 signature="KXUj1H3ZOhv3Nk4xlRLTn4bOMlMOmFiud3VXrMa9MaLCxnVmrqOX5B 1252 ulRvB65YW/wQp0oT/nNQpXgOYeY8ovmHlpkRyz5buNDqoOpRsCpLGxsIJ9cX8 1253 XVsM9jy+Q1+RIlD9wfWoPHhqhoXt35ZkasuIDPF/AETuObs9QydlsqONwbK+T 1254 dQguDK/8Va1Pocl6wK1uLwqcXlxhPEb55EmdYB9pddDyHTADING7K4qMwof2m 1255 C3t8Pb0yoLZoZX5a4Or4FrCCKK/9BHAhq/RsVk0dTENMbTB4i7cHvKQu+o9xu 1256 YWuxyvBa0Z6NdOb0di70cdrSDEsL5Gz7LBY5J2N9KdGg==" 1258 A.3.2. Signature Verification 1259 A.3.2.1. Minimal Required Signature Header 1261 This presents a Signature header containing only the minimal required 1262 parameters: 1264 Signature: keyId="test-key-a", (created): 1402170695, 1265 signature="V3SijFpJOvDUT8t1/EnYli/4TbF2AGqwBGiGUGrgClCkiOAIlOxxY7 1266 2Mr13DccFkYzg3gX1jIOpKXzH70C5bru4b71SBG+ShiJLu34gHCG33iw44NLG 1267 UvT5+F+LCKbbHberyk8eyYsZ+TLwtZAYKafxfNOWQXF4o3QaWslDMm8Tcgrd8 1268 onM45ayFyR4nXRlcGad4PISYGz8PmO4Y+K8RYOyDkgsmRxKtftFQUYG41anyE 1269 lccNLfEfLBKsyV6kxr36U1Q7FdUopLv8kqluQySrWD6kesvFxNvbEOi+1uZqT 1270 uFlK8ZldITQiqtNYaabRjQFZio63gma2y+UAaTGLdM9A==" 1272 The corresponding signature metadata derived from this header field 1273 is: 1275 +--------------+-----------------------------------+ 1276 | Property | Value | 1277 +==============+===================================+ 1278 | Algorithm | "hs2019", using RSASSA-PSS | 1279 | | [RFC8017] using SHA-256 [RFC6234] | 1280 +--------------+-----------------------------------+ 1281 | Covered | "(created)" | 1282 | Content | | 1283 +--------------+-----------------------------------+ 1284 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1285 | Time | | 1286 +--------------+-----------------------------------+ 1287 | Expiration | Undefined | 1288 | Time | | 1289 +--------------+-----------------------------------+ 1290 | Verification | The public key specified in | 1291 | Key Material | Appendix A.1.1. | 1292 +--------------+-----------------------------------+ 1294 Table 8 1296 The corresponding Signature Input is: 1298 (created): 1402170695 1300 A.3.2.2. Minimal Recommended Signature Header 1302 This presents a Signature header containing only the minimal required 1303 and recommended parameters: 1305 Signature: algorithm="hs2019", keyId="test-key-a", 1306 (created): 1402170695, 1307 signature="V3SijFpJOvDUT8t1/EnYli/4TbF2AGqwBGiGUGrgClCkiOAIlOxxY7 1308 2Mr13DccFkYzg3gX1jIOpKXzH70C5bru4b71SBG+ShiJLu34gHCG33iw44NLG 1309 UvT5+F+LCKbbHberyk8eyYsZ+TLwtZAYKafxfNOWQXF4o3QaWslDMm8Tcgrd8 1310 onM45ayFyR4nXRlcGad4PISYGz8PmO4Y+K8RYOyDkgsmRxKtftFQUYG41anyE 1311 lccNLfEfLBKsyV6kxr36U1Q7FdUopLv8kqluQySrWD6kesvFxNvbEOi+1uZqT 1312 uFlK8ZldITQiqtNYaabRjQFZio63gma2y+UAaTGLdM9A==" 1314 The corresponding signature metadata derived from this header field 1315 is: 1317 +--------------+-----------------------------------+ 1318 | Property | Value | 1319 +==============+===================================+ 1320 | Algorithm | "hs2019", using RSASSA-PSS | 1321 | | [RFC8017] using SHA-512 [RFC6234] | 1322 +--------------+-----------------------------------+ 1323 | Covered | "(created)" | 1324 | Content | | 1325 +--------------+-----------------------------------+ 1326 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1327 | Time | | 1328 +--------------+-----------------------------------+ 1329 | Expiration | Undefined | 1330 | Time | | 1331 +--------------+-----------------------------------+ 1332 | Verification | The public key specified in | 1333 | Key Material | Appendix A.1.1. | 1334 +--------------+-----------------------------------+ 1336 Table 9 1338 The corresponding Signature Input is: 1340 (created): 1402170695 1342 A.3.2.3. Minimal Signature Header using "rsa-256" 1344 This presents a minimal Signature header for a signature using the 1345 "rsa-256" algorithm: 1347 Signature: algorithm="rsa-256", keyId="test-key-b", 1348 headers="date", 1349 signature="HtXycCl97RBVkZi66ADKnC9c5eSSlb57GnQ4KFqNZplOpNfxqk62Jz 1350 Z484jXgLvoOTRaKfR4hwyxlcyb+BWkVasApQovBSdit9Ml/YmN2IvJDPncrlh 1351 PDVDv36Z9/DiSO+RNHD7iLXugdXo1+MGRimW1RmYdenl/ITeb7rjfLZ4b9VNn 1352 LFtVWwrjhAiwIqeLjodVImzVc5srrk19HMZNuUejK6I3/MyN3+3U8tIRW4LWz 1353 x6ZgGZUaEEP0aBlBkt7Fj0Tt5/P5HNW/Sa/m8smxbOHnwzAJDa10PyjzdIbyw 1354 lnWIIWtZKPPsoVoKVopUWEU3TNhpWmaVhFrUL/O6SN3w==" 1356 The corresponding signature metadata derived from this header field 1357 is: 1359 +---------------------------+--------------------------+ 1360 | Property | Value | 1361 +===========================+==========================+ 1362 | Algorithm | "rsa-256" | 1363 +---------------------------+--------------------------+ 1364 | Covered Content | "date" | 1365 +---------------------------+--------------------------+ 1366 | Creation Time | Undefined | 1367 +---------------------------+--------------------------+ 1368 | Expiration Time | Undefined | 1369 +---------------------------+--------------------------+ 1370 | Verification Key Material | The public key specified | 1371 | | in Appendix A.1.1. | 1372 +---------------------------+--------------------------+ 1374 Table 10 1376 The corresponding Signature Input is: 1378 date: Tue, 07 Jun 2014 20:51:35 GMT 1380 Appendix B. Topics for Working Group Discussion 1382 This section is to be removed before publishing as an RFC. 1384 The goal of this draft document is to provide a starting point at 1385 feature parity and compatible with the cavage-12 draft. The draft 1386 has known issues that will need to be addressed during development, 1387 and in the spirit of keeping compatibility, these issues have been 1388 enumerated but not addressed in this version. The editor recommends 1389 the working group discuss the issues and features described in this 1390 section after adoption of the document by the working group. Topics 1391 are not listed in any particular order. 1393 B.1. Issues 1394 B.1.1. Confusing guidance on algorithm and key identification 1396 The current draft encourages determining the Algorithm metadata 1397 property from the "keyId" field, both in the guidance for the use of 1398 "algorithm" and "keyId", and the definition for the "hs2019" 1399 algorithm and deprecation of the other algorithms in the registry. 1400 The current state arose from concern that a malicious party could 1401 change the value of the "algorithm" parameter, potentially tricking 1402 the verifier into accepting a signature that would not have been 1403 verified under the actual parameter. 1405 Punting algorithm identification into "keyId" hurts interoperability, 1406 since we aren't defining the syntax or semantics of "keyId". It 1407 actually goes against that claim, as we are dictating that the 1408 signing algorithm must be specified by "keyId" or derivable from it. 1409 It also renders the algorithm registry essentially useless. Instead 1410 of this approach, we can protect against manipulation of the 1411 Signature header field by adding support for (and possibly mandating) 1412 including Signature metadata within the Signature Input. 1414 B.1.2. Lack of definition of "keyId" hurts interoperability 1416 The current text leaves the format and semantics of "keyId" 1417 completely up to the implementation. This is primarily due to the 1418 fact that most implementers of Cavage have extensive investment in 1419 key distribution and management, and just need to plug an identifier 1420 into the header. We should support those cases, but we also need to 1421 provide guidance for the developer that doesn't have that and just 1422 wants to know how to identify a key. It may be enough to punt this 1423 to profiling specs, but this needs to be explored more. 1425 B.1.3. Algorithm Registry duplicates work of JWA 1427 JSON Web Algorithms (JWA) [RFC7518] already defines an IANA registry 1428 for cryptographic algorithms. This wasn't used by Cavage out of 1429 concerns about complexity of JOSE, and issues with JWE and JWS being 1430 too flexible, leading to insecure combinations of options. Using 1431 JWA's definitions does not need to mean we're using JOSE, however. 1432 We should look at if/how we can leverage JWA's work without 1433 introducing too many sharp edges for implementers. 1435 In any use of JWS algorithms, this spec would define a way to create 1436 the JWS Signing Input string to be applied to the algorithm. It 1437 should be noted that this is incompatible with JWS itself, which 1438 requires the inclusion of a structured header in the signature input. 1440 A possible approach is to incorporate all elements of the JWA 1441 signature algorithm registry into this spec using a prefix or other 1442 marker, such as "jws-RS256" for the RSA 256 JSON Web Signature 1443 algorithm. 1445 B.1.4. Algorithm Registry should not be initialized with deprecated 1446 entries 1448 The initial entries in this document reflect those in Cavage. The 1449 ones that are marked deprecated were done so because of the issue 1450 explained in Appendix B.1.1, with the possible exception of "rsa- 1451 sha1". We should probably just remove that one. 1453 B.1.5. No percent-encoding normalization of path/query 1455 See: issue #26 (https://github.com/w3c-dvcg/http-signatures/ 1456 issues/26) 1458 The canonicalization rules for "(request-target)" do not perform 1459 handle minor, semantically meaningless differences in percent- 1460 encoding, such that verification could fail if an intermediary 1461 normalizes the effective request URI prior to forwarding the message. 1463 At a minimum, they should be case and percent-encoding normalized as 1464 described in sections 6.2.2.1 and 6.2.2.2 of [RFC3986]. 1466 B.1.6. Misleading name for "headers" parameter 1468 The Covered Content list contains identifiers for more than just 1469 headers, so the "header" parameter name is no longer appropriate. 1470 Some alternatives: "content", "signed-content", "covered-content". 1472 B.1.7. Changes to whitespace in header field values break verification 1474 Some header field values contain RWS, OWS, and/or BWS. Since the 1475 header field value canonicalization rules do not address whitespace, 1476 changes to it (e.g., removing OWS or BWS or replacing strings of RWS 1477 with a single space) can cause verification to fail. 1479 B.1.8. Multiple Set-Cookie headers are not well supported 1481 The Set-Cookie header can occur multiple times but does not adhere to 1482 the list syntax, and thus is not well supported by the header field 1483 value concatenation rules. 1485 B.1.9. Covered Content list is not signed 1487 The Covered Content list should be part of the Signature Input, to 1488 protect against malicious changes. 1490 B.1.10. Algorithm is not signed 1492 The Algorithm should be part of the Signature Input, to protect 1493 against malicious changes. 1495 B.1.11. Verification key identifier is not signed 1497 The Verification key identifier (e.g., the value used for the "keyId" 1498 parameter) should be part of the Signature Input, to protect against 1499 malicious changes. 1501 B.1.12. Max values, precision for Integer String and Decimal String not 1502 defined 1504 The definitions for Integer String and Decimal String do not specify 1505 a maximum value. The definition for Decimal String (used to provide 1506 sub-second precision for Expiration Time) does not define minimum or 1507 maximum precision requirements. It should set a sane requirement 1508 here (e.g., MUST support up to 3 decimal places and no more). 1510 B.1.13. "keyId" parameter value could break list syntax 1512 The "keyId" parameter value needs to be constrained so as to not 1513 break list syntax (e.g., by containing a comma). 1515 B.1.14. Creation Time and Expiration Time do not allow for clock skew 1517 The processing instructions for Creation Time and Expiration Time 1518 imply that verifiers are not permitted to account for clock skew 1519 during signature verification. 1521 B.1.15. Should require lowercased header field names as identifiers 1523 The current text allows mixed-case header field names when they are 1524 being used as content identifiers. This is unnecessary, as header 1525 field names are case-insensitive, and creates opportunity for 1526 incompatibility. Instead, content identifiers should always be 1527 lowercase. 1529 B.1.16. Reconcile Date header and Creation Time 1531 The draft is missing guidance on if/how the Date header relates to 1532 signature Creation Time. There are cases where they may be 1533 different, such as if a signature was pre-created. Should Creation 1534 Time default to the value in the Date header if the "created" 1535 parameter is not specified? 1537 B.1.17. Remove algorithm-specific rules for content identifiers 1539 The rules that restrict when the signer can or must include certain 1540 identifiers appear to be related to the pseudo-revving of the Cavage 1541 draft that happened when the "hs2019" algorithm was introduced. We 1542 should drop these rules, as it can be expected that anyone 1543 implementing this draft will support all content identifiers. 1545 B.1.18. Add guidance for signing compressed headers 1547 The draft should provide guidance on how to sign headers when HTTP/2 1548 header compression [RFC7541] is used. This guidance might be as 1549 simple as "sign the uncompressed header field value." 1551 B.1.19. Transformations to Via header field value break verification 1553 Intermediaries are permitted to strip comments from the Via header 1554 field value, and consolidate related sequences of entries. The 1555 canonicalization rules do not account for these changes, and thus 1556 they cause signature verification to fail if the Via header is 1557 signed. At the very least, guidance on signing or not signing Via 1558 headers needs to be included. 1560 B.1.20. Case changes to case-insensitive header field values break 1561 verification 1563 Some header field values are case-insensitive, in whole or in part. 1564 The canonicalization rules do not account for this, thus a case 1565 change to a covered header field value causes verification to fail. 1567 B.1.21. Need more examples for Signature header 1569 Add more examples showing different cases e.g, where "created" or 1570 "expires" are not present. 1572 B.1.22. Expiration not needed 1574 In many cases, putting the expiration of the signature into the hands 1575 of the signer opens up more options for failures than necessary. 1576 Instead of the "expires", any verifier can use the "created" field 1577 and an internal lifetime or offset to calculate expiration. We 1578 should consider dropping the "expires" field. 1580 B.2. Features 1581 B.2.1. Define more content identifiers 1583 It should be possible to independently include the following content 1584 and metadata properties in Covered Content: 1586 * The signature's Algorithm 1588 * The signature's Covered Content 1590 * The value used for the "keyId" parameter 1592 * Request method 1594 * Individual components of the effective request URI: scheme, 1595 authority, path, query 1597 * Status code 1599 * Request body (currently supported via Digest header) 1601 B.2.2. Multiple signature support 1603 [[ Editor's note: I believe this use case is theoretical. Please let 1604 me know if this is a use case you have. ]] 1606 There may be scenarios where attaching multiple signatures to a 1607 single message is useful: 1609 * A gateway attaches a signature over headers it adds (e.g., 1610 Forwarded) to messages already signed by the user agent. 1612 * A signer attaches two signatures signed by different keys, to be 1613 verified by different entities. 1615 This could be addressed by changing the Signature header syntax to 1616 accept a list of parameter sets for a single signature, e.g., by 1617 separating parameters with "";"" instead of "","". It may also be 1618 necessary to include a signature identifier parameter. 1620 B.2.3. Support for incremental signing of header field value list items 1622 [[ Editor's note: I believe this use case is theoretical. Please let 1623 me know if this is a use case you have. ]] 1625 Currently, signing a header field value is all-or-nothing: either the 1626 entire value is signed, or none of it is. For header fields that use 1627 list syntax, it would be useful to be able to specify which items in 1628 the list are signed. 1630 A simple approach that allowed the signer to indicate the list size 1631 at signing time would allow a signer to sign header fields that are 1632 may be appended to by intermediaries as the message makes its way to 1633 the recipient. Specifying list size in terms of number of items 1634 could introduce risks of list syntax is not strictly adhered to 1635 (e.g., a malicious party crafts a value that gets parsed by the 1636 application as 5 items, but by the verifier as 4). Specifying list 1637 size in number of octets might address this, but more exploration is 1638 required. 1640 B.2.4. Support expected authority changes 1642 In some cases, the authority of the effective request URI may be 1643 expected to change, for example from "public-service- 1644 name.example.com" to "service-host-1.public-service- 1645 name.example.com". This is commonly the case for services that are 1646 hosted behind a load-balancing gateway, where the client sends 1647 requests to a publicly known domain name for the service, and these 1648 requests are transformed by the gateway into requests to specific 1649 hosts in the service fleet. 1651 One possible way to handle this would be to special-case the Host 1652 header field to allow verifier to substitute a known expected value, 1653 or a value provided in another header field (e.g., Via) when 1654 generating the Signature Input, provided that the verifier also 1655 recognizes the real value in the Host header. Alternatively, this 1656 logic could apply to an "(audience)" content identifier. 1658 B.2.5. Support for signing specific cookies 1660 A signer may only wish to sign one or a few cookies, for example if 1661 the website requires its authentication state cookie to be signed, 1662 but also sets other cookies (e.g., for analytics, ad tracking, etc.) 1664 Acknowledgements 1666 This specification is based on the draft-cavage-http-signatures 1667 draft. The editor would like to thank the authors of that draft, 1668 Mark Cavage and Manu Sporny, for their work on that draft and their 1669 continuing contributions. 1671 The editor would also like to thank the following individuals for 1672 feedback on and implementations of the draft-cavage-http-signatures 1673 draft (in alphabetical order): Mark Adamcin, Mark Allen, Paul 1674 Annesley, Karl Boehlmark, Stephane Bortzmeyer, Sarven Capadisli, Liam 1675 Dennehy, ductm54, Stephen Farrell, Phillip Hallam-Baker, Eric Holmes, 1676 Andrey Kislyuk, Adam Knight, Dave Lehn, Dave Longley, James H. 1677 Manger, Ilari Liusvaara, Mark Nottingham, Yoav Nir, Adrian Palmer, 1678 Lucas Pardue, Roberto Polli, Julian Reschke, Michael Richardson, 1679 Wojciech Rygielski, Adam Scarr, Cory J. Slep, Dirk Stein, Henry 1680 Story, Lukasz Szewc, Chris Webber, and Jeffrey Yasskin 1682 Document History 1684 This section is to be removed before publishing as an RFC. 1686 * *draft-richanna-http-message-signatures* 1688 - *-00* 1690 o Converted to xml2rfc v3 and reformatted to comply with RFC 1691 style guides. 1693 o Removed "Signature" auth-scheme definition and related 1694 content. 1696 o Removed conflicting normative requirements for use of 1697 "algorithm" parameter. Now MUST NOT be relied upon. 1699 o Removed Extensions appendix. 1701 o Rewrote abstract and introduction to explain context and 1702 need, and challenges inherent in signing HTTP messages. 1704 o Rewrote and heavily expanded algorithm definition, retaining 1705 normative requirements. 1707 o Added definitions for key terms, referenced RFC 7230 for 1708 HTTP terms. 1710 o Added examples for canonicalization and signature generation 1711 steps. 1713 o Rewrote Signature header definition, retaining normative 1714 requirements. 1716 o Added default values for "algorithm" and "expires" 1717 parameters. 1719 o Rewrote HTTP Signature Algorithms registry definition. 1720 Added change control policy and registry template. Removed 1721 suggested URI. 1723 o Added IANA HTTP Signature Parameter registry. 1725 o Added additional normative and informative references. 1727 o Added Topics for Working Group Discussion section, to be 1728 removed prior to publication as an RFC. 1730 Authors' Addresses 1732 Annabelle Backman (editor) 1733 Amazon 1734 P.O. Box 81226 1735 Seattle, WA 98108-1226 1736 United States of America 1738 Email: richanna@amazon.com 1739 URI: https://www.amazon.com/ 1741 Justin Richer 1742 Bespoke Engineering 1744 Email: ietf@justin.richer.org 1745 URI: https://bspk.io/ 1747 Manu Sporny 1748 Digital Bazaar 1749 203 Roanoke Street W. 1750 Blacksburg, VA 24060 1751 United States of America 1753 Phone: +1 540 961 4469 1754 Email: msporny@digitalbazaar.com 1755 URI: https://manu.sporny.org/