[dnssec-key-tf] Proposed Mesage to IANA

On 16 Apr 2008, at 10:34, Daniel Karrenberg wrote:

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

Perhaps we combine these to get: The registry should be technology  
neutral. It should not exclude or prevent different flavours of trust  
anchors to be published provided those trust anchor technologies are  
documented by 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 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.

I'd like to know this rather than assume it was SOP. At the moment  
Daniel, not all TLD requests involve something we'd recognise as a  
secure channel. Though I understand this is one of the many things Kim  
has in the pipeline.

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

Again, I'd like to know that rather than assume it.

As for the rest of the draft Daniel, I like it. You've done a nice job  
here of weeding out the cruft and aligning things with how the IANA  
effort is progressing. Thanks.

> RIPE DNSSEC trust Anchor Repository Task Forkce
> Jim Reid
> Chair

Er, it's news to me that I chair the TF. :-) I didn't think we had  
one. However it says this on the web site, so it must be true. :-)

My personal preference here would be for the TF to reach consensus and  
have that endorsed by the DNS WG. And then the WG sends something on  
behalf of the RIPE community to ICANN. We set up the TF because the WG  
was evenly divided, so I would be more comfortable if the WG supported  
the draft rather than the TF.