Proposal: extend bip70 with OpenAlias

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.

Hi Thomas,

FYI there is a company called Netki is also working on a kind of DNSSEC integration with BIP70, there's a thread here about their efforts:

https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J

If you would like to work on this, perhaps it's worth teaming up with them? Obviously they plan to have an open spec and open source implementation.

Now w.r.t. the other things - I think we have discussed this before, but to reiterate: the biggest flaw with doing things the way you suggest is that in practice, no email provider is going to implement your scheme any time soon. Most obviously the big web mail providers won't. Therefore hardly anyone will use it.

Whilst having an extension cannot really hurt, obviously, BIP70 will not be amended to reduce the certificate types it allows in favour of a system that has a very low chance of mainstream adoption. Restricting options like that would just make no sense at all.

I think your primary concern is that if your email account is hacked, someone could get a cert issued in your name, and you'd be unable to revoke it? But that's not quite true. Every CA I know of allows you to revoke a certificate that was issued for your email address if you have access to that email address. Now, if you don't know that this issuance took place, you cannot invoke that procedure of course .... but that's what certificate transparency is already working on solving in a scalable manner:

  https://crt.sh/

That site doesn't currently index email address certs, but it certainly could with minimal extra effort by the creators as they're almost identical to domain name certs.

So the existing infrastructure seems to have everything in place to solve that issue.

Now, if you still want a mechanism that eliminates the CA entirely, I think there's a better approach which is backwards compatible with existing email providers. It works like this:

   1. User sends a public key in the subject line to a one-time collector
   address like <random-number>@publish-email-headers.net    (who runs this
   service is arbitrary as they do not need to be trusted). On receiving the
   email, the headers are made available via
   https://publish-email-headers.net/<random-number> for download by the
   users wallet.

   2. The act of sending the email triggers DKIM signing of the subject
   line and From header, and thus, the public key and email address are bound
   together via the ESP's own signing key.

   3. The textual email headers can be run through the DKIM validation
   algorithm in combination with the domain key retrieved via DNS.

With this scheme, setup is largely automatic and involves the wallet asking the operating system to open a mailto: URL. The user just has to press "send" and the wallet can then sit on a long-lived HTTPS connection waiting for the headers to turn up. Once the headers are downloaded, they can be saved to disk and this becomes your "DKIM certificate" which can then be used with a new pki_type in BIP70.

Note the following useful characteristics of this approach:

   1. It does not require the email provider to know/care about Bitcoin.
   DKIM is already widely deployed by major email providers due to its
   benefits for spam and phishing protection: the majority of all email on the
   internet is DKIM signed. So you automatically have a system that works with
   nearly all consumer email accounts.

   2. The enrolment UI is straightforward, assuming the user has a working
   mailto: handler on their system. Even webmail services like Gmail can
   attach themselves to mailto: handling these days.

   3. There are DKIM validation libraries already in existence, so new code
   required is minimal.

And the downsides:

   1. There is no way to revoke such a "certificate" because you have, of
   course, abandoned the PKI which specifies how to handle all these details.
   You could potentially hijack/reuse OCSP to allow such a custom cert to be
   revoked, but then the question is, who actually runs such a revocation
   server. Doing things like this is why we have CAs in the first place.

   2. The UX leaves a bit of binary nonsense in the users sent folder that
   clutters up their account.

   3. Does it even solve the right problem? A lot of users don't actually
   use emails as identifiers anymore. In the modern world people are using
   their social networking profiles (i.e. Facebook) and phone numbers (e.g.
   for WhatsApp) as the personal identifier of choice. Email address support
   might be solving yesterdays problem.

Mike Hearn wrote:

> Hi Thomas,
>
> FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70,
> there's a thread here about their efforts:
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J

Hi Mike,

Thanks! I believe it is better to keep the current discussion on bitcoin-dev, though.

> If you would like to work on this, perhaps it's worth teaming up with them?
> Obviously they plan to have an open spec and open source implementation.
>

