[dnssec-key-tf] Proposed Mesage to IANA

Let m make a fresh start.  Propsed mesage to IANA at bottom.
Here is what we had:

[1] The TAR should be technology neutral. It should not exclude or  
prevent different flavours of trust anchors to be published.

[2] The TAR should be OS/DNS implementation neutral. Tools and  
documentation should be provided for the common platforms: "here's how  
to transform this tarball of crypto gunk into stuff to plug into your  
name server configuration".

[3] The TAR should somehow verify the keying material it's given  
before publishing or storing it. There should also be a secure channel  
for authenticating the TAR and any data it's publishing.

[4] A process is needed to revoke a trust anchor and notify those who  
may be using the now withdrawn or invalid trust anchor.

[5] Everybody should sign up to T&C's that hold everyone else harmless.

[6] The TAR should be clear what support, if any, is available.

[7] The TAR must make it clear what they keying material is for and  
its political significance: eg "we're not undermining IANA" (or  
perhaps not) or "we make no claims about the appropriateness of the  
stuff in our TAR" (national sovereignty & competition issues).

[8] The TAR should treat all parties equally. Provided they  
demonstrate suitable levels of DNSSEC clue.

[9] There should be regular reviews of the TAR's usefulness: ie clear  
goals for defining "success" or "failure" and some way of establishing  
consensus around these goals.

[10] The TAR must have exit and escrow strategies

[11] The TAR should only publish keying material with the consent of
     the respective key manager.


Discussion:

[1] is being satisfied by the proposal. Just publishing RRs as defined in the standards
which would otherwise go into the root zone is abut as neutral as one can get.

[2] can be done, and we can help. IAnA could publish info or pointers to it.

[3] IANA SOP should be good enough. 

[4] needs to be implemented. Can be opt-in maillist.

[5] not sure if relevant in context. drop?

[6] relevant

[7] not relevant n contet, drop!

[8] not clear what this really means, don't know about cluelevel qualiication, drop that?

[9] dangerous in ICANN context, really needed? drop?

[10] exit part of proposal, escrow not, could delay things, drop?

[11] SOP I believe, anyway: relevant


So I propose toend the following to IANA (with numbering of requiremetns fixed) :

------

Dear Barbara,

thank you for your note about the proposed DS key registry for TLDs. 
The RIPE DNSSEC Trust Anchor Repository task force welcomes this
development. We would like to see IANA providing such a registry as
soon as possible. From our own work we have developed the following 
set of reuirements which may be useful for you when implementing
the service:


[1] The registry should be technology neutral. It should not exclude or  
prevent different flavours of trust anchors to be published.

Comment: Publishing RRs as defined by the relevant standards meets
this requirement.

[2] The TAR should be OS/DNS implementation neutral. Tools and  
documentation should be provided for the common platforms: "here's how  
to transform this tarball of crypto gunk into stuff to plug into your  
name server configuration".

Comment: IANA should publish such docmentation and tools, or pointers to 
them. Once we know details of repository, we can help putting together 
this documentation.

[3] The TAR should somehow verify the keying material it's given  
before publishing or storing it. There should also be a secure channel  
for authenticating the TAR and any data it's publishing.

Comment: We assume this is SOP for TLD requests and would be implemented
here also.

[4] A process is needed to revoke a trust anchor and notify those who  
may be using the now withdrawn or invalid trust anchor.

Comment: An opt-in mailing list for operational news should be sufficient
to satisfy this.

[6] The TAR should be clear what support, if any, is available.

[10] The TAR must have exit strategy.

Comment: The proposal includes that.

[10a] the TAR must store its data under escrow somewhere.

Comment: Not necessary to start with, i.e. should not delay but needs to be developed

[11] The TAR should only publish keying material with the consent of
     the respective key manager.

Comment: we believe that is SOP and part of the proposa.


Please let us know any the details of the repository as well as the time-line 
for implementation as soon as they become available. Please feel free to make
our supoort for this repository known to anyone in the ICANN govenance structure
if it helps to push this along.

Kind rregards

RIPE DNSSEC trust Anchor Repository Task Forkce 
Jim Reid
Chair 

--------

Can we have a discussion on what needs to be changed in the draft message?


Daniel