rfc9925v2.txt		rfc9925.txt
	skipping to change at line 77 ¶		skipping to change at line 77 ¶
	1. Introduction		1. Introduction
	An X.509 certificate [RFC5280] relates two entities in the PKI:		An X.509 certificate [RFC5280] relates two entities in the PKI:
	information about a subject and a proof from an issuer. Viewing the		information about a subject and a proof from an issuer. Viewing the
	PKI as a graph with entities as nodes, as in [RFC4158], a certificate		PKI as a graph with entities as nodes, as in [RFC4158], a certificate
	is an edge between the subject and issuer.		is an edge between the subject and issuer.
	In some contexts, an application needs standalone subject information		In some contexts, an application needs standalone subject information
	instead of a certificate. In the graph model, the application needs		instead of a certificate. In the graph model, the application needs
	a node, not an edge. For example, certification path validation		a node, not an edge. For example, certification path validation
	(Section 6 of [RFC5280]) begins at a trust anchor or root		(Section 6 of [RFC5280]) begins at a trust anchor, sometimes referred
	certification authority (root CA). The application trusts this trust		to as a root certification authority (root CA). The application
	anchor information out-of-band and does not require an issuer's		trusts this trust anchor information out-of-band and does not require
	signature.		an issuer's signature.
	X.509 does not define a structure for this scenario. Instead, X.509		X.509 does not define a structure for this scenario. Instead, X.509
	trust anchors are often represented with "self-signed" certificates,		trust anchors are often represented with "self-signed" certificates,
	where the subject's key signs over itself. Other formats, such as		where the subject's key signs over itself. Other formats, such as
	[RFC5914], exist to convey trust anchors, but self-signed		[RFC5914], exist to convey trust anchors, but self-signed
	certificates remain widely used.		certificates remain widely used.
	Additionally, some TLS [RFC8446] server deployments use self-signed		Additionally, some TLS [RFC8446] server deployments use self-signed
	end entity certificates when they do not intend to present a CA-		end entity certificates when they do not intend to present a CA-
	issued identity, instead expecting the relying party to authenticate		issued identity, instead expecting the relying party to authenticate
End of changes. 1 change blocks.
	4 lines changed or deleted		4 lines changed or added
This html diff was produced by rfcdiff 1.48.