I'm not a big fan of canonicalization for signatures. In the past it has
been brittle, the libraries subject to bugs, and hard for developers to
adopt. That said, if no canonicalization is not a requirement, have you
checked out JSON-LD? It has embedded signature support.
https://json-ld.org/spec/latest/
On 9/3/18 6:23 AM, Dave Tonge wrote:
Hi Phil
Thanks again for the helpful reply.
I 100% agree with you about the problem of false negatives with RFC3230.
I am not in favour of the its use and will do my best to highlight
these issues with those who are proposing its use with the draft
cavage spec.
I also share your worry about the potential for things to move back to
a SOAP style of API.
Having a look at the
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
spec it is quite general purpose, whereas I'm in favour of something
that is explicitly designed for JSON requests and responses. If there
was confidence in the JSON canonicalisation described in
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then
this seems to enable APIs to stay REStful but with the support for
self-contained signatures. For many applications I agree that there
will need to be some repetition of values in the JSON payload that are
already in the header, e.g. audience, issuer and time. But if general
purpose HTTP signing is a lost cause, then "Cleartext JSON Web
Signatures" seem the next best thing.
Dave
On Sat, 1 Sep 2018 at 01:06, Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
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
<mailto: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
--
Dave Tonge
CTO
Moneyhub Enterprise
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120
Moneyhub Enterprise is a trading style of Moneyhub Financial
Technology Limited which is authorised and regulated by the Financial
Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on
the Financial Services Register (FRN 809360) at fca.org.uk/register
<http://fca.org.uk/register>. Moneyhub Financial Technology is
registered in England & Wales, company registration number 06909772 .
Moneyhub Financial Technology Limited 2018 ©
DISCLAIMER: This email (including any attachments) is subject to
copyright, and the information in it is confidential. Use of this
email or of any information in it other than by the addressee is
unauthorised and unlawful. Whilst reasonable efforts are made to
ensure that any attachments are virus-free, it is the recipient's sole
responsibility to scan all attachments for viruses. All calls and
emails to and from this company may be monitored and recorded for
legitimate purposes relating to this company's business. Any opinions
expressed in this email (or in any attachments) are those of the
author and do not necessarily represent the opinions of Moneyhub
Financial Technology Limited or of any other group company.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
