Network Working Group S. Weiler Internet-Draft SPARTA, Inc. Intended status: Standards Track July 13, 2010 Expires: January 14, 2011 Simple RPKI Trust Anchor Format draft-weiler-sidr-trust-anchor-format-01 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 January 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 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 January 14, 2011 [Page 1] Internet-Draft RPKI Trust Anchor Format July 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. 1.1. Terminology RFC5280 and RFC5914 define the term "trust anchor" slightly differently than it is used here. In particular, those definitions do not include an external pointer such as the URI used in this format. The broader security literature, however, uses the term "trust anchor" to refer to something (relatively) static. In this case, the certificate pointed to by the URI contains a dynamic list of resources in the RFC3779 extensions, which makes the certificate unstable. While acknowledging the slight differences from the RFC5280 and RFC5914 definitions, we choose to use the term "trust anchor" in a way that is more consistent with the broader literature and which we find more intuitive. 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 Weiler Expires January 14, 2011 [Page 2] Internet-Draft RPKI Trust Anchor Format July 2010 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. 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. OPEN ISSUE: should this document mandate the use of a second tier CA cert? Weiler Expires January 14, 2011 [Page 3] Internet-Draft RPKI Trust Anchor Format July 2010 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", 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 Weiler Expires January 14, 2011 [Page 4] Internet-Draft RPKI Trust Anchor Format July 2010 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 January 14, 2011 [Page 5]