Validation of the root trust anchor for the DNS

In deployment of DNSSEC, the root zone will have one or more Key Signing Keys (KSK) each having a private and public part. The public part is to be used for verification of the trust chain and because of that distributed to and trusted by every resolver that want to verify DNSSEC signed responses. As the distribution of the public part of the KSK is made using electronic communication mechanisms, and replaced frequently, it is important that the distribution made in a way so that the integrity of the KSK can be verified. The simplest way to manage this is to sign the public part of the KSK, and have the digital signature of the KSK, and therefore the public part of the key that signs the KSK, be what is trusted by the resolver. To be able to handle changes in the KSK in an automated fashion, while at the same time allow external organisations to audit the KSK management, and give the ability for parties that is to trust the KSK to automatically do so, it is proposed to have a recommended way of managing this distribution of the public part of the KSK. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Key Signing Key Zone Signing Key Trust Anchor Repository An entity signing the TAR An entity using the contents of the TAR as DNSSEC trust anchors, possibly based on the signatures created by the TAR signees.

It is proposed that the public key signing keys (KSKs) for the root zone are distributed in the form of a trust anchor repository (TAR) signed by multiple parties. To be able to put trust in the KSKs, and therefore in the root zone signing process, the TAR signees should be able to audit the root signing policies and procedures. The signing mechanisms should be such that the TAR can be signed by more than one entity. It should be possible to for each signee to sign the TAR separately form other signees. After the entities have signed the TAR, it is to be distributed. In some cases by the entities that sign it, in other cases by third parties. It is up to the TAR distributor to bundle the TAR with the signatures made by the TAR signees. A TAR distributor might choose to not include all signatures in the distribution. Someone that receive such a signed TAR can verify the signatures and that way ensure two things - that the contents of the TAR has not changed during transmission and that the current process used for managing the keys that forms the TAR is trusted by the TAR signee. It is suggested that the lifetime of the signatures on the TAR is potentially shorter than the administrative lifetime of the TAR contents (e.g. keys and fingerprints). This enables the ability for the signee to do the audit of the root signing policies and procedures repeatedly over time. If the consumer of the TAR cannot validate enough signatures, it is recommended that the contents of the TAR should not be used to configure the validating DNSSEC resolver.

The signees may sign the TAR using a detached signature created using either OpenPGP or S/MIME.

This document does not require any IANA actions.

DNSSEC adds data origin authentication and data integrity to the DNS. Because of this, DNSSEC is almost certainly necessary for any application mechanism that stores authorization data in the DNS. If the signature(s) on the TAR does not validate, the content of the TAR is not to be used for configuration of the DNSSEC verifying resolver. This might lead to the resolver ignoring all DNSSEC signed data that can not be verified using a trust chain to some other trust anchor, and because of this it might lead to it not returning any responses to queries that reaches it. A signature on the TAR that is not renewed might because of this lead to DNS resolution not work (from the client perspective). Local policy in the resolver is to be carefully tuned to take care of these situations. The mechanisms described in this document does not introduce any new security implications than what traditionally is the case for detached signatures for PGP and/or S/MIME.

The authors gratefully acknowledges, in no particular order, the contributions of the following persons: Patrik Wallstrom