From c974263f167d35b2eb932827ac8e52f1c913e230 Mon Sep 17 00:00:00 2001 From: Annabelle Backman Date: Thu, 23 Jul 2020 16:20:08 -0700 Subject: [PATCH 1/5] Added actual Integer String values for Creation Time and Expiration Time example in Table 2. --- draft-ietf-httpbis-message-signatures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-message-signatures.md b/draft-ietf-httpbis-message-signatures.md index dda35da461..df2062a4b1 100644 --- a/draft-ietf-httpbis-message-signatures.md +++ b/draft-ietf-httpbis-message-signatures.md @@ -332,7 +332,7 @@ For example, given the following HTTP message: ~~~ GET /foo HTTP/1.1 Host: example.org -Date: Tue, 07 Jun 2014 20:51:35 GMT +Date: Sat, 07 Jun 2014 20:51:35 GMT X-Example: Example header with some whitespace. X-EmptyHeader: @@ -346,8 +346,8 @@ The following table presents a non-normative example of metadata values that a s |--- |--- | |Algorithm|`rsa-256`| |Covered Content|`(request-target)`, `(created)`, `host`, `date`, `cache-contol`, `x-emptyheader`, `x-example`| -|Creation Time|Equal to the value specified in the `Date` header field.| -|Expiration Time|Equal to the Creation Time plus five minutes.| +|Creation Time|`1402174295`| +|Expiration Time|`1402174595`| |Verification Key Material|The public key provided in and identified by the `keyId` value "test-key-b".| {: title="Non-normative example metadata values" #example-metadata} From faaaaff7dbc35e4ba9ae5e12406e1210b5c8dee5 Mon Sep 17 00:00:00 2001 From: Annabelle Backman Date: Thu, 23 Jul 2020 16:27:45 -0700 Subject: [PATCH 2/5] Broke Covered Content list requirements into bullets for readability. --- draft-ietf-httpbis-message-signatures.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-message-signatures.md b/draft-ietf-httpbis-message-signatures.md index df2062a4b1..d64481107b 100644 --- a/draft-ietf-httpbis-message-signatures.md +++ b/draft-ietf-httpbis-message-signatures.md @@ -324,7 +324,12 @@ The following sections describe each of these steps in detail. 4. The signer sets the signature's Expiration Time property to the time at which the signature is to expire, or to undefined if the signature will not expire. -5. The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's Covered Content. Each identifier MUST be one of those defined in Section 2. This list MUST NOT be empty, as this would result in creating a signature over the empty string. If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request-target) in the list. If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list. Further guidance on what to include in this list and in what order is out of scope for this document. However, the list order is significant and once established for a given signature it MUST be preserved for that signature. +5. The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's Covered Content. + * Each identifier MUST be one of those defined in Section 2. + * This list MUST NOT be empty, as this would result in creating a signature over the empty string. + * If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request-target) in the list. + * If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list. + * Further guidance on what to include in this list and in what order is out of scope for this document. However, the list order is significant and once established for a given signature it MUST be preserved for that signature. For example, given the following HTTP message: From 9320e41472e4a15783e81d4fa40fa375b30d7b94 Mon Sep 17 00:00:00 2001 From: Annabelle Backman Date: Thu, 23 Jul 2020 16:58:21 -0700 Subject: [PATCH 3/5] Require examining Creation Time and Expiration Time against verifier's rules. --- draft-ietf-httpbis-message-signatures.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-message-signatures.md b/draft-ietf-httpbis-message-signatures.md index d64481107b..c3c5843fe1 100644 --- a/draft-ietf-httpbis-message-signatures.md +++ b/draft-ietf-httpbis-message-signatures.md @@ -406,7 +406,7 @@ In order to verify a signature, a verifier MUST: 3. Use the signature's Algorithm and Verification Key Material with the recreated Signing Input to verify the signature value. -A signature with a Creation Time that is in the future or an Expiration Time that is in the past MUST NOT be processed. +The verifier MUST examine the signature's Creation Time and Expiration Time and evaluate whether they meet the verifier's requirements. These requirements may vary depending on the use case. When comparing Creation Time and/or Expiration Time to a timestamp obtained from another source (e.g., testing that the Expiration Time is later than the local time at the verifier), the verifier MAY allow for some variability due to clock skew between the two timestamp sources (e.g., the signer and the verifier). The verifier MAY impose its own maximum age limits, and reject signatures that are too old (i.e., have a Creation Time too far in the past) regardless of whether the signer gave the signatures an Expiration Time. The verifier MUST ensure that a signature's Algorithm is appropriate for the key material the verifier will use to verify the signature. If the Algorithm is not appropriate for the key material (for example, if it is the wrong size, or in the wrong format), the signature MUST NOT be processed. @@ -1059,6 +1059,10 @@ Jeffrey Yasskin *RFC EDITOR: please remove this section before publication* - draft-ietf-httpbis-message-signatures + - -01 + * Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier's requirements. + * Minor editorial corrections and readability improvements. + - -00 * Initialized from draft-richanna-http-message-signatures-00, following adoption by the working group. From b60a4cd176db43f41b25a6c76483914d54324af4 Mon Sep 17 00:00:00 2001 From: Annabelle Backman Date: Thu, 23 Jul 2020 17:05:07 -0700 Subject: [PATCH 4/5] Strengthened requirement for content identifiers for header fields to be lower-case. --- draft-ietf-httpbis-message-signatures.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-message-signatures.md b/draft-ietf-httpbis-message-signatures.md index c3c5843fe1..31606bd76d 100644 --- a/draft-ietf-httpbis-message-signatures.md +++ b/draft-ietf-httpbis-message-signatures.md @@ -166,7 +166,7 @@ The following sections define content identifiers, their associated content, and ## HTTP Header Fields -An HTTP header field value is identified by its header field name. While HTTP header field names are case-insensitive, implementations SHOULD use lowercased field names (e.g., `content-type`, `date`, `etag`) when using them as content identifiers. +An HTTP header field is identified by its header field name. While HTTP header field names are case-insensitive, implementations MUST use lowercased field names (e.g., `content-type`, `date`, `etag`) when using them as content identifiers. An HTTP header field value is canonicalized as follows: @@ -1060,6 +1060,7 @@ Jeffrey Yasskin - draft-ietf-httpbis-message-signatures - -01 + * Strengthened requirement for content identifiers for header fields to be lower-case (changed from SHOULD to MUST). * Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier's requirements. * Minor editorial corrections and readability improvements. From 97576096de20e9272e7752a98e6ba1b9a33d30bb Mon Sep 17 00:00:00 2001 From: Justin Richer Date: Thu, 1 Oct 2020 15:24:52 -0400 Subject: [PATCH 5/5] Revert text Now in #1280 --- draft-ietf-httpbis-message-signatures.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-message-signatures.md b/draft-ietf-httpbis-message-signatures.md index 31606bd76d..22dcc9ba05 100644 --- a/draft-ietf-httpbis-message-signatures.md +++ b/draft-ietf-httpbis-message-signatures.md @@ -406,7 +406,7 @@ In order to verify a signature, a verifier MUST: 3. Use the signature's Algorithm and Verification Key Material with the recreated Signing Input to verify the signature value. -The verifier MUST examine the signature's Creation Time and Expiration Time and evaluate whether they meet the verifier's requirements. These requirements may vary depending on the use case. When comparing Creation Time and/or Expiration Time to a timestamp obtained from another source (e.g., testing that the Expiration Time is later than the local time at the verifier), the verifier MAY allow for some variability due to clock skew between the two timestamp sources (e.g., the signer and the verifier). The verifier MAY impose its own maximum age limits, and reject signatures that are too old (i.e., have a Creation Time too far in the past) regardless of whether the signer gave the signatures an Expiration Time. +A signature with a Creation Time that is in the future or an Expiration Time that is in the past MUST NOT be processed. The verifier MUST ensure that a signature's Algorithm is appropriate for the key material the verifier will use to verify the signature. If the Algorithm is not appropriate for the key material (for example, if it is the wrong size, or in the wrong format), the signature MUST NOT be processed. @@ -1083,4 +1083,3 @@ Jeffrey Yasskin * Added IANA HTTP Signature Parameter registry. * Added additional normative and informative references. * Added Topics for Working Group Discussion section, to be removed prior to publication as an RFC. -