rfc9642v4.txt		rfc9642.txt
	skipping to change at line 1683 ¶		skipping to change at line 1683 ¶
	<cert-data>BASE64VALUE=</cert-data>		<cert-data>BASE64VALUE=</cert-data>
	</certificate>		</certificate>
	</certificates>		</certificates>
	</asymmetric-key>		</asymmetric-key>
	</asymmetric-keys>		</asymmetric-keys>
	</keystore>		</keystore>
	4. Encrypting Keys in Configuration		4. Encrypting Keys in Configuration
	This section describes an approach that enables both the symmetric		This section describes an approach that enables both the symmetric
	and asymmetric keys on a server to be encrypted, such that		and asymmetric keys on a server to be encrypted, such that backup/
	traditional backup/restore procedures can be used without concern for		restore procedures can be used without concern for raw key data being
	raw key data being compromised when in transit.		compromised when in transit.
	The approach presented in this section is not normative. This		The approach presented in this section is not normative. This
	section answers how a configuration containing secrets that are		section answers how a configuration containing secrets that are
	encrypted by a built-in key (Section 3) can be backed up from one		encrypted by a built-in key (Section 3) can be backed up from one
	server and restored on a different server when each server has unique		server and restored on a different server when each server has unique
	master keys. The API defined by the "ietf-keystore" YANG module		primary keys. The API defined by the "ietf-keystore" YANG module
	presented in this document is sufficient to support the workflow		presented in this document is sufficient to support the workflow
	described in this section.		described in this section.
	4.1. Key Encryption Key		4.1. Key Encryption Key
	The ability to encrypt configured keys is predicated on the existence		The ability to encrypt configured keys is predicated on the existence
	of a key encryption key (KEK). There may be any number of KEKs in a		of a key encryption key (KEK). There may be any number of KEKs in a
	server. A KEK, by its namesake, is a key that is used to encrypt		server. A KEK, by its namesake, is a key that is used to encrypt
	other keys. A KEK MAY be either a symmetric key or an asymmetric		other keys. A KEK MAY be either a symmetric key or an asymmetric
	key.		key.
	skipping to change at line 1762 ¶		skipping to change at line 1762 ¶
	longer be operational.		longer be operational.
	In other deployments, an organization's crypto officer, possessing a		In other deployments, an organization's crypto officer, possessing a
	KEK's cleartext value, configures the same KEK on the second server,		KEK's cleartext value, configures the same KEK on the second server,
	presumably as a hidden key or a key protected by access control, so		presumably as a hidden key or a key protected by access control, so
	that the cleartext value is not disclosed to regular administrators.		that the cleartext value is not disclosed to regular administrators.
	However, this approach creates high coupling to and dependency on the		However, this approach creates high coupling to and dependency on the
	crypto officers that does not scale in production environments.		crypto officers that does not scale in production environments.
	In order to decouple the crypto officers from the regular		In order to decouple the crypto officers from the regular
	administrators, a special KEK, called the "master key" (MK), may be		administrators, a special KEK, called the "primary key" (PK), may be
	used.		used.
	An MK is commonly a globally unique built-in (see Section 3)		A PK is commonly a globally unique built-in (see Section 3)
	asymmetric key. The private raw key value, due to its long lifetime,		asymmetric key. The private raw key value, due to its long lifetime,
	is hidden (i.e., "hidden-private-key"; see Section 2.1.4.5. of		is hidden (i.e., "hidden-private-key"; see Section 2.1.4.5. of
	[RFC9640]). The raw public key value is often contained in an		[RFC9640]). The raw public key value is often contained in an
	identity certificate (e.g., IDevID). How to configure an MK during		identity certificate (e.g., IDevID). How to configure an PK during
	the manufacturing process is outside the scope of this document.		the manufacturing process is outside the scope of this document.
	Assuming the server has an MK, the MK can be used to encrypt a		Assuming the server has a PK, the PK can be used to encrypt a "shared
	"shared KEK", which is then used to encrypt the keys configured by		KEK", which is then used to encrypt the keys configured by regular
	regular administrators.		administrators.
	With this extra level of indirection, it is possible for a crypto		With this extra level of indirection, it is possible for a crypto
	officer to encrypt the same KEK for a multiplicity of servers offline		officer to encrypt the same KEK for a multiplicity of servers offline
	using the public key contained in their identity certificates. The		using the public key contained in their identity certificates. The
	crypto officer can then safely hand off the encrypted KEKs to regular		crypto officer can then safely hand off the encrypted KEKs to regular
	administrators responsible for server installations, including		administrators responsible for server installations, including
	migrations.		migrations.
	In order to migrate the configuration from a first server, an		In order to migrate the configuration from a first server, an
	administrator would need to make just a single modification to the		administrator would need to make just a single modification to the
	skipping to change at line 1798 ¶		skipping to change at line 1798 ¶
	configuration (containing many encrypted keys) can be loaded into the		configuration (containing many encrypted keys) can be loaded into the
	second server while enabling the second server to decrypt all the		second server while enabling the second server to decrypt all the
	encrypted keys in the configuration.		encrypted keys in the configuration.
	The following diagram illustrates this idea:		The following diagram illustrates this idea:
	+-------------+ +-------------+		+-------------+ +-------------+
	| shared KEK | | shared KEK |		| shared KEK | | shared KEK |
	|(unencrypted)|-------------------------------> | (encrypted) |		|(unencrypted)|-------------------------------> | (encrypted) |
	+-------------+ encrypts offline using +-------------+		+-------------+ encrypts offline using +-------------+
	^ each server's MK |		^ each server's PK |
	| |		| |
	| |		| |
	| possesses \o |		| possesses \o |
	+-------------- |\ |		+-------------- |\ |
	/ \ shares with |		/ \ shares with |
	crypto +--------------------+		crypto +--------------------+
	officer |		officer |
	|		|
	|		|
	+----------------------+ | +----------------------+		+----------------------+ | +----------------------+
	| server-1 | | | server-2 |		| server-1 | | | server-2 |
	| configuration | | | configuration |		| configuration | | | configuration |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| +----------------+ | | | +----------------+ |		| +----------------+ | | | +----------------+ |
	| | MK-1 | | | | | MK-2 | |		| | PK-1 | | | | | PK-2 | |
	| | (hidden) | | | | | (hidden) | |		| | (hidden) | | | | | (hidden) | |
	| +----------------+ | | | +----------------+ |		| +----------------+ | | | +----------------+ |
	| ^ | | | ^ |		| ^ | | | ^ |
	| | | | | | |		| | | | | | |
	| | | | | | |		| | | | | | |
	| | encrypted | | | | encrypted |		| | encrypted | | | | encrypted |
	| | by | | | | by |		| | by | | | | by |
	| | | | | | |		| | | | | | |
	| | | | | | |		| | | | | | |
	| +----------------+ | | | +----------------+ |		| +----------------+ | | | +----------------+ |
End of changes. 8 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.