draft-ietf-dnsext-parent-stores-zone-keys-00.txt   draft-ietf-dnsext-parent-stores-zone-keys-01.txt 
INTERNET-DRAFT R. Gieben INTERNET-DRAFT R. Gieben
DNSEXT Working Group NLnet Labs DNSEXT Working Group NLnet Labs
Expires September 2001 T. Lindgreen Expires September 2001 T. Lindgreen
NLnet Labs NLnet Labs
Parent stores the child's zone KEYs Parent stores the child's zone KEYs
draft-ietf-dnsext-parent-stores-zone-keys-00.txt draft-ietf-dnsext-parent-stores-zone-keys-01.txt
Status of This Document Status of This Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at line 30 skipping to change at page 10, line ?
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of http://www.ietf.org/ietf/1id-abstracts.txt. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSEXT WG mailing Comments should be sent to the authors or the DNSEXT WG mailing
list namedroppers@ops.ietf.org. list namedroppers@ops.ietf.org.
This document updates RFC 2535 [2]. This document updates RFC 2535.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved. Copyright (C) The Internet Society (2001). All rights reserved.
Abstract Abstract
When dealing with large amounts of keys the procedures to update a When dealing with large amounts of keys the procedures to update a
zone and to sign a zone need to be clearly defined and practically zone and to sign a zone need to be clearly defined and practically
possible. The current idea is to have the zone KEY RR and the possible. The current idea is to have the zone KEY RR and the
skipping to change at line 61 skipping to change at page 10, line ?
Besides the operational advantages, this also obsoletes the NULL key, Besides the operational advantages, this also obsoletes the NULL key,
as the absence of child's zone KEY, which is securely verified by the as the absence of child's zone KEY, which is securely verified by the
absence of the KEY-bit in the corresponding NXT RR, now unambiguously absence of the KEY-bit in the corresponding NXT RR, now unambiguously
indicates that the child is not secured by this parent. indicates that the child is not secured by this parent.
We further discuss the impact on a secure aware resolver/forwarder We further discuss the impact on a secure aware resolver/forwarder
and the impact on the authority of KEYs and the NXT record. and the impact on the authority of KEYs and the NXT record.
Table of Contents Table of Contents
Status of This Document....................................2 Status of This Document....................................
Abstract...................................................2 Abstract...................................................
Table of Contents..........................................3 Table of Contents..........................................
1 Introduction.............................................3 1 Introduction.............................................
2 Proposal.................................................4 2 Proposal.................................................
2.1. TTL of the KEY and SIG at the parent..................4 2.1. TTL of the KEY and SIG at the parent..................
2.2. No NULL KEY...........................................5 2.2. No NULL KEY...........................................
3 Impact on a secure aware resolver/forwarder..............5 3 Impact on a secure aware resolver/forwarder..............
3.1 Impact of key rollovers on resolver/forwarder..........5 3.1 Impact of key rollovers on resolver/forwarder..........
4 Scheduled key rollover...................................6 4 Scheduled key rollover...................................
5 Unscheduled key rollover.................................6 5 Unscheduled key rollover.................................
6 Zone resigning...........................................7 6 Zone resigning...........................................
7. Consequences for KEY and NXT records....................7 7. Consequences for KEY and NXT records....................
7.1. KEY bit in NXT records................................7 7.1. KEY bit in NXT records................................
7.2. Authority of KEY records..............................8 7.2. Authority of KEY records..............................
7.3. Selecting KEY sets....................................8 7.3. Selecting KEY sets....................................
8. The zone-KEY and local KEY records......................8 8. The zone-KEY and local KEY records......................
9. Security Considerations.................................8 9. Security Considerations.................................
Authors' Addresses.........................................9 Authors' Addresses.........................................
References.................................................9 References.................................................
Full Copyright Statement...................................9 Full Copyright Statement...................................
1. Introduction 1. Introduction
Within a CENTR working group NLnet Labs is researching the impact of Within a CENTR working group NLnet Labs is researching the impact of
DNSSEC on the ccTLDs and gTLDs. DNSSEC on the ccTLDs and gTLDs.
In this document we are considering a secure zone, somewhere under a In this document we are considering a secure zone, somewhere under a
secure entry point and on-tree [1] validation between the secure secure entry point and on-tree [RFC 3090] validation between the
entry point and the zone in question. The resolver we are secure entry point and the zone in question. The resolver we are
considering is security aware and is preconfigured with the KEY of considering is security aware and is preconfigured with the KEY of
the secure entry point. We also make a distinction between a the secure entry point. We also make a distinction between a
scheduled and a unscheduled key rollover. A scheduled rollover is scheduled and a unscheduled key rollover. A scheduled rollover is
announced before hand. An unscheduled key rollover is needed when a announced before hand. An unscheduled key rollover is needed when a
private key is compromised. private key is compromised.
RFC 2535 [2] states that a zone KEY must be present in the apex of a RFC 2535 states that a zone KEY must be present in the apex of a
zone. This can be in the at the delegation point in the parent's zone. This can be in the at the delegation point in the parent's
zonefile, or in the child's zonefile, or in both. This key is only zonefile, or in the child's zonefile, or in both. This key is only
valid if it is signed by the parent, so there is also the question valid if it is signed by the parent, so there is also the question
where this signature and this zone KEY are located. where this signature and this zone KEY are located.
The original idea was to have the zone KEY RR and the parent's SIG to The original idea was to have the zone KEY RR and the parent's SIG to
reside in the child's zone and perhaps also in the parent's zone. reside in the child's zone and perhaps also in the parent's zone.
There is a draft proposal [3], that describes how a keyrollover can There is a draft proposal [RFC 2535], that describes how a
be handled. keyrollover can be handled.
At NLnet Labs we found that storing the parent's signature over the At NLnet Labs we found that storing the parent's signature over the
child's zone KEY in the child's zone: child's zone KEY in the child's zone:
- makes resigning a KEY by the parent difficult - makes resigning a KEY by the parent difficult
- makes a scheduled keyrollover very complicated - makes a scheduled keyrollover very complicated
- makes an unscheduled keyrollover virtually impossible - makes an unscheduled keyrollover virtually impossible
We propose an alternative scheme in which the parent's signature over We propose an alternative scheme in which the parent's signature over
the child's zone KEY and the child's zone KEY itself are only stored the child's zone KEY and the child's zone KEY itself are only stored
in the parent's zone, i.e. where the signing key resides. This would in the parent's zone, i.e. where the signing key resides. This would
solve the above problems and also obsoletes the NULL KEY. solve the above problems and also obsoletes the NULL KEY.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119.
2. Proposal 2. Proposal
The core of the new proposal is that the parent zone stores the The core of the new proposal is that the parent zone stores the
parent's signature over the child's zone KEY and also the child's parent's signature over the child's zone KEY and also the child's
zone KEY itself. The child zone may also contain its zone KEY, in zone KEY itself, and is authoritative for both KEY and SIG. The
which case is must be selfsigned. child zone may also contain its zone KEY, in which case is must be
selfsigned. The child zone must not hold the parent's SIG, and must
also not set the AA-bit on requests for its zone KEY.
The main advantage of this proposal is that all signatures signed by The main advantage of this proposal is that all signatures signed by
a key are in the same zone file as the producing key. This allows for a key are in the same zone file as the producing key. This allows for
a simple key rollover and resigning mechanism. For large TLDs this is a simple key rollover and resigning mechanism. For large TLDs this is
extremely important. A disadvantage would be that not all the extremely important. A disadvantage would be that not all the
information concerning one zone is stored at that zone, this is information concerning one zone is stored at that zone, this is
covered in section 7.2. covered in section 7.2.
A parent running DNSSEC SHOULD NOT refuse a request from a child to A parent running DNSSEC SHOULD NOT refuse a request from a child to
include and sign its key, but can ask for certain conditions to be include and sign its key, but can ask for certain conditions to be
skipping to change at line 176 skipping to change at page 10, line ?
" A zone KEY RR with the "no-key" type field value (both key type " A zone KEY RR with the "no-key" type field value (both key type
flag bits 0 and 1 on) indicates that the zone named is unsecured flag bits 0 and 1 on) indicates that the zone named is unsecured
while a zone KEY RR with a key present indicates that the zone named while a zone KEY RR with a key present indicates that the zone named
is secure. The secured versus unsecured status of a zone may vary is secure. The secured versus unsecured status of a zone may vary
with different cryptographic algorithms. Even for the same with different cryptographic algorithms. Even for the same
algorithm, conflicting zone KEY RRs may be present. " algorithm, conflicting zone KEY RRs may be present. "
This is rewritten as: This is rewritten as:
" A zone is considered secured by on-tree validation [1] when the " A zone is considered secured by on-tree validation [RFC 3090] when
there is a zone KEY from that zone present at its parent. If there the there is a zone KEY from that zone present at its parent. If
is no zone KEY present, and the resolver is also unaware of there is no zone KEY present, and the resolver is also unaware of
alternative algorithms used and/or possible off-tree validation, the alternative algorithms used and/or possible off-tree validation, the
zone is considered unsecured. " zone is considered unsecured. "
To further clarify this. A zone is secure, when the resolver expects
it to be, there are two possibilities:
1. When its parent is secure and holds a signed KEY for this child.
2. When zone is a secure entry point, i.e. the resolver is
preconfigured with the KEY of this zone.
RFC 3090 calls this globally secured.
When a zone contains SIGs and a selfsigned KEY and this KEY is
preconfigured in the resolvers of interest, the a zone can be
considered locally secured (the RFC 3090 defintion). hijacked.
If a zone is not globally or locally it must be considered unsecure.
3. Impact on a secure aware resolver/forwarder 3. Impact on a secure aware resolver/forwarder
The resolver must be aware of the fact that the parent is more The resolver must be aware of the fact that the parent is more
authoritative than a child when it comes to deciding whether a zone authoritative than a child when it comes to deciding whether a zone
is secured or not. is secured or not.
Without caching and with on-tree validation, a resolver will always Without caching and with on-tree validation, a resolver will always
start its search at a secure entry point. In this way it can start its search at a secure entry point. In this way it can
determine whether it must expect SIG records or not. determine whether it must expect SIG records or not.
Considering caching in a secure aware resolver or forwarder. If Considering caching in a secure aware resolver or forwarder. If
skipping to change at line 224 skipping to change at page 10, line ?
unsecured by this parent, despite the appearance of an (old) KEY in unsecured by this parent, despite the appearance of an (old) KEY in
the cache. This could for instance happen after an emergency request the cache. This could for instance happen after an emergency request
from the child, who has suffered a key compromise, and has decided to from the child, who has suffered a key compromise, and has decided to
prefer being unsecured over either dropping of the Internet or being prefer being unsecured over either dropping of the Internet or being
exposed to have verifiable secure info added by the key-compromiser exposed to have verifiable secure info added by the key-compromiser
to their zone information. to their zone information.
4. Scheduled key rollover 4. Scheduled key rollover
When the signatures, produced by the key to be rolled over, are all When the signatures, produced by the key to be rolled over, are all
in one zone file, there are two parties involved. Let us look at an in one zone file, there are two parties involved. Let us look at an
example where a TLD rolls over its zone KEY. The new key needs to be possible example where a TLD rolls over its zone KEY. The new key
signed with the root's key before it can be used to sign the TLD zone needs to be signed with the root's key before it can be used to sign
and the zone KEYs of the TLD's children. The steps that need to be the TLD zone and the zone KEYs of the TLD's children. The steps that
taken by TLD and root are: need to be taken by TLD and root are:
- the TLD adds the new key to its KEY set in its zonefile. This - the TLD adds the new key to its KEY set in its zonefile. This
zone and KEY set are signed with the old zone KEY zone and KEY set are signed with the old zone KEY
- then the TLD signals the parent - then the TLD signals the parent
- the root copies the new KEY set, consisting of the both new and - the root copies the new KEY set, consisting of the both new and
the old key, in its zonefile, resigns it and signals the TLD the old key, in its zonefile, resigns it and signals the TLD
- the TLD removes the old key from its KEY set, resigns its zone - the TLD removes the old key from its KEY set, resigns its zone
with the new KEY, and signals the the root with the new KEY, and signals the the root
- the root copies the new KEY set, now consisting of the new key - the root copies the new KEY set, now consisting of the new key
only, and resigns it only, and resigns it
skipping to change at line 253 skipping to change at page 10, line ?
that the parent holds. that the parent holds.
5. Unscheduled key rollover 5. Unscheduled key rollover
Although nobody hopes that this will ever happen, we must be able to Although nobody hopes that this will ever happen, we must be able to
cope with possible key compromises. When such an event occurs, an cope with possible key compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the shortest immediate keyrollover is needed and must be completed in the shortest
possible time. With two parties involved, it will still be awkward, possible time. With two parties involved, it will still be awkward,
but not impossible to update two zonefiles overnight. "Out-of-band" but not impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary, since the communication between the two parties will be necessary, since the
compromised old key can not be trusted. We think that between two compromised old key can not be trusted. We think that between two
parties this is doable, but this complicated procedure [5] is beyond parties this is doable, but this complicated procedure is beyond the
the scope of this document. scope of this document.
An alternative to an emergency key-rollover is becoming unsecured as An alternative to an emergency key-rollover is becoming unsecured as
an emercengy measure. This has already been mentioned above in an emergency measure. This has already been mentioned above in
section 3.1. This only involves an emergency change in the parents section 3.1. This only involves an emergency change in the parents
zonefile (deleting the child's zone KEY), and allows the child and zonefile (deleting the child's zone KEY), and allows the child and
its underlying zones time to clean up before becoming secured again, its underlying zones time to clean up before becoming secured again,
without dropping from the Internet or being exposed to having secured without dropping from the Internet or being exposed to having secured
but false zone information. but false zone information.
6. Zone resigning 6. Zone resigning
Resigning a TLD is necessary before the current signatures expire. Resigning a TLD is necessary before the current signatures expire.
When all SIGs (produced by the TLD's zone KEY) and the child KEY When all SIGs (produced by the TLD's zone KEY) and the child KEY
records, are kept in the TLD's zonefile, such a resign session is records, are kept in the TLD's zonefile, such a resign session is
skipping to change at line 286 skipping to change at page 10, line ?
To cope with 1, secure aware resolvers MUST be aware that during a To cope with 1, secure aware resolvers MUST be aware that during a
key-rollover there may be a conflict, and that in that case the key-rollover there may be a conflict, and that in that case the
parent always holds the active KEY set. To cope with 2, the local parent always holds the active KEY set. To cope with 2, the local
resolver/caching forwarder should be preconfigured with the zone-KEY resolver/caching forwarder should be preconfigured with the zone-KEY
and thus looks at its own zone as were it a secure entry-point. For and thus looks at its own zone as were it a secure entry-point. For
both things to work, the zone-KEY set must be selfsigned in the child both things to work, the zone-KEY set must be selfsigned in the child
zonefile. zonefile.
7.1. KEY bit in NXT records 7.1. KEY bit in NXT records
RFC 2535 [3], section 5.2 states: RFC 2535, section 5.2 states:
" The NXT RR type bit map format currently defined is one bit per " The NXT RR type bit map format currently defined is one bit per RR
RR type present for the owner name. A one bit indicates that at type present for the owner name. A one bit indicates that at least
least one RR of that type is present for the owner name. A zero one RR of that type is present for the owner name. A zero indicates
indicates that no such RR is present. [....] " that no such RR is present. [....] "
As the zone KEY is present in a child zone, and signed by the As the zone KEY is present in a child zone, and signed by the zone
zone KEY (thus selfsigned), the definition of NXT RR type bit states KEY (thus selfsigned), the definition of NXT RR type bit states in
in RFC 2535 [3], section 5.2 that the KEY bit must be set. We do not RFC 2535, section 5.2 that the KEY bit must be set. We do not see a
see a compelling reason to change this default behavior. compelling reason to change this default behavior.
7.2. Authority of KEY records 7.2. Authority of KEY records
The parent of a zone generates the signature for the key belonging to The parent of a zone generates the signature for the key belonging to
that zone. By making that signature available the parent publicly that zone. By making that signature available the parent publicly
states that the child zone is trustworthy: when it comes to security states that the child zone is trustworthy: when it comes to security
in DNSSEC the parent is more authoritative than the child. in DNSSEC the parent is more authoritative than the child.
From this we conclude that a parent zone MUST set the authority bit From this we conclude that a parent zone MUST set the authority bit
to 1 and child zones MUST set this bit to 0 when dealing with KEYs to 1 and child zones MUST set this bit to 0 when dealing with KEYs
from that child zone.This also causes resolvers to pick up and cache from that child zone.This also causes resolvers to pick up and cache
skipping to change at line 321 skipping to change at page 10, line ?
instance, the root. To be secure anyway it must be defined a secure instance, the root. To be secure anyway it must be defined a secure
entry point. If a resolver knows that a secure entry point is a entry point. If a resolver knows that a secure entry point is a
secure entry point it must have its key preconfigured. There is no secure entry point it must have its key preconfigured. There is no
need for a parent in this scenario, because the resolver itself can need for a parent in this scenario, because the resolver itself can
check the security of that zone. A interesting consequence of this is check the security of that zone. A interesting consequence of this is
that nobody is authoritative for a key belonging to a secure entry that nobody is authoritative for a key belonging to a secure entry
point. This authority must established via some out of band point. This authority must established via some out of band
mechanism, like publishing it in a newspaper. mechanism, like publishing it in a newspaper.
7.3. Selecting KEY sets 7.3. Selecting KEY sets
As the zone KEY set is present in two places, there may be a As the zone KEY set is present in two places, there is a possibility
possibility to find conflicting KEY sets, and this will at least of two conflicting KEY sets, this will happen during a key-rollover
really happen during a key-rollover. and may happen at other times.
With one exception, a resolver MUST always select the KEY set from With one exception, a resolver MUST always select the KEY set from
the parent in case of a conflict, as this is the active KEY set. For the parent in case of a conflict, as this is the active KEY set. For
this reason, the parent sets the AA-bit on requests, while the child this reason, the parent sets the AA-bit on requests, while the child
does not. does not.
The one exception is when a resolver regards the child's zone as a The one exception is when a resolver regards the child's zone as a
secure-entry point, in which case it has the zone KEY preconfigured. secure-entry point, in which case it has the zone KEY preconfigured.
In other words: a preconfigured KEY has even more authority then what In other words: a preconfigured KEY has even more authority then what
a parent says. Specifying a zone as a secure entry-point makes sense a parent says. Specifying a zone as a secure entry-point makes sense
for a local resolver in its own local zone. for a local resolver in its own local zone.
8. The zone KEY and local KEY records. 8. The zone KEY and local KEY records.
It must be recognized that the zone KEY RR, which is signed by a It must be recognized that the zone KEY RR, which is signed by a
non-local organisation, is something special. The external signature non-local organization, is something special. The external signature
over the public part of the key provides the local zone-administrator over the public part of the key provides the local zone-administrator
with the authority to use the corresponding private part to sign with the authority to use the corresponding private part to sign
everything local, and thus to make his/her own zone secure. Please everything local, and thus to make his/her own zone secure. Please
also note that the external signer, and NOT the local zone is also note that the external signer, and NOT the local zone is
authoritative for the zone KEY RRset. authoritative for the zone KEY RRset.
Part of the RRs that the zone-administrator may wish to sign are KEY Part of the RRs that the zone-administrator may wish to sign are KEY
RRs for local use, for instance for IPSEC. RRs for local use, for instance for IPSEC.
To make sure, that the local zone is authoritative for its own local To make sure, that the local zone is authoritative for its own local
KEY RRs, and that they get not exported and signed externally, these KEY RRs, and that they get not exported and signed externally, these
local KEY records SHOULD not be part of the zone KEY RRset. local KEY records SHOULD not be part of the zone KEY RRset.
Therefore, they SHOULD be placed under a label in the zonefile, f.i. Therefore, they could be placed under a label in the zonefile, f.i.
keys.child.parent. keys.child.parent, or for these kind of keys a new RR type could be
defined (e.g. PUBKEY).
Besides being kept clear of local KEY records, the zone KEY RRset Besides being kept clear of local KEY records, the zone KEY RRset
SHOULD also be kept clear of any other obsolete or otherwise not SHOULD also be kept clear of any other obsolete or otherwise not
strictly needed KEY records, because this increases the number of strictly needed KEY records, because this increases the number of
possible key compromise attacks and also increases the size of the possible key compromise attacks and also increases the size of the
parents zone file unnecessarily. parents zone file unnecessarily.
In other words: the KEY RRset with the toplevel label of a zone In other words: the KEY RRset with the toplevel label of a zone
SHOULD only contain its active zone KEY, unless a key-rollover is in SHOULD only contain its active zone KEY, unless a key-rollover is in
progress. During a keyrollover a new KEY RR must be added to this progress. During a keyrollover a new KEY RR must be added to this
RRset. Once the new KEY becomes the active zone KEY, the old KEY RRset. Once the new KEY becomes the active zone KEY, the old KEY
becomes obsolete and SHOULD be removed as soon as practically becomes obsolete and SHOULD be removed as soon as practically
possible. possible. Information stored in caches SHOULD NOT be an issue on when
to remove the old zone KEY.
9. Security Considerations 9. Security Considerations
This document addresses the operational difficulties that arise if This document addresses the operational difficulties that arise when
DNSSEC is deployed as it stands now, with the child's zone KEY not DNSSEC is deployed. By putting the child's zone KEY at the parent we
stored at the parent. By putting that key in the parent's zone the solve at lot of problems by minimizing the amount of communication
communication between the two is kept to a minimum thus reducing the between the two. There is one security issue: the parent must not
risk of errors. All security considerations from RFC 2535 apply. ever create a valid parental SIG over a KEY RR, from which the
private part is (also) known to someone else than the legitimate
administrator of the child zone. This can happen in two ways:
1. The private KEY at the child has been compromised.
2. The parent has been fooled and thus insufficiently checked
whether the KEY RR is really from the child.
For the security it doesn't matter if the SIG and the KEY are located
at the child or at the parent, but if they are located at the parent
it is much easier to replace the SIG. And by keeping the parental SIG
lifetime short, the parent helps to protect the child against
possible key compromises. The selfsigned zone KEY stored in the
child's zone can have a long SIG expiration lifetime, this has no
impact on the child's security.
All security considerations from RFC 2535 apply.
Authors' Addresses Authors' Addresses
R. Gieben T. Lindgreen R. Gieben T. Lindgreen
Stichting NLnet Labs Stichting NLnet Labs Stichting NLnet Labs Stichting NLnet Labs
Kruislaan 419 Kruislaan 419 Kruislaan 419 Kruislaan 419
1098 VA Amsterdam 1098 VA Amsterdam 1098 VA Amsterdam 1098 VA Amsterdam
miek@nlnetlabs.nl ted@nlnetlabs.nl miek@nlnetlabs.nl ted@nlnetlabs.nl
References References
[1] Lewis, E. "DNS Security Extension Clarification on Zone [RFC 3090] Lewis, E. "DNS Security Extension Clarification on Zone
Status", RFC 3090 Status", RFC 3090
www.ietf.org/rfc/rfc3090.txt www.ietf.org/rfc/rfc3090.txt
[2] Bradner, S. "Key words for use in RFCs to Indicate Requirement [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
www.ietf.org/rfc/rfc2119.txt www.ietf.org/rfc/rfc2119.txt
[3] Eastlake, D. "DNS Security Extensions", RFC 2535 [RFC 2535] Eastlake, D. "DNS Security Extensions", RFC 2535
www.ietf.org/rfc/rfc2535.txt www.ietf.org/rfc/rfc2535.txt
[4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security
Key Rollover"
www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
[5] Gieben, R. "Chain of trust"
secnl.nlnetlabs.nl/thesis/thesis.html
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/