[dnssec-key-tf] let's get things started

At long last, we have a mailing list to discuss the issue of a DNSSEC  
key repository that spun out of the discussions in Tallinn. So let's  
get down to work. :-) There are 6-7 weeks to go before the next RIPE  
meeting and it would be wonderful, if a little ambitious, if this  
task force has something to report to the WG by RIPE55.

The WG appeared to be evenly split in Tallinn and the positions were  
almost mutually exclusive. Half wanted some trusted, neutral entity  
(the NCC perhaps?) to provide a central key repository, principally  
for TLD DNSSEC keys. The other half didn't want that and seemed to  
prefer the effort was spent on getting the root signed. I think it's  
fair to say that we all want so see the root signed. The disagreement  
(if it can be called that) is one of strategy.

The key repository folks see that as another stepping stone on the  
way to getting the root signed, figuring out how to do key rollover  
and other key management stuff as well as working out good operating  
practices and processes. OTOH the root guys consider that key  
repository to take pressure off the powers that be to remove the  
obstacles to getting the root signed.

So, here are some things to chew on and hopefully start the discussions:

[1] Suppose IANA (say) signed the root zone and put it on some name  
servers -- not the real root servers -- for consenting adults to play  
with trust anchors, signed TLD delegations and so on. Is this a good  
idea or not? Would IANA be the best or only entity who could do this?

[2] DLV has gone to Last Call. There has been a suggestion made that  
the DNS WG (or this task force) should comment on the draft. For  
example to encourage IAB/IESG to do the Right Thing. Whatever the  
Right Thing would be.... Is it worth us commenting on the IETF list?  
If so, what do we say?

[3] Is there value in having a trusted repository for DNSSEC keys? If  
so, what keys could/should be stored there? What are the implications  
of that? Should the NCC operate such a repository? If so, on what  
basis does it do that and how would that be reviewed and supervised?  
What would be the exit strategy, if any?

[4] Suppose there was a trusted key repository. How would the  
authentication and validation aspects be handled? ie If I present a  
(new) key for some TLD, how is this verified and what happens if it  
isn't? How are those keys securely made available? For instance to  
embed in named.conf trusted-keys{} statements...


Feel free to answer these questions. Or add more questions... :-)

I am also expecting Peter to wade in with the obvious questions on  
process. :-) For example, what are this task force's delieverables  
and when should they be produced, milestones and so on. Personally, I  
hope we can have the "what are we here for?" discussions in parallel  
with the technical/engineering ones. IMO it shouldn't be necessary to  
spend lots of time writing up a charter or defining our scope. Though  
if you feel differently about that, please speak up!

BTW, the sign the root statement was sent to ICANN and discussed  
during the ccNSO session at the ICANN meeting in Puerto Rico. There  
wasn't much interest. There were a few questions in the panel session  
that followed the presentation, mostly on matters of clarification.