new draft

doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt

@@ -2,7 +2,7 @@
 
 DNS Extensions                                                 R. Arends
 Internet-Draft                                      Telematica Instituut
-Expires: November 15, 2004                                    R. Austein
+Expires: January 13, 2005                                     R. Austein
                                                                      ISC
                                                                M. Larson
                                                                 VeriSign
@@ -10,33 +10,36 @@ Expires: November 15, 2004                                    R. Austein
                                                                  USC/ISI
                                                                  S. Rose
                                                                     NIST
-                                                            May 17, 2004
+                                                           July 15, 2004
 
 
                DNS Security Introduction and Requirements
-                   draft-ietf-dnsext-dnssec-intro-10
+                   draft-ietf-dnsext-dnssec-intro-11
 
 Status of this Memo
 
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
 
    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.
+   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 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 November 15, 2004.
+   This Internet-Draft will expire on January 13, 2005.
 
 Copyright Notice
 
@@ -46,17 +49,17 @@ Abstract
 
    The Domain Name System Security Extensions (DNSSEC) add data origin
    authentication and data integrity to the Domain Name System.  This
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 1]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
    document introduces these extensions, and describes their
    capabilities and limitations.  This document also discusses the
    services that the DNS security extensions do and do not provide.
-
-
-
-Arends, et al.         Expires November 15, 2004                [Page 1]
-
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
-
-
    Last, this document describes the interrelationships between the
    group of documents that collectively describe DNSSEC.
 
@@ -105,12 +108,9 @@ Table of Contents
 
 
 
-
-
-
-Arends, et al.         Expires November 15, 2004                [Page 2]
+Arends, et al.          Expires January 13, 2005                [Page 2]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 1.  Introduction
@@ -164,9 +164,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 3]
+Arends, et al.          Expires January 13, 2005                [Page 3]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 2.  Definitions of Important DNSSEC Terms
@@ -202,14 +202,14 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
       at least one public key; this configured data is usually either
       the public key itself or a hash of the public key as found in the
       DS RR (see "trust anchor").  Second, the resolver may use an
-      authenticated public key to verify a DS RR and its associated
-      DNSKEY RR.  Third, the resolver may be able to determine that a
-      new public key has been signed by the private key corresponding to
-      another public key which the resolver has verified.  Note that the
-      resolver must always be guided by local policy when deciding
-      whether to authenticate a new public key, even if the local policy
-      is simply to authenticate any new public key for which the
-      resolver is able verify the signature.
+      authenticated public key to verify a DS RR and the DNSKEY RR to
+      which the DS RR refers.  Third, the resolver may be able to
+      determine that a new public key has been signed by the private key
+      corresponding to another public key which the resolver has
+      verified.  Note that the resolver must always be guided by local
+      policy when deciding whether to authenticate a new public key,
+      even if the local policy is simply to authenticate any new public
+      key for which the resolver is able verify the signature.
 
    Delegation Point: Term used to describe the name at the parental side
       of a zone cut.  That is, the delegation point for "foo.example"
@@ -220,26 +220,26 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 4]
+Arends, et al.          Expires January 13, 2005                [Page 4]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
    Island of Security: Term used to describe a signed, delegated zone
       that does not have an authentication chain from its delegating
       parent.  That is, there is no DS RR containing a hash of a DNSKEY
       RR for the island in its delegating parent zone (see
-      [I-D.ietf-dnsext-dnssec-records]). An island of security is served
-      by security-aware name servers and may provide authentication
-      chains to any delegated child zones.  Responses from an island of
-      security or its descendents can only be authenticated if its
-      authentication keys can be authenticated by some trusted means out
-      of band from the DNS protocol.
+      [I-D.ietf-dnsext-dnssec-records]).  An island of security is
+      served by security-aware name servers and may provide
+      authentication chains to any delegated child zones.  Responses
+      from an island of security or its descendents can only be
+      authenticated if its authentication keys can be authenticated by
+      some trusted means out of band from the DNS protocol.
 
-   Key Signing Key: An authentication key that corresponds to a private
-      key used to sign one or more other authentication keys for a given
-      zone.  Typically, the private key corresponding to a key signing
-      key will sign a zone signing key, which in turn has a
+   Key Signing Key (KSK): An authentication key that corresponds to a
+      private key used to sign one or more other authentication keys for
+      a given zone.  Typically, the private key corresponding to a key
+      signing key will sign a zone signing key, which in turn has a
       corresponding private key which will sign other zone data.  Local
       policy may require the zone signing key to be changed frequently,
       while the key signing key may have a longer validity period in
@@ -276,7 +276,7 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 5]
+Arends, et al.          Expires January 13, 2005                [Page 5]
 
 
    Security-Aware Recursive Name Server: An entity which acts in both
@@ -317,7 +317,7 @@ Arends, et al.         Expires November 15, 2004                [Page 5]
       obtain the initial values of its trust anchors via some secure or
       trusted means outside the DNS protocol.  Presence of a trust
       anchor also implies that the resolver should expect the zone to
