draft-ietf-sidrops-https-tal-06.txt		draft-ietf-sidrops-https-tal-07.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: July 27, 2019 G. Michaelson		Expires: September 5, 2019 G. Michaelson
	APNIC		APNIC
	S. Kent		S. Kent
	Unaffiliated		Unaffiliated
	T. Bruijnzeels		T. Bruijnzeels
	NLnet Labs		NLnet Labs
	January 23, 2019		March 4, 2019
	Resource Public Key Infrastructure (RPKI) Trust Anchor Locator		Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
	draft-ietf-sidrops-https-tal-06		draft-ietf-sidrops-https-tal-07
	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
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 July 27, 2019.		This Internet-Draft will expire on September 5, 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 6		3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 6
	4. HTTPS Considerations . . . . . . . . . . . . . . . . . . . . 7		4. HTTPS Considerations . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
			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 in
	a TAL.		a TAL.
	1.1. Terminology		1.1. Terminology
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document, are to be interpreted as described in [RFC2119].		"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.
	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
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	referenced self-signed CA certificate. Instead, the RP is referred		referenced self-signed CA certificate. Instead, the RP is referred
	to the trust anchor itself and the INR extension(s) within this		to the trust anchor itself and the INR extension(s) within this
	certificate. This provides necessary operational flexibility, but it		certificate. This provides necessary operational flexibility, but it
	also allows the certificate issuer to claim to be authoritative for		also allows the certificate issuer to claim to be authoritative for
	any resource. Relying parties should either have great confidence in		any resource. Relying parties should either have great confidence in
	the issuers of such certificates that they are configuring as trust		the issuers of such certificates that they are configuring as trust
	anchors, or they should issue their own self-signed certificate as a		anchors, or they should issue their own self-signed certificate as a
	trust anchor and, in doing so, impose constraints on the subordinate		trust anchor and, in doing so, impose constraints on the subordinate
	certificates.		certificates.
	6. Acknowledgements		6. IANA Considerations
			This document has no actions for IANA.
			7. Acknowledgements
	This approach to trust anchor material was originally described by		This approach to trust anchor material was originally described by
	Robert Kisteleki.		Robert Kisteleki.
	The authors acknowledge the contributions of Rob Austein and Randy		The authors acknowledge the contributions of Rob Austein and Randy
	Bush, who assisted with drafting this document and with helpful		Bush, who assisted with drafting this document and with helpful
	review comments.		review comments.
	The authors acknowledge work of Roque Gagliano, Terry Manderson, and		The authors acknowledge work of Roque Gagliano, Terry Manderson, and
	Carlos Martinez Cagnazzo in developing the ideas behind the inclusion		Carlos Martinez Cagnazzo in developing the ideas behind the inclusion
	of multiple URIs in the TAL.		of multiple URIs in the TAL.
	The authors acknowledge Job Snijders for suggesting the inclusion of		The authors acknowledge Job Snijders for suggesting the inclusion of
	comments at the start of the TAL.		comments at the start of the TAL.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 47 ¶
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	[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
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[X.509] TU-T Recommendation X.509, "The Directory: Public-key and		[X.509] TU-T Recommendation X.509, "The Directory: Public-key and
	attribute certificate frameworks", October 2012.		attribute certificate frameworks", October 2012.
	7.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
	Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,		Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
	<https://www.rfc-editor.org/info/rfc5914>.		<https://www.rfc-editor.org/info/rfc5914>.
End of changes. 11 change blocks.
	15 lines changed or deleted		26 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/