RFC 6490

Resource Public Key Infrastructure (RPKI) Trust Anchor Locator

📅 published February 2012, from ietf

RFC 6490: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator 🎀

okay bestie, let's start with the basics ✨ this is RFC 6490, and it's a Standards Track doc from February 2012 💅 The authors are G. Huston (APNIC), S. Weiler (SPARTA, Inc.), G. Michaelson (APNIC), and S. Kent (BBN). The ISSN is 2070-1721. Its header doesn't list anything it obsoletes or updates, so there's nothing to chase there 🙈

Abstract

okay so the big idea is that this doc defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI) 🔐🦋

Status of This Memo

this one is an Internet Standards Track document 💖

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want the deets on Internet Standards, check out Section 2 of RFC 5741 📚

info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6490 🧚

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they spell out your rights and restrictions for this doc 🫶 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ✨

Table of Contents

1. Introduction ....................................................2
   1.1. Terminology ................................................2
2. Trust Anchor Locator ............................................2
   2.1. Trust Anchor Locator Format ................................2
   2.2. TAL and Trust Anchor Certificate Considerations ............3
   2.3. Example ....................................................4
3. Relying Party Use ...............................................5
4. Security Considerations .........................................5
5. Acknowledgments .................................................6
6. References ......................................................6
   6.1. Normative References .......................................6
   6.2. Informative References .....................................6

1. Introduction ✨

okay so this doc defines the Trust Anchor Locator (TAL) for the RPKI [RFC6480] 🦋 The format may be used to distribute trust anchor material using a mix of out-of-band and online means 🌈 Procedures used by Relying Parties (RPs) to verify RPKI signed objects SHOULD support this format, so that creators of trust anchor material and RPs can actually interoperate 💜

1.1. Terminology

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 [RFC2119] 📖

2. Trust Anchor Locator 🎀

2.1. Trust Anchor Locator Format

this doc does not propose a new format for trust anchor material 🙌 A trust anchor in the RPKI is a self-signed X.509 Certification Authority (CA) certificate, which is a format that's common in PKIs and widely supported by RP software 💅 What this doc does specify is a format for the data used to retrieve and verify the authenticity of a trust anchor, in a very simple way. That data is called the TAL 🍓

the whole motivation for the TAL is to let selected data in the trust anchor change without needing to redistribute the trust anchor itself 🫶 In the RPKI, certificates carry extensions that represent Internet Number Resources (INRs) [RFC3779]. The set of INRs tied to an entity will probably change over time 🕰️ So if you used the usual PKI habit of distributing a trust anchor to RPs securely, you'd have to repeat that whole procedure every time the INR set changed. Distributing the TAL securely instead of the trust anchor avoids that problem. The TAL stays constant as long as the trust anchor's public key and its location don't change 🔐

the TAL is analogous to the TrustAnchorInfo data structure [RFC5914], which was adopted as a PKIX standard. That standard could represent the TAL if someone defined an rsync URI extension for that data structure 🤔 But the TAL format was adopted by RPKI implementors before the PKIX trust anchor work happened, and the RPKI implementer community chose to use the TAL format rather than define the extension it would need. The community also likes the simplicity of the ASCII encoding of the TAL more than the binary (ASN.1) encoding used for TrustAnchorInfo 💜

the TAL is an ordered sequence of:

  1. An rsync URI [RFC5781]
  2. A <CRLF> or <LF> line break
  3. A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648])

2.2. TAL and Trust Anchor Certificate Considerations

okay this part is where the rules get serious 💅 The rsync URI in the TAL MUST reference a single object. It MUST NOT reference a directory or any other kind of collection of objects 🚫

the referenced object MUST be a self-signed CA certificate that conforms to the RPKI certificate profile [RFC6487]. This certificate is the trust anchor in certification path discovery [RFC4158] and validation [RFC5280] [RFC3779] 👑

the validity interval of this trust anchor SHOULD reflect the anticipated period of stability for the particular set of INRs associated with the putative trust anchor 🦋

the INR extension(s) of this trust anchor MUST contain a non-empty set of number resources. It MUST NOT use the "inherit" form of the INR extension(s). The INR set described in this certificate is the set of number resources for which the issuing entity is offering itself as a putative trust anchor in the RPKI [RFC6480] 🌸

the public key used to verify the trust anchor MUST be the same as the subjectPublicKeyInfo in the CA certificate and in the TAL 🔑

the trust anchor MUST contain a stable key. This key MUST NOT change when the certificate is reissued because of changes in the INR extension(s), when the certificate is renewed before it expires, or for any reason other than a key change 🧚

