[Teep] Fwd: Side-meeting: Canonical JSON, Signed REST

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 27 March 2019 08:25 UTC

References: <4944d01f-4565-9688-8833-1c8b287c6ae0@gmail.com>
To: "teep@ietf.org" <teep@ietf.org>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <5e1c4ee8-0e8f-d1b7-2fca-759d2aaadb45@gmail.com>
Date: Wed, 27 Mar 2019 09:25:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <4944d01f-4565-9688-8833-1c8b287c6ae0@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/lrAfYuWoNo1Utr4f8uUjo5lZcwo>
Subject: [Teep] Fwd: Side-meeting: Canonical JSON, Signed REST
Precedence: list

I hope you didn't mind me mentioning TEEP/OTrP as a [partially] awkward solution...

-------- Forwarded Message --------
Subject: Side-meeting: Canonical JSON, Signed REST
Date: Wed, 27 Mar 2019 06:52:39 +0100
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: 104Attendees <104attendees@ietf.org>

Wednesday 14-15 in Paris.

My presentations at IETF-104 couldn't go into details, so here some additional facts and motivations.

The lack of canonicalized JSON have had quite practical implications in IETF security protocols like in this one:

https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02

    "The top element "<name>[Signed][Request|Response]" cannot be fully
     trusted to match the content because it doesn't participate in the
     signature generation.  However, a recipient can always match it with
     the value associated with the property "payload".  It purely serves
     to provide a quick reference for reading and method invocation"

That is, the TEEP folks were forced adding a redundant (and IMO pretty ugly) JSON layer in order to tag objects since the JWS signature scheme dresses the payload in Base64Url.  This scheme also introduces an additional validation step.

This is sort of the opposite to my own work in this space, where canonicalization is also applied to the JWS container itself (aka clear text signatures).  Here an example from "Saturn":

   {
       "requestHash": {
           "alg": "S256",
           "val": "cA-QNdJHcynjuM44ty-zXgXwx100AZVRFLmYx1So0Xc"
       },
       "domainName": "demomerchant.com",
       "paymentMethod": "https://bankdirect.net",
       "accountId": "8645-7800239403",
       "timeStamp": "2019-03-23T10:33:02+01:00",
       "signature": {
           "alg": "ES256",
           "jwk": {
               "kty": "EC",
               "crv": "P-256",
               "x": "rQ4WXMB6_wQKHSiY_mbJ4QkGpfWLssF7hvIiiFpDEx8",
               "y": "Fh2rl0LGTtvaomOuhuRNo9Drz9o0--WXV2ITvdVQFRY"
           },
           "val": "j2LL9pr2RyrPxvFlj8IzMhno5vvgGIgf2xi23dA5u_XwjYlIvT9qwIVKaCKYwjb26J5mMUL5zV02lqQGjZRClw"
       }
  }

Recent proposal addressing Signed/JSON/REST since this apparently still is missing:
https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00
https://datatracker.ietf.org/meeting/104/materials/slides-104-hotrfc-3-signed-http-requests-shreq-00

Bring your rotten tomatoes if you want :-)

Cheers,
Anders

[Teep] Fwd: Side-meeting: Canonical JSON, Signed … Anders Rundgren
Re: [Teep] Fwd: Side-meeting: Canonical JSON, Sig… Carsten Bormann
Re: [Teep] Fwd: Side-meeting: Canonical JSON, Sig… Anders Rundgren
Re: [Teep] Fwd: Side-meeting: Canonical JSON, Sig… Anders Rundgren