Against draft-ietf-webbotauth-httpsig-protocol-00, §5.2.
§5.2 introduces expires as a required @signature-params entry, then the
list continues with keyid and tag, and three sentences on other topics
follow before the recommendation:
The signing key is available to the agent at request time. Algorithms should
be registered with IANA as part of HTTP Message Signatures Algorithm
registry.
The creation of the signature is defined in Section 3.1 of
[HTTP-MESSAGE-SIGNATURES].
It is RECOMMENDED that expiry be no more than 24 hours.
By that point the nearest concrete noun is "the signing key", and the sentence
says "expiry" rather than naming the parameter. I read it as a bound on key
lifetime.
The document uses that word family for both clocks, which is what makes the
bare noun ambiguous rather than merely loose. §5.5.2 describes a key's own
expiry in the same terms: "Continue to include the old key until its
expiration date", and "Remove expired keys from the directory". The directory
example in §5.5.1 gives such a key a 30-day life (nbf 2024-04-11, exp
2024-05-11). A reader who attaches the 24-hour figure to keys therefore lands
somewhere the document contradicts by two orders of magnitude, and has no local
cue that they have done so.
In fairness, the paragraph immediately after does resolve it: "A signature
covering @authority alone verifies against any method, path, or body sent to
that authority until it expires [...] expires bounds how long that lasts."
So a reader going straight through recovers one paragraph later. The cost is
that they recover by backtracking, having already formed the wrong reading.
Naming the parameter avoids that for one word.
Suggested fix, either:
- name the parameter: "It is RECOMMENDED that a signature's
expires be no
more than 24 hours after its created."
- or move the sentence up so it attaches directly to the
expires entry in the
@signature-params list, where its antecedent is unambiguous.
Against
draft-ietf-webbotauth-httpsig-protocol-00, §5.2.§5.2 introduces
expiresas a required@signature-paramsentry, then thelist continues with
keyidandtag, and three sentences on other topicsfollow before the recommendation:
By that point the nearest concrete noun is "the signing key", and the sentence
says "expiry" rather than naming the parameter. I read it as a bound on key
lifetime.
The document uses that word family for both clocks, which is what makes the
bare noun ambiguous rather than merely loose. §5.5.2 describes a key's own
expiry in the same terms: "Continue to include the old key until its
expiration date", and "Remove expired keys from the directory". The directory
example in §5.5.1 gives such a key a 30-day life (
nbf2024-04-11,exp2024-05-11). A reader who attaches the 24-hour figure to keys therefore lands
somewhere the document contradicts by two orders of magnitude, and has no local
cue that they have done so.
In fairness, the paragraph immediately after does resolve it: "A signature
covering @authority alone verifies against any method, path, or body sent to
that authority until it expires [...] expires bounds how long that lasts."
So a reader going straight through recovers one paragraph later. The cost is
that they recover by backtracking, having already formed the wrong reading.
Naming the parameter avoids that for one word.
Suggested fix, either:
expiresbe nomore than 24 hours after its
created."expiresentry in the@signature-paramslist, where its antecedent is unambiguous.