Un certificado digital es un documento que identifica cada clave pública con su propietario correspondiente. Para que un certificado tenga validez es necesario que vaya firmado por una Autoridad de Certificación que es una entidad en la que confían el emisor y el receptor y que certifica la identidad de los participantes.

Los certificados, por tanto, son emitidos y firmados por la Autoridad Certificadora y están identificados por un número de serie y un período de validez. Por último, existe la firma de Autoridad de Registro que es una entidad que identifica de forma inequívoca al solicitante de un certificado para después suministrar a la Autoridad Certificadora los datos verificados del solicitante a fin de que ésta emita el correspondiente certificado.

Actualmente se usa el estándar x.509 que materializa estos conceptoss formando lo que se denomina una Infraestructura de Clave Pública (PKI; Public Key Infrastructure)

Un certificado contiene:

• la identidad del usuario, al igual que su capacidad de firma, se encuentra almacenada en una tarjeta inteligente (el documento de identificación electrónica, informática y telemática) que no puede ser accesible salvo por un propietario cuando introduzca el número de identificación personal, similar a la clave de una tarjeta de crédito.
• el sistema es completamente transparente al usuario, es decir, no es necesario conocer ninguna técnica criptográfica para realizar o verificar una firma electrónica o cifrar o descifrar un mensaje.

Los servicios que presta la Entidad Pública de Certificación se agrupan en servicios básicos y servicios avanzados:

1. servicios básicos: incluyen servicios de certificación de claves, registros de usuarios, publicación,etc. Sobre estos servicios se apoyan otros servicios.
1. servicios de artificación de claves. Se opera como una entidad certificadora siguiendo el estándar X509. Incluye los siguientes servicios:
• emisión y renovación de certificados
• archivo de certificados
• generación de claves
• archivo de claves
2. servicios de registro de usuarios. Se opera como una Autoridad de Registro realizando la emisión y renovación de Registros. Entrega al usuario una tarjeta inteligente.
3. servicios de publicación mediante los cuales se da a los usuarios acceso a los certificados,listas de revocación, directorios,etc.


2. servicios avanzados:
1. certificación temporal (time stamping)
2. certificación de contenido
3. confirmación de envío, entrega y recepción de documentos en sistemas de mensajerías.
4. servicios de recuperación de claves, únicamente para las claves orientadas a la confidencialidad.

---

5. Creación de la Autoridad Certificadora (CA)
6. Modelo Operacional de la Autoridad Certificadora PKI y certificados digitales
   

   Cualquier PKI resulta tan segura en su totalidad como lo sea su componente más débil. Por tanto, un buen diseño de PKI requiere la previa comprensión del rol tecnológico y funcional de todos y cada uno de sus componentes. Aquí se ofrece una descripción de los principales pasos a dar, con algunos consejos para llegar a buen puerto.
   
   De un modo sencillo, se puede decir que una infraestructura de clave pública o PKI (Public Key Infrastructure) es el conjunto de componentes y políticas necesarias para crear, gestionar y revocar certificados digitales que pueden ser utilizados para autenticar cualquier aplicación, persona, proceso u organización de una red de empresa, extranet o Internet.
   La idea básica de una infraestructura de clave pública es muy simple: se trata de que los datos sensibles sean protegidos mediante técnicas de encriptación. Cada dispositivo de usuario final posee software de encriptación y dos claves: una pública para distribuirla a otros usuarios, y otra privada, guardada y protegida por su propietario. El usuario encripta un mensaje utilizando la clave pública del receptor; cuando el mensaje se recibe, el destinatario lo desencripta con su clave privada. Se pueden tener múltiples pares de claves para mantener comunicaciones distintas con grupos diferentes.
   Pero, dado el elevado número de claves que intervienen en las comunicaciones, resulta crucial contar con algún método para administrarlas y controlar su utilización. Aquí es donde una PKI entra en juego, permitiendo la creación, distribución, seguimiento y revocación centralizada de claves.
   
   Sistema de autenticación
   El primer paso a dar para la creación de una PKI consiste en establecer un sistema de autenticación, de modo que los usuarios puedan ser identificados antes de recibir los derechos de red. Aunque, para ello, los logon basados en contraseñas suponen un método muy extendido, son mucho más seguros los certificados digitales, ya que poseen información específica sobre el usuario para permitir su identificación, como nombre, clave pública y firma digital, la cual le vincula con el certificado.
   Para obtener un certificado, un usuario envía una petición a la autoridad de registro designada, que verifica su identidad y encarga a la autoridad certificadora la expedición del certificado. En sí mismo, el certificado es un documento digital que, generalmente, se almacena y administra en un directorio central. Si el usuario está operando desde el hogar, el certificado se almacena en su sistema; en otros casos, se transmite automáticamente cuando es necesaria su utilización, sin interrumpir el trabajo del usuario. Asimismo, la autoridad verifica la autenticidad del certificado cuando lo precisa un tercero, igualmente de modo transparente. La autoridad de certificación, como entidad que firma y publica certificados mediante una clave privada, representa el corazón de cualquier PKI, y, por tanto, su seguridad debe ser máxima.
   Como ya se ha dicho, los certificados digitales no sólo autentican personas, sino que su campo de acción se extiende también a una aplicación, correo electrónico, dirección IP o incluso una organización entera, así como a las propias autoridades de certificación. Pero, pese a esta versatilidad, los certificados digitales no identifican los roles o funciones que su poseedor puede realizar, lo que implica un problema de seguridad, ya que, por sí mismos, no se pueden aplicar para controlar accesos al no restringir las acciones de sus titulares.
   A fin de eliminar este inconveniente, el grupo de trabajo X.509 PKI de Internet Engineering Task Force (IETF) –el formato de certificados X.509 es el más extendido– está desarrollando un perfil de certificados de atributos compatible con el formato de certificados X.509, el más extendido. De este modo, cuando se publique la especificación –ahora en borrador– los certificados ofrecerán además un mecanismo de autorización y control de accesos.
   Por supuesto, los certificados no deberían durar eternamente, por lo que se editan con una fecha de expiración. No obstante, algunas veces deben ser revocados inmediatamente, como cuando un empleado abandona la empresa. Para tratar tales situaciones, la autoridad mantiene actualizada una lista de revocación de certificados (Certificate Revocation List – CRL), que los usuarios pueden consultar para asegurarse de que un determinado certificado sigue siendo válido justo en ese momento. Estas CRL son accesibles por diferentes medios de consulta, como correo electrónico, Web o LDAP (Lightweight Directory Access Protocol).
   Aún así, habrá que tener en cuenta la frecuencia con que las CRL se actualizan, ya que su carácter es estático. Por ello, es preferible que dicha información se ofrezca en tiempo real, que es justo lo que aporta el nuevo OCSP (Online Certificate Status Protocol), ya soportado por las últimas versiones de los navegadores de Microsoft y Netscape.
   La autoridad de registro es responsable de verificar la identidad de los poseedores de certificados. Este es un proceso diferente de la certificación en sí, y puede suceder antes o después de que la autoridad de certificados genere un certificado.
   
   Directorio central y políticas
   Generalmente, como parte de la PKI se implementa un directorio central donde se almacenan –y pueden consultarse– los certificados, junto con otras informaciones relevantes. Si el directorio existente en la empresa está basado en LDAP (Lightweight Directory Access Protocol) o cumple la norma X.500, es muy probable que satisfaga los requerimientos de una PKI. No obstante, los sistemas de directorio no siempre interoperan entre sí como sería de desear, un inconveniente que el Directory Interoperability Forum trata de resolver.
   Otro elemento de una PKI es la política de certificación, que establece las reglas de su uso y los servicios de certificados. Este conjunto de normas debe prever todo tipo de situaciones, estableciendo, por ejemplo, que si un usuario erróneamente comparte su clave privada deberá notificarlo al personal de seguridad o a la autoridad de certificación.
   Como la determinación proactiva de cómo ese evento ha de ser tratado es crítico para la operación de una PKI, está prevista en una declaración de prácticas de certificados (CPS –Certificate Practice Statement). La política de certificados y el CPS se redactan por lo común con el asesoramiento del personal de TI, los grupos de usuarios y personal jurídico.
   El CPS proporciona una explicación detallada de cómo la autoridad de certificación ha de gestionar los certificados que edita y otros servicios asociados, como la gestión de claves. Además, actúa como un contrato entre la autoridad certificadora y los usuarios, describiendo las obligaciones y limitaciones legales, y estableciendo los principios para futuras verificaciones y audito- rías. Los fabricantes de PKI pueden proporcionar plantillas CPS para trabajar con ellas.
   Como sucede con muchas otras infraestructuras TI, será necesario disponer de personal dedicado específicamente a crear, administrar y gestionar la PKI, algo que no siempre resulta sencillo. De entrada, es preciso nombrar un responsable de seguridad, encargado de establecer y administrar la política de seguridad. Esta persona no ha de ser necesariamente parte del personal TI, pero debe comprender bien todas las cuestiones que entran en juego.
   El paso siguiente será nombrar un responsable que se encargue de identificar los requerimientos y, en función de ellos, diseñar la PKI. También, cuando las operaciones ya están en marcha, hay que contar con un administrador de seguridad de la PKI, que utilizará herramientas de gestión de autoridad de certificados para añadir, autorizar y revocar usuarios y sus certificados.
   Asimismo, se necesitará un administrador del directorio y alguien que actúe como autoridad de registro, aunque es posible establecer una autoridad de registro automatizada para tratar las peticiones de los usuarios realizadas a través de sus navegadores Web. En ese caso, se puede aprovechar el personal ya existente, como, por ejemplo, el administrador de bases de datos, para que ayude a crear y mantener el servicio de autoridad de registro automatizado.
   
   ¿Realmente lo necesita?
   Desde luego, poner en marcha una PKI lleva un considerable tiempo y dinero. ¿Merece la pena la inversión? Puede ser. La verdadera cuestión que se ha de considerar es si el negocio necesita realmente disponer de los niveles de seguridad que aporta una PKI y si éstos resuelven todo los problemas. La gestión de las empresas deben dar respuesta a estos interrogantes, y nada mejor para ello que intentar comprender lo que una PKI supone.
   En cualquier caso, no hay que perder de vista los servicios más inmediatos que puede soportar una PKI, como correo y transferencia de ficheros seguros, servicios de gestión de documentos, acceso remoto, comercio electrónico y servicios de transacción basados en Web.
   
   
   Plan de trabajo de implementación de una PKI
   ---------------------------------------------------------------
   La creación y puesta en marcha de una PKI comprende distintas fases:
   - Formación de un equipo. El equipo debe representar a toda la comunidad de usuarios.
   - Evaluación del entorno de partida. Hay que determinar qué de lo ya existente podría ser útil en la creación de la PKI: personal, directorios y hardware.
   - Identificación de los requerimientos. Es necesario identificar los requerimientos estratégicos, comerciales y técnicos. Todas las partes afectadas han de ser consultadas.
   - Revisar y comparar distintas opciones. Hay que formarse sobre los diferentes modelos de PKI y considerar las distintas opciones que ofrecen los fabricantes.
   - Desarrollar un plan. En función de la información ya obtenida, hay que diseñar un plan de proyecto con todos los recursos necesarios. Después, conviene revisarlo e incrementar el presupuesto al menos un 50% para hacer frente a costes no previstos y posibles retrasos.
   - Diseñar la arquitectura PKI. En la arquitectura general de la PKI se ha de incluir también los sistemas de backup y los enlaces con clientes externos.
   - Evaluar, probar y seleccionar. Es conveniente redactar un conjunto de criterios de evaluación para la revisión inicial de productos y servicios. Después, hay que identificar los criterios de prueba y evaluar los productos.
   - Fase piloto. En esta fase, es necesario instalar el producto seleccionado y poner en marcha una PKI piloto para estar seguro de que ofrece justo lo que se pretendía. Es el momento de explicar a los usuarios los nuevos servicios PKI y los beneficios que proporcionará, así como formar técnicamente al personal de soporte.
   - Implementación, prueba y lanzamiento. Luego, hay que pasar de la fase piloto a la implementación total, preferentemente por etapas sucesivas.
   
   
   Obtención de un certificado
   --------------------------------------
   1- El usuario pide un certificado digital a la autoridad de registro
   2- La autoridad de registro verifica la identidad del usuario y pide a la autoridad de certificación que expida el certificado.
   3- La autoridad de certificados almacena los certificados en el directorio y manda copia al usuario cuando lo necesita.
   
   
   Utilización de un certificado
   --------------------------------------
   1- El usuario accede a un servidor seguro proporcionando un certificado personal
   2- El servidor proporciona al usuario un certificado de servidor
   3- El usuario y el servidor validan los certificados comprobándolos en un directorio. Una vez que la autenticación se ha completado, el usuario obtiene el permiso de acceso.
   
   
   Validación de certificados
   ------------------------------------
   El estándar OCSP (Online Certificate Status Protocol) ofrece validación de certificados en tiempo real, imprescindible para muchos sitios de comercio electrónico.
   
   Imaginemos un sitio Web que opera transacciones online de compraventa de divisas y que, lógicamente, cuenta con una infraestructura de clave pública para distribuir certificados con fines de autenticación. Cuando los clientes acceden al sitio, sus navegadores presentan los certificados y, en función de esta información, se les permite realizar órdenes. Como el sistema soporta transacciones por valor de millones de dólares, euros y otras monedas, los certificados tienen un periodo de validez de seis meses, en vez de un año, como es lo más común.
   Ahora supongamos que una de las compañías clientes rechaza a un comerciante dudoso cuyo certificado es válido aún durante tres meses. Para asegurarse de que dicho comerciante ya no tendrá acceso, se utiliza un procedimiento llamado revocación de certificado, por el que es declarado inválido antes de que expire.
   El mecanismo básico de revocación es el conocido como CRL (Certificate Revocation List), que consiste en una lista, firmada digitalmente, de certificados revocados que no han expirado. La autoridad certificadora se encarga de actualizarla periódicamente.
   
   En tiempo real
   Pero las CRL presentan algunos inconvenientes. Por ejemplo, no operan en tiempo real; de hecho, muchas autoridades de certificación editan las CRL sólo una vez al día, algo que sería inaceptable en el caso expuesto. Además, no es suficiente con incluir un certificado en la lista. La aplicación que precisa de la certificación debe chequear la CRL en cada operación, lo que resulta problemático por muchas razones. La primera es que la CRL rápidamente se hace inmanejable. Cada autoridad certificadora mantiene sólo una lista para cada certificado raíz, o certificado de alto nivel bajo el cual se publican otros muchos certificados individuales. Y las CRL son acumulativas: cada certificado revocado es añadido a la lista, donde se guarda hasta que expire.
   Así, las CRL crecen enormemente. Por ejemplo, las CRL para algunos certificados raíces publicados por VeriSign (http://crl.verisign.com) pueden tener un tamaño de megabytes. Si una autoridad certificadora utiliza un único certificado raíz por cada certificado individual que publica, como puede ser el caso cuando una corporación es su propia autoridad de certificación, entonces todos los certificados revocados podrían ser listados en una CRL.
   Por tanto, compilar, firmar, transmitir, publicar y procesar una CRL implica un largo proceso que consume potencia de CPU. En el peor de los casos, la culminación de esta tarea puede llevar varios segundos. El tiempo y los recursos crecen exponencialmente cuando un sitio Web debe chequear certificados en múltiples autoridades de certificación, como puede suceder después de una fusión de compañías que usan diferentes PKI.
   Otro inconveniente consiste en que las autoridades certificadoras actualizan sus CRL sobrescribiendo el fichero previo, sin mantener datos históricos.
   
   Llegan los estándares
   Ante tal situación, no es de extrañar que las empresas demanden un mecanismo que permita a las aplicaciones verificar rápidamente la validez de un certificado en tiempo real. Y esto es justo lo que ya ofrece Online Certificate Status Protocol (OCSP), estandarizado por el IETF (Internet Engineering Task Force) en junio de 1999.
   En un sistema basado en OCSP, cuando un certificado necesita validación, la aplicación pasa una petición a un servidor OCSP (responder en inglés), como Validation TrustPlatform de KiberPass o Validation Authority de ValiCert; el servidor verifica entonces el certificado, informando al cliente si ha sido o no revocado. Estos servidores OCSP, que son vendidos como paquetes independientes o integrados en soluciones PKI, pueden entrar en contacto con otros servidores remotos situados en las instalaciones de las autoridades certificadoras.
   Internet Engineering Task Force trabaja ahora en la versión 2 de OCSP, que añade la posibilidad de solicitar información sobre el estado de un certificado en el pasado y trata la validación de certificados de atributos. Los atributos permiten separar la información de autenticación, almacenada en un certificado utilizado para obtener acceso, de la información de autorización, almacenada en un certificado distinto que identifica los servicios específicos que pueden ser accedidos.
   Sin embargo, algunos analistas de la industria afirman que extender la funcionalidad de OCSP, como propone la versión 2, complicará innecesariamente un protocolo ahora bastante simple. Por ello, proponen la alternativa SCVP (Simple Certificate Validation Protocol) como un modo má sencillo de ampliar las características de OCSP.
   SCVP –todavía en desarrollo por el IETF– no sólo amplía las funciones de validación a los atributos, como se propone en la versión 2 de OCSP, sino que va más allá, al permitir contestar, además de a la simple cuestión de si el certificado es válido, a la más compleja de si es válido para un propósito concreto. Asimismo, simplifica las tareas que el cliente debe realizar para validar un certificado, pasando al servidor el potencialmente complejo proceso de construir tales cadenas de certificados. Así, el software cliente se hace más ligero y más indicado para, por ejemplo, dispositivos inalámbricos. Lógicamente, en contrapartida el software servidor se hace más complejo.
   Cualquiera que sea el estándar que se imponga en el futuro, parece claro que, dadas sus ventajas, el chequeo de estado online debería ser parte de cualquier aplicación que dependa de certificados para las tareas de autenticación y autorización, así como de las arquitecturas basadas en certificados. Algo que en el comercio electrónico, ya sea B2C o B”B, es fundamental.
   
   Más información sobre OCSP en www.ietf.org/proceedings/98mar/slides/ pkix-ocsp/index.htm
   
   
   OCSP en acción
   ----------------------
   Online Certificate Status Protocol permite a una aplicación validar un certificado en tiempo real. Aquí se muestra cómo OCSP podría funcionar con una aplicación comercial online.
   
   1- Un comerciante inicia una conexión al servidor Web de una firma de intermediación financiera sobre un enlace Secure Sockets Layer. El navegador envía el certificado del comerciante para que sea validado.
   
   2- La aplicación Web utiliza OCSP para pasar el certificado al servidor (responder) OCSP local.
   
   3- Dependiendo de la implementación, el servidor OCSP local puede pasar el certificado a servidores remotos para realizar la validación.
   
   4- La página Web dice al comerciante si se garantiza o no el acceso de la aplicación.
   
   5- El servidor OCSP ofrece el estado del certificado, indicando si es “bueno”, “revocado” o “desconocido”. En función de esta información de estado, la aplicación Web permite o deniega accesos.
   

   PKI (Public Key Infrastructure) is an arrangement in cryptography that facilitates third party examination of, and vouching for, user identities.

   PKI allows the binding of public keys to users. These public keys are most frequently stored in cartificates. This binding of public keys to users is usually carried out by software in a central location, in coordination with other associated software components installed in distributed locations.

   The term Public Key Infrastructure is sometimes used in a broader sense to mean both the Certificate Authority (CA) and related arrangements as well, and in some other times, confusingly or wrongly, to denote public key algorithms used in electronic communications. In the latter case, it should be kept in mind that public key algorithms do not require PKI.

Public Key Infrastructure arrangements help users to authenticate each other and to use the information in identity certificates (public keys of each person) to encrypt and decrypt messages between each other.

Here is the way PKI works: The public key infrastructure architecture consists of client software, server software such as a certificate authority, hardware (e.g., smart cards) and operational procedures. Using his/her private key, a user may sign messages digitally, and another person can verify this signature using the public key embedded in that user's certificate issued by a certificate authority within the Public Key Infrastructure, thereby enabling two or more parties to establish confidentiality, message integrity and user authentication without having to compromise any secret information in advance or during the process.

Most enterprise PKI systems depend upon certificate chains to establish a party's identity. That is, while the certificate for any party may be issued by a certificate authority computer, it becomes mandatory that the legitimacy of that computer in turn need to be certified, and that is done by a higher certification authority and the chain goes on.

This certification hierarchy, at a minimum level, will consists of many computers, often more than an organization, and an assortment of interoperating software packages from different systems across different sources. This hierarchical structure is in fact inevitable as standards are critical to PKI operation. Many of the operating standards in this area are formulated by the IETF PKIX workgroup.

Enterprise-scale public key infrastructure systems are sometimes tied closely with the enterprise's directory schema by combining the employee's public key - embedded in a certificate - with other personal details such as name, designation, and department. X509 is the most commonly used certificate format alongside the directory schema LDAP.

Public Key Infrastructures, irrespective of the vendors, have many uses. These include providing public keys and bindings to user identities which are used for:

• Encryption or authentication of documents. For example, XML signature standards if the document concerned is encoded in XML.
• The same, but in case of email messages (using S/MIME or OpenPGP).
• Verification and authentication of users to applications such as in smart card login and client validation using SSL.
• Bootstrapping secure communication protocols such as SSL and Internet Key Exchange IKE).

