Subject: [Secdispatch] Plain text JSON digital signatures

From: Bret Jordan <[email-masked]>
Date: Tue, 27 Apr 2021 09:27:17 -0600

Dear Dispatch,

Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your
consideration. This document describes how to use JWS and JCS to create
plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending the scope of the JSON Web
Signature (JWS) standard, called JWS/CT.  By combining the detached mode of
JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON
objects to remain in the JSON format after being signed (aka "Clear Text"
signing).  In addition to supporting a consistent data format, this
arrangement also simplifies documentation, debugging, and logging.  The
ability to embed signed JSON objects in other JSON objects, makes the use
of counter-signatures straightforward.

The data tracker page for this:
https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that needs digital signatures for
plain text JSON data, meaning where the JSON data is not base64 encoded.
This ID provides a solution using existing IETF RFCs to make this work.
Further, this work looks to be adopted by many groups and organizations
from financial services, threat intelligence, and incident response.

We are not sure what direction would be best for this work in the IETF,
should we send to the ISE for publication or do you want to create a
working group. Ultimately there is a lot of work that could be done in this
space to meet the needs of the market. We would be happy with releasing
these IDs for ISE publication, or for creating a working group to move them
forward. It is just important to note that the market is in desperate need
of these solutions. If you want to take it for a spin, there is a JWS/CT
playground at: https://mobilepki.org/jws-ct

Thanks
Bret

-- 

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Apr 2021 11:47:03 -0400

I am very much interested in this work.  My preference would be for a Proposed Standard.  There was a lot of opposition to the idea previously, so it may be that ISE is all we can get, but I would be willing to work towards PS, either in a new, short lived work group or as part of another work group.  

Brian

> On Apr 27, 2021, at 11:27 AM, Bret Jordan <[email-masked]> wrote:
> 
> Dear Dispatch,
> 
> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows:
> 
> This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging.  The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward.
> 
> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ <https://datatracker.ietf.org/doc/draft-jordan-jws-ct/>
> 
> As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response. 
> 
> We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct <https://mobilepki.org/jws-ct>
> 
> Thanks
> Bret
> 
> -- 
> 
> Sent from my TI-99/4A
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 18:21:59 +0200

On 2021-04-27, at 17:47, Brian Rosen <[email-masked]> wrote:
> 
> There was a lot of opposition to the idea previously,

Yes.

But there is also some opposition to the weird way this is presented:

>> JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  

We have a lot of ways that enable signed objects to remain in the format in which they were at signature time.

Maybe we can fix the presentation of the idea more towards “we really liked XMLDsig and want it back for JSON”, which is certainly a position one can take.

Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Tue, 27 Apr 2021 11:42:26 -0600

Hi Brian,

Yes, there are are lot of people and organizations that are looking for a solution like this. There are several that I know of that are already looking to adopt this or something similar in production. I also know Anders has been doing a lot of work in the financial sector using this for payment processing. What people need to realize is that plain text signatures and plain text JSON is a fundamental requirement. The proof of concept code I have written so far shows that this works, and works really well. 

It is great to hear that you would support this work, either through a PS or via the ISE. Please let us know if you have any feedback on the ID. 

Thanks
Bret

> On Apr 27, 2021, at 9:47 AM, Brian Rosen <[email-masked]> wrote:
> 
>> On Apr 27, 2021, at 11:27 AM, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear Dispatch,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 28 Apr 2021 01:48:46 +0200

>> There was a lot of opposition to the idea previously,

Dear Carsten,
There were indeed a lot of opposition at IETF-104 but nobody has to date bothered providing a single example showing why this idea {w|sh}ould not work [1].

If we take the better [and fully standardized] alternative (JWS), it transforms a JSON object into a Base64Url-encoded string and then puts it into a specific signature container.  That is, the result bears very little similarity to the original which obviously is a drawback. Then a [moderately] skillful attacker replaces the algorithm in the JWS header with the standardized "none" and the whole thing passes validation with flying colors [2].

Anyway, variants of detached (enveloped) JWS signatures in JSON are likely to become a de-facto standard.  Here is an example from a very active group withing the W3C:
https://w3c-ccg.github.io/ld-proofs/#example-2-a-simple-signed-linked-data-document

