[dns-wg] Interim Trust Anchor Repository

Dear colleagues,

Last year, this working group wrote to ICANN requesting it implement a
trust-anchor repository for top-level domains which deploy DNSSEC. After a
couple of months of quiet usage by some of you since the RIPE meeting in
Dubai, today we are announcing it publicly.

It is available at https://itar.iana.org/

We of course are very interested in feedback and evolving the service,
implementing any operational experience we gain into future procedures for
key management in the trust anchor repository and the root zone itself.

In its letter, the working group enumerated a number of requirements which I
believe we have addressed in the implementation:

1) The service should be technology neutral, supporting different flavours
of trust anchors: The trust anchor repository supports different algorithms
and digest types, and doesn't seek to unnecessarily prohibit these. We'll
try and adopt any future types and methodologies as they are standardised.

2) The service should be operating system and DNS neutral: There is nothing
we are aware of that makes the trust anchor repository dependent on a
specific implementation. As some implementations don't accept DS records as
trust anchors, we have provided a tool to convert these to DNSKEY records.

3a) The service should verify keying material comes from an authorised
source: We verify all listing requests with the same contacts we use to
verify root zone changes.

3b) The trust anchors should be correctly formatted and consistent with the
TLD zone. We compute the DS record from the DNSKEY records in the child
zone, and ensure it matches before a listing request will succeed.

4) A process is needed to revoke a trust anchor: We have a revocation
process, and we have set up a mailing list to send key revocation
notifications to. Clearly, revoked keys will be removed from the machine
readable formats immediately after they are verified.

5) It should be clear what support is available: ICANN is providing this as
a clearly marked experimental service, with a limited lifespan. Hopefully
events will overtake it and we'll have a signed root zone before we consider
it leaving the experimental state.

6) It should have a clear exit strategy: ICANN has made it clear this is an
interim service (hence the name "ITAR"), and that we will be decommissioning
it after an appropriate time once the root zone is signed.

7) The respective manager must consent to list keying material: It is a
requirement they consent before we list keys. We will not list keys without
their explicit consent, even if we know they exist through other means.

Thanks!

Kim Davies
Internet Assigned Numbers Authority