-      which the trust anchor points to be signed
+      which the trust anchor points to be signed.
 
    Unsigned Zone: A zone that is not signed.
 
@@ -332,17 +332,17 @@ Arends, et al.         Expires November 15, 2004                [Page 5]
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 6]
+Arends, et al.          Expires January 13, 2005                [Page 6]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
    Validating Stub Resolver: A less tedious term for a validating
       security-aware stub resolver.
 
-   Zone Signing Key: An authentication key that corresponds to a private
-      key used to sign a zone.  Typically a zone signing key will be
-      part of the same DNSKEY RRset as the key signing key whose
+   Zone Signing Key (ZSK): An authentication key that corresponds to a
+      private key used to sign a zone.  Typically a zone signing key
+      will be part of the same DNSKEY RRset as the key signing key whose
       corresponding private key signs this DNSKEY RRset, but the zone
       signing key is used for a slightly different purpose, and may
       differ from the key signing key in other ways, such as validity
@@ -388,9 +388,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 7]
+Arends, et al.          Expires January 13, 2005                [Page 7]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 3.  Services Provided by DNS Security
@@ -427,7 +427,8 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    keys for DNS transaction authentication mechanisms may also appear in
    zones, as described in [RFC2931], but DNSSEC itself is concerned with
    object security of DNS data, not channel security of DNS
-   transactions).
+   transactions.  The keys associated with transaction security may be
+   stored in different RR types.  See [RFC3755] for details.).
 
    A security-aware resolver can learn a zone's public key either by
    having a trust anchor configured into the resolver or by normal DNS
@@ -440,15 +441,15 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    authenticated previously.  Security-aware resolvers authenticate zone
    information by forming an authentication chain from a newly learned
    public key back to a previously known authentication public key,
-   which in turn either has been configured into the resolver or must
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 8]
+Arends, et al.          Expires January 13, 2005                [Page 8]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
+   which in turn either has been configured into the resolver or must
    have been learned and verified previously.  Therefore, the resolver
    must be configured with at least one trust anchor.  If the configured
    key is a zone signing key, then it will authenticate the associated
@@ -488,23 +489,23 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    an RRset's signature is "valid" within the meaning of DNSSEC.  In the
    final analysis however, authenticating both DNS keys and data is a
    matter of local policy, which may extend or even override the
-   protocol extensions defined in this document set.  See  for further
-   discussion.
+   protocol extensions defined in this document set.  See Section 5 for
+   further discussion.
 
 3.2  Authenticating Name and Type Non-Existence
 
    The security mechanism described in Section 3.1 only provides a way
    to sign existing RRsets in a zone.  The problem of providing negative
    responses with the same level of authentication and integrity
-   requires the use of another new resource record type, the NSEC
 
 
 
-Arends, et al.         Expires November 15, 2004                [Page 9]
+Arends, et al.          Expires January 13, 2005                [Page 9]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
+   requires the use of another new resource record type, the NSEC
    record.  The NSEC record allows a security-aware resolver to
    authenticate a negative reply for either name or type non-existence
    via the same mechanisms used to authenticate other DNS replies.  Use
@@ -555,10 +556,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-
-Arends, et al.         Expires November 15, 2004               [Page 10]
+Arends, et al.          Expires January 13, 2005               [Page 10]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 4.  Services Not Provided by DNS Security
@@ -612,9 +612,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 11]
+Arends, et al.          Expires January 13, 2005               [Page 11]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 5.  Scope of the DNSSEC Document Set and Last Hop Issues
@@ -668,9 +668,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 12]
+Arends, et al.          Expires January 13, 2005               [Page 12]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
    the lack of the specification of such communication does not prohibit
@@ -724,9 +724,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 13]
+Arends, et al.          Expires January 13, 2005               [Page 13]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 6.  Resolver Considerations
@@ -780,9 +780,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 14]
+Arends, et al.          Expires January 13, 2005               [Page 14]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 7.  Stub Resolver Considerations
@@ -836,9 +836,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 15]
+Arends, et al.          Expires January 13, 2005               [Page 15]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 8.  Zone Considerations
@@ -857,8 +857,8 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    and the signature validity period specified by the RRSIG RR covering
    that RRset.  DNSSEC does not change the definition or function of the
    TTL value, which is intended to maintain database coherency in
-   caches. A caching resolver purges RRsets from its cache no later than
-   the end of the time period specified by the TTL fields of those
+   caches.  A caching resolver purges RRsets from its cache no later
+   than the end of the time period specified by the TTL fields of those
    RRsets, regardless of whether or not the resolver is security-aware.
 
    The inception and expiration fields in the RRSIG RR
