Signature: error in 4.3 examples

[bblfish]

The first example signature from §4.3 of message-signatures-15 fails signature verification.

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature:  sig1=:LAH8BjcfcOcLojiuOBFWn0P5keD3xAOuJRGziCLuD8r5MW9S0\
  RoXXLzLSRfGY/3SF8kVIkHjE13SEFdTo4Af/fJ/Pu9wheqoLVdwXyY/UkBIS1M8Br\
  c8IODsn5DFIrG0IrburbLi0uCc+E2ZIIb6HbUJ+o+jP58JelMTe0QE3IpWINTEzpx\
  jqDf5/Df+InHCAkQCTuKsamjWXUpyOT1Wkxi7YPVNOjW4MfNuTZ9HdbD2Tr65+BXe\
  TG9ZS/9SWuXAc+BZ8WyPz0QRz//ec3uWXd7bYYODSjRAxHqX+S1ag3LZElYyUKaAI\
  jZ8MGOt4gXEwCSLDv/zqxZeWLj/PDkn6w==:

{"hello": "world"}

By changing the validity date from 1618884475 to 1618884473 the validation succeeds. I guessed that date as it is the one used in all the other signatures. So I guess that is a typo. (It would have been good to have a different created date, just to make testing less mechanical, but then the signature needs to be changed).

There is then perhaps a logical mistake in the next example.
The story goes that the proxy receiving the above request alters the message and signs it before sending it on. The original signature is kept and added as part of the signature. The proxy alters the Host header and adds a Forwarded header along with a new Signature. But by changing the Host the proxy makes it impossible for the recipient to verify the initial signature, since that includes a @authority component which was changed.

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18
Forwarded: for=192.0.2.123
Signature-Input: sig1=("@method" "@authority" "@path" \
    "content-digest" "content-length" "content-type")\
    ;created=1618884475;keyid="test-key-rsa-pss", \
  proxy_sig=("signature";key="sig1" "forwarded")\
    ;created=1618884480;expires=1618884540;keyid="test-key-rsa"\
    ;alg="rsa-v1_5-sha256"
Signature:  sig1=:LAH8BjcfcOcLojiuOBFWn0P5keD3xAOuJRGziCLuD8r5MW9S0\
    RoXXLzLSRfGY/3SF8kVIkHjE13SEFdTo4Af/fJ/Pu9wheqoLVdwXyY/UkBIS1M8\
    Brc8IODsn5DFIrG0IrburbLi0uCc+E2ZIIb6HbUJ+o+jP58JelMTe0QE3IpWINT\
    EzpxjqDf5/Df+InHCAkQCTuKsamjWXUpyOT1Wkxi7YPVNOjW4MfNuTZ9HdbD2Tr\
    65+BXeTG9ZS/9SWuXAc+BZ8WyPz0QRz//ec3uWXd7bYYODSjRAxHqX+S1ag3LZE\
    lYyUKaAIjZ8MGOt4gXEwCSLDv/zqxZeWLj/PDkn6w==:, \
  proxy_sig=:G1WLTL4/9PGSKEQbSAMypZNk+I2dpLJ6qvl2JISahlP31OO/QEUd8/\
    HdO2O7vYLi5k3JIiAK3UPK4U+kvJZyIUidsiXlzRI+Y2se3SGo0D8dLfhG95bKr\
    6ukYXl60QHpsGRTfSiwdtvYKXGpKNrMlISJYd+oGrGRyI9gbCy0aFhc6I/okIML\
    eK4g9PgzpC3YTwhUQ98KIBNLWHgREfBgJxjPbxFlsgJ9ykPviLj8GKJ81HwsK3X\
    M9P7WaS7fMGOt8h1kSqgkZQB9YqiIo+WhHvJa7iPy8QrYFKzx9BBEY6AwfStZAs\
    XXz3LobZseyxsYcLJLs8rY0wVA9NPsxKrHGA==:

{"hello": "world"}

So the spec has to either remove the @authority component from the client request, or change the text at the end of the section which says

The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application.

Note: the proxy's signature does verify for me with the timestamp of the client as it appears in the spec.

[bblfish]

Verification of claim above:

The test on line 173 of VerifySignatureTests.scala had to be disabled for my tests to pass on the JVM (JS tests coming soon).
All the other tests on requests from the spec are passing (well on one I had to change the time for it to pass.

Further commits to the PR 12 should get the JS to work.

[jricher]

The proxy should not alter the original signature, and that signature does need to include the @authority component. The whole point of the story is that the proxy verifies the first signature, and the service behind the proxy verifies the proxy's signature. If we can make that story more clear, I'd be glad to!

[bblfish]

The whole point of the story is that the proxy verifies the first signature, and the service behind the proxy verifies the proxy's signature. If we can make that story more clear, I'd be glad to!

It is indeed an option to have the final recipient rely on the signature of the proxy as a verification of the originally signed message.

But the text currently says "The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application."

The "independently" reads to me as if the application (that is the server receiving the signature) should be able to verify both signatures. It seems to me that it can only verify the proxy's signature though. But perhaps I was just misreading... It seems there is a dependence of the final recipient on the signature of the proxy.

I think there is still the problem of the time being wrong...

[jricher]

Yes, the signature needs to be recalculated and replaced due to the typo in the timestamp (I will need to check the generation script).

I can see now how that line can be misread. Though it is definitely possible for the origin server to validate the client's signature if it has additional information, like that discussed in https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-14.html#name-multiple-message-component- and https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-14.html#name-message-component-source-an -- but this could be made more clear.