From: Mark van Cuijk <mark@coinqy•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
Date: Mon, 28 Jul 2014 15:06:26 +0200 [thread overview]
Message-ID: <5E988ED7-845D-4982-9240-155AACD20F66@coinqy.com> (raw)
In-Reply-To: <CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
On 28 Jul 2014, at 14:46 , Mike Hearn <mike@plan99•net> wrote:
> I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose.
>
> I don't think I proposed this exactly? It's the other way around - a merchant issues an extension cert to allow the PP to act on their behalf.
I referred to your idea in https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html which is indeed not the proposal itself.
> Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal.
>
> I'm not sure I understand. Your proposal also has two signatures. Indeed it must because delegation of authority requires a signature, but old clients won't understand it.
I’ll rephrase what I intended to say. In your proposal two signatures need to be computed over the payment request data, one with the key related to the X.509 certificate (for backwards compatibility) and one with the ECDSA public key. On my proposal only one signature needs to be computed over the payment request data using the former key, the same way it happens now.
Indeed there is another signature, which is to authenticate the payment delegation. If you take it into account in the signature count, then your proposal has three signatures.
/Mark
[-- Attachment #2: Type: text/html, Size: 2878 bytes --]
next prev parent reply other threads:[~2014-07-28 13:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-27 6:55 Mark van Cuijk
2014-07-27 19:31 ` Mike Hearn
2014-07-28 9:01 ` Mark van Cuijk
2014-07-28 12:46 ` Mike Hearn
2014-07-28 13:06 ` Mark van Cuijk [this message]
2014-07-28 13:32 ` Mike Hearn
2014-07-30 7:54 ` Mark van Cuijk
2014-07-30 11:34 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5E988ED7-845D-4982-9240-155AACD20F66@coinqy.com \
--to=mark@coinqy$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox