DNSSEC Trust Anchor History Service

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

Abstract

When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. The service can be made to withstand multiple key compromises and large-scale spoofing.

Requirements Language

1. Introduction

2. Theory of Operation

3. Key History Resource Record Types
    3.1. The KEYHIST_LOC RRType
        3.1.1. Wire Format
        3.1.2. Presentation Format
    3.2. The KEYHIST_CHAIN RRType
        3.2.1. Wire Format
        3.2.2. Presentation Format
    3.3. The KEYHIST_SIG RRType

4. Processing
    4.1. Rollover of Stale Trust Anchors
    4.2. Validator Check of History Node

5. Signer Considerations

6. Example

7. Priming Keys

8. Security Considerations

9. IANA Considerations

10. Normative References

1. Introduction

When DNS validators have trusted keys, but have been offline for a longer period, trusted key rollover will fail. A method is presented to establish trust in current DNSKEYs. The method requires new RR types to hold the historical information, and requires implementation of the algorithm by the zone signer and validator. Zone operators and validators can deploy the method independently and incrementally.

The stale trust anchor rollover is vulnerable to a single key compromise coupled with a server take-over. A more secure rollover method can be selected by the zone owner. This more secure priming (with the prime bit set) rollover is described in Section 7 (Priming Keys). The priming rollover method can resist N-1 key compromises, with N the number of keys in the trusted priming key set held by the validator.

For priming keys, which are retrieved using many small queries, key size is limited by the size that will fit in one packet. The number of keys can be up to 255. A zone operator can choose the keysize and number of keys.

2. Theory of Operation

The basic mode of operation for the trust anchor history is to present a playback of historical states of the DNSKEY RRSet to the validator. The validator can then roll-forward the trust anchor using its trust anchor rollover algorithm. It is assumed [draft-timers] is used to rollover, however, if it fails with stale trust anchors the mechanism from this draft can be used to freshen the trust anchors. If the prime bit is used, as described later, [draft-timers] does not have to be in use.

The validator that requests history replay starts by requesting the DNSKEY RRSet as is currently present for the trust point. The validator then requests the previous RRSet, which comes signed and dated with a timestamp. The validator continues to request previous RRSets until it finds one that is signed by a key it trusts, or the server indicates no more are available. The validator can then reconstruct the key rollover from the past timepoints to the current keyset at the trust point.

The validator does not have to cache all of the zone history, it can use queries to walk forwards and backwards through the list of keysets.

To be able to request and serve historical DNSKEY RRSets, new RR Types are added, KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG.

The KEYHIST_LOC RR is used to locate the historical information. The historical information can be spread out over a number of domains, so that packet size can stay small. The validator queries each of these domains, and assembles the final set of DNSKEY, KEYHIST_SIG and KEYHIST_CHAIN RRs together. In this way the zone operator can use very large key sizes, while keeping packets within acceptable limits.

The DNSKEY RRs hold the keys. The KEYHIST_CHAIN RR holds hashes of DNSKEY RRsets, and is signed. It securely links together the historical information.

The KEYHIST_SIG RR is the same format as an RRSIG, but the signature is historical. The signature it holds can be expired, but valid in the past. It is used to sign the DNSKEY and KEYHIST_CHAIN types. The time at which the KEYHIST_SIGs are valid is stored in the KEYHIST_CHAIN type.

3. Key History Resource Record Types

3.1. The KEYHIST_LOC RRType

The KEYHIST_LOC RR type has type code (TBD) (decimal). It is class independent. History RR types pertaining to DNSKEYs MUST be of the same class as those DNSKEYs.

This RR Type is used to find the historical information that is stored in the DNS. It is signed with the regular zone signing key(s).

3.1.1. Wire Format

If the N or P flag (Bit 0, 1) is set, then the Next or Previous moment field is not present. Other flag fields MUST be set to zero, validators MUST ignore KEYHIST_LOC RRs with these flags set. Bit 7 (I) is the prime flag, denoting that the validator needs to have a priming key set to use this set of history data. The more history storage dname is always present. At this domain another KEYHIST_LOC is present, forming a cyclic linked list. All domain names are stored in uncompressed format.

3.1.2. Presentation Format

3.2. The KEYHIST_CHAIN RRType

The KEYHIST_CHAIN RR type has type code (TBD) (decimal). It is class independent.

This RR Type is used to sign hashes of historical DNSKEY RRsets. It MAY be signed with the regular zone signing keys as well, but MUST be signed with KEYHIST_SIG signatures by all keys in the DNSKEY RRset covered by this_hash. The DNSKEY keys and KEYHIST_SIG signatures are spread out over the list of domains from the KEYHIST_LOC type.

3.2.1. Wire Format

If bit 0 or 1 (Next or Previous omitted) is set, the previous hash or the next hash field is omitted. The this_hash field is always present. The hash length is in octets. The hashes use the same algorithm, and so have the same length, if they are present. The hash length depends on the hash algorithm. The MBZ flags MUST be set to zero. Validators MUST ignore RRs with these flags set. The I field, bit 7, is the priming keys flag, denoting that all keys MUST match the known trusted keys by the validator, for the validator to consider trusting this KEYHIST_CHAIN and ending rollover.

3.2.2. Presentation Format

3.3. The KEYHIST_SIG RRType

This RRtype has type code (TBD) (decimal). The presentation and wireformat of the rdata is the same as for the RRSIG type. It is used to sign the DNSKEY and KEYHIST_CHAIN types. It is different from RRSIG in that the signature may be expired, but was valid at the time in the timestamp from the KEYHIST_CHAIN.

Another difference with RRSIGs is that KEYHIST_SIG does not require special processing. It is queried for directly. KEYHIST_SIG signatures may be stored at a different node than the RRset they sign. The KEYHIST_LOC type provides the location of the historical RRsets and signatures.

Both historical DNSKEY and historical KEYHIST_CHAIN types require that the owner name be set to the zone apex name of the zone for which trust anchors are sought, before the KEYHIST_SIG signature is validated.

4. Processing

4.1. Rollover of Stale Trust Anchors

4.2. Validator Check of History Node

This section describes the checks needed to validate a history node. First the necessary information MUST be queried from the more data domains listed in the KEYHIST_LOC type. Also the owner name of the KEYHIST_LOC RR MUST be queried for historical data. Note that the last KEYHIST_LOC more_domain points back to the first, and all have the same priming flag, previous and next values.

The hashvalue of the DNSKEY RRset at this node, with the owner names replaced by the zone apex (of the zone that is rolled over) MUST match the this_hash value. The reason to replace the owner name before hashing is so that the history data may be moved after creation without needing the old key private data.

The hashvalues prev_hash and next_hash MUST also be correct. The next_hash value MUST be NULL if the KEYHIST_LOC has been retrieved from the rollover zone apex domain name. The prev_hash value is only NULL if no more history is available. The prev_hash value MUST be equal to the hash of the DNSKEY RRset from the previous history node. The next_hash value MUST be equal to the hash of the DNSKEY RRset from the next history node.

Since the validator algorithm specifies to walk the history from new to old, the hash checking is as follows. The this_hash is checked for the current node. The last seen node's prev_hash value MUST equal the hash of the DNSKEYs found in the current node. The next_hash value for this node MUST equal the hash of the DNSKEYs from the last seen node.

The KEYHIST_SIG, RRSIG, DNSKEY and KEYHIST_CHAIN RRs can have different algorithm values for signatures and hashing. This allows the zone operator to switch algorithms. To check a hash in a KEYHIST_CHAIN the hash algorithm from that RR is used.

The number of DNSKEYs in the KEYHIST_CHAIN, and the key ids in the KEYHIST_CHAIN MUST be correct. With many keys, an 16 bit ids, it is likely to have keys with the same id, that id is then listed multiple times in the KEYHIST_CHAIN.

The KEYHIST_SIG over the KEYHIST_CHAIN MUST validate. Validation is performed at the time from the timestamp in the KEYHIST_CHAIN. All keys in the DNSKEY RRset MUST sign the KEYHIST_CHAIN in this way. This signs the timestamp, and hashes of the current, previous and next DNSKEY RRsets.

The KEYHIST_SIG over the DNSKEY MUST validate. Validation is performed at the time from the timestamp in the KEYHIST_CHAIN. All keys in the DNSKEY RRset MUST sign the DNSKEY RRset in this way.

