draft-ietf-sidrops-https-tal-07.txt   draft-ietf-sidrops-https-tal-08.txt 
Network Working Group G. Huston Network Working Group G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Obsoletes: 7730 (if approved) S. Weiler Obsoletes: 7730 (if approved) S. Weiler
Intended status: Standards Track W3C/MIT Intended status: Standards Track W3C/MIT
Expires: September 5, 2019 G. Michaelson Expires: November 1, 2019 G. Michaelson
APNIC APNIC
S. Kent S. Kent
Unaffiliated Unaffiliated
T. Bruijnzeels T. Bruijnzeels
NLnet Labs NLnet Labs
March 4, 2019 April 30, 2019
Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
draft-ietf-sidrops-https-tal-07 draft-ietf-sidrops-https-tal-08
Abstract Abstract
This document defines a Trust Anchor Locator (TAL) for the Resource This document defines a Trust Anchor Locator (TAL) for the Resource
Public Key Infrastructure (RPKI). TALs allow Relying Parties in the Public Key Infrastructure (RPKI). TALs allow Relying Parties in the
RPKI to download the current Trust Anchor (TA) CA certificate from RPKI to download the current Trust Anchor (TA) CA certificate from
one or more locations, and verify that the key of this self-signed 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 certificate matches the key on the TAL. Thus, Relying Parties can be
configured with TA keys, but allow these TAs to change the content of configured with TA keys, but allow these TAs to change the content of
their CA certificate. In particular it allows TAs to change the set their CA certificate. In particular it allows TAs to change the set
of Internet Number Resources included in the RFC3779 extension of of IP Address Delegations and/or Autonomous System Identifier
their certificate. Delegations included in the RFC3779 extension of their certificate.
This document obsoletes the previous definition of Trust Anchor This document obsoletes the previous definition of Trust Anchor
Locators in RFC 7730 by adding support for HTTPS URIs. Locators in RFC 7730 by adding support for RFC3986 Uniform Resource
Identifiers (URIs) that use HTTPS as the scheme.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on November 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from RFC7730 . . . . . . . . . . . . . . . . . . 3
2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . 3 2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . 3
2.1. Trust Anchor Locator Motivation . . . . . . . . . . . . . 3 2.1. Trust Anchor Locator Motivation . . . . . . . . . . . . . 3
2.2. Trust Anchor Locator File Format . . . . . . . . . . . . 3 2.2. Trust Anchor Locator File Format . . . . . . . . . . . . 4
2.3. TAL and Trust Anchor Certificate Considerations . . . . . 4 2.3. TAL and Trust Anchor Certificate Considerations . . . . . 4
2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 6 3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 6
4. HTTPS Considerations . . . . . . . . . . . . . . . . . . . . 7 4. URI Scheme Considerations . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document defines a Trust Anchor Locator (TAL) for the Resource This document defines a Trust Anchor Locator (TAL) for the Resource
Public Key Infrastructure (RPKI) [RFC6480]. This format may be used Public Key Infrastructure (RPKI) [RFC6480]. This format may be used
to distribute trust anchor material using a mix of out-of-band and to distribute trust anchor material using a mix of out-of-band and
online means. Procedures used by Relying Parties (RPs) to verify online means. Procedures used by Relying Parties (RPs) to verify
RPKI signed objects SHOULD support this format to facilitate RPKI signed objects SHOULD support this format to facilitate
interoperability between creators of trust anchor material and RPs. interoperability between creators of trust anchor material and RPs.
This document obsoletes [RFC7730] by adding support for HTTPS URIs in This document obsoletes [RFC7730] by adding support for HTTPS URIs
a TAL. [RFC7230] in a TAL.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC7730
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 Relying Parties may not support this new format
yet. Therefore it is RECOMMENDED that a Trust Anchor operator
maintains a [RFC7730] TAL file for a time as well until they are
satisfied that RP tooling has been updated.
2. Trust Anchor Locator 2. Trust Anchor Locator
2.1. Trust Anchor Locator Motivation 2.1. Trust Anchor Locator Motivation
This document does not propose a new format for trust anchor This document does not propose a new format for trust anchor
material. A trust anchor in the RPKI is represented by a self-signed material. A trust anchor in the RPKI is represented by a self-signed
X.509 Certification Authority (CA) certificate, a format commonly X.509 Certification Authority (CA) certificate, a format commonly
used in PKIs and widely supported by RP software. This document used in PKIs and widely supported by RP software. This document
specifies a format for data used to retrieve and verify the specifies a format for data used to retrieve and verify the
authenticity of a trust anchor in a very simple fashion. That data authenticity of a trust anchor in a very simple fashion. That data
is referred to as the TAL. is referred to as the TAL.
The motivation for defining the TAL is to enable selected data in the The motivation for defining the TAL is to enable selected data in the
trust anchor to change, without needing to effect redistribution of trust anchor to change, without needing to redistribute the trust
the trust anchor per se. In the RPKI, certificates contain anchor per se.
extensions that represent Internet Number Resources (INRs) [RFC3779].
In the RPKI, certificates contain an RFC3779 extension, 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 (INR) contained in an
RPKI certificate.
The set of INRs associated with an entity acting as a trust anchor is 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 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, convention of distributing a trust anchor to RPs in a secure fashion,
then this procedure would need to be repeated whenever the INR set then this procedure would need to be repeated whenever the INR set
for the entity acting as a trust anchor changed. By distributing the for the entity acting as a trust anchor changed. By distributing the
TAL (in a secure fashion), instead of distributing the trust anchor, 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 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. trust anchor's public key and its location do not change.
The TAL is analogous to the TrustAnchorInfo data structure specified The TAL is analogous to the TrustAnchorInfo data structure specified
skipping to change at page 4, line 9 skipping to change at page 4, line 29
2.2. Trust Anchor Locator File Format 2.2. Trust Anchor Locator File Format
In this document we define a Trust Anchor URI as a URI that can be In this document we define a Trust Anchor URI as a URI that can be
used to retrieved a current Trust Anchor certificate. This URI MUST used to retrieved a current Trust Anchor certificate. This URI MUST
be either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]. be either an rsync URI [RFC5781], or an HTTPS URI [RFC7230].
The TAL is an ordered sequence of: The TAL is an ordered sequence of:
1. an optional comment section consisting of one or more lines each 1. an optional comment section consisting of one or more lines each
starting with the '#' character, followed by human readable starting with the '#' character, followed by human readable
informational UTF-8 text, and ending with a line break, 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, 2. a URI section, that is comprised of one or more ordered lines,
each containing a Trust Anchor URI, and ending with a line break, each containing a Trust Anchor URI, and ending with a line break,
3. a line break, 3. a line break,
4. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded 4. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded
in Base64 (see Section 4 of [RFC4648]). To avoid long lines, in Base64 (see Section 4 of [RFC4648]). To avoid long lines,
line breaks MAY be inserted into the Base64-encoded string. line breaks MAY be inserted into the Base64-encoded string.
Note that line breaks in this file can use either "<CRLF>" or "<LF>". Note that line breaks in this file can use either "<CRLF>" or "<LF>".
2.3. TAL and Trust Anchor Certificate Considerations 2.3. TAL and Trust Anchor Certificate Considerations
Each Trust Anchor URI in the TAL MUST reference a single object. It Each Trust Anchor URI in the TAL MUST reference a single object. It
MUST NOT reference a directory or any other form of collection of MUST NOT reference a directory or any other form of collection of
objects. objects. The referenced object MUST be a self-signed CA certificate
that conforms to the RPKI certificate profile [RFC6487]. This
The referenced object MUST be a self-signed CA certificate that certificate is the trust anchor in certification path discovery
conforms to the RPKI certificate profile [RFC6487]. This certificate [RFC4158] and validation [RFC5280] [RFC3779].
is the trust anchor in certification path discovery [RFC4158] and
validation [RFC5280] [RFC3779].
The validity interval of this trust anchor SHOULD reflect the The validity interval of this trust anchor is chosen such that the
anticipated period of stability of the particular set of INRs that "notBefore" time predates the moment that this certificate is
are associated with the putative trust anchor. published, and the "notAfter" time is after the planned time of re-
issuance of this certificate.
The INR extension(s) of this trust anchor MUST contain a non-empty 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 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 INR extension(s). The INR set described in this certificate is the
set of number resources for which the issuing entity is offering set of number resources for which the issuing entity is offering
itself as a putative trust anchor in the RPKI [RFC6480]. 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 public key used to verify the trust anchor MUST be the same as
the subjectPublicKeyInfo in the CA certificate and in the TAL. the subjectPublicKeyInfo in the CA certificate and in the TAL.
The trust anchor MUST contain a stable key. This key MUST NOT change The trust anchor MUST contain a stable key which does not change when
when the certificate is reissued due to changes in the INR the certificate is reissued due to changes in the INR extension(s),
extension(s), when the certificate is renewed prior to expiration, or when the certificate is renewed prior to expiration.
for any reason other than a key change.
Because the public key in the TAL and the trust anchor MUST be Because the public key in the TAL and the trust anchor MUST be
stable, this motivates operation of that CA in an offline mode. stable, this motivates operation of that CA in an offline mode. In
that case a subordinate CA certificate containing the same INRs, or
Thus, the entity that issues the trust anchor SHOULD issue a in theory any sub-set of INRs, can be issued for online operations.
subordinate CA certificate that contains the same INRs (via the use This allows the entity that issues the trust anchor to keep the
of the "inherit" option in the INR extensions of the subordinate corresponding private key of this certificate offline, while issuing
certificate). This allows the entity that issues the trust anchor to all relevant child certificates under the immediate subordinate CA.
keep the corresponding private key of this certificate offline, while This measure also allows the Certificate Revocation List (CRL) issued
issuing all relevant child certificates under the immediate by that entity to be used to revoke the subordinate CA certificate in
subordinate CA. This measure also allows the Certificate Revocation the event of suspected key compromise of this online operational key
List (CRL) issued by that entity to be used to revoke the subordinate pair that is potentially more vulnerable.
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 The trust anchor MUST be published at a stable URI. When the trust
anchor is reissued for any reason, the replacement CA certificate anchor is reissued for any reason, the replacement CA certificate
MUST be accessible using the same URI. MUST be accessible using the same URI.
Because the trust anchor is a self-signed certificate, there is no 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 corresponding CRL that can be used to revoke it, nor is there a
manifest [RFC6486] that lists this certificate. manifest [RFC6486] that lists this certificate.
If an entity wishes to withdraw a self-signed CA certificate as a If an entity wishes to withdraw a self-signed CA certificate as a
skipping to change at page 7, line 5 skipping to change at page 7, line 22
o Selecting the Trust Anchor URI randomly from the available list o Selecting the Trust Anchor URI randomly from the available list
o Creating a prioritized list of URIs based on RP-specific o Creating a prioritized list of URIs based on RP-specific
parameters, such as connection establishment delay parameters, such as connection establishment delay
If the connection to the preferred URI fails, or the retrieved CA If the connection to the preferred URI fails, or the retrieved CA
certificate public key does not match the TAL public key, the RP certificate public key does not match the TAL public key, the RP
SHOULD retrieve the CA certificate from the next URI, according to SHOULD retrieve the CA certificate from the next URI, according to
the local preference ranking of URIs. the local preference ranking of URIs.
4. HTTPS Considerations 4. URI Scheme Considerations
Note that a Man in the Middle (MITM) cannot produce a CA certificate Please note that the RSYNC protocol provides neither transport
that would be considered valid according to the process described in security nor any means by which the Relying Party can validate that
Section 3. However, a MITM attack can be performed to prevent the they are connected to the proper host. There it is RECOMMENDED that
Relying Party from learning about an updated CA certificate. Because HTTPS is used as the preferred scheme.
of this, Relying Parties MUST do TLS certificate and host name
validation when they fetch a CA certificate using an HTTPS URI on a
TAL.
Relying Party tools SHOULD log any TLS certificate or host name Note that, although a Man in the Middle (MITM) cannot produce a CA
validation issues found, so that an operator can investigate the certificate that would be considered valid according to the process
cause. described in Section 3, this attack can prevent that the Relying
Party learns about an updated CA certificate.
Relying Parties 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 Relying Parties and Repository Servers follow It is RECOMMENDED that Relying Parties and Repository Servers follow
the Best Current Practices outlined in [RFC7525] on the use of HTTP the Best Current Practices outlined in [RFC7525] on the use of HTTP
over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS
certificate and host name validation using subjectAltName dNSName certificate and host name validation using subjectAltName dNSName
identities as described in [RFC6125]. The rules and guidelines identities as described in [RFC6125]. The rules and guidelines
defined in [RFC6125] apply here, with the following considerations: defined in [RFC6125] apply here, with the following considerations:
o Relying Parties and Repository Servers SHOULD support the DNS-ID o Relying Parties and Repository Servers SHOULD support the DNS-ID
identifier type. The DNS-ID identifier type SHOULD be present in identifier type. The DNS-ID identifier type SHOULD be present in
skipping to change at page 9, line 5 skipping to change at page 9, line 23
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[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., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
<https://www.rfc-editor.org/info/rfc5781>. <https://www.rfc-editor.org/info/rfc5781>.
skipping to change at page 9, line 51 skipping to change at page 10, line 25
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor "Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
<https://www.rfc-editor.org/info/rfc7730>. <https://www.rfc-editor.org/info/rfc7730>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.509] TU-T Recommendation X.509, "The Directory: Public-key and [X.509] ITU-T, "The Directory: Public-key and attribute
attribute certificate frameworks", October 2012. certificate frameworks", October 2012.
8.2. Informative References 8.2. Informative References
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure: Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, Certification Path Building", RFC 4158,
DOI 10.17487/RFC4158, September 2005, DOI 10.17487/RFC4158, September 2005,
<https://www.rfc-editor.org/info/rfc4158>. <https://www.rfc-editor.org/info/rfc4158>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
 End of changes. 24 change blocks. 
57 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/