¿Qué propiedades de un certificado X.509 deberían ser críticas y cuáles no?

22

La sección 4.2 de RFC5280

declara
  

Cada extensión en una      El certificado se designa como crítico o no crítico. UNA      El sistema que utiliza el certificado DEBE rechazar el certificado si encuentra      una extensión crítica que no reconoce o una extensión crítica      que contiene información que no puede procesar. Un no critico      la extensión PUEDE ser ignorada si no se reconoce, pero DEBE ser      procesado si se reconoce.

pero no puedo encontrar información (preferiblemente una lista corta) en cuáles las extensiones deben (n't) ser designadas como críticas. Encontré que basicConstraints es crítico, tanto porque es básico como porque un certificado marcado como CA:FALSE obviamente no debería poder firmar certificados de niños (aunque creo que leí en algún lugar que pathlen para CA restringidas parece ser ignorado de vez en cuando), pero también es una de las partes más básicas de un certificado, por lo que es probable que también sea no designado crítico. keyUsage suena como un buen candidato para críticos, pero ¿qué pasa con extendedKeyUsage y subjectAltName ?

¿Hay una breve descripción que indique qué extensiones deberían ser a) críticas b) no críticas c) no importa?

    
pregunta Tobias Kienzler 15.02.2013 - 18:01
fuente

1 respuesta

28

En "X.509 puro", realmente no importa si una extensión es crítica o no, ya que se supone que las implementaciones conformes honran las extensiones que reconocen, estén marcadas como críticas o no. El indicador "crítico" es para las extensiones que son no estándar: usted hace que dicha extensión sea crítica si es importante para la seguridad (las implementaciones que no entienden la extensión deben rechazar el certificado), o no críticas de lo contrario (las implementaciones que no entiendan la extensión pueden ignorarla).

Hay una pequeña excepción a esta regla, con la extensión CRL Distribution Points . Tiene dos propósitos: documentar desde dónde se pueden descargar las CRL e implementar segmentación del alcance . Este último rol está activo solo cuando la extensión es crítica. Cuando la extensión es crítica, se puede considerar que una CRL cubre el certificado (es decir, que puede informar algo sobre su estado de revocación) solo si la CRL contiene una extensión Issuing Distribution Point , con un "punto de distribución" que coincide con uno de los especificados en la extensión CRL Distribution Point en el certificado. Cuando la extensión no es crítica, la extensión sirve solo en su función de documentación.

En la práctica , hará que las extensiones sean críticas o no dependiendo de si pueden ignorarse sin perforar un agujero demasiado grande en toda la seguridad, y también dependiendo de si hacer que la extensión sea crítica inducirá la existencia de Implementaciones para rechazar el certificado por falta de soporte. Por ejemplo, si usa una extensión crítica Name Constraints , corre el riesgo de un rechazo incondicional de OpenSSL (las versiones anteriores a 1.0, que son bastante recientes, no lo admiten); pero si lo hace no crítico, entonces el mismo OpenSSL lo ignorará . La extensión Name Constraints es un caso típico de una extensión que no puede ignorarse de manera segura, por lo que siempre debe marcarse como crítico (pero problemas de interoperabilidad hacen que su uso sea problemático).

RFC 5280 enumera, para cada extensión de certificado, si una CA conforme debe hacer que la extensión sea crítica o no. Estos son los requisitos en la CA y no en los validadores; un sistema que valida un certificado no debe rechazarlo sobre la base de que incluye una extensión crítica Subject Key Identifier , aunque RFC 5280 dice (sección 4.2.1.2):

  

Las CA conformes DEBEN marcar esta extensión como no crítica.

Consulte el RFC para obtener detalles sobre cada extensión: estas son pautas sobre cómo debe comportarse su CA. Por ejemplo, Key Usage es un "DEBERÍA ser crítico", Basic Constraints es un "PODRÍA ser crítico", Name Constraints es un "DEBE ser crítico", y así sucesivamente ... Si sigue estas reglas, su seguridad estará bien (pero es posible que tenga que realizar algunas modificaciones para la interoperabilidad).

    
respondido por el Thomas Pornin 15.02.2013 - 19:05
fuente

Lea otras preguntas en las etiquetas