One document matched: draft-wijngaards-dnsext-trust-history-00.txt
DNS Extensions Working Group W. Wijngaards
Internet-Draft NLnet Labs
Intended status: Standards Track March 2007
Expires: September 2, 2007
DNSSEC Trust Anchor History Service
draft-wijngaards-dnsext-trust-history-00
Status of This Memo
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Wijngaards Expires September 2, 2007 [Page 1]
Internet-Draft Trust History Service March 2007
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3
3. Key History Resource Record Types . . . . . . . . . . . . . . 4
3.1. The KEYHIST_LOC RRType . . . . . . . . . . . . . . . . . . 4
3.1.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Presentation Format . . . . . . . . . . . . . . . . . 5
3.2. The KEYHIST_CHAIN RRType . . . . . . . . . . . . . . . . . 5
3.2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Presentation Format . . . . . . . . . . . . . . . . . 6
3.3. The KEYHIST_SIG RRType . . . . . . . . . . . . . . . . . . 7
4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Rollover of Stale Trust Anchors . . . . . . . . . . . . . 7
4.2. Validator Check of History Node . . . . . . . . . . . . . 8
5. Signer Considerations . . . . . . . . . . . . . . . . . . . . 9
6. Priming Keys . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Wijngaards Expires September 2, 2007 [Page 2]
Internet-Draft Trust History Service March 2007
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 6. 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.
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
Wijngaards Expires September 2, 2007 [Page 3]
Internet-Draft Trust History Service March 2007
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
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|P|MBZ flags|I| Previous moment (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next moment (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ more history storage (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Wijngaards Expires September 2, 2007 [Page 4]
Internet-Draft Trust History Service March 2007
stored in uncompressed format.
3.1.2. Presentation Format
<owner> <ttl> <class> KEYHIST_LOC <flags> <prev_domain>
<next_domain> <more_domain>
flags: unsigned integer octet representing flags. Bit 0 means 'no
next record'. Bit 1 means 'no previous record'. Bit 7 means
'priming keys'.
prev_domain: The domain name where a KEYHIST_LOC older than this set
of information can be found. Stored as an uncompressed domain
name. Not presented if the 'no previous record' flag is set.
next_domain: The domain name where a KEYHIST_LOC newer than this
information can be found. Stored as an uncompressed domain name.
Not presented if the 'no next record' flag is set.
more_domain: A domain name where another KEYHIST_LOC is present.
And also more historical data is present at that point. The
KEYHIST_LOCs form a cyclic linked list with the more_domains
pointing to another. The prev and next moment of all the
KEYHIST_LOCs in the same more_domain list are all the same. This
is where the historical information can be found. At these
domains the RR Types KEYHIST_CHAIN, KEYHIST_SIG and DNSKEY can be
found. Stored as uncompressed domain name.
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 is
spread out over the list of domains from the KEYHIST_LOC type.
3.2.1. Wire Format
Wijngaards Expires September 2, 2007 [Page 5]
Internet-Draft Trust History Service March 2007
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|P|MBZ Flags|I| Hash algo. | Hash length | number of keys|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous hash data octets /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| This hash data octects /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next hash data octets /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | first key_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key_id ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
<owner> <ttl> <class> KEYHIST_CHAIN <flags> <algo>
<hash_length> <num_keys> <prev_hash> <this_hash>
<next_hash> <timestamp> <key_ids>...
flags: Presented as unsigned integer. Bit 7 means 'priming keys'.
Bits 0 and 1 are set if there are no next or previous historical
rrsets. The hashes are then ommitted from presentation.
algo: Hash algorithm used. Unsigned integer presentation format,
one octet. Same list of values as the DS record.
hash_length: This field is presented as an unsigned integer.
num_keys: The number of DNSKEYs in the DNSKEY RRset covered by
this_hash. Unsigned integer, one octet.
prev_hash: The hashes are presented by a sequence of hexadecimal
characters. The field is ommitted if not present. The prev_hash
is the hash algorithm applied to the DNSKEY RRset before this one,
the owner names of the DNSKEY RRset are set to the zone apex when
taking the hash and signatures (exactly as the DNSKEY RRset was
when it was in use). If there is no previous DNSKEY RRset it is
not present.
Wijngaards Expires September 2, 2007 [Page 6]
Internet-Draft Trust History Service March 2007
this_hash: Encoded like prev_hash. Hash over the DNSKEY RRset as
found when querying all data_domains from the KEYHIST_LOC RR,
taken together, with owner name equal to the zone apex.
next_hash: Encoded like prev_hash. Hash over the next DNSKEY RRset.
If there is no next DNSKEY RRset, it is not present.
timestamp: The timestamp is presented the same as the RRSIG
timestamps. Either as an unsigned decimal integer indicating
seconds since 1 January 1970 00:00:00 UTC, or in the form
YYYYMMDDHHmmSS in UTC [RFC4034]. This is the time at which this
DNSKEY RRset is valid. The KEYHIST_SIGs over the DNSKEY and
KEYHIST_CHAIN RRsets MUST be valid at this time.
key_ids: The Key ID of every DNSKEY RR key is given, in ascending
order as unsigned 16-bit numbers. If there are keys in the RRset
with the same ID, that ID is stated twice. This is the same ID as
stored in RRSIGs. These ids are present to assist validator
lookups, so that the validator can check number and IDs of keys
that were fetched before attempting validation.
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
1. The first step is a query that looks exactly like a regular
rollover query. This query is for the zone DNSKEY RRset. It
MUST be exactly like a regular rollover, so that an attacker
finds it hard to distinguish clients with stale keys from regular
clients. The results from this query MUST be stored. The
rollover algorithm MUST end up at this DNSKEY RRset. If any or
all of these checks fail the rollover fails.
Wijngaards Expires September 2, 2007 [Page 7]
Internet-Draft Trust History Service March 2007
2. The validator then looks for history service. Query for
KEYHIST_LOC at the zone apex. If no history is available, the
rollover fails. If history is available, the KEYHIST_LOC type
will point to the data domains where the KEYHIST_CHAIN, DNSKEY
and KEYHIST_SIG RRs for the DNSKEY rrset that is currently in use
can be found. The validator MUST fetch these. The DNSKEYs found
MUST equal the SEP keys from the set found in step 1.
3. The validator checks the gathered types, as described in
Section 4.2. If checks fail, the rollover fails.
4. The validator fetches the KEYHIST_LOC type from the domain name
listed in the prev_domain field. This can lead to a subzone of
the original zone. In that case the delegation MUST be signed
(with valid DS) by the keys from step 1. This KEYHIST_LOC type
MUST be signed by one of the zone keys from step 1.
5. Fetch the history RRs from the data domains. Check them as
described in Section 4.2.
6. If this RRset contains trusted keys, then the rollover is done.
The trust anchor state can be brought into correct state by
performing key rollover at the timepoints from KEYHIST_CHAIN.
This rollover MUST end in the keyset from step 1.
7. Because of DNS timing issues, the trust keys held by a validator
may not be exactly one DNSKEY RRset from the history. In that
case some of the trusted keys can be found in older DNSKEY
RRsets.
8. The validator continues to an older DNSKEY RRset, go to step 4.
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.
Wijngaards Expires September 2, 2007 [Page 8]
Internet-Draft Trust History Service March 2007
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 number of DNSKEYs in the KEYHIST_CHAIN, and the key ids in the
KEYHIST_CHAIN MUST be correct.
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, 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.
The timestamp MUST be smaller (using serial arithmatic [RFC1982])
than the timestamp from the last seen newer node.
5. Signer Considerations
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
Wijngaards Expires September 2, 2007 [Page 9]
Internet-Draft Trust History Service March 2007
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. 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. That is what [draft-timers] is for. A
validator only needs to rollover priming keys when the trust anchors
go stale.
Priming key RRsets MUST be kept as a whole RRset. All the priming
keys 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
the 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 trust anchor intermediate states are
retrieved, the keys found in step 1 are set as trusted keys without
performing the rollover algorithm and possibly an updated set of
priming keys is stored for later use.
7. 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
Wijngaards Expires September 2, 2007 [Page 10]
Internet-Draft Trust History Service March 2007
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 6. 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, which has larger keysizes or
more keys, also defeats the hold-down period for the final keyset, as
it 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.
Wijngaards Expires September 2, 2007 [Page 11]
Internet-Draft Trust History Service March 2007
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. If the priming
keys method is used, a validator may opt to walk the non-priming key
history service to determine which keys have been revoked, or simply
choose to remove all stale trust anchors when the priming rollover
completes.
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 these keys.
The KEYHIST_CHAIN requires second preimage resistance of the hash
function. But if that property is lost, RRSIGs on the current zone
are broken as well.
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.
8. IANA Considerations
New Resource Record type codes for KEYHIST_LOC, KEYHIST_CHAIN and
KEYHIST_SIG.
9. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
Wijngaards Expires September 2, 2007 [Page 12]
Internet-Draft Trust History Service March 2007
Author's Address
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
Wijngaards Expires September 2, 2007 [Page 13]
Internet-Draft Trust History Service March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wijngaards Expires September 2, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 04:58:15 |