I have a few comments to the latest version of draft-cavage-http-signatures-12.
The created signature parameter is a really good additions as this simplifies the time validation of the request when you do not need to relate to the Date header anymore.
The road you have gone down with the algorithm signature parameter is to me unfortunate. It seems to unnecessarily complicate the specification and remove part of the clarity of it. Would it not be better and more consistent to protect the algorithm parameter by the signature. The algorithm parameter could then be added to the signature in the same manner as request-target and created parameters. This would then keep the simplicity and clarity that the previous version of the specification has, but algorithm manipulation by an attacker would then lead to faulty Signature. Taken this with the fact that the server validating the signature is free at any time to limit which algorithms it deems sufficiently secure, this would then solve the algorithm issue as far as I understand. The solution would in worst case scenario then be as secure as the least secure algorithm the server selects to support.
I hope you have the possibility to consider this feedback.
Gisle wrote:
I have a few comments to the latest version of draft-cavage-http-signatures-12.
The created signature parameter is a really good additions as this simplifies the time validation of the request when you do not need to relate to the Date header anymore.
The road you have gone down with the algorithm signature parameter is to me unfortunate. It seems to unnecessarily complicate the specification and remove part of the clarity of it. Would it not be better and more consistent to protect the algorithm parameter by the signature. The algorithm parameter could then be added to the signature in the same manner as request-target and created parameters. This would then keep the simplicity and clarity that the previous version of the specification has, but algorithm manipulation by an attacker would then lead to faulty Signature. Taken this with the fact that the server validating the signature is free at any time to limit which algorithms it deems sufficiently secure, this would then solve the algorithm issue as far as I understand. The solution would in worst case scenario then be as secure as the least secure algorithm the server selects to support.
I hope you have the possibility to consider this feedback.