w3c-ccg / http-signatures

Signing HTTP Messages specification
https://w3c-dvcg.github.io/http-signatures/
Other
34 stars 9 forks source link

Inconsistencies relating to "(created)" pseudo-header #110

Open Diggsey opened 4 years ago

Diggsey commented 4 years ago

These excerpts don't make sense together:

If the header field name is (created) and the algorithm parameter starts with rsa, hmac, or ecdsa an implementation MUST produce an error.

If not specified, implementations MUST operate as if the field were specified with a single value, (created), in the list of HTTP headers.

All Headers Test

Authorization: Signature keyId="Test",algorithm="rsa-sha256", created=1402170695, expires=1402170699, headers="(request-target) (created) (expires) host date content-type digest content-length", signature="vSdrb+dS3EceC9bcwHSo4MlyKS59iFIrhgYkz8+oVLEEzmYZZvRs 8rgOp+63LEM3v+MFHB32NfpB2bEKBIvB1q52LaEUHFv120V01IL+TAD48XaERZF ukWgHoBTLMhYS2Gb51gWxpeIq8knRmPnYePbF5MOkR0Zkly4zKH7s1dE="

First, the algorithm parameter is specified to always be hs2019 now.

Second, the set of algorithms for which the (created) parameter is disallowed appears to cover all supported algorithms.

Third, making (created) the default when all implementations are required to error on it due to the above does not make sense.

Fourth, the "all headers test" uses (created) in a way which is specifically disallowed (with rsa-sha256)