Local Trust Anchor Management for the Resource Public Key Infrastructure

Document Type Replaced Internet-Draft (individual)
Last updated 2011-01-24 (latest revision 2010-10-21)
Replaced by draft-ietf-sidr-ltamgmt
Stream (None)
Intended RFC status (None)
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-sidr-ltamgmt
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document.


Stephen Kent (kent@bbn.com)
Mark Reynolds (mreynold@bbn.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)