Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses

From: Dave Tonge <[email-masked]>
Date: Mon, 3 Sep 2018 12:23:24 +0200

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 <[email-masked]> 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 <[email-masked]>
> 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
<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.

---

From: George Fletcher <[email-masked]>
Date: Mon, 3 Sep 2018 08:27:07 -0400

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:
> 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 
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dave,
>
>     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..
>     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
>>     <[email-masked]
>>     <mailto:[email-masked]>> 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..
>>
>>     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://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 
> 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 .
> 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.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 3 Sep 2018 15:38:04 +0300

Hi Dave,

> signing is a lost cause, then "Cleartext JSON Web Signatures" seem the next
That's probably the wisest approach here.

For reliable signing the data and its structure must remain immutable
from end to end, including how the messages are seen / processed by
programming / library interfaces. That's not the case with HTTP, which
allows bits of the message and its structure to get modified along the
way. If general purpose HTTP signatures were easy to achieve, and
there's obviously all sorts of demand for that, we would have had a
working standard a long time ago.

I wonder what it would take to resurrect
draft-erdtman-jose-cleartext-jws. I see it's formally going to expire in
2 days.

Are we aware of any working implementations?

Vladimir

>>    The HTTP Digest Access Authentication mechanism [5 <https://tools.ietf..org/html/rfc3230#ref-5>] provides some
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: "Manger, James" <[email-masked]>
Date: Mon, 3 Sep 2018 12:56:17 +0000

ACME<https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html> (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the Flattened JSON Serialization with a "url" member in the protected header. It is likely to use the same scheme (POST a JWS) to replace GET methods as well.

--
James Manger

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 3 Sep 2018 16:09:51 +0300

Hi George,

JSON-LD still requires c14n. I opened the particular spec and the c14n
job with JSON-LD appears quite complex. The structure of the linked data
must also be brought into some particular form.

https://json-ld.github.io/normalization/spec/

C10n of plain JSON should be a simpler job. There should also be more
and better software support for that. I don't think we can get around
JSON c10n, if we want to keep the message content in clear text.

Vladimir

On 03/09/18 15:27, George Fletcher wrote:
> 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/
>
>> I also share your worry about the potential for things to move back
>> to a SOAP style of API.
>>
>> Having a look at the
>> 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
>>
>>
>>
>>
>>
>>
>>>         spoofing attack [9
>>> <https://tools.ietf.org/html/rfc3230#ref-9>].  However, it is not
>>> intended as general
>>>         The HTTP Digest Access Authentication mechanism [5
>>> <https://tools.ietf.org/html/rfc3230#ref-5>] provides some
>>>     > If you want attestation, better to use SET or plain JWT.
>>>
>> 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 .
>> 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

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 4 Sep 2018 23:33:39 +0200

Hi

As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
think this is the way to go. The initial use case was to sign transaction
requests and responses, and as was mentioned in previous emails it is very
much desirable to not obfuscate the payload with base64 encoding.

The current draft just expired but if we have found interest I would be
more than willing to post an update. I was supposed to do so earlier but
since it has been hard to find a home for the work (an interested WG) it
has not be top of my proirity list.

With the potential update we (I and the co authors) intended to do some
cleanup and one significant change. We think we should move from ES6
serialization to canonicalization based on
draft-rundgren-json-canonicalization-scheme
<https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
After a lot of research and emails we have come to the conclusion that it
would be easier to get buy in for this method than to get languages to
support ES6 compatible serialization.
draft-rundgren-json-canonicalization-scheme has the additional benefit that
non-intrusive modifications such as attribute reordering would not make
ruin this signature which was the case with ES6 serialization (and we could
avoid some minor ES6 quirks).

Implementations for the draft-rundgren-json-canonicalization-scheme
canonicalization schema is available in JavaScript
<https://www.npmjs.com/package/canonicalize>, .NET
<https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>, Java
<https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>,
and Python
<https://github.com/cyberphone/json-canonicalization/tree/master/python3>.
Anders is currently putting a lot of effort into the canonicalization to
make sure it is stable, and it has been reviewed by several people
knowledgeable in JSON.

When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
done one in JavaScript (I modified an existing JOSE implementation in a few
hours) and Anders has done a Java implementation (at least). The examples
in the specification was created and validated with different
implementations.

I know canonicalization is a scary thing if you have worked with
canonicalization of XML, but I can tell you canonicalization of JSON is not
even close to that complex.

Best regards
//Samuel Erdtman

On Mon, Sep 3, 2018 at 3:09 PM, Vladimir Dzhuvinov <[email-masked]>
wrote:

> Hi George,
>
> JSON-LD still requires c14n. I opened the particular spec and the c14n job
> with JSON-LD appears quite complex. The structure of the linked data must
> also be brought into some particular form.
>
> C10n of plain JSON should be a simpler job. There should also be more and
> better software support for that. I don't think we can get around JSON
> c10n, if we want to keep the message content in clear text.
>
> Vladimir
>
> Having a look at the https://tools.ietf.org/html/dr
> aft-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/dr
> aft-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
>
>
>
>
>
>
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
>     Dave,
>
>         7 <https://tools.ietf.org/html/rfc3230#section-7>
> <https://tools.ietf.org/html/rfc3230#section-7> Security
>         Considerations
>
>
>
>         spoofing attack [9 <https://tools.ietf.org/html/rfc3230#ref-9>
> <https://tools.ietf.org/html/rfc3230#ref-5>
>     <mailto:[email-masked]> <[email-masked]>>
> wrote:
>
>     Thanks for the replies.
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8P
> Zh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL
> cLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=
> y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-
> 2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap
> I_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvD
> LnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlL
> nfhtq6GZGc0HlswqLcp4OK4&e=>
> Moneyhub Enterprise <http://www.google.com/url?q=h
> ttp%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCN
> GUnR5opJv5S1uZOVg8aISwPKAv3A>
> Financial Services Register (FRN 809360) at fca.org.uk/register
> <http://fca.org.uk/register> <http://fca.org.uk/register>.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772 .
> 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
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Dave Tonge <[email-masked]>
Date: Wed, 5 Sep 2018 15:54:29 +0200

Hi Samuel,

Thanks for the reply, I would definitely be interested in an updated draft.
Both the signing spec and the canonicalization spec seem a lot simpler than
JSON-LD.
It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs

Thanks

Dave

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 5 Sep 2018 16:01:57 +0200

Then I’ll post an update within a ~week.

There is one thing that could make implementing even simpler (from my
experience). That is how to handle multiple signatures. Today the
specification supports sharing of headers between signatures. If signatures
instead are completely independent and put in an array at the top level
cleartext_signature attribute one could just do a minor change to existing
implementations to support cleartext signatures.
On Wed, 5 Sep 2018 at 15:54, Dave Tonge <[email-masked]> wrote:

> Both the signing spec and the canonicalization spec seem a lot simpler
> than JSON-LD.

---

From: Dave Tonge <[email-masked]>
Date: Wed, 5 Sep 2018 16:51:54 +0200

Thanks James - definitely an interesting case.
I'd be sorry to see ACME and other APIs go down the route of POSTing base64
encoded blobs for all API interactions.

On Mon, 3 Sep 2018 at 14:56, Manger, James <[email-masked]>
wrote:

> ACME <https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html>
> (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg
> Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the
> Flattened JSON Serialization with a "url" member in the protected header.
> It is likely to use the same scheme (POST a JWS) to replace GET methods as
> well.
>
>
>
> --
>
> James Manger
>
>

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 6 Sep 2018 22:20:02 +0200

Hi,

A new version has been submitted. It would awesome if we could get some
comments on the draft and thoughts about a potential future adoption.

https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01

Changes includes the change of canonicalization method and some minor
clarifications.

Best regards
//Samuel

On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <[email-masked]> wrote:

>>> serialization to canonicalization based on draft-rundgren-json-
>>> canonicalization-scheme
>>> support ES6 compatible serialization. draft-rundgren-json-canonicalization-scheme
>>> has the additional benefit that non-intrusive modifications such as
>>> attribute reordering would not make ruin this signature which was the case
>>> with ES6 serialization (and we could avoid some minor ES6 quirks).
>>>
>>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I
>>> have done one in JavaScript (I modified an existing JOSE implementation in
>>> a few hours) and Anders has done a Java implementation (at least). The
>>> examples in the specification was created and validated with different
>>> implementations.
>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 9 Sep 2018 14:36:48 +0200

Hi Samuel,

thanks for preparing this draft. I‘ve got one question: how would one use it for non-reputation? I assume non-reputation would require not only to sign the request body but also (at least) data about the target of the request, typically a URL + HTTP method. Would one need to include (replicate) this data in the JSON object?

kind regards,
Torsten.

> Am 06.09.2018 um 22:20 schrieb Samuel Erdtman <[email-masked]>:
> 
> Hi,
> 
> A new version has been submitted. It would awesome if we could get some comments on the draft and thoughts about a potential future adoption.
> 
> Changes includes the change of canonicalization method and some minor clarifications.
> 
> Best regards
> //Samuel
> 
> 
> 
>> There is one thing that could make implementing even simpler (from my experience). That is how to handle multiple signatures. Today the specification supports sharing of headers between signatures. If signatures instead are completely independent and put in an array at the top level cleartext_signature attribute one could just do a minor change to existing implementations to support cleartext signatures.
>> 
>>> Both the signing spec and the canonicalization spec seem a lot simpler than JSON-LD.
>>>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely think this is the way to go. The initial use case was to sign transaction requests and responses, and as was mentioned in previous emails it is very much desirable to not obfuscate the payload with base64 encoding.
>>>> 
>>>> The current draft just expired but if we have found interest I would be more than willing to post an update. I was supposed to do so earlier but since it has been hard to find a home for the work (an interested WG) it has not be top of my proirity list. 
>>>> 
>>>> With the potential update we (I and the co authors) intended to do some cleanup and one significant change. We think we should move from ES6 serialization to canonicalization based on draft-rundgren-json-canonicalization-scheme. After a lot of research and emails we have come to the conclusion that it would be easier to get buy in for this method than to get languages to support ES6 compatible serialization. draft-rundgren-json-canonicalization-scheme has the additional benefit that non-intrusive modifications such as attribute reordering would not make ruin this signature which was the case with ES6 serialization (and we could avoid some minor ES6 quirks). 
>>>> 
>>>> Implementations for the draft-rundgren-json-canonicalization-scheme canonicalization schema is available in JavaScript, .NET, Java , and Python. Anders is currently putting a lot of effort into the canonicalization to make sure it is stable, and it has been reviewed by several people knowledgeable in JSON.
>>>> 
>>>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I have done one in JavaScript (I modified an existing JOSE implementation in a few hours) and Anders has done a Java implementation (at least). The examples in the specification was created and validated with different implementations.
>>>> 
>>>> I know canonicalization is a scary thing if you have worked with canonicalization of XML, but I can tell you canonicalization of JSON is not even close to that complex.
>>>> 
>>>> Best regards 
>>>> //Samuel Erdtman
>>>> 
>

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 9 Sep 2018 22:05:00 +0200

Thank you for asking Torsten,

If method or URL contains additional information not contained in the
request body then it would have to be duplicated into the request to be
signed. This may also aplie to headers.

I do not necessarily think it would be bad to duplicate this information
into the request. To support the non-repudiation use-case I expect the
request to be archived and then all this information must be stored. If we
had a schema that could sign method, URL, headers, and body independently
we would still need to collect them when archiving the full request. If we
instead duplicate this information in the request JSON it would be ready
for archiving and the information-format could be in the most appropriate
format for the application context.

With that said draft-erdtman-jose-cleartext-jws does not dictate a solution.

Best regards
//Samuel

On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt <[email-masked]

> Hi Samuel,
>
> thanks for preparing this draft. I‘ve got one question: how would one use
> it for non-reputation? I assume non-reputation would require not only to
> sign the request body but also (at least) data about the target of the
> request, typically a URL + HTTP method. Would one need to include
> (replicate) this data in the JSON object?
>
> kind regards,
> Torsten.
>

---

From: Dave Tonge <[email-masked]>
Date: Mon, 10 Sep 2018 05:02:25 +0200

H Torsten

I agree that use use of draft-erdtman-jose-cleartext-jws doesn't support
non-repudiation for JSON HTTP requests or responses alone.
There was a reference made earlier in the email chain to ACME which
requires `url` to be added to the JWT payload, and mention was made that
some header params (e.g. time) would need to be repeated.

However, despite the title of this thread, the main business need that I've
come across is the requirement for non-repudiation for business actions
that are often communicated in JSON via HTTP - rather than just the raw
JSON HTTP requests and responses themselves. As a way of example, consider
a payment initiation request made to a bank - I believe it would be more
important to have in such a payload,  persistent identifiers of the bank
and the originating party, rather than relying solely on recording the
`host` (HTTP/1.1) or `:authority` (HTTP/2) header fields to represent the
bank. First of all the headers change between HTTP/1.1 and HTTP/2, but also
that value is not guaranteed to be persistent, e.g. it could be `
rs2-west-03-api.bank123.com`.

My suggestion would be that for many applications, requiring `iss`, `aud`
and `iat` in the payload would be sufficient. The path and the method may
not be required.

Best Regards

Dave

On Sun, 9 Sep 2018 at 22:05, Samuel Erdtman <[email-masked]> wrote:

> On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt <
> [email-masked]> wrote:
>
>> Hi Samuel,
>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 10 Sep 2018 12:11:39 +0300

Hi Samuel,

Thanks for the quick update. Factoring out the c14n to a separate
independent spec resulted in a much clearer draft. I don't see anything
missing in terms of spec have it implemented.

Can you suggest a Java library that can handle the c14n
(rundgren-json-canonicalization-scheme)? We already have the JOSE
infrastructure, and I was wondering how we could plug in the c14n.

Vladimir

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 10 Sep 2018 21:35:34 +0200

Hi Vladimir

I have published an implementation created by Anders. You can find it here
https://github.com/erdtman/java-json-canonicalization

I have tested to add support for this in a JavaScript JOSE implementation
(node-jose), it was super easy (just hours of work).

Best regards

On Mon, Sep 10, 2018 at 11:11 AM, Vladimir Dzhuvinov <
[email-masked]> wrote:

> Can you suggest a Java library that can handle the c14n (rundgren-json-canonicalization-scheme)?
> We already have the JOSE infrastructure, and I was wondering how we could
> plug in the c14n.
>
> Vladimir
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <[email-masked]> <[email-masked]> wrote:
>
>
> On Wed, 5 Sep 2018 at 15:54, Dave Tonge <[email-masked]> <[email-masked]>
> wrote:
>
>
> Hi Samuel,
>
> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <[email-masked]> <[email-masked]> wrote:
>
>
> Hi
>
> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01> <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>.
> canonicalization schema is available in JavaScript<https://www.npmjs.com/package/canonicalize> <https://www.npmjs.com/package/canonicalize>, .NET<https://github.com/cyberphone/json-canonicalization/tree/master/dotnet> <https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>,
> Java<https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar> <https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>,
> and Python<https://github.com/cyberphone/json-canonicalization/tree/master/python3> <https://github.com/cyberphone/json-canonicalization/tree/master/python3>.