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

[Samuel Erdtman <[e-mail]>]

Hi Carsten,

One more thing, you wrote "Signing data at rest certainly is a use case
that is worth addressing.". With my new fond insights (thanks) does this
mean that you are in favor of specifying how to do enveloped signatures for
JSON (or at least not against it)?

Cheers
//Samuel


On Sat, May 1, 2021 at 11:24 PM 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).
>
>
>>
>> > 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.
>>
>>