Keys MUST NOT be used for signatures over the DNSKEY set and the KEYHIST_CHAIN RR, using KEYHIST_SIG entries in the history chain, when they have previously been revoked. Keys are revoked via a self-signed revocation signature. The revocation flag in DNSKEY is discussed in [draft-timers]. To check that this does not happen, the validator MUST keep track of the keys that have been used to sign keysets in the future, which means it has seen them already since it queries from future to past. If a revocation of a key is seen which is also used for signatures at a future moment, then the rollover fails.

5. Signer Considerations

The zone, or a signed subzone, is used to store history snapshots. New snapshots are added to the history whenever the key-signing keyset for the zone changes. The operator MAY opt to make snapshots at different times, but these snapshots MUST allow for orderly rollover by a validator. So the operator can omit intermediate or emergency recovery zone states from the history list. A change of ZSK keys does not trigger a new history snapshot, because the KSKs sign the new ZSK.

The zone operator is to provide a key history to the server, produced by a signer. The RR formats are such that private key data for old keys can be discarded, only the current and the previous set of keys are needed. The data can be treated as unknown RR types by servers, caches and intermediate resolvers. The zone operator may opt to move the history data after it has been created, since it is not the location but content that verifies the keys. The data may be moved without needing private key data, since the KEYHIST_LOC type is signed using the current zone signing keys. Also, the owner name of DNSKEY and KEYHIST_CHAIN types is changed to the rollover zone apex name before hashing or verifying signatures. The zone operator may move history service to a signed subzone of the zone, to move key history query load to other authoritative servers. The history store is stored at domain names chosen by the operator, for example numbered sequentially, or by date. The data may be divided onto many domains to make packet sizes smaller. The signer SHOULD provide an option to set a maximum history reply size that is acceptable so that it can divide the data over multiple domains as needed. The signer produces normal zone signing RRSIGs as well as KEYHIST_SIGs as needed for historical data storage points.

6. Example

To illustrate the use of history, an example zone is listed below. The zone name is example.com. and it has several history points.

; example.com. zone apex
example.com. SOA ns.example.com. hostmaster.example.com. (
    2007100701 7200 3600 604800 86400)
example.com. RRSIG SOA by ZSK;
example.com. NS ns.example.com.
example.com. RRSIG NS by ZSK;
example.com. DNSKEY ZSK; id=1
example.com. DNSKEY KSK; id=101
example.com. DNSKEY KSK; id=102
example.com. RRSIG DNSKEY by ZSK;
example.com. RRSIG DNSKEY by KSK 101;
example.com. RRSIG DNSKEY by KSK 102;
; this RR provides location of more history information.
example.com. KEYHIST_LOC 128 (
    hist200709.example.com. hist200710.example.com. )
example.com. RRSIG KEYHIST_LOC by ZSK;

; the nameserver address
ns.example.com. A 192.0.2.10
; zone content.
www.example.com. AAAA 2001:DB8::10

; more history information for the zone apex (current keyset).
; The KEYHIST_LOC RR completes the more information chain
; for the zone apex by pointing back to the apex.
hist200710.example.com. KEYHIST_LOC 128 (
    hist200709.example.com. example.com. )
hist200710.example.com. RRSIG KEYHIST_LOC by ZSK;
; The KEYCHAIN RR, the hash_ words would be actual hexadecimal
; data in practice. Lists the current KSKs: 101 and 102.
hist200710.example.com. KEYHIST_CHAIN 128 5 20 2 (
    hash_prev_hex hash_101_102_hex 20071007000000 101 102 )
; Signatures valid at the snapshot time above.
hist200710.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 101;
hist200710.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 102;
; signatures over the DNSKEY set comprised of key 101 and 102.
hist200710.example.com. KEYHIST_SIG DNSKEY by key 101;
hist200710.example.com. KEYHIST_SIG DNSKEY by key 102;
; these signatures sign the KEYHIST_LOC and _CHAIN with
; ZSK to be backward compatible with software that does
; DNSSEC but not keyhistory. the server can continue to
; treat KEYHIST_ types as unknown RR types. These signatures
; are not needed during a historical key update.
hist200710.example.com. RRSIG KEYHIST_CHAIN by ZSK
hist200710.example.com. RRSIG KEYHIST_SIG by ZSK