PKI Alternatives

Newer techniques for the authentication of public key information have been introduced and some of them are already in use by various enterprises. Most popular amongst them include the Web of Trust, Simple Public Key Infrastructure (SPKI) and Robot Certificate Authorities or Robot CAs.

PKI Authorities consists of three different authorities that essentially make up a PKI system. These are the Registration Authority, Certification Authority and Certificate Directory.

Registration Authority

The jobs of the Registration Authority are to processes user requests, confirm their identities, and induct them into the user database.

Certification Authority

The tasks of a Certification Authority are to issue public key certificates and to attest that the public key embedded in it indeed belongs to the particular entity as stated in the certificate. The Certification Authority also has the right to cancel a certificate if required, and verify it at any point of time depending on the registration conditions.

Certificate Directory

The Certificate Directory manages and stores the user's registration information and certificates for future references.

From the above mentioned logical structuring of the different authorities, it is quite clear that the success of any public key infrastructure system depends entirely upon the efficiency, coordination, and performance of its public key infrastructure system authorities.

Alternatives to PKI Authorities

Alternatives to PKI authorities include: Web of Trust, Simple Public Key Infrastructure (SPKI) and Robot Certificate Authorities.

A PKI certificate, which stands for Public Key Infrastructure certificate, allows someone to combine their digital signature with a public key and something that identifies them, an example being their real life name. This certificate is used to allow computer users to show that they do own the public keys they claim to. In other words, it is a security mechanism for public keys.