because the public key in the TAL and the trust anchor MUST be stable, that motivates running this CA in an off-line mode 🌙 So the entity that issues the trust anchor SHOULD issue a subordinate CA certificate that contains the same INRs (by using the "inherit" option in the INR extensions of the subordinate certificate). That lets the issuing entity keep the matching private key off-line while it issues all the relevant child certificates under the immediate subordinate CA 🔒 The CRL that entity issues can also be used to revoke the subordinate CA certificate if there's suspected key compromise of this potentially more vulnerable online operational key pair 🚨

the trust anchor MUST be published at a stable URI. When the trust anchor is reissued for any reason, the replacement CA certificate MUST be accessible using the same URI 🔗

because the trust anchor is a self-signed certificate, there's no corresponding CRL that can revoke it, and there's no manifest [RFC6486] that lists this certificate 🙈

if an entity wants to withdraw a self-signed CA certificate as a putative trust anchor for any reason, including key rollover, the entity MUST remove the object from the location referenced in the TAL 🗑️

2.3. Example

here's the example, verbatim, because we do not touch the base64 🫶

rsync://rpki.example.org/rpki/hedgehog/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB

3. Relying Party Use 🌈

okay so to use the TAL to retrieve and validate a (putative) trust anchor, an RP SHOULD:

  1. Retrieve the object referenced by the URI contained in the TAL.
  2. Confirm that the retrieved object is a current, self-signed RPKI CA certificate that conforms to the profile specified in [RFC6487].
  3. Confirm that the public key in the TAL matches the public key in the retrieved object.
  4. Perform other checks, as deemed appropriate (locally), to make sure the RP is willing to accept the entity publishing this self-signed CA certificate as a trust anchor. These checks apply to the validity of attestations made in the context of the RPKI, relating to all resources described in the INR extension of this certificate 💅

an RP SHOULD perform these functions for each instance of TAL it's holding for this purpose, every time the RP does a re-synchronization across the local repository cache ⏰ And in any case, an RP also SHOULD perform these functions before the locally cached copy of the retrieved trust anchor referenced by the TAL expires 💀

4. Security Considerations 🚨

okay, this section is dramatic and I'm here for it 😭 Compromise of a trust anchor private key lets unauthorized parties masquerade as a trust anchor, and that can have potentially severe consequences. Relying on an inappropriate or incorrect trust anchor has similarly potentially severe consequences 💀

this TAL doesn't directly provide a list of resources covered by the referenced self-signed CA certificate. Instead, the RP is referred to the trust anchor itself and the INR extension(s) within this certificate. That gives necessary operational flexibility, but it also lets the certificate issuer claim to be authoritative for any resource 🙈 So relying parties should either have great confidence in the issuers of the certificates they configure as trust anchors, or they should issue their own self-signed certificate as a trust anchor and, in doing so, impose constraints on the subordinate certificates. For more on this approach, see [TA-MGMT] 🫶

5. Acknowledgments 💖

this approach to trust anchor material was originally described by Robert Kisteleki 🌸

the authors acknowledge the contributions of Rob Austein and Randy Bush, who helped with earlier draft versions of this document and with really helpful review comments 🎀

6. References 📚

(part 2 is coming next, so stay tuned!) 🧚✨

6.1. Normative References ✨

okay bestie, these are the docs this RFC needs you to have read 📚🫶

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
  • [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 (CRL) Profile", RFC 5280, May 2008.
  • [RFC5781] 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.
  • [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
  • [X.509] ITU-T, "Recommendation X.509: The Directory - Authentication Framework", 2000.
ngl the [RFC5781] entry is giving copy-paste energy 💀 it has the exact same title, authors and date as [RFC5280]. It's written exactly like that in the original, so I'm keeping it as-is 🙈

6.2. Informative References 📖

these ones are just extra reading, not required, but lowkey worth a look 🌸

  • [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
  • [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
  • [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
  • [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
  • [TA-MGMT] Reynolds, M. and S. Kent, "Local Trust Anchor Management for the Resource Public Key Infrastructure", Work in Progress, December 2011.

Authors' Addresses 🎀

the squad behind this RFC, and where to find them 💜

Geoff Huston
APNIC

EMail: gih@apnic.net
URI:   http://www.apnic.net


Samuel Weiler
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, Maryland  21046
USA

EMail: weiler@tislabs.com


George Michaelson
APNIC

EMail: ggm@apnic.net
URI:   http://www.apnic.net


Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA  02138
USA

EMail: kent@bbn.com

that's the whole RFC, bestie 🌈✨ you did amazing 👑💖

📦 where this page comes from