I would love to work with Netki. However, it's not clear to me what they are selling. OpenAlias is an open standard, not a company. In contrast, Netki have very long Terms of Service, that do not help understand what part of their solution is open-source, and what is the product. They surely know about OpenAlias, it would be nice to hear what they think about it.

> Now w.r.t. the other things - I think we have discussed this before, but to
> reiterate:  the biggest flaw with doing things the way you suggest is that
> in practice, no email provider is going to implement your scheme any time
> soon. Most obviously the big web mail providers won't. Therefore hardly
> anyone will use it.
>

What I propose does not rely on email. Please read again. I am proposing an alternative way to sign BIP70 requests. This is independent from the communication channel used to send/receive them.

> Whilst having an extension cannot really hurt, obviously, BIP70 will not be
> amended to reduce the certificate types it allows in favour of a system
> that has a very low chance of mainstream adoption. Restricting options like
> that would just make no sense at all.
>

Hardly anyone uses email certificates today, so I don't think it would affect a lot of users. In contrast, it would increase the security of all users who don't use email certs, because they may receive a payment request signed by an email cert.

> I think your primary concern is that if your email account is hacked,
> someone could get a cert issued in your name, and you'd be unable to revoke
> it?

If your email account is hacked and someone else gets a certificate in your name, you'd be unable to *know* about it, because they would use a different CA.

> But that's not quite true. Every CA I know of allows you to revoke a
> certificate that was issued for your email address if you have access to
> that email address. Now, if you don't know that this issuance took place,
> you cannot invoke that procedure of course .... but that's what certificate
> transparency is already working on solving in a scalable manner:
>
>   https://crt.sh/
>
> That site doesn't currently index email address certs, but it certainly
> could with minimal extra effort by the creators as they're almost identical
> to domain name certs.
>
> So the existing infrastructure seems to have everything in place to solve
> that issue.

That does not look so... not until (1) BIP70 wallets integrate with https://crt.sh, (2) you convince that service to index email certs (3) you convince all CAs to report all email certs they issue to crt.sh.

Good luck with that!

> Now, if you still want a mechanism that eliminates the CA entirely, I think
> there's a better approach which is backwards compatible with existing email
> providers. It works like this: [...]

Again, that olution is for email only. We both agree that this is solving yesterdays problems, so there's no need to discuss that.

Hi Mike,

FYI there is a company called Netki is also working on a kind of DNSSEC

> integration with BIP70, there's a thread here about their efforts:
>
>
>
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J
>
> If you would like to work on this, perhaps it's worth teaming up with them?
> Obviously they plan to have an open spec and open source implementation.
>

Netki's solution is incredibly limited, it's a single return value and no metadata (where OA encapsulates metadata in KV pairs). This does not lend itself well to handling BIP70-style communication.

As an aside, they also seem to have a complete disregard for lookup privacy, which we address in OpenAlias by means of DNSCrypt encrypted lookups. To that end we have even written the first independent DNSCrypt implementation (ie. over-and-above dnscrypt-proxy) which provides a full Python implementation that uses libsodium / nacl if available, but falls back to a 100% Python slownacl implementation: https://github.com/openalias/dnscrypt-python

Riccardo

> If your email account is hacked and someone else gets a certificate in
> your name, you'd be unable to *know* about it, because they would use a
> different CA.

Maybe I am confused but I thought you are using DNSSEC to sign the zones so only the domain owner could issue certificates for a zone (or corresponding email address). If you have "example.com" the domain owner of the domain would sign zone "joe.example.com" which can correspond to the "joe@example•com" email address. Under this scenario you would only have one CA per domain.

Russ

Hi Thomas,

Re: NetKi, I think any proposal in this space has to be an open standard, almost by the definition of what it is. At any rate, it may be worth talking to them. They have signed up to implement their system at least.

I did understand that your proposal does not rely on email - for instance a web forum could issue username@reddit•com type aliases, even if those are not also email accounts. I am just continuing the comparison against email address certs.

