idnits 2.17.1 draft-ietf-httpbis-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 (10 April 2020) is 1471 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: 12 October 2020 Bespoke Engineering 6 M. Sporny 7 Digital Bazaar 8 10 April 2020 10 Signing HTTP Messages 11 draft-ietf-httpbis-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 12 October 2020. 59 Copyright Notice 61 Copyright (c) 2020 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 | 427 | Host: www.example.com | /?param=value" | 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. 532 If the signature's Algorithm name does not start with "rsa", 533 "hmac", or "ecdsa", signers SHOULD include "(created)" and 534 "(request-target)" in the list. 536 If the signature's Algorithm starts with "rsa", "hmac", or 537 "ecdsa", signers SHOULD include "date" and "(request-target)" in 538 the list. 540 Further guidance on what to include in this list and in what 541 order is out of scope for this document. However, the list order 542 is significant and once established for a given signature it MUST 543 be preserved for that signature. 545 For example, given the following HTTP message: 547 GET /foo HTTP/1.1 548 Host: example.org 549 Date: Tue, 07 Jun 2014 20:51:35 GMT 550 X-Example: Example header 551 with some whitespace. 552 X-EmptyHeader: 553 Cache-Control: max-age=60 554 Cache-Control: must-revalidate 556 The following table presents a non-normative example of metadata 557 values that a signer may choose: 559 +--------------+--------------------------------------------------+ 560 | Property | Value | 561 +==============+==================================================+ 562 | Algorithm | "rsa-256" | 563 +--------------+--------------------------------------------------+ 564 | Covered | "(request-target)", "(created)", "host", "date", | 565 | Content | "cache-contol", "x-emptyheader", "x-example" | 566 +--------------+--------------------------------------------------+ 567 | Creation | Equal to the value specified in the Date header | 568 | Time | field. | 569 +--------------+--------------------------------------------------+ 570 | Expiration | Equal to the Creation Time plus five minutes. | 571 | Time | | 572 +--------------+--------------------------------------------------+ 573 | Verification | The public key provided in Appendix A.1.1 and | 574 | Key Material | identified by the "keyId" value "test-key-b". | 575 +--------------+--------------------------------------------------+ 577 Table 3: Non-normative example metadata values 579 3.2.2. Create the Signature Input 581 The Signature Input is a US-ASCII string containing the content that 582 will be signed. To create it, the signer concatenates together 583 entries for each identifier in the signature's Covered Content in the 584 order it occurs in the list, with each entry separated by a newline 585 ""\n"". An identifier's entry is a US-ASCII string consisting of the 586 lowercased identifier followed with a colon "":"", a space "" "", and 587 the identifier's canonicalized value (described below). 589 If Covered Content contains "(created)" and the signature's Creation 590 Time is undefined or the signature's Algorithm name starts with 591 "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. 593 If Covered Content contains "(expires)" and the signature does not 594 have an Expiration Time or the signature's Algorithm name starts with 595 "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. 597 If Covered Content contains an identifier for a header field that is 598 not present or malformed in the message, the implementation MUST 599 produce an error. 601 For the non-normative example Signature metadata in Table 3, the 602 corresponding Signature Input is: 604 (request-target): get /foo 605 (created): 1402170695 606 host: example.org 607 date: Tue, 07 Jun 2014 20:51:35 GMT 608 cache-control: max-age=60, must-revalidate 609 x-emptyheader: 610 x-example: Example header with some whitespace. 612 Figure 1: Non-normative example Signature Input 614 3.2.3. Sign the Signature Input 616 The signer signs the Signature Input using the signing algorithm 617 described by the signature's Algorithm property, and the key material 618 chosen by the signer. The signer then encodes the result of that 619 operation as a base 64-encoded string [RFC4648]. This string is the 620 signature value. 622 For the non-normative example Signature metadata in Section 3.2.1 and 623 Signature Input in Figure 1, the corresponding signature value is: 625 T1l3tWH2cSP31nfuvc3nVaHQ6IAu9YLEXg2pCeEOJETXnlWbgKtBTaXV6LNQWtf4O42V2 626 DZwDZbmVZ8xW3TFW80RrfrY0+fyjD4OLN7/zV6L6d2v7uBpuWZ8QzKuHYFaRNVXgFBXN3 627 VJnsIOUjv20pqZMKO3phLCKX2/zQzJLCBQvF/5UKtnJiMp1ACNhG8LF0Q0FPWfe86YZBB 628 xqrQr5WfjMu0LOO52ZAxi9KTWSlceJ2U361gDb7S5Deub8MaDrjUEpluphQeo8xyvHBoN 629 Xsqeax/WaHyRYOgaW6krxEGVaBQAfA2czYZhEA05Tb38ahq/gwDQ1bagd9rGnCHtAg== 631 Figure 2: Non-normative example signature value 633 3.3. Verifying a Signature 635 In order to verify a signature, a verifier MUST: 637 1. Examine the signature's metadata to confirm that the signature 638 meets the requirements described in this document, as well as any 639 additional requirements defined by the application such as which 640 header fields or other content are required to be covered by the 641 signature. 643 2. Use the received HTTP message and the signature's metadata to 644 recreate the Signature Input, using the process described in 645 Section 3.2.2. 647 3. Use the signature's Algorithm and Verification Key Material with 648 the recreated Signing Input to verify the signature value. 650 A signature with a Creation Time that is in the future or an 651 Expiration Time that is in the past MUST NOT be processed. 653 The verifier MUST ensure that a signature's Algorithm is appropriate 654 for the key material the verifier will use to verify the signature. 655 If the Algorithm is not appropriate for the key material (for 656 example, if it is the wrong size, or in the wrong format), the 657 signature MUST NOT be processed. 659 3.3.1. Enforcing Application Requirements 661 The verification requirements specified in this document are intended 662 as a baseline set of restrictions that are generally applicable to 663 all use cases. Applications using HTTP Message Signatures MAY impose 664 requirements above and beyond those specified by this document, as 665 appropriate for their use case. 667 Some non-normative examples of additional requirements an application 668 might define are: 670 * Requiring a specific set of header fields to be signed (e.g., 671 Authorization, Digest). 673 * Enforcing a maximum signature age. 675 * Prohibiting the use of certain algorithms, or mandating the use of 676 an algorithm. 678 * Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 679 bits). 681 Application-specific requirements are expected and encouraged. When 682 an application defines additional requirements, it MUST enforce them 683 during the signature verification process, and signature verification 684 MUST fail if the signature does not conform to the application's 685 requirements. 687 Applications MUST enforce the requirements defined in this document. 688 Regardless of use case, applications MUST NOT accept signatures that 689 do not conform to these requirements. 691 4. The 'Signature' HTTP Header 693 The "Signature" HTTP header provides a mechanism to attach a 694 signature to the HTTP message from which it was generated. The 695 header field name is "Signature" and its value is a list of 696 parameters and values, formatted according to the "signature" syntax 697 defined below, using the extended Augmented Backus-Naur Form (ABNF) 698 notation used in [HTTP]. 700 signature = #( sig-param ) 702 sig-param = token BWS "=" BWS ( token / quoted-string ) 704 Each "sig-param" is the name of a parameter defined in the 705 Section 5.2 defined in this document. The initial contents of this 706 registry are described in Section 4.1. 708 4.1. Signature Header Parameters 710 The Signature header's parameters contain the signature value itself 711 and the signature metadata properties required to verify the 712 signature. Unless otherwise specified, parameters MUST NOT occur 713 multiple times in one header, whether with the same or different 714 values. The following parameters are defined: 716 "algorithm" 717 RECOMMENDED. The "algorithm" parameter contains the name of the 718 signature's Algorithm, as registered in the HTTP Signature 719 Algorithms Registry defined by this document. Verifiers MUST 720 determine the signature's Algorithm from the "keyId" parameter 721 rather than from "algorithm". If "algorithm" is provided and 722 differs from or is incompatible with the algorithm or key material 723 identified by "keyId" (for example, "algorithm" has a value of 724 "rsa-sha256" but "keyId" identifies an EdDSA key), then 725 implementations MUST produce an error. Implementers should note 726 that previous versions of this specification determined the 727 signature's Algorithm using the "algorithm" parameter only, and 728 thus could be utilized by attackers to expose security 729 vulnerabilities. The default value for this parameter is 730 "hs2019". 732 "created" 733 RECOMMENDED. The "created" parameter contains the signature's 734 Creation Time, expressed as the canonicalized value of the 735 "(created)" content identifier, as defined in Section 2. If not 736 specified, the signature's Creation Time is undefined. This 737 parameter is useful when signers are not capable of controlling 738 the "Date" HTTP Header such as when operating in certain web 739 browser environments. 741 "expires" 742 OPTIONAL. The "expires" parameter contains the signature's 743 Expiration Time, expressed as the canonicalized value of the 744 "(expires)" content identifier, as defined in Section 2. If the 745 signature does not have an Expiration Time, this parameter "MUST" 746 be omitted. If not specified, the signature's Expiration Time is 747 undefined. 749 "headers" 750 OPTIONAL. The "headers" parameter contains the signature's 751 Covered Content, expressed as a string containing a quoted list of 752 the identifiers in the list, in the order they occur in the list, 753 with a space "" "" between each identifier. If specified, 754 identifiers for header fields SHOULD be lowercased and all others 755 MUST be lowercased. The default value for this parameter is 756 "(created)". 758 "keyId" 759 REQUIRED. The "keyId" parameter is a US-ASCII string whose value 760 can be used by a verifier to identify and/or obtain the 761 signature's "Verification Key Material". The format and semantics 762 of this value are out of scope for this document. 764 "signature" 765 REQUIRED. The "signature" parameter contains the signature value, 766 as described in Section 3.2.3. 768 4.2. Example 770 The following is a non-normative example Signature header field 771 representing the signature in Figure 2: 773 Signature: keyId="test-key-b", algorithm="rsa-sha256", 774 created=1402170695, expires=1402170995, 775 headers="(request-target) (created) host date cache-control 776 x-emptyheader x-example", 777 signature="T1l3tWH2cSP31nfuvc3nVaHQ6IAu9YLEXg2pCeEOJETXnlWbgKtBTa 778 XV6LNQWtf4O42V2DZwDZbmVZ8xW3TFW80RrfrY0+fyjD4OLN7/zV6L6d2v7uB 779 puWZ8QzKuHYFaRNVXgFBXN3VJnsIOUjv20pqZMKO3phLCKX2/zQzJLCBQvF/5 780 UKtnJiMp1ACNhG8LF0Q0FPWfe86YZBBxqrQr5WfjMu0LOO52ZAxi9KTWSlceJ 781 2U361gDb7S5Deub8MaDrjUEpluphQeo8xyvHBoNXsqeax/WaHyRYOgaW6krxE 782 GVaBQAfA2czYZhEA05Tb38ahq/gwDQ1bagd9rGnCHtAg==" 784 5. IANA Considerations 786 5.1. HTTP Signature Algorithms Registry 788 This document defines HTTP Signature Algorithms, for which IANA is 789 asked to create and maintain a new registry titled "HTTP Signature 790 Algorithms". Initial values for this registry are given in 791 Section 5.1.2. Future assignments and modifications to existing 792 assignment are to be made through the Expert Review registration 793 policy [BCP 26] and shall follow the template presented in 794 Section 5.1.1. 796 5.1.1. Registration Template 798 Algorithm Name 799 An identifier for the HTTP Signature Algorithm. The name MUST be 800 an ASCII string consisting only of lower-case characters (""a"" - 801 ""z""), digits (""0"" - ""9""), and hyphens (""-""), and SHOULD 802 NOT exceed 20 characters in length. The identifier MUST be unique 803 within the context of the registry. 805 Status 806 A brief text description of the status of the algorithm. The 807 description MUST begin with one of "Active" or "Deprecated", and 808 MAY provide further context or explanation as to the reason for 809 the status. 811 Description 812 A description of the algorithm used to sign the signing string 813 when generating an HTTP Message Signature, or instructions on how 814 to determine that algorithm. When the description specifies an 815 algorithm, it MUST include a reference to the document or 816 documents that define the algorithm. 818 5.1.2. Initial Contents 820 [[ MS: The references in this section are problematic as many of the 821 specifications that they refer to are too implementation specific, 822 rather than just pointing to the proper signature and hashing 823 specifications. A better approach might be just specifying the 824 signature and hashing function specifications, leaving implementers 825 to connect the dots (which are not that hard to connect). ]] 827 "hs2019" 829 Algorithm Name 830 "hs2019" 832 Status 833 active 835 Description 836 Derived from metadata associated with "keyId". Recommend support 837 for: 839 * RSASSA-PSS [RFC8017] using SHA-512 [RFC6234] 841 * HMAC [RFC2104] using SHA-512 [RFC6234] 843 * ECDSA using curve P-256 [DSS] and SHA-512 [RFC6234] 845 * Ed25519ph, Ed25519ctx, and Ed25519 [RFC8032] 847 "rsa-sha1" 848 Algorithm Name 849 "rsa-sha1" 851 Status 852 Deprecated; SHA-1 not secure. 854 Description 855 RSASSA-PKCS1-v1_5 [RFC8017] using SHA-1 [RFC6234] 857 "rsa-sha256" 859 Algorithm Name 860 "rsa-sha256" 862 Status 863 Deprecated; specifying signature algorithm enables attack vector. 865 Description 866 RSASSA-PKCS1-v1_5 [RFC8017] using SHA-256 [RFC6234] 868 "hmac-sha256" 870 Algorithm Name 871 "hmac-sha256" 873 Status 874 Deprecated; specifying signature algorithm enables attack vector. 876 Description 877 HMAC [RFC2104] using SHA-256 [RFC6234] 879 "ecdsa-sha256" 881 Algorithm Name 882 "ecdsa-sha256" 884 Status 885 Deprecated; specifying signature algorithm enables attack vector. 887 Description 888 ECDSA using curve P-256 [DSS] and SHA-256 [RFC6234] 890 5.2. HTTP Signature Parameters Registry 892 This document defines the Signature header field, whose value 893 contains a list of named parameters. IANA is asked to create and 894 maintain a new registry titled "HTTP Signature Parameters" to record 895 and maintain the set of named parameters defined for use within the 896 Signature header field. Initial values for this registry are given 897 in Section 5.2.2. Future assignments and modifications to existing 898 assignment are to be made through the Expert Review registration 899 policy [BCP 26] and shall follow the template presented in 900 Section 5.2.1. 902 5.2.1. Registration Template 904 Name 905 An identifier for the parameter. The name MUST be an ASCII string 906 consisting only of lower-case characters (""a"" - ""z""), digits 907 (""0"" - ""9""), and hyphens (""-""), and SHOULD NOT exceed 20 908 characters in length. The identifier MUST be unique within the 909 context of the registry. 911 Status 912 A value indicating the status of the parameter definition. 913 Allowed values are "Active" and "Deprecated". Active parameter 914 definitions are available for general use. Deprecated parameter 915 definitions may be in use by existing implementations, but SHOULD 916 NOT be used by new implementations. 918 Reference(s) 919 A reference or list of references to the documents that define the 920 purpose, content, and usage of the parameter. The parameter 921 definition MUST define the format of the parameter's value using 922 the extended ABNF notation used in [HTTP], or by referencing one 923 or more standard formats such as base 64 or URI. The parameter 924 definition MUST also specify the normative requirements for when 925 and how the parameter may be used. Value formats MUST NOT allow 926 values that would break the parameter list syntax used by the 927 Signature header. 929 5.2.2. Initial Contents 931 The table below contains the initial contents of the HTTP Signature 932 Parameters Registry. Each row in the table represents a distinct 933 entry in the registry. 935 +-------------+--------+------------------------------+ 936 | Name | Status | Reference(s) | 937 +=============+========+==============================+ 938 | "algorithm" | Active | Section 4.1 of this document | 939 +-------------+--------+------------------------------+ 940 | "created" | Active | Section 4.1 of this document | 941 +-------------+--------+------------------------------+ 942 | "expires" | Active | Section 4.1 of this document | 943 +-------------+--------+------------------------------+ 944 | "headers" | Active | Section 4.1 of this document | 945 +-------------+--------+------------------------------+ 946 | "keyId" | Active | Section 4.1 of this document | 947 +-------------+--------+------------------------------+ 948 | "signature" | Active | Section 4.1 of this document | 949 +-------------+--------+------------------------------+ 951 Table 4: Initial contents of the HTTP Signature 952 Parameters Registry. 954 6. Security Considerations 956 [[ TODO: need to dive deeper on this section; not sure how much of 957 what's referenced below is actually applicable, or if it covers 958 everything we need to worry about. ]] 960 [[ TODO: Should provide some recommendations on how to determine what 961 content needs to be signed for a given use case. ]] 963 There are a number of security considerations to take into account 964 when implementing or utilizing this specification. A thorough 965 security analysis of this protocol, including its strengths and 966 weaknesses, can be found in Security Considerations for HTTP 967 Signatures [WP-HTTP-Sig-Audit]. 969 7. References 971 7.1. Normative References 973 [BCP 26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 974 Writing an IANA Considerations Section in RFCs", BCP 26, 975 RFC 8126, DOI 10.17487/RFC8126, June 2017, 976 . 978 [DSS] NIST, "Digital Signature Standard (DSS)", FIPS 186-4, 979 DOI 10.6028/NIST.FIPS.186-4, July 2013, 980 . 983 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 984 Protocol (HTTP/1.1): Message Syntax and Routing", 985 RFC 7230, DOI 10.17487/RFC7230, June 2014, 986 . 988 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 989 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 990 DOI 10.17487/RFC7540, May 2015, 991 . 993 [POSIX.1] IEEE and The Open Group, "The Open Group Base 994 Specifications Issue 7, 2018 edition", IEEE 995 Std 1003.1-2017, 2018, 996 . 998 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 999 Hashing for Message Authentication", RFC 2104, 1000 DOI 10.17487/RFC2104, February 1997, 1001 . 1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1004 Requirement Levels", BCP 14, RFC 2119, 1005 DOI 10.17487/RFC2119, March 1997, 1006 . 1008 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1009 Resource Identifier (URI): Generic Syntax", STD 66, 1010 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1011 . 1013 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1014 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1015 . 1017 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1018 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1019 . 1021 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1022 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1023 May 2017, . 1025 7.2. Informative References 1027 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1028 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1029 . 1031 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1032 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1033 DOI 10.17487/RFC6234, May 2011, 1034 . 1036 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1037 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1038 . 1040 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1041 DOI 10.17487/RFC7518, May 2015, 1042 . 1044 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1045 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1046 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1047 . 1049 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1050 Signature Algorithm (EdDSA)", RFC 8032, 1051 DOI 10.17487/RFC8032, January 2017, 1052 . 1054 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1055 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1056 . 1058 [WP-HTTP-Sig-Audit] 1059 Sporny, M., "Security Considerations for HTTP Signatures", 1060 June 2013, . 1063 Appendix A. Examples 1065 A.1. Example Keys 1067 This section provides cryptographic keys that are referenced in 1068 example signatures throughout this document. These keys MUST NOT be 1069 used for any purpose other than testing. 1071 A.1.1. "rsa-test" 1073 The following key is a 2048-bit RSA public and private key pair: 1075 -----BEGIN RSA PUBLIC KEY----- 1076 MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw 1077 WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq 1078 MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg 1079 kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P 1080 uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ 1081 PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB 1082 -----END RSA PUBLIC KEY----- 1084 -----BEGIN RSA PRIVATE KEY----- 1085 MIIEqAIBAAKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsP 1086 BRrwWEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsd 1087 JKFqMGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75 1088 jfZgkne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKI 1089 lE0PuKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZ 1090 SFlQPSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQABAoIBAG/JZuSWdoVHbi56 1091 vjgCgkjg3lkO1KrO3nrdm6nrgA9P9qaPjxuKoWaKO1cBQlE1pSWp/cKncYgD5WxE 1092 CpAnRUXG2pG4zdkzCYzAh1i+c34L6oZoHsirK6oNcEnHveydfzJL5934egm6p8DW 1093 +m1RQ70yUt4uRc0YSor+q1LGJvGQHReF0WmJBZHrhz5e63Pq7lE0gIwuBqL8SMaA 1094 yRXtK+JGxZpImTq+NHvEWWCu09SCq0r838ceQI55SvzmTkwqtC+8AT2zFviMZkKR 1095 Qo6SPsrqItxZWRty2izawTF0Bf5S2VAx7O+6t3wBsQ1sLptoSgX3QblELY5asI0J 1096 YFz7LJECgYkAsqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOM 1097 cCNq8SyYbTqgnWlB9ZfcAm/cFpA8tYci9m5vYK8HNxQr+8FS3Qo8N9RJ8d0U5Csw 1098 DzMYfRghAfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1 1099 mwJ5AL0pYF0G7x81prlARURwHo0Yf52kEw1dxpx+JXER7hQRWQki5/NsUEtv+8RT 1100 qn2m6qte5DXLyn83b1qRscSdnCCwKtKWUug5q2ZbwVOCJCtmRwmnP131lWRYfj67 1101 B/xJ1ZA6X3GEf4sNReNAtaucPEelgR2nsN0gKQKBiGoqHWbK1qYvBxX2X3kbPDkv 1102 9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn 1103 f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo 1104 81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa 1105 /2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG 1106 IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m 1107 qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P 1108 WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ 1109 EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0= 1110 -----END RSA PRIVATE KEY----- 1112 A.2. Example "keyId" Values 1114 The table below maps example "keyId" values to associated algorithms 1115 and/or keys. These are example mappings that are valid only within 1116 the context of examples in examples within this and future documents 1117 that reference this section. Unless otherwise specified, within the 1118 context of examples it should be assumed that the signer and verifier 1119 understand these "keyId" mappings. These "keyId" values are not 1120 reserved, and deployments are free to use them, with these 1121 associations or others. 1123 +--------------+---------------------------------+-----------------+ 1124 | "keyId" | Algorithm | Verification | 1125 | | | Key | 1126 +==============+=================================+=================+ 1127 | "test-key-a" | "hs2019", using RSASSA-PSS | The public key | 1128 | | [RFC8017] and SHA-512 [RFC6234] | specified in | 1129 | | | Appendix A.1.1. | 1130 +--------------+---------------------------------+-----------------+ 1131 | "test-key-b" | "rsa-256" | The public key | 1132 | | | specified in | 1133 | | | Appendix A.1.1. | 1134 +--------------+---------------------------------+-----------------+ 1136 Table 5 1138 A.3. Test Cases 1140 This section provides non-normative examples that may be used as test 1141 cases to validate implementation correctness. These examples are 1142 based on the following HTTP message: 1144 POST /foo?param=value&pet=dog HTTP/1.1 1145 Host: example.com 1146 Date: Tue, 07 Jun 2014 20:51:35 GMT 1147 Content-Type: application/json 1148 Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 1149 Content-Length: 18 1151 {"hello": "world"} 1153 A.3.1. Signature Generation 1155 A.3.1.1. "hs2019" signature over minimal recommended content 1157 This presents metadata for a Signature using "hs2019", over minimum 1158 recommended data to sign: 1160 +--------------+-----------------------------------+ 1161 | Property | Value | 1162 +==============+===================================+ 1163 | Algorithm | "hs2019", using RSASSA-PSS | 1164 | | [RFC8017] using SHA-512 [RFC6234] | 1165 +--------------+-----------------------------------+ 1166 | Covered | "(created) (request-target)" | 1167 | Content | | 1168 +--------------+-----------------------------------+ 1169 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1170 | Time | | 1171 +--------------+-----------------------------------+ 1172 | Expiration | Undefined | 1173 | Time | | 1174 +--------------+-----------------------------------+ 1175 | Verification | The public key specified in | 1176 | Key Material | Appendix A.1.1. | 1177 +--------------+-----------------------------------+ 1179 Table 6 1181 The Signature Input is: 1183 (created): 1402170695 1184 (request-target): post /foo?param=value&pet=dog 1186 The signature value is: 1188 e3y37nxAoeuXw2KbaIxE2d9jpE7Z9okgizg6QbD2Z7fUVUvog+ZTKKLRBnhNglVIY6fAa 1189 YlHwx7ZAXXdBVF8gjWBPL6U9zRrB4PFzjoLSxHaqsvS0ZK9FRxpenptgukaVQ1aeva3PE 1190 1aD6zZ93df2lFIFXGDefYCQ+M/SrDGQOFvaVykEkte5mO6zQZ/HpokjMKvilfSMJS+vbv 1191 C1GJItQpjs636Db+7zB2W1BurkGxtQdCLDXuIDg4S8pPSDihkch/dUzL2BpML3PXGKVXw 1192 HOUkVG6Q2ge07IYdzya6N1fIVA9eKI1Y47HT35QliVAxZgE0EZLo8mxq19ReIVvuFg== 1194 A possible Signature header for this signature is: 1196 Signature: keyId="test-key-a", created=1402170695, 1197 headers="(created) (request-target)", 1198 signature="e3y37nxAoeuXw2KbaIxE2d9jpE7Z9okgizg6QbD2Z7fUVUvog+ZTKK 1199 LRBnhNglVIY6fAaYlHwx7ZAXXdBVF8gjWBPL6U9zRrB4PFzjoLSxHaqsvS0ZK 1200 9FRxpenptgukaVQ1aeva3PE1aD6zZ93df2lFIFXGDefYCQ+M/SrDGQOFvaVyk 1201 Ekte5mO6zQZ/HpokjMKvilfSMJS+vbvC1GJItQpjs636Db+7zB2W1BurkGxtQ 1202 dCLDXuIDg4S8pPSDihkch/dUzL2BpML3PXGKVXwHOUkVG6Q2ge07IYdzya6N1 1203 fIVA9eKI1Y47HT35QliVAxZgE0EZLo8mxq19ReIVvuFg==" 1205 A.3.1.2. "hs2019" signature covering all header fields 1207 This presents metadata for a Signature using "hs2019" that covers all 1208 header fields in the request: 1210 +--------------+--------------------------------------------------+ 1211 | Property | Value | 1212 +==============+==================================================+ 1213 | Algorithm | "hs2019", using RSASSA-PSS [RFC8017] using | 1214 | | SHA-512 [RFC6234] | 1215 +--------------+--------------------------------------------------+ 1216 | Covered | "(created)", "(request-target)", "host", "date", | 1217 | Content | "content-type", "digest", "content-length" | 1218 +--------------+--------------------------------------------------+ 1219 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1220 | Time | | 1221 +--------------+--------------------------------------------------+ 1222 | Expiration | Undefined | 1223 | Time | | 1224 +--------------+--------------------------------------------------+ 1225 | Verification | The public key specified in Appendix A.1.1. | 1226 | Key Material | | 1227 +--------------+--------------------------------------------------+ 1229 Table 7 1231 The Signature Input is: 1233 (created): 1402170695 1234 (request-target): post /foo?param=value&pet=dog 1235 host: example.com 1236 date: Tue, 07 Jun 2014 20:51:35 GMT 1237 content-type: application/json 1238 digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 1239 content-length: 18 1241 The signature value is: 1243 KXUj1H3ZOhv3Nk4xlRLTn4bOMlMOmFiud3VXrMa9MaLCxnVmrqOX5BulRvB65YW/wQp0o 1244 T/nNQpXgOYeY8ovmHlpkRyz5buNDqoOpRsCpLGxsIJ9cX8XVsM9jy+Q1+RIlD9wfWoPHh 1245 qhoXt35ZkasuIDPF/AETuObs9QydlsqONwbK+TdQguDK/8Va1Pocl6wK1uLwqcXlxhPEb 1246 55EmdYB9pddDyHTADING7K4qMwof2mC3t8Pb0yoLZoZX5a4Or4FrCCKK/9BHAhq/RsVk0 1247 dTENMbTB4i7cHvKQu+o9xuYWuxyvBa0Z6NdOb0di70cdrSDEsL5Gz7LBY5J2N9KdGg== 1249 A possible Signature header for this signature is: 1251 Signature: keyId="test-key-a", algorithm="hs2019", 1252 created=1402170695, 1253 headers="(request-target) (created) host date content-type digest 1254 content-length", 1255 signature="KXUj1H3ZOhv3Nk4xlRLTn4bOMlMOmFiud3VXrMa9MaLCxnVmrqOX5B 1256 ulRvB65YW/wQp0oT/nNQpXgOYeY8ovmHlpkRyz5buNDqoOpRsCpLGxsIJ9cX8 1257 XVsM9jy+Q1+RIlD9wfWoPHhqhoXt35ZkasuIDPF/AETuObs9QydlsqONwbK+T 1258 dQguDK/8Va1Pocl6wK1uLwqcXlxhPEb55EmdYB9pddDyHTADING7K4qMwof2m 1259 C3t8Pb0yoLZoZX5a4Or4FrCCKK/9BHAhq/RsVk0dTENMbTB4i7cHvKQu+o9xu 1260 YWuxyvBa0Z6NdOb0di70cdrSDEsL5Gz7LBY5J2N9KdGg==" 1262 A.3.2. Signature Verification 1263 A.3.2.1. Minimal Required Signature Header 1265 This presents a Signature header containing only the minimal required 1266 parameters: 1268 Signature: keyId="test-key-a", (created): 1402170695, 1269 signature="V3SijFpJOvDUT8t1/EnYli/4TbF2AGqwBGiGUGrgClCkiOAIlOxxY7 1270 2Mr13DccFkYzg3gX1jIOpKXzH70C5bru4b71SBG+ShiJLu34gHCG33iw44NLG 1271 UvT5+F+LCKbbHberyk8eyYsZ+TLwtZAYKafxfNOWQXF4o3QaWslDMm8Tcgrd8 1272 onM45ayFyR4nXRlcGad4PISYGz8PmO4Y+K8RYOyDkgsmRxKtftFQUYG41anyE 1273 lccNLfEfLBKsyV6kxr36U1Q7FdUopLv8kqluQySrWD6kesvFxNvbEOi+1uZqT 1274 uFlK8ZldITQiqtNYaabRjQFZio63gma2y+UAaTGLdM9A==" 1276 The corresponding signature metadata derived from this header field 1277 is: 1279 +--------------+-----------------------------------+ 1280 | Property | Value | 1281 +==============+===================================+ 1282 | Algorithm | "hs2019", using RSASSA-PSS | 1283 | | [RFC8017] using SHA-256 [RFC6234] | 1284 +--------------+-----------------------------------+ 1285 | Covered | "(created)" | 1286 | Content | | 1287 +--------------+-----------------------------------+ 1288 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1289 | Time | | 1290 +--------------+-----------------------------------+ 1291 | Expiration | Undefined | 1292 | Time | | 1293 +--------------+-----------------------------------+ 1294 | Verification | The public key specified in | 1295 | Key Material | Appendix A.1.1. | 1296 +--------------+-----------------------------------+ 1298 Table 8 1300 The corresponding Signature Input is: 1302 (created): 1402170695 1304 A.3.2.2. Minimal Recommended Signature Header 1306 This presents a Signature header containing only the minimal required 1307 and recommended parameters: 1309 Signature: algorithm="hs2019", keyId="test-key-a", 1310 (created): 1402170695, 1311 signature="V3SijFpJOvDUT8t1/EnYli/4TbF2AGqwBGiGUGrgClCkiOAIlOxxY7 1312 2Mr13DccFkYzg3gX1jIOpKXzH70C5bru4b71SBG+ShiJLu34gHCG33iw44NLG 1313 UvT5+F+LCKbbHberyk8eyYsZ+TLwtZAYKafxfNOWQXF4o3QaWslDMm8Tcgrd8 1314 onM45ayFyR4nXRlcGad4PISYGz8PmO4Y+K8RYOyDkgsmRxKtftFQUYG41anyE 1315 lccNLfEfLBKsyV6kxr36U1Q7FdUopLv8kqluQySrWD6kesvFxNvbEOi+1uZqT 1316 uFlK8ZldITQiqtNYaabRjQFZio63gma2y+UAaTGLdM9A==" 1318 The corresponding signature metadata derived from this header field 1319 is: 1321 +--------------+-----------------------------------+ 1322 | Property | Value | 1323 +==============+===================================+ 1324 | Algorithm | "hs2019", using RSASSA-PSS | 1325 | | [RFC8017] using SHA-512 [RFC6234] | 1326 +--------------+-----------------------------------+ 1327 | Covered | "(created)" | 1328 | Content | | 1329 +--------------+-----------------------------------+ 1330 | Creation | 8:51:35 PM GMT, June 7th, 2014 | 1331 | Time | | 1332 +--------------+-----------------------------------+ 1333 | Expiration | Undefined | 1334 | Time | | 1335 +--------------+-----------------------------------+ 1336 | Verification | The public key specified in | 1337 | Key Material | Appendix A.1.1. | 1338 +--------------+-----------------------------------+ 1340 Table 9 1342 The corresponding Signature Input is: 1344 (created): 1402170695 1346 A.3.2.3. Minimal Signature Header using "rsa-256" 1348 This presents a minimal Signature header for a signature using the 1349 "rsa-256" algorithm: 1351 Signature: algorithm="rsa-256", keyId="test-key-b", 1352 headers="date", 1353 signature="HtXycCl97RBVkZi66ADKnC9c5eSSlb57GnQ4KFqNZplOpNfxqk62Jz 1354 Z484jXgLvoOTRaKfR4hwyxlcyb+BWkVasApQovBSdit9Ml/YmN2IvJDPncrlh 1355 PDVDv36Z9/DiSO+RNHD7iLXugdXo1+MGRimW1RmYdenl/ITeb7rjfLZ4b9VNn 1356 LFtVWwrjhAiwIqeLjodVImzVc5srrk19HMZNuUejK6I3/MyN3+3U8tIRW4LWz 1357 x6ZgGZUaEEP0aBlBkt7Fj0Tt5/P5HNW/Sa/m8smxbOHnwzAJDa10PyjzdIbyw 1358 lnWIIWtZKPPsoVoKVopUWEU3TNhpWmaVhFrUL/O6SN3w==" 1360 The corresponding signature metadata derived from this header field 1361 is: 1363 +---------------------------+--------------------------+ 1364 | Property | Value | 1365 +===========================+==========================+ 1366 | Algorithm | "rsa-256" | 1367 +---------------------------+--------------------------+ 1368 | Covered Content | "date" | 1369 +---------------------------+--------------------------+ 1370 | Creation Time | Undefined | 1371 +---------------------------+--------------------------+ 1372 | Expiration Time | Undefined | 1373 +---------------------------+--------------------------+ 1374 | Verification Key Material | The public key specified | 1375 | | in Appendix A.1.1. | 1376 +---------------------------+--------------------------+ 1378 Table 10 1380 The corresponding Signature Input is: 1382 date: Tue, 07 Jun 2014 20:51:35 GMT 1384 Appendix B. Topics for Working Group Discussion 1386 This section is to be removed before publishing as an RFC. 1388 The goal of this draft document is to provide a starting point at 1389 feature parity and compatible with the cavage-12 draft. The draft 1390 has known issues that will need to be addressed during development, 1391 and in the spirit of keeping compatibility, these issues have been 1392 enumerated but not addressed in this version. The editor recommends 1393 the working group discuss the issues and features described in this 1394 section after adoption of the document by the working group. Topics 1395 are not listed in any particular order. 1397 B.1. Issues 1398 B.1.1. Confusing guidance on algorithm and key identification 1400 The current draft encourages determining the Algorithm metadata 1401 property from the "keyId" field, both in the guidance for the use of 1402 "algorithm" and "keyId", and the definition for the "hs2019" 1403 algorithm and deprecation of the other algorithms in the registry. 1404 The current state arose from concern that a malicious party could 1405 change the value of the "algorithm" parameter, potentially tricking 1406 the verifier into accepting a signature that would not have been 1407 verified under the actual parameter. 1409 Punting algorithm identification into "keyId" hurts interoperability, 1410 since we aren't defining the syntax or semantics of "keyId". It 1411 actually goes against that claim, as we are dictating that the 1412 signing algorithm must be specified by "keyId" or derivable from it. 1413 It also renders the algorithm registry essentially useless. Instead 1414 of this approach, we can protect against manipulation of the 1415 Signature header field by adding support for (and possibly mandating) 1416 including Signature metadata within the Signature Input. 1418 B.1.2. Lack of definition of "keyId" hurts interoperability 1420 The current text leaves the format and semantics of "keyId" 1421 completely up to the implementation. This is primarily due to the 1422 fact that most implementers of Cavage have extensive investment in 1423 key distribution and management, and just need to plug an identifier 1424 into the header. We should support those cases, but we also need to 1425 provide guidance for the developer that doesn't have that and just 1426 wants to know how to identify a key. It may be enough to punt this 1427 to profiling specs, but this needs to be explored more. 1429 B.1.3. Algorithm Registry duplicates work of JWA 1431 JSON Web Algorithms (JWA) [RFC7518] already defines an IANA registry 1432 for cryptographic algorithms. This wasn't used by Cavage out of 1433 concerns about complexity of JOSE, and issues with JWE and JWS being 1434 too flexible, leading to insecure combinations of options. Using 1435 JWA's definitions does not need to mean we're using JOSE, however. 1436 We should look at if/how we can leverage JWA's work without 1437 introducing too many sharp edges for implementers. 1439 In any use of JWS algorithms, this spec would define a way to create 1440 the JWS Signing Input string to be applied to the algorithm. It 1441 should be noted that this is incompatible with JWS itself, which 1442 requires the inclusion of a structured header in the signature input. 1444 A possible approach is to incorporate all elements of the JWA 1445 signature algorithm registry into this spec using a prefix or other 1446 marker, such as "jws-RS256" for the RSA 256 JSON Web Signature 1447 algorithm. 1449 B.1.4. Algorithm Registry should not be initialized with deprecated 1450 entries 1452 The initial entries in this document reflect those in Cavage. The 1453 ones that are marked deprecated were done so because of the issue 1454 explained in Appendix B.1.1, with the possible exception of "rsa- 1455 sha1". We should probably just remove that one. 1457 B.1.5. No percent-encoding normalization of path/query 1459 See: issue #26 (https://github.com/w3c-dvcg/http-signatures/ 1460 issues/26) 1462 The canonicalization rules for "(request-target)" do not perform 1463 handle minor, semantically meaningless differences in percent- 1464 encoding, such that verification could fail if an intermediary 1465 normalizes the effective request URI prior to forwarding the message. 1467 At a minimum, they should be case and percent-encoding normalized as 1468 described in sections 6.2.2.1 and 6.2.2.2 of [RFC3986]. 1470 B.1.6. Misleading name for "headers" parameter 1472 The Covered Content list contains identifiers for more than just 1473 headers, so the "header" parameter name is no longer appropriate. 1474 Some alternatives: "content", "signed-content", "covered-content". 1476 B.1.7. Changes to whitespace in header field values break verification 1478 Some header field values contain RWS, OWS, and/or BWS. Since the 1479 header field value canonicalization rules do not address whitespace, 1480 changes to it (e.g., removing OWS or BWS or replacing strings of RWS 1481 with a single space) can cause verification to fail. 1483 B.1.8. Multiple Set-Cookie headers are not well supported 1485 The Set-Cookie header can occur multiple times but does not adhere to 1486 the list syntax, and thus is not well supported by the header field 1487 value concatenation rules. 1489 B.1.9. Covered Content list is not signed 1491 The Covered Content list should be part of the Signature Input, to 1492 protect against malicious changes. 1494 B.1.10. Algorithm is not signed 1496 The Algorithm should be part of the Signature Input, to protect 1497 against malicious changes. 1499 B.1.11. Verification key identifier is not signed 1501 The Verification key identifier (e.g., the value used for the "keyId" 1502 parameter) should be part of the Signature Input, to protect against 1503 malicious changes. 1505 B.1.12. Max values, precision for Integer String and Decimal String not 1506 defined 1508 The definitions for Integer String and Decimal String do not specify 1509 a maximum value. The definition for Decimal String (used to provide 1510 sub-second precision for Expiration Time) does not define minimum or 1511 maximum precision requirements. It should set a sane requirement 1512 here (e.g., MUST support up to 3 decimal places and no more). 1514 B.1.13. "keyId" parameter value could break list syntax 1516 The "keyId" parameter value needs to be constrained so as to not 1517 break list syntax (e.g., by containing a comma). 1519 B.1.14. Creation Time and Expiration Time do not allow for clock skew 1521 The processing instructions for Creation Time and Expiration Time 1522 imply that verifiers are not permitted to account for clock skew 1523 during signature verification. 1525 B.1.15. Should require lowercased header field names as identifiers 1527 The current text allows mixed-case header field names when they are 1528 being used as content identifiers. This is unnecessary, as header 1529 field names are case-insensitive, and creates opportunity for 1530 incompatibility. Instead, content identifiers should always be 1531 lowercase. 1533 B.1.16. Reconcile Date header and Creation Time 1535 The draft is missing guidance on if/how the Date header relates to 1536 signature Creation Time. There are cases where they may be 1537 different, such as if a signature was pre-created. Should Creation 1538 Time default to the value in the Date header if the "created" 1539 parameter is not specified? 1541 B.1.17. Remove algorithm-specific rules for content identifiers 1543 The rules that restrict when the signer can or must include certain 1544 identifiers appear to be related to the pseudo-revving of the Cavage 1545 draft that happened when the "hs2019" algorithm was introduced. We 1546 should drop these rules, as it can be expected that anyone 1547 implementing this draft will support all content identifiers. 1549 B.1.18. Add guidance for signing compressed headers 1551 The draft should provide guidance on how to sign headers when HTTP/2 1552 header compression [RFC7541] is used. This guidance might be as 1553 simple as "sign the uncompressed header field value." 1555 B.1.19. Transformations to Via header field value break verification 1557 Intermediaries are permitted to strip comments from the Via header 1558 field value, and consolidate related sequences of entries. The 1559 canonicalization rules do not account for these changes, and thus 1560 they cause signature verification to fail if the Via header is 1561 signed. At the very least, guidance on signing or not signing Via 1562 headers needs to be included. 1564 B.1.20. Case changes to case-insensitive header field values break 1565 verification 1567 Some header field values are case-insensitive, in whole or in part. 1568 The canonicalization rules do not account for this, thus a case 1569 change to a covered header field value causes verification to fail. 1571 B.1.21. Need more examples for Signature header 1573 Add more examples showing different cases e.g, where "created" or 1574 "expires" are not present. 1576 B.1.22. Expiration not needed 1578 In many cases, putting the expiration of the signature into the hands 1579 of the signer opens up more options for failures than necessary. 1580 Instead of the "expires", any verifier can use the "created" field 1581 and an internal lifetime or offset to calculate expiration. We 1582 should consider dropping the "expires" field. 1584 B.2. Features 1585 B.2.1. Define more content identifiers 1587 It should be possible to independently include the following content 1588 and metadata properties in Covered Content: 1590 * The signature's Algorithm 1592 * The signature's Covered Content 1594 * The value used for the "keyId" parameter 1596 * Request method 1598 * Individual components of the effective request URI: scheme, 1599 authority, path, query 1601 * Status code 1603 * Request body (currently supported via Digest header) 1605 B.2.2. Multiple signature support 1607 [[ Editor's note: I believe this use case is theoretical. Please let 1608 me know if this is a use case you have. ]] 1610 There may be scenarios where attaching multiple signatures to a 1611 single message is useful: 1613 * A gateway attaches a signature over headers it adds (e.g., 1614 Forwarded) to messages already signed by the user agent. 1616 * A signer attaches two signatures signed by different keys, to be 1617 verified by different entities. 1619 This could be addressed by changing the Signature header syntax to 1620 accept a list of parameter sets for a single signature, e.g., by 1621 separating parameters with "";"" instead of "","". It may also be 1622 necessary to include a signature identifier parameter. 1624 B.2.3. Support for incremental signing of header field value list items 1626 [[ Editor's note: I believe this use case is theoretical. Please let 1627 me know if this is a use case you have. ]] 1629 Currently, signing a header field value is all-or-nothing: either the 1630 entire value is signed, or none of it is. For header fields that use 1631 list syntax, it would be useful to be able to specify which items in 1632 the list are signed. 1634 A simple approach that allowed the signer to indicate the list size 1635 at signing time would allow a signer to sign header fields that are 1636 may be appended to by intermediaries as the message makes its way to 1637 the recipient. Specifying list size in terms of number of items 1638 could introduce risks of list syntax is not strictly adhered to 1639 (e.g., a malicious party crafts a value that gets parsed by the 1640 application as 5 items, but by the verifier as 4). Specifying list 1641 size in number of octets might address this, but more exploration is 1642 required. 1644 B.2.4. Support expected authority changes 1646 In some cases, the authority of the effective request URI may be 1647 expected to change, for example from "public-service- 1648 name.example.com" to "service-host-1.public-service- 1649 name.example.com". This is commonly the case for services that are 1650 hosted behind a load-balancing gateway, where the client sends 1651 requests to a publicly known domain name for the service, and these 1652 requests are transformed by the gateway into requests to specific 1653 hosts in the service fleet. 1655 One possible way to handle this would be to special-case the Host 1656 header field to allow verifier to substitute a known expected value, 1657 or a value provided in another header field (e.g., Via) when 1658 generating the Signature Input, provided that the verifier also 1659 recognizes the real value in the Host header. Alternatively, this 1660 logic could apply to an "(audience)" content identifier. 1662 B.2.5. Support for signing specific cookies 1664 A signer may only wish to sign one or a few cookies, for example if 1665 the website requires its authentication state cookie to be signed, 1666 but also sets other cookies (e.g., for analytics, ad tracking, etc.) 1668 Acknowledgements 1670 This specification is based on the draft-cavage-http-signatures 1671 draft. The editor would like to thank the authors of that draft, 1672 Mark Cavage and Manu Sporny, for their work on that draft and their 1673 continuing contributions. 1675 The editor would also like to thank the following individuals for 1676 feedback on and implementations of the draft-cavage-http-signatures 1677 draft (in alphabetical order): Mark Adamcin, Mark Allen, Paul 1678 Annesley, Karl Böhlmark, Stéphane Bortzmeyer, Sarven 1679 Capadisli, Liam Dennehy, ductm54, Stephen Farrell, Phillip Hallam- 1680 Baker, Eric Holmes, Andrey Kislyuk, Adam Knight, Dave Lehn, Dave 1681 Longley, James H. Manger, Ilari Liusvaara, Mark Nottingham, Yoav 1682 Nir, Adrian Palmer, Lucas Pardue, Roberto Polli, Julian Reschke, 1683 Michael Richardson, Wojciech Rygielski, Adam Scarr, Cory J. Slep, 1684 Dirk Stein, Henry Story, Lukasz Szewc, Chris Webber, and Jeffrey 1685 Yasskin 1687 Document History 1689 This section is to be removed before publishing as an RFC. 1691 * *draft-ietf-httpbis-message-signatures* 1693 - *-00* 1695 o Copied from draft-richanna-http-message-signatures 1697 o Corrected header field content identifiers in Table 1. 1699 * *draft-richanna-http-message-signatures* 1701 - *-00* 1703 o Converted to xml2rfc v3 and reformatted to comply with RFC 1704 style guides. 1706 o Removed "Signature" auth-scheme definition and related 1707 content. 1709 o Removed conflicting normative requirements for use of 1710 "algorithm" parameter. Now MUST NOT be relied upon. 1712 o Removed Extensions appendix. 1714 o Rewrote abstract and introduction to explain context and 1715 need, and challenges inherent in signing HTTP messages. 1717 o Rewrote and heavily expanded algorithm definition, retaining 1718 normative requirements. 1720 o Added definitions for key terms, referenced RFC 7230 for 1721 HTTP terms. 1723 o Added examples for canonicalization and signature generation 1724 steps. 1726 o Rewrote Signature header definition, retaining normative 1727 requirements. 1729 o Added default values for "algorithm" and "expires" 1730 parameters. 1732 o Rewrote HTTP Signature Algorithms registry definition. 1733 Added change control policy and registry template. Removed 1734 suggested URI. 1736 o Added IANA HTTP Signature Parameter registry. 1738 o Added additional normative and informative references. 1740 o Added Topics for Working Group Discussion section, to be 1741 removed prior to publication as an RFC. 1743 Authors' Addresses 1745 Annabelle Backman (editor) 1746 Amazon 1747 P.O. Box 81226 1748 Seattle, WA 98108-1226 1749 United States of America 1751 Email: richanna@amazon.com 1752 URI: https://www.amazon.com/ 1754 Justin Richer 1755 Bespoke Engineering 1757 Email: ietf@justin.richer.org 1758 URI: https://bspk.io/ 1760 Manu Sporny 1761 Digital Bazaar 1762 203 Roanoke Street W. 1763 Blacksburg, VA 24060 1764 United States of America 1766 Phone: +1 540 961 4469 1767 Email: msporny@digitalbazaar.com 1768 URI: https://manu.sporny.org/