Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ietf-104-report.html #7

Merged
merged 1 commit into from May 10, 2019
Merged
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

Update ietf-104-report.html

  • Loading branch information...
cyberphone committed May 10, 2019
commit 3315e36c0bb343d25a0e4d1d0bf8459d7e6c639f
@@ -15,8 +15,8 @@
I have taken the liberty commenting them here.</i>
<p>
For those who are not familiar with JCS
<a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05"
target="_blank">(https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05)</a>,
<a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06"
target="_blank">(https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06)</a>,
the core rationale is simply "keeping JSON as JSON even when signed".
</p>

@@ -37,7 +37,7 @@
</li>
</ul>
None of the Open Banking systems out there have to date chosen
this route, <u>they all build on variants using detached clear text JSON data</u>.
this route; <u>they all build on variants using detached clear text JSON data</u>.
That none of them utilize JCS is quite logical since
JCS is (correctly) not perceived as a standard.
</div>
@@ -57,37 +57,46 @@
</p>
<p>
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 <a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06#section-5"
target="_blank">Security Considerations</a>.
</p>
<p>
In fact, the absence of clear text signatures creates issues even
for true security experts like the TEEP folks:
</p><div style="margin-left:30pt">
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:
</p>
<div style="margin-left:30pt">
<a href="https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02"
target="_blank">https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02</a>
<p>
<i>
"The top element "<name>
[Signed][Request|Response]" cannot be fully
The top element &quot;<name>[Signed][Request|Response]&quot; 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.
</i>
</p>
</div>
Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear.
By using <a href="https://mobilepki.org/jws-jcs/verify"
target="_blank">JCS with JWS</a>
the need for artificial holder objects and associated matching requirements
disappear, while message content is provided in clear.
</div>

<div class="claim" id="3">
3. Number serialization is major problem
3. Number serialization is huge problem
</div>
<div class="response">
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
<a href="https://github.com/ulfjack/ryu"
target="_blank">algorithms</a> have been developed
making number serialization according to JCS/ES6 in scope for any platform.
Extensive test data is
<a href="https://github.com/cyberphone/json-canonicalization/tree/master/testdata#es6-numbers"
target="_blank">publicly available</a>.
</div>

<div class="claim" id="4">
@@ -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
<u>do not seem to have hampered the popularity and ubiquity of JSON</u>.
Standardizing external mappings is another [possible] IETF activity, not related to JCS.
</div>
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.