I agree the resources are non-trivial But it creates a put-up or shut-up point for the non-US objectors to the sole US controlled root. What it does not do is to address the state dept concerns that the root is a liability. And the cost of setting up an apex authority are much less than the cost of fracturing the root. Given the complete lack of interest that the DNSSEC community has had in consultation with deployment stakeholders, the quorate approach might well be important as a way to co-opt the existing Domain Validated SSL cert providers to seed a DNSSEC deployment in a DLV structure. One of the administrative parts of the puzzle that nobody seems to have thought out is why the registrars are going to play ball. Or for that matter what the charge for a DNSSEC zone entry is going to be. On Thu, Jun 11, 2009 at 8:35 PM, Stephen Kent<kent@xxxxxxx> wrote: > Phil, > The examples you give about backed-in trust anchors are valid, but they > point to decisions by vendors to simplify their designs at the cost of > secruity and functionality. I've been told that it is very hard, if not > impossible, to permanently remove some vendor-supplied TAs in a popular > browser. These are not fundamental results of architectural decisions of > the sort the IETF makes, but vendor choices that lead to possible problems > for user. > I think I understand the multi-party, RP-centric threshold approach to > managing the DNSSEC root that you outlined. But, in a DNSSEC environment, > IANA performs two roles: > - it coordinates the info from the gTLDs and ccTLDs and constructs > the authoritative root zone file > - it signs the records of that file > Any scheme that allows multiple entities to "confirm" the content of the > root zone file also has to include a means for these entities to > independently acquire and verify the master file data and to create a > separate, distinct master file if they disagree. This is a lot more complex > that what you outlined in your message (from an from an administrative vs. > crypto perspective). It also raises questions about how complex RP software > has to be in dealing with multiple sets of quasi-authoritative root > authorities. All experience to date suggests that RPs fare poorly when > trying to deal with much less complex trust anchor situations in other PKI > environments today. > It is conceivable (under the new administration) that ICANN will stop being > under the control of the U.S DoC, but it also is not clear that such a > change would ameliorate the concerns of all governments with regard to this > issue. I think the set of folks who feel a need to use other than the > current, proposed model (IANA as the DNSSEC root) are a very small minority > of the set of public Internet users and thus they should bear the burden of > dealing with the resulting costs and complexity for managing alternative > root schemes. I don't think that such costs and complexity should be borne > by the vast majority of Internet users. Its also not clear how long one > might spend debating the question of whether any single scheme would satisfy > all of the players who are not comfortable with the current model. > > Steve -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf