Skip to main content

3. Constructing Unsigned Certificates

This section preserves the RFC text for unsigned X.509 certificates, including id-alg-unsigned, id-rdna-unsigned, zero-length signatureValue, issuer handling, extension guidance, validation rules, IANA registrations, and the ASN.1 module.

Original RFC Text​

3.  Constructing Unsigned Certificates

   This section describes how a sender constructs an unsigned
   certificate.

3.1.  Signature

   To construct an unsigned X.509 certificate, the sender MUST set the
   Certificate's signatureAlgorithm and TBSCertificate's signature
   fields each to an AlgorithmIdentifier with algorithm id-alg-unsigned,
   defined below:

     id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}

   The parameters for id-alg-unsigned MUST be omitted.  The
   Certificate's signatureValue field MUST be a BIT STRING of length
   zero.

3.2.  Issuer

   An unsigned certificate takes the place of a self-signed certificate
   in scenarios where the application only requires subject information.
   It has no issuer, so some requirements in the profile defined in
   [RFC5280] cannot meaningfully be applied.  However, the application
   may have pre-existing requirements derived from [X.509] and
   [RFC5280], so senders MAY construct the certificate as if it were a
   self-signed certificate, if needed for interoperability.

   In particular, the following fields describe a certificate's issuer:

   *  issuer (Section 4.1.2.4 of [RFC5280])

   *  issuerUniqueID (Section 4.1.2.8 of [RFC5280])

   The issuer field is not optional, and both [X.509] and
   Section 4.1.2.4 of [RFC5280] forbid empty issuers, so such a value
   may not be interoperable with existing applications.

   If the subject is not empty, senders MAY set the issuer to the
   subject, similar to how they would construct a self-signed
   certificate.  This may be useful in applications that, for example,
   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 self-issued.

   Senders MAY alternatively use a short placeholder issuer consisting
   of a single relative distinguished name that has a single attribute
   with a type of id-rdna-unsigned 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}

   This placeholder name, in the string representation of [RFC4514], is:

     1.3.6.1.5.5.7.25.1=#0C00

   Senders MUST omit the issuerUniqueID field, as it is optional, not
   applicable, and already forbidden by Section 4.1.2.8 of [RFC5280].

3.3.  Extensions

   Some X.509 extensions also describe the certificate issuer and thus
   are not meaningful for an unsigned certificate:

   *  authority key identifier (Section 4.2.1.1 of [RFC5280])

   *  issuer alternative name (Section 4.2.1.7 of [RFC5280])

   Senders SHOULD omit the authority key identifier and issuer
   alternative name extensions.  Section 4.2.1.1 of [RFC5280] requires
   certificates to include the authority key identifier, but it permits
   an exception for self-signed certificates used when distributing a
   public key.  This document updates [RFC5280] to also permit omitting
   the authority key identifier in unsigned certificates.

   Some extensions reflect whether the subject is a CA or an end entity:

   *  key usage (Section 4.2.1.3 of [RFC5280])

   *  basic constraints (Section 4.2.1.9 of [RFC5280])

   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.
Last updated on