It's also the case that a domain can use the DKIM setup without actually offering email accounts. They can just have a web form or API that triggers sending of the signed email (or simply, providing the signed headers themselves). Thus the same system can be used transparently by both email providers and other sites that don't give their users email addresses, but would still like to use the same system.

Hardly anyone uses email certificates today, so I don't think it would

> affect a lot of users.

No, but obviously we'd like to change that! The holdup is not the certificate side of things, really, but rather the lack of a store-and-forward network for signed payment requests. I keep asking someone to build one but I fear the problem is almost too simple ...... everyone who looks at this decides to solve 12 other problems simultaneously, it gets complicated, then they never launch :(

Once there's a simple and robust way to get PaymentRequest's from one end user to another, even when that first user is offline, then getting an email cert issued is no big deal.

That does not look so... not until (1) BIP70 wallets integrate with

> https://crt.sh, (2) you convince that service to index email certs (3)
> you convince all CAs to report all email certs they issue to crt.sh.
>

Any solution that separates identity providers from certificate issuers would have these requirements, though. And as many identity providers today do not wish to become CAs too, it seems fundamental.

I don't think it's such a problem, mind you. The crt.sh website is actually a frontend to the CT protocol, which is a somewhat blockchain like audit log that's eventually intended to contain all issued certificates. Right now, of course, they focus on SSL certs because those are the most common and important. If other kinds of certs became more widely used, support in the infrastructure would follow.

Don't get me wrong - I would like to see a way for a domain to delegate BIP70 signing power to a third party. For instance, this would mean payment processors like BitPay could sign on the behalf of the merchant, and the merchant identity would then show up in wallets. The "chain a cert off a domain cert" trick would be a good way to do that, though rather than hacking the X.509 stack to validate invalid stuff, at this point it may as well be a custom (better) cert format. There's little reason to use X.509 beyond backwards compatibility.

But the most popular identity providers today either don't care about Bitcoin at all, or worse, are developing competitors to it. So for real adoption to occur, we must have solutions that do not require identity provider cooperation. I realise this is a business reason rather than a technical reason, but it's a very strong one - so bootstrapping off existing infrastructure with a split CA/ID provider design still makes much more sense to me.

Le 14/07/2015 13:19, Milly Bitcoin a écrit :

>
>> If your email account is hacked and someone else gets a certificate in
>> your name, you'd be unable to *know* about it, because they would use a
>> different CA.
>
> Maybe I am confused but I thought you are using DNSSEC to sign the zones
> so only the domain owner could issue certificates for a zone (or
> corresponding email address).  If you have "example.com" the domain
> owner of the domain would sign zone "joe.example.com" which can
> correspond to the "joe@example•com" email address.  Under this scenario
> you would only have one CA per domain.
>

One CA per domain is indeed what I want to achieve. The paragraph you quoted was about the current situation with email certs, where that is not the case.

Hi Mike,

The reason why I would like to extend BIP70 is because it is currently not being used in transactions between end-users. BIP70 works very well in B2C situations, where users buy products from a website. However, end-users still share Bitcoin addresses.

Before BIP70 was written, I had proposed "Signed URIs", where the signature is a public proof that a payee requested a payment. This is one of the main benefits of BIP70, and I still want to bring it to user-to-user transactions.

I believe one of the main barriers to BIP70 adoption is that bitcoin: URIs have been extended in a way that requires the request to be hosted on a webserver. You may complain about the lack of store-and-forward network, despite the apparent simplicity of creating one such network. However, that does not mean we should absolutely do things that way and wait until such a network exists.

Bitcoin addresses do not require a webserver. If we want to build something that competes with that, we should have at least that level of convenience.

EC signatures are short, and they can be shared by copy-paste, or added to a bitcoin: URI. This is a features of my "Signed URIs" proposal, that was lost in BIP70. Indeed, signed URIs were self-contained. A serialized payment request can also be made very short, if it is signed by a EC key, and if it does not include the chain of certificates. Such a "lightweight request" can be base58-encoded, and easily shared by copy-paste, or passed in a bitcoin: URI.

