Subject: Re: [jose] Canonical JSON form

From: Anders Rundgren <[email-masked]>
Date: Sat, 3 Nov 2018 05:52:31 +0100

On 2018-10-29 14:38, Tim Bray wrote:
> I like Samuel Erdtman's idea of starting with an open-source implementation.  If I see one of those, with a convincing set of test cases, I'd be inclined to make the case for spinning up a working group.
> 
> The argument isn't "Would it be useful?" it's "Can it be done?" So, start by proving it can.

Things are progressing:
https://github.com/dotnet/coreclr/pull/20707#issuecomment-435536433
A coming version of the .NET platform should then be fully compatible with the proposed scheme.

Anyway, since there are two quite distinct ways of addressing this topic, I'm thinking about a BoF session in Prague as a possible next step.

WDYT?

Anders

> 
> On Mon., Oct. 29, 2018, 1:33 a.m. Anders Rundgren <[email-masked] <mailto:[email-masked]> wrote:
> 
>     On 2018-10-28 21:32, Samuel Erdtman wrote:
>      > In my opinion we can create a good canonicalization format for JSON to be used to sign cleartext JSON.
>      >
>      > As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations.
> 
>     Yes, and part of that is supplying test data like: https://github.com/cyberphone/json-canonicalization/tree/master/testdata
>     The Microsoft folks developing "Chakra" (their JS engine) already use the 100 million reference values.
> 
> 
>      > If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome.
> 
>     Well, another part of the standards puzzle is getting early work into real products and services.
> 
>     FWIW, I'm personally involved in a couple of efforts using clear text JSON signatures:
>     - Saturn, an open payment authorization scheme based on an enhanced "four corner" trust model which aims giving banks an upper hand against Apple Pay, Google Pay, PayPal, etc.
>     - Mobile ID, an open, PKI-based, multi-issuer mobile authentication and signature solution for e-governments.
> 
>     Regards,
>     Anders
> 
>      > Best regards
>      > //Samuel
>      >
>      >
>      > On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     On Oct 22, 2018, at 04:47, David Waite <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      >
>      >      > intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions
>      >
>      >     Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/
>      >
>      >     Grüße, Carsten
>      >
>      >     _______________________________________________
>      >     jose mailing list
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      > https://www.ietf.org/mailman/listinfo/jose
>      >
> 
>     _______________________________________________
>     jose mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/jose
>

---

From: Bret Jordan <[email-masked]>
Date: Sat, 3 Nov 2018 19:55:39 +0700

I would love to attend the BOF in Prague on this topic.

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Nov 3, 2018, at 11:52 AM, Anders Rundgren <[email-masked]> wrote:
> 
>>     >      > intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions
>>     >

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 5 Nov 2018 19:52:15 +0100

If a BOF happens in Prague I will try to join.

(Thanks Jim for the concert information on how to move this forward.)

Cheers
//Samuel

On Sat, Nov 3, 2018 at 1:55 PM Bret Jordan <[email-masked]> wrote:

> I like Samuel Erdtman's idea of starting with an open-source
> implementation.  If I see one of those, with a convincing set of test
> cases, I'd be inclined to make the case for spinning up a working group.
> Anyway, since there are two quite distinct ways of addressing this topic,
> I'm thinking about a BoF session in Prague as a possible next step.
>
> WDYT?
>
> Anders
>
> On Mon., Oct. 29, 2018, 1:33 a.m. Anders Rundgren <
> [email-masked] <mailto:[email-masked]>
> wrote:
>     > As can be seen on this list many are skeptical so my approach would
> be to publish easy to use open source implementations.
>    Yes, and part of that is supplying test data like:
> https://github.com/cyberphone/json-canonicalization/tree/master/testdata
>     > If we do that and there is real interest then we might be able to
> convince people here about the need. In line with this ambition I have done
> the JS and Java publications. This might also show there is no actual
> interest and then that is also an outcome.
>    - Saturn, an open payment authorization scheme based on an enhanced
> "four corner" trust model which aims giving banks an upper hand against
> Apple Pay, Google Pay, PayPal, etc.
>     > On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     On Oct 22, 2018, at 04:47, David Waite <
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> wrote:
>     >      >
>     >      > intermittent interoperability failures until a new language
> runtime release which revises the numerical print and parse functions
>     >
>     >     Note that this is not a theoretical concern, as CVE-2010-4476
> and CVE-2010-4645 amply demonstrate, nicely underscored by the
> re-occurrence of the latter in
> https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/
>     >
>     >     Grüße, Carsten
>     >

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 18 Nov 2018 08:53:49 +0100

