rfc9444v1.txt		rfc9444.txt
	Internet Engineering Task Force (IETF) O. Friel		Internet Engineering Task Force (IETF) O. Friel
	Request for Comments: 9444 R. Barnes		Request for Comments: 9444 R. Barnes
	Category: Standards Track Cisco		Category: Standards Track Cisco
	ISSN: 2070-1721 T. Hollebeek		ISSN: 2070-1721 T. Hollebeek
	DigiCert		DigiCert
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	July 2023		August 2023
	Automated Certificate Management Environment (ACME) for Subdomains		Automated Certificate Management Environment (ACME) for Subdomains
	Abstract		Abstract
	This document specifies how Automated Certificate Management		This document specifies how Automated Certificate Management
	Environment (ACME) can be used by a client to obtain a certificate		Environment (ACME) can be used by a client to obtain a certificate
	for a subdomain identifier from a certification authority.		for a subdomain identifier from a certification authority.
	Additionally, this document specifies how a client can fulfill a		Additionally, this document specifies how a client can fulfill a
	challenge against an ancestor domain but may not need to fulfill a		challenge against an ancestor domain but may not need to fulfill a
	skipping to change at line 113 ¶		skipping to change at line 113 ¶
	a portion of the graph of all possible domain names.		a portion of the graph of all possible domain names.
	Domain Name:		Domain Name:
	An ordered list of one or more labels.		An ordered list of one or more labels.
	Fully-Qualified Domain Name (FQDN):		Fully-Qualified Domain Name (FQDN):
	This is often just a clear way of saying the same thing as "domain		This is often just a clear way of saying the same thing as "domain
	name of a node", as outlined above. However, the term is		name of a node", as outlined above. However, the term is
	ambiguous. Strictly speaking, a fully-qualified domain name would		ambiguous. Strictly speaking, a fully-qualified domain name would
	include every label, including the zero-length label of the root:		include every label, including the zero-length label of the root:
	such a name would be written "www.example.net." (note the		such a name would be written www.example.net. (note the
	terminating dot). But, because every name eventually shares the		terminating dot). But, because every name eventually shares the
	common root, names are often written relative to the root (such as		common root, names are often written relative to the root (such as
	"www.example.net") and are still called "fully qualified". This		www.example.net) and are still called "fully qualified". This
	term first appeared in [RFC0819]. In this document, names are		term first appeared in [RFC0819]. In this document, names are
	often written relative to the root.		often written relative to the root.
	The following definition for "subdomain" is taken from "DNS		The following definition for "subdomain" is taken from "DNS
	Terminology" [RFC8499] and reproduced here; however, the definition		Terminology" [RFC8499] and reproduced here; however, the definition
	is ambiguous and is further clarified below:		is ambiguous and is further clarified below:
	Subdomain:		Subdomain:
	"A domain is a subdomain of another domain if it is contained		"A domain is a subdomain of another domain if it is contained
	within that domain. This relationship can be tested by seeing if		within that domain. This relationship can be tested by seeing if
	the subdomain's name ends with the containing domain's name."		the subdomain's name ends with the containing domain's name."
	(Quoted from Section 3.1 of [RFC1034].) For example, in the host		(Quoted from Section 3.1 of [RFC1034].) For example, in the host
	name "nnn.mmm.example.com", both "mmm.example.com" and		name nnn.mmm.example.com, both mmm.example.com and
	"nnn.mmm.example.com" are subdomains of "example.com". Note that		nnn.mmm.example.com are subdomains of example.com. Note that the
	the comparisons here are done on whole labels; that is,		comparisons here are done on whole labels; that is,
	"ooo.example.com" is not a subdomain of "oo.example.com".		ooo.example.com is not a subdomain of oo.example.com.
	The definition is ambiguous as it appears to allow a subdomain to		The definition is ambiguous as it appears to allow a subdomain to
	include the given domain. That is, "mmm.example.com" ends with		include the given domain. That is, mmm.example.com ends with
	"mmm.example.com" and thus is a subdomain of itself. This document		mmm.example.com and thus is a subdomain of itself. This document
	interprets the first sentence of the above definition as meaning "a		interprets the first sentence of the above definition as meaning "a
	domain is a subdomain of a different domain if it is contained within		domain is a subdomain of a different domain if it is contained within
	that different domain". A domain cannot be a subdomain of itself.		that different domain". A domain cannot be a subdomain of itself.
	For example, "mmm.example.com" is not a subdomain of		For example, mmm.example.com is not a subdomain of mmm.example.com.
	"mmm.example.com".
	The following additional terms are used in this document:		The following additional terms are used in this document:
	Certification Authority (CA):		Certification Authority (CA):
	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 less 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		name nnn.mmm.example.com, both mmm.example.com and example.com are
	"example.com" are ancestor domains of "nnn.mmm.example.com".		ancestor domains of nnn.mmm.example.com. However,
	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		whole labels; that is, oo.example.com is not an ancestor domain of
	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:
	Order Object: An ACME order object represents a client's request for		Order Object: An ACME order object represents a client's request for
	a certificate and is used to track the progress of that order		a certificate and is used to track the progress of that order
	through to issuance.		through to issuance.
	Authorization Object: An ACME authorization object represents a		Authorization Object: An ACME authorization object represents a
	server's authorization for an account to represent an identifier.		server's authorization for an account to represent an identifier.
	skipping to change at line 192 ¶		skipping to change at line 191 ¶
	POST-as-GET Request:		POST-as-GET Request:
	When a client wishes to fetch a resource from the server, then it		When a client wishes to fetch a resource from the server, then it
	MUST send a POST request with a signed JSON Web Signature (JWS)		MUST send a POST request with a signed JSON Web Signature (JWS)
	body, where the JWS body is specified in ACME [RFC8555],		body, where the JWS body is specified in ACME [RFC8555],
	Section 6.2. ACME refers to these as "POST-as-GET" requests.		Section 6.2. ACME refers to these as "POST-as-GET" requests.
	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		1. Client POSTs a newOrder request that contains a set of identifier
	"identifiers".		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 requests 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,		the identifier that the client must prove that they control, and
	and a set of links to associated challenges objects, one of which		a set of links to associated challenges objects, one of which the
	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.
	7. Client sends a POST-as-GET request to the "certificate" URI to		7. Client sends a POST-as-GET request to the certificate URI to
	download the certificate.		download the certificate.
	ACME places the following restrictions on "identifiers":		ACME places the following restrictions on identifiers:
	* [RFC8555], Section 7.1.3: "The authorizations required are		* [RFC8555], Section 7.1.3: "The authorizations required are
	dictated by server policy; there may not be a 1:1 relationship		dictated by server policy; there may not be a 1:1 relationship
	between the order identifiers and the authorizations required."		between the order identifiers and the authorizations required."
	* [RFC8555], Section 7.1.4: The only type of "identifier" defined by		* [RFC8555], Section 7.1.4: The only type of identifier defined by
	the ACME specification is an FQDN: "The only type of identifier		the ACME specification is an FQDN: "The only type of identifier
	defined by this specification is a fully qualified domain name		defined by this specification is a fully qualified domain name
	(type: "dns"). The domain name MUST be encoded in the form in		(type: "dns"). The domain name MUST be encoded in the form in
	which it would appear in a certificate."		which it would appear in a certificate."
	* [RFC8555], Section 7.4: The "identifier" in the CSR request must		* [RFC8555], Section 7.4: The identifier in the CSR request must
	match the "identifier" in the newOrder request: "The CSR MUST		match the identifier in the newOrder request: "The CSR MUST
	indicate the exact same set of requested identifiers as the		indicate the exact same set of requested identifiers as the
	initial newOrder request."		initial newOrder request."
	* [RFC8555], Section 8.3: The "identifier", or FQDN, in the		* [RFC8555], Section 8.3: The identifier, or FQDN, in the
	authorization object must be used when fulfilling challenges via		authorization object must be used when fulfilling challenges via
	HTTP: "Construct a URL by populating the URL template ... where		HTTP: "Construct a URL by populating the URL template ... where
	the domain field is set to the domain name being verified."		the domain field is set to the domain name being verified."
	* [RFC8555], Section 8.4: The "identifier", or FQDN, in the		* [RFC8555], Section 8.4: The identifier, or FQDN, in the
	authorization object must be used when fulfilling challenges via		authorization object must be used when fulfilling challenges via
	DNS: "The client constructs the validation domain name by		DNS: "The client constructs the validation domain name by
	prepending the label "_acme-challenge" to the domain name being		prepending the label "_acme-challenge" to the domain name being
	validated."		validated."
	ACME does not mandate that the "identifier" in a newOrder request		ACME does not mandate that the identifier in a newOrder request
	matches the "identifier" in authorization objects.		matches the identifier in authorization objects.
	The ACME base document [RFC8555] only specifies the "dns" identifier		The ACME base document [RFC8555] only specifies the "dns" identifier
	type. Additional identifiers may be defined and registered in the		type. Additional identifiers may be defined and registered in the
	IANA [ACME-Identifier-Types] registry. For example, [RFC8738]		IANA [ACME-Identifier-Types] registry. For example, [RFC8738]
	specifies the "ip" identifier type. This document is only relevant		specifies the "ip" identifier type. This document is only relevant
	for the "dns" identifier type.		for the "dns" identifier type.
	Note that ACME supports multiple different validation methods that		Note that ACME supports multiple different validation methods that
	can be used to fulfill challenges and prove ownership of identifiers.		can be used to fulfill challenges and prove ownership of identifiers.
	Validation methods are registered in the IANA		Validation methods are registered in the IANA
	[ACME-Validation-Methods] registry. This document does not mandate		[ACME-Validation-Methods] registry. This document does not mandate
	use of any particular validation method or methods. ACME server		use of any particular validation method or methods. ACME server
	policy dictates which validation methods are supported. See		policy dictates which validation methods are supported. See
	Section 7.3 for more information on ACME server policy.		Section 7.3 for more information on ACME server policy.
	4. ACME Issuance of Subdomain Certificates		4. ACME Issuance of Subdomain Certificates
	As noted in the previous section, ACME [RFC8555] does not mandate		As noted in the previous section, ACME [RFC8555] does not mandate
	that the "identifier" in a newOrder request matches the "identifier"		that the identifier in a newOrder request matches the identifier in
	in authorization objects. This means that the ACME specification		authorization objects. This means that the ACME specification does
	does not preclude an ACME server processing newOrder requests and		not preclude an ACME server processing newOrder requests and issuing
	issuing certificates for a subdomain without requiring a challenge to		certificates for a subdomain without requiring a challenge to be
	be fulfilled against that explicit subdomain.		fulfilled against that explicit subdomain.
	ACME server policy could allow issuance of certificates for a		ACME server policy could allow issuance of certificates for a
	subdomain to a client where the client only has to fulfill an		subdomain to a client where the client only has to fulfill an
	authorization challenge for an ancestor domain of that subdomain.		authorization challenge for an ancestor domain of that subdomain.
	This allows a flow where a client proves ownership of, for example,		For example, this allows for a flow where a client proves ownership
	"example.org" and then successfully obtains a certificate for		of example.org and then successfully obtains a certificate for
	"sub.example.org".		sub.example.org.
	ACME server policy is out of scope of this document; however, some		ACME server policy is out of scope of this document; however, some
	commentary is provided in Section 7.3.		commentary is provided in Section 7.3.
	Clients need a mechanism to instruct the ACME server that they are		Clients need a mechanism to instruct the ACME server that they are
	requesting authorization for all subdomains subordinate to the		requesting authorization for all subdomains subordinate to the
	specified domain, as opposed to just requesting authorization for an		specified domain, as opposed to just requesting authorization for an
	explicit domain identifier. Clients need a mechanism to do this in		explicit domain identifier. Clients need a mechanism to do this in
	both newAuthz and newOrder requests. ACME servers need a mechanism		both newAuthz and newOrder requests. ACME servers need a mechanism
	to indicate to clients that authorization objects are valid for all		to indicate to clients that authorization objects are valid for all
	subdomains under the specified domain. These are described in this		subdomains under the specified domain. These are described in this
	section.		section.
	4.1. Authorization Object		4.1. Authorization Object
	ACME ([RFC8555], Section 7.1.4) defines the authorization object.		ACME ([RFC8555], Section 7.1.4) defines the authorization object.
	This document defines a new "subdomainAuthAllowed" field for the		This document defines a new subdomainAuthAllowed field for the
	authorization object. When ACME server policy allows authorization		authorization object. When ACME server policy allows authorization
	for subdomains subordinate to a domain, the server indicates this by		for subdomains subordinate to a domain, the server indicates this by
	including the new "subdomainAuthAllowed" field in the authorization		including the new subdomainAuthAllowed field in the authorization
	object for that domain identifier:		object for that domain identifier:
	subdomainAuthAllowed (optional, boolean): If present, this field		subdomainAuthAllowed (optional, boolean): If present, this field
	MUST be true for authorizations where ACME server policy allows		MUST be true for authorizations where ACME server policy allows
	certificates to be issued for any subdomain subordinate to the		certificates to be issued for any subdomain subordinate to the
	domain specified in the 'identifier' field of the authorization		domain specified in the identifier field of the authorization
	object.		object.
	The following example shows an authorization object for the domain		The following example shows an authorization object for the domain
	example.org, where the authorization covers the subdomains		example.org, where the authorization covers the subdomains
	subordinate to example.org.		subordinate to example.org.
	{		{
	"status": "valid",		"status": "valid",
	"expires": "2023-09-01T14:09:07.99Z",		"expires": "2023-09-01T14:09:07.99Z",
	skipping to change at line 330 ¶		skipping to change at line 329 ¶
	"type": "http-01",		"type": "http-01",
	"status": "valid",		"status": "valid",
	"token": "DGyRejmCefe7v4NfDGDKfA",		"token": "DGyRejmCefe7v4NfDGDKfA",
	"validated": "2014-12-01T12:05:58.16Z"		"validated": "2014-12-01T12:05:58.16Z"
	}		}
	],		],
	"subdomainAuthAllowed": true		"subdomainAuthAllowed": true
	}		}
	If the "subdomainAuthAllowed" field is not included, then the assumed		If the subdomainAuthAllowed field is not included, then the assumed
	default value is false.		default value is false.
	If ACME server policy allows issuance of certificates containing		If ACME server policy allows issuance of certificates containing
	wildcard identifiers under that authorization object, then the server		wildcard identifiers under that authorization object, then the server
	SHOULD include the "wildcard" field with a value of true, as per		SHOULD include the wildcard field with a value of true, as per
	[RFC8555], Section 7.1.4.		[RFC8555], Section 7.1.4.
	4.2. Pre-authorization		4.2. Pre-authorization
	The basic ACME workflow has authorization objects created reactively		The basic ACME workflow has authorization objects created reactively
	in response to a certificate order. ACME also allows for pre-		in response to a certificate order. ACME also allows for pre-
	authorization, where clients obtain authorization for an identifier		authorization, where clients obtain authorization for an identifier
	proactively, outside of the context of a specific issuance. With the		proactively, outside of the context of a specific issuance. With the
	ACME pre-authorization flow, a client can pre-authorize for a domain		ACME pre-authorization flow, a client can pre-authorize for a domain
	once and then issue multiple newOrder requests for certificates with		once and then issue multiple newOrder requests for certificates with
	identifiers in the subdomains subordinate to that domain.		identifiers in the subdomains subordinate to that domain.
	ACME ([RFC8555], Section 7.4.1) defines the "identifier" object for		ACME ([RFC8555], Section 7.4.1) defines the identifier object for
	newAuthz requests. This document defines a new		newAuthz requests. This document defines a new subdomainAuthAllowed
	"subdomainAuthAllowed" field for the "identifier" object:		field for the identifier object:
	subdomainAuthAllowed (optional, boolean): An ACME client sets this		subdomainAuthAllowed (optional, boolean): An ACME client sets this
	flag to indicate to the server that it is requesting an		flag to indicate to the server that it is requesting an
	authorization for the subdomains subordinate to the specified		authorization for the subdomains subordinate to the specified
	domain identifier value.		domain identifier value.
	Clients include the new "subdomainAuthAllowed" field in the		Clients include the new subdomainAuthAllowed field in the identifier
	"identifier" object of newAuthz requests to indicate that they are		object of newAuthz requests to indicate that they are requesting a
	requesting a subdomain authorization. In the following example of a		subdomain authorization. In the following example of a newAuthz
	newAuthz payload, the client is requesting pre-authorization for the		payload, the client is requesting pre-authorization for the
	subdomains subordinate to example.org.		subdomains subordinate to example.org.
	"payload": base64url({		"payload": base64url({
	"identifier": {		"identifier": {
	"type": "dns",		"type": "dns",
	"value": "example.org",		"value": "example.org",
	"subdomainAuthAllowed": true		"subdomainAuthAllowed": true
	}		}
	})		})
	If the server is willing to allow a single authorization for the		If the server is willing to allow a single authorization for the
	subdomains and there is not an existing authorization object for the		subdomains and there is not an existing authorization object for the
	identifier, then it will create an authorization object and include		identifier, then it will create an authorization object and include
	the "subdomainAuthAllowed" flag with a value of true.		the subdomainAuthAllowed flag with a value of true.
	If the server policy does not allow creation of subdomain		If the server policy does not allow creation of subdomain
	authorizations subordinate to that domain, the server can create an		authorizations subordinate to that domain, the server can create an
	authorization object for the indicated identifier and MAY include the		authorization object for the indicated identifier and MAY include the
	"subdomainAuthAllowed" flag with a value of false. If the server		subdomainAuthAllowed flag with a value of false. If the server
	creates an authorization object and does not include the		creates an authorization object and does not include the
	"subdomainAuthAllowed" flag, then the assumed value is false.		subdomainAuthAllowed flag, then the assumed value is false.
	In both scenarios, handling of the pre-authorization follows the		In both scenarios, handling of the pre-authorization follows the
	process documented in ACME [RFC8555], Section 7.4.1.		process documented in ACME [RFC8555], Section 7.4.1.
	4.3. New Orders		4.3. New Orders
	Clients need a mechanism to optionally indicate to servers whether or		Clients need a mechanism to optionally indicate to servers whether or
	not they are authorized to fulfill challenges against an ancestor		not they are authorized to fulfill challenges against an ancestor
	domain for a given identifier. For example, if a client places an		domain for a given identifier. For example, if a client places an
	order for an identifier foo.bar.example.org and is authorized to		order for an identifier foo.bar.example.org and is authorized to
	fulfill a challenge against the ancestor domains bar.example.org or		fulfill a challenge against the ancestor domains bar.example.org or
	example.org, then the client needs a mechanism to indicate control		example.org, then the client needs a mechanism to indicate control
	over the ancestor domains to the ACME server.		over the ancestor domains to the ACME server.
	In order to accomplish this, this document defines a new		In order to accomplish this, this document defines a new
	"ancestorDomain" field for the identifier that is included in order		ancestorDomain field for the identifier that is included in order
	objects.		objects.
	ancestorDomain (optional, string): This is an ancestor domain of the		ancestorDomain (optional, string): This is an ancestor domain of the
	requested identifier. The client MUST be able to fulfill a		requested identifier. The client MUST be able to fulfill a
	challenge against the ancestor domain.		challenge against the ancestor domain.
	This field specifies an ancestor domain of the identifier that the		This field specifies an ancestor domain of the identifier that the
	client has DNS control over and is capable of fulfilling challenges		client has DNS control over and is capable of fulfilling challenges
	against. Based on server policy, the server can choose to issue a		against. Based on server policy, the server can choose to issue a
	challenge against any ancestor domain of the identifier up to and		challenge against any ancestor domain of the identifier up to and
	including the specified "ancestorDomain" and create a corresponding		including the specified ancestorDomain and create a corresponding
	authorization object against the chosen identifier.		authorization object against the chosen identifier.
	In the following example of a newOrder payload, the client requests a		In the following example of a newOrder payload, the client requests a
	certificate for identifier foo.bar.example.org and indicates that it		certificate for identifier foo.bar.example.org and indicates that it
	can fulfill a challenge against the ancestor domain bar.example.org.		can fulfill a challenge against the ancestor domain bar.example.org.
	The server can then choose to issue a challenge against either		The server can then choose to issue a challenge against either
	foo.bar.example.org or bar.example.org identifiers.		foo.bar.example.org or bar.example.org identifiers.
	"payload": base64url({		"payload": base64url({
	"identifiers": [		"identifiers": [
	skipping to change at line 444 ¶		skipping to change at line 443 ¶
	"identifiers": [		"identifiers": [
	{ "type": "dns",		{ "type": "dns",
	"value": "foo.bar.example.org",		"value": "foo.bar.example.org",
	"ancestorDomain": "example.org" }		"ancestorDomain": "example.org" }
	],		],
	"notBefore": "2023-09-01T00:04:00+04:00",		"notBefore": "2023-09-01T00:04:00+04:00",
	"notAfter": "2023-09-08T00:04:00+04:00"		"notAfter": "2023-09-08T00:04:00+04:00"
	})		})
	If the client is unable to fulfill authorizations against an ancestor		If the client is unable to fulfill authorizations against an ancestor
	domain, the client should not include the "ancestorDomain" field.		domain, the client should not include the ancestorDomain field.
	Server newOrder handling generally follows the process documented in		Server newOrder handling generally follows the process documented in
	ACME (Section 7.4 of [RFC8555]). If the server is willing to allow		ACME (Section 7.4 of [RFC8555]). If the server is willing to allow
	subdomain authorizations for the domain specified in		subdomain authorizations for the domain specified in ancestorDomain,
	"ancestorDomain", then it creates an authorization object against		then it creates an authorization object against that ancestor domain
	that ancestor domain and includes the "subdomainAuthAllowed" flag		and includes the subdomainAuthAllowed flag with a value of true.
	with a value of true.
	If the server policy does not allow creation of subdomain		If the server policy does not allow creation of subdomain
	authorizations against that ancestor domain, then it can create an		authorizations against that ancestor domain, then it can create an
	authorization object for the indicated identifier value and SHOULD		authorization object for the indicated identifier value and SHOULD
	NOT include the "subdomainAuthAllowed" flag. As the client requested		NOT include the subdomainAuthAllowed flag. As the client requested a
	a subdomain authorization for the ancestor domain and not for the		subdomain authorization for the ancestor domain and not for the
	indicated identifier, there is no need for the server to include the		indicated identifier, there is no need for the server to include the
	"subdomainAuthAllowed" flag in the authorization object for the		subdomainAuthAllowed flag in the authorization object for the
	indicated identifier.		indicated identifier.
	4.4. Directory Object Metadata		4.4. Directory Object Metadata
	This document defines a new "subdomainAuthAllowed" ACME directory		This document defines a new subdomainAuthAllowed ACME directory
	metadata field. An ACME server can advertise support for		metadata field. An ACME server can advertise support for
	authorization of subdomains by including the "subdomainAuthAllowed"		authorization of subdomains by including the subdomainAuthAllowed
	boolean flag in its "ACME Directory Metadata Fields" registry:		boolean flag in its "ACME Directory Metadata Fields" registry:
	subdomainAuthAllowed (optional, bool): Indicates if an ACME server		subdomainAuthAllowed (optional, bool): Indicates if an ACME server
	supports authorization of subdomains.		supports authorization of subdomains.
	If not specified, then the assumed default value is false. If an		If not specified, then the assumed default value is false. If an
	ACME server supports authorization of subdomains, it can indicate		ACME server supports authorization of subdomains, it can indicate
	this by including this field with a value of "true".		this by including this field with a value of "true".
	5. Illustrative Call Flow		5. Illustrative Call Flow
	skipping to change at line 558 ¶		skipping to change at line 556 ¶
	| POST /certificate | |		| POST /certificate | |
	|--------------------------->| |		|--------------------------->| |
	| | |		| | |
	| 200 OK | |		| 200 OK | |
	| PEM SAN "sub2.example.org" | |		| PEM SAN "sub2.example.org" | |
	|<---------------------------| |		|<---------------------------| |
	* Step 1: Pre-authorization of ancestor domain.		* Step 1: Pre-authorization of ancestor domain.
	The client sends a newAuthz request for the ancestor domain and		The client sends a newAuthz request for the ancestor domain and
	includes the "subdomainAuthAllowed" flag in the identifier object.		includes the subdomainAuthAllowed flag in the identifier object.
	POST /acme/new-authz HTTP/1.1		POST /acme/new-authz HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "uQpSjlRb4vQVCjVYAyyUWg",		"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
	skipping to change at line 582 ¶		skipping to change at line 580 ¶
	"identifier": {		"identifier": {
	"type": "dns",		"type": "dns",
	"value": "example.org",		"value": "example.org",
	"subdomainAuthAllowed": true		"subdomainAuthAllowed": true
	}		}
	}),		}),
	"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"		"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
	}		}
	The server creates and returns an authorization object for the		The server creates and returns an authorization object for the
	identifier that includes the "subdomainAuthAllowed" flag. The		identifier that includes the subdomainAuthAllowed flag. The
	object is initially in "pending" state.		object is initially in "pending" state.
	{		{
	"status": "pending",		"status": "pending",
	"expires": "2023-09-01T14:09:07.99Z",		"expires": "2023-09-01T14:09:07.99Z",
	"identifier": {		"identifier": {
	"type": "dns",		"type": "dns",
	"value": "example.org"		"value": "example.org"
	},		},
	skipping to change at line 630 ¶		skipping to change at line 628 ¶
	the client's challenge immediately with a status of "processing"		the client's challenge immediately with a status of "processing"
	and the client will then need to poll the authorization resource		and the client will then need to poll the authorization resource
	to see when it is finalized. Refer to Section 7.5.1 of [RFC8555]		to see when it is finalized. Refer to Section 7.5.1 of [RFC8555]
	for more details.		for more details.
	* Step 2: The client places a newOrder for sub1.example.org.		* Step 2: The client places a newOrder for sub1.example.org.
	The client sends a newOrder request to the server and includes the		The client sends a newOrder request to the server and includes the
	subdomain identifier. Note that the identifier is a subdomain of		subdomain identifier. Note that the identifier is a subdomain of
	the ancestor domain that has been pre-authorized in Step 1. The		the ancestor domain that has been pre-authorized in Step 1. The
	client does not need to include the "subdomainAuthAllowed" field		client does not need to include the subdomainAuthAllowed field in
	in the "identifier" object, as it has already pre-authorized the		the identifier object, as it has already pre-authorized the
	ancestor domain.		ancestor domain.
	POST /acme/new-order HTTP/1.1		POST /acme/new-order HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	skipping to change at line 683 ¶		skipping to change at line 681 ¶
	],		],
	"authorizations": [		"authorizations": [
	"https://example.com/acme/authz/PAniVnsZcis"		"https://example.com/acme/authz/PAniVnsZcis"
	],		],
	"finalize": "https://example.com/acme/order/TOlocrfgo/finalize"		"finalize": "https://example.com/acme/order/TOlocrfgo/finalize"
	}		}
	The client can proceed to finalize the order by posting a CSR to		The client can proceed to finalize the order by posting a CSR to
	the "finalize" resource. The client can then download the		the finalize resource. The client can then download the
	certificate for sub1.example.org.		certificate for sub1.example.org.
	* Step 3: The client places a newOrder for sub2.example.org.		* Step 3: The client places a newOrder for sub2.example.org.
	The client sends a newOrder request to the server and includes the		The client sends a newOrder request to the server and includes the
	subdomain identifier. Note that the identifier is a subdomain of		subdomain identifier. Note that the identifier is a subdomain of
	the ancestor domain that has been pre-authorized in Step 1. The		the ancestor domain that has been pre-authorized in Step 1. The
	client does not need to include the "subdomainAuthAllowed" field		client does not need to include the subdomainAuthAllowed field in
	in the "identifier" object, as it has already pre-authorized the		the identifier object, as it has already pre-authorized the
	ancestor domain.		ancestor domain.
	POST /acme/new-order HTTP/1.1		POST /acme/new-order HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	skipping to change at line 744 ¶		skipping to change at line 742 ¶
	],		],
	"authorizations": [		"authorizations": [
	"https://example.com/acme/authz/PAniVnsZcis"		"https://example.com/acme/authz/PAniVnsZcis"
	],		],
	"finalize": "https://example.com/acme/order/ROni7rdde/finalize"		"finalize": "https://example.com/acme/order/ROni7rdde/finalize"
	}		}
	The client can proceed to finalize the order by posting a CSR to		The client can proceed to finalize the order by posting a CSR to
	the "finalize" resource. The client can then download the		the finalize resource. The client can then download the
	certificate for sub2.example.org.		certificate for sub2.example.org.
	6. IANA Considerations		6. IANA Considerations
	6.1. Authorization Object Fields Registry		6.1. Authorization Object Fields Registry
	The following field has been added to the "ACME Authorization Object		The following field has been added to the "ACME Authorization Object
	Fields" registry defined in ACME [RFC8555].		Fields" registry defined in ACME [RFC8555].
	+======================+============+==============+===========+		+======================+============+==============+===========+
End of changes. 46 change blocks.
	78 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.48.