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

[Anders Rundgren <[e-mail]>]

On 2017-07-01 03:57, Mingliang Pei wrote:
> Hi Anders,

Hi Ming,

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

This is a question that is not only technical, but political. Converting JCS
into an RFC is probably quite possible but without backing from a more noteworthy
entity, I wouldn't mean that much.  The JOSE WG is concluded BTW.

IMO, standards need an application to thrive, JOSE WG was effectively created
by the needs of OpenID including URL-safe signatures.

JCS was designed for information-rich applications that previously typically
would be expressed in XML like payments.  JCS dropped the canonicalization
requirement by building on ECMA's definition of JSON.parse() and JSON.stringify().
This scheme was neither known nor considered by the JOSE WG.

It is important to get the proportions right here, we are talking about
*extremely simple code* compared to XML canonicalization.

If the TEEP WG consider message readability and the Message/TBS layer design
a minor issue, JWS is an obvious choice.  I would do the same :-)

Outside of the IETF, I don't think many people is going to dress their precious
messages in Base64 since it has been proved (by multiple parties working with standards
in this space including the W3C), to be unnecessary and obstructing message syntax.

For my work JWS was sort of "impossible" since some of it builds on signed messages
enveloping other signed messages (counter-signing).  Nowadays there is also an
encryption counterpart which shares the JCS clear text notion and JWK support for
header elements: https://cyberphone.github.io/doc/security/jef.html

I would love to go Prague, but I'm currently rather busy with a payment consultant
job. A tele-conference would be quite possible just about anytime if you would be
interested in discussing JCS.

Regards,
Anders

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