From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YwwmT-0002Sy-45 for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 18:07:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.182 as permitted sender) client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f182.google.com; Received: from mail-wi0-f182.google.com ([209.85.212.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YwwmR-00048v-SO for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 18:07:17 +0000 Received: by wicmx19 with SMTP id mx19so54538021wic.0 for ; Mon, 25 May 2015 11:07:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.96.196 with SMTP id du4mr4685481wib.77.1432577229864; Mon, 25 May 2015 11:07:09 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Mon, 25 May 2015 11:07:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 May 2015 20:07:09 +0200 X-Google-Sender-Auth: bC_8_45L2W_ohSP6FWdEoepCaDk Message-ID: From: Mike Hearn To: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Content-Type: multipart/alternative; boundary=f46d043bdabce645540516ebe0e1 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YwwmR-00048v-SO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Virtual Notary. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 18:07:17 -0000 --f46d043bdabce645540516ebe0e1 Content-Type: text/plain; charset=UTF-8 Very nice Emin! This could be very useful as a building block for oracle based services. If only there were opcodes for working with X.509 ;) I'd suggest at least documenting in the FAQ how to extract the data from the certificate: openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -passin pass:"" | openssl x509 -text|less That's good enough to get started, but I note two issues: 1. X.509 is kind of annoying to work with: example code in popular languages/frameworks to extract the statement would be useful. 2. The stock price plugin, at least, embeds the data as text inside the X.509 certificate. That's also not terribly developer friendly and risks parsing errors undermining security schemes built on it. The way I'd solve this is to embed either a protocol buffer or DER encoded structure inside the extension, so developers can extract the notarised data directly, without needing to do any additional parsing. --f46d043bdabce645540516ebe0e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Very nice Emin! This could be very useful as a building bl= ock for oracle based services. If only there were opcodes for working with = X.509 ;)

=
I'd suggest at least documenting in the FAQ how to extract t= he data from the certificate:

openssl pkcs12 -in virtual-notary-cert-stock= s-16070.p12 -nodes -passin pass:"" | openssl x509 -text|less

That's good enough to get started, but I note two i= ssues:

  1. X.509 is kind of annoying to work with:= example code in popular languages/frameworks to extract the statement woul= d be useful.

  2. The stock price plugin, at least, embeds the d= ata as text inside the X.509 certificate. That's also not terribly deve= loper friendly and risks parsing errors undermining security schemes built = on it.

    The way I'd solve this is to embed either a protocol buff= er or DER encoded structure inside the extension, so developers can extract= the notarised data directly, without needing to do any additional parsing.=

--f46d043bdabce645540516ebe0e1--