Subject: Re: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)

From: Mike Jones <[email-masked]>
Date: Fri, 10 Jul 2020 20:21:53 +0000

I must admit, I was surprised to see this RFC, because very little discussion of it happened on the JOSE mailing list.  The last mention I can see of it was in February 2019 - the same time you were proposing to take this to SecDispatch.  I never heard of it again after that.

So that any future related efforts have an opportunity for widespread review, particularly if they are JOSE related, I'd request that you and others working on them also post drafts to the JOSE mailing list, even if you're working in the Independent Stream.

There are things I would have commented on in JCS if I'd seen intermediate drafts before it became an RFC.  (For instance, I would have asked for explicit serialization instructions for the one ASCII control character not in the range 0x00-0x1F - 0x7F (DEL).)

				Thanks,
				-- Mike

-----Original Message-----
From: jose <[email-masked]> On Behalf Of Anders Rundgren
Sent: Friday, July 10, 2020 11:41 AM
To: [email-masked]
Subject: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)

After virtually eons of time https://www.rfc-editor.org/rfc/rfc8785 has finally been published.
It wouldn't have happened without the input from the IETF community!

Since canonicalization in itself is fairly useless, there are several additional work-items building on JCS (RFC 8785) in the pipe-line:

On-line demo/test using JWS: https://mobilepki.org/jws-jcs On-line demo/test using an "unwrapped" JWS called JSON Signature Format (JSF): https://mobilepki.org/jsf-lab

A real-world implementation by OWASP using JSF: https://cyclonedx.org/use-cases/#authenticity

There is also an "unwrapped" JWE called JSON Encryption Format (JEF), currently published as an HTML document: https://cyberphone.github.io/doc/security/jef.html

If anybody out there would be interested in "RFC-ing" JWS-JCS, JSF, or JEF, please drop me a line.

The current plan is publishing the additional RFCs using the Independent Stream, rather than as IETF standards.

Anders

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Jul 2020 22:43:46 +0200

On 2020-07-10, at 22:21, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> There are things I would have commented on in JCS 

Much of what discussion we had happened on the JSON mailing list.
There is a map (JSON object) key ordering mechanism in there for which I only have the word “sick”, and this was commented on the JSON mailing list [1] (in slightly more elaborate wording).  That “feature” is still in there.  No comment.

The disturbing part is that people are now running ahead and are trying to do run-arounds around the JOSE format based on the old XMLDSig thinking.  I certainly suspected that was the point of JCS, but it plaid no role in the IESG conflict review for this independent submission — I have seen very inconsistent levels of attention in IESG to considerations about how a spec will actually be used over time.

Grüße, Carsten

[1]: <https://mailarchive.ietf.org/arch/msg/json/IePAqXNJ3On_mSRbJGn6zYt-HRs>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Jul 2020 14:21:33 -0700

> The disturbing part is that people are now running ahead and are trying to do run-arounds around the JOSE format based on the old XMLDSig thinking.  I certainly suspected that was the point of JCS,…

https://tools.ietf.org/html/rfc5742#section-3 seems pretty clear that the
IESG reviews the work that is being presented for publication on the
Independent Submission stream, which would seem to exclude extensive
consideration of what might be done later that builds upon such work.  I'm
not sure which of the 5 "types of conclusion" from RFC 5742 you are
proposing should have been sent (and why)...

Thanks,

Ben

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Jul 2020 23:34:48 +0200

Hi Ben,

> proposing should have been sent (and why)...

I understand that the rules are somewhat limiting the scope of consideration.

Hmm, if I were to try to publish an independent submission that defines a YANG module for TLS implementations to make their ephemeral keys available over NETCONF, I’m sure I wouldn’t even get beyond the ISE, much less the IESG — you *would* consider "what might be done later that builds upon such work", and would choose 3 or 5.

But I didn’t write this to criticize the IESG (and my objective is certainly not to make it harder to publish independent submissions; I think overall we got this about right at the moment), but more to lay out to JOSE the inevitable consequences to what’s ahead of us.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 11 Jul 2020 08:50:25 +0200

Hi Mike,

> I must admit, I was surprised to see this RFC, because very little discussion of it happened on the JOSE mailing list.  The last mention I can see of it was in February 2019 - the same time you wer…

