Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
	designates 50.117.27.232 as permitted sender)
	client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
	helo=mail.taplink.co; 
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Date: Fri, 28 Feb 2014 22:26:39 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xb05iptvyldrnw@laptop-air>
User-Agent: Opera Mail/1.0 (Win32)
Subject: [Bitcoin-development] Positive and negative feedback on certificate
	validation errors
Precedence: list

We currently have subtle positive feedback of a signed payment request in  
the form of the green background. Unsigned requests simply show up without  
the green background, as well as requests which provide a certificate but  
have a missing or invalid signature.

There's a open bug (#3628) and pull request (#3684) to provide negative  
feedback (yellow background) for a missing or invalid signature, but it  
seems like there's some debate on whether bitcoind should do that...

If an attacker can avoid the negative feedback by just stripping the  
signature and setting pki_type to none, then arguably there's no security  
benefit by singling out badly signed payment requests from unsigned  
payment requests.

So perhaps the root problem is that the positive feedback (green  
background) is not strong enough to make its absence highly conspicuous to  
the end user.

As an aside, how could we go about implementing the equivalent of HTTP  
Strict Transport Security for payment protocol to prevent this trivial  
signature stripping attack? Is this a possible extension field merchants  
are interested in?