Feel free rearchitecting https://fido-web-pay.github.io/ using the current JOSE stack; it might even be fun :)

BTW, I have just started the design of a CBOR library needed for dealing with CTAP2/FIDO for the project above.  CBOR seems pretty cool.

Regards,
Anders

1] In all fairness, it does require a bit of work for the application developer who may have to adjust the parsing scheme (not the parser) for things like RFC3339 data.

2] In a n00b world, where developers do not understand that a compliant JWS library does not necessarily come with suitable default policies.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 27 Apr 2021 18:38:33 -0700

I am supportive of this work, and would also be willing to work towards a
PS. I am seeing rapid growth in the demand to embed JWS in JWS.

Given my experience with XML-DSig (see below) making it more XML-DSig like
does not sound like a good thing.

For any interested in some JWT history, when we were brewing up what became
OAuth 2.0, we did not want to tie a token format to the implementation as
many deployments had their own proprietary token formats -- but we knew new
deployments would benefit from standardizing a token.

Our requirements were:
- URL safe (access tokens at the time were often passed as a query
parameter -- I know, not the best idea, but working with what people wanted)
- HTTP header safe
- richer than name / value pairs

Options we considered:
ASN.1 - the 60s are calling and want their data back
XML-DSig - not URL safe, large size, and I personally had many scars
canonicalizing XML. (An earlier company of mine had a contract to build
XML-DSig libraries for a few languages)

JSON was becoming very cool at that time, and with base 64 URL safe
encoding the string, it was URL safe, and treating the JSON text as binary
dealt with the canonicalization concerns -- and JSON canonicalization did
not exist.

Using a dot as the separator between header, payload, and signature made it
easy to parse. The dot was URL safe, but not in the base 64 set.

And Simple Web Tokens were born -- to be renamed JSON Web Tokens.

/Dick

ᐧ

On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <[email-masked]> wrote:

> Dear Dispatch,
>
> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for
> your consideration. This document describes how to use JWS and JCS to
> create plain-text JSON signatures. The abstract reads as follows:
>
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Bret Jordan <[email-masked]>
Date: Tue, 27 Apr 2021 20:29:03 -0600

Luckily this time we have RFC8785 that solves the canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64

> On Apr 27, 2021, at 7:39 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS.
> 
> Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing.
>  
> For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token.
> 
> Our requirements were:
> - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted)
> - HTTP header safe
> XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages)
>  
> JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist.
> 
> Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set.
> 
>> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/
>> 
>> We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct
>> 
>> Thanks
>> Bret
>> 
>> -- 
>> 
>> Sent from my TI-99/4A
>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Apr 2021 08:52:04 +0200

How is this different/better than implementing RFC 7797 and apply the
header b64=false in order to carry plaintext JSON in the payload?

/Stefan

On 2021-04-28 04:29, Bret Jordan wrote:
>> I am supportive of this work, and would also be willing to work
>> towards a PS. I am seeing rapid growth in the demand to embed JWS in
>> JWS.
>>
>> For any interested in some JWT history, when we were brewing up what
>> became OAuth 2.0, we did not want to tie a token format to the
>> implementation as many deployments had their own proprietary token
>> formats -- but we knew new deployments would benefit from
>> standardizing a token.
>>
>> Our requirements were:
>> canonicalizing XML. (An earlier company of mine had a contract to
>> build XML-DSig libraries for a few languages)
>>  
>> encoding the string, it was URL safe, and treating the JSON text as
>> binary dealt with the canonicalization concerns -- and JSON
>> canonicalization did not exist.
>>
>> Using a dot as the separator between header, payload, and signature
>> made it easy to parse. The dot was URL safe, but not in the base 64 set.
>>
>>     Anders Rundgren, Samuel, Erdtman, and I have been working on an
>>     ID for your consideration. This document describes how to use JWS
>>     and JCS to create plain-text JSON signatures. The abstract reads
>>     as follows:
>>
>>     This document describes a method for extending the scope of the
>>     JSON Web Signature (JWS) standard, called JWS/CT.  By combining
>>     the detached mode of JWS with the JSON Canonicalization Scheme
>>     (JCS), JWS/CT enables JSON objects to remain in the JSON format
>>     after being signed (aka "Clear Text" signing).  In addition to
>>     supporting a consistent data format, this arrangement also
>>     simplifies documentation, debugging, and logging.  The ability
>>     to embed signed JSON objects in other JSON objects, makes the use
>>     As you know there are large ecosystems that needs digital
>>     signatures for plain text JSON data, meaning where the JSON data
>>     is not base64 encoded. This ID provides a solution using existing
>>     IETF RFCs to make this work. Further, this work looks to be
>>     adopted by many groups and organizations from financial services,
>>     threat intelligence, and incident response.
>>
>>     We are not sure what direction would be best for this work in the
>>     IETF, should we send to the ISE for publication or do you want to
>>     create a working group. Ultimately there is a lot of work that
>>     could be done in this space to meet the needs of the market. We
>>     would be happy with releasing these IDs for ISE publication, or
>>     for creating a working group to move them forward. It is just
>>     important to note that the market is in desperate need of these
>>     solutions. If you want to take it for a spin, there is a JWS/CT
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 28 Apr 2021 11:00:05 +0200

