Jerry Leichter <leich...@lrw.com> writes: >One could certainly screw up the design of a recovery system, but one >would have to try. There really ought not be that much of difference >between recovering from m pieces and recovering from one.
There's a *huge* difference, see my previous posting on this the last time the topic came up, http://www.mail-archive.com/cryptography@metzdowd.com/msg07671.html: the cognitive load imposed is just so high that most users can't cope with it, particularly since they're already walking on eggshells because they're working on hardware designed to fail closed (i.e. lock everything out) if you as much as look at it funny. The last time I went through this exercise for a high-value key, after quite some time going through the various implications, by unanimous agreement we went with "lock an encrypted copy in two different safes" (this was for an organisation with a lot of experience with physical security, and their threat assessment was that anyone who could compromise their physical security would do far more interesting things with the capability than stealing a key). For the case of DNSSEC, what would happen if the key was lost? There'd be a bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but it's not like commercial PKI with certs with 40-year lifetimes hardcoded into every browser on the planet is it? Presumably there's some mechanism for getting the root (pubic) key distributed to existing implementations, could this be used to roll over the root or is it still a manual config process for each server/resolver? How *is* the bootstrap actually done, presumably you need to go from "no certs in resolvers" to "certs in resolvers" through some mechanism. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com