Los certificados X.509 se pueden utilizar para servidores, clientes, correo electrónico, firma de código y más aplicaciones. enlace indica que un certificado puede tener diferentes de estas 'capacidades', pero ¿cómo ve eso? ¿Qué campo X.509 denota estos diferentes usos?
Hay varias extensiones que restringen los usos de un certificado. Un certificado básico, sin ninguna extensión, se considera "apto para cualquier propósito", en lo que respecta a X.509 . El tipo de clave todavía puede tener algunas consecuencias; p.ej. una clave RSA puede funcionar tanto para el cifrado asimétrico como para las firmas, pero una clave DSA (o ECDSA), por construcción, solo puede servir para firmas (un certificado de firma solamente es lo suficientemente bueno para un cliente o servidor SSL, sin embargo, debido a Suites de cifrado "DHE").
Las extensiones estándar que limitan las "capacidades" para un certificado son las siguientes:
Key Usage : esto es un Conjunto de banderas que indican operaciones de bajo nivel. Hay exactamente nueve indicadores: firma digital, no rechazo, cifrado de clave, cifrado de datos, acuerdo de clave, registro de clave, firma cRL, firma, cifrado solo y descifrado. La semántica de cada bandera es sutil y no está bien definida (por ejemplo, la diferencia entre la firma digital y el no repudio es una cuestión mucho más especulativa que de interoperabilidad).
Extended Key Usage : esto es un lista abierta de "usos permitidos" que se representan como OID . Como virtualmente hay una infinidad de OID posibles, no puede haber una lista exhaustiva de posibles usos de claves extendidas. Se supone que cada protocolo o estándar que utiliza el certificado X.509 define sus propios usos de clave extendida; p.ej. autoridades de marca de tiempo utilice 1.3.6.1.5.5.7.3.8 (consulte la sección 2.3).
Microsoft, en su propio software de CA ("Servicios de certificados de Active Directory") decidió que las extensiones estándar no eran lo suficientemente buenas, por lo que definieron otra llamada Application Policies , que contiene exactamente la misma información que Extended Key Usage , excepto que su formato de codificación imita al del estándar Certificate Policies extensión, lo que significa que obtiene campos de comentarios opcionales adicionales, que ADCS en realidad no completa. Tenga en cuenta que ADCS también almacena la información como una extensión estándar Extended Key Usage , por lo que el efecto neto de esta extensión no estándar es propagar la confusión.
Otra extensión, más antigua, no estándar que intentó transmitir una restricción de uso fue la extensión netscape-cert-type . Esto nos devuelve al Netscape Navigator 4.0 veces, a fines del siglo anterior. Algunos CA aún incluyen esta extensión en sus certificados, más por Tradición que por interoperabilidad real.
El contenido de una extensión se respeta solo en la medida en que el software involucrado lo entiende. Las extensiones se pueden marcar como "críticas", lo que significa que una implementación que no reconoce una extensión no crítica puede ignorarla, mientras que una extensión crítica desconocida DEBE desencadenar el rechazo incondicional del certificado. Esa es la teoría, y, por supuesto, la práctica puede diferir. Algunas implementaciones no respetan la bandera de criticidad. Otros ignoran la extensión no crítica incluso si los reconocen. La redacción de la norma tampoco es muy clara:
Un no crítico la extensión PUEDE ser ignorada si no se reconoce, pero DEBE ser procesado si se reconoce.
Una implementación puede afirmar que ha "procesado" una extensión al ignorar su contenido, porque existe una diferencia entre reconocer una extensión y hacer cumplir su semántica. La imagen completa se vuelve aún más borrosa con algunas extensiones, en particular CRL Distribution Points , cuya semántica depende de si la extensión fue marcada como crítica o no.
Hay un resumen de las extensiones utilizadas para TLS / SSL en Nota técnica de NSS: 3, por Nelson B. Bolyard .
Lea otras preguntas en las etiquetas public-key-infrastructure encryption tls certificates x.509