doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7730.txt b/doc/rfc/rfc7730.txt
new file mode 100644
index 0000000..5cd8aa9
--- /dev/null
+++ b/doc/rfc/rfc7730.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Huston
+Request for Comments: 7730                                         APNIC
+Obsoletes: 6490                                                S. Weiler
+Category: Standards Track                                        Parsons
+ISSN: 2070-1721                                            G. Michaelson
+                                                                   APNIC
+                                                                 S. Kent
+                                                                     BBN
+                                                            January 2016
+
+
+     Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
+
+Abstract
+
+   This document defines a Trust Anchor Locator (TAL) for the Resource
+   Public Key Infrastructure (RPKI).  This document obsoletes RFC 6490
+   by adding support for multiple URIs in a TAL.
+
+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 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7730.
+
+Copyright Notice
+
+   Copyright (c) 2016 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.
+
+
+
+
+Huston, et al.               Standards Track                    [Page 1]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+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 . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Relying Party Use . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+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 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 trust anchor material and RPs.
+   This document obsoletes RFC 6490 by adding support for multiple URIs
+   in a TAL.
+
+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 document does not propose a new format for trust anchor
+   material.  A trust anchor 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 trust anchor 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
+   trust anchor to change, without needing to effect redistribution of
+   the trust anchor per se.  In the RPKI, certificates contain
+
+
+
+Huston, et al.               Standards Track                    [Page 2]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+   extensions that represent Internet Number Resources (INRs) [RFC3779].
+   The set of INRs associated with an entity acting as a trust anchor is
+   likely to change over time.  Thus, if one were to use the common PKI
+   convention of distributing a trust anchor to RPs in a secure fashion,
+   then this procedure would need to be repeated whenever the INR set
+   for the entity acting as a trust anchor changed.  By distributing the
+   TAL (in a secure fashion), instead of distributing the trust anchor,
+   this problem is avoided, i.e., the TAL is constant so long as the
+   trust anchor'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 URI
+   extension for that data structure.  However, the TAL format was
+   adopted by RPKI implementors prior to the PKIX trust anchor work, and
+   the RPKI implementer 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.
+
+   The TAL is an ordered sequence of:
+
+      1)  a URI section,
+
+      2)  a <CRLF> or <LF> line break,
+
+      3)  a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
+          encoded in Base64 (see Section 4 of [RFC4648]).  To avoid long
+          lines, <CRLF> or <LF> line breaks MAY be inserted into the
+          Base64-encoded string.
+
+   where the URI section is comprised of one of more of the ordered
+   sequence of:
+
+      1.1)  an rsync URI [RFC5781],
+
+      1.2)  a <CRLF> or <LF> line break.
+
+2.2.  TAL and Trust Anchor Certificate Considerations
+
+   Each rsync 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 trust anchor in certification path discovery [RFC4158] and
+   validation [RFC5280] [RFC3779].
+
+
+
+
+Huston, et al.               Standards Track                    [Page 3]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+   The validity interval of this trust anchor SHOULD reflect the
+   anticipated period of stability of the particular set of INRs that
+   are 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 due to changes in the INR
+   extension(s), when the certificate is renewed prior to expiration, or
+   for any reason other than a key change.
+
+   Because the public key in the TAL and the trust anchor MUST be
+   stable, this motivates operation of that CA in an offline mode.
+   Thus, the entity that issues the trust anchor SHOULD issue a
+   subordinate CA certificate that contains the same INRs (via the use
+   of the "inherit" option in the INR extensions of the subordinate
+   certificate).  This allows the entity that issues the trust anchor 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 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 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 trust anchor, 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 rsync URIs, then the same self-
+   signed CA certificate MUST be found at each referenced location.  In
+   order to increase operational resilience, it is RECOMMENDED that the
+   domain name parts of each of these URIs resolve to distinct IP
+
+
+
+Huston, et al.               Standards Track                    [Page 4]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+   addresses that are used by a diverse set of repository publication
+   points, and these IP addresses be included in distinct Route Origin
+   Authorizations (ROAs) objects signed by different CAs.
+
+2.3.  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.  Relying Party Use
+
+   In order to use the TAL to retrieve and validate a (putative) trust
+   anchor, an RP SHOULD:
+
+   1.  Retrieve the object referenced by (one of) the 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 trust anchor.  These tests 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 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 trust anchor referenced by the
+   TAL.
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 5]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+   In the case where a TAL contains multiple 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 trust anchor.
+   Some examples are:
+
+   o  Using the order provided in the TAL
+   o  Selecting the 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.  Security Considerations
+
+   Compromise of a trust anchor private key permits unauthorized parties
+   to masquerade as a trust anchor, with potentially severe
+   consequences.  Reliance on an inappropriate or incorrect trust anchor
+   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 trust anchor 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.  Relying parties should either have great confidence in
+   the issuers of such certificates that they are 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 subordinate
+   certificates.
+
+5.  References
+
+5.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,
+              <http://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,
+              <http://www.rfc-editor.org/info/rfc3779>.
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 6]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <http://www.rfc-editor.org/info/rfc4648>.
+
+   [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,
+              <http://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,
+              <http://www.rfc-editor.org/info/rfc5781>.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487,
+              DOI 10.17487/RFC6487, February 2012,
+              <http://www.rfc-editor.org/info/rfc6487>.
+
+   [X.509]    ITU-T, "The Directory: Public-key and attribute
+              certificate frameworks", ITU-T Recommendation X.509,
+              ISO/IEC 9594-8, October 2012.
+
+5.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,
+              <http://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,
+              <http://www.rfc-editor.org/info/rfc5914>.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+              February 2012, <http://www.rfc-editor.org/info/rfc6480>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6486>.
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 7]
+
+RFC 7730                RPKI Trust Anchor Locator           January 2016
+
+
+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 assisted with drafting this document and with helpful
+   review comments.
+
+   The authors acknowledge with work of Roque Gagliano, Terry Manderson,
+   and Carlos Martinez Cagnazzo in developing the ideas behind the
+   inclusion of multiple URIs in the TAL.
+
+Authors' Addresses
+
+   Geoff Huston
+   APNIC
+
+   Email: gih@apnic.net
+   URI:   http://www.apnic.net
+
+
+   Samuel Weiler
+   Parsons
+   7110 Samuel Morse Drive
+   Columbia, MD  21046
+   United States
+
+   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
+   United States
+
+   Email: kent@bbn.com
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 8]
+