rfc9444v4.txt		rfc9444.txt
	skipping to change at line 155 ¶		skipping to change at line 155 ¶
	An organization that is responsible for the creation, issuance,		An organization that is responsible for the creation, issuance,
	revocation, and management of Certificates. The term applies		revocation, and management of Certificates. The term applies
	equally to both root CAs and subordinate CAs. Refer to [RFC5280]		equally to both root CAs and subordinate CAs. Refer to [RFC5280]
	for detailed information on Certification Authorities.		for detailed information on Certification Authorities.
	CSR:		CSR:
	Certificate Signing Request, as defined in [RFC2986].		Certificate Signing Request, as defined in [RFC2986].
	Ancestor Domain:		Ancestor Domain:
	A domain is an ancestor domain of a subdomain if it contains that		A domain is an ancestor domain of a subdomain if it contains that
	subdomain and has less labels than that subdomain. A domain		subdomain and has fewer labels than that subdomain. A domain
	cannot be an ancestor domain of itself. For example, for the host		cannot be an ancestor domain of itself. For example, for the host
	name nnn.mmm.example.com, both mmm.example.com and example.com are		name nnn.mmm.example.com, both mmm.example.com and example.com are
	ancestor domains of nnn.mmm.example.com. However,		ancestor domains of nnn.mmm.example.com. However,
	nnn.mmm.example.com is not an ancestor domain of		nnn.mmm.example.com is not an ancestor domain of
	nnn.mmm.example.com. Note that the comparisons here are done on		nnn.mmm.example.com. Note that the comparisons here are done on
	whole labels; that is, oo.example.com is not an ancestor domain of		whole labels; that is, oo.example.com is not an ancestor domain of
	ooo.example.com.		ooo.example.com.
	[RFC8555] defines the following object types that are used in this		[RFC8555] defines the following object types that are used in this
	document:		document:
	skipping to change at line 197 ¶		skipping to change at line 197 ¶
	3. ACME Workflow and Identifier Requirements		3. ACME Workflow and Identifier Requirements
	A typical ACME workflow for issuance of certificates is as follows:		A typical ACME workflow for issuance of certificates is as follows:
	1. Client POSTs a newOrder request that contains a set of identifier		1. Client POSTs a newOrder request that contains a set of identifier
	objects in the identifiers field of the ACME order object.		objects in the identifiers field of the ACME order object.
	2. Server replies with an order object that contains a set of links		2. Server replies with an order object that contains a set of links
	to authorization object(s) and a finalize URI.		to authorization object(s) and a finalize URI.
	3. Client sends POST-as-GET requests to retrieve the authorization		3. Client sends POST-as-GET request(s) to retrieve the authorization
	object(s), with the downloaded authorization object(s) containing		object(s), with the downloaded authorization object(s) containing
	the identifier that the client must prove that they control, and		the identifier that the client must prove that they control, and
	a set of links to associated challenges objects, one of which the		a set of links to associated challenge objects, one of which the
	client must fulfill.		client must fulfill.
	4. Client proves control over the identifier in the authorization		4. Client proves control over the identifier in the authorization
	object by completing one of the specified challenges, for		object by completing one of the specified challenges, for
	example, by publishing a DNS TXT record.		example, by publishing a DNS TXT record.
	5. Client POSTs a CSR to the finalize API.		5. Client POSTs a CSR to the finalize API.
	6. Server replies with an updated order object that includes a		6. Server replies with an updated order object that includes a
	certificate URI.		certificate URI.
End of changes. 3 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.