Size is another reason why I proposed to use DNSSEC in BIP70 (the first reason is that the subdomain is signed by the domain, not by an external CA). Indeed, DNSSEC provides a canonical way to download the chain of signatures needed to verify a record. Thus, the chain of signatures does not need to be included in the payment request; it can be downloaded and archived by the verifier.

Now, I understand that SSL vertificates have distinct advantages over DNSSEC; for example, CA-signed SSL certificates have a legal value, which is important for dispute resolution.

Would it be possible to create the same kind of "lightweight payment requests" using SSL certificates? Probably, if the final signing key is a EC key, and if the payment request does not include the whole chain of certificates. (However, that would require an additional infrastructure to publish the chain of certificates, and I do not think that x509 certification path are unique, which makes things more complicated, but not impossible).

Sorry if I did not answer point-by-point to your post. I felt that I failed to explain one of the reasons why I want to use DNSSEC in the validation of payment requests.

Thomas

Le 14/07/2015 13:45, Mike Hearn a écrit :

> Hi Thomas,
>
> Re: NetKi, I think any proposal in this space has to be an open standard,
> almost by the definition of what it is. At any rate, it may be worth
> talking to them. They have signed up to implement their system at least.
>
> I did understand that your proposal does not rely on email - for instance a
> web forum could issue username@reddit•com type aliases, even if those are
> not also email accounts. I am just continuing the comparison against email
> address certs.
>
> It's also the case that a domain can use the DKIM setup without actually
> offering email accounts. They can just have a web form or API that triggers
> sending of the signed email (or simply, providing the signed headers
> themselves). Thus the same system can be used transparently by both email
> providers and other sites that don't give their users email addresses, but
> would still like to use the same system.
>
> Hardly anyone uses email certificates today, so I don't think it would
>> affect a lot of users.
>
>
> No, but obviously we'd like to change that! The holdup is not the
> certificate side of things, really, but rather the lack of a
> store-and-forward network for signed payment requests. I keep asking
> someone to build one but I fear the problem is almost too simple ......
> everyone who looks at this decides to solve 12 other problems
> simultaneously, it gets complicated, then they never launch :(
>
> Once there's a simple and robust way to get PaymentRequest's from one end
> user to another, even when that first user is offline, then getting an
> email cert issued is no big deal.
>
> That does not look so... not until (1) BIP70 wallets integrate with
>> https://crt.sh, (2) you convince that service to index email certs (3)
>> you convince all CAs to report all email certs they issue to crt.sh.
>>
>
> Any solution that separates identity providers from certificate issuers
> would have these requirements, though. And as many identity providers today
> do not wish to become CAs too, it seems fundamental.
>
> I don't think it's such a problem, mind you. The crt.sh website is actually
> a frontend to the CT protocol, which is a somewhat blockchain like audit
> log that's eventually intended to contain all issued certificates. Right
> now, of course, they focus on SSL certs because those are the most common
> and important. If other kinds of certs became more widely used, support in
> the infrastructure would follow.
>
>
>
> Don't get me wrong - I would like to see a way for a domain to delegate
> BIP70 signing power to a third party. For instance, this would mean payment
> processors like BitPay could sign on the behalf of the merchant, and the
> merchant identity would then show up in wallets. The "chain a cert off a
> domain cert" trick would be a good way to do that, though rather than
> hacking the X.509 stack to validate invalid stuff, at this point it may as
> well be a custom (better) cert format. There's little reason to use X.509
> beyond backwards compatibility.
>
> But the most popular identity providers today either don't care about
> Bitcoin at all, or worse, are developing competitors to it. So for real
> adoption to occur, we must have solutions that do not require identity
> provider cooperation. I realise this is a business reason rather than a
> technical reason, but it's a very strong one - so bootstrapping off
> existing infrastructure with a split CA/ID provider design still makes much
> more sense to me.
>

Hey Thomas,

Was great to hang out with you in Berlin last week!

> Bitcoin addresses do not require a webserver. If we want to build
> something that competes with that, we should have at least that level of
> convenience.
>

Absolutely agree! Convenience for the user is an absolute must. I just don't know how to let users exchange large data packets without some kind of server acting as a dropbox in the middle. That leaves two solutions:

1) Set up a way for users to exchange large data packets by using other people's web servers, e.g. with no user visible signup flow (pure p2p/done automatically in the background by user wallets)