Well, it was mentioned that a separate mailing-list had been created for discussing the I-D.  This was done to not "spam" the JOSE list with things that were of no interest.  There were a few but useful topics discussed there which indeed are reflected by the RFC.

> So that any future related efforts have an opportunity for widespread review, particularly if they are JOSE related, I'd request that you and others working on them also post drafts to the JOSE mai…

Sure. If we stick to "features", the documents referred to should give you a pretty good idea of what to expect. https://mobilepki.org/jws-jcs is built directly on top of JOSE, while the other schemes [currently] are not.

With respect to JOSE, it seems that right now, the biggest challenge for the IETF is dealing with topic I presented in a SEC-DISPATCH session at IETF-104, that is, "Signed HTTP Requests".  Due to the lack of progress in this space, ETSI have recently published their take on the matter as well.  ETSI are targeting Open Banking so it may impact the entire "market".

FWIW, I have not given up this subject because "Signed and Serializable HTTP requests using JSON" seems be a unique feature.  Serialization enables counter-signatures which is a core component of a universal payment authorization system known as "Saturn".  For this particular system, counter-signatures are also used for simplifying state-holding and referencing by embedding preceding related messages (aka "Russian Doll").  Counter-signatures are also useful for digital contracts in block-chain systems.

> There are things I would have commented on in JCS if I'd seen intermediate drafts before it became an RFC.  (For instance, I would have asked for explicit serialization instructions for the one ASC…

Serialization of JSON tokens follows ECMAScript to 100% so the string serialization algorithm is essentially just a copy.

Thanx
Anders

---

From: David Waite <[email-masked]>
Date: Sat, 11 Jul 2020 01:25:57 -0600

> On Jul 11, 2020, at 00:50, Anders Rundgren <[email-masked]> wrote:

Neither IETF nor ECMA variants of JSON actually define required escaping for the high control points (0x7F-0x9F). So this is likely fairly consistent, if arguably bad behavior.

In the node REPL (which is the same JSON code as Chrome):

> console.log(JSON.stringify({"a":"\u007f"}))
{"a":""}

Printing the code points, that is an inline DEL character in the JSON stringified output.

-DW

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 11 Jul 2020 09:55:49 +0200

> Printing the code points, that is an inline DEL character in the JSON stringified output.

Arguably, this is really a JSON problem and not a JCS one.

There are many “non-printables” in Unicode, and JSON chose to require escaping only U+0000 to U+001F (and \ and ").  U+007F to U+009F is not the only range of interest here, think U+2028 and U+2029, or even U+200D.

I think the idea of JSON as a (readable) “text” form only ever worked to the first approximation.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 11 Jul 2020 15:10:43 +0200

> There is a map (JSON object) key ordering mechanism in there for which I only have the word “sick”, and this was commented on the JSON mailing list [1] (in slightly more elaborate wording).  That “…

Hi Carsten,

The chosen solution may not be "perfect" but it has no proven [1] downsides either unless JSON would be fundamentally revised or the Unicode consortium would suddenly pull the plug on UTF-16.  The chance/risk for that to happen seems minimal.  Therefore JCS simply followed its JavaScript origins.  An additional problem is that there is no consensus what the "right" solution is; some people advocate for UTF-8, while other camps insist that sorting must be based on Unicode.

However, if you stick to best practices for JSON keys, like spelled out in JWK Thumbprint (RFC 7638), it doesn't even matter if you sort on UTF-8, UTF-16, or Unicode!

Could we for fairness sake, take a peek at the existing JOSE standards from a "perfection" point of view?  All "blob" contents are coded in base64url with "x5c" as sole exception.  Although I know why, the (not mentioned) rationale is actually pretty weak.  Calling it "sick" is though taking things way too far since it obviously has no consequences except for JOSE implementers. The "none" algorithm is another non-obvious JOSE ingredient.

A JCS implementation recently published on the JSON list required less than 200 lines of GO code. XML canonicalization including schema support (for dealing with default values) could easily reach 10000 lines.

Anyway, the immediate issue the former JSON members may need to focus on is "Signed HTTP Requests".  I'm there as well :-)  Maybe we meet again at some future IETF!

Best
Anders

1] https://mailarchive.ietf.org/arch/msg/json/6VJlTUpKUCXU6gKN0eg3i-GADtw/