Re: [Teep] [EXT] OTrP Proposal - Removing Redundant Message Layer

[Mingliang Pei <[e-mail]>]

Hi Anders,

Thank you for your comments and suggestions. I was on vacation and travel,
and just circle back on this. Please see my comments inline.

Overall, I did hope that JOSE signature can be inline as JCS for easier
readability without being in the encoded form but I do see much bigger
benefit to leverage well discussed and approved standard JOSE for
achieving implementation interoperability. If JCS can get further
alignment within IETF as an alternative JSON signature standard, I am open
to support it. We know the history of XML signature - enveloped and
attached flavors. I didn¹t get into the JOSE discussion of the final
choice but I knew that canonicalization was complex to handle. The
overhead of Base64URL of payload looks to be tolerable if not ideal in
this usage context here, I think.

How do you see the traction that JCS becomes a commonly endorsed standard
format? 

Thanks,

Ming

On 5/23/17, 10:49 PM, "TEEP on behalf of Anders Rundgren"
<[e-mail] on behalf of [e-mail]> wrote:

>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

Ming: right. The naming is a reference, and can be compared with the name
in the payload that has integrity check. The overhead is pretty small or
trivial in my consideration, leveraging JOSE while providing some quick
reference benefit without decoding. It is a balance.

>
>
>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.

Ming: the payload data itself can freely have any data content we need to
construct for OTrP logic. It just goes back to the encoding to get payload
and the JOSE signature.

>
>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.

Ming: thanks for your work. I trust it is well written and tested. Just
for standard reference, I am personally inclined to leverage what has been
approved JSON after many considerable debates and compromise for
interoperability. Happy to discuss further here and at Prague if you are
going. Thanks again for your improvement suggestion.

>
>Cheers,
>Anders
>Co-inventor of signed JavaScript/JSON objects
>https://clicktime.symantec.com/a/1/QTy_yBCUNYZo9tIyB1dIFw0oU5d_qTtMg1iQZNC
>hLtQ=?d=H1RqBoAz6Y6IDyLUoGRp6kVw-Qep7vDUn0dbUlh75Rjsxyxc5WkwHTZm5rN7aT9qnG
>pI-VF8jgfJSICAEGQjVGq0UVUkXypftYQeaNBTYhG73dVHczyC_w405LsuUV9elouoIWeZVz-v
>56y-nOct4hnWBHZbsJ27bdVdshzT8N1OgpfTNF6skQp5qTIzGvYaGXkpWmi9FTqlFpYsMcM0la
>g32Fv2kiYAHiJBWtlPlD-E4ebDPyTUoZKB1WLGphwu0jnVc0HVM5Y5iyTQtCG0UFP9JgdEVamw
>B-WPU8l0518eiQ_sqIx71zVgggh9G2d9zyXz3aQq_pUBb4Ky3HzsTrpo1wkF7gRfutAsnCsJWo
>uCkhN7ZkB33OSAesgr5A2r_RGsnpNn6YScZ7kBiJzG&u=https%3A%2F%2Fgithub.com%2Fcy
>berphone%2Fopenkeystore%23openkeystore
>
>* Through third-party libraries
>
>_______________________________________________
>TEEP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/teep