1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B73E1BCB
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <thomasv@electrum.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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.
|
