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
