idnits 2.17.1 draft-ietf-httpbis-message-signatures-03.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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 April 2021) is 1113 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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. 'FIPS186-4' ** Obsolete normative reference: RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) ** Obsolete normative reference: RFC 7230 (ref. 'MESSAGING') (Obsoleted by RFC 9110, RFC 9112) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 8792 ** Obsolete normative reference: RFC 7231 (ref. 'SEMANTICS') (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP A. Backman, Ed. 3 Internet-Draft Amazon 4 Intended status: Standards Track J. Richer 5 Expires: 9 October 2021 Bespoke Engineering 6 M. Sporny 7 Digital Bazaar 8 7 April 2021 10 Signing HTTP Messages 11 draft-ietf-httpbis-message-signatures-03 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 to Readers 24 _RFC EDITOR: please remove this section before publication_ 26 Discussion of this draft takes place on the HTTP working group 27 mailing list (ietf-http-wg@w3.org), which is archived at 28 https://lists.w3.org/Archives/Public/ietf-http-wg/ 29 (https://lists.w3.org/Archives/Public/ietf-http-wg/). 31 Working Group information can be found at https://httpwg.org/ 32 (https://httpwg.org/); source code and issues list for this draft can 33 be found at https://github.com/httpwg/http-extensions/labels/ 34 signatures (https://github.com/httpwg/http-extensions/labels/ 35 signatures). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 9 October 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Discussion . . . . . . . . . . . . . . . . . 4 72 1.2. HTTP Message Transformations . . . . . . . . . . . . . . 5 73 1.3. Safe Transformations . . . . . . . . . . . . . . . . . . 5 74 1.4. Conventions and Terminology . . . . . . . . . . . . . . . 6 75 1.5. Application of HTTP Message Signatures . . . . . . . . . 7 76 2. HTTP Message Signature Covered Content . . . . . . . . . . . 8 77 2.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 9 78 2.1.1. Canonicalized Structured HTTP Headers . . . . . . . . 9 79 2.1.2. Canonicalization Examples . . . . . . . . . . . . . . 9 80 2.2. Dictionary Structured Field Members . . . . . . . . . . . 10 81 2.2.1. Canonicalization Examples . . . . . . . . . . . . . . 10 82 2.3. List Prefixes . . . . . . . . . . . . . . . . . . . . . . 11 83 2.3.1. Canonicalization Examples . . . . . . . . . . . . . . 11 84 2.4. Specialty Content Fields . . . . . . . . . . . . . . . . 12 85 2.4.1. Request Target . . . . . . . . . . . . . . . . . . . 12 86 2.4.2. Signature Parameters . . . . . . . . . . . . . . . . 13 87 2.5. Creating the Signature Input String . . . . . . . . . . . 16 88 3. HTTP Message Signatures . . . . . . . . . . . . . . . . . . . 17 89 3.1. Creating a Signature . . . . . . . . . . . . . . . . . . 18 90 3.2. Verifying a Signature . . . . . . . . . . . . . . . . . . 20 91 3.2.1. Enforcing Application Requirements . . . . . . . . . 21 92 3.3. Signature Algorithm Methods . . . . . . . . . . . . . . . 22 93 3.3.1. RSASSA-PSS using SHA-512 . . . . . . . . . . . . . . 22 94 3.3.2. RSASSA-PKCS1-v1_5 using SHA-256 . . . . . . . . . . . 22 95 3.3.3. HMAC using SHA-256 . . . . . . . . . . . . . . . . . 23 96 3.3.4. ECDSA using curve P-256 DSS and SHA-256 . . . . . . . 23 97 3.3.5. JSON Web Signature (JWS) algorithms . . . . . . . . . 24 98 4. Including a Message Signature in a Message . . . . . . . . . 24 99 4.1. The 'Signature-Input' HTTP Header . . . . . . . . . . . . 24 100 4.2. The 'Signature' HTTP Header . . . . . . . . . . . . . . . 25 101 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 103 5.1. HTTP Signature Algorithms Registry . . . . . . . . . . . 26 104 5.1.1. Registration Template . . . . . . . . . . . . . . . . 26 105 5.1.2. Initial Contents . . . . . . . . . . . . . . . . . . 27 106 5.2. HTTP Signature Metadata Parameters Registry . . . . . . . 28 107 5.2.1. Registration Template . . . . . . . . . . . . . . . . 28 108 5.2.2. Initial Contents . . . . . . . . . . . . . . . . . . 28 109 5.3. HTTP Signature Specialty Content Identifiers Registry . . 29 110 5.3.1. Registration Template . . . . . . . . . . . . . . . . 29 111 5.3.2. Initial Contents . . . . . . . . . . . . . . . . . . 29 112 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 113 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 115 7.2. Informative References . . . . . . . . . . . . . . . . . 31 116 Appendix A. Detecting HTTP Message Signatures . . . . . . . . . 32 117 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 32 118 B.1. Example Keys . . . . . . . . . . . . . . . . . . . . . . 32 119 B.1.1. Example Key RSA test . . . . . . . . . . . . . . . . 32 120 B.2. Example keyid Values . . . . . . . . . . . . . . . . . . 33 121 B.3. Test Cases . . . . . . . . . . . . . . . . . . . . . . . 34 122 B.3.1. Signature Verification . . . . . . . . . . . . . . . 34 123 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 124 Document History . . . . . . . . . . . . . . . . . . . . . . . . 35 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 127 1. Introduction 129 Message integrity and authenticity are important security properties 130 that are critical to the secure operation of many HTTP applications. 131 Application developers typically rely on the transport layer to 132 provide these properties, by operating their application over [TLS]. 133 However, TLS only guarantees these properties over a single TLS 134 connection, and the path between client and application may be 135 composed of multiple independent TLS connections (for example, if the 136 application is hosted behind a TLS-terminating gateway or if the 137 client is behind a TLS Inspection appliance). In such cases, TLS 138 cannot guarantee end-to-end message integrity or authenticity between 139 the client and application. Additionally, some operating 140 environments present obstacles that make it impractical to use TLS, 141 or to use features necessary to provide message authenticity. 142 Furthermore, some applications require the binding of an application- 143 level key to the HTTP message, separate from any TLS certificates in 144 use. Consequently, while TLS can meet message integrity and 145 authenticity needs for many HTTP-based applications, it is not a 146 universal solution. 148 This document defines a mechanism for providing end-to-end integrity 149 and authenticity for content within an HTTP message. The mechanism 150 allows applications to create digital signatures or message 151 authentication codes (MACs) over only that content within the message 152 that is meaningful and appropriate for the application. Strict 153 canonicalization rules ensure that the verifier can verify the 154 signature even if the message has been transformed in any of the many 155 ways permitted by HTTP. 157 The mechanism described in this document consists of three parts: 159 * A common nomenclature and canonicalization rule set for the 160 different protocol elements and other content within HTTP 161 messages. 163 * Algorithms for generating and verifying signatures over HTTP 164 message content using this nomenclature and rule set. 166 * A mechanism for attaching a signature and related metadata to an 167 HTTP message. 169 1.1. Requirements Discussion 171 HTTP permits and sometimes requires intermediaries to transform 172 messages in a variety of ways. This may result in a recipient 173 receiving a message that is not bitwise equivalent to the message 174 that was originally sent. In such a case, the recipient will be 175 unable to verify a signature over the raw bytes of the sender's HTTP 176 message, as verifying digital signatures or MACs requires both signer 177 and verifier to have the exact same signed content. Since the raw 178 bytes of the message cannot be relied upon as signed content, the 179 signer and verifier must derive the signed content from their 180 respective versions of the message, via a mechanism that is resilient 181 to safe changes that do not alter the meaning of the message. 183 For a variety of reasons, it is impractical to strictly define what 184 constitutes a safe change versus an unsafe one. Applications use 185 HTTP in a wide variety of ways, and may disagree on whether a 186 particular piece of information in a message (e.g., the body, or the 187 "Date" header field) is relevant. Thus a general purpose solution 188 must provide signers with some degree of control over which message 189 content is signed. 191 HTTP applications may be running in environments that do not provide 192 complete access to or control over HTTP messages (such as a web 193 browser's JavaScript environment), or may be using libraries that 194 abstract away the details of the protocol (such as the Java 195 HTTPClient library (https://openjdk.java.net/groups/net/httpclient/ 196 intro.html)). These applications need to be able to generate and 197 verify signatures despite incomplete knowledge of the HTTP message. 199 1.2. HTTP Message Transformations 201 As mentioned earlier, HTTP explicitly permits and in some cases 202 requires implementations to transform messages in a variety of ways. 203 Implementations are required to tolerate many of these 204 transformations. What follows is a non-normative and non-exhaustive 205 list of transformations that may occur under HTTP, provided as 206 context: 208 * Re-ordering of header fields with different header field names 209 ([MESSAGING], Section 3.2.2). 211 * Combination of header fields with the same field name 212 ([MESSAGING], Section 3.2.2). 214 * Removal of header fields listed in the "Connection" header field 215 ([MESSAGING], Section 6.1). 217 * Addition of header fields that indicate control options 218 ([MESSAGING], Section 6.1). 220 * Addition or removal of a transfer coding ([MESSAGING], 221 Section 5.7.2). 223 * Addition of header fields such as "Via" ([MESSAGING], 224 Section 5.7.1) and "Forwarded" ([RFC7239], Section 4). 226 1.3. Safe Transformations 228 Based on the definition of HTTP and the requirements described above, 229 we can identify certain types of transformations that should not 230 prevent signature verification, even when performed on content 231 covered by the signature. The following list describes those 232 transformations: 234 * Combination of header fields with the same field name. 236 * Reordering of header fields with different names. 238 * Conversion between different versions of the HTTP protocol (e.g., 239 HTTP/1.x to HTTP/2, or vice-versa). 241 * Changes in casing (e.g., "Origin" to "origin") of any case- 242 insensitive content such as header field names, request URI 243 scheme, or host. 245 * Addition or removal of leading or trailing whitespace to a header 246 field value. 248 * Addition or removal of "obs-folds". 250 * Changes to the "request-target" and "Host" header field that when 251 applied together do not result in a change to the message's 252 effective request URI, as defined in Section 5.5 of [MESSAGING]. 254 Additionally, all changes to content not covered by the signature are 255 considered safe. 257 1.4. Conventions and Terminology 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 261 "OPTIONAL" in this document are to be interpreted as described in 262 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 263 capitals, as shown here. 265 The terms "HTTP message", "HTTP request", "HTTP response", "absolute- 266 form", "absolute-path", "effective request URI", "gateway", "header 267 field", "intermediary", "request-target", "sender", and "recipient" 268 are used as defined in [MESSAGING]. 270 The term "method" is to be interpreted as defined in Section 4 of 271 [SEMANTICS]. 273 For brevity, the term "signature" on its own is used in this document 274 to refer to both digital signatures and keyed MACs. Similarly, the 275 verb "sign" refers to the generation of either a digital signature or 276 keyed MAC over a given input string. The qualified term "digital 277 signature" refers specifically to the output of an asymmetric 278 cryptographic signing operation. 280 In addition to those listed above, this document uses the following 281 terms: 283 Signer: 284 The entity that is generating or has generated an HTTP Message 285 Signature. 287 Verifier: 288 An entity that is verifying or has verified an HTTP Message 289 Signature against an HTTP Message. Note that an HTTP Message 290 Signature may be verified multiple times, potentially by different 291 entities. 293 The term "Unix time" is defined by [POSIX.1] section 4.16 294 (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ 295 V1_chap04.html#tag_04_16). 297 This document contains non-normative examples of partial and complete 298 HTTP messages. To improve readability, header fields may be split 299 into multiple lines, using the "obs-fold" syntax. This syntax is 300 deprecated in [MESSAGING], and senders MUST NOT generate messages 301 that include it. 303 Additionally, some examples use '\' line wrapping for long values 304 that contain no whitespace, as per [RFC8792]. 306 1.5. Application of HTTP Message Signatures 308 HTTP Message Signatures are designed to be a general-purpose security 309 mechanism applicable in a wide variety of circumstances and 310 applications. In order to properly and safely apply HTTP Message 311 Signatures, an application or profile of this specification MUST 312 specify all of the following items: 314 * The set of content identifiers (Section 2) that are expected and 315 required. For example, an authorization protocol could mandate 316 that the "Authorization" header be covered to protect the 317 authorization credentials and mandate the signature parameters 318 contain a "created" parameter, while an API expecting HTTP message 319 bodies could require the "Digest" header to be present and 320 covered. 322 * A means of retrieving the key material used to verify the 323 signature. An application will usually use the "keyid" parameter 324 of the signature parameters Section 2.4.2 and define rules for 325 resolving a key from there, though the appropriate key could be 326 known from other means. 328 * A means of determining the signature algorithm used to verify the 329 signature content is appropriate for the key material. For 330 example, the process could use the "alg" parameter of the 331 signature parameters Section 2.4.2 to state the algorithm 332 explicitly, derive the algorithm from the key material, or use 333 some pre-configured algorithm agreed upon by the signer and 334 verifier. 336 * A means of determining that a given key and algorithm presented in 337 the request are appropriate for the request being made. For 338 example, a server expecting only ECDSA signatures should know to 339 reject any RSA signatures, or a server expecting asymmetric 340 cryptography should know to reject any symmetric cryptography. 342 The details of this kind of profiling are the purview of the 343 application and outside the scope of this specification. 345 2. HTTP Message Signature Covered Content 347 In order to allow signers and verifiers to establish which content is 348 covered by a signature, this document defines content identifiers for 349 data items covered by an HTTP Message Signature as well as the means 350 for combining these canonicalized values into a signature input 351 string. 353 Some content within HTTP messages can undergo transformations that 354 change the bitwise value without altering meaning of the content (for 355 example, the merging together of header fields with the same name). 356 Message content must therefore be canonicalized before it is signed, 357 to ensure that a signature can be verified despite such intermediary 358 transformations. This document defines rules for each content 359 identifier that transform the identifier's associated content into 360 such a canonical form. 362 Content identifiers are defined using production grammar defined by 363 [RFC8941] section 4. The content identifier is an "sf-string" value. 364 The content identifier type MAY define parameters which are included 365 using the "parameters" rule. 367 content-identifier = sf-string parameters 369 Note that this means the value of the identifier itself is encased in 370 double quotes, with parameters following as a semicolon-separated 371 list, such as ""cache-control"", ""date"", or ""@signature-params"". 373 The following sections define content identifier types, their 374 parameters, their associated content, and their canonicalization 375 rules. The method for combining content identifiers into the 376 signature input string is defined in Section 2.5. 378 2.1. HTTP Headers 380 The content identifier for an HTTP header is the lowercased form of 381 its header field name. While HTTP header field names are case- 382 insensitive, implementations MUST use lowercased field names (e.g., 383 "content-type", "date", "etag") when using them as content 384 identifiers. 386 Unless overridden by additional parameters and rules, the HTTP header 387 field value MUST be canonicalized with the following steps: 389 1. Create an ordered list of the field values of each instance of 390 the header field in the message, in the order that they occur (or 391 will occur) in the message. 393 2. Strip leading and trailing whitespace from each item in the list. 395 3. Concatenate the list items together, with a comma "," and space " 396 " between each item. 398 The resulting string is the canonicalized value. 400 2.1.1. Canonicalized Structured HTTP Headers 402 If value of the the HTTP header in question is a structured field 403 [RFC8941], the content identifier MAY include the "sf" parameter. If 404 this parameter is included, the HTTP header value MUST be 405 canonicalized using the rules specified in [RFC8941] section 4. Note 406 that this process will replace any optional whitespace with a single 407 space. 409 The resulting string is used as the field value input in Section 2.1. 411 2.1.2. Canonicalization Examples 413 This section contains non-normative examples of canonicalized values 414 for header fields, given the following example HTTP message: 416 HTTP/1.1 200 OK 417 Server: www.example.com 418 Date: Tue, 07 Jun 2014 20:51:35 GMT 419 X-OWS-Header: Leading and trailing whitespace. 420 X-Obs-Fold-Header: Obsolete 421 line folding. 422 X-Empty-Header: 423 Cache-Control: max-age=60 424 Cache-Control: must-revalidate 425 The following table shows example canonicalized values for header 426 fields, given that message: 428 +=====================+==================================+ 429 | Header Field | Canonicalized Value | 430 +=====================+==================================+ 431 | "cache-control" | max-age=60, must-revalidate | 432 +---------------------+----------------------------------+ 433 | "date" | Tue, 07 Jun 2014 20:51:35 GMT | 434 +---------------------+----------------------------------+ 435 | "server" | www.example.com | 436 +---------------------+----------------------------------+ 437 | "x-empty-header" | | 438 +---------------------+----------------------------------+ 439 | "x-obs-fold-header" | Obsolete line folding. | 440 +---------------------+----------------------------------+ 441 | "x-ows-header" | Leading and trailing whitespace. | 442 +---------------------+----------------------------------+ 444 Table 1: Non-normative examples of header field 445 canonicalization. 447 2.2. Dictionary Structured Field Members 449 An individual member in the value of a Dictionary Structured Field is 450 identified by using the parameter "key" on the content identifier for 451 the header. The value of this parameter is a the key being 452 identified, without any parameters present on that key in the 453 original dictionary. 455 An individual member in the value of a Dictionary Structured Field is 456 canonicalized by applying the serialization algorithm described in 457 Section 4.1.2 of [RFC8941] on a Dictionary containing only that 458 member. 460 2.2.1. Canonicalization Examples 462 This section contains non-normative examples of canonicalized values 463 for Dictionary Structured Field Members given the following example 464 header field, whose value is assumed to be a Dictionary: 466 X-Dictionary: a=1, b=2;x=1;y=2, c=(a b c) 468 The following table shows example canonicalized values for different 469 content identifiers, given that field: 471 +======================+=====================+ 472 | Content Identifier | Canonicalized Value | 473 +======================+=====================+ 474 | "x-dictionary";key=a | 1 | 475 +----------------------+---------------------+ 476 | "x-dictionary";key=b | 2;x=1;y=2 | 477 +----------------------+---------------------+ 478 | "x-dictionary";key=c | (a, b, c) | 479 +----------------------+---------------------+ 481 Table 2: Non-normative examples of 482 Dictionary member canonicalization. 484 2.3. List Prefixes 486 A prefix of a List Structured Field consisting of the first N members 487 in the field's value (where N is an integer greater than 0 and less 488 than or equal to the number of members in the List) is identified by 489 the parameter "prefix" with the value of N as an integer. 491 A list prefix value is canonicalized by applying the serialization 492 algorithm described in Section 4.1.1 of [RFC8941] on a List 493 containing only the first N members as specified in the list prefix, 494 in the order they appear in the original List. 496 2.3.1. Canonicalization Examples 498 This section contains non-normative examples of canonicalized values 499 for list prefixes given the following example header fields, whose 500 values are assumed to be Dictionaries: 502 X-List-A: (a b c d e f) 503 X-List-B: () 505 The following table shows example canonicalized values for different 506 content identifiers, given those fields: 508 +=====================+=====================+ 509 | Content Identifier | Canonicalized Value | 510 +=====================+=====================+ 511 | "x-list-a";prefix=0 | () | 512 +---------------------+---------------------+ 513 | "x-list-a";prefix=1 | (a) | 514 +---------------------+---------------------+ 515 | "x-list-a";prefix=3 | (a, b, c) | 516 +---------------------+---------------------+ 517 | "x-list-a";prefix=6 | (a, b, c, d, e, f) | 518 +---------------------+---------------------+ 519 | "x-list-b";prefix=0 | () | 520 +---------------------+---------------------+ 522 Table 3: Non-normative examples of list 523 prefix canonicalization. 525 2.4. Specialty Content Fields 527 Content not found in an HTTP header can be included in the signature 528 base string by defining a content identifier and the canonicalization 529 method for its content. 531 To differentiate specialty content identifiers from HTTP headers, 532 specialty content identifiers MUST start with the "at" "@" character. 533 This specification defines the following specialty content 534 identifiers: 536 @request-target The target request endpoint. Section 2.4.1 538 @signature-params The signature metadata parameters for this 539 signature. Section 2.4.2 541 Additional specialty content identifiers MAY be defined and 542 registered in the HTTP Signatures Specialty Content Identifier 543 Registry. Section 5.3 545 2.4.1. Request Target 547 The request target endpoint, consisting of the request method and the 548 path and query of the effective request URI, is identified by the 549 "@request-target" identifier. 551 Its value is canonicalized as follows: 553 1. Take the lowercased HTTP method of the message. 555 2. Append a space " ". 557 3. Append the path and query of the request target of the message, 558 formatted according to the rules defined for the :path pseudo- 559 header in [HTTP2], Section 8.1.2.3. The resulting string is the 560 canonicalized value. 562 2.4.1.1. Canonicalization Examples 564 The following table contains non-normative example HTTP messages and 565 their canonicalized "@request-target" values. 567 +=========================+=================+ 568 |HTTP Message | @request-target | 569 +=========================+=================+ 570 | POST /?param=value HTTP/1.1| post | 571 | Host: www.example.com | /?param=value | 572 +-------------------------+-----------------+ 573 | POST /a/b HTTP/1.1 | post /a/b | 574 | Host: www.example.com | | 575 +-------------------------+-----------------+ 576 | GET http://www.example.com/a/ HTTP/1.1| get /a/ | 577 +-------------------------+-----------------+ 578 | GET http://www.example.com HTTP/1.1| get / | 579 +-------------------------+-----------------+ 580 | CONNECT server.example.com:80 HTTP/1.1| connect / | 581 | Host: server.example.com| | 582 +-------------------------+-----------------+ 583 | OPTIONS * HTTP/1.1 | options * | 584 | Host: server.example.com| | 585 +-------------------------+-----------------+ 587 Table 4: Non-normative examples of "@request-target" 588 canonicalization. 590 2.4.2. Signature Parameters 592 HTTP Message Signatures have metadata properties that provide 593 information regarding the signature's generation and/or verification. 595 The signature parameters special content is identified by the 596 "@signature-params" identifier. 598 Its canonicalized value is the serialization of the signature 599 parameters for this signature, including the covered content list 600 with all associated parameters. The following metadata properties 601 are defined: 603 Covered Content: 605 An ordered list of content identifiers for headers Section 2.1 and 606 specialty content Section 2.4 that indicates the metadata and 607 message content that is covered by the signature. This list MUST 608 NOT include the "@signature-params" specialty content identifier 609 itself. 611 Algorithm: 612 An HTTP Signature Algorithm defined in the HTTP Signature 613 Algorithms Registry defined in this document, represented as a 614 string. It describes the signing and verification algorithms for 615 the signature. 617 Key Material: 618 The key material required to create or verify the signature. 620 Creation Time: 621 A timestamp representing the point in time that the signature was 622 generated, represented as an integer. Sub-second precision is not 623 supported. A signature's Creation Time MAY be undefined, 624 indicating that it is unknown. 626 Expiration Time: 627 A timestamp representing the point in time at which the signature 628 expires, represented as an integer. An expired signature always 629 fails verification. A signature's Expiration Time MAY be 630 undefined, indicating that the signature does not expire. 632 The signature parameters are serialized using the rules in [RFC8941] 633 section 4 as follows: 635 1. Let the output be an empty string. 637 2. Serialize the content identifiers of the covered content as an 638 ordered "inner-list" according to [RFC8941] section 4.1.1.1 and 639 append this to the output. 641 3. Append the signature metadata as parameters according to 642 [RFC8941] section 4.1.1.2 in the any order, skipping fields that 643 are not available: 645 * "alg": Algorithm as an "sf-string" value. 647 * "keyid": Identifier for the key material as an "sf-string" 648 value. 650 * "created": Creation time as an "sf-integer" timestamp value. 652 * "expires": Expiration time as an "sf-integer" timestamp value. 654 Note that the "inner-list" serialization is used for the covered 655 content instead of the "sf-list" serialization in order to facilitate 656 this value's additional inclusion in the "Signature-Input" header's 657 dictionary, as discussed in Section 4.1. 659 This example shows a canonicalized value for the parameters of a 660 given signature: 662 # NOTE: '\' line wrapping per RFC 8792 663 ("@request-target" "host" "date" "cache-control" "x-empty-header" 664 "x-example"); keyid="test-key-a"; alg="rsa-pss-sha512"; \ 665 created=1402170695; expires=1402170995 667 Note that an HTTP message could contain multiple signatures, but only 668 the signature parameters used for the current signature are included. 670 2.4.2.1. Canonicalization Examples 672 Given the following signature parameters: 674 +==============+=========================================+ 675 | Property | Value | 676 +==============+=========================================+ 677 | Algorithm | rsa-pss-sha512 | 678 +--------------+-----------------------------------------+ 679 | Covered | "@request-target", "host", "date", | 680 | Content | "cache-control", "x-emptyheader", | 681 | | "x-example", "x-dictionary;key=b", | 682 | | "x-dictionary;key=a", "x-list;prefix=3" | 683 +--------------+-----------------------------------------+ 684 | Creation | 1402174295 | 685 | Time | | 686 +--------------+-----------------------------------------+ 687 | Expiration | 1402174595 | 688 | Time | | 689 +--------------+-----------------------------------------+ 690 | Verification | The public key provided in | 691 | Key Material | Appendix B.1.1 and identified by the | 692 | | "keyid" value "test-key-a". | 693 +--------------+-----------------------------------------+ 695 Table 5 697 The signature parameter value is defined as: 699 # NOTE: '\' line wrapping per RFC 8792 700 "@signature-params": ("@request-target" "host" "date" "cache-control" \ 701 "x-empty-header" "x-example" "x-dictionary";key=b \ 702 "x-dictionary";key=a "x-list";prefix=3); keyid="test-key-a"; \ 703 alg="rsa-pss-sha512"; created=1402170695; expires=1402170995 705 2.5. Creating the Signature Input String 707 The signature input is a US-ASCII string containing the content that 708 is covered by the signature. To create the signature input string, 709 the signer or verifier concatenates together entries for each 710 identifier in the signature's covered content and parameters using 711 the following algorithm: 713 1. Let the output be an empty string. 715 2. For each covered content item in the covered content list (in 716 order): 718 1. Append the identifier for the covered content serialized 719 according to the "content-identifier" rule. 721 2. Append a single colon "":"" 723 3. Append a single space "" "" 725 4. Append the covered content's canonicalized value, as defined 726 by the covered content type. Section 2.1 and Section 2.4 728 5. Append a single newline ""\\n"" 730 3. Append the signature parameters Section 2.4.2 as follows: 732 1. Append the identifier for the signature parameters serialized 733 according to the "content-identifier" rule, ""@signature- 734 params"" 736 2. Append a single colon "":"" 738 3. Append a single space "" "" 740 4. Append the signature parameters' canonicalized value as 741 defined in Section 2.4.2 743 4. Return the output string. 745 If covered content references an identifier that cannot be resolved 746 to a value in the message, the implementation MUST produce an error. 747 Such situations are included but not limited to: * The signer or 748 verifier does not understand the content identifier. * The identifier 749 identifies a header field that is not present in the message or whose 750 value is malformed. * The identifier is a Dictionary member 751 identifier that references a header field that is not present in the 752 message, is not a Dictionary Structured Field, or whose value is 753 malformed. * The identifier is a List Prefix member identifier that 754 references a header field that is not present in the message, is not 755 a List Structured Field, or whose value is malformed. * The 756 identifier is a Dictionary member identifier that references a member 757 that is not present in the header field value, or whose value is 758 malformed. E.g., the identifier is ""x-dictionary";key=c" and the 759 value of the "x-dictionary" header field is "a=1, b=2" * The 760 identifier is a List Prefix member identifier that specifies more 761 List members than are present the header field. E.g., the identifier 762 is ""x-list";prefix=3" and the value of the "x-list" header field is 763 "(1, 2)". 765 For the non-normative example Signature metadata in Table 6, the 766 corresponding Signature Input is: 768 # NOTE: '\' line wrapping per RFC 8792 769 "@request-target": get /foo 770 "host": example.org 771 "date": Tue, 07 Jun 2014 20:51:35 GMT 772 "cache-control": max-age=60, must-revalidate 773 "x-emptyheader": 774 "x-example": Example header with some whitespace. 775 "x-dictionary";key=b: 2 776 "x-dictionary";key=a: 1 777 "x-list";prefix=3: (a, b, c) 778 "@signature-params": ("@request-target" "host" "date" "cache-control" \ 779 "x-empty-header" "x-example" "x-dictionary";key=b \ 780 "x-dictionary";key=a "x-list";prefix=3); keyid="test-key-a"; \ 781 created=1402170695; expires=1402170995 783 Figure 1: Non-normative example Signature Input 785 3. HTTP Message Signatures 787 An HTTP Message Signature is a signature over a string generated from 788 a subset of the content in an HTTP message and metadata about the 789 signature itself. When successfully verified against an HTTP 790 message, it provides cryptographic proof that with respect to the 791 subset of content that was signed, the message is semantically 792 equivalent to the message for which the signature was generated. 794 3.1. Creating a Signature 796 In order to create a signature, a signer completes the following 797 process: 799 1. The signer chooses an HTTP signature algorithm and key material 800 for signing. The signer MUST choose key material that is 801 appropriate for the signature's algorithm, and that conforms to 802 any requirements defined by the algorithm, such as key size or 803 format. The mechanism by which the signer chooses the algorithm 804 and key material is out of scope for this document. 806 2. The signer sets the signature's creation time to the current 807 time. 809 3. If applicable, the signer sets the signature's expiration time 810 property to the time at which the signature is to expire. 812 4. The signer creates an ordered list of content identifiers 813 representing the message content and signature metadata to be 814 covered by the signature, and assigns this list as the 815 signature's Covered Content. 817 * Each covered content identifier MUST reference either an HTTP 818 header or a specialty content field listed in Section 2.4 or 819 its associated registry. 821 * Signers SHOULD include "@request-target" in the covered 822 content list list. 824 * Signers SHOULD include a date stamp in some form, such as 825 using the "date" header. Alternatively, the "created" 826 signature metadata parameter can fulfil this role. 828 * Further guidance on what to include in this list and in what 829 order is out of scope for this document. However, note that 830 the list order is significant and once established for a given 831 signature it MUST be preserved for that signature. 833 * Note that the "@signature-params" specialty identifier is not 834 explicitly listed in the list of covered content identifiers, 835 because it is required to always be present as the last line 836 in the signature input. This ensures that a signature always 837 covers its own metadata. 839 5. The signer creates the signature input string. Section 2.5 840 6. The signer signs the signature input with the chosen signing 841 algorithm using the key material chosen by the signer. Several 842 signing algorithms are defined in in Section 3.3. 844 7. The signer then encodes the result of that operation as a 845 Base64-encoded string [RFC4648]. This string is the signature 846 output value. 848 For example, given the following HTTP message: 850 GET /foo HTTP/1.1 851 Host: example.org 852 Date: Sat, 07 Jun 2014 20:51:35 GMT 853 X-Example: Example header 854 with some whitespace. 855 X-EmptyHeader: 856 X-Dictionary: a=1, b=2 857 X-List: (a b c d) 858 Cache-Control: max-age=60 859 Cache-Control: must-revalidate 861 The following table presents a non-normative example of metadata 862 values that a signer may choose: 864 +==============+=========================================+ 865 | Property | Value | 866 +==============+=========================================+ 867 | Covered | "@request-target", "host", "date", | 868 | Content | "cache-control", "x-emptyheader", | 869 | | "x-example", "x-dictionary;key=b", | 870 | | "x-dictionary;key=a", "x-list;prefix=3" | 871 +--------------+-----------------------------------------+ 872 | Creation | 1402174295 | 873 | Time | | 874 +--------------+-----------------------------------------+ 875 | Expiration | 1402174595 | 876 | Time | | 877 +--------------+-----------------------------------------+ 878 | Verification | The public key provided in | 879 | Key Material | Appendix B.1.1 and identified by the | 880 | | "keyid" value "test-key-a". | 881 +--------------+-----------------------------------------+ 883 Table 6: Non-normative example metadata values 885 For the non-normative example signature metadata and signature input 886 in Figure 1, the corresponding signature value is: 888 # NOTE: '\' line wrapping per RFC 8792 889 K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUeZx/Kdrq32DrfakQ6b\ 890 PsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibeoHyqU/yCjphSmEdd7WD+z\ 891 rchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4CaB8X/I5/+HLZLGvDiezqi6/7\ 892 p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg1Q7MpWYZs0soHjttq0uLIA3DIbQfL\ 893 iIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZgFquQrXRlmYOh+Hx5D9fJkXcXe5tmAg== 895 Figure 2: Non-normative example signature value 897 3.2. Verifying a Signature 899 In order to verify a signature, a verifier MUST follow the following 900 algorithm: 902 1. Examine the signature's parameters to confirm that the signature 903 meets the requirements described in this document, as well as any 904 additional requirements defined by the application such as which 905 contents are required to be covered by the signature. 906 Section 3.2.1 908 2. Determine the verification key material for this signature. If 909 the key material is known through external means such as static 910 configuration or external protocol negotiation, the verifier will 911 use that. If the key is identified in the signature parameters, 912 the verifier will dereference this to appropriate key material to 913 use with the signature. The verifier has to determine the 914 trustworthiness of the key material for the context in which the 915 signature is presented. 917 3. Determine the algorithm to apply for verification: 919 1. If the algorithm is known through external means such as 920 static configuration or external protocol negotiation, the 921 verifier will use this algorithm. 923 2. If the algorithm is explicitly stated in the signature 924 parameters using a value from the HTTP Message Signatures 925 registry, the verifier will use the referenced algorithm. 927 3. If the algorithm can be determined from the keying material, 928 such as through an algorithm field on the key value itself, 929 the verifier will use this algorithm. 931 4. Use the received HTTP message and the signature's metadata to 932 recreate the signature input, using the process described in 933 Section 2.5. The value of the "@signature-params" input is the 934 value of the SignatureInput header field for this signature 935 serialized according to the rules described in Section 2.4.2, not 936 including the signature's label from the SignatureInput header. 938 5. If the key material is appropriate for the algorithm, apply the 939 verification algorithm to the signature, signature input, 940 signature parameters, key material, and algorithm. The results 941 of the verification algorithm function are the final results of 942 the signature verification. Several algorithms are defined in 943 Section 3.3. 945 If any of the above steps fail, the signature validation fails. 947 3.2.1. Enforcing Application Requirements 949 The verification requirements specified in this document are intended 950 as a baseline set of restrictions that are generally applicable to 951 all use cases. Applications using HTTP Message Signatures MAY impose 952 requirements above and beyond those specified by this document, as 953 appropriate for their use case. 955 Some non-normative examples of additional requirements an application 956 might define are: 958 * Requiring a specific set of header fields to be signed (e.g., 959 Authorization, Digest). 961 * Enforcing a maximum signature age. 963 * Prohibiting the use of certain algorithms, or mandating the use of 964 an algorithm. 966 * Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 967 bits). 969 Application-specific requirements are expected and encouraged. When 970 an application defines additional requirements, it MUST enforce them 971 during the signature verification process, and signature verification 972 MUST fail if the signature does not conform to the application's 973 requirements. 975 Applications MUST enforce the requirements defined in this document. 976 Regardless of use case, applications MUST NOT accept signatures that 977 do not conform to these requirements. 979 3.3. Signature Algorithm Methods 981 HTTP Message signatures MAY use any cryptographic digital signature 982 or MAC method that allows for the signing of the signature input 983 string. This section contains several common algorithm parameters 984 that can be communicated through the algorithm signature parameter 985 defined in Section 2.4.2, by reference to the key material, or 986 through agreement between the signer and verifier. 988 Signatures are generated from and verified against the byte values of 989 the signature input string defined in Section 2.5. 991 3.3.1. RSASSA-PSS using SHA-512 993 To sign using this algorithm, the signer applies the "RSASSA-PSS-SIGN 994 (K, M)" function [RFC8017] with the signer's private signing key 995 ("K") and the signature input string ("M") Section 2.5. The hash 996 SHA-512 [RFC6234] is applied to the signature input string to create 997 the digest content to which the digital signature is applied. The 998 resulting signed content ("S") is Base64-encoded as described in 999 Section 3.1. The resulting encoded value is the HTTP message 1000 signature output. 1002 To verify using this algorithm, the verifier applies the "RSASSA-PSS- 1003 VERIFY ((n, e), M, S)" function [RFC8017] using the public key 1004 material ("(n, e)"). The verifier re-creates the signature input 1005 string ("M") from the received message, as defined in Section 2.5. 1006 The hash function SHA-512 [RFC6234] is applied to the signature input 1007 string to create the digest content to which the verification 1008 function is applied. The verifier decodes the HTTP message signature 1009 from Base64 as described in Section 3.2 to give the http message 1010 signature to be verified ("S"). The results of the verification 1011 function are compared to the http message signature to determine if 1012 the signature presented is valid. 1014 3.3.2. RSASSA-PKCS1-v1_5 using SHA-256 1016 To sign using this algorithm, the signer applies the "RSASSA- 1017 PKCS1-V1_5-SIGN (K, M)" function [RFC8017] to signer's private 1018 signing key ("K") and the signature input string ("M") Section 2.5. 1019 The hash SHA-256 [RFC6234] is applied to the signature input string 1020 to create the digest content to which the digital signature is 1021 applied. The resulting signed content ("S") is Base64-encoded as 1022 described in Section 3.1. The resulting encoded value is the HTTP 1023 message signature output. 1025 To verify using this algorithm, the verifier applies the "RSASSA- 1026 PKCS1-V1_5-VERIFY ((n, e), M, S)" function [RFC8017] using the public 1027 key material ("(n, e)"). The verifier re-creates the signature input 1028 string ("M") from the received message, as defined in Section 2.5. 1029 The hash function SHA-256 [RFC6234] is applied to the signature input 1030 string to create the digest content to which the verification 1031 function is applied. The verifier decodes the HTTP message signature 1032 from Base64 as described in Section 3.2 to give the http message 1033 signature to be verified ("S"). The results of the verification 1034 function are compared to the http message signature to determine if 1035 the signature presented is valid. 1037 3.3.3. HMAC using SHA-256 1039 To sign and verify using this algorithm, the signer applies the 1040 "HMAC" function [RFC2104] with the shared signing key ("K") and the 1041 signature input string ("text") Section 2.5. The hash function 1042 SHA-256 [RFC6234] is applied to the signature input string to create 1043 the digest content to which the HMAC is applied, giving the signature 1044 result. 1046 For signing, the resulting signed content is Base64-encoded as 1047 described in Section 3.1. The resulting encoded value is the HTTP 1048 message signature output. 1050 For verification, the verifier decodes the HTTP message signature 1051 from Base64 as described in Section 3.2 to give the signature to be 1052 compared to the output of the HMAC function. The results of the 1053 comparison determine the validity of the signature presented. 1055 3.3.4. ECDSA using curve P-256 DSS and SHA-256 1057 To sign using this algorithm, the signer applies the "ECDSA" 1058 algorithm [FIPS186-4] using curve P-256 with signer's private signing 1059 key and the signature input string Section 2.5. The hash function 1060 SHA-256 [RFC6234] is applied to the signature input string to create 1061 the digest content to which the digital signature is applied. The 1062 resulting signed content is Base64-encoded as described in 1063 Section 3.1. The resulting encoded value is the HTTP message 1064 signature output. 1066 To verify using this algorithm, the verifier applies the "ECDSA" 1067 algorithm [FIPS186-4] using the public key material. The verifier 1068 re-creates the signature input string defined in Section 2.5. The 1069 hash function SHA-256 [RFC6234] is applied to the signature input 1070 string to create the digest content to which the verification 1071 function is applied. The verifier decodes the HTTP message signature 1072 from Base64 as described in Section 3.2 to give the signature to be 1073 verified. The results of the verification function are compared to 1074 the http message signature to determine if the signature presented is 1075 valid. 1077 3.3.5. JSON Web Signature (JWS) algorithms 1079 If the signing algorithm is a JOSE signing algorithm from the JSON 1080 Web Signature and Encryption Algorithms Registry established by 1081 [RFC7518], the JWS algorithm definition determines the signature and 1082 hashing algorithms to apply for both signing and verification. 1084 For both signing and verification, the HTTP messages signature input 1085 string Section 2.5 is used as the entire "JWS Signing Input". The 1086 JWS Header defined in [RFC7517] is not used, nor is the input string 1087 first encoded in Base64 before applying the algorithm. 1089 The JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm 1090 with a JOSE Implementation Requirement of "Prohibited". 1092 4. Including a Message Signature in a Message 1094 Message signatures can be included within an HTTP message via the 1095 "Signature-Input" and "Signature" HTTP header fields, both defined 1096 within this specification. The "Signature" HTTP header field 1097 contains signature values, while the "Signature-Input" HTTP header 1098 field identifies the Covered Content and metadata that describe how 1099 each signature was generated. 1101 4.1. The 'Signature-Input' HTTP Header 1103 The "Signature-Input" HTTP header field is a Dictionary Structured 1104 Header [RFC8941] containing the metadata for zero or more message 1105 signatures generated from content within the HTTP message. Each 1106 member describes a single message signature. The member's name is an 1107 identifier that uniquely identifies the message signature within the 1108 context of the HTTP message. The member's value is the serialization 1109 of the covered content including all signature metadata parameters, 1110 using the serialization process defined in Section 2.4.2. 1112 # NOTE: '\' line wrapping per RFC 8792 1113 Signature-Input: sig1=("@request-target" "host" "date" 1114 "cache-control" "x-empty-header" "x-example"); keyid="test-key-a"; 1115 alg="rsa-pss-sha512"; created=1402170695; expires=1402170995 1117 To facilitate signature validation, the "Signature-Input" header MUST 1118 contain the same serialization value used in generating the signature 1119 input. 1121 4.2. The 'Signature' HTTP Header 1123 The "Signature" HTTP header field is a Dictionary Structured Header 1124 [RFC8941] containing zero or more message signatures generated from 1125 content within the HTTP message. Each member's name is a signature 1126 identifier that is present as a member name in the "Signature-Input" 1127 Structured Header within the HTTP message. Each member's value is a 1128 Byte Sequence containing the signature value for the message 1129 signature identified by the member name. Any member in the 1130 "Signature" HTTP header field that does not have a corresponding 1131 member in the HTTP message's "Signature-Input" HTTP header field MUST 1132 be ignored. 1134 # NOTE: '\' line wrapping per RFC 8792 1135 Signature: sig1=:K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUe\ 1136 Zx/Kdrq32DrfakQ6bPsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibe\ 1137 oHyqU/yCjphSmEdd7WD+zrchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4\ 1138 CaB8X/I5/+HLZLGvDiezqi6/7p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg\ 1139 1Q7MpWYZs0soHjttq0uLIA3DIbQfLiIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZg\ 1140 FquQrXRlmYOh+Hx5D9fJkXcXe5tmAg==: 1142 4.3. Examples 1144 The following is a non-normative example of "Signature-Input" and 1145 "Signature" HTTP header fields representing the signature in 1146 Figure 2: 1148 # NOTE: '\' line wrapping per RFC 8792 1150 Signature-Input: sig1=("@request-target" "host" "date" 1151 "cache-control" "x-empty-header" "x-example"); keyid="test-key-a"; 1152 alg="rsa-pss-sha512"; created=1402170695; expires=1402170995 1153 Signature: sig1=:K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUe\ 1154 Zx/Kdrq32DrfakQ6bPsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibe\ 1155 oHyqU/yCjphSmEdd7WD+zrchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4\ 1156 CaB8X/I5/+HLZLGvDiezqi6/7p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg\ 1157 1Q7MpWYZs0soHjttq0uLIA3DIbQfLiIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZg\ 1158 FquQrXRlmYOh+Hx5D9fJkXcXe5tmAg==: 1160 Since "Signature-Input" and "Signature" are both defined as 1161 Dictionary Structured Headers, they can be used to easily include 1162 multiple signatures within the same HTTP message. For example, a 1163 signer may include multiple signatures signing the same content with 1164 different keys and/or algorithms to support verifiers with different 1165 capabilities, or a reverse proxy may include information about the 1166 client in header fields when forwarding the request to a service 1167 host, and may also include a signature over those fields and the 1168 client's signature. The following is a non-normative example of 1169 header fields a reverse proxy might add to a forwarded request that 1170 contains the signature in the above example: 1172 # NOTE: '\' line wrapping per RFC 8792 1174 X-Forwarded-For: 192.0.2.123 1175 Signature-Input: reverse_proxy_sig=("host" "date" 1176 "signature";key=sig1 "x-forwarded-for"); keyid="test-key-a"; 1177 alg="rsa-pss-sha512"; created=1402170695; expires=1402170695 1178 Signature: reverse_proxy_sig=:ON3HsnvuoTlX41xfcGWaOEVo1M3bJDRBOp0Pc/O\ 1179 jAOWKQn0VMY0SvMMWXS7xG+xYVa152rRVAo6nMV7FS3rv0rR5MzXL8FCQ2A35DCEN\ 1180 LOhEgj/S1IstEAEFsKmE9Bs7McBsCtJwQ3hMqdtFenkDffSoHOZOInkTYGafkoy78\ 1181 l1VZvmb3Y4yf7McJwAvk2R3gwKRWiiRCw448Nt7JTWzhvEwbh7bN2swc/v3NJbg/w\ 1182 JYyYVbelZx4IywuZnYFxgPl/qvqbAjeEVvaLKLgSMr11y+uzxCHoMnDUnTYhMrmOT\ 1183 4O8lBLfRFOcoJPKBdoKg9U0a96U2mUug1bFOozEVYFg==: 1185 5. IANA Considerations 1187 5.1. HTTP Signature Algorithms Registry 1189 This document defines HTTP Signature Algorithms, for which IANA is 1190 asked to create and maintain a new registry titled "HTTP Signature 1191 Algorithms". Initial values for this registry are given in 1192 Section 5.1.2. Future assignments and modifications to existing 1193 assignment are to be made through the Expert Review registration 1194 policy [RFC8126] and shall follow the template presented in 1195 Section 5.1.1. 1197 5.1.1. Registration Template 1199 Algorithm Name: 1200 An identifier for the HTTP Signature Algorithm. The name MUST be 1201 an ASCII string consisting only of lower-case characters (""a"" - 1202 ""z""), digits (""0"" - ""9""), and hyphens (""-""), and SHOULD 1203 NOT exceed 20 characters in length. The identifier MUST be unique 1204 within the context of the registry. 1206 Status: 1208 A brief text description of the status of the algorithm. The 1209 description MUST begin with one of "Active" or "Deprecated", and 1210 MAY provide further context or explanation as to the reason for 1211 the status. 1213 Description: 1214 A brief description of the algorithm used to sign the signature 1215 input string. 1217 Specification document(s): 1218 Reference to the document(s) that specify the token endpoint 1219 authorization method, preferably including a URI that can be used 1220 to retrieve a copy of the document(s). An indication of the 1221 relevant sections may also be included but is not required. 1223 5.1.2. Initial Contents 1225 5.1.2.1. rsa-pss-sha512 1227 Algorithm Name: 1228 "rsa-pss-sha512" 1230 Status: 1231 Active 1233 Definition: 1234 RSASSA-PSS using SHA-256 1236 Specification document(s): 1237 [[This document]] Section 3.3.1 1239 5.1.2.2. rsa-v1_5-sha256 1241 Algorithm Name: 1242 "rsa-v1_5-sha256" 1244 Status: 1245 Active 1247 Description: 1248 RSASSA-PKCS1-v1_5 using SHA-256 1250 Specification document(s): 1251 [[This document]] Section 3.3.2 1253 5.1.2.3. hmac-sha256 1255 Algorithm Name: 1257 "hmac-sha256" 1259 Status: 1260 Active 1262 Description: 1263 HMAC using SHA-256 1265 Specification document(s): 1266 [[This document]] Section 3.3.3 1268 5.1.2.4. ecdsa-p256-sha256 1270 Algorithm Name: 1271 "ecdsa-p256-sha256" 1273 Status: 1274 Active 1276 Description: 1277 ECDSA using curve P-256 DSS and SHA-256 1279 Specification document(s): 1280 [[This document]] Section 3.3.4 1282 5.2. HTTP Signature Metadata Parameters Registry 1284 This document defines the "Signature-Input" Structured Header, whose 1285 member values may have parameters containing metadata about a message 1286 signature. IANA is asked to create and maintain a new registry 1287 titled "HTTP Signature Metadata Parameters" to record and maintain 1288 the set of parameters defined for use with member values in the 1289 "Signature-Input" Structured Header. Initial values for this 1290 registry are given in Section 5.2.2. Future assignments and 1291 modifications to existing assignments are to be made through the 1292 Expert Review registration policy [RFC8126] and shall follow the 1293 template presented in Section 5.2.1. 1295 5.2.1. Registration Template 1297 5.2.2. Initial Contents 1299 The table below contains the initial contents of the HTTP Signature 1300 Metadata Parameters Registry. Each row in the table represents a 1301 distinct entry in the registry. 1303 +=========+========+================================+ 1304 | Name | Status | Reference(s) | 1305 +=========+========+================================+ 1306 | alg | Active | Section 2.4.2 of this document | 1307 +---------+--------+--------------------------------+ 1308 | created | Active | Section 2.4.2 of this document | 1309 +---------+--------+--------------------------------+ 1310 | expires | Active | Section 2.4.2 of this document | 1311 +---------+--------+--------------------------------+ 1312 | keyid | Active | Section 2.4.2 of this document | 1313 +---------+--------+--------------------------------+ 1315 Table 7: Initial contents of the HTTP Signature 1316 Metadata Parameters Registry. 1318 5.3. HTTP Signature Specialty Content Identifiers Registry 1320 This document defines a method for canonicalizing HTTP message 1321 content, including content that can be generated from the context of 1322 the HTTP message outside of the HTTP headers. This content is 1323 identified by a unique key. IANA is asked to create and maintain a 1324 new registry typed "HTTP Signature Specialty Content Identifiers" to 1325 record and maintain the set of non-header content identifiers and 1326 their canonicalization method. Initial values for this registry are 1327 given in Section 5.3.2. Future assignments and modifications to 1328 existing assignments are to be made through the Expert Review 1329 registration policy [RFC8126] and shall follow the template presented 1330 in Section 5.3.1. 1332 5.3.1. Registration Template 1334 5.3.2. Initial Contents 1336 The table below contains the initial contents of the HTTP Signature 1337 Specialty Content Identifiers Registry. 1339 +===================+========+================================+ 1340 | Name | Status | Reference(s) | 1341 +===================+========+================================+ 1342 | @request-target | Active | Section 2.4.1 of this document | 1343 +-------------------+--------+--------------------------------+ 1344 | @signature-params | Active | Section 2.4.2 of this document | 1345 +-------------------+--------+--------------------------------+ 1347 Table 8: Initial contents of the HTTP Signature Specialty 1348 Content Identifiers Registry. 1350 6. Security Considerations 1352 (( TODO: need to dive deeper on this section; not sure how much of 1353 what's referenced below is actually applicable, or if it covers 1354 everything we need to worry about. )) 1356 (( TODO: Should provide some recommendations on how to determine what 1357 content needs to be signed for a given use case. )) 1359 There are a number of security considerations to take into account 1360 when implementing or utilizing this specification. A thorough 1361 security analysis of this protocol, including its strengths and 1362 weaknesses, can be found in [WP-HTTP-Sig-Audit]. 1364 7. References 1366 7.1. Normative References 1368 [FIPS186-4] 1369 "Digital Signature Standard (DSS)", 2013, 1370 . 1373 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1374 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1375 DOI 10.17487/RFC7540, May 2015, 1376 . 1378 [MESSAGING] 1379 Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1380 Protocol (HTTP/1.1): Message Syntax and Routing", 1381 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1382 . 1384 [POSIX.1] "The Open Group Base Specifications Issue 7, 2018 1385 edition", 2018, 1386 . 1388 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1389 Hashing for Message Authentication", RFC 2104, 1390 DOI 10.17487/RFC2104, February 1997, 1391 . 1393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1394 Requirement Levels", BCP 14, RFC 2119, 1395 DOI 10.17487/RFC2119, March 1997, 1396 . 1398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1400 May 2017, . 1402 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 1403 "Handling Long Lines in Content of Internet-Drafts and 1404 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 1405 . 1407 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 1408 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 1409 . 1411 [SEMANTICS] 1412 Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1413 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1414 DOI 10.17487/RFC7231, June 2014, 1415 . 1417 7.2. Informative References 1419 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1420 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1421 . 1423 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1424 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1425 DOI 10.17487/RFC6234, May 2011, 1426 . 1428 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1429 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1430 . 1432 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1433 DOI 10.17487/RFC7517, May 2015, 1434 . 1436 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1437 DOI 10.17487/RFC7518, May 2015, 1438 . 1440 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1441 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1442 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1443 . 1445 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1446 Writing an IANA Considerations Section in RFCs", BCP 26, 1447 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1448 . 1450 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1451 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1452 . 1454 [WP-HTTP-Sig-Audit] 1455 "Security Considerations for HTTP Signatures", 2013, 1456 . 1459 Appendix A. Detecting HTTP Message Signatures 1461 There have been many attempts to create signed HTTP messages in the 1462 past, including other non-standard definitions of the "Signature" 1463 header used within this specification. It is recommended that 1464 developers wishing to support both this specification and other 1465 historial drafts do so carefully and deliberately, as 1466 incompatibilities between this specification and various versions of 1467 other drafts could lead to problems. 1469 It is recommended that implementers first detect and validate the 1470 "Signature-Input" header defined in this specification to detect that 1471 this standard is in use and not an alternative. If the "Signature- 1472 Input" header is present, all "Signature" headers can be parsed and 1473 interpreted in the context of this draft. 1475 Appendix B. Examples 1477 B.1. Example Keys 1479 This section provides cryptographic keys that are referenced in 1480 example signatures throughout this document. These keys MUST NOT be 1481 used for any purpose other than testing. 1483 B.1.1. Example Key RSA test 1485 The following key is a 2048-bit RSA public and private key pair: 1487 -----BEGIN RSA PUBLIC KEY----- 1488 MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw 1489 WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq 1490 MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg 1491 kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P 1492 uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ 1493 PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB 1494 -----END RSA PUBLIC KEY----- 1496 -----BEGIN RSA PRIVATE KEY----- 1497 MIIEqAIBAAKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsP 1498 BRrwWEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsd 1499 JKFqMGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75 1500 jfZgkne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKI 1501 lE0PuKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZ 1502 SFlQPSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQABAoIBAG/JZuSWdoVHbi56 1503 vjgCgkjg3lkO1KrO3nrdm6nrgA9P9qaPjxuKoWaKO1cBQlE1pSWp/cKncYgD5WxE 1504 CpAnRUXG2pG4zdkzCYzAh1i+c34L6oZoHsirK6oNcEnHveydfzJL5934egm6p8DW 1505 +m1RQ70yUt4uRc0YSor+q1LGJvGQHReF0WmJBZHrhz5e63Pq7lE0gIwuBqL8SMaA 1506 yRXtK+JGxZpImTq+NHvEWWCu09SCq0r838ceQI55SvzmTkwqtC+8AT2zFviMZkKR 1507 Qo6SPsrqItxZWRty2izawTF0Bf5S2VAx7O+6t3wBsQ1sLptoSgX3QblELY5asI0J 1508 YFz7LJECgYkAsqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOM 1509 cCNq8SyYbTqgnWlB9ZfcAm/cFpA8tYci9m5vYK8HNxQr+8FS3Qo8N9RJ8d0U5Csw 1510 DzMYfRghAfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1 1511 mwJ5AL0pYF0G7x81prlARURwHo0Yf52kEw1dxpx+JXER7hQRWQki5/NsUEtv+8RT 1512 qn2m6qte5DXLyn83b1qRscSdnCCwKtKWUug5q2ZbwVOCJCtmRwmnP131lWRYfj67 1513 B/xJ1ZA6X3GEf4sNReNAtaucPEelgR2nsN0gKQKBiGoqHWbK1qYvBxX2X3kbPDkv 1514 9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn 1515 f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo 1516 81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa 1517 /2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG 1518 IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m 1519 qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P 1520 WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ 1521 EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0= 1522 -----END RSA PRIVATE KEY----- 1524 B.2. Example keyid Values 1526 The table below maps example "keyid" values to associated algorithms 1527 and/or keys. These are example mappings that are valid only within 1528 the context of examples in examples within this and future documents 1529 that reference this section. Unless otherwise specified, within the 1530 context of examples it should be assumed that the signer and verifier 1531 understand these "keyid" mappings. These "keyid" values are not 1532 reserved, and deployments are free to use them, with these 1533 associations or others. 1535 +============+=================+==========================+ 1536 | keyid | Algorithm | Verification Key | 1537 +============+=================+==========================+ 1538 | test-key-a | rsa-pss-sha512 | The public key specified | 1539 | | | in Appendix B.1.1 | 1540 +------------+-----------------+--------------------------+ 1541 | test-key-b | rsa-v1_5-sha256 | The public key specified | 1542 | | | in Appendix B.1.1 | 1543 +------------+-----------------+--------------------------+ 1545 Table 9 1547 B.3. Test Cases 1549 This section provides non-normative examples that may be used as test 1550 cases to validate implementation correctness. These examples are 1551 based on the following HTTP message: 1553 POST /foo?param=value&pet=dog HTTP/1.1 1554 Host: example.com 1555 Date: Tue, 07 Jun 2014 20:51:35 GMT 1556 Content-Type: application/json 1557 Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 1558 Content-Length: 18 1560 {"hello": "world"} 1562 B.3.1. Signature Verification 1564 B.3.1.1. Minimal Signature Header using rsa-pss-sha512 1566 This presents a minimal "Signature-Input" and "Signature" header for 1567 a signature using the "rsa-pss-sha512" algorithm: 1569 # NOTE: '\' line wrapping per RFC 8792 1571 Signature: sig1=("date"); alg="rsa-pss-sha512"; keyid="test-key-b" 1572 Signature: sig1=:HtXycCl97RBVkZi66ADKnC9c5eSSlb57GnQ4KFqNZplOpNfxqk62\ 1573 JzZ484jXgLvoOTRaKfR4hwyxlcyb+BWkVasApQovBSdit9Ml/YmN2IvJDPncrlhPD\ 1574 VDv36Z9/DiSO+RNHD7iLXugdXo1+MGRimW1RmYdenl/ITeb7rjfLZ4b9VNnLFtVWw\ 1575 rjhAiwIqeLjodVImzVc5srrk19HMZNuUejK6I3/MyN3+3U8tIRW4LWzx6ZgGZUaEE\ 1576 P0aBlBkt7Fj0Tt5/P5HNW/Sa/m8smxbOHnwzAJDa10PyjzdIbywlnWIIWtZKPPsoV\ 1577 oKVopUWEU3TNhpWmaVhFrUL/O6SN3w==: 1579 The corresponding signature metadata derived from this header field 1580 is: 1582 +===========================+==========================+ 1583 | Property | Value | 1584 +===========================+==========================+ 1585 | Algorithm | rsa-pss-sha512 | 1586 +---------------------------+--------------------------+ 1587 | Covered Content | date | 1588 +---------------------------+--------------------------+ 1589 | Creation Time | Undefined | 1590 +---------------------------+--------------------------+ 1591 | Expiration Time | Undefined | 1592 +---------------------------+--------------------------+ 1593 | Verification Key Material | The public key specified | 1594 | | in Appendix B.1.1. | 1595 +---------------------------+--------------------------+ 1597 Table 10 1599 The corresponding Signature Input is: 1601 "date": Tue, 07 Jun 2014 20:51:35 GMT 1602 "@signature-params": ("date"); alg="rsa-pss-sha512"; keyid="test-key-b" 1604 Acknowledgements 1606 This specification was initially based on the draft-cavage-http- 1607 signatures internet draft. The editors would like to thank the 1608 authors of that draft, Mark Cavage and Manu Sporny, for their work on 1609 that draft and their continuing contributions. 1611 The editor would also like to thank the following individuals for 1612 feedback on and implementations of the draft-cavage-http-signatures 1613 draft (in alphabetical order): Mark Adamcin, Mark Allen, Paul 1614 Annesley, Karl Boehlmark, Stephane Bortzmeyer, Sarven Capadisli, Liam 1615 Dennehy, ductm54, Stephen Farrell, Phillip Hallam-Baker, Eric Holmes, 1616 Andrey Kislyuk, Adam Knight, Dave Lehn, Dave Longley, James H. 1617 Manger, Ilari Liusvaara, Mark Nottingham, Yoav Nir, Adrian Palmer, 1618 Lucas Pardue, Roberto Polli, Julian Reschke, Michael Richardson, 1619 Wojciech Rygielski, Adam Scarr, Cory J. Slep, Dirk Stein, Henry 1620 Story, Lukasz Szewc, Chris Webber, and Jeffrey Yasskin 1622 Document History 1624 _RFC EDITOR: please remove this section before publication_ 1626 * draft-ietf-httpbis-message-signatures 1628 - -03 1629 o Clarified signing and verification processes. 1631 o Updated algorithm and key selection method. 1633 o Clearly defined core algorithm set. 1635 o Defined JOSE signature mapping process. 1637 o Removed legacy signature methods. 1639 o Define signature parameters separately from "signature" 1640 object model. 1642 o Define serialization values for signature-input header based 1643 on signature input. 1645 - -02 1647 o Removed editorial comments on document sources. 1649 o Removed in-document issues list in favor of tracked issues. 1651 o Replaced unstructured "Signature" header with "Signature- 1652 Input" and "Signature" Dictionary Structured Header Fields. 1654 o Defined content identifiers for individual Dictionary 1655 members, e.g., ""x-dictionary-field";key=member-name". 1657 o Defined content identifiers for first N members of a List, 1658 e.g., ""x-list-field":prefix=4". 1660 o Fixed up examples. 1662 o Updated introduction now that it's adopted. 1664 o Defined specialty content identifiers and a means to extend 1665 them. 1667 o Required signature parameters to be included in signature. 1669 o Added guidance on backwards compatibility, detection, and 1670 use of signature methods. 1672 - -01 1674 o Strengthened requirement for content identifiers for header 1675 fields to be lower-case (changed from SHOULD to MUST). 1677 o Added real example values for Creation Time and Expiration 1678 Time. 1680 o Minor editorial corrections and readability improvements. 1682 - -00 1684 o Initialized from draft-richanna-http-message-signatures-00, 1685 following adoption by the working group. 1687 * draft-richanna-http-message-signatures 1689 - -00 1691 o Converted to xml2rfc v3 and reformatted to comply with RFC 1692 style guides. 1694 o Removed Signature auth-scheme definition and related 1695 content. 1697 o Removed conflicting normative requirements for use of 1698 algorithm parameter. Now MUST NOT be relied upon. 1700 o Removed Extensions appendix. 1702 o Rewrote abstract and introduction to explain context and 1703 need, and challenges inherent in signing HTTP messages. 1705 o Rewrote and heavily expanded algorithm definition, retaining 1706 normative requirements. 1708 o Added definitions for key terms, referenced RFC 7230 for 1709 HTTP terms. 1711 o Added examples for canonicalization and signature generation 1712 steps. 1714 o Rewrote Signature header definition, retaining normative 1715 requirements. 1717 o Added default values for algorithm and expires 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 Email: msporny@digitalbazaar.com 1754 URI: https://manu.sporny.org/