[dnssec-key-tf] Proposed Mesage to IANA

New text. 

I dropped the escrow bit, because further cogitation makes it seem 
a very bottomless pit to me in the IANA context. I hope y'all can agree.
diff follows below:


------

Dear Barbara,

thank you for your note about the proposed DS key registry for TLDs. 
The RIPE DNS working group (DNS WG) force welcomes this
development. We would like to see IANA providing such a registry as
soon as possible. As you know we have developed a set of requirements
for such a repository. As these may be useful for you when implementing
the service, we offer them here:


[1] The registry should be technology neutral. It should not exclude or  
prevent different flavours of trust anchors to be published, provided
provided those trust anchors conform to the relevant standards.

[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 crypto gunk into stuff to plug into your  
resolver/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 verify that the keying material it receives comes 
from authorised source, verify it is correctly formatted and verify
it is consisten with what is published in the TLD zone before publishing it. 
There should also be a secure channel  for authenticating the TAR and any 
data it is publishing.

Comment: Using the same channels IANA uses to receive update requests to the 
root zone from TLDs is fine. We do not mean special new channels. 
https delivery and possibly checksums are sufficient for publication.

[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.

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

[6] The TAR must have exit strategy.

Comment: The proposal includes that.

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

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 Regards

RIPE DNS WG
Jim Reid
Chair 


------


5c5
< The RIPE DNSSEC Trust Anchor Repository task force welcomes this
---
> The RIPE DNS working group (DNS WG) force welcomes this
7,9c7,9
< 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:
---
> soon as possible. As you know we have developed a set of requirements
> for such a repository. As these may be useful for you when implementing
> the service, we offer them here:
13,16c13,14
< prevent different flavours of trust anchors to be published.
< 
< Comment: Publishing RRs as defined by the relevant standards meets
< this requirement.
---
> prevent different flavours of trust anchors to be published, provided
> provided those trust anchors conform to the relevant standards.
20,21c18,19
< to transform this tarball of crypto gunk into stuff to plug into your  
< name server configuration".
---
> to transform this crypto gunk into stuff to plug into your  
> resolver/server configuration".
27,32c25,33
< [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.
---
> [3] The TAR should verify that the keying material it receives comes 
> from authorised source, verify it is correctly formatted and verify
> it is consisten with what is published in the TLD zone before publishing it. 
> There should also be a secure channel  for authenticating the TAR and any 
> data it is publishing.
> 
> Comment: Using the same channels IANA uses to receive update requests to the 
> root zone from TLDs is fine. We do not mean special new channels. 
> https delivery and possibly checksums are sufficient for publication.
40c41
< [6] The TAR should be clear what support, if any, is available.
---
> [5] The TAR should be clear what support, if any, is available.
42c43
< [10] The TAR must have exit strategy.
---
> [6] The TAR must have exit strategy.
46,50c47
< [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
---
> [7] The TAR should only publish keying material with the consent of
53,55d49
< Comment: we believe that is SOP and part of the proposa.
< 
< 
61c55
< Kind rregards
---
> Kind Regards
63c57
< RIPE DNSSEC trust Anchor Repository Task Forkce 
---
> RIPE DNS WG
66,69d59
<