On 28 Jul 2014, at 14:46 , Mike Hearn <m...@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
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