; previous history moment. The operator has instructed the
; zone signer to divide this up into two domain names.
; One with the public key data, one with the _CHAIN data.
; The KEYHIST_* RRs can be distributed in any way; even splitting
; apart the KEYHIST_SIG and DNSKEY RRsets.
hist200709.example.com. KEYHIST_LOC 0 (
    hist200708.example.com. hist200910.example.com.
    hist200709_2.example.com.)
hist200709.example.com. RRSIG KEYHIST_LOC by ZSK;
hist200709.example.com. DNSKEY KSK; id = 102
hist200709.example.com. DNSKEY KSK; id = 103
hist200709.example.com. KEYHIST_SIG DNSKEY by key 102;
hist200709.example.com. KEYHIST_SIG DNSKEY by key 103;
; backwards compatibility RRSIGs.
hist200708.example.com. RRSIG DNSKEY by ZSK
hist200709.example.com. RRSIG KEYHIST_SIG by ZSK

; more data for 200709.
hist200709_2.example.com. KEYHIST_LOC 0 (
    hist200708.example.com. hist200910.example.com.
    hist200709.example.com.)
hist200709_2.example.com. RRSIG KEYHIST_LOC by ZSK
hist200709_2.example.com. KEYHIST_CHAIN 0 5 20 2 (
    hash_prev_hex hash_102_103_hex hash_next_hex
    20070907000000 102 103 )
; Signatures valid at the snapshot time above.
hist200709_2.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 102;
hist200709_2.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 103;
; backwards compatibility RRSIGs.
hist200709_2.example.com. RRSIG KEYHIST_SIG by ZSK
hist200709_2.example.com. RRSIG KEYHIST_CHAIN by ZSK

; 200708 is the oldest moment in the example history chain.
; the operator had the information put on one domain name
hist200708.example.com. KEYHIST_LOC 64 (
    host200709.example.com. hist200708.example.com. )
hist200708.example.com. RRSIG KEYHIST_LOC by ZSK
hist200708.example.com. KEYHIST_CHAIN 64 5 20 2 (
    hash_103_104_hex hash_next_hex
    20070807000000 103 104 )
hist200708.example.com. DNSKEY KSK; id = 103
hist200708.example.com. DNSKEY KSK; id = 104
hist200708.example.com. KEYHIST_SIG DNSKEY by key 103;
hist200708.example.com. KEYHIST_SIG DNSKEY by key 104;
hist200708.example.com. KEYHIST_SIG KEYHIST_CHAIN by key 103;
hist200708.example.com. KEYHIST_SIG KEYHIST_CHAIN by key 104;
; backwards compatibility RRSIGs. These are not required for
; history rollover
hist200708.example.com. RRSIG DNSKEY by ZSK
hist200708.example.com. RRSIG KEYHIST_SIG by ZSK
hist200708.example.com. RRSIG KEYHIST_CHAIN by ZSK

The above zone would also need NSEC denial of existance information, not shown in the example. The zone has three history moments, 200710 (that is linked from the zone apex and contains the current keys), 200709 and 200708. The KSK keys have been rolled from 104,103 to 103,102 to 102,101 at the current time.

The zone operator can choose to leave out some zone changes from the history list. For example, if during change from keys 104,103 to 103,102 the zone briefly becomes signed only with key 103, this state can be left out without affecting the draft-timers based key rollover.

The zone operator may also insert extra history moments when the valid zone keys do not change. This may not seem very useful, but emergency key revocations can be inserted in this way, without waiting for key rollover.

If an attacker compromises key 103, then this key is not in current use, and cannot directly be used to sign data (draft-timers will have removed the key from usage, and priming keys do not have ZSK bit set in the validator). However, if a validator that trusts key 103 (and has no more recent key) tries to perform history rollover, key 103 can be used to subvert rollover and insert a new key of attackers choice. A single key compromise breaks security in this case.

