rfc3008.txt revision b0ec080043c586a6be6a7f88151d7df61fd22009
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyNetwork Working Group B. Wellington
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyRequest for Comments: 3008 Nominum
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyUpdates: 2535 November 2000
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyCategory: Standards Track
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley Domain Name System Security (DNSSEC) Signing Authority
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyStatus of this Memo
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley This document specifies an Internet standards track protocol for the
9c3531d72aeaad6c5f01efe6a1c82023e1379e4dDavid Lawrence Internet community, and requests discussion and suggestions for
9c3531d72aeaad6c5f01efe6a1c82023e1379e4dDavid Lawrence improvements. Please refer to the current edition of the "Internet
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley Official Protocol Standards" (STD 1) for the standardization state
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley and status of this protocol. Distribution of this memo is unlimited.
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyCopyright Notice
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley Copyright (C) The Internet Society (2000). All Rights Reserved.
de8661e517ed679cfaa12e47eb9a8e23829ed320David Lawrence This document proposes a revised model of Domain Name System Security
de8661e517ed679cfaa12e47eb9a8e23829ed320David Lawrence (DNSSEC) Signing Authority. The revised model is designed to clarify
de8661e517ed679cfaa12e47eb9a8e23829ed320David Lawrence earlier documents and add additional restrictions to simplify the
de8661e517ed679cfaa12e47eb9a8e23829ed320David Lawrence secure resolution process. Specifically, this affects the
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley authorization of keys to sign sets of records.
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley document are to be interpreted as described in RFC 2119 [RFC2119].
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley1 - Introduction
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley This document defines additional restrictions on DNSSEC signatures
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley (SIG) records relating to their authority to sign associated data.
77771185071bf74d53378f1a3099a04d2af5153eBrian Wellington The intent is to establish a standard policy followed by a secure
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley resolver; this policy can be augmented by local rules. This builds
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley upon [RFC2535], updating section 2.3.6 of that document.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The most significant change is that in a secure zone, zone data is
077daa21229ffaedda79588fa70fbaeae19ae998Bob Halley required to be signed by the zone key.
077daa21229ffaedda79588fa70fbaeae19ae998Bob Halley Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
077daa21229ffaedda79588fa70fbaeae19ae998Bob Halley security extensions [RFC2535] is assumed.
9b2267b5ba9d0640512a41e139a4a36caa43730dBob HalleyWellington Standards Track [Page 1]
1a69a1a78cfaa86f3b68bbc965232b7876d4da2aDavid LawrenceRFC 3008 DNSSEC Signing Authority November 2000
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley2 - The SIG Record
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley A SIG record is normally associated with an RRset, and "covers" (that
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley is, demonstrates the authenticity and integrity of) the RRset. This
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley is referred to as a "data SIG". Note that there can be multiple SIG
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley records covering an RRset, and the same validation process should be
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley repeated for each of them. Some data SIGs are considered "material",
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley that is, relevant to a DNSSEC capable resolver, and some are
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
77771185071bf74d53378f1a3099a04d2af5153eBrian Wellington validation. Immaterial SIGs may have application defined roles. SIG
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley records may exist which are not bound to any RRset; these are also
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley considered immaterial. The validation process determines which SIGs
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley are material; once a SIG is shown to be immaterial, no other
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley validation is necessary.
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley SIGs may also be used for transaction security. In this case, a SIG
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley record with a type covered field of 0 is attached to a message, and
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley is used to protect message integrity. This is referred to as a
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley SIG(0) [RFC2535, RFC2931].
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The following sections define requirements for all of the fields of a
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley SIG record. These requirements MUST be met in order for a DNSSEC
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley capable resolver to process this signature. If any of these
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley requirements are not met, the SIG cannot be further processed.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley Additionally, once a KEY has been identified as having generated this
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley SIG, there are requirements that it MUST meet.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley2.1 - Type Covered
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley For a data SIG, the type covered MUST be the same as the type of data
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley in the associated RRset. For a SIG(0), the type covered MUST be 0.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley2.2 - Algorithm Number
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley The algorithm specified in a SIG MUST be recognized by the client,
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley and it MUST be an algorithm that has a defined SIG rdata format.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley The labels count MUST be less than or equal to the number of labels
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley in the SIG owner name, as specified in [RFC2535, section 4.1.3].
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley2.4 - Original TTL
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley The original TTL MUST be greater than or equal to the TTL of the SIG
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley record itself, since the TTL cannot be increased by intermediate
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley servers. This field can be ignored for SIG(0) records.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob HalleyWellington Standards Track [Page 2]
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob HalleyRFC 3008 DNSSEC Signing Authority November 2000
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley2.5 - Signature Expiration and Inception
5e4b7294d88ab58371d8c98e05ea80086dcb67cdBob Halley The current time at the time of validation MUST lie within the
5e4b7294d88ab58371d8c98e05ea80086dcb67cdBob Halley validity period bounded by the inception and expiration times.
5e4b7294d88ab58371d8c98e05ea80086dcb67cdBob Halley2.6 - Key Tag
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley There are no restrictions on the Key Tag field, although it is
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley possible that future algorithms will impose constraints.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley2.7 - Signer's Name
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The signer's name field of a data SIG MUST contain the name of the
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley zone to which the data and signature belong. The combination of
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley signer's name, key tag, and algorithm MUST identify a zone key if the
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley SIG is to be considered material. The only exception that the
5e4b7294d88ab58371d8c98e05ea80086dcb67cdBob Halley signer's name field in a SIG KEY at a zone apex SHOULD contain the
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley parent zone's name, unless the KEY set is self-signed. This document
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley defines a standard policy for DNSSEC validation; local policy may
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley override the standard policy.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley There are no restrictions on the signer field of a SIG(0) record.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The combination of signer's name, key tag, and algorithm MUST
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley identify a key if this SIG(0) is to be processed.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley2.8 - Signature
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley There are no restrictions on the signature field. The signature will
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley be verified at some point, but does not need to be examined prior to
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley verification unless a future algorithm imposes constraints.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley3 - The Signing KEY Record
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley Once a signature has been examined and its fields validated (but
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley before the signature has been verified), the resolver attempts to
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley locate a KEY that matches the signer name, key tag, and algorithm
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley fields in the SIG. If one is not found, the SIG cannot be verified
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley and is considered immaterial. If KEYs are found, several fields of
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley the KEY record MUST have specific values if the SIG is to be
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley considered material and authorized. If there are multiple KEYs, the
77771185071bf74d53378f1a3099a04d2af5153eBrian Wellington following checks are performed on all of them, as there is no way to
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley determine which one generated the signature until the verification is
1fc4929aa610263a2362afed516d7dc8e689397dBob HalleyWellington Standards Track [Page 3]
1fc4929aa610263a2362afed516d7dc8e689397dBob HalleyRFC 3008 DNSSEC Signing Authority November 2000
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley3.1 - Type Flags
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley The signing KEY record MUST have a flags value of 00 or 01
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley A DNSSEC resolver MUST only trust signatures generated by keys that
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley are permitted to authenticate data.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley3.2 - Name Flags
1fc4929aa610263a2362afed516d7dc8e689397dBob Halley The interpretation of this field is considerably different for data
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley SIGs and SIG(0) records.
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley3.2.1 - Data SIG
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley If the SIG record covers an RRset, the name type of the associated
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535,
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley section 2.3.6. The DNSSEC validation process performed by a resolver
9b2267b5ba9d0640512a41e139a4a36caa43730dBob Halley MUST ignore all keys that are not zone keys unless local policy
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley dictates otherwise.
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley The primary reason that RFC 2535 allows host and user keys to
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley generate material DNSSEC signatures is to allow dynamic update
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley without online zone keys; that is, avoid storing private keys in an
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley online server. The desire to avoid online signing keys cannot be
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley achieved, though, because they are necessary to sign NXT and SOA sets
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley [RFC3007]. These online zone keys can sign any incoming data.
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley Removing the goal of having no online keys removes the reason to
ed0b018ee06295f5fa8c45412486d40f219f2fefMichael Graff allow host and user keys to generate material signatures.
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley Limiting material signatures to zone keys simplifies the validation
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley process. The length of the verification chain is bounded by the
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley name's label depth. The authority of a key is clearly defined; a
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley resolver does not need to make a potentially complicated decision to
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley determine whether a key has the proper authority to sign data.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Finally, there is no additional flexibility granted by allowing
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley host/user key generated material signatures. As long as users and
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley hosts have the ability to authenticate update requests to the primary
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley zone server, signatures by zone keys are sufficient to protect the
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley integrity of the data to the world at large.
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley3.2.2 - SIG(0)
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley If the SIG record is a SIG(0) protecting a message, the name type of
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley the associated KEY SHOULD be 00 (user) or 10 (host/entity).
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley Transactions are initiated by a host or user, not a zone, so zone
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob Halley keys SHOULD not generate SIG(0) records.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob HalleyWellington Standards Track [Page 4]
2aa67e804d85f4d88153368ce65ce4df7b5390e6Bob HalleyRFC 3008 DNSSEC Signing Authority November 2000
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley A client is either explicitly executed by a user or on behalf of a
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley host, therefore the name type of a SIG(0) generated by a client
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley SHOULD be either user or host. A nameserver is associated with a
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley host, and its use of SIG(0) is not associated with a particular zone,
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley so the name type of a SIG(0) generated by a nameserver SHOULD be
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley3.3 - Signatory Flags
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley This document does not assign any values to the signatory field, nor
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley require any values to be present.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley3.4 - Protocol
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley resolver MUST NOT trust any signature that it generates.
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley3.5 - Algorithm Number
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The algorithm field MUST be identical to that of the generated SIG
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley record, and MUST meet all requirements for an algorithm value in a
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley4 - Security Considerations
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley This document defines a standard baseline for a DNSSEC capable
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley resolver. This is necessary for a thorough security analysis of
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley DNSSEC, if one is to be done.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley Specifically, this document places additional restrictions on SIG
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley records that a resolver must validate before the signature can be
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley considered worthy of DNSSEC trust. This simplifies the protocol,
e5afb85e525b2d2ed248dca0a954a124a704b206Andreas Gustafsson making it more robust and able to withstand scrutiny by the security
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley5 - Acknowledgements
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley The author would like to thank the following people for review and
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley informative comments (in alphabetical order):
2dfd6bca9aa6d9279b4278d6fa18ea5f63ba0ec9Bob Halley Olafur Gudmundsson
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob HalleyWellington Standards Track [Page 5]
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob HalleyRFC 3008 DNSSEC Signing Authority November 2000
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley6 - References
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley STD 13, RFC 1034, November 1987.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley [RFC1035] Mockapetris, P., "Domain Names - Implementation and
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley Specification", STD 13, RFC 1035, November 1987.
134ba0e08a0ae9a564a8d8628fc633377d3fc239Bob Halley [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Requirement Levels", BCP 14, RFC 2119, March 1997.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley "Dynamic Updates in the Domain Name System", RFC 2136,
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley RFC 2535, March 1999.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley (SIG(0)s )", RFC 2931, September 2000.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley [RFC3007] Wellington, B., "Simple Secure Domain Name System
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley (DNS) Dynamic Update", RFC 3007, November 2000.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley7 - Author's Address
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Brian Wellington
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Nominum, Inc.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley 950 Charter Street
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Redwood City, CA 94063
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Phone: +1 650 381 6022
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley EMail: Brian.Wellington@nominum.com
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob HalleyWellington Standards Track [Page 6]
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob HalleyRFC 3008 DNSSEC Signing Authority November 2000
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley8 Full Copyright Statement
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Copyright (C) The Internet Society (2000). All Rights Reserved.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley This document and translations of it may be copied and furnished to
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley others, and derivative works that comment on or otherwise explain it
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley or assist in its implementation may be prepared, copied, published
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley and distributed, in whole or in part, without restriction of any
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley kind, provided that the above copyright notice and this paragraph are
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley included on all such copies and derivative works. However, this
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley document itself may not be modified in any way, such as by removing
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley the copyright notice or references to the Internet Society or other
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley Internet organizations, except as needed for the purpose of
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley developing Internet standards in which case the procedures for
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley copyrights defined in the Internet Standards process must be
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley followed, or as required to translate it into languages other than
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley The limited permissions granted above are perpetual and will not be
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley revoked by the Internet Society or its successors or assigns.
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley This document and the information contained herein is provided on an
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
9ee5efde7df57cbe70fb9b32c9d898e8ef7eca1eBob Halley TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING