Problem including the Date header in the signature

[mpuzar]

While implementing the signature, I found out that the Dateheader is something that the application server (or possibly even apache & co. later) set after the response is delivered and, as such, is out of our hands. And if I set the Date header myself, it is overwritten, invalidating the signature.

To avoid having to look for ways to circumvent this problem for every possible implementation, I would suggest adding a custom date header instead (X-Response-Signature-Date, or maybe just X-Date?).

The same applies to generating signatures on the client side.

[wrygiel]

I don't think we should change that. This recommendation is part of the httpsig spec:

The minimum recommended data to sign is the (request-target), host, and date.

By introducing alternative date headers, and by not signing the actual date header, we would be violating this recommendation.

[mpuzar]

I am just saying that it might technically be hard or impossible to adhere strictly to this particular recommendation (it is only a SHOULD, not a MUST). By allowing to use an alternative date header instead, where the original Date is out of reach for the implementer, we would still keep this recommended information, while also making it possible to implement where it otherwise would not be the case.

[wrygiel]

Please check if I understood you correctly:

Solution 1

• Allow the signer to sign either Date xor X-Date header (but not both, I guess?)
• Require the verifier to support both.
  • If none of these two is signed, then verification will fail.
  • If the value of the signed one fails the threshold check, then verification will fail.
  • What to do when both Date and X-Date are signed? Fail? Verify any of them? Verify both of them?

[wrygiel]

I wonder what would be the best name for the X-Date header. Perhaps there already exists a standard one to handle this kind of scenario.

[wrygiel]

X-Date is a bad choice. Quote from RFC 6648:

   Creators of new parameters to be used in the context of application
   protocols:

   1.  SHOULD assume that all parameters they create might become
       standardized, public, commonly deployed, or usable across
       multiple implementations.

   2.  SHOULD employ meaningful parameter names that they have reason to
       believe are currently unused.

   3.  SHOULD NOT prefix their parameter names with "X-" or similar
       constructs.

Response-Signature-Date might be good for srvauth, but if we want to extend this to cliauth, then it fails.

[wrygiel]

Signature-Date would work, but it still fails to convey the actual meaning we are trying to get. We are not really interested in "the date it has been signed", but rather "the date is has been originally generated by the app" (and later we're signing this information to prove that it's correct).

Since Apache acts as a proxy here, and a proxy has a source/origin, then perhaps Originating-Date or Origin-Date would fit it best?

[wrygiel]

Origin-Date seems redundant though, because this is exactly how the Date header is documented as (here):

The "Date" header field represents the date and time at which the message was originated (...)

When a Date header field is generated, the sender SHOULD generate its field value as the best available approximation of the date and time of message generation. In theory, the date ought to represent the moment just before the payload is generated. In practice, the date can be generated at any time during message origination.

sigh

Original-Date? (as in, "before it got replaced by proxy"?)

[mpuzar]

I'm fine with both Original-Date, Signature-Date, or even Date-Signed? Because, that is the main context and reason for it - signing.

As for the recipient - it will only check the headers mentioned in the Authorization header (and in that particular order), which is up to the sender to decide.

[wrygiel]

As for the recipient - it will only check the headers mentioned in the Authorization header (and in that particular order), which is up to the sender to decide.

So, if the sender signs both Date and Original-Date, then the recipient is required to check both. Yes?

[mpuzar]

Yes, otherwise the signature verification will fail.

[wrygiel]

I'm not talking about signature verification. I'm talking about verifying the dates. See here.

[mpuzar]

Ah, I understand. Well, that is up to us to decide. It will probably not be a problem (I expect the difference to be max 1-2 s, unless one of the servers in the chain is misconfigured). I have no strong opinions here.

[wrygiel]

The same applies to generating signatures on the client side.

Do you suspect that this problem also occurs in the cliauth case?

[mpuzar]

I suspect it might, but it really depends on how the clients are implemented and who is in control of the Date header there.

[wrygiel]

Went with:

Solution 2

• Allow the signer to include and sign either Date or Original-Date header (or both).
• Require the verifier to support both.
  • If none of these two is signed, then verification will fail.
  • If the value of the signed one fails the threshold check, then verification will fail.
  • If both are included, then it's recommended for both to be verified, but it's not strictly required.