As mentioned before, a digital signature is required for the PKI certificate. This signature can either be made by an authority figure who assigns the certificates, the person whose identity is being confirmed, or even endorsers of the public key. As with credit cards, a digital signature is a way for other parties and people to verify that a person is in fact the owner of the public key they claim is their own.

PKI certificates are most commonly used to authenticate cryptographic public keys. In small networks, giving public keys to others may be safe. This is often untrue for larger networks, however, and a solution must be found. This solution is public-key cryptography.

To give an example of why having an unsecured public key may become troublesome, let us take the example that a person needs to communicate with another person in order to establish a business relationship. By publishing his public key, the first person is able to receive and send messages to his companion through a secure and safe method. A problem arises, however, in the fact that someone else can pose as the first person and send messages that person did not want to send. I am sure it becomes obvious why a person pretending to be another can be a huge problem during any sort of communication effort.

The PKI certificate is a way to stop this problem. This certificate allows other people to verify that they are indeed communicating with the right person and using the right public key. It is a clear answer to the problem of the third party problems that may arise without it.

Multiple Certificate Authorities

A problem can occur when two different people or parties meet each other and both are using certification authorities the other does not recognize. Because they do not recognize the respective authorities, the certificates may not seem real. To help combat this, many certificate authorities now keep their own personal public keys in the certificates to help guide new finders of their services to them. This public key is signed by yet another certification authority, allowing a complicated hierarchy of trust to be created. To keep this simple, it basically means that all certificates are linked together by one source in an ideal situation and this source is a trustworthy one.

