1. Introduction

この節では unsigned X.509 certificates の RFC テキストを保持し, id-alg-unsigned, id-rdna-unsigned, zero-length signatureValue, issuer handling, extension guidance, validation rules, IANA registrations, ASN.1 module を扱う.

RFC 原文

1.  Introduction

   An X.509 certificate [RFC5280] relates two entities in the PKI:
   information about a subject and a proof from an issuer.  Viewing the
   PKI as a graph with entities as nodes, as in [RFC4158], a certificate
   is an edge between the subject and issuer.

   In some contexts, an application needs standalone subject information
   instead of a certificate.  In the graph model, the application needs
   a node, not an edge.  For example, certification path validation
   (Section 6 of [RFC5280]) begins at a trust anchor, sometimes referred
   to as a root certification authority (root CA).  The application
   trusts this trust anchor information out-of-band and does not require
   an issuer's signature.

   X.509 does not define a structure for this scenario.  Instead, X.509
   trust anchors are often represented with "self-signed" certificates,
   where the subject's key signs over itself.  Other formats, such as
   [RFC5914], exist to convey trust anchors, but self-signed
   certificates remain widely used.

   Additionally, some TLS [RFC8446] server deployments use self-signed
   end entity certificates when they do not intend to present a CA-
   issued identity, instead expecting the relying party to authenticate
   the certificate out-of-band, e.g., via a known fingerprint.

   These self-signatures typically have no security value, aren't
   checked by the receiver, and only serve as placeholders to meet
   syntactic requirements of an X.509 certificate.

   Computing signatures as placeholders has some drawbacks:

   *  Post-quantum signature algorithms are large, so including a self-
      signature significantly increases the size of the payload.

   *  If the subject is an end entity, rather than a CA, computing an
      X.509 signature risks cross-protocol attacks with the intended use
      of the key.

   *  It is ambiguous whether such a self-signature requires the CA bit
      in basic constraints or keyCertSign in key usage.  If the key is
      intended for a non-X.509 use, asserting those capabilities is an
      unnecessary risk.

   *  If the subject is an end entity, and the end entity's key is not a
      signing key (e.g., a Key Encapsulation Mechanism (KEM) key), there
      is no valid signature algorithm to use with the key.

   This document defines a profile for unsigned X.509 certificates,
   which may be used when the certificate is used as a container for
   subject information, without any specific issuer.