Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <adam.back@gmail.com>) id 1Valia-0006XW-Dv
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Oct 2013 12:14:48 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.54 as permitted sender)
	client-ip=74.125.83.54; envelope-from=adam.back@gmail.com;
	helo=mail-ee0-f54.google.com; 
Received: from mail-ee0-f54.google.com ([74.125.83.54])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1ValiX-0004sG-W3
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Oct 2013 12:14:48 +0000
Received: by mail-ee0-f54.google.com with SMTP id t10so3187506eei.13
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 28 Oct 2013 05:14:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=30HWIvXxxNMXImzfsIxancqrJDl56rWqrLoud3gmW2o=;
	b=OBclb1YSSw6T4oX6dDjv6REGB+TPQXTl7n3ffFnkr9dbJ9SiL8cDK2uRDooBh3avzX
	9FzNZ4hXUyGYIC0UVeoSa/J15mudWqq7k4FXbaObj2hPGmZKeAE0hIxjBUquoPb2eyTr
	5yyic7k3MDnMA3wp/lH13GZPNxRflK8nqvlzG1p/4npthF/fU/VUmT8VmxBp4mFkNwcq
	MSbdAQgEjwe3YqEdGJtlnCXrDTF0UyvRwPCedxWyDstFIWDq3yT/EeInqpG8D+393/Wt
	T46RibnseSc62hOWIDEgK1N01NHHiQ0jT85gO1KamGsYg9VjSms+mQRb/kGPeeImii0k
	zjhA==
X-Received: by 10.15.10.6 with SMTP id f6mr2222929eet.57.1382962479540;
	Mon, 28 Oct 2013 05:14:39 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
	by mx.google.com with ESMTPSA id z12sm56551426eev.6.2013.10.28.05.14.37
	for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 28 Oct 2013 05:14:38 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
	id 038432E0AAA; Mon, 28 Oct 2013 13:14:35 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
	Mon, 28 Oct 2013 13:14:33 +0100
Date: Mon, 28 Oct 2013 13:14:33 +0100
From: Adam Back <adam@cypherspace.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20131028121433.GA10254@netbook.cypherspace.org>
References: <CAAS2fgRRobkE2GdYomtJof7HCH-9ZczE9EBj7DBS-pCGscUSNQ@mail.gmail.com>
	<201310260341.41613.luke@dashjr.org>
	<CAAS2fgTWjPCdAZB22GdRWkfULS-L9XaqYRZqB=dcbGV1+My3nA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CAAS2fgTWjPCdAZB22GdRWkfULS-L9XaqYRZqB=dcbGV1+My3nA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:131028:gmaxwell@gmail.com::ieQ+mg+QWkXu5O/8:0000000000000000000
	0000000000000000000000005t4t
X-Hashcash: 1:20:131028:luke@dashjr.org::J3+QrFwh3gK40dGo:003G1+
X-Hashcash: 1:20:131028:bitcoin-development@lists.sourceforge.net::jXJ9LRWRYkKQ1
	rvD:000000000000000000000DSJ
X-Hashcash: 1:20:131028:adam@cypherspace.org::kUOnasaMdWAD/h6t:00000000000000000
	0000000000000000000000005gnk
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: doubleclick.net]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(adam.back[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1ValiX-0004sG-W3
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2013 12:14:48 -0000

I think its a mistake relying directly on X509, its subject to corrpution
attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other
code base) to be a security nightmare.

Why not make the payment messages signed by bitcoin keys.  If someone wants
to associate with X.509 they can put a bitcoin address on their SSL site.

If someone can get into your site deeply enough to modify your SSL served
code and you're trying to run ecommerce you have other problems.

Never the less if they care they can clear sign the bitcoin addr with xmlsig
and their X.509 private key, and/or with PGP and a WoT.

I think its smarter to pollute bitcoin main with X509.  Make a little helper
util if there are not enough xmlsig tools that you cant pick one up
opensource for multiple languages.

This then avoids the binding to Tor - you can publish a bitcoin address
authenticated anyway you like.  Eg tahoe-LAFS auth/integrity, i2p, tor, pgp
- you name it.

Maybe I voice this opinion a bit late in the cycle, but I think it would do
bitcoin a favor otherwise its a camels nose in the tent into the TLAs that
control their own X.509 CAs, or issue NSL letters for CA private keys, or
forged certs.  It's all happening and thanks to Snowden we now have even
more evidence...

Adam

On Fri, Oct 25, 2013 at 09:06:48PM -0700, Gregory Maxwell wrote:
>On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr <luke@dashjr.org> wrote:
>> Is there any point to additional encryption over tor (which afaik is already
>> encrypted end-to-end)? Is there a safe way to make this work through tor entry
>> nodes/gateways?
>
>The x.509 in the payment protocol itself is for authentication and
>non-repudiation, not confidentiality.
>
>It's used to sign the payment request so that later there is
>cryptographic evidence in the event of a dispute:
>"He didn't send me my alpaca socks!" "Thats not the address I told you to pay!"
>"He told me he'd send my 99 red-balloons, not just one!"  "No way,
>that was the price for 1 red-balloon!"
>
>Just using SSL or .onion (or whatever else) gets you confidentiality
>and authentication.  Neither of these things get you non-repudiation.
>
>> It'd be nice to have a way to support namecoin-provided keys too...
>
>The payment protocol is extensible, so I hope that someday someone
>will support namecoin authenticated messages (but note: this requires
>namecoin to support trust-free SPV resolvers, otherwise there is no
>way to extract a compact proof that can be stuck into a payment
>request) and GPG authenticated messages.
>
>But those things will require a fair amount of code (even fixing the
>namecoin protocol in the nmc case), and GPG could be done just by
>externally signing the actual payment request like you'd sign any
>file... and considering the sorry state of their _practical_
>usability, I don't think they're worth doing at this time.
>
>By contrast, I _think_ the tor onion support would require only a
>relatively few lines of code since it could just be the existing x.509
>mechanism with just a simple special validation rule for .onion, plus
>a little tool to repack the keys.  I think it would easily be more
>widely used than namecoin (though probably both would not really be
>used, as gavin notes).
>
>w/ Gavin's comments I'll go check in with the tor folks and see if
>anyone has ever though of doing this before and if there is already a
>canonical structure for the x.509 certs used in this way.
>
>------------------------------------------------------------------------------
>October Webinars: Code for Performance
>Free Intel webinars can help you accelerate application performance.
>Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>the latest Intel processors and coprocessors. See abstracts and register >
>http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development