On Thu, 2 Apr 2015, John Levine wrote:
Most important, there's the scale issue. Reports say that Yahoo has over 300,000,000 active mailboxes and Gmail has over 500,000,000. I gather the goal here is to make publishing your key cheap and easy, so let's posit modest success and say that 20% of Gmail users have keys. It looks to me like a typical PGP key is about 1.5K,
That is not my experience from adding 1000+ keys from the fedoraproject.org into the _openpgpkey zone. The keys are bigger.
Is it really plausible that anyone is going to generate and sign and serve static zones more than an order of magnitude bigger than .COM? That seems like a stretch.
You do not need static zones. You just need to pull the right signed data from further inside your network on demand. I do not know of any DNS provider doing online signing for 1 zone on dozens or hundreds of DNS servers. The chance of losing your private key, and worse, not even knowing someone else has a copy of your private key, would be too high. In your example 499,000,000 records will never be asked for and do not need to be available on the DNS servers. The signed records do not need to reside in "zone files". The nameservers can fetch data on demand, without having the private key to sign their own data. I'm sure Yahoo and Google are smart and rich enough to implement the most insane and complicated scheme we throw at them. But there are many other players with a lot less time and money to throw at these problems. My problem is not with base32, it is with your suggested split and using a "." (or was it "\." and who knows what the difference is?) I fear will cause interop issues. If we can do lossless encoding using gzip then base32 or something, I would be okay with that. As long as we stick to < 63 characters. If that means some theoretical long high entropy email address cannot be mapped, I'm fine with that. I'm solving a practical matter, not a philosophical one. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
