Secure Inter-Domain Routing G. Huston
Internet-Draft R. Loomans
Intended status: BCP G. Michaelson
Expires: April 14, 2011 APNIC
October 11, 2010
A Profile for Resource Certificate Repository Structure
draft-ietf-sidr-repos-struct-05.txt
Abstract
This document defines a profile for the structure of repository
publication points that contain X.509 / PKIX Resource Certificates,
Certificate Revocation Lists and signed objects. This profile
contains the proposed object naming scheme, the contents of
repository publication points, and a suggested internal structure of
a local repository cache that is intended to facilitate
synchronisation across a distributed collection of repository
publication points and facilitate certification path construction.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Huston, et al. Expires April 14, 2011 [Page 1]
Internet-Draft ResCert Respository Structure October 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. RPKI Repository Publication Point Content and Structure . . . 4
2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. CA Repository Publication Points . . . . . . . . . . . . . 6
2.3. Multi-Use EE Repository Publication Points . . . . . . . . 8
3. Resource Certificate Publication Repository Considerations . . 9
4. Certificate Reissuance and Repositories . . . . . . . . . . . 11
5. Synchronising Repositories with a Local Cache . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Huston, et al. Expires April 14, 2011 [Page 2]
Internet-Draft ResCert Respository Structure October 2010
1. Introduction
To validate attestations made in the context of the Resource Public
Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], relying parties (RPs)
need access to all the X.509 / PKIX Resource Certificates,
Certificate Revocation Lists (CRLs), and signed objects that
collectively define the RPKI.
Each issuer of a certificate, CRL or a signed object makes it
available for download to RPs through the publication of the object
in an RPKI repository.
The repository system is the central clearing-house for all signed
objects that MUST be globally accessible to all RPs. When
certificates, CRLs and signed objects are created, they are uploaded
to a repository publication point, from whence they can be downloaded
for use by RPs.
This document defines a profile for the structure of RPKI
repositories. This profile defines the proposed object naming
scheme, the contents of repository publication points and an internal
structure of a Repository Cache that is intended to facilitate
synchronisation across a distributed collection of repositories, in
support of certificate validation path construction.
A Resource Certificate attests to a binding of an entity's public key
to a set of IP address blocks and AS numbers. The Subject of a
Resource Certificate can demonstrate that it is the holder of the
resources enumerate in the certificate by using its private key to
generate a digital signature (that can be verified using the public
key from the certificate).
1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779].
In addition, the following terms are used in this document:
Repository Object (or Object):
This refers to a terminal object in a repository publication
point. A terminal object is conventionally implemented as a file
in a publicly accessible directory, where the file is not a
directory itself, although other forms of objects that have an
analogous public appearance to a file are encompassed by this
term.
Huston, et al. Expires April 14, 2011 [Page 3]
Internet-Draft ResCert Respository Structure October 2010
Repository Publication Point:
This refers to a collection of Repository Objects that are
published at a common publication point. This is conventionally
implemented as a directory in a publicly accessible filesystem
that is identified by a URI [RFC3986], although other forms of
local storage that have an analogous public appearance to a simple
directory of files are also encompassed by this term.
Repository Instance:
This refers to a collection of one or more Repository Publication
Points that share a common publication instance. This
conventionally is implemented as a collection of filesystem
directories that share a common URI prefix, where each directory
is also identifiable by its own unique URI.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. RPKI Repository Publication Point Content and Structure
The RPKI does not require that a single repository instance contain
all published RPKI objects. Instead, the RPKI repository system is
comprised of multiple repository instances. Each individual
repository instance is composed of one or more repository publication
points. Each repository publication point is used by one or more
entities referenced in RPKI certificates, as defined in the
certificate's Subject Information Authority (SIA) extension.
This section describes the collection of objects (RPKI certificates,
CRLs, manifests and signed objects) held in repository publication
points.
For every Certification Authority (CA) certificate in the RPKI there
is a corresponding repository publication point that is the
authoritative publication point for all current certificates and CRLs
issued by this CA. For every End-entity (EE) certificate in the RPKI
there is a repository publication point that holds all current signed
objects that can be verified via this EE certificate. In both cases
certificate's SIA extension contains a URI [RFC3986] that references
this repository publication point and identifies the repository
access mechanisms. Additionally, a certificate's Authority
Information Access (AIA) extension contains a URI that references the
authoritative location for the Certification Authority (CA)
certificate under which the given certificate was issued.
For example, if the subject of certificate A has issued certificates
Huston, et al. Expires April 14, 2011 [Page 4]
Internet-Draft ResCert Respository Structure October 2010
B and C, then the AIA extensions of certificates B and C both point
to the publication point for the certificate A object, and the SIA
extension of certificate A points to a repository publication point
(directory) containing certificates B and C (see Figure 1).
+--------+
+--------->| Cert A |<----+
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP-------+ | | CRLDP-----+ |
+----------- AIA | | +----- AIA | | |
| | SIA------+ | | SIA------------+
| +--------+ | | +--------+ | | |
| | V V | |
| | +-----------------+ | |
| | | CRL issued by A | | |
| A's Repository| +-----------------+ | |
| Directory | | |
+---------------|----------------------+ |
| |
+----------------+ | +----------------+ |
| B's Repository |<-------+ | C's Repository |<--+
| Directory | | Directory |
+----------------+ +----------------+
Figure 1. Use of AIA and SIA extensions in the RPKI.
In Figure 1, certificates B and C are issued by (CA) A. Therefore,
the AIA extensions of certificates B and C point to (certificate) A,
and the SIA extension of certificate A points to the repository
publication point of CA A's subordinate products, which includes
certificates B and C, as well as the CRL issued by A. The CRL
Distribution Points (CRLDP) extension in certificates B and C both
point to the Certificate Revocation List (CRL) issued by A.
In this distributed repository structure an instance of a CA's
repository publication point contains all published certificates
issued by that CA, and the CRL issued by that CA. An End Entity's
(EE's) repository publication point contains all the published
objects that are verified via the associated EE certificate.
Huston, et al. Expires April 14, 2011 [Page 5]
Internet-Draft ResCert Respository Structure October 2010
2.1. Manifests
Every repository publication point MUST contain a manifest
[I-D.ietf-sidr-rpki-manifests]. The manifest contains a list of the
names of all objects, as well as the hash value of each object's
contents, that are currently published by a CA, or by an EE.
An authority MAY perform a number of object operations on a
publication repository within the scope of a repository change before
issuing a single manifest that covers all the operations within the
scope of this change. Repository operators SHOULD implement some
form of directory management regime function on the repository to
ensure that RPs who are performing retrieval operations on the
repository are not exposed to intermediate states during changes to
the repository and the associated manifest.
2.2. CA Repository Publication Points
A CA Certificate has two accessMethod elements specified in its SIA
field. The id-ad-caRepository accessMethod element has an associated
accessLocation element that points to the repository publication
point of the certificates issued by this CA, as specified in
[I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod
element has an associated accessLocation element that points to the
manifest object, as an object URI (as distinct to a directory URI),
that is associated with this CA.
A CA's publication repository contains the current (non-expired and
non-revoked) certificates issued by this CA, the most recent CRL
issued by this CA, the current manifest, and all other current signed
objects that can be verified using a "single-use" EE certificate
[I-D.ietf-sidr-res-certs] issued by this CA.
The CA's manifest contains the names of this collection of objects,
together with the hash value of each object's contents, with the
single exception of the manifest itself.
The RPKI design requires that a CA be uniquely associated with a
single key pair. Thus, the administrative entity that is a CA
performs key rollover by generating a new CA certificate with a new
Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll].
(The reason for the new Subject name is that in the context of the
RPKI the Subject names in all certificates issued by a CA are
intended to be unique, and because the RPKI key rollover procedure
creates a new instance of a CA with the new key, the name constraint
implies the need for a new Subject name for the CA with the new key.)
In such cases the entity SHOULD continue to use the same repository
publication point for both CA instances during the key rollover,
Huston, et al. Expires April 14, 2011 [Page 6]
Internet-Draft ResCert Respository Structure October 2010
ensuring that the value of the AIA extension in indirect subordinate
objects that refer to the certificates issued by this CA remain valid
across the key rollover, and that the re-issuance of subordinate
certificates in a key rollover is limited to the collection of
immediate subordinate products of this CA. In such cases the
repository publication point will contain the CRL, manifest and
subordinate certificates of both CA instances.
The following paragraphs provide guidelines for naming objects in a
CA's repository publication point:
CRL:
When a CA issues a new CRL, it replaces the previous CRL (issued
under the same CA key pair) in the repository publication point.
CAs MUST NOT continue to publish previous CRLs in the repository
publication point. Thus, it SHOULD replace (overwrite) previous
CRLs signed by the same CA (instance). A non-normative guideline
for naming such objects is that the file name chosen for the CRL
in the repository be a value derived from the public key of the CA
One such method of generating a CRL publication name is described
in section 2.1 of [RFC4387]; convert the 160-bit hash of a CA's
public key value into a 27-character string using a modified form
of Base64 encoding, with an additional modification as proposed in
section 5, table 2, of [RFC4648]. The filename extension of
".crl" MUST be used, to denote the file as a CRL.
Manifest:
When a new instance of a manifest is published, it SHOULD replace
the previous manifest, to avoid confusion. CAs MUST NOT continue
to publish previous CA manifests in the repository publication
point. A non-normative guideline for naming such objects is that
the filename chosen for the manifest in the publication repository
be a value derived from the public key part of the entity's key
pair, using the algorithm described for CRLs above for generation
of filenames. The filename extension of ".mft" MUST be used, to
denote the object as a manifest.
Certificates:
Within the RPKI framework it is possible that a CA MAY issue a
series of certificates to the same subject name, the same subject
public key, and the same resource collection. However, a relying
party requires access only to the most recently published
certificate in such a series. Thus, the such a series of
certificates SHOULD share the same filename. This ensures that
each successive issued certificate in such a series effectively
overwrites the previous instance of the certificate. A non-
normative guideline for naming such objects is for the CA to adopt
a (local) policy requiring a subject to use a unique key pair for
Huston, et al. Expires April 14, 2011 [Page 7]
Internet-Draft ResCert Respository Structure October 2010
each unique instance of a certificate series issued to the same
subject, thereby the CA to use a file name generation scheme based
on the subject's public key, e.g., using the algorithm described
above for CRLs above. Published certificates MUST use a filename
extension of ".cer" to denote the object as a certificate.
Signed Objects:
Within the RPKI framework there are two kinds of EE certificates:
"single-use" EE certificates (that are used to verify a single
object), and "multi-use" EE certificates (that may be used to
verify multiple objects). In the case of "multi-use" EE
certificates the repository publication point is described in the
following section. In the case of a "single-use" EE certificate,
the single signed object is published in the repository
publication point referenced by the SIA of the CA certificate that
issued the "single-use" EE certificate. A non-normative guideline
for naming such objects is for the filename of such objects to be
derived from the associated EE certificate's public key, applying
the algorithm described above. Published objects MUST NOT use the
filename extensions ".crl", ".mft", or ".cer".
2.3. Multi-Use EE Repository Publication Points
EE repository publication points are used only in conjunction with
"multi-use" EE Certificates. In this case the EE Certificate has two
accessMethods specified in its SIA field. The id-
adsignedObjectRepository accessMethod has an associated
accessLocation that points to the repository publication point of the
objects verified by this EE certificate, as specified in
[I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod has
an associated access location that points to the manifest, as an
object URI (as distinct from a directory URI), associated with this
repository publication point. This manifest describes all the signed
objects that are to be found in that publication point that can be
verified by this EE certificate, and the hash value of each product
(excluding the manifest itself) [I-D.ietf-sidr-rpki-manifests].
In the case of multi-use EE, the repository publication point
contains all published objects that can be verified using the EE's
public key, and a manifest of all such signed objects. A multi-use
EE's manifest is limited in scope to listing the objects verified by
this multi-use EE certificate.
The objects published in a multi-use EE repository publication point
do not form a logical, temporal sequence, and thus the filenames
associated with each instance of these objects MUST be unique per
multi-use EE.
Huston, et al. Expires April 14, 2011 [Page 8]
Internet-Draft ResCert Respository Structure October 2010
It is consistent with this specification, but NOT recommended
practice, that all subordinate multi-use EE certificates of a given
CA share a common repository publication point. This common
repository publication point MAY be shared with that of the given CA,
bit this, too, is NOT recommended practice. In this case, the
repository publication point would contain multiple manifest objects,
one for each (multi-use) EE certificate associated with this common
publication point (and, potentially, additional manifests generated
by the CA's that also share this common repository publication
point). In such a scenario it is necessary to ensure that the set of
filenames used by each multi-use EE are unique. A non-normative
guideline is for a multi-use EE to use a common base name component
that is generated from the public key of the multi-use EE
certificate, in the manner described above for CRL names. The choice
of whether to use a common single publication repository or a
dedicated publication repository for each multi-use EE and CA is an
implementation choice.
3. Resource Certificate Publication Repository Considerations
Each issuer MAY publish its issued certificates and CRL in any
repository. However, there are a number of considerations that guide
the choice of a suitable repository publication structure:
* The publication repository SHOULD be hosted on a highly
available service and high capacity publication platform.
* The publication repository MUST be available using RSYNC
[RFC5781]. Support of additional retrieval mechanisms is the
choice of the repository operator. The supported retrieval
mechanisms MUST be consistent with the accessMethod element
value(s) specified in the SIA of the associated CA or EE.
* Each CA repository publication point SHOULD contain the
products of this CA, including those objects that can be
verified by single-use EE certificates that have been issued by
this CA. The signed products of related CA's that are operated
by the same entity MAY share this CA repository publication
point. Aside from subdirectories, any other objects SHOULD NOT
be placed in a repository publication point.
Any such subdirectory SHOULD be the repository publication
point of a CA or EE certificate that is contained in the CA
directory. These considerations also apply recursively to
subdirectories of these directories.
Huston, et al. Expires April 14, 2011 [Page 9]
Internet-Draft ResCert Respository Structure October 2010
* Signed Objects are published in the location indicated by the
SIA field of the EE certificate used to verify the signature of
each object. The choice of the repository publication point is
determined by the nature of the corresponding EE certificate.
In the case of a "multi-use" EE certificate signed objects are
published in the EE repository publication point referenced by
the SIA extension of the EE certificate in question. In the
case of a "single-use" EE certificate the signed object is
published in the repository publication point of the CA
certificate that issued the EE certificate. The SIA extension
of the single use EE certificate references this object rather
than the repository publication
directory[I-D.ietf-sidr-res-certs].
* It is recommended in Section 2.1 that repository operators
SHOULD implement some form of directory management regime
function on the repository to ensure that RPs who are
performing retrieval operations on the repository are not
exposed to intermediate states during changes to the repository
and the associated manifest. Notwithstanding the following
commentary, RPs SHOULD NOT assume that a consistent repository
and manifest state is assured, and organise their retrieval
operations accordingly (see Section 5).
The manner in which a repository operator can implement a
directory update regime that mitigates the risk of the manifest
and directory contents being inconsistent, to some extent, is
dependant on the operational characteristics of the filesystem
that hosts the repository, so the following comments are non-
normative in terms of any implicit guidelines for repository
operators.
A commonly used technique to avoid exposure to inconsistent
retrieval states during updates to a large directory, is to
batch a set of changes to be made, create a working copy of the
directory's contents, and then perform the batch of changes to
this local copy of the directory. On completion, rename the
filesystem symbolic link of the repository directory name to
point to this working copy of the directory. The old
repository directory contents can be purged at a slightly later
time. However, it is noted that the outcomes of this technique
in terms of ensuring the integrity of client synchronization
functions performed over the directory depend on the
interaction between the supported access mechanisms and the
local filesystem behaviour. It is probable that this technique
will not remove all possibilities for RPs to see inconsistent
states between the manifest and the repository.
Huston, et al. Expires April 14, 2011 [Page 10]
Internet-Draft ResCert Respository Structure October 2010
4. Certificate Reissuance and Repositories
If a CA certificate is reissued, e.g., due to changes in the set of
resources contained in the number resource extensions, it should not
be necessary to reissue all certificates issued under it. Because
these certificates contains AIA extensions that point to the
publication point for the CA certificate, a CA SHOULD use a name for
its repository publication point that persists across certificate
reissuance events. That is, reissued CA certificates SHOULD use the
same repository publication point as previously issued CA
certificates having the same subject and subject public key, such
that certificate reissuance SHOULD intentionally overwrite the
previously issued certificate within the repository publication
point.
It is noted in section Section 2.2 that when a CA performs a key
rollover the entity SHOULD use a name for its repository publication
point that persists across key rollover. In such cases the
repository publication point will contain the CRLs, and manifests of
both CA instances as a transient state in the key rollover procedure.
The RPKI key rollover procedure [I-D.ietf-sidr-keyroll] requires that
the subordinate products of the old CA are overwritten in the common
repository publication point by subordinate products issued by the
new CA.
5. Synchronising Repositories with a Local Cache
It is possible to perform the validation-related task of certificate
path construction using retrieval of individual certificates and
certificate revocation lists using online retrieval of individual
certificates, sets of candidate certificates and certificate
revocation lists based on the AIA, SIA and CRLDP certificate fields.
This is NOT recommended in circumstances where speed and efficiency
are relevant considerations.
To enable efficient validation of RPKI certificates, CRLs, and signed
objects, it is recommended that each relying party maintain a local
repository containing a synchronized copy of all valid certificates,
current certificate revocation lists, and all related signed objects.
The general approach to repository synchronisation is one of a "top-
down" walk of the distributed repository structure. This commences
with the collection of locally selected trust anchor material
corresponding to the local choice of Trust Anchors, which can be used
to load the initial set of self-signed resource certificate(s) that
form the "seed" of this process [I-D.ietf-sidr-ta]. The process then
populates the local repository cache will all valid certificates that
Huston, et al. Expires April 14, 2011 [Page 11]
Internet-Draft ResCert Respository Structure October 2010
have been issued by these issuers. This procedure can be recursively
applied to each of these subordinate certificates. Such a repository
traversal process SHOULD support a locally configured maximal chain
length from the initial trust anchors to the current working
validation point in order to ensure that the process does not follow
a loop or a non-terminating certificate chain.
RPs SHOULD ensure that this local synchronisation uses the retrieved
manifests [I-D.ietf-sidr-rpki-manifests] to ensure that they are
synchronising against a current consistent state of each repository
publication point. It is noted in Section 3 that a repository
operator cannot assure RPs that when the repository publication point
contents are updated that the manifest contents and the repository
contents will be precisely aligned at all times. RPs SHOULD use a
retrieval algorithm that takes this potential for transient
inconsistency into account. Possible algorithms for the RP to
mitigate this situation include performing the synchronisation across
the repository twice in succession, or performing a manifest
retrieval both before and after the synchronisation of the directory
contents, and repeating the synchronization function if the second
copy of the manifest differs from the first.
6. Security Considerations
Repositories are not assumed to be integrity-protected databases, and
repository retrieval operations MAY be vulnerable to various forms of
"man-in-the-middle" attacks. Corruption of retrieved objects is
detectable by a relying party through the validation of the signature
associated with each retrieved object. Replacement of newer
instances of an object with an older instance of the same object is
detectable through the use of manifests. Insertion of revoked,
deleted certificates is detected through the retrieval and processing
of CRLs at scheduled intervals. However, even the use of manifests
and CRLs will not allow a relying party to detect all forms of
substitution attacks based on older (but not expired) valid objects.
7. IANA Considerations
[There are no IANA considerations in this document.]
8. References
Huston, et al. Expires April 14, 2011 [Page 12]
Internet-Draft ResCert Respository Structure October 2010
8.1. Normative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11.txt
(work in progress), September 2010.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-18.txt (work in progress),
May 2010.
[I-D.ietf-sidr-rpki-manifests]
Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-manifests (work in progress),
May 2010.
8.2. Informative References
[I-D.ietf-sidr-keyroll]
Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in
progress), October 2010.
[I-D.ietf-sidr-ta]
Michaelson, G., Kent, S., and G. Huston, "A Profile for
Trust Anchor Material for the Resource Certificate PKI",
draft-ietf-sidr-ta-04.txt (work in progress), May 2010.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via HTTP",
RFC 4387, February 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
Huston, et al. Expires April 14, 2011 [Page 13]
Internet-Draft ResCert Respository Structure October 2010
(CRL) Profile", RFC 5280, May 2008.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
Authors' Addresses
Geoff Huston
APNIC
Email: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans
APNIC
Email: robertl@apnic.net
URI: http://www.apnic.net
George Michaelson
APNIC
Email: ggm@apnic.net
URI: http://www.apnic.net
Huston, et al. Expires April 14, 2011 [Page 14]
