43.1 The Principles of Digital Certification
Digital certification uses cryptographic processes to encrypt data,
protecting the data from access by unauthorized people. The user
data is encrypted using a second data record, or
key. The key is applied to the user data in a
mathematical process, producing an altered data record in which the
original content can no longer be identified. Asymmetrical
encryption is now in general use (public key
method). Keys always occur in pairs:
- Private Key
-
The private key must be kept safely by the key owner. Accidental
publication of the private key compromises the key pair and renders it
useless.
- Public Key
-
The key owner circulates the public key for use by third parties.
43.1.1 Key Authenticity
Because the public key process is in widespread use, there are many public
keys in circulation. Successful use of this system requires that every user
be sure that a public key actually belongs to the assumed owner. The
assignment of users to public keys is confirmed by trustworthy
organizations with public key certificates. Such certificates
contain the name of the key owner, the corresponding public key, and the
electronic signature of the person issuing the certificate.
Trustworthy organizations that issue and sign public key certificates are
usually part of a
certification infrastructure that is also responsible for the
other aspects of certificate management, such as publication,
withdrawal, and renewal of certificates. An infrastructure of this kind is
generally referred to as a public key infrastructure
or PKI. One familiar PKI is the
OpenPGP standard in which users publish their
certificates themselves without central authorization points. These
certificates become trustworthy when signed by other parties in the
web of trust.
The X.509 Public Key
Infrastructure (PKIX) is an alternative model
defined by the IETF (Internet
Engineering Task Force) that serves as a model for almost all
publicly-used PKIs today. In this model,
authentication is made by certificate authorities
(CA) in a hierarchical tree structure. The
root of the tree is the root CA, which certifies all
sub-CAs. The lowest level of sub-CAs
issue user certificates. The user certificates are trustworthy
by certification that can be traced to the root CA.
The security of such a PKI depends on the trustworthiness of the CA
certificates. To make certification practices clear to PKI
customers, the PKI operator defines a certification
practice statement (CPS) that defines the procedures for
certificate management. This should ensure that the
PKI only issues trustworthy certificates.
43.1.2 X.509 Certificates
An X.509 certificate is a data structure with several fixed fields
and, optionally, additional extensions. The fixed fields mainly
contain the name of the key owner, the public key, and the data
relating to the issuing CA (name and signature). For security
reasons, a certificate should only have a limited period of
validity, so a field is also provided for this
date. The CA guarantees the validity of the certificate in the
specified period. The CPS usually requires the PKI (the issuing CA) to
create and
distribute a new certificate before expiration.
The extensions can contain any additional information. An
application is only required to be able to evaluate an
extension if it is identified as
critical. If an application does not
recognize a critical extension, it must reject the
certificate. Some extensions are only useful for a specific application,
such as signature or encryption.
X.509v3 Certificate
shows the fields of a basic X.509 certificate in version 3.
Table 43-1 X.509v3 Certificate
Version |
The version of the certificate, for example, v3
|
Serial Number |
Unique certificate ID (an integer)
|
Signature |
The ID of the algorithm used to sign the certificate
|
Issuer |
Unique name (DN) of the issuing authority (CA)
|
Validity |
Period of validity
|
Subject |
Unique name (DN) of the owner
|
Subject Public Key Info |
Public key of the owner and the ID of the algorithm
|
Issuer Unique ID |
Unique ID of the issuing CA (optional)
|
Subject Unique ID |
Unique ID of the owner (optional)
|
Extensions |
Optional additional information, such as
KeyUsage or BasicConstraints
|
43.1.3 Blocking X.509 Certificates
If a certificate becomes untrustworthy before it has expired, it must be
blocked immediately. This can be needed if, for
example, the private key has accidentally been made public. Blocking
certificates is especially important if the private key belongs to a CA
rather than a user
certificate. In this case, all user certificates issued by the relevant CA
must be blocked immediately. If a certificate is blocked, the PKI (the
responsible CA) must make this information available to all those involved
using a certificate revocation list (CRL).
These lists are supplied by the CA to public CRL distribution
points (CDPs) at regular intervals. The CDP can optionally
be named as an extension in the certificate, so a checker
can fetch a current CRL for validation purposes. One
way to do this is the online certificate status
protocol (OCSP). The authenticity of the CRLs is
ensured with the signature of the issuing
CA. Table 43-2 shows the basic parts of a
X.509 CRL.
Table 43-2 X.509 Certificate Revocation List (CRL)
Version |
The version of the CRL, such as v2
|
Signature |
The ID of the algorithm used to sign the CRL
|
Issuer |
Unique name (DN) of the publisher of the CRL (usually the issuing CA)
|
This Update |
Time of publication (date, time) of this CRL
|
Next Update |
Time of publication (date, time) of the next CRL
|
List of revoked certificates |
Every entry contains the serial number of the certificate, the
time of revocation, and optional extensions (CRL entry
extensions)
|
Extensions |
Optional CRL extensions
|
43.1.4 Repository for Certificates and CRLs
The certificates and CRLs for a CA must be made publicly
accessible using a repository. Because the signature
protects the certificates and CRLs from being forged, the
repository itself does not need to be secured in a special way. Instead, it
tries to grant the simplest and fastest access
possible. For this reason, certificates are often provided on an
LDAP or HTTP server. Find explanations about LDAP in Section 37.0,
LDAP—A Directory Service. Section 41.0,
The Apache HTTP Server contains
information about the HTTP server.
43.1.5 Proprietary PKI
YaST contains modules for the basic management of X.509 certificates.
This mainly involves the creation of CAs, sub-CAs, and their certificates.
The services of a PKI go far beyond simply creating and distributing
certificates and CRLs. The operation of a PKI requires a well-conceived
administrative infrastructure allowing continuous update of certificates
and CRLs. This infrastructure is provided by commercial PKI products and
can also be partly automated. YaST provides tools for creating and
distributing CAs and certificates, but cannot currently offer this
background infrastructure. To set up a small PKI, you can use the available
YaST modules. However, you should use commercial products to set up an
official
or commercial PKI.