Network Working Group S. Weiler
Internet-Draft SPARTA, Inc.
Intended status: Standards Track June 7, 2010
Expires: December 9, 2010
RPKI Trust Anchor Format
draft-weiler-sidr-trust-anchor-format-00
Abstract
This document describes a simple convention for distributing trust
anchors for the Resource Public Key Infrastructure (RPKI).
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 December 9, 2010.
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
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.
Weiler Expires December 9, 2010 [Page 1]
Internet-Draft RPKI Trust Anchor Format June 2010
1. Introduction
This document describes a convention for distributing and using trust
anchors for the Resource Public Key Infrastructure (RPKI). It
assumes a working knowledge of the RPKI. [I-D.ietf-sidr-arch]
The trust anchor has two parts: a URI of a self-signed certificate
and a copy of the public key from that certificate. Neither part of
the trust anchor directly lists the resources for which the
certificate is authoritative. Instead, that list is stored in the
certificate itself, which allows the list of resources to change
without changing the trust anchor.
2. Format Details
The URI part of the trust anchor is an rsync URI. See [RFC5781].
The URI is followed by a CRLF.
The key part is a base64 encoded, DER-encoded X.509
subjectPublicKeyInfo. See [RFC5280].
2.1. Example
rsync://rpki.example.org/rpki/hedgehog/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
3. Usage
To use one of these trust anchors, a relying party (RP):
1. Retrieves the object referenced by the URI.
2. Checks that the received object is a valid, self-signed X.509
certificate with [RFC3779] extensions conforming to the profile
described in [I-D.ietf-sidr-res-certs].
3. Extracts the public key from the X.509 certificate.
4. Compares the public key from the trust anchor to the key from the
certificate. If they don't match, the trust anchor is invalid.
Weiler Expires December 9, 2010 [Page 2]
Internet-Draft RPKI Trust Anchor Format June 2010
4. Operational Considerations
When creating a certificate which will be referenced by a trust
anchor, several constraints apply:
1. It must conform to the profile described in
[I-D.ietf-sidr-res-certs].
2. It must be self-signed.
3. It must use a stable key. When reissuing the certificate,
whether because the list of resources changes, or renewal, or for
any other reason, the same key must be reused in the new
certificate.
4. It must be published at a stable URI. When the certificate is
reissued, the replacement must be accessible using the same URI.
If the issuer of a trust anchor wants to keep the private key
corresponding to the self-signed certificate off-line, that can be
easily done by delegating all of the resources in the certificate to
a single child certificate and issuing all relevant certificates
under the child.
5. IANA Considerations
This document specifies no IANA Actions.
6. Security Considerations
This trust anchor format does not directly provide a list of
resources covered by the certificate. Instead, the relying party is
referred to the certificate itself. This provides necessary
operational flexibility, but it also allows the certificate issuer to
claim to be authoritative for any resource. Relying parties should
either have great confidence in the issuers of certificates that
they're configuring as trust anchors, or they should issue their own
self-signed certificate as a trust anchor and, in doing so, impose
constraints on the child certificates. For more information on this
approach, see [I-D.reynolds-rpki-ltamgmt].
7. References
7.1. Normative References
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
Weiler Expires December 9, 2010 [Page 3]
Internet-Draft RPKI Trust Anchor Format June 2010
draft-ietf-sidr-res-certs-18 (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.
[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
(CRL) Profile", RFC 5280, May 2008.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
7.2. Informative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-09 (work in
progress), October 2009.
[I-D.reynolds-rpki-ltamgmt]
Kent, S. and M. Reynolds, "Local Trust Anchor Management
for the Resource Public Key Infrastructure",
draft-reynolds-rpki-ltamgmt-00 (work in progress),
March 2010.
Appendix A. Acknowledgments
This idea came from Robert Kisteleki, circa 2007.
The editor thanks Rob Austein for his help in understanding the
details of his implementation of this convention.
Author's Address
Samuel Weiler
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Weiler Expires December 9, 2010 [Page 4]