Root DNSSEC Design Team F. Ljunggren
Kirei
T. Okubo
VeriSign
R. Lamb
ICANN
J. Schlyter
Kirei
May 21, 2010
DNSSEC Practice Statement for the Root Zone KSK Operator
Abstract
This document is the DNSSEC Practice Statement (DPS) for the Root
Zone Key Signing Key (KSK) Operator. It states the practices and
provisions that are used to provide Root Zone Key Signing and Key
Distribution services. These include, but are not limited to:
issuing, managing, changing and distributing DNS keys in accordance
with the specific requirements of the U.S. Department of Commerce.
Copyright Notice
Copyright 2009 by VeriSign, Inc., and by Internet Corporation For
Assigned Names and Numbers. This work is based on the Certification
Practice Statement, Copyright 1996-2004 by VeriSign, Inc. Used by
Permission. All Rights Reserved.
Trademark Notices
ICANN is a registered trademark of The Internet Corporation for
Assigned Names and Numbers.
VERISIGN is a registered trademark of VeriSign, Inc.
Ljunggren, et al. [Page 1]
Root Zone KSK Operator DPS May 2010
Table of Contents
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Document name and identification . . . . . . . . . . . . . 7
1.3. Community and Applicability . . . . . . . . . . . . . . . 7
1.3.1. IANA Functions Operator . . . . . . . . . . . . . . . 7
1.3.2. Root Zone Administrator . . . . . . . . . . . . . . . 7
1.3.3. Root Zone Maintainer . . . . . . . . . . . . . . . . . 7
1.3.4. Root Server Operators . . . . . . . . . . . . . . . . 7
1.3.5. Root Zone Key Signing Key Operator . . . . . . . . . . 8
1.3.6. Root Zone Zone Signing Key Operator . . . . . . . . . 8
1.3.7. Child zone manager . . . . . . . . . . . . . . . . . . 9
1.3.8. Relying Party . . . . . . . . . . . . . . . . . . . . 9
1.3.9. Applicability . . . . . . . . . . . . . . . . . . . . 9
1.4. Specification Administration . . . . . . . . . . . . . . . 10
1.4.1. Specification administration organization . . . . . . 10
1.4.2. Contact Information . . . . . . . . . . . . . . . . . 10
1.4.3. Specification change procedures . . . . . . . . . . . 10
2. PUBLICATION AND REPOSITORIES . . . . . . . . . . . . . . . . . 11
2.1. Repositories . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Publication of key signing keys . . . . . . . . . . . . . 11
2.3. Access controls on repositories . . . . . . . . . . . . . 11
3. OPERATIONAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . 11
3.1. Meaning of domain names . . . . . . . . . . . . . . . . . 11
3.2. Activation of DNSSEC for child zone . . . . . . . . . . . 12
3.3. Identification and authentication of child zone manager . 12
3.4. Registration of delegation signer (DS) resource records . 12
3.5. Method to prove possession of private key . . . . . . . . 12
3.6. Removal of DS resource records . . . . . . . . . . . . . . 12
3.6.1. Who can request removal . . . . . . . . . . . . . . . 13
3.6.2. Procedure for removal request . . . . . . . . . . . . 13
3.6.3. Emergency removal request . . . . . . . . . . . . . . 13
4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS . . . . . . . . 13
4.1. Physical Controls . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Site location and construction . . . . . . . . . . . . 13
4.1.2. Physical access . . . . . . . . . . . . . . . . . . . 14
4.1.3. Power and air conditioning . . . . . . . . . . . . . . 14
4.1.4. Water exposures . . . . . . . . . . . . . . . . . . . 14
4.1.5. Fire prevention and protection . . . . . . . . . . . . 14
4.1.6. Media storage . . . . . . . . . . . . . . . . . . . . 15
4.1.7. Waste disposal . . . . . . . . . . . . . . . . . . . . 15
4.1.8. Off-site backup . . . . . . . . . . . . . . . . . . . 15
4.2. Procedural Controls . . . . . . . . . . . . . . . . . . . 15
4.2.1. Trusted roles . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Number of persons required per task . . . . . . . . . 16
4.2.3. Identification and authentication for each role . . . 17
4.2.4. Tasks requiring separation of duties . . . . . . . . . 17
Ljunggren, et al. [Page 2]
Root Zone KSK Operator DPS May 2010
4.3. Personnel Controls . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Qualifications, experience, and clearance
requirements . . . . . . . . . . . . . . . . . . . . . 17
4.3.2. Background check procedures . . . . . . . . . . . . . 18
4.3.3. Training requirements . . . . . . . . . . . . . . . . 18
4.3.4. Retraining frequency and requirements . . . . . . . . 19
4.3.5. Job rotation frequency and sequence . . . . . . . . . 19
4.3.6. Sanctions for unauthorized actions . . . . . . . . . . 19
4.3.7. Contracting personnel requirements . . . . . . . . . . 19
4.3.8. Documentation supplied to personnel . . . . . . . . . 20
4.4. Audit Logging Procedures . . . . . . . . . . . . . . . . . 20
4.4.1. Types of events recorded . . . . . . . . . . . . . . . 20
4.4.2. Frequency of processing log . . . . . . . . . . . . . 20
4.4.3. Retention period for audit log information . . . . . . 21
4.4.4. Protection of audit log . . . . . . . . . . . . . . . 21
4.4.5. Audit log backup procedures . . . . . . . . . . . . . 21
4.4.6. Audit collection system . . . . . . . . . . . . . . . 21
4.4.7. Notification to event-causing subject . . . . . . . . 22
4.4.8. Vulnerability assessments . . . . . . . . . . . . . . 22
4.5. Compromise and Disaster Recovery . . . . . . . . . . . . . 22
4.5.1. Incident and compromise handling procedures . . . . . 22
4.5.2. Corrupted computing resources, software, and/or
data . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5.3. Entity private key compromise procedures . . . . . . . 23
4.5.4. Business Continuity and IT Disaster Recovery
Capabilities . . . . . . . . . . . . . . . . . . . . . 24
4.6. Entity termination . . . . . . . . . . . . . . . . . . . . 25
5. TECHNICAL SECURITY CONTROLS . . . . . . . . . . . . . . . . . 25
5.1. Key Pair Generation and Installation . . . . . . . . . . . 25
5.1.1. Key pair generation . . . . . . . . . . . . . . . . . 25
5.1.2. Public key delivery . . . . . . . . . . . . . . . . . 25
5.1.3. Public key parameters generation and quality
checking . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.4. Key usage purposes . . . . . . . . . . . . . . . . . . 26
5.2. Private key protection and Cryptographic Module
Engineering Controls . . . . . . . . . . . . . . . . . . . 26
5.2.1. Cryptographic module standards and controls . . . . . 26
5.2.2. Private key (m-of-n) multi-person control . . . . . . 26
5.2.3. Private key escrow . . . . . . . . . . . . . . . . . . 27
5.2.4. Private key backup . . . . . . . . . . . . . . . . . . 27
5.2.5. Private key storage on cryptographic module . . . . . 27
5.2.6. Private key archival . . . . . . . . . . . . . . . . . 27
5.2.7. Private key transfer into or from a cryptographic
module . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.8. Method of activating private key . . . . . . . . . . . 28
5.2.9. Method of deactivating private key . . . . . . . . . . 28
5.2.10. Method of destroying private key . . . . . . . . . . . 28
5.3. Other Aspects of Key Pair Management . . . . . . . . . . . 28
Ljunggren, et al. [Page 3]
Root Zone KSK Operator DPS May 2010
5.3.1. Public key archival . . . . . . . . . . . . . . . . . 28
5.3.2. Key usage periods . . . . . . . . . . . . . . . . . . 28
5.4. Activation data . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. Activation data generation and installation . . . . . 28
5.4.2. Activation data protection . . . . . . . . . . . . . . 29
5.4.3. Other aspects of activation data . . . . . . . . . . . 29
5.5. Computer Security Controls . . . . . . . . . . . . . . . . 29
5.6. Network Security Controls . . . . . . . . . . . . . . . . 29
5.7. Timestamping . . . . . . . . . . . . . . . . . . . . . . . 30
5.8. Life Cycle Technical Controls . . . . . . . . . . . . . . 30
5.8.1. System development controls . . . . . . . . . . . . . 30
5.8.2. Security management controls . . . . . . . . . . . . . 30
5.8.3. Life cycle security controls . . . . . . . . . . . . . 31
6. ZONE SIGNING . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Key lengths and algorithms . . . . . . . . . . . . . . . . 31
6.2. Authenticated denial of existence . . . . . . . . . . . . 31
6.3. Signature format . . . . . . . . . . . . . . . . . . . . . 32
6.4. Zone signing key roll-over . . . . . . . . . . . . . . . . 32
6.5. Key signing key roll-over . . . . . . . . . . . . . . . . 32
6.6. Signature life-time and re-signing frequency . . . . . . . 32
6.7. Verification of zone signing key set . . . . . . . . . . . 34
6.8. Verification of resource records . . . . . . . . . . . . . 35
6.9. Resource records time-to-live . . . . . . . . . . . . . . 35
7. COMPLIANCE AUDIT . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Frequency of entity compliance audit . . . . . . . . . . . 35
7.2. Identity/qualifications of auditor . . . . . . . . . . . . 35
7.3. Auditor's relationship to audited party . . . . . . . . . 36
7.4. Topics covered by audit . . . . . . . . . . . . . . . . . 36
7.5. Actions taken as a result of deficiency . . . . . . . . . 36
7.6. Communication of results . . . . . . . . . . . . . . . . . 36
8. LEGAL MATTERS . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Financial responsibility . . . . . . . . . . . . . . . . . 37
8.3. Confidentiality of business information . . . . . . . . . 37
8.3.1. Scope of confidential information . . . . . . . . . . 37
8.3.2. Information not within the scope of confidential
information . . . . . . . . . . . . . . . . . . . . . 37
8.3.3. Responsibility to protect confidential information . . 37
8.4. Privacy of personal information . . . . . . . . . . . . . 37
8.4.1. Information treated as private . . . . . . . . . . . . 38
8.4.2. Types of information not considered private . . . . . 38
8.4.3. Responsibility to protect private information . . . . 38
8.4.4. Disclosure Pursuant to Judicial or Administrative
Process . . . . . . . . . . . . . . . . . . . . . . . 38
8.5. Limitations of liability . . . . . . . . . . . . . . . . . 38
8.6. Term and termination . . . . . . . . . . . . . . . . . . . 38
8.6.1. Term . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.6.2. Termination . . . . . . . . . . . . . . . . . . . . . 38
Ljunggren, et al. [Page 4]
Root Zone KSK Operator DPS May 2010
8.6.3. Dispute resolution provisions . . . . . . . . . . . . 38
8.6.4. Governing law . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Table of acronyms and definitions . . . . . . . . . . 39
A.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. History of changes . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Ljunggren, et al. [Page 5]
Root Zone KSK Operator DPS May 2010
1. INTRODUCTION
This document is the ICANN DNSSEC Practice Statement (DPS) as the
Root Zone Key Signing Key Operator. It states the practices and
provisions that ICANN, on behalf of the U.S. Department of Commerce
(DoC), employ in providing Root Zone Key Signing and Key Distribution
services. These include, but are not limited to, issuing, managing,
changing and distributing DNS keys in accordance with the specific
requirements of the DoC.
1.1. Overview
The Domain Name System Security Extensions (DNSSEC) is a set of IETF
specifications for adding origin authentication and data integrity to
the Domain Name System. DNSSEC provides a way for software to
validate that Domain Name System (DNS) data has not been modified
during Internet transit. This is done by incorporating public key
cryptography into the DNS hierarchy to form a chain of trust
originating at the root zone.
The DNS was not originally designed with strong security mechanisms
to provide integrity and authenticity of DNS data. Over the years, a
number of vulnerabilities have been discovered that threaten the
reliability and trustworthiness of the system. DNSSEC addresses
these vulnerabilities by adding data origin authentication, data
integrity verification and authenticated denial of existence
capabilities to the DNS.
This DPS is specifically applicable to the IANA Functions Operator
and Root Zone Key Signing Key Operator. More generally, this
document provides the governing practices and provisions related to
the management, security and technical specifications of DNSSEC
operation at the Root. This document will be under the control and
management of ICANN with guidance and direction from the DoC.
Information in this document and subsequent documents will be made
public as required.
The DPS is only one of a set of documents relevant to ICANN's
management of the Root Zone's Key Signing Key. Other documents
include: ancillary security and operational documents that supplement
the DPS by providing more detailed requirements, such as the Key
Ceremony Reference Guide, which presents detailed key management
operational procedures. In some instances, the DPS refers to these
ancillary documents for specific, detailed practices implementing
ICANN policies where including the specifics are not relevant to the
purpose of the DPS.
Ljunggren, et al. [Page 6]
Root Zone KSK Operator DPS May 2010
1.2. Document name and identification
Document title:
DNSSEC Practice Statement for the Root Zone KSK Operator
Version:
A ($Revision: 1358 $)
Date:
$Date: 2010-05-21 16:02:17 +0200 (Fri, 21 May 2010) $
1.3. Community and Applicability
1.3.1. IANA Functions Operator
The Internet Corporation for Assigned Names and Numbers (ICANN) acts
as the Internet Assigned Numbers Authority (IANA) Functions Operator
under contract to the U.S. Department of Commerce, National
Telecommunications and Information Administration (DoC/NTIA). The
IANA Functions Operator accepts change requests to the contents of
the Root Zone from the Top Level Domain (TLD) Operators and validates
those requests. After validation occurs, the IANA Functions Operator
submits the requests to the DoC/NTIA for authorization and sends a
copy to the Root Zone Maintainer for implementation once
authorization is received.
1.3.2. Root Zone Administrator
The Root Zone Administrator is the National Telecommunications and
Information Administration, which is an agency in the U.S. Department
of Commerce that performs the authorization for changes to the Root
Zone. This role differs from the third party auditors who conduct
the compliance audit and generates the audit report.
1.3.3. Root Zone Maintainer
VeriSign, per the Cooperative Agreement with the U.S. Department of
Commerce, is acting as the Root Zone Maintainer. The Root Zone
Maintainer is performing the function of receiving change requests to
the Root Zone from the IANA Functions Operator, receiving
authorization to make changes to the Root Zone from the Root Zone
Administrator, implementing the changes, generating a new Root Zone
File and distributing it to the Root Server Operators.
1.3.4. Root Server Operators
The Root Server Operators consists of 12 different professional
engineering entities responsible for providing the root zone to the
public via the 13 Root Zone Authoritative Name Servers.
Ljunggren, et al. [Page 7]
Root Zone KSK Operator DPS May 2010
The Root Server Operators are not involved in the making of any
policies or modification of data.
1.3.5. Root Zone Key Signing Key Operator
ICANN is the Root Zone Key Signing Key Operator (as the IANA
Functions Operator) performing the function of generating the Root
Zone's Key Signing Key (KSK) and signing the Root Keyset, including
the Root Zone Zone Signing Key (RZ ZSK), using the KSK. The Root
Zone KSK Operator is also responsible for securely generating and
storing the private keys and distributing the public portion of the
KSK as the Trust Anchor to the relying parties.
The Root Zone KSK (RZ KSK) Operator is responsible for:
(1) Generating and protecting the private component of the RZ KSK.
(2) Securely importing public key components from the RZ ZSK
Operator.
(3) Authenticating and validating the public RZ ZSK keyset.
(4) Securely signing the RZ ZSK keyset.
(5) Securely transmitting the signed RZ ZSK key set to the RZ ZSK
Operator.
(6) Securely exporting the RZ KSK public key components.
(7) Issuing an emergency key roll-over within a reasonable time if
any private key component associated with the zone is lost or
suspected to be compromised.
1.3.6. Root Zone Zone Signing Key Operator
The Root Zone Zone Signing Key Operator is VeriSign performing the
function of generating the Root Zone's Zone Signing Key (ZSK) and
signing the Root Zone File using the ZSK.
The Root Zone Zone Signing Key (RZ ZSK) Operator is also responsible
for securely generating and storing the private keys and distributing
the public portion of the ZSK to the RZ KSK Operator for signing.
The Root Zone ZSK Operator is responsible for:
(1) Generating and protecting the private component of the RZ ZSK.
(2) Securely exporting and transmitting the public RZ ZSK component
to the RZ KSK Operator.
(3) Securely importing the signed RZ ZSK keyset from the RZ KSK
Operator.
Ljunggren, et al. [Page 8]
Root Zone KSK Operator DPS May 2010
(4) Signing the Root Zone's resource records (optionally omitting
the DNSKEY resource record).
(5) Issue emergency key roll-over within a reasonable amount of time
if any private key component associated with the zone is lost or
suspected to be compromised.
1.3.7. Child zone manager
The child zone (TLD) manager is a trustee for the delegated domain,
and as such responsible for providing registry services and operating
subordinate DNS servers. If a child zone is signed using DNSSEC, the
child zone manager is also responsible for:
(1) Generating the keys associated with its zone using a trustworthy
method.
(2) Registering and maintaining the shorthand representations of its
Key Signing Key (Delegation Signer Resource Record) in the
parent zone to establish the chain of trust.
(3) Taking reasonable precautions to prevent any loss, disclosure or
unauthorized use of the keys associated with its zone.
(4) Issuing emergency key roll-over within reasonable time if any
private key associated with its zone is lost or suspected to be
compromised.
1.3.8. Relying Party
A Relying Party is the entity that relies on DNSSEC, such as
security-aware validating resolvers and other applications that
perform validation of DNSSEC signatures.
The relying party must properly configure and update the Trust
Anchors as appropriate. The automated method described in RFC 5011
[RFC5011] may be used.
Relying parties must also stay informed of any critical changes in
the Root Zone operation as notified by ICANN in accordance with
section 2.1.
1.3.9. Applicability
This DPS is only applicable to the Root Zone, and more specifically
the RZ KSK Operator. Each link in the chain of trust may have
entirely different requirements that can affect the end entity, and
is not governed by this DPS.
Entities must evaluate their own environments and its associated
threats and vulnerabilities to determine the level of risk they are
willing to accept.
Ljunggren, et al. [Page 9]
Root Zone KSK Operator DPS May 2010
1.4. Specification Administration
This DPS will be periodically reviewed and updated, as appropriate by
the RZ KSK Operator Policy Management Authority (PMA). The PMA is
responsible for the management of the DPS and should be considered as
the point of contact for all matters related to the DPS. The PMA
notifies, and when appropriate, seeks the review and authorization
from DoC prior to taking action and/or modification of the DPS.
1.4.1. Specification administration organization
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601
USA
1.4.2. Contact Information
RZ KSK Operator Policy Management Authority
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601
USA
+1 (310) 823-9358 (voice)
+1 (310) 823-8649 (fax)
dnssec-pma@iana.org
1.4.3. Specification change procedures
Amendments to this DPS are made by the RZ KSK Operator Policy
Management Authority (PMA). Amendments will either be in the form of
a document containing an amended form of the DPS or an update.
Amended versions or updates will be linked to the Practices Updates
and Notices section of the ICANN Repository (See section 2.1).
Updates supersede any designated or conflicting provisions of the
referenced version of the DPS.
The PMA reserves the right to amend the DPS without notification for
amendments that are not material, including without limitation
corrections of typographical errors, changes to URLs, and changes to
contact information. The PMA's decision to designate amendments as
material or non-material is within the PMA's sole discretion.
Proposed amendments to the DPS will appear in the Practices Updates
and Notices section of the ICANN Repository, which is located at
https://www.iana.org/dnssec. The PMA solicits proposed amendments to
the DPS from the community. If the PMA considers such an amendment
desirable and proposes to implement the amendment, the PMA will
provide public notice of such amendment in accordance with this
Ljunggren, et al. [Page 10]
Root Zone KSK Operator DPS May 2010
section. Should the PMA determine that material amendments to the
DPS are necessary immediately to stop or prevent a breach of the
security of any portion of it, the PMA is entitled to make such
amendments by publication in the ICANN Repository. Such amendments
will be effective immediately upon publication.
2. PUBLICATION AND REPOSITORIES
2.1. Repositories
ICANN, as the KSK Operator, publishes the DPS in the repository
section of the IANA web site at https://www.iana.org/dnssec. Public
access to this repository will include the option of using an HTTPS-
authenticated channel.
Announcements relevant to DNSSEC in the Root Zone will also be posted
on an announcement-only mailing list. Subscription and related
information for the mailing list can be found at
https://www.iana.org/dnssec.
2.2. Publication of key signing keys
The public portion of the Root Key Signing Key will be posted on
ICANN's repository as a Trust Anchor along with the method to
validate its integrity.
Refer to "DNSSEC Trust Anchor Publication for the Root Zone" for
details.
2.3. Access controls on repositories
Information published in the repository portion of the ICANN web site
is publicly accessible information. Read-only access to this
information is unrestricted. ICANN has implemented logical and
physical security measures to prevent unauthorized persons from
adding, deleting, or modifying repository entries.
3. OPERATIONAL REQUIREMENTS
3.1. Meaning of domain names
DNSSEC provides mechanisms for ensuring that the origin of the DNS
data is consistent with the information in the registry. It does not
provide any way of determining the legal entity behind the domain
name, or the relevance of the domain name itself. Refer to ICANN's
policies (http://www.icann.org/en/policy/) for details on top level
Ljunggren, et al. [Page 11]
Root Zone KSK Operator DPS May 2010
domain name assignments.
3.2. Activation of DNSSEC for child zone
The DNSSEC chain of trust from the RZ to a child zone is activated by
the publishing of a signed Delegation Signer (DS) record for that
child zone in the root zone. The DS record is a cryptographic
shorthand representation, or hash, of the child zone generated and
controlled Key Signing Key. It will establish a chain of trust from
the Root Zone to the Child Zone.
The child zone manager must submit the DS record to request
activation of DNSSEC. In this DPS, the child zone is equivalent to
TLD.
3.3. Identification and authentication of child zone manager
The identity and authority of the Child Zone Manager will be verified
using the appropriate method for that specific child zone.
3.4. Registration of delegation signer (DS) resource records
The Delegation Signer (DS) resource record provided by the Child Zone
Manager is vetted and processed by the IANA Functions Operator and
incorporated into a change request, requesting Root Zone
Administrator authorization to make the change in the root zone as
per DoC requirements.
The DS resource record must be valid and submitted in the DS RR
Presentation Format as described in RFC 4034 [RFC4034]. As part of
the vetting process the DS record is checked against the child zones
DNSKEY keyset and signatures. After Root Zone Administrator
authorization, the DS resource record is incorporated into the Root
Zone and signed by the Root Zone Maintainer.
3.5. Method to prove possession of private key
The IANA Functions Operator will take effort to ensure the
availability and integrity of the child zone by validating the DS
resource record to the currently published DNSKEY RRSIGs. If a DS
resource record does not validate, there will be an out-of-band
process in order to confirm the authenticity and intention of
publishing the DS resource record.
3.6. Removal of DS resource records
Ljunggren, et al. [Page 12]
Root Zone KSK Operator DPS May 2010
3.6.1. Who can request removal
The removal of DS resource records (stale or active) can only be
requested by the Child Zone Manager.
3.6.2. Procedure for removal request
Delegation Signer (DS) removal requests is vetted and processed by
the IANA Functions Operator, and authorized by the Root Zone
Administrator like any other changes to the Root Zone file.
Upon reception of the request and authentication of the requester,
the IANA Functions Operator will conduct checks to confirm the
removal of the relevant key from the child's zones DNSKEY RRset as
part of the vetting process.
3.6.3. Emergency removal request
If the Child Zone Manager is unable to produce a valid DNSSEC signed
zone, the manager of that zone may request an emergency removal of
the DS resource record following the IANA Functions Operator's
emergency change process.
The emergency change process will be completed within 48 hours from
the reception of a valid Emergency removal request.
4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS
4.1. Physical Controls
As the KSK Operator, ICANN has implemented physical security
controls, which support the security requirements of this DPS.
Compliance with these policies is included in ICANN's independent
audit requirements described in section 7.
4.1.1. Site location and construction
ICANN's DNSSEC operations are conducted within physically protected
environments that deter, prevent, and detects any unauthorized use
of, access to, or disclosure of sensitive information and systems,
whether covert or overt. ICANN maintains disaster recovery
capabilities for its DNSSEC operations by maintaining more than one
site with comparable physical security.
Ljunggren, et al. [Page 13]
Root Zone KSK Operator DPS May 2010
4.1.2. Physical access
ICANN's signer systems are protected by a minimum of four tiers of
physical security, with access to lower tiers required before gaining
access to higher tiers. Progressively more restrictive physical
access controls to each tier are applied. Unauthorized access
becomes increasingly difficult as one reaches higher tiers.
Sensitive DNSSEC operational activity and any activity related to the
lifecycle of the RZ KSK occur within these restrictive physical
tiers.
Physical access is automatically logged and video recorded. All
tiers enforce individual access control through the use of two-factor
authentication. Unescorted personnel, including visitors or
employees without specific authorization, are not allowed into such
secured areas. The physical security system includes additional
controls for tiers used for key management activity which serves to
protect storage of Hardware Security Modules (HSMs) and keying
material.
Areas used to create and store cryptographic material enforce dual
access control, each through the use of two-factor authentication.
HSMs are protected through the use of tamper-evident bags, locked
safes, cabinets and containers. Access to HSMs and keying material
is restricted in accordance with ICANN's segregation of duty
requirements. The opening and closing of cabinets or containers in
these tiers is logged for auditing purposes.
4.1.3. Power and air conditioning
ICANN's secure facilities are equipped with primary and backup power
systems to ensure continuous, uninterrupted access to electric power
and backup heating/ventilation/air conditioning systems to control
temperature and relative humidity.
4.1.4. Water exposures
ICANN has taken reasonable precautions to minimize the impact of
water exposure to the signer systems.
4.1.5. Fire prevention and protection
ICANN has taken reasonable precautions to prevent and extinguish
fires or other damaging exposure to flame or smoke. ICANN's fire
prevention and protection measures have been designed to comply with
local fire safety regulations.
Ljunggren, et al. [Page 14]
Root Zone KSK Operator DPS May 2010
4.1.6. Media storage
All media containing production software and data, audit, archive, or
backup information are stored within ICANN facilities or in a secure
off-site storage facility with appropriate physical and logical
access controls designed to limit access to authorized personnel and
protect such media from accidental damage (e.g., water, fire and
electromagnetic radiation).
4.1.7. Waste disposal
Sensitive documents and materials are shredded before disposal.
Media used to collect or transmit sensitive information are rendered
unreadable before disposal. Cryptographic devices are physically
destroyed or zeroized in accordance with the manufacturers' guidance
prior to disposal. Other waste is disposed of in accordance with
ICANN's normal waste disposal requirements.
4.1.8. Off-site backup
ICANN performs routine backups of critical system data, audit log
data, and other sensitive information. Off-site backup media are
stored in a physically secure manner using a bonded third party
storage facility.
4.2. Procedural Controls
4.2.1. Trusted roles
ICANN considers the categories of personnel identified in this
section as Trusted Persons having a Trusted Role. A Trusted Person
may only possess one Trusted Role. Persons seeking to become Trusted
Persons by obtaining a Trusted Role must successfully complete the
screening requirements set out in this DPS.
Trusted Persons include all employees, contractors, and consultants
that have access to or control operations that may materially affect:
o Generation and protection of the private component of the Root
Zone Key Signing Key.
o Secure export or import of any public components.
o Zone File data.
Trusted roles include, but are not limited to:
o Designated system administration personnel
Ljunggren, et al. [Page 15]
Root Zone KSK Operator DPS May 2010
o Crypto officers
o Recovery key share holders
o Safe security controllers
o Internal witnesses
o The ceremony administrators
4.2.2. Number of persons required per task
ICANN has established, maintains, and enforces rigorous control
procedures to ensure the segregation of duties based on roles and to
ensure that multiple Trusted Persons are required to perform
sensitive tasks.
The most sensitive tasks, such as access to and management of
cryptographic key material, are enforced by rigorous control
procedures to ensure the segregation of duties based on roles. These
procedures also ensure that multiple Trusted Persons are required to
perform any sensitive tasks.
Access to and management of cryptographic hardware is based on the
principle of successive barriers in three tiers, requiring at least
seven trusted persons from four different roles. These barriers are
as follows:
Tier 5:
Physical access to safe room requires one out of four persons
from the Key Ceremony Administrator role in combination with
one out of four persons from the Internal Witness roles.
Tier 6:
Physical access to cryptographic hardware (HSM) and activation
material requires one out of two of the Safe Controller #1s,
and one out of the two Safe Controller #2s in addition to the
Trusted Persons required at Tier 5 and 7.
Tier 7:
Activation of HSM requires three out of seven Crypto Officers.
Restoration of the contents of a HSM requires at least six trusted
persons from two different roles, as follows:
Secret share:
Reconstruction of the secret key used for encryption of the
application keys requires five out of seven Recovery Key Share
Holders.
Encrypted application keys:
Physical access to the encrypted application keys requires one
out of four Ceremony Administrators.
These combinations of people are designed so that the binomial
Ljunggren, et al. [Page 16]
Root Zone KSK Operator DPS May 2010
probability to find a group collaborating in any of these
constellations is less than one in a million, assuming a dishonesty
rate of 5% among Trusted Persons
Other internal control procedures are designed to ensure that at a
minimum of two Trusted Persons are required to perform any sensitive
task.
4.2.3. Identification and authentication for each role
For all personnel seeking to become Trusted Persons, verification of
identity is performed through the personal (physical) presence of
such personnel before Trusted Persons performing security functions
and a check of well-recognized forms of identification (e.g.,
passports and driver's licenses). Identity is further confirmed
through the background checking procedures described in section 4.3
of this DPS. ICANN ensures that personnel have achieved Trusted
Status and approval has been given before these personnel are:
o issued access devices and granted access to the required
facilities,
o issued electronic credentials to access and perform specific
functions on ICANN IT systems.
4.2.4. Tasks requiring separation of duties
Tasks requiring separation of duties include (but are not limited to)
the generation, use and destruction of Root Zone DNSSEC key material.
Personnel holding a role in the multi-party access to the RZ KSK do
not hold a role in the multi-party access to the RZ ZSK, or vice
versa. Audit personnel also may not participate in the multi-person
control for the RZ KSK or RZ ZSK.
4.3. Personnel Controls
4.3.1. Qualifications, experience, and clearance requirements
ICANN requires that personnel seeking to become Trusted Persons
present proof of the requisite background, qualifications, and
experience needed to perform their prospective job responsibilities
competently and satisfactorily.
Background checks are repeated at least every 5 years for personnel
holding Trusted Roles.
Ljunggren, et al. [Page 17]
Root Zone KSK Operator DPS May 2010
4.3.2. Background check procedures
All personnel with access to any cryptographic components used with
the Root Zone Signing process are required to pass a background check
extending back at least three years.
Prior to commencement of engagement in a Trusted Role, ICANN conducts
background checks that include the following:
o Confirmation of previous employment
o Check of professional references
o Confirmation of the highest or most relevant educational degree
obtained
o Check of credit/financial records to the extent allowed by
national laws for the individual's country of residence
The factors revealed in a background check that may be considered
grounds for rejecting candidates for Trusted Roles, or for taking
action against an existing Trusted Person generally include, but are
not limited to:
o Misrepresentations made by the candidate or Trusted Person
o Highly unfavorable or unreliable professional references
o Indications of a lack of financial responsibility
Reports containing such information are evaluated by human resources
and security personnel, who determine the appropriate course of
action in light of the type, magnitude, and frequency of the behavior
uncovered by the background check.
Such actions may include measures up to and including the
cancellation of offers of employment made to candidates for Trusted
Roles or the termination of existing Trusted Persons. The use of
information revealed in a background check to take such actions is
subject to the applicable federal, state, and local laws.
4.3.3. Training requirements
ICANN provides its personnel with training when hired, as well as the
requisite on-the-job training needed for them to perform their job
responsibilities competently and satisfactorily. ICANN periodically
reviews and enhances its training programs as necessary.
ICANN's training programs are tailored to the individuals'
responsibilities and include the following as relevant:
Ljunggren, et al. [Page 18]
Root Zone KSK Operator DPS May 2010
o Basic DNS/DNSSEC concepts
o Job responsibilities
o Use and operation of deployed hardware and software
o Security and operational policies and procedures
o Incident and compromise reporting and handling
o Disaster recovery and business continuity procedures
4.3.4. Retraining frequency and requirements
ICANN provides refresher training and updates to their personnel to
the extent and frequency required to ensure that such personnel
maintain the required level of proficiency to perform their job
responsibilities competently and satisfactorily.
4.3.5. Job rotation frequency and sequence
The responsibility to execute the tasks of respective Trusted Roles
will be distributed evenly over the set of the appointed personnel.
Recovery Key Share Holders and Crypto Officers will be serving annual
terms. Refer to "Trusted Community Representatives - Proposed
Approach to Root Key Management" for details.
Other positions are rotated and replaced as needed.
4.3.6. Sanctions for unauthorized actions
Appropriate disciplinary actions are taken for unauthorized actions
with respect to this DPS and/or other violations of ICANN security
policies and procedures. Disciplinary actions may include measures
up to and including termination and are commensurate with the
frequency and severity of the unauthorized actions.
4.3.7. Contracting personnel requirements
In limited circumstances, independent contractors or consultants may
be used to fill Trusted Roles. Any such contractor or consultant is
held to the same functional and security criteria that apply to any
ICANN employees in a comparable role. Independent contractors and
consultants who have not completed or passed the background check
procedures specified in DPS section 4.3 are permitted access to
ICANN's secure facilities only to the extent they are escorted and
directly supervised by Trusted Persons at all times.
Ljunggren, et al. [Page 19]
Root Zone KSK Operator DPS May 2010
4.3.8. Documentation supplied to personnel
ICANN provides its employees the requisite training and other
documentation needed to perform their job responsibilities
competently and satisfactorily.
4.4. Audit Logging Procedures
4.4.1. Types of events recorded
Specific auditing events related to KSK key life cycle management
events, including:
o Key generation, backup, storage, recovery, archival, and
destruction.
o Exporting of public key components.
KSK signing and management events, including:
o Key activation
o Receipt and validation of public key material (i.e., from the ZSK
holder)
o Successful or unsuccessful signing requests
Security-related events, including:
o Assignment and revocation of credentials
o Successful and unsuccessful system access attempts
o Key and security system actions performed by trusted personnel
o Security sensitive files or records read, written or deleted
o Security profile changes
o System crashes, hardware failures and other anomalies
o Facility visitor entry/exit
o System changes and maintenance/system updates
o Incident response handling
Log entries include the following elements:
o Date and time of the entry
o Identity of the entity making the journal entry
o Type of entry
Other events as appropriate.
4.4.2. Frequency of processing log
Audit logs are examined after each key ceremony for significant
security and operational events. In addition, ICANN reviews its
Ljunggren, et al. [Page 20]
Root Zone KSK Operator DPS May 2010
audit logs for suspicious or unusual activity in response to alerts
generated based on irregularities and incidents within the DNSSEC
related systems. Audit log processing consists of a review of the
audit logs and documentation for all significant events in an audit
log summary. Audit log reviews include a verification that the log
has not been tampered with and an investigation of any alerts or
irregularities in the logs. Actions taken based on audit log reviews
are also documented.
4.4.3. Retention period for audit log information
All audit data collected in terms of section 4.4.1 is retained on-
site for at least one year after creation and then archived for at
least 10 years.
The media holding the audit data and the applications required to
process the information are maintained to ensure that the archived
data can be accessed for the time period set forth in this DPS.
4.4.4. Protection of audit log
Audit logs are kept off-line and protected with an audit log handling
procedure that includes mechanisms to protect the log files from
unauthorized viewing, modification, deletion, or other tampering.
Only authorized Trusted Persons are able to obtain direct access to
the audit information.
4.4.5. Audit log backup procedures
ICANN backs up electronic archives of its audit information in an
off-site secure facility after each key ceremony. Copies of paper-
based records are also stored off-site and are maintained in the same
manner.
4.4.6. Audit collection system
Automated audit data is generated and recorded at the application and
operating system level. Manually generated audit data is recorded by
the Ceremony Administrator on paper.
After each completed Key Ceremony, the audit log information is
collected by the Ceremony Administrator at the generating host and
copied onto at least two portable media. Electronic copies of paper-
based documents are also made.
The Ceremony Administrator is responsible for storing one copy of the
audit log information at the off-site secure facility, and one copy
Ljunggren, et al. [Page 21]
Root Zone KSK Operator DPS May 2010
with the signer system.
4.4.7. Notification to event-causing subject
No notice is required to be given to the individual, organization,
device, or application causing a log event.
4.4.8. Vulnerability assessments
Events in the audit process are logged, in part, to monitor system
vulnerabilities. Vulnerability assessments are performed manually as
part of the audit log review process after each key ceremony.
ICANN also maintains contacts with relevant parties within the
community to share the latest security-related information which may
affect the signed root zone. Continuous vulnerability assessments
are made based on this information.
4.5. Compromise and Disaster Recovery
4.5.1. Incident and compromise handling procedures
If ICANN detects an event that has lead to, or could have lead to a
security compromise of any of the security mechanisms, it will
perform an investigation in order to determine the nature of the
incident. If the incident is suspected to have compromised the
private component of an active KSK, the Emergency KSK roll-over
procedure will be enacted as described in section 4.5.3.
Otherwise, the scope, severity and damage of the incident will be
assessed and a plan to remedy the effect will be developed and
implemented. The plan will also include measures to prevent the
event from reoccurring.
The incident handling procedures include reporting of all events to
ICANN KSK Operations Security (IKOS), which in turn reports to the
Policy Management Authority (PMA).
4.5.2. Corrupted computing resources, software, and/or data
In the event of the corruption of computing resources, software,
and/or data, this occurrence will be reported to IKOS and will cause
ICANN's incident handling procedures to be enacted. Such procedures
require appropriate escalation, incident investigation, and incident
response. If necessary, ICANN's key compromise or disaster recovery
procedures will be enacted as described in section 4.5.4 and 4.5.3.
Ljunggren, et al. [Page 22]
Root Zone KSK Operator DPS May 2010
4.5.3. Entity private key compromise procedures
4.5.3.1. Key Signing Key compromise
ICANN has established and maintains Emergency KSK roll-over
procedures to ensure readiness for key compromise situations.
Upon the suspected or known compromise of a Root Zone Key Signing
Key, IKOS will assess the situation, develop an appropriate action
plan, and implement the action plan with approval from the PMA and
ICANN executive management.
As part of the KSK emergency roll-over procedures, ICANN maintains
the capability of being able to generate and publish an interim Trust
Anchor within 48 hours. In favorable circumstances, this interim
Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011]
automatic KSK roll-over to a new and sanctioned Trust Anchor
generated at a new scheduled key ceremony, held within reasonable
time.
ICANN will inform the community of any emergency as soon as possible
using the channels stipulated in section 2.1.
4.5.3.2. Key Signing Key loss
If the private component of a Trust Anchor is permanently lost, the
latest point in time where this loss is detected, will inevitably be
at the key ceremony when it is supposed to be used. At this point in
time, the Root Zone Maintainer/ZSK Operator has signatures for at
least 33 days (see 6.6) of independent operations.
If possible, a new KSK will be generated at this key ceremony or
another ceremony scheduled within 48 hours. If ICANN is unable to
accommodate the key ceremony, an interim KSK must be generated by
ICANN and published as a Trust Anchor within the stipulated 48 hours.
The community is then given a minimum of 30 days notice to add the
new Trust Anchors to the validating resolvers before the DNSKEY RRset
has to be re-signed with the new Trust Anchor. Failure to update a
validating resolver will render that resolver inoperable.
ICANN will inform the community of any emergency as soon as possible
using the channels stipulated in section 2.1.
The old Trust Anchor will remain untouched in the key set for one 10
days time slot (see section Section 6.6). In the next consecutive
time slot, the old Trust Anchor will be marked as revoked, and after
this time slot the lost key is permanently removed.
Ljunggren, et al. [Page 23]
Root Zone KSK Operator DPS May 2010
4.5.3.3. Zone Signing Key Compromise
ICANN will support Root Zone Zone Signing Key emergency rollover in
the case of RZ ZSK compromise while following VeriSign's procedural
directions. Refer to the Root Zone ZSK Operator's DPS for details.
4.5.4. Business Continuity and IT Disaster Recovery Capabilities
ICANN has implemented at least two fully-functional, geographically
and logically dispersed sites, which at any point in time hold the
data required for production, and are evenly utilized. All sites
implements the same physical security protections and operational
controls as specified in 4.1.2.
ICANN has developed, implemented and tested a business continuity and
IT disaster recovery plan to mitigate the effects of natural, man-
made, or technological disasters or other disasters that requires
temporary or permanent cessation of operations from any of ICANN's
facilities. The business continuity and IT disaster recovery plans
are in place to address the restoration of information systems
services and key business functions. These plans address:
o Roles and responsibilities in the event of a disaster.
o Fallback procedures for restoring business-critical processes
within acceptable times.
o Resumption procedures for restoring normal operations.
o The criteria for activating the plan.
ICANN maintains the capability to restore or recover essential
operations within 48 hours following a disaster with support for at
minimum the following functions:
o Communication with the public.
o Ability to import KSRs (Key Signing Requests) and export SKRs
(Signed Key Responses).
o Generation of Key Signing Keys.
o Processing and signing of KSR contents.
o Publishing the Trust Anchor.
ICANN maintains redundant hardware and backups of its infrastructure
system software at all sites. In addition, private keys are backed
up and maintained in accordance with DPS section 5.2.4, and in such a
way that critical keying material is distributed to all sites before
put into production.
ICANN's business continuity and IT disaster recovery plans have been
designed to provide full recovery within one week at the alternative
site following any incident or disaster occurring at any of ICANN's
Ljunggren, et al. [Page 24]
Root Zone KSK Operator DPS May 2010
sites.
When possible, operational status is restored as soon as possible
following any incident or disaster.
These plans are regularly tested, validated, and updated to be
operational in the event of any incident or disaster. Results of
such tests are reviewed and kept for audit and planning purposes.
4.6. Entity termination
ICANN has implemented a DNSSEC termination plan in the event that the
roles and responsibilities of the Root Zone KSK Operator must
transition to other entities. ICANN will co-ordinate with the Root
Zone Maintainer, Root Zone ZSK Operator and DoC in order to execute
the transition in a secure and transparent manner.
The DNSSEC termination plan also includes procedures in the event of
the termination of the Root Zone Maintainer and/or Root Zone ZSK
Operator.
5. TECHNICAL SECURITY CONTROLS
5.1. Key Pair Generation and Installation
5.1.1. Key pair generation
Root Zone (RZ) Key Signing Key (KSK) key pair generation is performed
by multiple pre-selected, trained and trusted individuals using
Trustworthy Systems and processes that provide for the security and
required cryptographic strength for the generated keys.
All KSK key pairs are generated in pre-planned Key Generation
Ceremonies in accordance with the requirements of the Key Ceremony
Reference Guide. The activities performed in each key generation
ceremony are recorded, dated and signed by the Ceremony
Administrator. These records are kept for audit and tracking
purposes as required in section 4.4.3.
5.1.2. Public key delivery
The public component of a Trust Anchor will be distributed in a
secure fashion to preclude substitution attacks.
Acceptable methods for delivery and validation of Trust Anchors
include, but are not limited to:
Ljunggren, et al. [Page 25]
Root Zone KSK Operator DPS May 2010
o In-band as zone data in DNSKEY RRset, with proof traceable to the
previous Trust Anchor as described in RFC 5011 [RFC5011].
o Publication of the Trust Anchor on ICANN's web site, protected and
authenticated via TLS/SSL, while also providing detached OpenPGP
[RFC4880], S/MIME [RFC5751] and other signatures traceable to
ICANN and optionally other parties.
o Proof distributed out-of-band directly to the witnesses
participating at the key ceremony, whereas distribution to their
respective communities is at the witness' own discretions.
5.1.3. Public key parameters generation and quality checking
For the current key size, primality testing of RSA parameters (p and
q) will be performed to ensure with a probability less than 2^-100
that the numbers are not composite.
Quality checking will also include validating the size of the public
exponent to be both resource efficient and secure.
5.1.4. Key usage purposes
Any root zone KSK private key will only be used for signing the root
zone's DNSKEY RRset or self-signing using the same padding scheme in
order to prove possession of the private key.
Any RRSIG record generated as a result of a KSK signing operation
will not have a validity period longer than 15 days, and will never
expire more than 180 days in the future.
5.2. Private key protection and Cryptographic Module Engineering
Controls
All cryptographic functions involving the private component of the
KSK are performed within the HSM; that is, the private component will
not be exported from the HSM except in encrypted form for purposes of
key backup.
5.2.1. Cryptographic module standards and controls
For RZ KSK generation and RZ KSK private component operations and
storage, ICANN uses hardware security modules that are validated at
FIPS 140-2 level 4 overall.
5.2.2. Private key (m-of-n) multi-person control
ICANN has implemented technical and procedural mechanisms that
require the participation of multiple trusted individuals to perform
sensitive cryptographic operations. ICANN splits activation data
Ljunggren, et al. [Page 26]
Root Zone KSK Operator DPS May 2010
needed to make use of the RZ KSK private key onto separate smartcards
controlled by trusted individuals (crypto officers) selected from
members of the Internet community not already part of root zone
management operations. Specifically, organizationally separate
parties, not affiliated with ICANN, VeriSign, or the U.S. Department
of Commerce. Refer to "Trusted Community Representatives - Proposed
Approach to Root Key Management" for details.
A threshold number of smartcards (m) out of the total number of
smartcards created and distributed for a particular hardware security
module (n) is required to activate a RZ KSK private key stored on the
module. The threshold number of cards needed to sign using the RZ
KSK is three out of seven. The smartcards are protected in
accordance with Section 5.4.2.
5.2.3. Private key escrow
Private components of Root Zone Key Signing Keys are not escrowed.
5.2.4. Private key backup
Encrypted copies of the RZ KSK private key(s) are backed up onto
portable media held by ICANN and sent by courier to the other
facilities. The key used to encrypt the private key(s) is backed up
using a five out of seven threshold scheme with smartcards
distributed to trusted individuals (recovery key share-holders)
selected from members of the Internet community not already part of
root zone management operations. Specifically, organizationally
separate parties, not affiliated with ICANN, VeriSign, or the U.S.
Department of Commerce. The recovery key share holders keep the
cards in tamper-evident bags, stored in geographically dispersed
locations under their control. Refer to "Trusted Community
Representatives - Proposed Approach to Root Key Management" for
details.
5.2.5. Private key storage on cryptographic module
Private keys held on hardware cryptographic modules are stored in
encrypted form.
5.2.6. Private key archival
The private half of the RZ KSK key pair is not archived after
rollover. This eliminates the possibility of its misuse in RZ KSK
rollover or revocation after its suppression.
Ljunggren, et al. [Page 27]
Root Zone KSK Operator DPS May 2010
5.2.7. Private key transfer into or from a cryptographic module
ICANN generates RZ KSK key pairs on the hardware security modules in
which the keys will be used. In addition, ICANN makes copies of
these key pairs for routine recovery and disaster recovery purposes.
When key pairs are backed up to another hardware security module,
these key pairs are transported between modules in encrypted form.
5.2.8. Method of activating private key
The RZ KSK private key will be activated using three out of seven
crypto officer controlled smartcards that must be inserted into the
HSM, one at a time, while entering the crypto officers' PIN.
5.2.9. Method of deactivating private key
ICANN RZ KSK private keys are deactivated upon system shutdown.
5.2.10. Method of destroying private key
When required, ICANN destroys RZ KSK private keys in a manner that
reasonably ensures that there are no residual remains of the keys
that could lead to the reconstruction of the keys. ICANN utilizes
the zeroization function of its hardware security modules and other
appropriate means to ensure the complete destruction of RZ KSK
private keys. When performed, private key destruction activities are
logged as part of a key ceremony.
5.3. Other Aspects of Key Pair Management
5.3.1. Public key archival
RZ KSK public keys are backed up and archived.
5.3.2. Key usage periods
The Operational Period of a RZ KSK ends upon its supersession. The
superseded RZ KSK will never be reused to sign a resource record
while in retention.
5.4. Activation data
5.4.1. Activation data generation and installation
Activation data used to protect access to hardware security modules
(HSM) containing RZ KSK private keys is generated in accordance with
the requirements of DPS section 5.1 and the Key Ceremony Reference
Guide. The creation and distribution of these smartcards and/or
Ljunggren, et al. [Page 28]
Root Zone KSK Operator DPS May 2010
access to them is logged.
5.4.2. Activation data protection
Crypto Officers are required to safeguard the credentials needed to
access activation data.
When required, activation data will be decommissioned using methods
that protect against the loss, theft, modification, unauthorized
disclosure, or unauthorized use of the private keys protected by this
activation data.
5.4.3. Other aspects of activation data
The crypto officers hold a key to a safety box inside a safe in the
ICANN safe room. In this box both the card and the PIN are stored in
tamper-evident bags with individual IDs. It is the crypto officers'
responsibility to safeguard and store this physical key between key
ceremonies.
5.5. Computer Security Controls
ICANN ensures that the systems maintaining key software and data
files are Trustworthy Systems secure from unauthorized access. In
addition, ICANN limits access to production servers to those
individuals with a valid business reason for such access. General
application users do not have accounts on production servers.
5.6. Network Security Controls
No part of the signer system making use of the HSM is connected to
any communications network. Communication of ZSK key signing
requests (KSR) from the Root Zone Maintainer/ZSK Operator is done
using a TLS client-side authenticated web server connected to ICANN's
production network. Transfer of a KSR from the web server to the
signer system is performed manually using removable media (refer to
Section 6.7 for further details on verification of the KSR).
ICANN's production network is logically separated from other
components. This separation prevents network access except through
defined application processes. ICANN uses firewalls to protect the
production network from internal and external intrusion and limit the
nature and source of network activities that may access production
systems that are related to key signing activities.
Ljunggren, et al. [Page 29]
Root Zone KSK Operator DPS May 2010
5.7. Timestamping
Time will be derived through a manual procedure before each key
ceremony. The ceremony administrator will manually set the signer
system clock and the wall clock to current UTC time drawn from a
reliable time source.
Time derived from the procedure will be used for timestamping of
o electronic and paper based audit log records
o DNSSEC signatures expiration- and inception times
Asserted times are required to be accurate within three minutes.
5.8. Life Cycle Technical Controls
5.8.1. System development controls
ICANN's Software Development Life-Cycle (SDLC) procedures for the
Root Zone KSK key generation and signer software implements relevant
parts of NIST SP 800-64 for incorporating security and
trustworthiness into the SDLC.
In addition, all critical parts of the signers modules developed by
ICANN will be subject to external code review. The code review is
required to certify that:
o There is a documented architectural design describing the security
domains and functions maintained by the signer.
o The architectural design demonstrates that the signer system
prevents bypass of the security-enforcing functionality.
o There is a functional specification completely representing the
signer system and all operations associated with it.
o There is a modular design description and a one-to-one
correspondence with the modular decomposition of the
implementation.
o The implementation representation completely and accurately
implements the security-enforcing functions.
ICANN developed software, when first loaded, provides a method to
verify that the software on the system originated from ICANN, has not
been modified prior to installation, and is the version intended for
use.
5.8.2. Security management controls
ICANN has mechanisms in place to control and monitor the
configuration of its systems. ICANN creates a hash of all software
Ljunggren, et al. [Page 30]
Root Zone KSK Operator DPS May 2010
packages and ICANN software updates. This hash is used to verify the
integrity of such software manually. Upon installation and
periodically thereafter, ICANN validates the integrity of its
systems.
5.8.3. Life cycle security controls
The signer system is designed to require a minimum of maintenance.
Updates critical to the security and operations of the signer system
will be applied after formal testing and approval. The origin of all
software and firmware will be securely authenticated by available
means.
Critical hardware components of the signer system will be procured
directly from the manufacturer and transported in tamper-evident bags
to their destination in the secure facility. Any hardware will be
decommissioned well before the specified life expectancy.
6. ZONE SIGNING
The IANA Functions Operator (ICANN) provides the Root Zone Maintainer
(VRSN) with signed and valid DNSSEC RRset for the Root Zone ZSK
Operator's current keys and the KSKs.
The Root Zone Maintainer includes this keyset into the Root Zone
file, adds the Next Secure resource records (NSEC), and creates
signatures for all relevant records. The Root Zone is then
distributed to the Root Server Operators.
The daily Root Zone signing will be conducted semi-automatically by
the system. It is not fully automatic since the interface with the
IANA Functions operator is currently manual.
6.1. Key lengths and algorithms
Key pairs are required to be of sufficient length to prevent others
from determining the key pair's private key using crypto-analysis
during the period of expected utilization of such key pairs.
The current RZ KSK key pair(s) is an RSA key pair, with a modulus
size of 2048 bits.
6.2. Authenticated denial of existence
Authenticated denial of existence will be provided through the use of
NSEC resource records as specified in RFC 4034 [RFC4034].
Ljunggren, et al. [Page 31]
Root Zone KSK Operator DPS May 2010
6.3. Signature format
The cryptographic hash function used in conjunction with the signing
algorithm is required to be sufficiently resistant to preimage
attacks during the time in which the signature is valid.
The RZ KSK signatures will be generated by encrypting SHA-256 hashes
using RSA [RFC5702].
6.4. Zone signing key roll-over
ZSK rollover is carried out quarterly automatically by the Root Zone
ZSK Operator's system as described in the Root Zone ZSK Operator's
DPS.
6.5. Key signing key roll-over
Each RZ KSK will be scheduled to be rolled over through a key
ceremony as required, or after 5 years of operation.
RZ KSK roll-over is scheduled to facilitate automatic updates of
resolvers' Trust Anchors as described in RFC 5011 [RFC5011].
After a RZ KSK has been removed from the key set, it will be retained
after its operational period until the next scheduled key ceremony,
when the private component will be destroyed in accordance with
section 5.2.10.
6.6. Signature life-time and re-signing frequency
The signing practice of the Root Zone is divided into quarterly
continuous time cycles of approximately 90 days. Time cycles begin
on the following dates each year:
January 1st
April 1st
July 1st
October 1st
For each of these time cycles there is a key ceremony scheduled
approximately 60 days but no later than 33 days, before the time
cycle commences. At this key ceremony, all of the necessary RZ KSK
operations are performed to enable the Root Zone Maintainer to
operate and publish the zone independently throughout the period.
To facilitate automatic updates of resolvers' Trust Anchors as
described in RFC 5011 [RFC5011] while minimizing the number of keys
in the key set, each of the ~90 day time cycles is divided into 10
Ljunggren, et al. [Page 32]
Root Zone KSK Operator DPS May 2010
day slots (9 slots).
The time cycle will never last less than 90 days. If the time cycle
is more than 90 days, the last slot in the cycle will be expanded to
fill the period.
For each of these slots there is a pre-generated DNSKEY key set that
is signed at the key ceremony with 15 days validity time to allow for
up to 50% overlap. The Root Zone Maintainer is responsible for
selecting the current key set and publishing it with the
corresponding valid signature.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
RRSIG 1 |---->|
RRSIG 2 |---->|
RRSIG 3 |---->|
RRSIG 4 |---->|
RRSIG 5 |---->|
RRSIG 6 |---->|
RRSIG 7 |---->|
RRSIG 8 |---->|
RRSIG 9 |---->|
DNSKEY RRSIG's validity period within the cycle
Figure 1
The Root Zone Maintainer may use slots at the edge of every time
cycle for pre- and post-publishing at RZ ZSK roll-overs.
Ljunggren, et al. [Page 33]
Root Zone KSK Operator DPS May 2010
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
ZSK n-1 ===|-->|
ZSK n ---|===================================|--->
ZSK n+1 |---|===>
KSK n ===========================|---|++>|
KSK n+1 |-------------------|===============>
(-) post- or pre-publish
(+) revoke bit set
(=) used for signing
90 day cycle with ZSK and KSK roll over
Figure 2
In the event of a RZ KSK roll-over and RZ ZSK roll-over in the same
cycle, time slots are used for pre- and post-publishing, adding and
deleting Trust Anchors in the following order:
Slot 1:
publish ZSK (n) + ZSK (n-1) + KSK (n), sign DNSKEY RRset with
KSK(n)
Slot 2-6:
publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with
KSK(n)
Slot 7:
publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with
KSK(n+1)
Slot 8:
publish ZSK (n) + KSK (n+1) + revoked KSK (n), sign DNSKEY
RRset with KSK(n+1)
Slot 9:
publish ZSK (n) + ZSK (n+1) + KSK (n+1), sign DNSKEY RRset with
KSK(n+1)
At each publication, the Root Zone Maintainer selects and includes
the current key set and corresponding signature(s), and then signs
all other authoritative records within the root zone using the
current RZ ZSK.
6.7. Verification of zone signing key set
Each key set within the Key Signing Request (KSR) is self-signed with
the active key to provide proof of possession of the corresponding
private key. The signer system will automatically validate this
Ljunggren, et al. [Page 34]
Root Zone KSK Operator DPS May 2010
signature and perform checking of available parameters before
accepting the KSR for signing.
The RZ KSK Operator will verify the authenticity of the KSR document
by performing an out-of-band verification (verbally over the phone,
by fax, or any other available method) of the hash of the KSR, before
entering the KSR into the signer system. The resulting Signed Key
Response (SKR) is transferred back using the same TLS client-side
authenticated connection used to receive the KSR from the Root Zone
Maintainer.
6.8. Verification of resource records
Signature verification will be performed on the signer system that
holds both the signed and the unsigned keyset prior to the
compilation of the SKR. Integrity of the signatures in the SKR is
verified by the RZ ZSK Operator using the published RZ TA.
6.9. Resource records time-to-live
+------------------------+---------------------------------+
| RRtype | TTL |
+------------------------+---------------------------------+
| DNSKEY | 48 hours |
| NSEC | same as SOA minimum (24 hours) |
| Delegation Signer (DS) | 24 hours |
| RRSIG | same as the covered RR (varies) |
+------------------------+---------------------------------+
7. COMPLIANCE AUDIT
An annual SysTrust audit for DNSSEC operations examination is
performed for ICANN's Root Zone Zone Signing services, including the
RZ KSK management.
7.1. Frequency of entity compliance audit
Compliance Audits are conducted at least annually at the sole expense
of the audited entity.
7.2. Identity/qualifications of auditor
ICANN's compliance audits are performed by a public accounting firm
that demonstrates proficiency in:
Ljunggren, et al. [Page 35]
Root Zone KSK Operator DPS May 2010
o DNSSEC public key infrastructure technology
o information security tools and techniques
o security auditing
o the third-party attestation function
and is accredited by the American Institute of Certified Public
Accountants (AICPA), which requires the possession of certain skill
sets, quality assurance measures such as peer review, competency
testing, standards with respect to proper assignment of staff to
engagements, and requirements for continuing professional education.
7.3. Auditor's relationship to audited party
Compliance audits of ICANN's operations are performed by a public
accounting firm that is independent of ICANN, VeriSign and the
auditor of VeriSign. Third party auditors do not participate in the
multi-person control for the RZ KSK.
7.4. Topics covered by audit
The scope of ICANN's annual Compliance Audit includes all DNSSEC
related procedures such as key environmental controls, key management
operations, infrastructure/administrative controls, RZ KSK and
signature life cycle management and practices disclosures.
7.5. Actions taken as a result of deficiency
With respect to compliance audits of ICANN's operations, significant
exceptions or deficiencies identified during the Compliance Audit
will result in a determination of actions to be taken. Such
determinations are made by ICANN management with input from the
auditor and DoC. ICANN management is responsible for developing and
implementing a corrective action plan. If ICANN or the DoC
determines that such exceptions or deficiencies pose an immediate
threat to the security or integrity of the RZ KSK, a corrective
action plan will be developed within 30 days and implemented within a
commercially reasonable period of time. For less serious exceptions
or deficiencies, ICANN Management will evaluate the significance of
such issues and determine the appropriate course of action with DoC
authorization.
7.6. Communication of results
A copy of ICANN's Compliance Audit report and Management's Assertion
letter can be found at https://www.iana.org/dnssec
Ljunggren, et al. [Page 36]
Root Zone KSK Operator DPS May 2010
8. LEGAL MATTERS
8.1. Fees
No fees are charged for acceptance, signing and publishing of
Delegation Signer resource records, or any other function related to
DNSSEC.
8.2. Financial responsibility
ICANN accepts no financial responsibility for improper use of Trust
Anchors or signatures issued under this DPS.
8.3. Confidentiality of business information
8.3.1. Scope of confidential information
The following records shall be kept confidential and private
(Confidential/Private Information):
o Private keys and information needed to recover such private keys
o Signatures of key sets to be published in the future
o Transactional records (both full records and the audit trail of
transactions)
o Audit trail records created or retained by ICANN or VeriSign
o Audit reports created by ICANN or VeriSign (to the extent such
reports are maintained), or their respective auditors (whether
internal or public), until such reports are made public
o Contingency planning and disaster recovery plans
o Security measures controlling the operations of ICANN hardware and
software and the administration of DNS Keys
8.3.2. Information not within the scope of confidential information
All information pertaining to the database of top-level domains is
public information, such as Public Keys, Key Revocation information,
and other status information. ICANN repositories and information
contained within them are not considered Confidential/Private
Information.
8.3.3. Responsibility to protect confidential information
Not applicable
8.4. Privacy of personal information
Ljunggren, et al. [Page 37]
Root Zone KSK Operator DPS May 2010
8.4.1. Information treated as private
Not applicable
8.4.2. Types of information not considered private
Not applicable
8.4.3. Responsibility to protect private information
Not applicable
8.4.4. Disclosure Pursuant to Judicial or Administrative Process
ICANN shall be entitled to disclose Confidential/Private Information
if, in good faith, ICANN believes that disclosure is necessary in
response to judicial, administrative, or other legal process during
the discovery process in a civil or administrative action, such as
subpoenas, interrogatories, requests for admission, and requests for
production of documents.
8.5. Limitations of liability
ICANN shall not be liable for any financial loss, or loss arising
from incidental damage or impairment, resulting from its performance
of its obligations hereunder. No other liability, implicit or
explicit, is accepted.
8.6. Term and termination
8.6.1. Term
The DPS becomes effective upon publication in the ICANN repository.
Amendments to this DPS become effective upon publication in the ICANN
repository.
8.6.2. Termination
This DPS as amended from time to time and will remain in force until
it is replaced by a new version.
8.6.3. Dispute resolution provisions
Disputes among DNSSEC participants shall be resolved pursuant to
provisions in the applicable agreements among the parties.
Ljunggren, et al. [Page 38]
Root Zone KSK Operator DPS May 2010
8.6.4. Governing law
This DPS shall be governed by the laws of the State of California.
9. References
9.1. Normative References
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
9.2. Informative References
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
Appendix A. Table of acronyms and definitions
A.1. Acronyms
+--------+----------------------------------------------------------+
| Term | Definition |
+--------+----------------------------------------------------------+
| AD | Authenticated Data Flag |
| AICPA | American Institute of Certified Public Accountants |
| BIND | Berkley Internet Name Domain |
| CC | Common Criteria |
| CD | Checking Disabled |
| DNS | Domain Name System |
| DNSKEY | Domain Name System Key |
| DNSSEC | Domain Name System Security Extensions |
| DO | DNSSEC OK |
| DoC | Department of Commerce |
| DPS | DNSSEC Policy and Practices Statement |
Ljunggren, et al. [Page 39]
Root Zone KSK Operator DPS May 2010
| DS | Delegation Signer |
| EAL | Evaluation Assurance Level (pursuant to the Common |
| | Criteria) |
| FIPS | Federal Information Processing Standards |
| FISMA | Federal Information Security Management Act |
| HSM | Hardware Security Module |
| IANA | Internet Assigned Numbers Authority |
| ICANN | Internet Corporation for Assigned Names and Numbers |
| IETF | Internet Engineering Task Force |
| IKOS | ICANN KSK Operations Security |
| ISO | International Organization for Standardization |
| NIST | National Institute of Standardization of Technology |
| NS | Name Server |
| NSEC | NextSecure |
| NSEC3 | Hashed NextSecure |
| NTIA | National Telecommunications and Information |
| | Administration of the U.S. Department of Commerce. |
| PKI | Public Key Infrastructure |
| PMA | Policy Management Authority |
| RFC | Request for Comments |
| RZ | Root Zone |
| KSKO | Key Signing Key Operator |
| RRSIG | Resource Record Signature |
| RZMS | Root Zone Management System |
| SEP | Secure Entry Point |
| SHA | Secure Hash Algorithm |
| SKR | Signed Key Responses |
| SOA | Start of Authority |
| SP | NIST Special Publication |
| TA | Trust Anchor |
| TLD | Top Level Domain |
| TSIG | Transaction Signature |
| TTL | Time To Live |
| VERT | VeriSign Emergency Response Team |
| VSIRT | VeriSign Security Incident Response Team |
| ZSKO | Zone Signing Key Operator |
+--------+----------------------------------------------------------+
Ljunggren, et al. [Page 40]
Root Zone KSK Operator DPS May 2010
A.2. Definitions
+----------------------+--------------------------------------------+
| Term | Definition |
+----------------------+--------------------------------------------+
| Chain of Trust | DNS keys, signatures and delegation signer |
| | records linked together forming a chain of |
| | signed data. |
| Compromise | A violation (or suspected violation) of a |
| | security policy, in which an unauthorized |
| | disclosure of, or loss of control over, |
| | sensitive information may have occurred. |
| | With respect to private keys, a compromise |
| | is a loss, theft, disclosure, |
| | modification, unauthorized use, or other |
| | compromise of the security of such private |
| | key. |
| Compliance Audit | A periodic audit that a Processing Center, |
| | Service Center, Managed PKI Customer, or |
| | Gateway Customer undergoes to determine |
| | its conformance with standards that apply |
| | to it. |
| Confidential/Private | Information required to be kept |
| Information | confidential and private. |
| Delegation Signer | Delegation Signer is one of the resource |
| (DS) | records indicating that the delegated zone |
| | is digitally signed. It also assures that |
| | the parent zone recognizes the indicated |
| | key for the delegated zone. |
| Hardware Security | A type of secure cryptoprocessor aimed at |
| Module (HSM) | managing cryptographic keys and |
| | cryptographic operations while providing |
| | physical protection of the private keying |
| | material through tamper protecting |
| | mechanisms. |
| ICANN KSK Operations | A security support and coordination role |
| Security | within ICANN, with the required security |
| | experience and skills to i.a. provide |
| | security-related advice to the PMA, follow |
| | up on incident reporting, provide |
| | assistance to the external auditors, |
| | conduct internal audits, initiate |
| | security-awareness activities, provide |
| | security training and maintain the |
| | Information Security Management System. |
Ljunggren, et al. [Page 41]
Root Zone KSK Operator DPS May 2010
| Intellectual | Rights under one or more of the following: |
| Property Rights | any copyright, patent, trade secret, |
| (IPR) | trademark, and any other intellectual |
| | property rights. |
| Island of Security | A signed zone that does not have a chain |
| | of trust from the parent zone. |
| Key Generation | A procedure whereby a key pair is |
| Ceremony | generated, its private key is transferred |
| | into a cryptographic module, its private |
| | key is backed up, and/or key sets are |
| | signed. |
| Key Signing Key | A key that signs the key set. |
| (KSK) | |
| Management Review | Compliance Audit of the entity or as part |
| | of the overall risk management process in |
| | the ordinary course of business. |
| Offline HSM | HSMs that are maintained offline for |
| | security reasons in order to protect them |
| | from possible attacks by intruders by way |
| | of the network. These HSMs do not |
| | directly sign. |
| Online HSM | HSMs that sign the Zone file under the |
| | Zone Signing Key are maintained online so |
| | as to provide continuous signing services. |
| Parent Zone | The zone that is one level higher in the |
| | DNS hierarchy. |
| Policy Management | The office within ICANN responsible for |
| Authority (PMA) | promulgating the DPS. |
| Public Key | The architecture, organization, |
| Infrastructure | techniques, practices, and procedures that |
| | collectively support the implementation |
| | and operation of a public key |
| | cryptographic system. |
| Regulated Financial | A financial institution that is regulated, |
| Institution | supervised, and examined by governmental, |
| | national, state or provincial, or local |
| | authorities having regulatory authority |
| | over such financial institution based on |
| | the governmental, national, state or |
| | provincial, or local laws under which such |
| | financial institutions was organized |
| | and/or licensed. |
| Resource Record | Signature data in the zone file. |
| Signature (RRSIG) | |
| RSA | A public key cryptographic system invented |
| | by Ron Rivest, Adi Shamir, and Leonard |
| | Adleman. |
Ljunggren, et al. [Page 42]
Root Zone KSK Operator DPS May 2010
| Root Zone Management | A system used to automate the Root Zone |
| System (RZMS) | update process. |
| Secret Share | A portion of a private key or a portion of |
| | the activation data needed to operate a |
| | private key under a Secret Sharing |
| | arrangement. |
| SysTrust Assurance | SysTrust is an assurance service developed |
| | by the American Institute of Certified |
| | Public Accountants (AICPA) and the |
| | Canadian Institute of Chartered |
| | Accountants (CICA). SysTrust is designed |
| | primarily to build trust and confidence |
| | among businesses depending on systems, |
| | addressing areas such as security, |
| | availability, confidentiality, and |
| | processing integrity. |
| Supplemental Risk | A review of an entity by ICANN following |
| | incomplete or exceptional findings in a |
| | Compliance Audit of the entity or as part |
| | of the overall risk management process in |
| | the ordinary course of business. |
| Trust Anchor | A trust anchor is an authoritative entity |
| | represented via a public key. It is used |
| | in the context of public key |
| | infrastructures, X.509 digital |
| | certificates and DNSSEC. |
| Trusted Role | The roles within the DNSSEC operations |
| | that must be held by a Trusted Person. |
| Trusted Person | Personnel assigned to a Trusted Role who |
| | have successfully completed a a |
| | comprehensive background investigation as |
| | defined in Section 4.3.2, which indicates |
| | their ability to maintain the level of |
| | trust necessary for critical DNSSEC |
| | operations. |
| Trusted Status | Trusted Status is achieved by a person who |
| | have successfully completed the screening |
| | requirements for Trusted Roles set out in |
| | this DPS. |
| VeriSign | Means, with respect to each pertinent |
| | portion of this, VeriSign, Inc. and/or any |
| | wholly owned VeriSign subsidiary |
| | responsible for the specific operations at |
| | issue. |
| Repository | DNSSEC-related information made accessible |
| | online. |
| Zone | A boundary of responsibility for each |
| | domain. |
Ljunggren, et al. [Page 43]
Root Zone KSK Operator DPS May 2010
| Zone Signing Key | A key that signs the Root Zone |
| (ZSK) | |
+----------------------+--------------------------------------------+
Appendix B. History of changes
+---------------------------+-------------+
| Section | Description |
+---------------------------+-------------+
| Creation of first Edition | N/A |
+---------------------------+-------------+
Authors' Addresses
Fredrik Ljunggren
Kirei AB
P.O. Box 53204
Goteborg SE-400 16
Sweden
Email: fredrik@kirei.se
Tomofumi Okubo
VeriSign Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
Email: tookubo@verisign.com
Richard Lamb
Internet Corporation For Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Ray, CA 90292
USA
Email: richard.lamb@icann.org
Ljunggren, et al. [Page 44]
Root Zone KSK Operator DPS May 2010
Jakob Schlyter
Kirei AB
P.O. Box 53204
Goteborg SE-400 16
Sweden
Email: jakob@kirei.se
Ljunggren, et al. [Page 45]
Presently we were in a very dark road, and at a point where it dropped suddenly between steep sides we halted in black shadow. A gleam of pale sand, a whisper of deep flowing waters, and a farther glimmer of more sands beyond them challenged our advance. We had come to a "grapevine ferry." The scow was on the other side, the water too shoal for the horses to swim, and the bottom, most likely, quicksand. Out of the blackness of the opposite shore came a soft, high-pitched, quavering, long-drawn, smothered moan of woe, the call of that snivelling little sinner the screech-owl. Ferry murmured to me to answer it and I sent the same faint horror-stricken tremolo back. Again it came to us, from not farther than one might toss his cap, and I followed Ferry down to the water's edge. The grapevine guy swayed at our side, we heard the scow slide from the sands, and in a few moments, moved by two videttes, it touched our shore. Soon we were across, the two videttes riding with us, and beyond a sharp rise, in an old opening made by the swoop of a hurricane, we entered the silent unlighted bivouac of Ferry's scouts. Ferry got down and sat on the earth talking with Quinn, while the sergeants quietly roused the sleepers to horse. Plotinus is driven by this perplexity to reconsider the whole theory of Matter.477 He takes Aristotle¡¯s doctrine as the groundwork of his investigation. According to this, all existence is divided into Matter and Form. What we know of things¡ªin other words, the sum of their differential characteristics¡ªis their Form. Take away this, and the unknowable residuum is their Matter. Again, Matter is the vague indeterminate something out of which particular Forms are developed. The two are related as Possibility to Actuality, as the more generic to the more specific substance through every grade of classification and composition. Thus there are two Matters, the one sensible and the other intelligible. The former constitutes the common substratum of bodies, the other the common element of ideas.478 The general distinction between Matter and Form was originally suggested to Aristotle by Plato¡¯s remarks on the same subject; but he differs325 from his master in two important particulars. Plato, in his Timaeus, seems to identify Matter with space.479 So far, it is a much more positive conception than the ?λη of the Metaphysics. On the other hand, he constantly opposes it to reality as something non-existent; and he at least implies that it is opposed to absolute good as a principle of absolute evil.480 Thus while the Aristotelian world is formed by the development of Power into Actuality, the Platonic world is composed by the union of Being and not-Being, of the Same and the Different, of the One and the Many, of the Limit and the Unlimited, of Good and Evil, in varying proportions with each other. The Lawton woman had heard of an officer's family at Grant, which was in need of a cook, and had gone there. [See larger version] On the 8th of July an extraordinary Privy Council was summoned. All the members, of whatever party, were desired to attend, and many were the speculations as to the object of their meeting. The general notion was that it involved the continuing or the ending of the war. It turned out to be for the announcement of the king's intended marriage. The lady selected was Charlotte, the second sister of the Duke of Mecklenburg-Strelitz. Apart from the narrowness of her education, the young princess had a considerable amount of amiability, good sense, and domestic taste. These she shared with her intended husband, and whilst they made the royal couple always retiring, at the same time they caused them to give, during their lives, a moral air to their court. On the 8th of September Charlotte arrived at St. James's, and that afternoon the marriage took place, the ceremony being performed by the Archbishop of Canterbury. On the 22nd the coronation took place with the greatest splendour. Mother and girls were inconsolable, for each had something that they were sure "Si would like," and would "do him good," but they knew Josiah Klegg, Sr., well enough to understand what was the condition when he had once made up his mind. CHAPTER V. THE YOUNG RECRUITS Si proceeded to deftly construct a litter out of the two guns, with some sticks that he cut with a knife, and bound with pawpaw strips. His voice had sunk very low, almost to sweetness. A soft flurry of pink went over her face, and her eyelids drooped. Then suddenly she braced herself, pulled herself taut, grew combative again, though her voice shook. HoME²Ô¾®Ïè̫ʲôÐÇ×ù
ENTER NUMBET 0016kmbffl.com.cn
goqrnz.com.cn
www.fzqplscd.com.cn
scchain.com.cn
mlsfs.com.cn
www.mlcygs.org.cn
uohhfg.com.cn
www.taipot.com.cn
www.qurong123.com.cn
www.xfhypy.com.cn