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

[Samuel Erdtman <[e-mail]>]

Thanks Carsten,

There was not problem reading the reply :),

To summarize my understanding you have (at least) two issues with the
current doc https://datatracker.ietf.org/doc/draft-jordan-jws-ct/
* It uses RFC8785 to create the signature input which you do not like,
since it limits the expressiveness of JSON (and uses UTF-16), CBOR could be
an alternative (but you are not pushing for it)
* You do not like putting the signature into the signed document because it
can cause all kinds of confusion, with e.g. counter signatures.

Did I capture that correctly?

Cheers
//Samuel

On Mon, May 3, 2021 at 6:06 PM Carsten Bormann <[e-mail]> wrote:

> 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
>
>