@@ -892,9 +892,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 16]
+Arends, et al.          Expires January 13, 2005               [Page 16]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 9.  Name Server Considerations
@@ -948,9 +948,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 17]
+Arends, et al.          Expires January 13, 2005               [Page 17]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 10.  DNS Security Document Family
@@ -1004,9 +1004,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 18]
+Arends, et al.          Expires January 13, 2005               [Page 18]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 11.  IANA Considerations
@@ -1060,9 +1060,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 19]
+Arends, et al.          Expires January 13, 2005               [Page 19]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 12.  Security Considerations
@@ -1097,9 +1097,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    vulnerable both to attacks on (and by) the security-aware recursive
    name servers which perform these checks on its behalf and also to
    attacks on its communication with those security-aware recursive name
-   servers. Non-validating security-aware stub resolvers should use some
-   form of channel security to defend against the latter threat. The
-   only known defense against the former threat would be for the
+   servers.  Non-validating security-aware stub resolvers should use
+   some form of channel security to defend against the latter threat.
+   The only known defense against the former threat would be for the
    security-aware stub resolver to perform its own signature validation,
    at which point, again by definition, it would no longer be a
    non-validating security-aware stub resolver.
@@ -1116,9 +1116,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 20]
+Arends, et al.          Expires January 13, 2005               [Page 20]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
    consume resources in a security-aware name server which supports DNS
@@ -1126,6 +1126,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    security-aware name server to re-sign some RRsets in the zone more
    frequently than would otherwise be necessary.
 
+   DNSSEC does not provide confidentiality, due to a deliberate design
+   choice.
+
    DNSSEC introduces the ability for a hostile party to enumerate all
    the names in a zone by following the NSEC chain.  NSEC RRs assert
    which names do not exist in a zone by linking from existing name to
@@ -1133,9 +1136,7 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    zone.  Thus, an attacker can query these NSEC RRs in sequence to
    obtain all the names in a zone.  While not an attack on the DNS
    itself, this could allow an attacker to map network hosts or other
-   resources by enumerating the contents of a zone. There are non-DNS
-   protocol means of detecting and limiting this attack beyond the scope
-   of this document set.
+   resources by enumerating the contents of a zone.
 
    DNSSEC introduces significant additional complexity to the DNS, and
    thus introduces many new opportunities for implementation bugs and
@@ -1143,9 +1144,6 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    validation in a resolver may cause entire legitimate zones to become
    effectively unreachable due to DNSSEC configuration errors or bugs.
 
-   DNSSEC does not provide confidentiality, due to a deliberate design
-   choice.
-
    DNSSEC does not protect against tampering with unsigned zone data.
    Non-authoritative data at zone cuts (glue and NS RRs in the parent
    zone) are not signed.  This does not pose a problem when validating
@@ -1172,9 +1170,11 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 21]
+
+
+Arends, et al.          Expires January 13, 2005               [Page 21]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 13.  Acknowledgements
@@ -1184,16 +1184,20 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
    who has contributed during the decade during which DNSSEC has been
    under development would be an impossible task, the editors would
    particularly like to thank the following people for their
-   contributions to and comments on this document set: Mark Andrews,
-   Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,
-   Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael
-   Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip
-   Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf
-   Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted
-   Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,
-   Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik
-   Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and
-   Brian Wellington.
+   contributions to and comments on this document set: Jaap Akkerhuis,
+   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+   Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
+   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+   Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
+   Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
+   Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
+   Suzanne Woolf.
 
    No doubt the above list is incomplete.  We apologize to anyone we
    left out.
@@ -1224,13 +1228,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-
-
-
-
-Arends, et al.         Expires November 15, 2004               [Page 22]
+Arends, et al.          Expires January 13, 2005               [Page 22]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 14.  References
@@ -1278,15 +1278,15 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
               progress), April 2004.
 
    [I-D.ietf-dnsext-nsec-rdata]
-              Schlyter, J., "KEY RR Secure Entry Point Flag",
-              draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
+              Schlyter, J., "DNSSEC NSEC RDATA Format",
+              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
               2004.
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 23]
+Arends, et al.          Expires January 13, 2005               [Page 23]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
@@ -1340,9 +1340,9 @@ Internet-Draft    DNSSEC Introduction and Requirements          May 2004
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 24]
+Arends, et al.          Expires January 13, 2005               [Page 24]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 Authors' Addresses
@@ -1396,69 +1396,52 @@ Authors' Addresses
 
 
 
-Arends, et al.         Expires November 15, 2004               [Page 25]
+Arends, et al.          Expires January 13, 2005               [Page 25]
 
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
 
 
 Intellectual Property Statement
 
    The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
+   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; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication 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 implementors or users of this specification can
-   be obtained from the IETF Secretariat.
+   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 which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
+   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.
 
 
-Full Copyright Statement
+Disclaimer of Validity
 
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   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 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.
 
 
+Copyright Statement
 
-Arends, et al.         Expires November 15, 2004               [Page 26]
-
-Internet-Draft    DNSSEC Introduction and Requirements          May 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+   Copyright (C) The Internet Society (2004).  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.
 
 
 Acknowledgment
@@ -1469,45 +1452,6 @@ Acknowledgment
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.         Expires November 15, 2004               [Page 27]
+Arends, et al.          Expires January 13, 2005               [Page 26]