Unsigned X.509 Certificates
updates
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (21)
An unsigned certificate has no specific issuer, so issuer-related RFC 5280 fields (issuer, issuerUniqueID, authorityKeyIdentifier, issuerAltName) are not meaningful. Senders are given flexibility to populate the issuer field in ways compatible with pre-existing applications while being clear that this is a placeholder, not self-issuance.
Implementations are RECOMMENDED to comply with the consumption rules simply by treating id-alg-unsigned as any other unrecognized signature algorithm, requiring no code changes. An unmodified validator will fail signature verification and reject the path, while an application already ignoring the self-signature will ignore id-alg-unsigned more efficiently.
Self-signatures in trust anchor and end-entity certificates have no security value and are not verified by receivers; they are mere syntactic placeholders. Post-quantum algorithms make such signatures large, KEM keys cannot produce X.509 signatures at all, and self-signing end-entity keys risks cross-protocol attacks. Unsigned certificates eliminate these drawbacks by replacing the placeholder signature with a zero-length BIT STRING.
Some applications check self-signedness to classify locally configured certificates as trust anchors. Such applications may need to modify their configuration model or user interface before accepting an unsigned certificate as a trust anchor, since unsigned certificates are not self-signed or self-issued.
The issuer field in X.509 is not optional, and both X.509 and RFC 5280 forbid empty issuers, so an empty issuer may not be interoperable with existing applications. Senders may use either the subject as the issuer value or the id-rdna-unsigned placeholder RDN to satisfy syntactic requirements.
If the subject is a CA, senders SHOULD assert the keyCertSign key usage bit and SHOULD include a basicConstraints extension with cA set to TRUE. If the subject is an end entity, senders SHOULD NOT assert keyCertSign and SHOULD either omit basicConstraints or set cA to FALSE.
Senders MAY set the issuer field to the subject (mimicking a self-signed certificate) for interoperability with applications that expect matching issuer and subject, but this is explicitly a placeholder value; the unsigned certificate is not considered self-signed or self-issued.
Senders MUST omit the issuerUniqueID field in an unsigned certificate, as it is optional, not applicable, and already forbidden by Section 4.1.2.8 of RFC 5280.
Senders SHOULD omit the authority key identifier and issuer alternative name extensions, as these describe the certificate issuer and are not meaningful for an unsigned certificate. This document updates RFC 5280 to permit omitting the authority key identifier in unsigned certificates.
To construct an unsigned X.509 certificate, the sender MUST set both the Certificate's signatureAlgorithm and TBSCertificate's signature fields to an AlgorithmIdentifier with algorithm id-alg-unsigned. Parameters MUST be omitted and signatureValue MUST be a BIT STRING of length zero.
When processing X.509 certificates without verifying signatures, receivers MAY accept id-alg-unsigned. When verifying X.509 signatures, receivers MUST reject id-alg-unsigned.
X.509 validators MUST NOT accept id-alg-unsigned in the place of a valid signature in the certification path. Treating it as an unknown algorithm — causing path validation to fail at Step (a.1) of RFC 5280 Section 6.1.3 — is the RECOMMENDED approach for unmodified implementations.
id-alg-unsigned is an OID (1.3.6.1.5.5.7.6.36) used as a placeholder signature algorithm in X.509 certificates where signature verification is not expected. It is placed in both the Certificate's signatureAlgorithm and TBSCertificate's signature fields.
id-rdna-unsigned (OID 1.3.6.1.5.5.7.25.1) is a placeholder RDN attribute type whose value is a zero-length UTF8String. Senders MAY use a single-attribute, single-RDN issuer of this type as a placeholder when a non-empty issuer is syntactically required.
IANA added decimal 122, description 'id-mod-algUnsigned-2025', to the 'SMI Security for PKIX Module Identifier' registry, referencing RFC 9925.
IANA added decimal 36, description 'id-alg-unsigned', to the 'SMI Security for PKIX Algorithms' registry (OID arc 1.3.6.1.5.5.7.6), referencing RFC 9925.
IANA created a new 'SMI Security for PKIX Relative Distinguished Name Attribute' registry (OID arc 1.3.6.1.5.5.7.25), initialized with decimal 1 for id-rdna-unsigned. Future assignments require Specification Required policy per RFC 8126. A new parent arc entry (decimal 25) was also added to the 'SMI Security for PKIX' registry.
An unsigned certificate provides no integrity guarantee. Applications relying on a self-signature as an integrity check (e.g., to detect accidental storage corruption) SHOULD instead use an external hash verified out-of-band.
If id-alg-unsigned is accepted as a valid signature in a certification path or any context requiring X.509 signature verification, the signature check is entirely bypassed. This risk is analogous to the JWT 'alg:none' vulnerability class and the JOSE 'none' deprecation, motivating the MUST NOT rule in Section 4.
Self-signed end-entity certificates cause the subject's key to be used both for the X.509 self-signature and for the end-entity protocol, creating a cross-protocol attack surface when the two uses collide. Unsigned certificates remove the self-signature, eliminating this key reuse.
For an unsigned certificate, the AlgorithmIdentifier for id-alg-unsigned MUST omit parameters, and the Certificate's signatureValue field MUST be a BIT STRING of length zero. This represents the entire on-wire encoding of the placeholder signature.