Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

openSUSE 11.1 Reference Guide
Previous Page Home Next Page

35.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.

35.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.

35.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 35-1 X.509v3 Certificate

Field

Content

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

35.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. X.509 Certificate Revocation List (CRL) shows the basic parts of a X.509 CRL.

Table 35-2 X.509 Certificate Revocation List (CRL)

Field

Content

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

35.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 26.0, LDAP—A Directory Service. Section 28.0, The Apache HTTP Server contains information about the HTTP server.

35.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.

openSUSE 11.1 Reference Guide
Previous Page Home Next Page

 
 
  Published under the terms fo the GNU General Public License Design by Interspire