§5.2: "expiry" is separated from its antecedent and reads as key expiry #133

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.