Closed mpuzar closed 6 years ago
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.
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.
Please check if I understood you correctly:
Date
xor X-Date
header (but not both, I guess?)Date
and X-Date
are signed? Fail? Verify any of them? Verify both of them?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.
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.
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?
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"?)
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.
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?
Yes, otherwise the signature verification will fail.
I'm not talking about signature verification. I'm talking about verifying the dates. See here.
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.
The same applies to generating signatures on the client side.
Do you suspect that this problem also occurs in the cliauth
case?
I suspect it might, but it really depends on how the clients are implemented and who is in control of the Date
header there.
Went with:
Date
or Original-Date
header (or both).
While implementing the signature, I found out that the
Date
header 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 theDate
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 justX-Date
?).The same applies to generating signatures on the client side.