On 2018-10-11 21:03, Carsten Bormann wrote:
> On Oct 11, 2018, at 20:23, Phil Hunt <[email-masked]> wrote:
>>
>> I am not sure of the value of canonicalization.  I prefer bytestream encoding style where the original content goes with the signature.
> 
> I’m afraid a lot of people are sitting in front of their screens silently agreeing, but not typing anything because their hands are tied up in an interminable facepalm.

Those who are not stuck in an a ever-lasting facepalm may not be entirely comfortable with signature schemes that completely change the structure of signed messages. COSE do this as well?

Well, you can of course add artificial unsigned layers (like the TEEP folks do), but that smells "workaround" rather than solution.

thanx,
Anders

> 
> So, for the record:
> To the people asking for a c14n solution for signature: If you want XMLDSig, you know where to find it.
> The basic approach of having humongous XML documents that get signatures added to themselves as part of the document only makes sense in certain processing models that went out of favor with XML.
> JOSE does the right thing for more modern applications.
> 
> I’m not opposed to doing some “c14n” work on serialization schemes — deterministic serialization has other applications than just XMLDSig.
> That would be work for a JSONbis WG (but I fear the interest level among JSON experts will be low).
> I definitely do not like giving the message that c14n-based signatures are the new thing that will replace doing the right thing (JOSE, that is).
> 
> Grüße, Carsten
> 
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Nov 2018 15:59:57 +0100

> Those who are not stuck in an a ever-lasting facepalm may not be entirely comfortable with signature schemes that completely change the structure of signed messages.  COSE do this as well?

I don’t understand the question.  The point of COSE is that the signed message is not changed at all.
(With JOSE, it needs to be base64-encoded for transfer, but it also isn’t changed otherwise.)

> Well, you can of course add artificial unsigned layers (like the TEEP folks do), but that smells “workaround" rather than solution.

>> The basic approach of having humongous XML documents that get signatures added to themselves as part of the document only makes sense in certain processing models that went out of favor with XML.

This.

>> JOSE does the right thing for more modern applications.

And this.

>> I’m not opposed to doing some “c14n” work on serialization schemes — deterministic serialization has other applications than just XMLDSig.

RFC 7049 has some recommendations for “c14n" that are being cleaned up and updated for 7049bis.
Those are implemented in a few CBOR libraries, albeit not in all.
The RFC 7049 version of “c14n” is in use in some other SDOs’ work.

>> I definitely do not like giving the message that c14n-based signatures are the new thing that will replace doing the right thing (JOSE, that is).

And this.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Sun, 18 Nov 2018 08:53:54 -0800

> -----Original Message-----
> From: jose <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Sunday, November 18, 2018 7:00 AM
> To: Anders Rundgren <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [jose] Canonical JSON form
> 
> >>> I am not sure of the value of canonicalization.  I prefer bytestream
> encoding style where the original content goes with the signature.
> >> I’m afraid a lot of people are sitting in front of their screens silently
> agreeing, but not typing anything because their hands are tied up in an
> interminable facepalm.
> >
> > Those who are not stuck in an a ever-lasting facepalm may not be entirely
> comfortable with signature schemes that completely change the structure of
> signed messages.  COSE do this as well?
> 

COSE does do the same type of wrapping as what the JOSE standard does.  In that sense -- that the content being signed and the signature are not at the same level in the encoding - yes it "completely changes the structure of the signed message".  

> 
> > Well, you can of course add artificial unsigned layers (like the TEEP folks do),
> but that smells “workaround" rather than solution.
> 

How it smells depends on how one looks at the world.  For me it smells "this is the right way to do things".  YMMV.

> >> The basic approach of having humongous XML documents that get
> signatures added to themselves as part of the document only makes sense in
> certain processing models that went out of favor with XML.
> 
> This.
> 
> >> I’m not opposed to doing some “c14n” work on serialization schemes —
> deterministic serialization has other applications than just XMLDSig.
> 
> >> I definitely do not like giving the message that c14n-based signatures are
> the new thing that will replace doing the right thing (JOSE, that is).
> 
> And this.
> 
> Grüße, Carsten
>

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 18 Nov 2018 19:06:22 +0100

On 2018-11-18 17:53, Jim Schaad wrote:
>> Again, I don’t understand.

There's no mystery going on here.  The TEEP folks needed Signed Data rather than Signature objects with embedded Data.

JSON can (as I have shown) fairly easily accomplish this without adding [redundant] unsigned wrapper objects.

