MIME-Version: 1.0
In-Reply-To: <20130208100354.GA26627@crunch>
References: <20130208100354.GA26627@crunch>
Date: Mon, 11 Feb 2013 11:39:03 -0800
Message-ID: <CAJ1JLtsAC5mxAXCdGBh_6byuLmjxc5kBrK6HMeDWwbXCRc5UWw@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: timo.hanke@web.de
Content-Type: multipart/alternative; boundary=20cf3074afa8b4a56e04d5780fdf
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Blockchain as root CA for payment protocol
Precedence: list

--20cf3074afa8b4a56e04d5780fdf
Content-Type: text/plain; charset=ISO-8859-1

I prefer to leverage the signing of the (.) root in the DNS tree. The
amount of effort in signing the root holds more weight than building a CA
off the bitcoin blockchain.

If you want to associate identifiers for payment addresses I suggest
putting those in DNSSEC signed records in the DNS.

For routing around x.509 CAs I suggest participating in the DANE working
group in the IETF.

-rick


On Fri, Feb 8, 2013 at 2:03 AM, Timo Hanke <timo.hanke@web.de> wrote:

> There have been proposals to use the blockchain to establish
> "identities". firstbits is a simple example. I would like to announce a
> project that extends this idea to turn the blockchain into a "root CA"
> that can sign arbitrary certificates. The purpose is to use these
> certificates in the payment protocol, where some might consider
> traditional centralized root CAs unsatisfactory.
>
> Code is here: https://github.com/bcpki
>
> Technical specification and full-length examples are found in the wiki.
> I therefore spare myself from repeating the details here, even though,
> of course, discussion about those details is welcome on this list.
>
> Excerpt from README.md follows:
>
> First, we have drafted a quite general specification for bitcoin
> certificates (protobuf messages) that allow for a variety of payment
> protocols (e.g. static as well as customer-side-generated payment
> addresses).
> This part has surely been done elsewhere as well and is orthogonal to the
> goal of this project.
> What is new here is the signatures _under_ the certificates.
>
> We have patched the bitcoind to handle certificates, submit signatures to
> the blockchain, verify certificates against the blockchain, pay directly to
> certificates (with various payment methods), revoke certificates.
> Signatures in the blockchain are stored entirely in the UTXO set (i.e. the
> unspend, unprunable outputs).
> This seems to make signature lookup and verification reasonably fast:
> it took us 10s in the mainnet test we performed (lookup is instant on the
> testnet, of course).
>
> Payment methods include: static bitcoin addresses, client-side derived
> payment addresses (pay-to-contract), pay-to-contract with multisig
> destinations (P2SH)
>
> Full-length real-world examples for all payment methods are provided in
> the tutorial pages.
> These examples have actually been carried out on testnet3.
>
> For further details and specifications see the wiki.
>
> timo hanke
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--20cf3074afa8b4a56e04d5780fdf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I=A0prefer=A0to leverage the signing of the (.) root in the DNS tree. The a=
mount of effort in signing the root holds more weight than building a CA of=
f the bitcoin blockchain.<div><br></div><div>If you want to associate ident=
ifiers for payment addresses I suggest putting those in DNSSEC signed recor=
ds in the DNS.</div>
<div><br></div><div>For routing around x.509 CAs I suggest=A0participating=
=A0in the DANE working group in the IETF.</div><div><br></div><div>-rick</d=
iv><div>=A0<br><br><div class=3D"gmail_quote">On Fri, Feb 8, 2013 at 2:03 A=
M, Timo Hanke <span dir=3D"ltr">&lt;<a href=3D"mailto:timo.hanke@web.de" ta=
rget=3D"_blank">timo.hanke@web.de</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">There have been proposals to use the blockch=
ain to establish<br>
&quot;identities&quot;. firstbits is a simple example. I would like to anno=
unce a<br>
project that extends this idea to turn the blockchain into a &quot;root CA&=
quot;<br>
that can sign arbitrary certificates. The purpose is to use these<br>
certificates in the payment protocol, where some might consider<br>
traditional centralized root CAs unsatisfactory.<br>
<br>
Code is here: <a href=3D"https://github.com/bcpki" target=3D"_blank">https:=
//github.com/bcpki</a><br>
<br>
Technical specification and full-length examples are found in the wiki.<br>
I therefore spare myself from repeating the details here, even though,<br>
of course, discussion about those details is welcome on this list.<br>
<br>
Excerpt from README.md follows:<br>
<br>
First, we have drafted a quite general specification for bitcoin certificat=
es (protobuf messages) that allow for a variety of payment protocols (e.g. =
static as well as customer-side-generated payment addresses).<br>
This part has surely been done elsewhere as well and is orthogonal to the g=
oal of this project.<br>
What is new here is the signatures _under_ the certificates.<br>
<br>
We have patched the bitcoind to handle certificates, submit signatures to t=
he blockchain, verify certificates against the blockchain, pay directly to =
certificates (with various payment methods), revoke certificates.<br>
Signatures in the blockchain are stored entirely in the UTXO set (i.e. the =
unspend, unprunable outputs).<br>
This seems to make signature lookup and verification reasonably fast:<br>
it took us 10s in the mainnet test we performed (lookup is instant on the t=
estnet, of course).<br>
<br>
Payment methods include: static bitcoin addresses, client-side derived<br>
payment addresses (pay-to-contract), pay-to-contract with multisig destinat=
ions (P2SH)<br>
<br>
Full-length real-world examples for all payment methods are provided in the=
 tutorial pages.<br>
These examples have actually been carried out on testnet3.<br>
<br>
For further details and specifications see the wiki.<br>
<br>
timo hanke<br>
<br>
---------------------------------------------------------------------------=
---<br>
Free Next-Gen Firewall Hardware Offer<br>
Buy your Sophos next-gen firewall before the end March 2013<br>
and get the hardware for free! Learn more.<br>
<a href=3D"http://p.sf.net/sfu/sophos-d2d-feb" target=3D"_blank">http://p.s=
f.net/sfu/sophos-d2d-feb</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--20cf3074afa8b4a56e04d5780fdf--