Subject: [Teep] OTrP Proposal - Removing Redundant Message Layer

From: Anders Rundgren <[email-masked]>
Date: Wed, 24 May 2017 07:49:37 +0200

Hi TEEers,

As an alternative (or maybe a complement) to the session-key proposal
https://mailarchive.ietf.org/arch/msg/teep/qs-4aXf2Fx9mrBOz6Kj8f1Mk7G8
you may consider evaluating an alternative to JOSE for signatures.

The JOSE standards stack is awesome but was designed for the needs of OpenId and such rather than security protocols in general. Another corner stone for the JOSE work was that there is no such thing as JSON canonicalization which is why data is dressed in Base64URL.  However, the latter changed with the advent of EcmaScript version 6 which specifies an exact method for serializing JavaScript/JSON objects which is already implemented in most Browsers, Node.js, as well as in Android* and Java* in general.  In fact (modulo floating point), it works flawlessly in most other platforms as well.

Now to the actual issue.  I have taken the liberty analyzing the consequences of using JWS in OTrP:

https://tools.ietf.org/html/draft-pei-opentrustprotocol-03#section-7.4

             "The top element " <name>[Signed][Request | Response]" cannot be
              fully trusted to match the content because it doesn't participate 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."

SIDE-EFFECT: JWS introduces additional signature verification steps

https://tools.ietf.org/html/draft-pei-opentrustprotocol-03#section-8.2.1.3

Top level message object:
             {
                  "CreateSDResponse": {
                    "payload":"<CreateSDTBSResponse JSON>",
                    "protected": {
                       "<BASE64URL of signing algorithm>"
                    },
                    "signature": "<signature contents signed by TEE device private   key (BASE64URL)>"
                  }
                }

Payload:
              {
                  "CreateSDTBSResponse": {
                    "ver": "1.0",
                    "status": "<operation result>",
                    "rid": "<the request ID received>",
                    "tid": "<the transaction ID received>",
                    "content": ENCRYPTED {
                      "reason":"<failure reason detail>", // optional
                      "did": "<the device id received from the request>",
                      "sdname": "<SD name for the domain created>",
                      "teespaik": "<TEE SP AIK public key, BASE64 encoded>",
                      "dsi": "<Updated TEE state, including all SD owned by    this TSM>"
                    }
                  }
               }

SIDE-EFFECT: JWS forces you adding artificial message layers in order to get a reasonable message structure.

By combining ES6 Serialization, JSON Web Algorithms (JOSE/JWA) and JSON Web Key (JOSE/JWK), you can stay pretty close to JOSE while getting away from the current two-level messaging scheme in addition to having header information in clear: https://cyberphone.github.io/doc/security/jsonsignatures.html

Although not on any IETF standard track, this is not a research project, JCS (JSON Cleartext Signature) is fully documented and supported by an extensive set of test vectors and working code.

Cheers,
Anders
Co-inventor of signed JavaScript/JSON objects
https://github.com/cyberphone/openkeystore#openkeystore

* Through third-party libraries