... we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
so a key roll or change of delegation requires two levels of human intervention to work?
no. in the normal, non-DLV DNSSEC-bis model, a registrant informs its registrar of new KSK's before existing KSK's expire (or perhaps during revocation events) using the same authenticated automation they would use to change NS RRs or arrange for payment of fees or whatever. the registrar (like alice's for ISC) then tells the appropriate registry (like Afilias-PIR-UltraDNS, for .ORG) the new DS RR data using the same (EPP? RRP? fax? carrier pigeon?) authenticated automated model they would use when changing NS RR data. no human intervention at all. in the DLVified DNSSEC-bis model, the DNS registry (like VeriSign for .COM) is not yet accepting DS RR data via their EPP interface to their registrars, although i note with admiration that VeriSign has led the effort to add new EPP protocol elements to support this new data. as far as i know, no existing DNS registry will accept DS RR data. therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this "useless" data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby "lots of keys" can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available. until we get that working, we're left with the least desireable alternative, which is accepting keys directly from registrants, and authenticating these folks the hard way, with human hands and eyeballs. alas, i repeat myself. i've said this already. and if folks aren't going to read the explainations i really need to discipline myself into not repeating them.
DNS-SEC will live and die on the business model. How user-friendly it is vs. how necessary it is against what alternatives there are.
To be honest, waiting for so many years for DNS-SEC, if these questions were not answered by now...
to be equally honest, i'm now weary of hearing what can't be done or shouldn't be done. anyone who wants to not do dnssec is free to do that, they don't need to shout it from the rooftop. anyone else who wants to wait until the root is signed and NSEC3 is done and automated trust key rollover is done is welcome to wait -- no shouting is required from any rooftop by those, either.