Dave, I’m not sure this is as useful as one might think - from RFC3230… > 7 <https://tools.ietf.org/html/rfc3230#section-7> Security Considerations > > This document specifies a data integrity mechanism that protects HTTP > instance data, but not HTTP entity headers, from certain kinds of > accidental corruption. It is also useful in detecting at least one > spoofing attack [9 <https://tools.ietf.org/html/rfc3230#ref-9>]. However, > it is not intended as general > protection against malicious tampering with HTTP messages. > > The HTTP Digest Access Authentication mechanism [5 > <https://tools.ietf.org/html/rfc3230#ref-5>] provides some > protection against malicious tampering.
For example, if you have a corporate web proxy or ISP that decides to help out by doing content compression as an example, all your requests will start failing (so-called accidental corruption). We learned from XML that consistent canonicalization of the request data is important. IOW…RFC3230 is valid when it works, but what about all the times it fails for no apparent reason? (false negatives) In my humble experience with REST, the HTTP body is only a small part of the transaction. The headers, method, and URL parameters contain all of the semantics to an application transaction. Sure there are some requests that are just built on HTTP POST. But you have to be sure, there are no parameters that matter in the headers or URL. The OAuth WG took a big ambitious stab at this (thanks Justin), but we weren’t convinced implementations would be stable. https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 I can’t help but worry we are headed back to RPC style SOAP like containers based on JSON tokens that can be signed and that contain all the semantics and data of a transaction to be signed. Now that I said that, I’m going to go wash my mouth out. Ugh. Phil > On Aug 31, 2018, at 3:05 PM, Dave Tonge <dave.to...@momentumft.co.uk> wrote: > > Thanks for the replies. > You're absolutely right Phil and George - apologies I omitted the digest step > from the first email. > Both the STET and Berlin Group specs require the use of SHA-256 or SHA-512 > digest header as per RFC3230 (https://tools.ietf.org/html/rfc3230 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=>) > They then use the draft cavage spec to sign a defined set of headers which > includes the date and digest headers. > > > If you want attestation, better to use SET or plain JWT. > > The pushback on this has been that to use JWTs for all API request bodies and > responses would make the APIs harder to develop against and debug. > However I do think it is a better option than having signatures in headers. I > like the idea of using content negotiation to allow clients to request either > application/json or application/jwt from an API endpoint. > > I'd be interested if there is any interest in the working group for this > draft though: https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=>. > As Ben mentioned, does the issue of JSON canonicalization make this a > non-starter? > > Thanks > > Dave
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
