Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SEoHL-0002rb-Sf for bitcoin-development@lists.sourceforge.net; Mon, 02 Apr 2012 20:55:08 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com; helo=mail-vb0-f47.google.com; Received: from mail-vb0-f47.google.com ([209.85.212.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SEoHK-00062O-PT for bitcoin-development@lists.sourceforge.net; Mon, 02 Apr 2012 20:55:07 +0000 Received: by vbbfr13 with SMTP id fr13so3065093vbb.34 for ; Mon, 02 Apr 2012 13:55:01 -0700 (PDT) Received: by 10.52.22.148 with SMTP id d20mr3791374vdf.102.1333400101257; Mon, 02 Apr 2012 13:55:01 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPS id dr10sm1075567qab.14.2012.04.02.13.55.00 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:55:00 -0700 (PDT) Message-ID: <4F7A1227.7070306@gmail.com> Date: Mon, 02 Apr 2012 16:55:03 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Bitcoin Dev Content-Type: multipart/alternative; boundary="------------000201060401000405020701" X-Spam-Score: -0.6 (/) 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 (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1SEoHK-00062O-PT Subject: [Bitcoin-development] Signature Blocks and URI Sign Requests 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, 02 Apr 2012 20:55:08 -0000 This is a multi-part message in MIME format. --------------000201060401000405020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I would like to propose two things that are closely related. I will start making BIPS if there's positive feedback. Sorry it's so long, but I felt both should be in the same email... _*(1) Signature Blocks* -- A more-robust, versatile, message-signing exchange_ Satoshi client 0.6.0 introduced message signing, but I've been fairly unimpressed with the implementation. Strictly speaking, it works, but it's really not intended for "regular users." There is no indication of what message was signed or what address signed it. Key recovery works for the computers processing it, but the user has no idea what this chunk of random data is. They don't even know if the message they thought they signed is what's in the signature (along the lines of the copy&paste virus, the message could be switched out without the user noticing). I have implemented Signature Blocks in Armory (as of v0.55), which is a fully-functional expansion on the idea. Along the lines of BIP 10, a signature block is a human-readable chunk of data that immediately identifies the address and the message that are being signed. It is easily copy&pasted via email or text files, and is fairly compact for visual identification. Click the link above to see an example signature block and an Armory screenshot of the UI (which needs improvement, but still usable). The verification process will include: -- Check that the public key (included or recovered) matches the address field. -- Verify that the signature matches the included message for this public key -- The message is properly formatted with a standardized character set and escape/replacement scheme for things like newlines or double-quotes. gmaxwell already pointed out that key recovery makes the "Public Key" field pointless. Okay fine -- I just don't have key recovery implemented yet in Armory, and when I do I can ditch that field (or simply make it optional). The point is to create a versatile, human-readable standardized form, much like the BIP 0010 signature-collection scheme . _*(2) Sign-Message URI scheme***-- Request signed messages from users using URIs_ I had the idea that for certain services, the first funding address could be used to identify the owner of an account, and all account maintenance (such as cashouts) be done through signed messages with this address. For instance, the user would need both a login password *and* a signed message in order to make a withdrawal or purchase: ("Please withdraw 12.3 BTC from acct 1828349132 to address 1Hfr3jk2093f")_signed_by_A This gives the service the ability to use two separate factors to authenticate the request (username&password *and* access to unencrypted wallet). This /could/ work with manual signature blocks alone... but it's too many steps for regular users. However, I think it's workable if we expand bitcoin URIs to include "Signature Requests". The URI scheme would add a few parameters to the scheme, and would have to have further replacement rules to make sure that messages are handled properly. The general CONOPs would be (*Con*cept of *Op*eration*s*): -- User navigates to "Withdraw funds" on webpage -- Webpage has you fill in the details: from-account, to-address, withdrawal amount -- Webpage produces a clickable URI link that loads all the information into your client, including addr-reqd-for-sig -- Client asks for confirmation and passphrase (if necessary) then produces a signature (and sig block if necessary) -- URI may include reply-to field that tells it where to send the siganture when it's ready So the extra tags that would be needed would probably be: "*requestSig*=True": Flag to identify that this is a signing request URI "*sigNeeded*=1Qjf3392k31h" The address that needs to sign the message "*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f" Some encoding of the message that can be parsed the same way on all systems "*replyurl*=http://requestor.com/sig_replies.asp?" (Optional) After signing, application will submit the signature to the replyurl The reply url could be simply an http URL which will use bitcoin URI syntax, with the fields above copied. Therefore, to complete the above request, the application handling the request will simply send an HTTP request to: http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h&*message*=...&*signature*=1fb1893ac193...&*replySig*=True Any thoughts? (I have no doubts that there are :) ) -Alan --------------000201060401000405020701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would like to propose two things that are closely related.  I will start making BIPS if there's positive feedback.  Sorry it's so long, but I felt both should be in the same email...


(1) Signature Blocks  -- A more-robust, versatile, message-signing exchange

Satoshi client 0.6.0 introduced message signing, but I've been fairly unimpressed with the implementation.  Strictly speaking, it works, but it's really not intended for "regular users."  There is no indication of what message was signed or what address signed it.  Key recovery works for the computers processing it, but the user has no idea what this chunk of random data is.  They don't even know if the message they thought they signed is what's in the signature (along the lines of the copy&paste virus, the message could be switched out without the user noticing).

I have implemented Signature Blocks in Armory (as of v0.55), which is a fully-functional expansion on the idea.  Along the lines of BIP 10, a signature block is a human-readable chunk of data that immediately identifies the address and the message that are being signed.  It is easily copy&pasted via email or text files, and is fairly compact for visual identification.   Click the link above to see an example signature block and an Armory screenshot of the UI (which needs improvement, but still usable).  The verification process will include:

-- Check that the public key (included or recovered) matches the address field. 
-- Verify that the signature matches the included message for this public key
-- The message is properly formatted with a standardized character set and escape/replacement scheme for things like newlines or double-quotes.

gmaxwell already pointed out that key recovery makes the "Public Key" field pointless.  Okay fine -- I just don't have key recovery implemented yet in Armory, and when I do I can ditch that field (or simply make it optional).  The point is to create a versatile, human-readable standardized form, much like the BIP 0010 signature-collection scheme.


(2) Sign-Message URI scheme  -- Request signed messages from users using URIs

I had the idea that for certain services, the first funding address could be used to identify the owner of an account, and all account maintenance (such as cashouts) be done through signed messages with this address.  For instance, the user would need both a login password and a signed message in order to make a withdrawal or purchase:

    ("Please withdraw 12.3 BTC from acct 1828349132 to address 1Hfr3jk2093f")_signed_by_A

This gives the service the ability to use two separate factors to authenticate the request (username&password and access to unencrypted wallet).  This could work with manual signature blocks alone... but it's too many steps for regular users.  However, I think it's workable if we expand bitcoin URIs to include "Signature Requests".

The URI scheme would add a few parameters to the scheme, and would have to have further replacement rules to make sure that messages are handled properly.   The general CONOPs would be (Concept of Operations):

    -- User navigates to "Withdraw funds" on webpage
    -- Webpage has you fill in the details:  from-account, to-address, withdrawal amount
    -- Webpage produces a clickable URI link that loads all the information into your client, including addr-reqd-for-sig
    -- Client asks for confirmation and passphrase (if necessary) then produces a signature (and sig block if necessary)
    -- URI may include reply-to field that tells it where to send the siganture when it's ready

So the extra tags that would be needed would probably be:

        "requestSig=True":
                Flag to identify that this is a signing request URI
        "sigNeeded=1Qjf3392k31h"
                The address that needs to sign the message
        "message=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"
                Some encoding of the message that can be parsed the same way on all systems
        "replyurl=http://requestor.com/sig_replies.asp?"
                (Optional) After signing, application will submit the signature to the replyurl

The reply url could be simply an http URL which will use bitcoin URI syntax, with the fields above copied.  Therefore, to complete the above request, the application handling the request will simply send an HTTP request to:

    http://requestor.com/sig_replies.asp?sigNeeded=1Qjf3392k31h&message=...&signature=1fb1893ac193...&replySig=True

Any thoughts?  (I have no doubts that there are :) )

-Alan





--------------000201060401000405020701--