[dns-wg] outcome from DNSSEC TAR Task Force

I'd like to offer my support to the statement below, in the absence of a
signed root this seems like the 'next best thing' and hopefully should help
the deployment of dnssec on two levels:
1. Encourage more tld's to sign their zones and publish their keys.
2. Make it easier and simpler for resolver admins to maximise the amount of
keys they support and minimise the work involved in keeping them configured.

Thanks to Jim and the rest of the task force for the work they did.

Brett Carr
Nominet UK.

On Sun, Apr 27, 2008 at 5:41 PM, Jim Reid <jim at rfc1035.com> wrote:

> Colleagues, the work of the task force has to some extent been overtaken
> by events. IANA's plans for a trust anchor repository (TAR) are progressing
> and the consensus of the task force is that the RIPE community should
> support that effort. The task force has produced a set of requirements for a
> TAR. It feels there is no need to do anything more at this stage: moves
> towards an alternate TAR may not help the IANA initiative.
>
> So on behalf of the task force, I'd like to ask the WG to consider these
> requirements and endorse them as a statement from the RIPE community which
> could be sent to ICANN. [A bit like our "sign the root" statement last
> year.] The proposed text is below.
>
> If the WG is happy with this letter, I suggest the task force declares
> victory (for some definition of victory) and either goes into hibernation or
> shuts down. Your comments about this letter and the suggested future for the
> task force would be appreciated. Is the upcoming RIPE meeting a reasonable
> deadline for comments?
>
>
> Dear Barbara,
>
> Thank you for your note about the proposed DNSSEC key repository for
> TLDs. The RIPE DNS working group (DNS WG) welcomes this development. We
> would like to see IANA establish this DNSSEC Trust Anchor Repository
> (TAR) as soon as possible. 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 TAR should be technology neutral. It should not exclude or
> prevent different flavours of trust anchors from being published,
> 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 use of the repository with common
> DNS resolver and name server platforms.
>
> Comment: IANA should publish such documentation 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 an authorised source, verify it is correctly formatted and verify
> it is consistent with what is published in the TLD zone before
> publishing it. There should also be a secure channel for
> authenticating the repository and any data it is publishing.
>
> Comment: Using the same channels IANA uses to process update requests
> to the root zone from TLDs should be 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 a published 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 support for this repository known publicly or
> within ICANN.
>
> Kind Regards
>
> RIPE DNS WG
> Jim Reid
> Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/dns-wg/attachments/20080430/69672e3c/attachment.html>