Another application I stumbled on is Open Banking, here in a request scenario:
POST /payments HTTP/1.1
x-jws-signature: eyJhbGciOiJFUzI1NiJ9..EzZmI2LxhWyCf9ljJBw-Z3i9uxnJu6XL5ljTY==
Content-Type: application/json

{
   "Data": {
    ...OB specific data..
  },
   "Risk": {
    ...OB specific data..
   }
}

Using JWS + JSON canonicalization:
POST /payments HTTP/1.1
Content-Type: application/json

{
   "Data": {
    ...OB specific data..
  },
   "Risk": {
    ...OB specific data..
   },
   "x-jws-signature": "eyJhbGciOiJFUzI1NiJ9..EzZmI2LxhWyCf9ljJBw-Z3i9uxnJu6XL5ljTY"
}

What's the advantage with that you may wonder?  Well, signed data becomes a self-contained object which can
- pass arbitrary proxies
- be stored in a database
- be embedded in another JSON object to for example support countersigning
etc. without losing its edge.

I would consider a similar solution for CBOR/COSE.

Anders
https://mobilepki.org/jws-jcs

 > > But maybe what I wrote earlier is still applicable:
>

---

From: David Waite <[email-masked]>
Date: Sun, 18 Nov 2018 12:37:15 -0700

Not to be a jerk (I promise!), but is there documentation of the TEEP issues with using JWS/JWE structure?

The existing specs seem to use JOSE as-is, I didn’t immediately see anything on the ML or in GitHub issues. 

It is difficult to fairly argue a specific desired solution to a non-disclosed problem set. Especially when so many people have battle scars from implementing that solution in the past. 

-DW

> On Nov 18, 2018, at 11:06 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 18 Nov 2018 22:03:47 +0100

> anything on the ML or in GitHub issues.

Correct.  Since the requirement was using standardized security solutions
but also maintaining a reasonable message structure, they didn't have any
option but adding a redundant layer like the TAInformation /
TAInformationTBS pair.

I was in a similar position having a bunch of systems to be converted from
XML to JSON.  Unlike TEEP, I had the freedom to select any working solution
which is the background to this work.

> It is difficult to fairly argue a specific desired solution to a
> non-disclosed problem set. Especially when so many people have battle scars
> from implementing that solution in the past.

Implementing, documenting and verifying this concept took quite some time
but apart from a math bug in .NET there were no surprises whatsoever.

The problem set is described, here is a short version:
- Keeping signed JSON in JSON format
- Enabling a consistent message structure regardless if messages are signed
or not
- Supporting signed JavaScript objects

Anders

> > There's no mystery going on here.  The TEEP folks needed Signed Data
> rather than Signature objects with embedded Data.
>
>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 18 Nov 2018 14:52:59 -0700

Andres,

I fully support working on this.  Can we have a meeting / BOF in Prague to talk through this and get everyone on the same page..?

I think some simple and clear examples might help everyone.

1) What is being proposed

2) Why it is needed

3) Why JOSE/COSE is not working for us

4) Possible solutions to this problem 

Thanks,
Bret

> On Nov 18, 2018, at 2:03 PM, Anders Rundgren <[email-masked]> wrote:
> 
> 
> 
> On Sun, 18 Nov 2018, 20:37 David Waite <[email-masked] <mailto:[email-masked]> wrote:
> Correct.  Since the requirement was using standardized security solutions but also maintaining a reasonable message structure, they didn't have any option but adding a redundant layer like the TAInformation / TAInformationTBS pair.
> 
> I was in a similar position having a bunch of systems to be converted from XML to JSON.  Unlike TEEP, I had the freedom to select any working solution which is the background to this work..
> 
> 
> 
> Implementing, documenting and verifying this concept took quite some time but apart from a math bug in .NET there were no surprises whatsoever.
> 
> - Enabling a consistent message structure regardless if messages are signed or not
> https://mobilepki.org/jws-jcs <https://mobilepki.org/jws-jcs>
> 
> 
> 
> -DW
> 
> > On Nov 18, 2018, at 11:06 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 22 Nov 2018 08:26:41 +0100

> I think some simple and clear examples might help everyone.

The TEEP OTrP use case might serve that purpose.  In short every OTrP message is tagged by an outer object type ID like in this extremely condensed example using JWS compact mode:
{
   "car": "jws-header.car-json-object-encoded-in-base64url.jws-signature"
}

A problem with this scheme is that since "car" is unsigned it can be replaced by something else and the signature will still validate.  The OTrP designers addressed this deficiency by mandating an inner (signed) object type id.  Obviously these MUST be compared in order to form a complete signature validation scheme.

