From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B73E1BCB for ; Mon, 13 Jul 2015 13:21:17 +0000 (UTC) X-Greylist: delayed 00:09:51 by SQLgrey-1.7.6 Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BE3D9ED for ; Mon, 13 Jul 2015 13:21:16 +0000 (UTC) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 20F4047E360 for ; Mon, 13 Jul 2015 15:06:14 +0200 (CEST) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id AF7D5FB89E for ; Mon, 13 Jul 2015 15:06:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 7dk8M-hELblH for ; Mon, 13 Jul 2015 15:06:09 +0200 (CEST) X-Originating-IP: 78.51.244.222 Received: from [192.168.1.3] (f051244222.adsl.alicedsl.de [78.51.244.222]) (Authenticated sender: thomasv@electrum.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 23A79FB87F for ; Mon, 13 Jul 2015 15:06:08 +0200 (CEST) Message-ID: <55A3B7C0.6030909@electrum.org> Date: Mon, 13 Jul 2015 15:06:08 +0200 From: Thomas Voegtlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: <55A3B52C.9020003@electrum.org> In-Reply-To: <55A3B52C.9020003@electrum.org> X-Forwarded-Message-Id: <55A3B52C.9020003@electrum.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Proposal: extend bip70 with OpenAlias X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 13:21:17 -0000 Dear Bitcoin developers, I would like to propose an extension of the signature scheme used in the Payment Protocol (BIP70), in order to authorize payment requests signed by user@domain aliases, where the alias is verified using DNSSEC (OpenAlias). Note that the Payment Protocol already includes the possibility to sign requests with user@domain aliases, using so-called "SSL email certificates". Email certificates do not require ownership of a domain name. They are usually delivered by a trusted CA, to the owner of an email address. So, why extend BIP70? Well, I believe that SSL email certificates, as they exist today, are not well suited for payment requests. The core issue is that email certificates are not delivered by the entity that owns the same domain. This has the following implications: 1. No cross-verification. Two different CAs may deliver certificates for the same email address. Thus, if a user's mailbox is compromised, the hacker can obtain a new certificate for the compromised email address, from another CA, and sign payment requests with it. OTOH, if the certificate was delivered by the same entity, they could require revokation of the existing certificate before issuing a new one. Revocation of a certificate would require signing a challenge with the corresponding private key. 2. Dilution of responsibilities. Three parties are involved in the security of an email certificate: the owner of the email address, the CA who signs the certificate, and the owner of the domain hosting the email service. If something goes wrong and a user claims that a payment request was not signed by them, it is not possible to determine who is to blame: the user, the domain owner or the CA? Any of these parties could have obtained or issued a new certificate. OTOH, if the alias "user@domain" was issued by "domain", we would have clear semantics and clear responsibilities. Instead of involving three parties, as in "User X hosted at domain Y was verified by trusted authority Z who is not shown in the alias", the alias only involves two parties: "user X was verified by domain Y". If domain Y misbehaves and issues a second certificate for user X, while the first certificate is still valid, then the first certificate can serve as a public proof that they misbehaved. 3. Lowest common denominator: email is only a communication channel, used for authentication by some CAs. Other CAs may decide to use other, possibly better, identity verification procedures. However, because of the absence of cross verification, the security of the whole scheme will always be the security of an email address, because it remains the method used by less regarding CAs. In fact, these issues are so bad that I believe BIP70 should be amended to reject email certificates. These issues would be solved, if we could enforce that the user@domain certificate was delivered by the same entity that controls the domain. How can we do that? Clearly, we need to change the certificate chain validation procedure. I see two methods to achieve this: 1. Keep using TLS and change the certificate chain validation. 2. Use DNSSEC and Openalias. Method 1: Modified chain validation. ------------------------------------ This introduces a new type of user certificate, where: - The commonName is a user@domain alias. - The certificate for user@domain must be issued by a domain certificate for the same domain (with some rules to allow wildcards). - Validation of the user@domain certificate does not require the issuer certificate to have a CA bit. This solution would probably be the easiest to deploy, because it uses TLS certificate chain validation, which is already available in BIP70 compatible wallets. However, it will break compatibility with the existing certificate validation procedures. Method 2: DNSSEC and OpenAlias. ------------------------------- OpenAlias (http://openalias.org) is a standard for storing Bitcoin addresses and public keys in DNS TXT records. DNSSEC chain validation imposes that a record is signed by its parent. In order to use DNSSEC with BIP70, we may add a new pki_type to BIP70 payment requests (let me call it 'dnssec+btc'), that indicates that the request has been signed with a Bitcoin public key, and that the chain validation uses DNSSEC. The chain of signatures may be included in the payment request. This solution has my preference. It has been implemented in Electrum and will be available in version 2.4. Please let me know what you think. Standardizing that proposal will probably require a new BIP number, because BIP70 is already final. I am willing to help doing that. OpenAlias developers have also expressed their support, and are willing to provide assistance.