For this reason the priming bit can be set. If in the above example the prime bit were set, then the validator armed with both keys 103 and 104 (a full keyset from 200708), is not subverted using only key 103. If both keys 103 and 104 are compromised, then again, rollover can be subverted. When the prime bit is set, compromise of all keys breaks security.

When the zone operator learns of the compromise of key 103, he will want to retract that key. He has discarded old private key information, including that for key 103, but has kept a self-signed keyset of key 103 with the REVOKE key flag. The operator can insert the key 103 revocation DNSKEY and RRSIG in the zone. This change of KSKs creates a new history moment, where keys 101 and 102 sign everything and key 103 only its revocation. In this way key revocations are also historically archived, so that later validators that perform history rollover will encounter them.

The RRSIG over key 103 revocation has timestamps in the past. For this reason, the signature can be stored in a KEYHIST_SIG RR type. The outdated timestamps can be ignored; because a key revocation at any time results in a revoked key. By including key 103 and its KEYHIST_SIG not in the zone apex itself, but only in hist200710.example.com, the key revocation can be included in the history information for the zone apex without affecting older validators; specifically since it is not part of the zone apex DNSKEY keyset, it does not have to sign the zone apex DNSKEY keyset, which the operator cannot do because the private key data for key 103 has been discarded.

7. Priming Keys

Because the stale trust anchor rollover presented before can be broken by an attacker obtaining the key material for one of the trust keys, a more secure method is presented here. The zone owner can opt to provide priming keys. These keys MUST NOT be kept up to date using frequent polls. A validator only needs to rollover priming keys when this becomes necessary.

Priming key sets MUST be stored by the validator with all keys from the set. All the priming keys from that set MUST be used whenever the set is used to sign or validate. The priming bit in the flags field of KEYHIST_LOC and KEYHIST_CHAIN RRs found MUST be set, when validating a priming key rollover.

The method for rollover is the same. However, rollover does not stop when one trust key is detected, but when the set of DNSKEYs equals a complete set of priming keys that the validator trusts, and all signatures validate.

The effect is that instead of one trust anchor key, all priming keys provide protection. Since no rollover algorithm intermediate states are retrieved, the keys found in step 1 are set as trusted keys without performing the rollover algorithm and the updated set of priming keys is stored for later use, preferably on stable storage as well.

Priming keys MUST have the SEP bit set, but SHOULD NOT have the ZSK bit set. This makes priming keys unable to sign ordinary zone data. It reduces the possible abuse of the priming keys.

The validator SHOULD update its keys if they are one year old, or older. This reduces the chance that validators are stuck with ancient keys when rollover fails. One year is suggested as default value. The validator MUST randomly determine ancient key update time so that the first updates start after a year, and one year later all clients have updated. This avoids congestion when all clients update ancient keys at the same time. If the priming keys are updated in another manner in the meantime (e.g. using software update), then a new update time has to be determined.

8. Security Considerations

If the attacker does not crack current keys, or spoof the initial queries, the trust roll over will end at the current SEP keys.

The situation where the attacker cracks current keys is not considered further. There is no security using key history service in that case.

Assuming the attacker spoofs the initial queries, in addition the attacker needs to have obtained the trusted keys that the validator possesses. An additional obstacle presented to the attacker by history service is that validators with stale trust anchors are not distinguishable from validators with valid ones, when they query for the current zone DNSKEY RRset. And further, the validator does not reveal which trust anchor it is holding until it stops the query process. An attacker needs other information (such as IP addresses) to identify victims. Or the attacker provides false information to validators with correct trust anchors. Those validators will flag the information as bogus, and attract attention from the zone operator, revealing the attack attempt.

In the case that the attacker has obtained the old trust anchor, can spoof all of the queries, and is able to identify the victim or willing to reveal the attack in progress, then the algorithm for stale trust anchor rollover fails to be secure.

If operators feel that their zone needs additional security against this threat, they can use the priming keys option, described in Section 7 (Priming Keys). A validator can download a set of priming keys using a valid trust anchor at any time, or get them via software updates. The priming keys can be very large, and a large number. Priming keys are only rolled over when trust anchors go stale. Priming keys are always obtained in a full set and they MUST all verify the RRsets together. This means an attacker needs to obtain the key material for all of the priming keys, and spoof queries as for the above case, to be able to subvert the rollover.

