rfc9925v1.txt   rfc9925.txt 
skipping to change at line 173 skipping to change at line 173
may not be interoperable with existing applications. may not be interoperable with existing applications.
If the subject is not empty, senders MAY set the issuer to the If the subject is not empty, senders MAY set the issuer to the
subject, similar to how they would construct a self-signed subject, similar to how they would construct a self-signed
certificate. This may be useful in applications that, for example, certificate. This may be useful in applications that, for example,
expect trust anchors to have a matching issuer and subject. This is, expect trust anchors to have a matching issuer and subject. This is,
however, a placeholder value. The unsigned certificate is not however, a placeholder value. The unsigned certificate is not
considered self-signed or self-issued. considered self-signed or self-issued.
Senders MAY alternatively use a short placeholder issuer consisting Senders MAY alternatively use a short placeholder issuer consisting
of a single relative distinguished name, with a single attribute of of a single relative distinguished name that has a single attribute
type id-rdna-unsigned and value a zero-length UTF8String. id-rdna- with a type of id-rdna-unsigned and value of a zero-length
unsigned is defined as follows: 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
Senders MUST omit the issuerUniqueID field, as it is optional, not Senders MUST omit the issuerUniqueID field, as it is optional, not
applicable, and already forbidden by Section 4.1.2.8 of [RFC5280]. applicable, and already forbidden by Section 4.1.2.8 of [RFC5280].
skipping to change at line 197 skipping to change at line 197
Some X.509 extensions also describe the certificate issuer and thus Some X.509 extensions also describe the certificate issuer and thus
are not meaningful for an unsigned certificate: are not 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])
Senders SHOULD omit the authority key identifier and issuer Senders SHOULD omit the authority key identifier and issuer
alternative name extensions. Section 4.2.1.1 of [RFC5280] requires alternative name extensions. Section 4.2.1.1 of [RFC5280] requires
certificates to include the authority key identifier, but includes an certificates to include the authority key identifier, but it permits
exception for self-signed certificates used when distributing a an exception for self-signed certificates used when distributing a
public key. This document updates [RFC5280] to also permit omitting public key. This document updates [RFC5280] to also permit omitting
the authority key identifier in unsigned certificates. 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])
Senders SHOULD fill in these values to reflect the subject. That is: Senders SHOULD fill in these values to reflect the subject. That is:
skipping to change at line 271 skipping to change at line 271
If an application accepts id-alg-unsigned as part of a certification 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 path, or in any other context where it is necessary to verify the
X.509 signature, the signature check would be bypassed. Thus, X.509 signature, the signature check would be bypassed. Thus,
Section 4 prohibits this and recommends that applications treat id- Section 4 prohibits this and recommends that applications treat id-
alg-unsigned the same as any other previously unrecognized signature alg-unsigned the same as any other previously unrecognized signature
algorithm. Non-compliant applications risk vulnerabilities analogous algorithm. Non-compliant applications risk vulnerabilities analogous
to those described in [JWT] and Section 1.1 of [JOSE]. to those described in [JWT] and Section 1.1 of [JOSE].
The signature in a self-signed certificate is self-derived and thus The signature in a self-signed certificate is self-derived and thus
of limited use to convey trust. However, some applications might use of limited use to convey trust. However, some applications might,
it as an integrity check to guard against accidental storage for example, use it as an integrity check to guard against accidental
corruption, etc. An unsigned certificate does not provide any storage corruption. An unsigned certificate does not provide any
integrity check. Applications checking self-signature for integrity integrity check. Applications checking self-signature for integrity
SHOULD instead use some other mechanism, such as an external hash SHOULD instead use some other mechanism, such as an external hash
that is verified out-of-band. that is verified out-of-band.
6. IANA Considerations 6. IANA Considerations
6.1. Module Identifier 6.1. 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 416 skipping to change at line 416
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[X.509] ITU-T, "Information technology - Open Systems [X.509] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509, ISO/ certificate frameworks", ITU-T Recommendation X.509, ISO/
IEC 9594-8:2020, October 2019, IEC 9594-8:2020, October 2019,
<https://www.itu.int/rec/t-rec-x.509/en>. <https://www.itu.int/rec/t-rec-x.509/en>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This ASN.1 module uses the conventions established by [RFC5912].
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
IMPORTS IMPORTS
SIGNATURE-ALGORITHM SIGNATURE-ALGORITHM
 End of changes. 4 change blocks. 
8 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.48.