I wasn't part of this development effort, so I only remember the dev discussion we had about it a few months ago. The idea is that this system allows you to create your own "DNS zone", i.e. you are deploying your own cryptographic credentials to a ring of trustees. In that sense it's closer to GPG than the SSL/CA structure. You need only to corrupt one out of the existing 300 or so CAs to successfully spoof a domain.
More or less. Basically, starting at the DNS root, you have keys that can be used to sign keys for, say, the "com" zone. That key can then be used for the "bitcoinarmory.com" zone, etc.
This tutorial is a bit rough but covers the rough basics. The idea is that if, say, the bitcoinarmory.com keys get compromised, that can't be done to compromise amazon.com, or whitehouse.gov, or whatever. It is, on one level, a way to minimize damage should something go wrong.
With DANE records, you can reduce the 3rd party involvement since you have control on the chain of trustees (the different entities that will sign and store your ZSK). This means there is a finite set of trusted 3rd parties of your choosing an attacker has to compromise to spoof your identity rather than one out of N certificate authorities.
Correct me if I'm wrong, but if you are using your own DNSsec zone, you never expose your key signing key (KSK) to the network. You sign the zone signing key (ZSK) with it and expose that instead, whereas with SSL your certificate's private key has to be available to your server at all times to handshake.
AFAIK, except for a short transition period when keys swap out, there should only be one key valid at a time. (Well, I guess you can have multiple valid keys all the time, but that seems pointless and dangerous.) What happens is you have a Key Signing Key (KSK), which is a master key of sorts. This is used to sign the Zone Signing Key (ZSK), which is weaker and is also what you actually want to use to sign DNSSEC records. (If you're signing "com" records, you need a smaller key in order to be able to efficiently sign all requests.) The ZSK swaps out more often than the KSK, which is more long-term. If the ZSK is compromised, you can quickly deploy a new key and limit the damage. If the KSK is compromised, it creates a larger attack vector, although it's still more limited than it would be if, say, an SSL CA is compromised and creates certs for any and all web sites.
We will most likely come up with a plugin to create and manage KSK + ZSK directly from Armory, sometimes in the future.
We're definitely in the prototype stage. There is a testnet plugin that can pull down payment info based on an email address. It'll be awhile before anything is ready for primetime, especially since we need to formally submit it to various orgs and informally to the Bitcoin community. We just wanted to get some code and some examples out there before throwing this concept to the wolves.
One last point on security is how the DANE record is used to verify the addresses in our proposed scheme. It doesn't simply green-light the address you are asking for. It provides a mathematical proof that the bitcoin address you resolved from the payment request is indeed derived from the master public key that is associated with this domain in the issuers' the DANE record.
Yes, this is being done to pass along payment info based on BIP32. One cool thing about BIP32 that not a lot of people know is that it's possible to start with a parent public key, supply a 32 byte multiplier, and land at any derived key on the tree, no matter how deep you go. So, if amazon.com wants to accept Bitcoin, they can publish their public key and then send each customer a 32 byte multiplier that yields a 3rd level key, or 92nd level key, or whatever. That multiplier is then broadcast to the paying party, and Amazon's key is protected by DNSSEC/DANE.
