rfc9691v2.txt		rfc9691.txt
	skipping to change at line 19 ¶		skipping to change at line 19 ¶
	R. Austein		R. Austein
	Dragon Research Labs		Dragon Research Labs
	December 2024		December 2024
	A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor		A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor
	Keys (TAKs)		Keys (TAKs)
	Abstract		Abstract
	A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the		A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the
	Resource Public Key Infrastructure (RPKI) to locate and validate		Resource Public Key Infrastructure (RPKI) to locate and validate a
	Trust Anchor (TA) Certification Authority (CA) certificate used in		Trust Anchor (TA) Certification Authority (CA) certificate used in
	RPKI validation. This document defines an RPKI signed object for a		RPKI validation. This document defines an RPKI signed object for a
	Trust Anchor Key (TAK). A TAK object can be used by a TA to signal		Trust Anchor Key (TAK). A TAK object can be used by a TA to signal
	to RPs the location(s) of the accompanying CA certificate for the		to RPs the location(s) of the accompanying CA certificate for the
	current public key, as well as the successor public key and the		current public key, as well as the successor public key and the
	location(s) of its CA certificate. This object helps to support		location(s) of its CA certificate. This object helps to support
	planned key rollovers without impacting RPKI validation.		planned key rollovers without impacting RPKI validation.
	Status of This Memo		Status of This Memo
	skipping to change at line 134 ¶		skipping to change at line 134 ¶
	if it is present. If the TAK object lists only the current public		if it is present. If the TAK object lists only the current public
	key, then the RP continues processing as it would in the absence of a		key, then the RP continues processing as it would in the absence of a
	TAK object. If the TAK object includes a successor public key, the		TAK object. If the TAK object includes a successor public key, the
	RP starts a 30-day acceptance timer for that key and then continues		RP starts a 30-day acceptance timer for that key and then continues
	standard top-down validation with the current public key. During the		standard top-down validation with the current public key. During the
	following validation runs up until the expiry of the acceptance		following validation runs up until the expiry of the acceptance
	timer, the RP verifies that the public keys and the certificate URLs		timer, the RP verifies that the public keys and the certificate URLs
	listed in the TAK object remain unchanged. If they remain unchanged		listed in the TAK object remain unchanged. If they remain unchanged
	as at that time, then the RP will fetch the successor public key,		as at that time, then the RP will fetch the successor public key,
	update its local state with that public key and its associated		update its local state with that public key and its associated
	certification location(s), and continue processing using that public		certificate location(s), and continue processing using that public
	key.		key.
	The primary motivation for this work is being able to migrate from a		The primary motivation for this work is being able to migrate from a
	Hardware Security Module (HSM) produced by one vendor to one produced		Hardware Security Module (HSM) produced by one vendor to one produced
	by another, where the first vendor does not support exporting private		by another, where the first vendor does not support exporting private
	keys for use by the second. There may be other scenarios in which		keys for use by the second. There may be other scenarios in which
	key rollover is useful, though.		key rollover is useful, though.
	1.1. Requirements Notation		1.1. Requirements Notation
	skipping to change at line 394 ¶		skipping to change at line 394 ¶
	the RP to alert the user when a new successor public key is seen and		the RP to alert the user when a new successor public key is seen and
	when the relevant acceptance timer has expired. The user can then		when the relevant acceptance timer has expired. The user can then
	manually transition to the new TA public key data. This process		manually transition to the new TA public key data. This process
	ensures that the benefits of the acceptance timer period are still		ensures that the benefits of the acceptance timer period are still
	realised, as compared with TA public key update based on a TAL		realised, as compared with TA public key update based on a TAL
	distributed out of band by a TA.		distributed out of band by a TA.
	5. Maintaining Multiple TA Key Pairs		5. Maintaining Multiple TA Key Pairs
	An RP that can process TAK objects will only ever use one public key		An RP that can process TAK objects will only ever use one public key
	for validation: either the current public key or the successor public		for validation: either the current public key, or the successor
	key once the relevant acceptance timer has expired. By contrast, an		public key once the relevant acceptance timer has expired. By
	RP that cannot process TAK objects will continue to use the public		contrast, an RP that cannot process TAK objects will continue to use
	key details per its TAL (or equivalent manual configuration)		the public key details per its TAL (or equivalent manual
	indefinitely. As a result, even when a TA is using a TAK object in		configuration) indefinitely. As a result, even when a TA is using a
	order to migrate clients to a new public key, the TA may have to		TAK object in order to migrate clients to a new public key, the TA
	maintain the previous key pair for a period of time alongside the new		may have to maintain the previous key pair for a period of time
	key pair in order to ensure continuity of service for older clients.		alongside the new key pair in order to ensure continuity of service
			for older clients.
	For each TA key pair that a TA maintains, the signed material for		For each TA key pair that a TA maintains, the signed material for
	these key pairs MUST be published under different directories in the		these key pairs MUST be published under different directories in the
	context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA		context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA
	descriptions contained on the CA certificates [RFC6487]. Publishing		descriptions contained on the CA certificates [RFC6487]. Publishing
	objects under the same directory is potentially confusing for RPs and		objects under the same directory is potentially confusing for RPs and
	could lead to object invalidity in the event of filename collisions.		could lead to object invalidity in the event of filename collisions.
	Also, the CA certificates for each maintained key pair and the		Also, the CA certificates for each maintained key pair and the
	content published for each key pair MUST be equivalent (except for		content published for each key pair MUST be equivalent (except for
	skipping to change at line 426 ¶		skipping to change at line 427 ¶
	This means that the IP and Autonomous System (AS) resources contained		This means that the IP and Autonomous System (AS) resources contained
	on all current CA certificates for the maintained TA key pairs MUST		on all current CA certificates for the maintained TA key pairs MUST
	be the same. Furthermore, for any delegation of IP and AS resources		be the same. Furthermore, for any delegation of IP and AS resources
	to a child CA, the TA MUST have an equivalent CA certificate		to a child CA, the TA MUST have an equivalent CA certificate
	published under each of its key pairs. Any updates in delegations		published under each of its key pairs. Any updates in delegations
	MUST be reflected under each of its key pairs. A TA SHOULD NOT		MUST be reflected under each of its key pairs. A TA SHOULD NOT
	publish any other objects besides a CRL, a manifest, a single TAK		publish any other objects besides a CRL, a manifest, a single TAK
	object, and any number of CA certificates for delegation to child		object, and any number of CA certificates for delegation to child
	CAs.		CAs.
	If a TA uses a single remote publication server (per per [RFC8181])		If a TA uses a single remote publication server (per [RFC8181]) for
	for its key pairs per, then it MUST include all <publish/> and		its key pairs, then it MUST include all <publish/> and <withdraw/>
	<withdraw/> Protocol Data Units (PDUs) for the products of each of		Protocol Data Units (PDUs) for the products of each of its key pairs
	its key pairs in a single query in order to reduce the risk of RPs		in a single query in order to reduce the risk of RPs seeing
	seeing inconsistent data in the TA's RPKI repositories.		inconsistent data in the TA's RPKI repositories.
	If a TA uses multiple publication servers, then the content for		If a TA uses multiple publication servers, then the content for
	different key pairs will be out of sync at times. The TA SHOULD		different key pairs will be out of sync at times. The TA SHOULD
	ensure that the duration of these moments is limited to the shortest		ensure that the duration of these moments is limited to the shortest
	possible time. Furthermore, the following should be observed:		possible time. Furthermore, the following should be observed:
	* In cases where a CA certificate is revoked or replaced by a		* In cases where a CA certificate is revoked or replaced by a
	certificate with a reduced set of resources, these changes will		certificate with a reduced set of resources, these changes will
	not take effect fully until all the relevant repository		not take effect fully until all the relevant repository
	publication points have been updated. Given that TA private key		publication points have been updated. Given that TA private key
End of changes. 4 change blocks.
	15 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48.