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

Dev #5

Merged
merged 6 commits into from May 10, 2019
Merged

Create ietf-104-report.html

  • Loading branch information...
cyberphone committed May 8, 2019
commit 177a8bbfb1a8836b88c980919ed1f2370e4d0236
@@ -0,0 +1,114 @@
<!DOCTYPE html><html><head><title>JCS - IETF-104 Report</title><meta http-equiv=Content-Type content="text/html; charset=utf-8"><style type="text/css">
body {font-size:10pt;color:#000000;font-family:verdana,arial;background-color:white;margin:10pt}
a {font-size:10pt;color:blue;text-decoration:none}
div.json {margin-top:8pt;margin-bottom:15pt;word-break:break-all;width:800pt;background:#F8F8F8;border-width:1px;border-style:solid;border-color:grey;padding:10pt;box-shadow:3pt 3pt 3pt #D0D0D0}
div.header {font-size:12pt;margin-top:15pt;margin-bottom:8pt;font-family:arial,verdana}
code {font-size:9pt;font-family:'Courier New',Courier}
div.claim {font-style:normal;margin-top:20pt;font-weight:bolder}
div.response {margin-top:10pt}
</style></head>
<body>
<div style="margin-top:20pt;margin-bottom:20pt;text-align:center;font-size:20pt;font-family:'Times New Roman',Serif">JCS - IETF-104 Report</div>
<i>There were in total 100 minutes of meeting time (including a 1 hour
side meeting with 10+ participants) devoted to JCS at IETF-104.
Here is a list of issues raised during these meetings.
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>,
the core rationale is simply "keeping JSON as JSON even when signed".
</p>

<div class="claim">
The need for clear text messages is a weak argument
</div>
<div class="response">
The <a href="https://tools.ietf.org/html/rfc7515"
target="_blank">current solution</a> requires you to:
<ul>
<li>
Encode JSON data to be signed in Base64Url
</li>
<li>
Disrupt the natural structure of messages by embedding
signed message data in specific signature containers
</li>
</ul>
None of the Open Banking systems out there have to date choosen
this route, they all build on variants using clear text JSON data.
That none of them utilize JCS is quite logical since
JCS is (correctly) not perceived as a standard.
</div>

<div class="claim">
Canonicalization introduces security vulnerabilities
</div>
<div class="response">If the canonicalization scheme is incorrectly implemented
(irrespective in which end), the likely result is that signatures will not validate.
Broken signatures in similarity to any other input error, including missing or
incorrectly formatted data should in a properly designed application lead to a
rejected message/application failure. The core of a JCS implementation is
typically only <u>a couple of kilobytes of executable code</u>
so it should be easy to verify for correctness.
</div>

<div class="claim">
Number serialization is major 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.
</div>

<div class="claim">
You should have stayed with the ES6 predictive parsing/serialization scheme
</div>
<div class="response">
That had been cool but the sentiment among other JSON tool vendors were
that "ECMA got it all wrong" so
<u>I was forced to select another and more conventional route</u>.
Fortunately, the revised scheme turned out to be very simple to get running
in other platforms including Go, Python, C# and Java/Android, while leaving
parsers or serializers unchanged.
The <a href="https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01"
target="_blank">original concept</a> would OTOH
require a total rewrite of the entire JSON landscape.
Sometimes "pushback" is just good 😀
</div>

<div class="claim">
You need a data model
</div>
<div class="response">
JCS builds on the same a bare-bones data model for primitives as JSON
(null, true, false, numbers, strings), albeit with a couple of constraints:
<ul>
<li>
JSON Numbers MUST conceptually be treated as IEEE-754 double precision data
</li>
<li>
JSON Strings MUST (modulo escaping) be treated as immutable during parsing/serialization
</li>
</ul>
This is all what's needed 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
<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>

<div class="claim">
I-JSON (JCS builds on that) only says SHOULD for IEEE-754 while JCS says MUST
</div>
<div class="response">
That is correct but if you for example send 64-bit integers expressed as
JSON Numbers to a JavaScript system, applications will typically break
every now and then since the inherent precision is only 53 bits.
JCS is designed to also be JavaScript compatible.
</div>
<div style="margin-top:30pt">Version 1.0, Anders Rundgren 2019-05-08</div>
</body></html>
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.