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

[Samuel Erdtman <[e-mail]>]

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


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


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


>
> > 3. So I totally get that one does not like XMLDigSig, in my opinion not
> because of the signing procedures but because of the canonicalization
> process. When I looked at it I gave up and created a hardcoded template.
> The difference in canonicalization of JSON (RFC7493 I-JSON subset)
> according to RFC8785 is like night and day compared to XML
> canonicalization. In your comment it seems like you are of the opinion that
> this effort will be as tricky as XMLDigSig. do you think so?
>
> Indeed, the RFC 8785 encoding is (ignoring potential problems on the
> numeric side) simpler than canonicalized XML, even with its weird
> regression to UTF16-land.
>
> Much of the actual problems of XMLDSig weren’t in the canonicalization,
> but in the confusion of how the data at rest was to be processed for
> signing, e.g., what part of the data at rest was contributing to the
> signing input and what the signature on that part then actually meant.  JWS
> is probably flexible enough that a carefully constructed application can
> get all this right, but we are talking about non-trivial specifications
> needed beyond the boring part of generating the byte-string signing input.
>
> > 4. Not sure I agree with “clear text” or “plain text" being bad
> descriptions. Yes what is signed is the RFC8785 transformation of the input
> data, but the signature are then put into your data keeping the data in its
> original “clear text” or “plain text" as opposed to base64-url encoded. I
> guess enveloped JWS is a more accurate name but “clear text” or “plain
> text" is easy to understand.
>
> Well, I understand that the naming you chose is a good strategy for
> selling the scheme.
> It is, however, not describing what is actually going on, and I try to
> minimize the use of misleading terminology.
>

Fair point


>
> Grüße, Carsten
>
> (*) Over at the JSON mailing list, there has been some fresh discussion
> just this week about how to get around some of the implementation
> limitations, or JSON’s (deliberate!) lack of extensibility, or both.
> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY>
> and the thread behind that.
>
>