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.