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

On 2021-05-01 1:04, Carsten Bormann wrote:

 > Your scheme does NOT require (or benefit in any way from) representing the data in JSON.

I don't have an answer or solution for people who firmly believe that JSON is (more or less) useless.

Stepping-up the game a bit :)
We have had 25y+ (!) of non-standard, security-broken, and user-hostile on-line payment-systems.  AFAIK, the following document is currently the ONLY specification that addresses this obvious deficiency:
https://fido-web-pay.github.io/specification/#operation
Browsers, FIDO, JavaScript, JSON, JWS, JWE, RFC 8785, and JWS/CT are the corner stones of this proposal. Yes, there is even a spoon with CBOR/COSE there.

Regarding RFC 8785, it works as claimed for applications adhering to two fairly reasonable requirements:
- Sticking to I-JSON where the SHOULDs are interpreted as MUSTs.
- Using parser schemes that do not mess up data embedded in JSON strings (like converting "2021-05-01T10:00:00Z" to "2021-05-01T09:00:00+01:00").

In all "modesty",
Anders

> 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?
> 
>> 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.
> 
>> 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.)
> 
>> 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.
> 
> 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.
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 