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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
