summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8630.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8630.txt')
-rw-r--r--doc/rfc/rfc8630.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8630.txt b/doc/rfc/rfc8630.txt
new file mode 100644
index 0000000..eaa8b68
--- /dev/null
+++ b/doc/rfc/rfc8630.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) G. Huston
+Request for Comments: 8630 APNIC
+Obsoletes: 7730 S. Weiler
+Category: Standards Track W3C/MIT
+ISSN: 2070-1721 G. Michaelson
+ APNIC
+ S. Kent
+ Unaffiliated
+ T. Bruijnzeels
+ NLnet Labs
+ August 2019
+
+
+ Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
+
+Abstract
+
+ This document defines a Trust Anchor Locator (TAL) for the Resource
+ Public Key Infrastructure (RPKI). The TAL allows Relying Parties in
+ the RPKI to download the current Trust Anchor (TA) Certification
+ Authority (CA) certificate from one or more locations and verify that
+ the key of this self-signed certificate matches the key on the TAL.
+ Thus, Relying Parties can be configured with TA keys but can allow
+ these TAs to change the content of their CA certificate. In
+ particular, it allows TAs to change the set of IP Address Delegations
+ and/or Autonomous System Identifier Delegations included in the
+ extension(s) (RFC 3779) of their certificate.
+
+ This document obsoletes the previous definition of the TAL as
+ provided in RFC 7730 by adding support for Uniform Resource
+ Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC
+ 7230) as the scheme.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8630.
+
+
+
+
+
+Huston, et al. Standards Track [Page 1]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 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
+ (https://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.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................3
+ 1.2. Changes from RFC 7730 ......................................3
+ 2. Trust Anchor Locator ............................................3
+ 2.1. Trust Anchor Locator Motivation ............................3
+ 2.2. Trust Anchor Locator File Format ...........................4
+ 2.3. TAL and TA Certificate Considerations ......................4
+ 2.4. Example ....................................................6
+ 3. Relying Party Use ...............................................6
+ 4. URI Scheme Considerations .......................................7
+ 5. Security Considerations .........................................8
+ 6. IANA Considerations .............................................8
+ 7. References ......................................................8
+ 7.1. Normative References .......................................8
+ 7.2. Informative References ....................................10
+ Acknowledgements ..................................................10
+ Authors' Addresses ................................................11
+
+1. Introduction
+
+ This document defines a Trust Anchor Locator (TAL) for the Resource
+ Public Key Infrastructure (RPKI) [RFC6480]. This format may be used
+ to distribute Trust Anchor (TA) 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 to facilitate
+ interoperability between creators of TA material and RPs. This
+ document obsoletes [RFC7730] by adding support for Uniform Resource
+ Identifiers (URIs) [RFC3986] that use HTTP over TLS (HTTPS) [RFC7230]
+ as the scheme.
+
+
+
+
+
+Huston, et al. Standards Track [Page 2]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Changes from RFC 7730
+
+ The TAL format defined in this document differs from the definition
+ in [RFC7730] in that:
+
+ o it allows for the use of the HTTPS scheme in URIs [RFC7230], and
+
+ o it allows for the inclusion of an optional comment section.
+
+ Note that current RPs may not support this new format yet.
+ Therefore, it is RECOMMENDED that a TA operator maintain a TAL file
+ as defined in [RFC7730] for a time as well, until they are satisfied
+ that RP tooling has been updated.
+
+2. Trust Anchor Locator
+
+2.1. Trust Anchor Locator Motivation
+
+ This document does not propose a new format for TA material. A TA in
+ the RPKI is represented by a self-signed X.509 Certification
+ Authority (CA) certificate, a format commonly used in PKIs and widely
+ supported by RP software. This document specifies a format for data
+ used to retrieve and verify the authenticity of a TA in a very simple
+ fashion. That data is referred to as the TAL.
+
+ The motivation for defining the TAL is to enable selected data in the
+ TA to change, without needing to redistribute the TA per se.
+
+ In the RPKI, certificates contain one or more extensions [RFC3779]
+ that can contain a set of IP Address Delegations and/or Autonomous
+ System Identifier Delegations. In this document, we refer to these
+ delegations as the Internet Number Resources (INRs) contained in an
+ RPKI certificate.
+
+ The set of INRs associated with an entity acting as a TA is likely to
+ change over time. Thus, if one were to use the common PKI convention
+ of distributing a TA to RPs in a secure fashion, then this procedure
+ would need to be repeated whenever the INR set for the entity acting
+ as a TA changed. By distributing the TAL (in a secure fashion)
+
+
+
+
+Huston, et al. Standards Track [Page 3]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ instead of distributing the TA, this problem is avoided, i.e., the
+ TAL is constant so long as the TA's public key and its location do
+ not change.
+
+ The TAL is analogous to the TrustAnchorInfo data structure specified
+ in [RFC5914], which is on the Standards Track. That specification
+ could be used to represent the TAL, if one defined an rsync or HTTPS
+ URI extension for that data structure. However, the TAL format was
+ adopted by RPKI implementors prior to the PKIX TA work, and the RPKI
+ implementor community has elected to utilize the TAL format rather
+ than define the requisite extension. The community also prefers the
+ simplicity of the ASCII encoding of the TAL, versus the binary
+ (ASN.1) encoding for TrustAnchorInfo.
+
+2.2. Trust Anchor Locator File Format
+
+ In this document, we define a TA URI as a URI that can be used to
+ retrieve a current TA certificate. This URI MUST be either an rsync
+ URI [RFC5781] or an HTTPS URI [RFC7230].
+
+ The TAL is an ordered sequence of:
+
+ 1. an optional comment section consisting of one or more lines each
+ starting with the "#" character, followed by human-readable
+ informational UTF-8 text, conforming to the restrictions defined
+ in Section 2 of [RFC5198], and ending with a line break,
+
+ 2. a URI section that is comprised of one or more ordered lines,
+ each containing a TA URI, and ending with a line break,
+
+ 3. a line break, and
+
+ 4. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded
+ in base64 (see Section 4 of [RFC4648]). To avoid long lines,
+ line breaks MAY be inserted into the base64-encoded string.
+
+ Note that line breaks in this file can use either "<CRLF>" or "<LF>".
+
+2.3. TAL and TA Certificate Considerations
+
+ Each TA URI in the TAL MUST reference a single object. It MUST NOT
+ reference a directory or any other form 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 TA in certification path discovery [RFC4158] and validation
+ [RFC5280] [RFC3779].
+
+
+
+
+
+Huston, et al. Standards Track [Page 4]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ The validity interval of this TA is chosen such that (1) the
+ "notBefore" time predates the moment that this certificate is
+ published and (2) the "notAfter" time is after the planned time of
+ reissuance of this certificate.
+
+ The INR extension(s) of this TA 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 TA in the RPKI [RFC6480].
+
+ The public key used to verify the TA MUST be the same as the
+ subjectPublicKeyInfo in the CA certificate and in the TAL.
+
+ The TA MUST contain a stable key that does not change when the
+ certificate is reissued due to changes in the INR extension(s), when
+ the certificate is renewed prior to expiration.
+
+ Because the public key in the TAL and the TA MUST be stable, this
+ motivates operation of that CA in an offline mode. In that case, a
+ subordinate CA certificate containing the same INRs, or, in theory,
+ any subset of INRs, can be issued for online operations. This allows
+ the entity that issues the TA to keep the corresponding private key
+ of this certificate offline, while issuing all relevant child
+ certificates under the immediate subordinate CA. This measure also
+ allows the Certificate Revocation List (CRL) issued by that entity to
+ be used to revoke the subordinate CA certificate in the event of
+ suspected key compromise of this online operational key pair that is
+ potentially more vulnerable.
+
+ The TA MUST be published at a stable URI. When the TA is reissued
+ for any reason, the replacement CA certificate MUST be accessible
+ using the same URI.
+
+ Because the TA is a self-signed certificate, there is no
+ corresponding CRL that can be used to revoke it, nor is there a
+ manifest [RFC6486] that lists this certificate.
+
+ If an entity wishes to withdraw a self-signed CA certificate as a
+ putative TA, for any reason, including key rollover, the entity MUST
+ remove the object from the location referenced in the TAL.
+
+ Where the TAL contains two or more TA URIs, the same self-signed
+ CA certificate MUST be found at each referenced location. In order
+ to increase operational resilience, it is RECOMMENDED that
+ (1) the domain name parts of each of these URIs resolve to distinct
+
+
+
+
+
+Huston, et al. Standards Track [Page 5]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ IP addresses that are used by a diverse set of repository publication
+ points and (2) these IP addresses be included in distinct Route
+ Origin Authorization (ROA) objects signed by different CAs.
+
+2.4. Example
+
+ # This TAL is intended for documentation purposes only.
+ # Do not attempt to use this in a production setting.
+ rsync://rpki.example.org/rpki/hedgehog/root.cer
+ https://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
+
+ In order to use the TAL to retrieve and validate a (putative) TA, an
+ RP SHOULD:
+
+ 1. Retrieve the object referenced by (one of) the TA URI(s)
+ contained in the TAL.
+
+ 2. Confirm that the retrieved object is a current, self-signed RPKI
+ CA certificate that conforms to the profile as 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 ensure
+ that the RP is willing to accept the entity publishing this
+ self-signed CA certificate to be a TA. These tests apply to the
+ validity of attestations made in the context of the RPKI relating
+ to all resources described in the INR extension(s) of this
+ certificate.
+
+ An RP SHOULD perform these functions for each instance of a TAL that
+ it is holding for this purpose every time the RP performs a
+ resynchronization across the local repository cache. In any case, an
+ RP also SHOULD perform these functions prior to the expiration of the
+ locally cached copy of the retrieved TA referenced by the TAL.
+
+
+
+
+
+Huston, et al. Standards Track [Page 6]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ In the case where a TAL contains multiple TA URIs, an RP MAY use a
+ locally defined preference rule to select the URI to retrieve the
+ self-signed RPKI CA certificate that is to be used as a TA. Some
+ examples are:
+
+ o Using the order provided in the TAL
+
+ o Selecting the TA URI randomly from the available list
+
+ o Creating a prioritized list of URIs based on RP-specific
+ parameters, such as connection establishment delay
+
+ If the connection to the preferred URI fails or the retrieved CA
+ certificate public key does not match the TAL public key, the RP
+ SHOULD retrieve the CA certificate from the next URI, according to
+ the local preference ranking of URIs.
+
+4. URI Scheme Considerations
+
+ Please note that the RSYNC protocol provides neither transport
+ security nor any means by which the RP can validate that they are
+ connected to the proper host. Therefore, it is RECOMMENDED that
+ HTTPS be used as the preferred scheme.
+
+ Note that, although a Man in the Middle (MITM) cannot produce a CA
+ certificate that would be considered valid according to the process
+ described in Section 3, this type of attack can prevent the RP from
+ learning about an updated CA certificate.
+
+ RPs MUST do TLS certificate and host name validation when they fetch
+ a CA certificate using an HTTPS URI on a TAL. RPs SHOULD log any TLS
+ certificate or host name validation issues found so that an operator
+ can investigate the cause.
+
+ It is RECOMMENDED that RPs and Repository Servers follow the Best
+ Current Practices outlined in [RFC7525] on the use of HTTPS
+ [RFC7230]. RPs SHOULD do TLS certificate and host name validation
+ using subjectAltName dNSName identities as described in [RFC6125].
+ The rules and guidelines defined in [RFC6125] apply here, with the
+ following considerations:
+
+ o RPs and Repository Servers SHOULD support the DNS-ID identifier
+ type. The DNS-ID identifier type SHOULD be present in Repository
+ Server certificates.
+
+ o DNS names in Repository Server certificates SHOULD NOT contain the
+ wildcard character "*".
+
+
+
+
+Huston, et al. Standards Track [Page 7]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ o This protocol does not require the use of SRV-IDs.
+
+ o This protocol does not require the use of URI-IDs.
+
+5. Security Considerations
+
+ Compromise of a TA private key permits unauthorized parties to
+ masquerade as a TA, with potentially severe consequences. Reliance
+ on an inappropriate or incorrect TA has similar potentially severe
+ consequences.
+
+ This TAL does not directly provide a list of resources covered by the
+ referenced self-signed CA certificate. Instead, the RP is referred
+ to the TA itself and the INR extension(s) within this certificate.
+ This provides necessary operational flexibility, but it also allows
+ the certificate issuer to claim to be authoritative for any resource.
+ RPs should either (1) have great confidence in the issuers of such
+ certificates that they are configuring as TAs or (2) issue their own
+ self-signed certificate as a TA and, in doing so, impose constraints
+ on the subordinate certificates.
+
+6. IANA Considerations
+
+ This document has no IANA actions.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+ Addresses and AS Identifiers", RFC 3779,
+ DOI 10.17487/RFC3779, June 2004,
+ <https://www.rfc-editor.org/info/rfc3779>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+ <https://www.rfc-editor.org/info/rfc4648>.
+
+
+
+
+Huston, et al. Standards Track [Page 8]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
+ Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
+ <https://www.rfc-editor.org/info/rfc5198>.
+
+ [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, DOI 10.17487/RFC5280, May 2008,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
+ Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
+ <https://www.rfc-editor.org/info/rfc5781>.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
+ March 2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+ [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
+ Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+ February 2012, <https://www.rfc-editor.org/info/rfc6480>.
+
+ [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+ X.509 PKIX Resource Certificates", RFC 6487,
+ DOI 10.17487/RFC6487, February 2012,
+ <https://www.rfc-editor.org/info/rfc6487>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Message Syntax and Routing",
+ RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <https://www.rfc-editor.org/info/rfc7230>.
+
+ [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
+ "Recommendations for Secure Use of Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
+ May 2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+ [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
+ "Resource Public Key Infrastructure (RPKI) Trust Anchor
+ Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
+ <https://www.rfc-editor.org/info/rfc7730>.
+
+
+
+
+
+
+Huston, et al. Standards Track [Page 9]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+ [X.509] ITU-T, "Information technology - Open Systems
+ Interconnection - The Directory: Public-key and attribute
+ certificate frameworks", ITU-T Recommendation X.509,
+ October 2016, <https://www.itu.int/rec/T-REC-X.509>.
+
+7.2. Informative References
+
+ [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+ Nicholas, "Internet X.509 Public Key Infrastructure:
+ Certification Path Building", RFC 4158,
+ DOI 10.17487/RFC4158, September 2005,
+ <https://www.rfc-editor.org/info/rfc4158>.
+
+ [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
+ Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
+ <https://www.rfc-editor.org/info/rfc5914>.
+
+ [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
+ "Manifests for the Resource Public Key Infrastructure
+ (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
+ <https://www.rfc-editor.org/info/rfc6486>.
+
+Acknowledgements
+
+ This approach to TA material was originally described by Robert
+ Kisteleki.
+
+ The authors acknowledge the contributions of Rob Austein and Randy
+ Bush, who assisted with drafting this document and with helpful
+ review comments.
+
+ The authors acknowledge the work of Roque Gagliano, Terry Manderson,
+ and Carlos Martinez-Cagnazzo in developing the ideas behind the
+ inclusion of multiple URIs in the TAL.
+
+ The authors acknowledge Job Snijders for suggesting the inclusion of
+ comments at the start of the TAL.
+
+
+
+
+
+
+
+
+
+Huston, et al. Standards Track [Page 10]
+
+RFC 8630 HTTPS TAL August 2019
+
+
+Authors' Addresses
+
+ Geoff Huston
+ APNIC
+
+ Email: gih@apnic.net
+ URI: https://www.apnic.net
+
+
+ Samuel Weiler
+ W3C/MIT
+
+ Email: weiler@csail.mit.edu
+
+
+ George Michaelson
+ APNIC
+
+ Email: ggm@apnic.net
+ URI: https://www.apnic.net
+
+
+ Stephen Kent
+ Unaffiliated
+
+ Email: kent@alum.mit.edu
+
+
+ Tim Bruijnzeels
+ NLnet Labs
+
+ Email: tim@nlnetlabs.nl
+ URI: https://www.nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al. Standards Track [Page 11]
+