[Bitcoin-development] "On behalf of" BIP 70 extension proposal

Mark van Cuijk mark at coinqy.com
Mon Jul 28 13:06:26 UTC 2014


On 28 Jul 2014, at 14:46 , Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140728/c9a8b502/attachment.html>


More information about the bitcoin-dev mailing list