Using detached JWS [1] combined with JCS [2,3] you sign the entire JSON object as well as keeping it in JSON format:
{
   "car":{
      "brand": "Ferrari",
      "horsePower": "450",
      "weight": "2357kg"
   },
   "signature": "jws-header..jws-signature"
}

Anyway, the core issue seems to be proving that JSON canonicalization actually is a realistic alternative. IMHO, it is usually easier doing the opposite; showing why something won't fly.  Personally, I believe that there is meaningful life between between "flawless" and "broken" :-)

Thanx,
Anders
1] https://tools.ietf.org/html/rfc7515#appendix-F
2] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
3] https://mobilepki.org/jws-jcs

>> On Nov 18, 2018, at 2:03 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Nov 2018 08:50:17 +0100

Counter signatures were actually the major "inspiration" for Canonical JSON since JWS based dittos are hard to debug and document due to the deep nesting of Base64Url encoded objects but it is still fully doable.

However, in a system which I will present at Trustech 2018, I came up with a counter signature scheme where JOSE simply put ran out of gas.

https://cyberphone.github.io/doc/payments/payment-decentralization-scheme-1a.pdf

In this system (very briefly):
1. a Merchant creates a Payment Request and sends it to the Payer for authorization
2. the Payer authorizes the Payment Request with his/her signature key.  The signed authorization data includes a hash of the Payment Request
3. the Payer (for privacy reasons) encrypts the authorization data and returns it to the Merchant together with an unencrypted URL pointing to the Payer's bank
4. the Merchant sends the original Payment Request + the encrypted Payer authorization data to the Payer's banks for fulfillment
5. the Payer's bank decrypts and validates the authorization data, including verifying that the hash of the Merchant-supplied Payment Request matches the hash in the authorization data

It seems to me that a JOSE based design would have to be architected in a fundamentally different way.

Anders

---

From: Bret Jordan <[email-masked]>
Date: Fri, 23 Nov 2018 09:49:16 -0700

And I am okay with finding something in the middle as you suggest.  Even if we have to call out the cases where the solution will not work.  Getting a solution that works for the 70% use case would be a huge win. 

Thanks,
Bret

> On Nov 22, 2018, at 12:26 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 23 Nov 2018 09:51:35 -0700

That is my understanding as well.   I really hope we can have a meeting / BOF / side meeting / other in Prague to talk about ways forward. 

Thanks,
Bret

> On Nov 23, 2018, at 12:50 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 23 Nov 2018 09:37:34 -0800

I am having a potential terminology problem.  When I read the term Counter
Signature, I am used to this meaning that I am signing a signature,
potentially with some additional information.   I am not sure that this is
what you have going on below.  Are these signatures "nested" or "parallel"
or "on the previous signature"?

Jim

> From: jose <[email-masked]> On Behalf Of Anders Rundgren
> Sent: Thursday, November 22, 2018 11:50 PM
> To: [email-masked]
> Subject: [jose] JWS Counter Signatures
> 
> Counter signatures were actually the major "inspiration" for Canonical
JSON
> since JWS based dittos are hard to debug and document due to the deep
> nesting of Base64Url encoded objects but it is still fully doable.
> 
> However, in a system which I will present at Trustech 2018, I came up with
a
> counter signature scheme where JOSE simply put ran out of gas.
> 
> 1. a Merchant creates a Payment Request and sends it to the Payer for
> authorization 2. the Payer authorizes the Payment Request with his/her
> signature key.  The signed authorization data includes a hash of the
Payment
> Request 3. the Payer (for privacy reasons) encrypts the authorization data
and
> returns it to the Merchant together with an unencrypted URL pointing to
the
> Payer's bank 4. the Merchant sends the original Payment Request + the
> encrypted Payer authorization data to the Payer's banks for fulfillment 5.
the
> Payer's bank decrypts and validates the authorization data, including
verifying
> that the hash of the Merchant-supplied Payment Request matches the hash in
> the authorization data
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Nov 2018 18:44:33 +0100

> or "on the previous signature"?

Well, it is "sort of" counter signature.  The Payment Request is indeed signed.
Anyway, the core is simply that taking a hash of a JSON object have multiple
applications.

Anders

---

From: Bret Jordan <[email-masked]>
Date: Fri, 23 Nov 2018 12:16:15 -0700

I have need have having both parallel and nested signatures of JSON content. 

Thanks,
Bret

> On Nov 23, 2018, at 10:37 AM, Jim Schaad <[email-masked]> wrote:
>

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 24 Nov 2018 04:32:18 +0900

Hmmm. I am failing to understand the problem. In JWS:

1) you can have multiple signatures on the same hash: Parallel signature;
as well as
2) you could encapsulate the signed blob into a new signature: Serial
signature.

