[ dunno to whom you are replying, but they miss the point, imiho ]
Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? yes.
to the best of my limited knowledge, the crypto has never been an issue with dnssec. it was done well from day zero, and has not changed. how it has been *used*, i.e. key management and use, have been the issues. e.g., the embarrassing deployment show-stopper (everything would have to roll at once) that delegation signer addressed. what still seems to remain poorly addressed is trust anchor management, e.g., roll and revocation of the root key. as far as i can tell, dlv attempts to address this by bypassing the root (from the dnssec aspect only). one half of what we seem to be trying to sort out is that it seems to have actually left the same problem, merely moving it to key management for the dlv servers' trust anchors. i don't know if there is hope for this one in the current design. is it like bogon filters, all who want to play are responsible for keeping abreast of changes and keeping their configs up to date? and dlv seems to add a new problem, needing to understand and feel comfortable with the policies and procedures by which dlv services vet and insert keys into their service. we know the policies of the iana and the root, whether we like them or not. i suspect and hope that this one can be relatively easily addressed, at least as far as isc's proposed service goes, by some specs from isc, joao's jet lag permitting and if the water don't rise (tm sra). dlv also sidesteps the layer 8..42 issues with the iana taking responsibility and authority for signing the root zone. reading drc's posts, this seems to be a wise move, though sad and somewhat embarrassing to see. but it ain't the crypto. never has been. and it is not always easy to explain math in plain english. so let's focus on where work needs to be done. randy