Re: [jose] JWS Counter Signatures

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 <ietf@augustcellars.com> 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 <jose-bounces@ietf.org> On Behalf Of Anders Rundgren
>> Sent: Thursday, November 22, 2018 11:50 PM
>> To: jose@ietf.org
>> 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-
>> 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
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose