From 3315e36c0bb343d25a0e4d1d0bf8459d7e6c639f Mon Sep 17 00:00:00 2001 From: Anders Rundgren Date: Fri, 10 May 2019 06:55:27 +0200 Subject: [PATCH] Update ietf-104-report.html --- ietf-104-report.html | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/ietf-104-report.html b/ietf-104-report.html index f3baf4d..bbc919b 100644 --- a/ietf-104-report.html +++ b/ietf-104-report.html @@ -15,8 +15,8 @@ I have taken the liberty commenting them here.

For those who are not familiar with JCS - (https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05), + (https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06), the core rationale is simply "keeping JSON as JSON even when signed".

@@ -37,7 +37,7 @@ None of the Open Banking systems out there have to date chosen - this route, they all build on variants using detached clear text JSON data. + this route; they all build on variants using detached clear text JSON data. That none of them utilize JCS is quite logical since JCS is (correctly) not perceived as a standard. @@ -57,37 +57,46 @@

It has been mentioned that clear text data will tempt developers into trusting - (=using) data without first verifying signatures. JCS obviously does not + (=acting upon) received data without verifying signatures. JCS obviously does not come with a cure for naïve developers. + See JCS Security Considerations.

- In fact, the absence of clear text signatures creates issues even - for true security experts like the TEEP folks: -

+ In fact, the absence of clear text signatures also creates security issues as shown + by the following example from IETF's Trusted Execution Protocol WG: +

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

- "The top element " - [Signed][Request|Response]" cannot be fully + The top element "[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" + to provide a quick reference for reading and method invocation.

- Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear. + By using JCS with JWS + the need for artificial holder objects and associated matching requirements + disappear, while message content is provided in clear.
- 3. Number serialization is major problem + 3. Number serialization is huge problem
I clearly underestimated this part when I started with JCS back in 2015, but - recently fast and quite simple algorithms have been developed, making number - serialization according to JCS/ES6 in scope for any platform. - Extensive test data is also publicly available. + recently fast, open sourced and quite simple + algorithms have been developed + making number serialization according to JCS/ES6 in scope for any platform. + Extensive test data is + publicly available.
@@ -123,7 +132,7 @@ This is all what is needed with respect to data models for creating reliable and interoperable "hashable" JSON. Existing JSON-based systems use external mappings to emulate missing data types like "DateTime", "Money", "Binary" and similar. - That not all JSON applications not use the same conventions + That not all JSON applications use the same conventions do not seem to have hampered the popularity and ubiquity of JSON. Standardizing external mappings is another [possible] IETF activity, not related to JCS.