Incorporating WG feedback

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:
 
@@ -324,15 +324,20 @@ 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:
 
 ~~~
 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 +351,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}
 
@@ -401,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.
 
@@ -1054,6 +1059,11 @@ Jeffrey Yasskin
 *RFC EDITOR: please remove this section before publication*
 
 - 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.
+
   - -00
      * Initialized from draft-richanna-http-message-signatures-00, following adoption by the working group.