I suspect that DNSSEC combined with tamper resistant private key storage (e.g. within mobile phones) once these technologies becomes more widely available, will help lessen a couple of hard key management problems to a useful extent. (NB these 2 problems don't have and probably never will have complete solutions).
1. Having a generally known and agreed place to obtain public keys from where the domain name represents the identity of the user and some kind of a chain of trust needs to be established to say that the public key for alice.smith.coventry.uk really belongs to the Alice known to have this globally unique identity. (If you don't like AINA as the identity trust root, DNSSEC enables you or your community to establish alternate and even multiple trust anchors). The advantage is that DNS identities are the ones we use anyway, the difference between firstname.lastname@example.org and alice.smith.coventry.uk being syntactic and not semantic.
2. Having arbitrarily short time to live values enables users to manage risk of key compromise and signature repudiation by leaving invalid signatures possible based upon user knowledge of key compromise for a known and more limited time extent. E.G if your bank requires you to inform them within 24 hours of your losing a signing device, it takes 48 hours to extract the private key from its tamper resistant container by someone with access to a semiconductor plant without destroying it, and the DNS record storing the key has a TTL of 24 hours, then the compromised key can be timed out before it can be used (unless a bank customer is unable to inform the bank within 24 hours. Larger transactions can have longer delays or additional security checks and those who think it may take them longer than 24 hours to inform their bank can insure against quantifiable risk, and the bank will probably be obliged to provide such insurance in exchange for normal bank charges).
One of the flies in this ointment concerns how Alice revokes her key once her mobile phone containing a tamper resistant module protecting her private key is stolen, if the signature from this key is the most reliable means for Alice to identify herself for this purpose. But I think all key-identity binding solutions have this problem, and require alternative means by which Alice's identity can be sufficiently established (e.g. personal knowledge of secrets over a phone conversation with Alice's bank). In this event the bank will prefer to risk an imposter who has been through Alice's rubbish bin and tapped her phone being able to cause a temporary denial of service on Alice's bank account than risk Alice's funds being stolen. Alternatively if Alice has signed a revocation certificate and left copies with friends who can identify her over the phone better than the bank, the bank may be able to accept a copy of one of these.
DNSSEC isn't just about securing the naming system, as I see it. It seems to provide for a more generic PKI.