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

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Mar 2019 09:25:15 +0100

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 <[email-masked]>
To: 104Attendees <[email-masked]>

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Mar 2019 09:49:06 +0100

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

If base64-coding data seems awkward, don’t do that, and use CBOR.  
No need to invent anything.  The rest stays exactly as it is.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Mar 2019 09:57:09 +0100

> No need to invent anything.  The rest stays exactly as it is.

In this particular case it was rather the need for introducing a redundant outer layer that caught my eye.

Personally, I would nuke JSON for TEEP since all data is either Base64-encoded or is encrypted (or both) making it a fairly poor candidate for a text based system.
And yes, CBOR would be the natural answer to that of course!

If CBOR/COSE can fix this outer layer thing it would be perfect.  For this particular mission.

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Mar 2019 10:10:46 +0100

> If CBOR/COSE can fix this outer layer thing it would be perfect.  For this particular mission.

In KeyGen2 which has similarities to OTrP there is very little need for Base64 and encryption is only applied to a few things that actually needs encryption.

This is not only due to canonicalization but also because it builds on attested session keys which is a more powerful scheme than the static solution used in TEEP.

Anders