Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.46 as permitted sender)
	client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f46.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
References: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
	<CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
	<C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
Date: Mon, 28 Jul 2014 14:46:38 +0200
Message-ID: <CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mark van Cuijk <mark@coinqy.com>
Content-Type: multipart/alternative; boundary=001a11332c8e630ca304ff405001
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
Precedence: list

--001a11332c8e630ca304ff405001
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <mark@coinqy.com> wrote:

> Good to see that it has been discussed, but I see the idea has been
> postponed.
>

I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.


> I do like the idea coined by Mike that a PP can issue non-SSL certificate=
s
> 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.


> Regarding the choice of how to authenticate the PP, I=E2=80=99m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don=E2=80=99t =
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.

--001a11332c8e630ca304ff405001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mark@coinqy.com" target=3D"_blank">mark@coinqy.com</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Goo=
d to see that it has been discussed, but I see the idea has been postponed.=
</div>
</div></blockquote><div><br></div><div>I&#39;m not sure postponed is the ri=
ght word. It wasn&#39;t in v1, but many useful things weren&#39;t. It&#39;s=
 more like, a bunch of people have to do work to upgrade this and at the mo=
ment they&#39;re all busy with other things.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div>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 cust=
omer is free to determine whether he trusts the PP for this purpose.<br>
</div></div></blockquote><div><br></div><div>I don&#39;t think I proposed t=
his exactly? It&#39;s the other way around - a merchant issues an extension=
 cert to allow the PP to act on their behalf.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div></div><div>Regarding the choice of=
 how to authenticate the PP, I=E2=80=99m a bit undetermined. Disregarding b=
ackward compatibility, I think the extended certificate system proposed by =
Mike is cleaner. However, I don=E2=80=99t like the concept of requiring two=
 separate signatures for old and new clients. Taking backward compatibility=
 in mind, I tend to prefer my proposal.<br>
</div></div></blockquote><div><br></div><div>I&#39;m not sure I understand.=
 Your proposal also has two signatures. Indeed it must because delegation o=
f authority requires a signature, but old clients won&#39;t understand it.<=
/div>
</div></div></div>

--001a11332c8e630ca304ff405001--