¿Qué atributos de un certificado X509v3 nunca se usan realmente?

Question

¿Qué atributos de un certificado X509v3 nunca se usan realmente?

#1 de Thomas Pornin (7 votos)

5

¿Existen atributos de uso de la clave de extensión / extensión de X.509Certificate que rara vez o nunca se usan en la práctica?
¿Ya sea por no ser parte de un certificado emitido o porque se omiten durante la validación por algún motivo (por ejemplo, la falta de claridad en el RFC sobre el uso del atributo)? Una documentación del contrario (es decir, la lista de extensiones de atributos / uso de clave extendida que se sabe que se usa en el campo) si está disponible también sería de interés para mí.

public-key-infrastructure tls certificates x.509

pregunta Jim 24.10.2012 - 18:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates x.509

¿Cómo verificar la huella digital SSL por línea de comando? (wget, rizo, ...) ¿Es un buen enfoque usar un navegador “Rojo” y un “Verde” para equilibrar los requisitos de LOB y la seguridad?

score 7 · Accepted Answer

Tenga cuidado de que el conjunto de posibles extensiones, por definición, no esté delimitado (al menos no en la práctica; hay un límite interno de unos 128 ^{2 ²⁵⁵} ). Hay extensiones estándar que se describen en el estándar X.509, pero podría haber muchas más en otros lugares. En particular, las implementaciones de Microsoft (por ejemplo, AD Certificate Services) tienden a usar algunas extensiones específicas de Microsoft (como una extensión que designa la "plantilla de certificado" que se usó para emitir un certificado determinado).

Entre las extensiones descritas en RFC 5280 (que es el estándar para "X.509 en Internet"), lo siguiente rara vez se usa en la práctica:

Policy Mappings : las personas rara vez tienen las políticas correctas de todos modos, y para usar las asignaciones de manera significativa debe comprender cómo funcionan las políticas de certificados.
Issuer Alternative Names : esta no es una extensión muy útil, ya que el encadenamiento de nombres en una ruta de certificado usa Nombres Distinguidos, por lo que hay pocas razones para dar nombres adicionales al emisor (si se necesitan nombres adicionales para una entidad, estarán como Subject Alternative Names en el certificado para esa entidad).
Name Constraints : el soporte de las implementaciones existentes es, digamos, un poco carente de fiabilidad. Además, la semántica es complicada y artificial, por lo que incluso si alguien dice que lo implementaron, no puede estar seguro de que lo haya implementado correctamente y es difícil de probar. Por lo tanto, nadie los usa realmente.
Policy Constraints y Inhibit anyPolicy : las mismas razones que para las asignaciones de políticas.
Subject Directory Attributes : demasiado nuevo, demasiado amplio en su alcance.

Todas las demás extensiones estándar se usan comúnmente (no se usa siempre , pero son lo suficientemente comunes). Sin embargo, algunas de las funciones de estas extensiones rara vez se utilizan, incluida la CRL indirecta (donde el emisor de la CRL no es la CA), los ámbitos de la CRL que no cubren todos los motivos de revocación, direcciones X.400, ...