Re: [jose] JWS Counter Signatures

[Bret Jordan <[e-mail]>]

Quoting Andres from a few messages back:

>> BEGIN

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

>>END

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 23, 2018, at 12:32 PM, Nat Sakimura <[e-mail]> wrote:
> 
> 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
> 
> On Sat, Nov 24, 2018 at 4:16 AM Bret Jordan <[e-mail] <mailto:[e-mail]>> wrote:
> I have need have having both parallel and nested signatures of JSON content. 
> 
> 
> 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 23, 2018, at 10:37 AM, Jim Schaad <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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
>> 
>> 
>>> -----Original Message-----
>>> From: jose <[e-mail] <mailto:[e-mail]>> On Behalf Of Anders Rundgren
>>> Sent: Thursday, November 22, 2018 11:50 PM
>>> To: [e-mail] <mailto:[e-mail]>
>>> 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.
>>> 
>>> https://cyberphone.github.io/doc/payments/payment-decentralization-scheme- <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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> _______________________________________________
> jose mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en