< draft-ietf-sidrops-rpki-has-no-identity-02.txt		draft-ietf-sidrops-rpki-has-no-identity-03.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & Internet Initiative Japan		Internet-Draft Arrcus & Internet Initiative Japan
	Intended status: Standards Track R. Housley		Intended status: Standards Track R. Housley
	Expires: 27 March 2022 Vigil Security		Expires: 10 July 2022 Vigil Security
	23 September 2021		6 January 2022
	The I in RPKI does not stand for Identity		The I in RPKI does not stand for Identity
	draft-ietf-sidrops-rpki-has-no-identity-02		draft-ietf-sidrops-rpki-has-no-identity-03
	Abstract		Abstract
	There is a false notion that Internet Number Resources (INRs) in the		There is a false notion that Internet Number Resources (INRs) in the
	RPKI can be associated with the real world identity of the 'owner' of		RPKI can be associated with the real world identity of the 'owner' of
	an INR. This document attempts to put that notion to rest.		an INR. This document attempts to put that notion to rest.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 27 March 2022.		This Internet-Draft will expire on 10 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3		2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Resource Public Key Infrastructure (RPKI), see [RFC6480],		The Resource Public Key Infrastructure (RPKI), see [RFC6480],
	"represents the allocation hierarchy of IP address space and		"Represents the allocation hierarchy of IP address space and
	Autonomous System (AS) numbers." Though since, it has grown to		Autonomous System (AS) numbers," which are collectively known as
			Internet Number Resources (INRs). Though since, it has grown to
	include other similar resource and routing data, e.g. Router Keying		include other similar resource and routing data, e.g. Router Keying
	for BGPsec, [RFC8635].		for BGPsec, [RFC8635].
	In security terms the phrase "Public Key" implies there are also		In security terms the phrase "Public Key" implies there is also a
	private keys, a la [RFC5280]. And, as the RPKI has strong authority		corresponding private key [RFC5280]. The RPKI's strong authority
	over ownership of Internet Number Resources (INRs), there is a desire		over ownership of INRs has misled some people toward a desire to use
	to use the private keys to sign arbitrary documents to attest that		RPKI private keys to sign arbitrary documents attesting that the INR
	the 'owner' of those resources has attested to the authenticity of		'owner' of those resources has attested to the authenticity of the
	those documents. But in reality, it is an authorization to speak for		document content. But in reality, the RPKI certificate is only an
	the named IP address blocks and AS numbers themselves, not their		authorization to speak for for the explicitly identified INRs; it is
	unidentifiable owners.		explicitly not intended for authentication of the 'owners' of the
			INRs. This situation is emphasized in Section 2.1 of [RFC6480].
	It has been suggested that one could authenticate real world business		It has been suggested that one could authenticate real world business
	transactions with the signatures of INR holders. E.g. Bill's Bait		transactions with the signatures of INR holders. E.g. Bill's Bait
	and Sushi could use their AS in the RPKI to sign a Letter of		and Sushi could use their AS in the RPKI to sign a Letter of
	Authorization (LOA) for some other party to rack and stack hardware		Authorization (LOA) for some other party to rack and stack hardware
	owned by BB&S. Unfortunately, this is not formally feasible.		owned by BB&S. Unfortunately, this is not formally feasible.
	The I in RPKI actually stands for "Infrastructure," as in Resource		The I in RPKI actually stands for "Infrastructure," as in Resource
	Public Key Infrastructure, not for "Identity". In fact, the RPKI		Public Key Infrastructure, not for "Identity". In fact, the RPKI
	does not provide any association between INRs and the real world		does not provide any association between INRs and the real world
	holder(s) of those INRs. The RPKI provides authorization to speak		holder(s) of those INRs. The RPKI provides authorization to speak
	for the named IP address blocks and AS numbers.		for the named IP address blocks and AS numbers.
			In short, avoid the desire to use RPKI certificates for any purpose
			other than the verification of authorizations associated with the
			delegation of INRs or attestations related to INRs. Instead,
			recognize that these authorizations and attestations take place
			irrespective of the identity of a RPKI private key holder.
	2. The Bottom Line		2. The Bottom Line
	The RPKI was designed and specified to sign certificates for use		The RPKI was designed and specified to sign certificates for use
	within the RPKI itself and to generate Route Origin Authorizations		within the RPKI itself and to generate Route Origin Authorizations
	(ROAs), [RFC6480], for use in routing. Its design intentionally		(ROAs), [RFC6480], for use in routing. Its design intentionally
	precluded use for attesting to real world identity as, among other		precluded use for attesting to real world identity as, among other
	issues, it would expose the Certification Authority (CA) to		issues, it would expose the Certification Authority (CA) to
	liability.		liability.
	That the RPKI does not authenticate real world identity is a feature		That the RPKI does not authenticate real world identity is a feature
	skipping to change at page 5, line 46 ¶		skipping to change at page 6, line 8 ¶
	anonymous INR holder to authenticate the particular document or		anonymous INR holder to authenticate the particular document or
	transaction.		transaction.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
	6. Acknowledgments		6. Acknowledgments
	The authors thank George Michaelson and Job Snijders for lively		The authors thank George Michaelson and Job Snijders for lively
	discussion, Ties de Kock for useful suggestions, and last but not		discussion, Geoff Huston for some more formal text, Ties de Kock for
	least, Biff for the loan of Bill's Bait and Sushi.		useful suggestions, and last but not least, Biff for the loan of
			Bill's Bait and Sushi.
	7. References		7. References
	7.1. Normative References		7.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>.
End of changes. 10 change blocks.
	23 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/