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

Hi Carsten,

Thank you for sharing your thoughts.

I´m not sure I understand your point, maybe you could elaborate a bit (I
have some questions).
1. What do you mean with data at rest, data store in database or file? Or
is it data that does not change? Sorry I do not get it.

2. What is weird with saying "Represented in JSON"? 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)

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?

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.

Best regards
//Samuel

On Wed, Apr 28, 2021 at 5:56 PM Carsten Bormann <cabo@tzi.org> wrote:

> Signing data at rest certainly is a use case that is worth addressing.
>
> “Represented in JSON” is a weird way to say that the data model that
> describes those data at rest is somehow compatible with the JSON data model
> (which isn’t really fully defined, but that is a problem that may not hurt
> you).  So if you have a deterministic way to transform your data at rest
> into the JSON-like data model subset supported by RFC8785 (which is in turn
> based on the RFC7493 I-JSON subset), you then can use RFC8785 to generate a
> text string that (using UTF-8’s deterministic encoding) can in turn be used
> as a signing input for well-known signature schemes such as JOSE or COSE.
>
> This is pretty much what XMLDSig set out to do, except that the XML data
> model is even less well-defined and generating a deterministic signing
> input from that is even more interesting.  Small matters of
> interoperability :-)
>
> None of this has anything to do with “clear text” or “plain text", which
> is an exceedingly bad label to apply to signing data at rest that are
> believed to be convertable to an RFC8785-subset JSON text.
>
> Grüße, Carsten
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>