[Openid-specs-fapi] Canonicalization is Evil Re: Alive and kicking: draft-cavage-http-signatures

Dave Tonge dave.tonge at momentumft.co.uk
Tue Mar 19 05:37:23 UTC 2019


I'm hopeful that we can discuss some of these approaches at the OAuth
Security Workshop.

As Jospeh mentioned in the previous thread I think FAPI should provide
guidance on the different options available for payload signing.

Dave

On Thu, 14 Mar 2019 at 16:17, Anders Rundgren via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hi All,
>
> As an alternative to (probably in vane) trying to convince everybody that
> B64 rules/suck or that JCS is fantastic/suck, I would investigate if there
> could be way offering deployment alternatives based on a common core:
> https://cyberphone.github.io/doc/research/shreq--jwsjcs--combo--jwsb64.pdf
>
> Technically this is trivial so it "simply" a matter of politics to make it
> a reality.  I'm personally not much of a politician so I leave this option
> to you guys to ponder about.
>
> For body-less requests like GET, I believe the current SHREQ scheme should
> be sufficient as is.
>
> thanx,
> Anders
>
> On 2019-03-14 14:49, Anders Rundgren wrote:
> > On 2019-03-14 13:45, n-sakimura wrote:
> > Hi Nat,
> >
> >> As far as I understand, Oracle has no intention of taking draft-cavage
> to a standard stage.
> >> That was communicated to me at the outset of the FAPI WG by Oracle and
> as far as I am aware of, it has not changed.
> >
> > I'm sure about that.
> >
> >
> >> Canonicalization is Evil. If there is anything that we have learnt from
> XMDISG, that's ne'er to do any canonicalization and better to ASCII armor
> it as middleware tend to screw any non-ascii character up.
> >
> > As far as I can tell my current canonicalization implementations running
> on JavaScript, Java, Python, C# and Go together with native JSON tools,
> flawlessly process non-ASCII.  It is a part of the of the verification
> suite:
> https://github.com/cyberphone/json-canonicalization/tree/master/testdata
> >
> > Now let's say that there actually is some marginal system out there
> which fails; should that set the bar for everybody else?  Creating a new
> JSON solution is not that hard if you really need it.  In fact, the
> verification suite initially failed on .NET but Microsoft were really nice
> and fixed it because it was due to a low-level bug in their number parser.
> >
> > However, it would be dishonest of me to say that there are zero
> problems.  This paragraph from the latest draft shows implications that
> sometimes spill over to the application space:
> >
> >      "An additional constraint is that parsed JSON String data MUST NOT
> be
> >       altered during subsequent serializations.  For more information see
> >       Appendix E"
> >
> >
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05#appendix-E
> >
> > IMO, this problem has reasonable short term solutions that also are
> needed for dealing with systems talking to browsers/javascript which to
> date still is I-JSON crippled.
> >
> > Anyway, as mentioned in a private message it would be technically
> straightforward creating a JWS/Base64 variant of SHREQ that would have the
> same security characteristics, be self-contained, etc.  WDYT?
> >
> >
> >> It is kind of sad that people mixes up an individual draft to a
> standard.
> >
> > Since there still isn't anything out there that qualifies as a
> "standard" what are developers supposed to do?
> > Transcending the OBIE signature solution into an IETF standard won't be
> easy since it isn't REST compatible.
> >
> > Cheers,
> > Anders
> >>
> >> Best,
> >>
> >> Nat Sakimura
> >>
> >> -----Original Message-----
> >> From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net>
> On Behalf Of Anders Rundgren via Openid-specs-fapi
> >> Sent: Thursday, March 14, 2019 7:14 PM
> >> To: Financial API Working Group List <
> openid-specs-fapi at lists.openid.net>; Joseph Heenan <joseph at authlete.com>
> >> Cc: Anders Rundgren <anders.rundgren.net at gmail.com>
> >> Subject: Re: [Openid-specs-fapi] Alive and kicking:
> draft-cavage-http-signatures
> >>
> >> On 2019-03-14 11:09, Dave Tonge via Openid-specs-fapi wrote:
> >>> Yeah a wiki would be good.
> >>>
> >>> I personally think that any relevant headers should be repeated in the
> JSON payload.
> >>
> >>
> >> Right, it works like a charm as well.
> >> https://mobilepki.org/shreq
> >>
> >> Anders
> >>
> >>> The person verifying the signature will then need to ensure that what
> is in the JSON payload matches what is in the http headers, but I think
> that is far less problematic than using the header values themselves to
> construct the signing material.
> >>>
> >>>
> >>>
> >>> On Thu, 14 Mar 2019 at 10:55, Joseph Heenan <joseph at authlete.com
> <mailto:joseph at authlete.com>> wrote:
> >>>
> >>>       Thanks for the detail Dave. That was a lot more issues than I
> expected.
> >>>
> >>>       Is it worth us starting a wiki page on our bitbucket (or is a
> markdown doc in git easier?) with a list of all the requirements, choices
> and pros/cons? I think I’d be in favour of that as I suspect there will be
> a lot of repetition in the conversation otherwise. I’m sure we discussed
> this previously at the face to face in Tokyo last year but it’s not
> mentioned in the minutes.
> >>>
> >>>       We’ve had a couple of previous discussions:
> >>>
> >>>
> https://bitbucket.org/openid/fapi/issues/100/signing-api-response-payloads
> >>>
> >>>
> https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2018-04-25#rst-header-id8
> >>>
> >>>       I think there’s also always been a feeling the IETF oauth
> working group might be a better place to discuss it, but I’m not sure if
> there’s been any progress discussing it there. I don’t obviously see
> anything on the mailing list in the last few months and don’t see anything
> relevant on the agenda for Prague.
> >>>
> >>>       Thanks
> >>>
> >>>       Joseph
> >>>
> >>>
> >>>>       On 13 Mar 2019, at 20:56, Dave Tonge <
> dave.tonge at momentumft.co.uk <mailto:dave.tonge at momentumft.co.uk>> wrote:
> >>>>
> >>>>       Hi Joseph
> >>>>
> >>>>       The problem is that there is lots of non-standard
> stringification and parsing as well as other weirdness.
> >>>>
> >>>>       Here are the problems I encountered:
> >>>>       1. the draft defines its own set of algorithms rather than just
> using the JWA
> >>>>       2. the signing material should be new line separated (why?)
> >>>>       3. the header which specifies the alg, what is being signed and
> the signature should be of the form 'Signature key="value",key="value"'
> >>>>       4. the header names are case sensitive (against http specs and
> caused me no end of grief as some http client libraries automatically
> lowercase http header names)
> >>>>       5. requirement on a date header in a non-standard form
> >>>>       6. requirement that http body is completely untouched or the
> digest will break
> >>>>       7. relies on the http digest spec (
> https://tools.ietf.org/html/rfc3230) for actual content integrity
> >>>>       8. uses a custom header to pass the http method and path (but
> leaves out host?)
> >>>>
> >>>>       When we are mainly talking about signing JSON API requests and
> responses I really don't think its the right way to go.
> >>>>
> >>>>       I agree that it would be a good topic for discussion at the
> OAuth Security Workshop.
> >>>>
> >>>>       Dave
> >>>>
> >>>>       On Wed, 13 Mar 2019 at 17:25, Joseph Heenan via
> Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:
> openid-specs-fapi at lists.openid.net>> wrote:
> >>>>
> >>>>           I presume the interoperability issues are solvable one way
> or another?
> >>>>
> >>>>           The early reports about OBUK’s signing algorithm seem to be
> cautiously pessimistic. I’m not sure if OB gave any reasons for not using
> the IETF cavage draft.
> >>>>
> >>>>           I know we’ve discussed it before, but it does seem like the
> FAPI working group should try and favour one standard, which would also
> allow us to build interoperability/certification tests for that standard. I
> think the oauth working group feels similarly. Justin Richer pulled
> together some of the thoughts at IETF 101 (
> https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessa-http-signing-00
> ) but I’m not sure if the conversation moved on from there.
> >>>>
> >>>>           Perhaps it’s one to put on the agenda for the oauth
> security workshop face-to-face?
> >>>>
> >>>>           Joseph
> >>>>
> >>>>
> >>>>
> >>>>>           On 13 Mar 2019, at 16:15, Dave Tonge via Openid-specs-fapi
> <openid-specs-fapi at lists.openid.net <mailto:
> openid-specs-fapi at lists.openid.net>> wrote:
> >>>>>
> >>>>>           Having integrated against it - the draft is terrible.
> >>>>>
> >>>>>           I highly doubt that it is being implemented in an
> interoperable way.
> >>>>>
> >>>>>           We need a better solution and I'm very much in favour of
> JSON based signatures - cleartext json would be great, but detached JWTs
> are still a lot better than http-signatures.
> >>>>>
> >>>>>           On Wed, 13 Mar 2019 at 16:41, Anders Rundgren via
> Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:
> openid-specs-fapi at lists.openid.net>> wrote:
> >>>>>
> >>>>>               After posting
> https://cyberphone.github.io/ietf-signed-http-requests/hotrfc-shreq.pdf
> in the https://open-banking-global.slack.com <
> https://open-banking-global.slack.com/> forum it became clear that quite
> a bunch of API builders in the financial sector (including Starling) indeed
> have settled on
> https://tools.ietf.org/html/draft-cavage-http-signatures-10.
> >>>>>
> >>>>>               Under those circumstances it seems a bit premature
> suggesting that other entities should not use it.  That a draft has expired
> doesn't make it worthless.
> >>>>>
> >>>>>               What's surprising is that I found no traces of any
> discussions within the IETF regarding this draft (which IMO doesn't look
> that bad).
> >>>>>
> >>>>>               Note: I'm not advocating for adoption of
> http-signatures, but for a more open discussion about the alternatives.
> >>>>>
> >>>>>               Thanx,
> >>>>>               Anders
> >>>>>               _______________________________________________
> >>>>>               Openid-specs-fapi mailing list
> >>>>>               Openid-specs-fapi at lists.openid.net <mailto:
> Openid-specs-fapi at lists.openid.net>
> >>>>>
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >>>>>
> >>>>>
> >>>>>
> >>>>>           --
> >>>>>           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.
> >>>>>           _______________________________________________
> >>>>>           Openid-specs-fapi mailing list
> >>>>>           Openid-specs-fapi at lists.openid.net <mailto:
> Openid-specs-fapi at lists.openid.net>
> >>>>>           http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >>>>
> >>>>           _______________________________________________
> >>>>           Openid-specs-fapi mailing list
> >>>>           Openid-specs-fapi at lists.openid.net <mailto:
> Openid-specs-fapi at lists.openid.net>
> >>>>           http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >>>>
> >>>>
> >>>>
> >>>>       --
> >>>>       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.
> >>>
> >>>
> >>>
> >>> --
> >>> 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.
> >>>
> >>> _______________________________________________
> >>> Openid-specs-fapi mailing list
> >>> Openid-specs-fapi at lists.openid.net
> >>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >>>
> >>
> >> _______________________________________________
> >> Openid-specs-fapi mailing list
> >> Openid-specs-fapi at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >>
> >
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>


-- 
Dave Tonge
CTO
[image: 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190319/ef68cb71/attachment-0001.html>


More information about the Openid-specs-fapi mailing list