2) Make the data packets small instead.

We can debate better signing methods that work towards (2). The reason I am unsure about this is that the point of BIP70 is to be extended with useful features. Even if we find a way to squeeze a human-meaningful signature/cert into a URI, that's only one of BIP70s features. The next set we want to add might end up running out of space again.

A lot of the problems come from how limited QR codes are. So perhaps there is also a third approach: either find a better replacement for QR codes (maybe something that uses colour like Microsoft Tag <http://tag.microsoft.com/what-is-tag/home.aspx>), or drop them as a design constraint.

Calling Jeff Garzik, Jeff, are you there? I recall BitPay did some experiments to find out how much data you can stuff into a QR code before it hurts scannability too much, do you have a writeup anywhere?

This is the main reason I feel uneasy about anything that isn't "build a store+forward network". QR codes are so fundamental to our ecosystem, but sooooooo limited, that I'm not sure how else to move forward. We were told when designing BIP70 that even putting a URL in the QR code is pushing it! There was talk of compressing the URL in some way. So adding even an ECC signature which is much longer seems risky.

We can imagine a parallel universe where our societies technology was more NFC oriented: laptops had NFC tags in them, phones had better NFC support etc. Then we would have more bytes to play with and we wouldn't face this pointer-indirection problem :( But laptops don't have the hardware and Apple sits on their NFC API because they can't imagine any use case that isn't credit cards :( :(

To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:

   1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
   won't fit nicely in a QR code, I think.

   2. 1024 bit is the absolute minimum strength you can get away with,
   really. DNSSEC assumes frequent key rotations to try and help, which
   complicates things.

So I'm not sure using DNSSEC fixes the usability problem we want to fix.

I will do a separate reply to break out some thoughts on replacing QR codes.

Would it be possible to create the same kind of "lightweight payment

> requests" using SSL certificates? Probably, if the final signing key is
> a EC key, and if the payment request does not include the whole chain of
> certificates.

Given that the pre-existing value of the PKI is much lower for individuals than for companies/websites, where they all have certs already, building a Bitcoin-specific or entirely new/independent PKI for people is not so unthinkable, I agree.

In theory such a cert could be as minimal as:

<ECC signature>thomasv@electrum•org

so literally just a signature + a UTF-8 string, and that's it! You don't need anything more if you're willing to sacrifice extensibility, revocability, etc.

The pubkey of the CA would be obtained by running the pubkey recovery algorithm on the signature, and then checked against a table of trusted pubkeys.

hi Mike,

I hope you had a good trip!

> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
>
>    1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
>    won't fit nicely in a QR code, I think.
>
>    2. 1024 bit is the absolute minimum strength you can get away with,
>    really. DNSSEC assumes frequent key rotations to try and help, which
>    complicates things.
>
> So I'm not sure using DNSSEC fixes the usability problem we want to fix.
>

In my previous post, I was suggesting to *not* include the proof in the request, because the payer can download it independently. Only the final signature is needed. What makes DNSSEC interesting is not the size of the proof, but rather the fact that you can request it easily, and in a canonical way.

A typical lightweight payment request, serialized with EC signature and without the proof, would be about 150 bytes long.

> I will do a separate reply to break out some thoughts on replacing QR codes.
>
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key is
>> a EC key, and if the payment request does not include the whole chain of
>> certificates.
>
>
> Given that the pre-existing value of the PKI is much lower for individuals
> than for companies/websites, where they all have certs already, building a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
>
> In theory such a cert could be as minimal as:
>
> <ECC signature>thomasv@electrum•org
>
> so literally just a signature + a UTF-8 string, and that's it! You don't
> need anything more if you're willing to sacrifice extensibility,
> revocability, etc.

Again, we don't have to sacrifice revocability, if the proof is downloaded separately.

>
> The pubkey of the CA would be obtained by running the pubkey recovery
> algorithm on the signature, and then checked against a table of trusted
> pubkeys.
>

>
> In my previous post, I was suggesting to *not* include the proof in the
> request, because the payer can download it independently. Only the final
> signature is needed. What makes DNSSEC interesting is not the size of
> the proof, but rather the fact that you can request it easily, and in a
> canonical way.
>

Yes, but you still need the final signature. Is it possible to use an EC signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong about that, and all you need is 32 bytes, then my argument does not hold.

Le 20/07/2015 16:42, Mike Hearn a écrit :

>>
>> In my previous post, I was suggesting to *not* include the proof in the
>> request, because the payer can download it independently. Only the final
>> signature is needed. What makes DNSSEC interesting is not the size of
>> the proof, but rather the fact that you can request it easily, and in a
>> canonical way.
>>
>
> Yes, but you still need the final signature. Is it possible to use an EC
> signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
> about that, and all you need is 32 bytes, then my argument does not hold.
>

The final signature is a signature of the payment request, it is not part of DNSSEC. So, yes, that signature can be EC.

The DNSSEC proof is used to verify that the public key, which is recovered from the signature, corresponds to the alias.

The payment requests I am currently playing with have the following values:

pki_type = "dnssec+btc" (btc means that the signature is checked against a Bitcoin address stored in DNS) pki_data = the user's alias (DNS key)

>
> The final signature is a signature of the payment request, it is not
> part of DNSSEC. So, yes, that signature can be EC.
>

Right, got it. I think we've been talking about two related but separate issues (DNSSEC vs squeezing payment requests into URIs/qrcodes somehow). So: DNSSEC attests via an RSA chain to some EC key stored in the wallet which is then used to sign the payment request or URI, which also contains a domain name.

> The payment requests I am currently playing with have the following values:
>
> pki_type = "dnssec+btc" (btc means that the signature is checked against
> a Bitcoin address stored in DNS)
> pki_data = the user's alias (DNS key)

By "alias" you mean domain name? I'm not sure what DNS key means in this context.

I'm still not really convinced that a domain name under some new roots is an identity people will want to use, but yes, I guess your approach would work for those who do want it.

It still may be worth exploring the compact cert+optimized BIP70 (no DNSSEC) in a qrcode if making a network that stores small bits of data really is beyond us :(

Le 20/07/2015 17:14, Mike Hearn a écrit :

>
> By "alias" you mean domain name? I'm not sure what DNS key means in this
> context.
>

yes, sorry, I mean the domain name corresponding to the TXT record. it's called 'alias' in the context of OpenAlias.

> I'm still not really convinced that a domain name under some new roots is
> an identity people will want to use, but yes, I guess your approach would
> work for those who do want it.

What do you mean by "under some new roots" ?

If I believe Netki, there is enough people who want to have a Bitcoin address stored in DNS, for at least one company to thrive. :)

All I am proposing is a new usage for these already existing DNS records; not only to receive BTC, but also to sign requests with them.

> It still may be worth exploring the compact cert+optimized BIP70 (no
> DNSSEC) in a qrcode if making a network that stores small bits of data
> really is beyond us :(
>

Heh, pastebin + base64 encoding the PR could work. However, it might violate their ToS. More seriously, there might be some legal issues for a company willing to provide that kind of service.

Re QR codes: 150 bytes, using base43 encoding, is not too bad.

>
> What do you mean by "under some new roots" ?
>

I mean, most users will need to sign up for some new identity under a DNS tree that they don't currently use (whether that's netki.com or whatever).