What is the problem?

Nat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Bret Jordan <[email-masked]>
Date: Fri, 23 Nov 2018 13:21:23 -0700

Quoting Andres from a few messages back:

>> BEGIN

>>END

Thanks,
Bret

> On Nov 23, 2018, at 12:32 PM, Nat Sakimura <[email-masked]> wrote:
> 
> 1) you can have multiple signatures on the same hash: Parallel signature; as well as 
> 2) you could encapsulate the signed blob into a new signature: Serial signature. 
> 
> What is the problem? 
> 
> Nat
> 
> On Sat, Nov 24, 2018 at 4:16 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>> On Nov 23, 2018, at 10:37 AM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> From: jose <[email-masked] <mailto:[email-masked]>> On Behalf Of Anders Rundgren
>>> To: [email-masked] <mailto:[email-masked]>
>>> https://cyberphone.github.io/doc/payments/payment-decentralization-scheme- <https://cyberphone.github.io/doc/payments/payment-decentralization-scheme->
>>> 1a.pdf
>>> 
>>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
>> 
>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Nov 2018 22:42:01 +0100

> - Keeping signed JSON in JSON format

But that is not a problem, just a preference.
(The cognitive dissonance of drowning in base64 also is a bit smaller with COSE.)

> - Enabling a consistent message structure regardless if messages are signed or not

That is an even more questionable preference.

> - Supporting signed JavaScript objects

I’m not sure I understand that.
(I know how to sign a JavaScript Object when represented in JSON.  What else do you want to do?)

Grüße, Carsten

---

From: Phil Hunt <[email-masked]>
Date: Fri, 23 Nov 2018 15:18:03 -0800

+1 each to Carsten and Nat’s comments. 

Phil

On Nov 23, 2018, at 1:42 PM, Carsten Bormann <[email-masked]> wrote:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=VVjG5M8wVvqKvp_6BXxQE9xFQLiIt-G2MLVX_HTrlzc&s=WayjNDVFZ2v-xTnNDnBpxRAZ1i0cP83nJffQt_4ef8Y&e=

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Nov 2018 18:08:58 -0600

> That is my understanding as well.   I really hope we can have a meeting / BOF / side meeting / other in Prague to talk about ways forward. 

A BoF or side meeting would need an organizer to step forward and do some
organizing in advance; it will not happen spontaneously on its own...

-Ben

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 24 Nov 2018 08:16:26 +0100

Since Open Banking's use of clear text signatures (enabled through HTTP
bindings and the downsides of that [1]), TEEP/OTrP's need for clear
text object type IDs (and the implications of that with respect to
signature validation [2]), as well as my own use of a hash only in a
novel counter signature scheme [3], haven't spurred a single comment
relating to the actual applications and how they {c|sh}ould make best
use of the existing or enhanced JOSE stack, there seems to be little
point continuing these discussions within the IETF.

I'm still waiting for messages pointing out why JCS isn't working
(beyond anecdotes from the XML/WS* era).  Since detached JWS signatures
is already a de-facto standard in Open Banking, claims that data to be
signed SHOULD be encoded in alien formats and then be embedded in specific
signature containers can safely be ignored unless somebody has a very compelling
security story to share with us.

Anyway, VmWare have a US patent on JSON clear text signatures [6] so maybe
it is toast from that perspective as well?  Although I'm not a patent
lawyer this smells prior art by a mile!  To me it only adds credibility
to the idea since the concepts are virtually identical:-)

 From the CBOR list I have gathered that the CBOR counterpart to JCS [4,5]
apparently is in a pretty bad shape.  Carsten, you have a new job :-)

thanx,
Anders

1] http://lists.openid.net/pipermail/openid-specs-fapi/2018-November/001164.html
2] https://www.ietf.org/mail-archive/web/jose/current/msg05810.html
3] https://www.ietf.org/mail-archive/web/jose/current/msg05811.html
4] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
5] https://mobilepki.org/jws-jcs
6] https://patentimages.storage.googleapis.com/68/be/70/582930ff11703d/US20150341176A1.pdf

---

From: Bret Jordan <[email-masked]>
Date: Sat, 24 Nov 2018 09:59:50 -0700

I would hope that we could do this work in the IETF.  But, if the IETF community is not willing to entertain other use-cases and market needs, I am willing to help make this happen in another SDO.  

The thing everyone needs to remember, just because you do not like something, does not mean the use case is not valid and it is not needed in the market.  

Thanks,
Bret

> On Nov 24, 2018, at 12:16 AM, Anders Rundgren <[email-masked]> wrote:
>