Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures

[Carsten Bormann <[e-mail]>]

Hi Samuel,

I haven’t responded to your message yet as it triggers some MacOS mail misbehavior.
Let me try anyway, I hope you can parse the result.

> On 2021-05-01, at 23:24, Samuel Erdtman <[e-mail]> wrote:
> 
>> Thanks Carsten,
>> 
>> Your clarifications were great!
>> 
>> See some comments inline.
>> 
>> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <[e-mail]> wrote:
>> Hi Samuel,
>> 
>> > 1. What do you mean with data at rest, data store in database or file?
>> 
>> The point is that you are not signing the data being transferred, but a local copy of some (e.g., freshly decoded) data (i.e., at the data model level) which is then processed a little (potentially taking out all signatures) and then is run through a rather complicated engine to produce a signing input that is a deterministic function of the decoded and processed data.
>> 
>> There are easier ways to get a signing input from JSON-like data at rest.
>> For a (quite workable) strawman: How about doing a CBOR encoding using deterministic encoding rules?
> 
> This is a good point. Still not convinced other solutions would be orders of magnitude better and the proposed one is easy to implement and easy to understand (maybe too easy since I had not thought about your alternative solution). 

It is hard to measure interoperability in orders of magnitude…
Doing a CBOR signing input is easy to implement and easy to understand, though.
No UTF-16 needed :-)

>> > Or is it data that does not change? Sorry I do not get it.
>> > 
>> > 2. What is weird with saying "Represented in JSON”?
>> 
>> Your scheme does NOT require (or benefit in any way from) representing the data in JSON.
>> The data could be transferred in YAML (or CBOR for that matter): as long as your local copy of the decoded data (after the little processing) sticks inside the confines of the I-JSON data model, you can use your scheme for signing.
>> 
> But since JSON according to https://tools.ietf.org/html/rfc7159 is fairly flexible, would not fitting it into CBOR require similar limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitations)

It does require some thinking.
https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 documents what we arrived at when discussing that in the CBOR WG.

(I’m very well aware that many applications would be content with just I-JSON, because they already have made their peace with it to enable JavaScript classic processing.  So I’m just answering the question here.)

>> > is it that the RFC7493 I-JSON subset is not all that JSON could be? (to me this is a reasonable limitation that I in practice never have had to go outside)
>> 
>> Well, that has been debated to death, and it is clear that nobody likes I-JSON (*), but it is the de-facto boundary within which the actually more capable JSON format needs to be used these days.
>> (If you need more flexibility, you know where to find CBOR.)
>> 
> So are you saying that CBOR would not impose the same limitations on the original JSON as RFC8785? 

Yes.  Again, please see https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2

Please note that I’m not making these points to push CBOR, even though I’m really convinced CBOR and its “JSON mode” can play a helpful role in addressing the underlying requirements.

Grüße, Carsten