etc/services - sync with NetBSD-8
[minix.git] / external / bsd / bind / dist / contrib / zkt-1.1.3 / doc / draft-gudmundsson-life-of-dnskey-00.txt
blob18cda6c74278edc7b03ab182db1b247d4e3b1be1
4 Intended Status: Informational                            O. Gudmundsson
5 Network Working Group                                OGUD Consulting LLC
6 Internet-Draft                                                  J. Ihren
7 Expires: August 21, 2008                                             AAB
8                                                        February 18, 2008
11                 Names of States in the life of a DNSKEY
12                   draft-gudmundsson-life-of-dnskey-00
14 Status of this Memo
16    By submitting this Internet-Draft, each author represents that any
17    applicable patent or other IPR claims of which he or she is aware
18    have been or will be disclosed, and any of which he or she becomes
19    aware will be disclosed, in accordance with Section 6 of BCP 79.
21    Internet-Drafts are working documents of the Internet Engineering
22    Task Force (IETF), its areas, and its working groups.  Note that
23    other groups may also distribute working documents as Internet-
24    Drafts.
26    Internet-Drafts are draft documents valid for a maximum of six months
27    and may be updated, replaced, or obsoleted by other documents at any
28    time.  It is inappropriate to use Internet-Drafts as reference
29    material or to cite them other than as "work in progress."
31    The list of current Internet-Drafts can be accessed at
32    http://www.ietf.org/ietf/1id-abstracts.txt.
34    The list of Internet-Draft Shadow Directories can be accessed at
35    http://www.ietf.org/shadow.html.
37    This Internet-Draft will expire on August 21, 2008.
39 Copyright Notice
41    Copyright (C) The IETF Trust (2008).
55 Gudmundsson & Ihren      Expires August 21, 2008                [Page 1]
57 Internet-Draft           DNSSEC Key life stages.           February 2008
60 Abstract
62    This document recommends a specific terminology to use when
63    expressing the state that a DNSKEY is in at particular time.  This
64    does not affect how the protocol operates in any way.
67 Table of Contents
69    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
70    2.  DNSKEY timeline  . . . . . . . . . . . . . . . . . . . . . . .  4
71    3.  Life stages of a DNSKEY  . . . . . . . . . . . . . . . . . . .  5
72      3.1.  Generated  . . . . . . . . . . . . . . . . . . . . . . . .  5
73      3.2.  Published  . . . . . . . . . . . . . . . . . . . . . . . .  5
74        3.2.1.  Pre-Publication  . . . . . . . . . . . . . . . . . . .  5
75        3.2.2.  Out-Of-Band Publication  . . . . . . . . . . . . . . .  5
76      3.3.  Active . . . . . . . . . . . . . . . . . . . . . . . . . .  5
77      3.4.  Retired  . . . . . . . . . . . . . . . . . . . . . . . . .  5
78      3.5.  Removed  . . . . . . . . . . . . . . . . . . . . . . . . .  6
79        3.5.1.  Lame . . . . . . . . . . . . . . . . . . . . . . . . .  6
80        3.5.2.  Stale  . . . . . . . . . . . . . . . . . . . . . . . .  6
81      3.6.  Revoked  . . . . . . . . . . . . . . . . . . . . . . . . .  6
82    4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
83    5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  8
84    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
85      6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
86      6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
87    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
88    Intellectual Property and Copyright Statements . . . . . . . . . . 11
111 Gudmundsson & Ihren      Expires August 21, 2008                [Page 2]
113 Internet-Draft           DNSSEC Key life stages.           February 2008
116 1.  Introduction
118    When the editors of this document where comparing their DNSSEC key
119    management projects they discovered that they where discussing
120    roughly the same thing but using different terminology.
122    This document presents a unified terminology to use when describing
123    the current state of a DNSKEY.
125    The DNSSEC standards documents ([1], [2] and [3]) do not address the
126    required states for the key management of a DNSSEC key.  The DNSSEC
127    Operational Practices [4] document does propose that keys be
128    published before use but uses inconsistent or confusing terms.  This
129    document assumes basic understanding of DNSSEC and key management.
131    The terms proposed in this document attempt to avoid any confusion
132    and make the states of keys to be as clear as possible.  The terms
133    used in this document are intended as a operational supplement to the
134    terms defined in Section 2 of [1].
136    To large extent this discussion is motivated by Trust anchor keys but
137    the same terminology can be used for zone signing keys.
167 Gudmundsson & Ihren      Expires August 21, 2008                [Page 3]
169 Internet-Draft           DNSSEC Key life stages.           February 2008
172 2.  DNSKEY timeline
174    The model in this document is that keys progress through a state
175    machine along a one-way path, keys never move to an earlier states.
179    GENERATED----------> PUBLISHED ---> ACTIVE ---> RETIRED --> REMOVED
180     |                   ^       |        |            |         ^
181     |                   |       |        |            v         |
182     +--> Pre-PUBLISHED--+       +--------+---------> REVOKED ---+
185    DNSKEY time line.
187    There are few more states that are defined below but these apply only
188    to the publisher of TA's and the consumer of TA's.  Two of these are
189    sub-sets of the Published state, the other two are error states.
223 Gudmundsson & Ihren      Expires August 21, 2008                [Page 4]
225 Internet-Draft           DNSSEC Key life stages.           February 2008
228 3.  Life stages of a DNSKEY
230 3.1.  Generated
232    Once a key is generated it enters state Generated and stays there
233    until the next state.  While in this state only the owner of the key
234    is aware of its existence and can prepare for its future use.
236 3.2.  Published
238    Once the key is added to the DNSKEY set of a zone the key is there
239    for the world to see, or published.  The key needs to remain in this
240    state for some time to propagate to all validators that have cached
241    the prior version of the DNSKEY set.  In the case of KSK the key
242    should remain in this state for a longer time as documented in DNSSEC
243    Timers RFC [5].
245 3.2.1.  Pre-Publication
247    In certain circumstances a zone owner may want to give out a new
248    Trust Anchor before exposing the actual public key.  In this case the
249    zone can publish a DS record of the key.  This allows others to
250    configure the trust anchor but will not be able to use the key until
251    the key is published in the DNSKEY RRset.
253 3.2.2.  Out-Of-Band Publication
255    In certain circumstances a domain may want to give out a new Trust
256    Anchor outside DNS to give others a long lead time to configure the
257    new key as trust anchor.  The reason people may want to do this is to
258    keep the size of the DNSKEY set smaller and only add new trust anchor
259    just before the key goes into use.  One likely use for this is the
260    DNS "." root key as it does not have a parent that can publish a DS
261    record for it.  The publication mechanism does not matter it can be
262    any one of web-site, advertisement in Financial Times and other
263    international publication, e-mail to DNS related mailing lists, etc..
265 3.3.  Active
267    The key is in ACTIVE state while it is actively signing data in the
268    zone it resides in.  It is one of the the keys that are signing the
269    zone or parts of the zone.
271 3.4.  Retired
273    When the key is no longer used for signing the zone it enters state
274    Retired.  In this state there may still be signatures by the key in
275    cached data from the zone available at recursive servers, but the
279 Gudmundsson & Ihren      Expires August 21, 2008                [Page 5]
281 Internet-Draft           DNSSEC Key life stages.           February 2008
284    authoritative servers for the zone do no longer carry any signatures
285    generated by the key.
287 3.5.  Removed
289    Once the key is removed from the DNSKEY RRset it enters the state
290    Removed.  At this point all signatures by the key that may still be
291    temporarily valid will fail to verify once the validator refreshes
292    the DNSKEY RRset in its memory.
294    Therefore "removal" of a key is typically not done until all the
295    cached signatures have expired.  Entering this state too early may
296    cause number of validators to end up with STALE Trust Anchors.
298 3.5.1.  Lame
300    A Trust Anchor is Lame if the parent continues to publish DS pointing
301    to the key after it has been removed from the DNSKEY RRset.  A Trust
302    Anchor is arguably Lame if there are no signatures by a Retired KSK
303    in the zone.
305 3.5.2.  Stale
307    A Stale Trust Anchor is an old TA that remains in a validators list
308    of active key(s) after the key has been removed from the zone's
309    DNSKEY RRset.
311 3.6.  Revoked
313    There are times when a zone wants to signal that a particular key
314    should not be used at all.  The mechanism to do this is to set the
315    REVOKE bit [5].  Any key in any of the while the key is the DNSSKEY
316    set can be exited to Revoked state.  After some time in the Revoke
317    state the key will be Removed.
335 Gudmundsson & Ihren      Expires August 21, 2008                [Page 6]
337 Internet-Draft           DNSSEC Key life stages.           February 2008
340 4.  Security considerations
342    TBD
391 Gudmundsson & Ihren      Expires August 21, 2008                [Page 7]
393 Internet-Draft           DNSSEC Key life stages.           February 2008
396 5.  IANA considerations
398    This document does not have any IANA actions.
447 Gudmundsson & Ihren      Expires August 21, 2008                [Page 8]
449 Internet-Draft           DNSSEC Key life stages.           February 2008
452 6.  References
454 6.1.  Normative References
456 6.2.  Informative References
458    [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
459         "DNS Security Introduction and Requirements", RFC 4033,
460         March 2005.
462    [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
463         "Resource Records for the DNS Security Extensions", RFC 4034,
464         March 2005.
466    [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
467         "Protocol Modifications for the DNS Security Extensions",
468         RFC 4035, March 2005.
470    [4]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
471         RFC 4641, September 2006.
473    [5]  StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust
474         Anchors", RFC 5011, September 2007.
503 Gudmundsson & Ihren      Expires August 21, 2008                [Page 9]
505 Internet-Draft           DNSSEC Key life stages.           February 2008
508 Authors' Addresses
510    Olafur Gudmundsson
511    OGUD Consulting LLC
512    3821 Village Park Drive
513    Chevy Chase, MD  20815
514    USA
516    Email: ogud@ogud.com
519    Johan Ihren
520    Automatica, AB
521    Bellmansgatan 30
522    Stockholm,   SE-118 47
523    Sweden
525    Email: johani@automatica.se
559 Gudmundsson & Ihren      Expires August 21, 2008               [Page 10]
561 Internet-Draft           DNSSEC Key life stages.           February 2008
564 Full Copyright Statement
566    Copyright (C) The IETF Trust (2008).
568    This document is subject to the rights, licenses and restrictions
569    contained in BCP 78, and except as set forth therein, the authors
570    retain all their rights.
572    This document and the information contained herein are provided on an
573    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
574    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
575    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
576    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
577    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
578    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
581 Intellectual Property
583    The IETF takes no position regarding the validity or scope of any
584    Intellectual Property Rights or other rights that might be claimed to
585    pertain to the implementation or use of the technology described in
586    this document or the extent to which any license under such rights
587    might or might not be available; nor does it represent that it has
588    made any independent effort to identify any such rights.  Information
589    on the procedures with respect to rights in RFC documents can be
590    found in BCP 78 and BCP 79.
592    Copies of IPR disclosures made to the IETF Secretariat and any
593    assurances of licenses to be made available, or the result of an
594    attempt made to obtain a general license or permission for the use of
595    such proprietary rights by implementers or users of this
596    specification can be obtained from the IETF on-line IPR repository at
597    http://www.ietf.org/ipr.
599    The IETF invites any interested party to bring to its attention any
600    copyrights, patents or patent applications, or other proprietary
601    rights that may cover technology that may be required to implement
602    this standard.  Please address the information to the IETF at
603    ietf-ipr@ietf.org.
606 Acknowledgment
608    Funding for the RFC Editor function is provided by the IETF
609    Administrative Support Activity (IASA).
615 Gudmundsson & Ihren      Expires August 21, 2008               [Page 11]