It is important for users who are given PKI certificates to ensure that his or her certification authority is indeed a legitimate provider of that service. It can obviously lead to problems if someone is using a certificate that really has no use as it was given out by someone lacking the authority to. Use the Certificate Revocation List or the Online Certificate Status Protocol to check this information.

PKI Certificate Revokation

There are times when a certificate must be revoked by an authority. A common example of this occurring is if a person's identity information changes, for instance if they decide to change their name for some reason or another.

PKI Certificate Standards

The PKI certificate usually includes personal information such as name, employment status and company's name, and how long the certificate is valid. The most popular standard for PKI certificates is ITU-T X.509.

Certificate Authority or Certification Authority (CA) is an entity, which is core to many PKI (Public Key Infrastructure) schemes, whose purpose is to issue digital certificates to use by other parties. It exemplifies a trusted third party. Some certification authorities may charge a fee for their service while some other CAs are free. It is also not uncommon for government and institutions to have their own CAs.

The certification authority issues a Public Key Certificate (PKC), which attests that the public key embedded in it indeed belongs to a particular person, server, organization or any other entity as said in the certificate. In such schemes, the obligation or duty of CAs is to verify the credentials of the applicants before issuing the certificate so that the users can trust the information in the CA certificates of a particular entity without any second thoughts.

