rfc9925v1.md		rfc9925.md
	skipping to change at line 158 ¶		skipping to change at line 158 ¶
	{{Section 4.1.2.4 of !RFC5280}} forbid empty issuers, so such a value may not be		{{Section 4.1.2.4 of !RFC5280}} forbid empty issuers, so such a value may not be
	interoperable with existing applications.		interoperable with existing applications.
	If the subject is not empty, senders MAY set the issuer to the subject, similar		If the subject is not empty, senders MAY set the issuer to the subject, similar
	to how they would construct a self-signed certificate.		to how they would construct a self-signed certificate.
	This may be useful in applications that, for example,		This may be useful in applications that, for example,
	expect trust anchors to have a matching issuer and subject. This is, however, a		expect trust anchors to have a matching issuer and subject. This is, however, a
	placeholder value. The unsigned certificate is not considered self-signed or		placeholder value. The unsigned certificate is not considered self-signed or
	self-issued.		self-issued.
	<!--[rfced] For clarity, may we update the latter part of this sentence
	as follows?
	Original:
	Senders MAY alternatively use a short placeholder issuer consisting
	of a single relative distinguished name, with a single attribute of
	type id-rdna-unsigned and value a zero-length UTF8String.
	Perhaps:
	Senders MAY alternatively use a short placeholder issuer consisting
	of a single relative distinguished name that has a single attribute of
	type id-rdna-unsigned and a value with a zero-length UTF8String.
	Senders MAY alternatively use a short placeholder issuer consisting of a single		Senders MAY alternatively use a short placeholder issuer consisting of a single
	relative distinguished name, with a single attribute of type id-rdna-unsigned		relative distinguished name that has a single attribute with a type of id-rdna-unsign
	and value a zero-length UTF8String. id-rdna-unsigned is defined as follows:		ed
			and value of a zero-length UTF8String. id-rdna-unsigned is defined as follows:
	~~~		~~~
	id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}		id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}
	~~~		~~~
	This placeholder name, in the string representation of {{?RFC4514}}, is:		This placeholder name, in the string representation of {{?RFC4514}}, is:
	~~~		~~~
	1.3.6.1.5.5.7.25.1=#0C00		1.3.6.1.5.5.7.25.1=#0C00
	~~~		~~~
	skipping to change at line 197 ¶		skipping to change at line 183 ¶
	and already forbidden by {{Section 4.1.2.8 of !RFC5280}}.		and already forbidden by {{Section 4.1.2.8 of !RFC5280}}.
	## Extensions		## Extensions
	Some X.509 extensions also describe the certificate issuer and thus are not		Some X.509 extensions also describe the certificate issuer and thus are not
	meaningful for an unsigned certificate:		meaningful for an unsigned certificate:
	* authority key identifier ({{Section 4.2.1.1 of !RFC5280}})		* authority key identifier ({{Section 4.2.1.1 of !RFC5280}})
	* issuer alternative name ({{Section 4.2.1.7 of !RFC5280}})		* issuer alternative name ({{Section 4.2.1.7 of !RFC5280}})
	<!--[rfced] To improve readability and avoid the repetition of "include" and
	"includes", may we update this sentence as follows?
	Original:
	Section 4.2.1.1 of [RFC5280] requires
	certificates to include the authority key identifier, but includes an
	exception for self-signed certificates used when distributing a
	public key.
	Perhaps:
	Section 4.2.1.1 of [RFC5280] requires
	certificates to include the authority key identifier, but it also describes an
	exception for self-signed certificates used when distributing a
	public key.
	Senders SHOULD omit the authority key identifier and issuer alternative name		Senders SHOULD omit the authority key identifier and issuer alternative name
	extensions. {{Section 4.2.1.1 of !RFC5280}} requires certificates to include		extensions. {{Section 4.2.1.1 of !RFC5280}} requires certificates to include
	the authority key identifier, but includes an exception for self-signed certificates		the authority key identifier, but it permits an exception for self-signed certificate s
	used when distributing a public key. This document updates {{!RFC5280}} to also		used when distributing a public key. This document updates {{!RFC5280}} to also
	permit omitting the authority key identifier in unsigned certificates.		permit omitting the authority key identifier in unsigned certificates.
	Some extensions reflect whether the subject is a CA or an end entity:		Some extensions reflect whether the subject is a CA or an end entity:
	* key usage ({{Section 4.2.1.3 of !RFC5280}})		* key usage ({{Section 4.2.1.3 of !RFC5280}})
	* basic constraints ({{Section 4.2.1.9 of !RFC5280}})		* basic constraints ({{Section 4.2.1.9 of !RFC5280}})
	<!--[rfced] FYI - We've reformatted the following text into an unordered
	list. Please review and let us know of any objections.
	Original:
	Senders SHOULD fill in these values to reflect the subject. That is:
	If the subject is a CA, it SHOULD assert the keyCertSign key usage
	bit and SHOULD include a basic constraints extensions that sets the
	cA boolean to TRUE.
	If the subject is an end entity, it SHOULD NOT assert the keyCertSign
	key usage bit, and it SHOULD either omit the basic constraints
	extension or set the cA boolean to FALSE. Unlike a self-signed
	certificate, an unsigned certificate does not issue itself, so there
	is no need to accommodate a self-signature in either extension.
	Current:
	Senders SHOULD fill in these values to reflect the subject. That is:
	* If the subject is a CA, it SHOULD assert the keyCertSign key usage
	bit and SHOULD include a basic constraints extension that sets
	the cA boolean to TRUE.
	* If the subject is an end entity, it SHOULD NOT assert the
	keyCertSign key usage bit, and it SHOULD either omit the basic
	constraints extension or set the cA boolean to FALSE. Unlike a
	self-signed certificate, an unsigned certificate does not issue
	itself, so there is no need to accommodate a self-signature in
	either extension.
	Senders SHOULD fill in these values to reflect the subject. That is:		Senders SHOULD fill in these values to reflect the subject. That is:
	* If the subject is a CA, it SHOULD assert the keyCertSign key usage bit and		* If the subject is a CA, it SHOULD assert the keyCertSign key usage bit and
	SHOULD include a basic constraints extension that sets the cA boolean to TRUE.		SHOULD include a basic constraints extension that sets the cA boolean to TRUE.
	* If the subject is an end entity, it SHOULD NOT assert the keyCertSign key usage		* If the subject is an end entity, it SHOULD NOT assert the keyCertSign key usage
	bit, and it SHOULD either omit the basic constraints extension or set the cA		bit, and it SHOULD either omit the basic constraints extension or set the cA
	boolean to FALSE. Unlike a self-signed certificate, an unsigned certificate does		boolean to FALSE. Unlike a self-signed certificate, an unsigned certificate does
	not issue itself, so there is no need to accommodate a self-signature in either		not issue itself, so there is no need to accommodate a self-signature in either
	extension.		extension.
	skipping to change at line 309 ¶		skipping to change at line 248 ¶
	reuse by removing the X.509 self-signature.		reuse by removing the X.509 self-signature.
	If an application accepts id-alg-unsigned as part of a certification path, or		If an application accepts id-alg-unsigned as part of a certification path, or
	in any other context where it is necessary to verify the X.509 signature, the		in any other context where it is necessary to verify the X.509 signature, the
	signature check would be bypassed. Thus, {{consuming-unsigned-certificates}}		signature check would be bypassed. Thus, {{consuming-unsigned-certificates}}
	prohibits this and recommends that applications treat id-alg-unsigned the same		prohibits this and recommends that applications treat id-alg-unsigned the same
	as any other previously unrecognized signature algorithm. Non-compliant		as any other previously unrecognized signature algorithm. Non-compliant
	applications risk vulnerabilities analogous to those described in {{JWT}} and		applications risk vulnerabilities analogous to those described in {{JWT}} and
	{{Section 1.1 of ?I-D.ietf-jose-deprecate-none-rsa15}}.		{{Section 1.1 of ?I-D.ietf-jose-deprecate-none-rsa15}}.
	<!--[rfced] To improve readability, may we update "etc." to "for example"?
	Original:
	However, some applications might use
	it as an integrity check to guard against accidental storage
	corruption, etc.
	Perhaps:
	However, some applications might, for example, use
	it as an integrity check to guard against accidental storage
	corruption.
	The signature in a self-signed certificate is self-derived and thus of limited		The signature in a self-signed certificate is self-derived and thus of limited
	use to convey trust. However, some applications might use it as an integrity		use to convey trust. However, some applications might, for example, use it as an inte
	check to guard against accidental storage corruption, etc. An unsigned		grity
			check to guard against accidental storage corruption. An unsigned
	certificate does not provide any integrity check. Applications checking		certificate does not provide any integrity check. Applications checking
	self-signature for integrity SHOULD instead use some other mechanism, such as an		self-signature for integrity SHOULD instead use some other mechanism, such as an
	external hash that is verified out-of-band.		external hash that is verified out-of-band.
	# IANA Considerations		# IANA Considerations
	## Module Identifier		## Module Identifier
	IANA has added the following entry in the "SMI Security for PKIX		IANA has added the following entry in the "SMI Security for PKIX
	Module Identifier" registry, defined by {{?RFC7299}}:		Module Identifier" registry, defined by {{?RFC7299}}:
	skipping to change at line 381 ¶		skipping to change at line 307 ¶
	|---------|------------------|------------|		|---------|------------------|------------|
	| 1 | id-rdna-unsigned | RFC 9925 |		| 1 | id-rdna-unsigned | RFC 9925 |
	Future updates to this table are to be made according to the Specification		Future updates to this table are to be made according to the Specification
	Required policy as defined in {{!RFC8126}}.		Required policy as defined in {{!RFC8126}}.
	--- back		--- back
	# ASN.1 Module		# ASN.1 Module
	<!--[rfced] We note that [RFC5912] is only cited in the ASN.1 module.		This ASN.1 module uses the conventions established by [RFC5912].
	In order to have a 1:1 matchup between the references section and the text,
	please review the text and let us know where a citation may be included.
	We suggest adding a sentence before the ASN.1 module to cite [RFC5912].
	Perhaps:
	This ASN.1 module uses the conventions established by [RFC5912].
	~~~ asn.1		~~~ asn.1
	SignatureAlgorithmNone		SignatureAlgorithmNone
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-algUnsigned-2025(122) }		id-mod-algUnsigned-2025(122) }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	skipping to change at line 440 ¶		skipping to change at line 359 ¶
	END		END
	~~~		~~~
	# Acknowledgements		# Acknowledgements
	{:numbered="false"}		{:numbered="false"}
	Thanks to {{{Bob Beck}}}, {{{Nick Harper}}}, and {{{Sophie Schmieg}}} for reviewing a n early		Thanks to {{{Bob Beck}}}, {{{Nick Harper}}}, and {{{Sophie Schmieg}}} for reviewing a n early
	iteration of this document. Thanks to {{{Alex Gaynor}}} for providing a link to cite		iteration of this document. Thanks to {{{Alex Gaynor}}} for providing a link to cite
	for {{JWT}}. Thanks to {{{Russ Housley}}} for additional input.		for {{JWT}}. Thanks to {{{Russ Housley}}} for additional input.
	<!-- [rfced] FYI - We have added an expansion for the following abbreviation
	per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
	expansion in the document carefully to ensure correctness.
	Key Encapsulation Mechanism (KEM)
	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	and let us know if any changes are needed. Updates of this nature typically
	result in more precise language, which is helpful for readers.
	Note that our script did not flag any words in particular, but this should
	still be reviewed as a best practice.
End of changes. 9 change blocks.
	82 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48.