On 2021-04-28 8:52, Stefan Santesson wrote:
> How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload?

Good question!

Apart from the fact that the data becomes embedded in the JWS signature container (=changing the structure), you cannot really put JSON there:
https://tools.ietf.org/html/rfc7797#section-5.2

My guess that the only real-world use of this option is to save an internal-only (but technically redundant) Base64Url-operation for truly detached data, be it it JSON, PNG, etc.

JWS/CT was designed for signing JSON Objects ({}), and let them remain as such.

Thanx,
Anders

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 28 Apr 2021 09:21:10 +0000

This draft is well written and an approach we would like to use in IEEE 2791, and from your text it will fit right into our “etag” field<https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/2791object.json#L129> where we hope for a consistent hashing mechanism to detect changes.

The draft seems to build on JSON Web Signature (RFC7515<https://www.rfc-editor.org/rfc/rfc7517.html>) and JSON Web Key (RFC7517<https://www.rfc-editor.org/rfc/rfc7517.html>), but the 3.1.3 is a bit too brief for readers new to these standards, perhaps give a brief summary for this example, especially as RFC7517 is quite comprehensive with many options?

In particular it is unclear if the JWS Header also needs to be JSON canonicalized – which may be a good idea for consistent “hash” purposes like in our use case?

Here’s my rough suggestion – probably wrong! My additions unindented.

3.1.3.  Generate a JWS String

   Use the result of the previous step as "JWS Payload" to the signature

   process described in Appendix F of JWS [RFC7515].

In short a detached JWS is represented as the string concatenated from

      BASE64URL(UTF8(JWS Protected Header)) || '.' ||

      || '.' ||

      BASE64URL(JWS Signature)

Notice, for comparison with the JWS Compact Serialization,

that the JWS Payload is not included in the detached JWS String,

but replaced by an empty string.

   For the example, the JWS header is assumed to be:

   {"alg":"HS256"}

The above example is equal to its own JCS canonicalization.

JSON Canonicalization is not a requirement for the

JWS Header, however this is RECOMMENDED, combined with

a fixed algorithm choice, if generating a consistent JWS/CT signature

that is s also to be used as as a canonical version identifier

of the JSON payload content, e.g. as a strong ETag (RFC7232).

The JWS Signature of the canonicalized JSON payload, using the key

specified in Section 3, is the bytes

54 75 48 b4 20 42 6f c4 39 x8 8e 3d 8a 66 ab xe

d2 5e 4b 11 f6 b8 b5 34 xe 1a 90 3f 96 63 c3

Encoding as Base64

The resulting concatenated JWS string should then read as follows:

   eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4

You may want to move my ETag recommendation to an appendix, as I don’t feel it fits well where I put it, but I think it is worth pointing out. As a use case.

I don’t know enough about RFC7515, is it possible to do something like regular SHA3 or would my fingerprint use case need to just publicly declare the signature key to use?

--
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note that I may work flexibly – whilst it suits me to email now,
    I do not expect a response or action outside of your own working hours.

From: art <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Date: Wednesday, 28 April 2021 at 03:29
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, DISPATCH <[email-masked]>, "[email-masked]" <[email-masked]>, IETF SecDispatch <[email-masked]>
Subject: Re: [art] Plain text JSON digital signatures

Bret

Our requirements were:

Options we considered:

/Dick

[Image removed by sender.]ᐧ

On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
Dear Dispatch,

Thanks
Bret

--

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
_______________________________________________
art mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/art

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Apr 2021 11:29:56 +0200

RFC 7797 is supported by common open source such as Nimbus and I use it
for instances where you obviously do not need a URL safe token.

As such it works for JWS but Not for JWT. But It works really well and
saves space when URL safeness is not needed.

So I guess your answer is that it still encapsulates the signed JSON in
the signature, and that the proposal really is about embedding signature
in the JSON object being signed (and not about whether the JSON is in
plaintext).

Could you elaborate why you think it is important to NOT embed signed
data in the signature?

What is the usecase?

/Stefan

On 2021-04-28 11:00, Anders Rundgren wrote:
> Apart from the fact that the data becomes embedded in the JWS
> signature container (=changing the structure), you cannot really put
> JSON there:
> My guess that the only real-world use of this option is to save an
> internal-only (but technically redundant) Base64Url-operation for
> truly detached data, be it it JSON, PNG, etc.
>
>>>> towards a PS. I am seeing rapid growth in the demand to embed JWS
>>>> in JWS.
>>>>
>>>> Given my experience with XML-DSig (see below) making it more
>>>> XML-DSig like does not sound like a good thing.
>>>>
>>>> For any interested in some JWT history, when we were brewing up
>>>> what became OAuth 2.0, we did not want to tie a token format to the
>>>> XML-DSig - not URL safe, large size, and I personally had many
>>>> scars canonicalizing XML. (An earlier company of mine had a
>>>> contract to build XML-DSig libraries for a few languages)
>>>> Using a dot as the separator between header, payload, and
>>>> signature made it easy to parse. The dot was URL safe, but not in
>>>> the base 64 set.
>>>>
>>>>     Anders Rundgren, Samuel, Erdtman, and I have been working on
>>>> an ID for your consideration. This document describes how to use
>>>> JWS and JCS to create plain-text JSON signatures. The abstract
>>>> reads as follows:
>>>>
>>>>     This document describes a method for extending the scope of
>>>> the JSON Web Signature (JWS) standard, called JWS/CT.  By
>>>> combining the detached mode of JWS with the JSON Canonicalization
>>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON
>>>> format after being signed (aka "Clear Text" signing).  In addition
>>>> to supporting a consistent data format, this arrangement also
>>>> simplifies documentation, debugging, and logging.  The ability to
>>>> embed signed JSON objects in other JSON objects, makes the use of
>>>> counter-signatures straightforward.
>>>>
>>>> signatures for plain text JSON data, meaning where the JSON data is
>>>> not base64 encoded. This ID provides a solution using existing IETF
>>>> RFCs to make this work. Further, this work looks to be adopted by
>>>> many groups and organizations from financial services, threat
>>>> intelligence, and incident response.
>>>>
>>>>     We are not sure what direction would be best for this work
>>>> in the IETF, should we send to the ISE for publication or do you
>>>> want to create a working group. Ultimately there is a lot of work
>>>> that could be done in this space to meet the needs of the market.
>>>> We would be happy with releasing these IDs for ISE publication, or

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 28 Apr 2021 09:52:02 +0000

… I think I got it wrong below, as the JWS Signature if I understand it correct also needs to include the JWS header?

Perhaps this is why it needs to be clarified here! 😊

From: art <[email-masked]> on behalf of Stian Soiland-Reyes <[email-masked]>
Date: Wednesday, 28 April 2021 at 10:22
To: Bret Jordan <[email-masked]>, Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF SecDispatch <[email-masked]>, DISPATCH <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [art] Plain text JSON digital signatures

      || '.' ||

      BASE64URL(JWS Signature)

   {"alg":"HS256"}

Encoding as Base64

Bret

Our requirements were:

Options we considered:

/Dick

Thanks
Bret

--

Sent from my TI-99/4A

---

From: Bret Jordan <[email-masked]>
Date: Wed, 28 Apr 2021 09:25:46 -0600

Hi Stefan,

Here is one of many use cases. Imagine a connected graph of threat intelligence data that is all represented in JSON. This data is processed, searched, analyzed, and forwarded between N number of entities. Some of the nodes in this connected graph are very large, 100 of MB to GB. Now entities 1…N  desire to sign both the nodes and the edge of this graph and issue them out to the ecosystem to increase trust and verification of the data in the graph. Entities need to be able create and issue detached signatures for data in the graph that they do not own but that they know is correct and valid. Further, a consumer of the data may need to process the signatures independently of the data in the graph. 

This is but one of many use cases where traditional JWS <header>.<b64 data>.<signature> does not work. 

Bret  

> On Apr 28, 2021, at 3:29 AM, Stefan Santesson <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Apr 2021 17:55:00 +0200

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

---

From: Bret Jordan <[email-masked]>
Date: Wed, 28 Apr 2021 11:06:37 -0600

Thanks Stian. It would be great to use this in IEEE 2791. Let's see what we need to do to make it more clear. 

Bret

> On Apr 28, 2021, at 3:21 AM, Stian Soiland-Reyes <[email-masked]> wrote:
> 
> This draft is well written and an approach we would like to use in IEEE 2791, and from your text it will fit right into our “etag” field <https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/2791object.json#L129> where we hope for a consistent hashing mechanism to detect changes.
>  
> The draft seems to build on JSON Web Signature (RFC7515 <https://www.rfc-editor.org/rfc/rfc7517.html>) and JSON Web Key (RFC7517 <https://www.rfc-editor.org/rfc/rfc7517.html>), but the 3.1.3 is a bit too brief for readers new to these standards, perhaps give a brief summary for this example, especially as RFC7517 is quite comprehensive with many options?
>  
> https://www.esciencelab.org.uk/ <https://www.esciencelab.org.uk/>
> https://orcid.org/0000-0001-9842-9718 <https://orcid.org/0000-0001-9842-9718>
> From: art <[email-masked] <mailto:[email-masked]>> on behalf of Bret Jordan <[email-masked] <mailto:[email-masked]>>
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, DISPATCH <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, IETF SecDispatch <[email-masked] <mailto:[email-masked]>>
>> On Apr 27, 2021, at 7:39 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>>> Dear Dispatch,
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Apr 2021 04:06:11 +0200

> for instances where you obviously do not need a URL safe token.

I see.

> saves space when URL safeness is not needed.

That's great.  Note though that this scheme require that '.' are escaped into \u002e as can be seen in the example below.  Data to sign:
{
   "payee": "Space Shop",
   "amount": {
     "currency": "EUR",
      "value": "100.00"
   }
}

Using RFC 7797 (with "b64":false,"crit":["b64"]):
eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19.{"amount":{"currency":"EUR","value":"100\u002e00"},"payee":"Space Shop"}.KFOhCfpyZnW7RUpwOvZAJPKDfpF1R2uENirUW6Ew4v1HwQI5iFJaXKW0PsvTuVNpb-T_UjpOcv868qihMjeMwA

Using JWS/CT (here pretty-printed using standard JSON tools):
{
   "payee": "Space Shop",
   "amount": {
     "currency": "EUR",
      "value": "100.00"
   },
   "signature": "eyJhbGciOiJFUzI1NiJ9..aY27xoS5B3J-uZtUdJzXevqBbnNf4vNT1YN1_eHPOcILMXlVu3VjdExW17f66EGdt4mxQSnpAVLsUa4k2zSLQw"
}

> in the JSON object being signed (and not about whether the JSON is in

JWS/CT addresses several issues:
- Maintaining a consistent message structure
- Maintaining JSON notation
- Full compliance with JavaScript and browser APIs (including the "JSON" object).

However, from an IETF adoption point of view it is rather the validity and reliance on RFC 8785 that is the core issue.

> Could you elaborate why you think it is important to NOT embed signed

The example above may serve this purpose.

> What is the usecase?

See this response to Carsten: https://mailarchive.ietf.org/arch/msg/dispatch/3EX1uM9K_oCft7BoQfW3EQj_En4/

thanx,
Anders

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 30 Apr 2021 23:37:32 +0200

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 <[email-masked]> wrote:

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 May 2021 01:04:43 +0200

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.

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 1 May 2021 07:09:48 +0200

> 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