draft-ietf-dnsop-dnssec-key-timing-05.txt   draft-ietf-dnsop-dnssec-key-timing-06.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force S. Morris
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational J. Ihren Intended status: Informational J. Ihren
Expires: March 21, 2015 Netnod Expires: April 16, 2015 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
W. Mekking W. Mekking
NLnet Labs NLnet Labs
September 17, 2014 October 13, 2014
DNSSEC Key Rollover Timing Considerations DNSSEC Key Rollover Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-05.txt draft-ietf-dnsop-dnssec-key-timing-06.txt
Abstract Abstract
This document describes the issues surrounding the timing of events This document describes the issues surrounding the timing of events
in the rolling of a key in a DNSSEC-secured zone. It presents in the rolling of a key in a DNSSEC-secured zone. It presents
timelines for the key rollover and explicitly identifies the timelines for the key rollover and explicitly identifies the
relationships between the various parameters affecting the process. relationships between the various parameters affecting the process.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 21, 2015. This Internet-Draft will expire on April 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3
1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Limitation of Scope . . . . . . . . . . . . . . . . . . . 4
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8
3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9
3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 13 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 14
3.3.1. Double-KSK Method . . . . . . . . . . . . . . . . . . 14 3.3.1. Double-KSK Method . . . . . . . . . . . . . . . . . . 14
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 16 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 16
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 19 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 19
3.3.4. Interaction with Configured Trust Anchors . . . . . . 21 3.3.4. Interaction with Configured Trust Anchors . . . . . . 21
3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 22 3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 22
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 23 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 24
6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 24 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. Normative References . . . . . . . . . . . . . . . . . . . . . 25
11. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 25
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 26 Appendix B. Change History (To be removed on publication) . . . . 28
Appendix B. Change History (To be removed on publication) . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
1.1. Key Rolling Considerations 1.1. Key Rolling Considerations
When a zone is secured with DNSSEC, the zone manager must be prepared When a zone is secured with DNSSEC, the zone manager must be prepared
to replace ("roll") the keys used in the signing process. The to replace ("roll") the keys used in the signing process. The
rolling of keys may be caused by compromise of one or more of the rolling of keys may be caused by compromise of one or more of the
existing keys, or it may be due to a management policy that demands existing keys, or it may be due to a management policy that demands
periodic key replacement for security or operational reasons. In periodic key replacement for security or operational reasons. In
skipping to change at page 4, line 10 skipping to change at page 4, line 10
zone until it is "safe" to do so ("safe" in this context meaning that zone until it is "safe" to do so ("safe" in this context meaning that
at no time during the rollover process does any part of the zone ever at no time during the rollover process does any part of the zone ever
go bogus). In other words, although key management logic enforces go bogus). In other words, although key management logic enforces
policy, it may not enforce it strictly. policy, it may not enforce it strictly.
A high-level overview of key rollover can be found in [RFC6781]. In A high-level overview of key rollover can be found in [RFC6781]. In
contrast, this document focuses on the low-level timing detail of two contrast, this document focuses on the low-level timing detail of two
classes of operations described there, the rollover of zone-signing classes of operations described there, the rollover of zone-signing
keys (ZSKs), and the rollover of key-signing keys (KSKs). keys (ZSKs), and the rollover of key-signing keys (KSKs).
Note that the process for the introduction of keys into a zone is
different to that of rolling a key; see Section 3.3.5 for more
information about that topic.
1.2. Types of Keys 1.2. Types of Keys
Although DNSSEC validation treats all keys equally, [RFC4033] Although DNSSEC validation treats all keys equally, [RFC4033]
recognises the broad classification of ZSKs and KSKs. A ZSK is used recognises the broad classification of ZSKs and KSKs. A ZSK is used
to authenticate information within the zone; a KSK is used to to authenticate information within the zone; a KSK is used to
authenticate the zone's DNSKEY RRset. The main implication for this authenticate the zone's DNSKEY RRset. The main implication for this
distinction concerns the consistency of information during a distinction concerns the consistency of information during a
rollover. rollover.
During operation, a validating resolver must use separate pieces of During operation, a validating resolver must use separate pieces of
skipping to change at page 4, line 32 skipping to change at page 4, line 36
need to be retrieved from an authoritative server. The rollover need to be retrieved from an authoritative server. The rollover
process needs to happen in such a way that at all times during the process needs to happen in such a way that at all times during the
rollover the information is consistent. With a ZSK, the information rollover the information is consistent. With a ZSK, the information
is the RRSIG (plus associated RRset) and the DNSKEY. These are both is the RRSIG (plus associated RRset) and the DNSKEY. These are both
obtained from the same zone. In the case of the KSK, the information obtained from the same zone. In the case of the KSK, the information
is the DNSKEY and DS RRset with the latter being obtained from a is the DNSKEY and DS RRset with the latter being obtained from a
different zone. different zone.
Although there are similarities in the algorithms to roll ZSKs and Although there are similarities in the algorithms to roll ZSKs and
KSKs, there are a number of differences. For this reason, the two KSKs, there are a number of differences. For this reason, the two
types of rollovers are described separately. It is also possible to types of rollovers are described separately.
use a single key as both the ZSK and KSK. However, the rolling of
this type of key is not treated in this document.
1.3. Terminology 1.3. Terminology
The terminology used in this document is as defined in [RFC4033] and The terminology used in this document is as defined in [RFC4033] and
[RFC5011]. [RFC5011].
A number of symbols are used to identify times, intervals, etc. All A number of symbols are used to identify times, intervals, etc. All
are listed in Appendix A. are listed in Appendix A.
1.4. Limitation of Scope
This document represents current thinking at the time of publication.
However, the subject matter is evolving and it is not possible for
the document to be comprehensive. In particular, it does not cover:
o Rolling a key that is used as both a ZSK and KSK.
o Algorithm rollovers. Only the rolling of keys of the same
algorithm are described here, not transitions between algorithms.
The reader is therefore reminded that DNSSEC is, as of date of
publication, in the early stages of deployment, and best practices
may further develop over time.
2. Rollover Methods 2. Rollover Methods
2.1. ZSK Rollovers 2.1. ZSK Rollovers
For ZSKs, the issue for the zone operator/signer is to ensure that For ZSKs, the issue for the zone operator/signer is to ensure that
any caching validator has access to a particular signature that any caching validator which has access to a particular signature also
corresponds to a valid ZSK. has access to the corresponding valid ZSK.
A ZSK can be rolled in one of three ways: A ZSK can be rolled in one of three ways:
o Pre-Publication: described in [RFC6781], the new key is introduced o Pre-Publication: described in [RFC6781], the new key is introduced
into the DNSKEY RRset which is then re-signed. This state of into the DNSKEY RRset which is then re-signed. This state of
affairs remains in place for long enough to ensure that any cached affairs remains in place for long enough to ensure that any cached
DNSKEY RRsets contain both keys. At that point signatures created DNSKEY RRsets contain both keys. At that point signatures created
with the old key can be replaced by those created with the new with the old key can be replaced by those created with the new
key, and the old signatures removed. During the re-signing key, and the old signatures removed. During the re-signing
process (which may or may not be atomic depending on how the zone process (which may or may not be atomic depending on how the zone
skipping to change at page 6, line 46 skipping to change at page 7, line 16
validated DS record in the parent zone or an explicitly configured validated DS record in the parent zone or an explicitly configured
trust anchor. If the former, the rollover algorithm will need to trust anchor. If the former, the rollover algorithm will need to
involve the parent zone in the addition and removal of DS records, so involve the parent zone in the addition and removal of DS records, so
timings are not wholly under the control of the zone manager. If the timings are not wholly under the control of the zone manager. If the
latter, [RFC5011] timings will be needed to roll the keys. (Even in latter, [RFC5011] timings will be needed to roll the keys. (Even in
the case where authentication is via a DS record, the zone manager the case where authentication is via a DS record, the zone manager
may elect to include [RFC5011] timings in the key rolling process so may elect to include [RFC5011] timings in the key rolling process so
as to cope with the possibility that the key has also been explicitly as to cope with the possibility that the key has also been explicitly
configured as a trust anchor.) configured as a trust anchor.)
It is important to note that this does not preclude the development It is important to note that the need to interact with the parent
of key rollover logic; in accordance with the goal of the rollover does not preclude the development of key rollover logic; in
logic being able to determine when a state change is "safe", the only accordance with the goal of the rollover logic being able to
effect of being dependent on the parent is that there may be a period determine when a state change is "safe", the only effect of being
of waiting for the parent to respond in addition to any delay the key dependent on the parent is that there may be a period of waiting for
rollover logic requires. Although this introduces additional delays, the parent to respond in addition to any delay the key rollover logic
even with a parent that is less than ideally responsive the only requires. Although this introduces additional delays, even with a
effect will be a slowdown in the rollover state transitions. This parent that is less than ideally responsive the only effect will be a
may cause a policy violation, but will not cause any operational slowdown in the rollover state transitions. This may cause a policy
problems. violation, but will not cause any operational problems.
Like the ZSK case, there are three methods for rolling a KSK: Like the ZSK case, there are three methods for rolling a KSK:
o Double-KSK: the new KSK is added to the DNSKEY RRset which is then o Double-KSK: the new KSK is added to the DNSKEY RRset which is then
signed with both the old and new key. After waiting for the old signed with both the old and new key. After waiting for the old
RRset to expire from caches, the DS record in the parent zone is RRset to expire from caches, the DS record in the parent zone is
changed. After waiting a further interval for this change to be changed. After waiting a further interval for this change to be
reflected in caches, the old key is removed from the RRset. reflected in caches, the old key is removed from the RRset.
o Double-DS: the new DS record is published. After waiting for this o Double-DS: the new DS record is published. After waiting for this
skipping to change at page 7, line 46 skipping to change at page 8, line 17
are required with the parent. are required with the parent.
Finally, Double-RRset is the fastest way to roll the KSK, but has the Finally, Double-RRset is the fastest way to roll the KSK, but has the
drawbacks of both of the other methods: a larger DNSKEY RRset and two drawbacks of both of the other methods: a larger DNSKEY RRset and two
interactions with the parent. interactions with the parent.
3. Key Rollover Timelines 3. Key Rollover Timelines
3.1. Key States 3.1. Key States
A DNSSEC key contributes two pieces of information to the validation DNSSEC validation requires both the DNSKEY and information created
process: the DNSKEY itself and the data created from it. In the case from it (referred to as "associated data" in this section). In the
of the validation of an RR, the data created from the DNSKEY is the case of validation of an RR, the data associated with the the key is
RRSIG. Where there is a need to validate a chain or trust, the data the corresponding RRSIG. Where there is a need to validate a chain
created from the DNSKEY is the DS. In this section, the term of trust, the associated data is the DS record.
"associated data" refers to the RRSIGs created from a DNSKEY when
discussing a ZSK, or to the DNSKEY's corresponding DS record when
referring to a KSK.
During the rolling process, keys move through different states. The During the rolling process, keys move through different states. The
defined states are: defined states are:
Generated Although keys may be created immediately prior to first Generated Although keys may be created immediately prior to first
use, some implementations may find it convenient to use, some implementations may find it convenient to
create a pool of keys in one operation and draw from it create a pool of keys in one operation and draw from it
as required. (Note: such a pre-generated pool must be as required. (Note: such a pre-generated pool must be
secured against surreptitious use.) Keys that have been secured against surreptitious use.) Keys that have been
created but not yet used are said to be in the created but not yet used are said to be in the
"Generated" state. "Generated" state.
Published A key enters the published state when either it or its Published A key enters the published state when either it or its
associated data first appears in the appropriate zone. associated data first appears in the appropriate zone.
Ready The DNSKEY or its associated data have been published for Ready The DNSKEY or its associated data have been published for
long enough to guarantee that any previous versions of long enough to guarantee that copies of the key(s) it is
the DNSKEY and/or associated data have expired from replacing (or associated data related to that key) have
caches. expired from caches.
Active The data is starting to be used for validation. In the Active The data is starting to be used for validation. In the
case of a ZSK, it means that the key is now being be used case of a ZSK, it means that the key is now being be used
to sign RRsets and that both it and the created RRSIGs to sign RRsets and that both it and the created RRSIGs
appear in the zone. In the case of a KSK, it means that appear in the zone. In the case of a KSK, it means that
it is possible to use it to validate a DNSKEY RRset as it is possible to use it to validate a DNSKEY RRset as
both the DNSKEY and DS records are present in their both the DNSKEY and DS records are present in their
relevant zones. Note that when this state is entered, it relevant zones. Note that when this state is entered, it
may not be possible for validating resolvers to use the may not be possible for validating resolvers to use the
data for validation in all cases: the zone signing may data for validation in all cases: the zone signing may
skipping to change at page 24, line 4 skipping to change at page 24, line 19
zone. zone.
Whatever algorithm is used, the standby item of data can be included Whatever algorithm is used, the standby item of data can be included
in the zone on a permanent basis, or be a successor introduced as in the zone on a permanent basis, or be a successor introduced as
early as possible. early as possible.
5. Algorithm Considerations 5. Algorithm Considerations
The preceding sections have implicitly assumed that all keys and The preceding sections have implicitly assumed that all keys and
signatures are created using a single algorithm. However, [RFC4035] signatures are created using a single algorithm. However, [RFC4035]
(section 2.4) requires that there be an RRSIG for each RRset using at (section 2.2) requires that there be an RRSIG for each RRset using at
least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
Except in the case of an algorithm rollover - where the algorithms Except in the case of an algorithm rollover - where the algorithms
used to create the signatures are being changed - there is no used to create the signatures are being changed - there is no
relationship between the keys of different algorithms. This means relationship between the keys of different algorithms. This means
that they can be rolled independently of one another. In other that they can be rolled independently of one another. In other
words, the key rollover logic described above should be run words, the key rollover logic described above should be run
separately for each algorithm; the union of the results is included separately for each algorithm; the union of the results is included
in the zone, which is signed using the active key for each algorithm. in the zone, which is signed using the active key for each algorithm.
6. Limitation of Scope 6. Summary
This document represents current thinking at the time of publication.
However, the subject matter is evolving and it is more than likely
that this document will need to be revised in the future.
Some of the techniques and ideas that DNSSEC operators are
considering differ from this those described in this document. Of
particular interest are alternatives to the strict split into KSK and
ZSK key roles and the consequences for rollover logic from partial
signing (i.e. when the new key initially only signs a fraction of the
zone while leaving other signatures generated by the old key in
place).
Furthermore, as noted in section 5, this document covers only rolling
keys of the same algorithm: it does not cover transitions between
algorithms. The timing issues associated with algorithm rollovers
will require a separate document.
The reader is therefore reminded that DNSSEC is, as of date of
publication, in the early stages of deployment, and best practices
may further develop over time.
7. Summary
For ZSKs, "Pre-Publication" is generally considered to be the For ZSKs, "Pre-Publication" is generally considered to be the
preferred way of rolling keys. As shown in this document, the time preferred way of rolling keys. As shown in this document, the time
taken to roll is wholly dependent on parameters under the control of taken to roll is wholly dependent on parameters under the control of
the zone manager. the zone manager.
In contrast, "Double-RRset" is the most efficient method for KSK In contrast, "Double-RRset" is the most efficient method for KSK
rollover due to the ability to have new DS records and DNSKEY RRsets rollover due to the ability to have new DS records and DNSKEY RRsets
propagate in parallel. The time taken to roll KSKs may depend on propagate in parallel. The time taken to roll KSKs may depend on
factors related to the parent zone if the parent is signed. For factors related to the parent zone if the parent is signed. For
skipping to change at page 25, line 14 skipping to change at page 25, line 6
virtually all cases the rollover time will be determined by the virtually all cases the rollover time will be determined by the
RFC5011 "add hold-down" and "remove hold-down" times. It should be RFC5011 "add hold-down" and "remove hold-down" times. It should be
emphasized that this delay is a policy choice and not a function of emphasized that this delay is a policy choice and not a function of
timing values and that it also requires changes to the rollover timing values and that it also requires changes to the rollover
process due to the need to manage revocation of trust anchors. process due to the need to manage revocation of trust anchors.
Finally, the treatment of emergency key rollover is significantly Finally, the treatment of emergency key rollover is significantly
simplified by the introduction of standby keys as standard practice simplified by the introduction of standby keys as standard practice
during all types of rollovers. during all types of rollovers.
8. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
10. Acknowledgements 9. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy The authors gratefully acknowledge help and contributions from Roy
Arends and Wouter Wijngaards. Arends and Wouter Wijngaards.
11. Normative References 10. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 29, line 14 skipping to change at page 28, line 49
TTLkey Time to live of a DNSKEY record. (By implication, this is TTLkey Time to live of a DNSKEY record. (By implication, this is
also the time to live of the signatures on the DNSKEY also the time to live of the signatures on the DNSKEY
RRset.) RRset.)
TTLsig The maximum time to live of all the RRSIG records in the TTLsig The maximum time to live of all the RRSIG records in the
zone that were created with the ZSK. zone that were created with the ZSK.
Appendix B. Change History (To be removed on publication) Appendix B. Change History (To be removed on publication)
o draft-ietf-dnsop-dnssec-key-timing-06
* Clarifications to various text, as identified in WGLC.
* Moved "Limitiation of Scope" section to be a subsection of
section 1.
o draft-ietf-dnsop-dnssec-key-timing-05 o draft-ietf-dnsop-dnssec-key-timing-05
* Some more renamings of "Double-Signature" KSK rollover to * Some more renamings of "Double-Signature" KSK rollover to
"Double-KSK". "Double-KSK".
* Remove Tgen from diagrams. * Remove Tgen from diagrams.
* Review by Richard Lamb. * Review by Richard Lamb.
* Updated KSK rollover summary text. * Updated KSK rollover summary text.
* Updated variable descriptions in the appendix. * Updated variable descriptions in the appendix.
o draft-ietf-dnsop-dnssec-key-timing-04 o draft-ietf-dnsop-dnssec-key-timing-04
* Renamed to "DNSSEC Key Rollover Timing Considerations" to * Renamed to "DNSSEC Key Rollover Timing Considerations" to
 End of changes. 22 change blocks. 
75 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/