Re: [jose] JWS Counter Signatures

[Nat Sakimura <[e-mail]>]

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


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