Digital Certificates and Digital Signatures

PKIv3 architectual model and datastructures conforming to ITU-T X.509

Basic certificate fields Introduction/motivation

  Users of a public key shall be confident that the associated private
  key is owned by the correct remote subject (person or system) with
  which an encryption or digital signature mechanism will be used.
  This confidence is obtained through the use of public key
  certificates, which are data structures that bind public key values
  to subjects.  

assertion

  The binding is asserted by having a trusted CA
  digitally sign each certificate. The CA may base this assertion upon
  technical means (a.k.a., proof of posession through a challenge-
  response protocol), presentation of the private key, or on an
  assertion by the subject.  A certificate has a limited valid lifetime
  which is indicated in its signed contents.  Because a certificate's
  signature and timeliness can be independently checked by a
  certificate-using client, certificates can be distributed via
  untrusted communications and server systems, and can be cached in
  unsecured storage in certificate-using systems.

  ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was
  first published in 1988 as part of the X.500 Directory
  recommendations, defines a standard certificate format [X.509]. The
  certificate format in the 1988 standard is called the version 1 (v1)
  format.  When X.500 was revised in 1993, two more fields were added,
  resulting in the version 2 (v2) format. These two fields may be used
  to support directory access control.

X.509v3

  The v3 format extends the v2 format by
  adding provision for additional extension fields.  Particular
  extension field types may be specified in standards or may be defined
  and registered by any organization or community. In June 1996,
  standardization of the basic v3 format was completed [X.509].

  ISO/IEC/ITU and ANSI X9 have also developed standard extensions for
  use in the v3 extensions field [X.509][X9.55].  These extensions can
  convey such data as additional subject identification information,
  key attribute information, policy information, and certification path
  constraints.

Certification path processing

  verifies the binding between the subject distinguished name and/or
  subject alternative name and subject public key.  The binding is
  limited by constraints which are specified in the certificates which
  comprise the path. The basic constraints and policy constraints
  extensions allow the certification path processing logic to automate
  the decision making process.

  The "most-trusted CA" is a matter of policy: it could be a root CA in
  a hierarchical PKI; the CA that issued the verifier's own
  certificate(s); or any other CA in a network PKI.  The path
  validation procedure is the same regardless of the choice of "most-
  trusted CA."

The path processing actions to be performed are:

     (a)  Verify the basic certificate information, including:

        (1) the certificate was signed using the subject public key
        from certificate i-1 (in the special case i=1, this step may be
        omitted; if not, use the subject public key from the same
        certificate),

        (2) the certificate validity period includes time T,

        (3) the certificate had not been revoked at time T and is not
        currently on hold status that commenced before time T, (this
        may be determined by obtaining the appropriate CRL or status
        information, or by out-of-band mechanisms), and

        (4) the subject and issuer names chain correctly (that is, the
        issuer of this certificate was the subject of the previous
        certificate.)

     (b)  Verify that the subject name and subjectAltName extension
     (critical or noncritical) is consistent with the constrained
     subtrees state variables.

     (c)  Verify that the subject name and subjectAltName extension
     (critical or noncritical) is consistent with the excluded subtrees
     state variables.

     (d)  Verify that policy information is consistent with the initial
     policy set:

        (1) if the explicit policy state variable is less than or equal
        to i, a policy identifier in the certificate shall be in the
        initial policy set; and

        (2) if the policy mapping variable is less than or equal to i,
        the policy identifier may not be mapped.

     (e)  Verify that policy information is consistent with the
     acceptable policy set:

        (1) if the certificate policies extension is marked critical,
        the intersection of the policies extension and the acceptable
        policy set shall be non-null;

        (2) the acceptable policy set is assigned the resulting
        intersection as its new value.

     (g) Verify that the intersection of the acceptable policy set and
     the initial policy set is non-null.

     (h)  Recognize and process any other critical extension present in
     the certificate.

     (i) Verify that the certificate is a CA certificate (as specified
     in a basicConstraints extension or as verified out-of-band).

     (j)  If permittedSubtrees is present in the certificate, set the
     constrained subtrees state variable to the intersection of its
     previous value and the value indicated in the extension field.

     (k)  If excludedSubtrees is present in the certificate, set the
     excluded subtrees state variable to the union of its previous
     value and the value indicated in the extension field.

     (l)  If a policy constraints extension is included in the
     certificate, modify the explicit policy and policy mapping state
     variables as follows:

        (1) If requireExplicitPolicy is present and has value r, the
        explicit policy state variable is set to the minimum of its
        current value and the sum of r and i (the current certificate
        in the sequence).

        (2) If inhibitPolicyMapping is present and has value q, the
        policy mapping state variable is set to the minimum of its
        current value and the sum of q and i (the current certificate
        in the sequence).

     (m) If a key usage extension is marked critical, ensure the
     keyCertSign bit is set.

  If any one of the above checks fail, the procedure terminates,
  returning a failure indication and an appropriate reason.  If none of
  the above checks fail on the end-entity certificate, the procedure
  terminates, returning a success indication together with the set of
  all policy qualifier values encountered in the set of certificates.

Revocation

  X.509 defines one method of certificate revocation.  This method
  involves each CA periodically issuing a signed data structure called
  a certificate revocation list (CRL).  A CRL is a time stamped list
  identifying revoked certificates which is signed by a CA and made
  freely available in a public repository.  Each revoked certificate is
  identified in a CRL by its certificate serial number.