< draft-ietf-sidrops-rpki-has-no-identity-06.txt		draft-ietf-sidrops-rpki-has-no-identity-07.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: 16 October 2022 Vigil Security		Expires: 21 October 2022 Vigil Security
	14 April 2022		19 April 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-06		draft-ietf-sidrops-rpki-has-no-identity-07
	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 'holder'		RPKI can be associated with the real-world identity of the 'holder'
	of an INR. This document attempts to put that notion to rest.		of an INR. This document specifies that RPKI does not associate to
			the INR holder.
	Requirements Language		Requirements Language
	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.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 42 ¶
	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 16 October 2022.		This Internet-Draft will expire on 21 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text 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 Revised 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 RPKI is for Authorization . . . . . . . . . . . . . . . . 3		2. The RPKI is for Authorization . . . . . . . . . . . . . . . . 3
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		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
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	INR 'holder' of those resources with the inappropriate expectation		INR 'holder' of those resources with the inappropriate expectation
	that the signature will be considered an attestation to the		that the signature will be considered an attestation to the
	authenticity of the document content. But in reality, the RPKI		authenticity of the document content. But in reality, the RPKI
	certificate is only an authorization to speak for the explicitly		certificate is only an authorization to speak for the explicitly
	identified INRs; it is explicitly not intended for authentication of		identified INRs; it is explicitly not intended for authentication of
	the 'holders' of the INRs. This situation is emphasized in		the 'holders' of the INRs. This situation is emphasized in
	Section 2.1 of [RFC6480].		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 the private key attesting to that they are the		and Sushi (BB&S) could use the private key attesting to that they are
	holder of their AS in the RPKI to sign a Letter of Authorization		the holder of their AS in the RPKI to sign a Letter of Authorization
	(LOA) for some other party to rack and stack hardware owned by BB&S.		(LOA) for some other party to rack and stack hardware owned by BB&S.
	Unfortunately, while this may be technically possible, it is neither		Unfortunately, while this may be technically possible, it is neither
	appropriate nor meaningful.		appropriate nor meaningful.
	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 make		holder(s) of those INRs. The RPKI provides authorization to make
	assertions only regarding named IP address blocks, AS numbers, etc.		assertions only regarding Internet Number Resources, such as IP
			prefixes or AS numbers, and data such as ASPA
			[I-D.ietf-sidrops-aspa-profile]records.
	In short, avoid the desire to use RPKI certificates for any purpose		In short, avoid the desire to use RPKI certificates for any purpose
	other than the verification of authorizations associated with the		other than the verification of authorizations associated with the
	delegation of INRs or attestations related to INRs. Instead,		delegation of INRs or attestations related to INRs. Instead,
	recognize that these authorizations and attestations take place		recognize that these authorizations and attestations take place
	irrespective of the identity of a RPKI private key holder.		irrespective of the identity of a RPKI private key holder.
	2. The RPKI is for Authorization		2. The RPKI is for Authorization
	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 by design.		That the RPKI does not authenticate real-world identity is by design.
	If it tried to do so, aside from the liability, it would end in a		If it tried to do so, aside from the liability, it would end in a
	world of complexity with no proof of termination, as X.400 learned.		world of complexity with no proof of termination.
	Registries such as the Regional Internet Registries (RIRs) provide		Registries such as the Regional Internet Registries (RIRs) provide
	INR to real-world identity mapping through WHOIS, [RFC3912], and		INR to real-world identity mapping through WHOIS, [RFC3912], and
	similar services. They claim to be authoritative, at least for the		similar services. They claim to be authoritative, at least for the
	INRs which they allocate.		INRs which they allocate.
	PKI operations MUST NOT be performed with RPKI certificates other		That is, RPKI-based credentials of INRs MUST NOT be used to
	than exactly as described, and for the purposes described, in		authenticate real-world documents or transactions. That might be
	[RFC6480]. That is, RPKI-based credentials of INRs MUST NOT be used		done with some formal external authentication of authority allowing
	to authenticate real-world documents or transactions without some		an otherwise anonymous INR holder to authenticate the particular
	formal external authentication of the INR and the authority for the		document or transaction. Given such external, i.e. non-RPKI,
	actually anonymous INR holder to authenticate the particular document		verification of authority, the use of RPKI-based credentials adds no
	or transaction.		authenticity.
	I.e., RPKI-based credentials of INRs MUST NOT be used to authenticate
	real-world documents or transactions without some formal external
	authentication of the INR and the authority for the actually
	anonymous INR holder to authenticate the particular document or
	transaction.
	Given sufficient external, i.e. non-RPKI, verification of authority,
	the use of RPKI-based credentials seems superfluous.
	3. Discussion		3. Discussion
	The RPKI base document, [RFC6480], Section 2.1 says explicitly "An		The RPKI base document, [RFC6480], Section 2.1 says explicitly "An
	important property of this PKI is that certificates do not attest to		important property of this PKI is that certificates do not attest to
	the identity of the subject."		the identity of the subject."
	The Template for a Certification Practice Statement (CPS) for the		The Template for a Certification Practice Statement (CPS) for the
	Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear		Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear
	that "The Subject name in each certificate SHOULD NOT be meaningful;"		that "The Subject name in each certificate SHOULD NOT be meaningful;"
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 28 ¶
	that INR. They could be just an INR administrative person.		that INR. They could be just an INR administrative person.
	Autonomous System Numbers do not identify real-world entities. They		Autonomous System Numbers do not identify real-world entities. They
	are identifiers some network operators 'own' and are only used for		are identifiers some network operators 'own' and are only used for
	loop detection in routing. They have no inherent semantics other		loop detection in routing. They have no inherent semantics other
	than uniqueness.		than uniqueness.
	4. Security Considerations		4. Security Considerations
	Attempts to use RPKI data to authenticate real-world documents or		Attempts to use RPKI data to authenticate real-world documents or
	other artifacts requiring identity are invalid and misleading.		other artifacts requiring identity, while possibly cryptographically
			valid within the RPKI, are misleading as to any authenticity.
	When a document is signed with the private key associated with an		When a document is signed with the private key associated with an
	RPKI certificate, the signer is speaking for the INRs, the IP address		RPKI certificate, the signer is speaking for the INRs, the IP address
	space and Autonomous System (AS) numbers, in the certificate. This		space and Autonomous System (AS) numbers, in the certificate. This
	is not an identity; this is an authorization. In schemes such as		is not an identity; this is an authorization. In schemes such as
	[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the		[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the
	signed message further narrows this scope of INRs. The INRs in the		signed message further narrows this scope of INRs. The INRs in the
	message are a subset of the INRs in the certificate. If the		message are a subset of the INRs in the certificate. If the
	signature is valid, the message content comes from a party that is		signature is valid, the message content comes from a party that is
	authorized to speak for that subset of INRs.		authorized to speak for that subset of INRs.
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 9 ¶
	transactions or documents for which the INR manager has no authority.		transactions or documents for which the INR manager has no authority.
	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, Geoff Huston for some more formal text, Ties de Kock for		discussion, Geoff Huston for some more formal text, Ties de Kock for
	useful suggestions, and last but not least, Biff for the loan of		useful suggestions, many directorate and IESG reviewers, and last but
	Bill's Bait and Sushi.		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>.
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 46 ¶
	[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>.
	[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for		[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for
	BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,		BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,
	<https://www.rfc-editor.org/info/rfc8635>.		<https://www.rfc-editor.org/info/rfc8635>.
	7.2. Informative References		7.2. Informative References
			[I-D.ietf-sidrops-aspa-profile]
			Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J.,
			and R. Housley, "A Profile for Autonomous System Provider
			Authorization", Work in Progress, Internet-Draft, draft-
			ietf-sidrops-aspa-profile-07, 31 January 2022,
			<https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa-
			profile-07.txt>.
	[I-D.ietf-sidrops-rpki-rsc]		[I-D.ietf-sidrops-rpki-rsc]
	Snijders, J., Harrison, T., and B. Maddison, "Resource		Snijders, J., Harrison, T., and B. Maddison, "Resource
	Public Key Infrastructure (RPKI) object profile for Signed		Public Key Infrastructure (RPKI) object profile for Signed
	Checklist (RSC)", Work in Progress, Internet-Draft, draft-		Checklist (RSC)", Work in Progress, Internet-Draft, draft-
	ietf-sidrops-rpki-rsc-06, 12 February 2022,		ietf-sidrops-rpki-rsc-06, 12 February 2022,
	<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-		<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
	rsc-06.txt>.		rsc-06.txt>.
	[I-D.ietf-sidrops-rpki-rta]		[I-D.ietf-sidrops-rpki-rta]
	Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,		Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
End of changes. 12 change blocks.
	29 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/