But this model is not fool proof, at least in a theoretical point of view. For example, if a person (say A) could manage to get a certification authority to issue a false certificate tying another person (say B) to a wrong public key, whose corresponding private key is available to A, then this could lead to some serious security problems. That is, if a third person (say C) eventually obtains and uses the public key in this certificate, then with the private key, it is possible for A to break into the security contours of C's communication. In such a way, on a practical level, C's messages could be decrypted and the person could be duped to accept forged signatures.

Security

As mentioned above, while the correctness of a certificate is taken for granted, it is to be accepted that assuring the correctness of data presented by companies, person or programs seeking a certificate is rather difficult and has glaring loop holes. That is, it is not an impossible task for an applicant to dupe the certification authority. In order to plug these chinks in the armor, certification authorities usually use a combination of authentication techniques which include leveraging government bureaus, third parties databases and services, the payment infrastructure, and custom heuristics to analyze the trust worthiness of the applicant. In few enterprise systems, local types of authentication like Kerberos can be used to obtain the certificate, which in turn can be used by relying third parties. Notaries may be required in some cases to personally verify the party whose sign is being notarized.

• Transport Layer Security (SSL/TLS)
• IPSec
• Secure Multipurpose Internet Mail Extensions (S/MIME)
• Smartcard
• SSH
• HTTPS
• LDAPv3
• EAP