The validator can follow a signed delegation to a subzone to get history information. The signature uses the untrusted current zone keys. A spoofing attacker can redirect a validator in this way. However, this simply amounts to more spoofing by the attacker. The signatures and DS are validated to raise the bar on spoofing the delegation.

The stale trust anchor rollover performs rollover of the trust anchor according to [draft-timers]. However, the final state is then under a hold-down timer of 30 days. This means no trust anchors may be used for 30 days, which is not attractive for people who have been offline for a long time (and need their software security updates from a secure site). The KEYHIST_CHAIN self-signed timestamps MAY be used to determine if the hold-down period has passed for some of the keys from the final keyset, but this fails to provide real timing security.

The priming keys algorithm does not use time periods, and the final keyset is trusted immediately.

None of the historical key private material needs to be online for a server to provide history service. They are only needed by the signer, when the key is rolled over. Private key material may be discarded for old keys.

Because the validator walks the history in reverse first, it will see all revoked keys with the revocation bit on first. The validator MUST NOT trust such keys for present-day validation. A validator may choose to remove all stale trust anchors when the priming rollover completes, removing the need for revocation determination.

Keys that have been revoked can be used to self-sign keysets at time moments before their revocation. The older entries are unchanged, partly to make it possible to discard old key private data. And partly because the validator can handle these cases. Since the validator walks the history backwards, it sees revocations first, and can ignore signatures from revoked keys on older keysets in the history chain. If all keys that a validator trusts are revoked, then, although rollover fails, the validator has gained the revocation knowledge and will not put false trust in these keys.

The KEYHIST_CHAIN requires second preimage resistance of the hash function. The rollover after a year should make sure where possible that keys with very old algorithms signed with KEYHIST_CHAIN RRs with very old hash algorithms are not in use by clients.

The algorithm can be abused to provide a secure method to get (close to) the current month or year. Validators without clock then know the date that validates DNSKEY RRSIGs currently in use by the zone.

9. IANA Considerations

10. Normative References

Author's Address

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

[RFC1982]	Elz, R. and R. Bush, “Serial Number Arithmetic,” RFC 1982, August 1996 (TXT).
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4034]	Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).

	Wouter Wijngaards
	NLnet Labs
	Kruislaan 419
	Amsterdam 1098 VA
	The Netherlands
Phone:	+31-20-888-4551
Fax:	+31-20-888-4462
EMail:	wouter@nlnetlabs.nl

DNSSEC Trust Anchor History Service
draft-wijngaards-dnsext-trust-history-01

Status of This Memo

Abstract

Requirements Language

Table of Contents

1. Introduction

2. Theory of Operation

3. Key History Resource Record Types

3.1. The KEYHIST_LOC RRType

3.1.1. Wire Format

3.1.2. Presentation Format

3.2. The KEYHIST_CHAIN RRType

3.2.1. Wire Format

3.2.2. Presentation Format

3.3. The KEYHIST_SIG RRType

4. Processing

4.1. Rollover of Stale Trust Anchors

4.2. Validator Check of History Node

5. Signer Considerations

6. Example

7. Priming Keys

8. Security Considerations

9. IANA Considerations

10. Normative References

Author's Address

Full Copyright Statement

Intellectual Property

DNSSEC Trust Anchor History Servicedraft-wijngaards-dnsext-trust-history-01

Status of This Memo

Abstract

Requirements Language

Table of Contents

1. Introduction

2. Theory of Operation

3. Key History Resource Record Types

3.1. The KEYHIST_LOC RRType

3.1.1. Wire Format

3.1.2. Presentation Format

3.2. The KEYHIST_CHAIN RRType

3.2.1. Wire Format

3.2.2. Presentation Format

3.3. The KEYHIST_SIG RRType

4. Processing

4.1. Rollover of Stale Trust Anchors

4.2. Validator Check of History Node

5. Signer Considerations

6. Example

7. Priming Keys

8. Security Considerations

9. IANA Considerations

10. Normative References

Author's Address

Full Copyright Statement

Intellectual Property

DNSSEC Trust Anchor History Service
draft-wijngaards-dnsext-trust-history-01