¿Qué usos de claves mejorados se requieren para las tareas de infraestructura PKI? (OID para OSPF y firma de CRL, etc.)

Question

¿Qué usos de claves mejorados se requieren para las tareas de infraestructura PKI? (OID para OSPF y firma de CRL, etc.)

#1 de Tom Leek (6 votos)

3

Estoy creando una PKI restringida que especifica EKU para toda la jerarquía y quiero documentar los OID necesarios para las tareas de mantenimiento del árbol PKI.

Entiendo que los clientes pueden no validar todo el árbol EKU, al igual que algunos clientes ni siquiera pueden verificar las CRL o las URL de OCSP. Mi intención es crear una línea de base de infraestructura que pueda usar para probar la interoperabilidad y documentar cómo los terceros validan (o no validan) los certificados utilizados por las AC.

Pregunta

Así que, suponiendo que un cliente validará una CRL, OSPF o cualquier otro certificado relacionado con el mantenimiento de la infraestructura PKI, ¿qué OID debo incluir en mi EKU raíz para habilitar una línea de base de soporte + SMIME?

Por ejemplo, algunos OID que pueden estar relacionados con la infraestructura PKI pueden incluir la firma de una CA secundaria (si existe tal OID), y también la subordinación calificada. Sin embargo, el problema que tengo es que todos los OID que puedo encontrar se encuentran en el espacio de nombres de Microsoft de 1.3.6.1.4.1.311 o simplemente se enumeran en esta página web . Dado que Microsoft no inventó la PKI, no quiero crear problemas de interoperabilidad al incluir solo sus OID ... Me gustaría incluir la implementación de IBM u Oracle (Java) en la validación de CA.

Respuesta de muestra

La respuesta ideal incluiría una lista de OID (en cualquier formato) y una descripción de para qué se utiliza con el mayor detalle posible. Lo siguiente está en el formato "Capolicy.inf" para el servidor de certificados de Microsoft, pero todo lo que me importa es la información ...

 ;OID = 1.3.6.1.4.1.311.20.2.1; Certificate Request Enrollment
 OID = 1.3.6.1.5.5.7.3.9;  OCSP Signing (Required for OCSP)
 ;OID = 1.3.6.1.5.5.7.48.1.5; OCSP signing (SHOWS AS UNKNOWN in some software)
 OID = 1.3.6.1.5.5.7.3.4 ; SMIME
 ; OID = 1.2.840.113549.1.9.15 ; On MSFT.com... Safari reports SMIME
 ; Should I include timestamping OIDs?

También si hay ciertos OID que no debería incluir, inclúyalos también. Por ejemplo, lo siguiente parece ser controvertido y puede escalar derechos de certificados innecesariamente

;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING

public-key-infrastructure certificates certificate-authority certificate-revocation smime

pregunta random65537 08.01.2013 - 01:08

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure certificates certificate-authority certificate-revocation smime

¿Qué tan efectivo es el Administrador de tareas de Windows para identificar los keyloggers? ¿Existen vectores de ataque especiales para las bases de datos estadísticas?

score 6 · Answer 1

EKU es Uso de clave extendida ; esta es una extensión de certificado descrita en X.509 (RFC 5280) , sección 4.2.1.12. Como dice el RFC:

En general, esto la extensión aparecerá solo en los certificados de entidad final.

porque, contrario a "Políticas de certificado", no hay noción de herencia y propagación de EKU a lo largo de una ruta de certificado. La extensión EKU le informa sobre los posibles usos de la clave pública en el certificado que presenta la extensión y solo esa clave pública. Como tal, su noción de "Root EKU" no parece tener mucho sentido para mí.

Como regla general, la falta de EKU no evita que las cosas se ejecuten, excepto en algunos casos:

El certificado para un respondedor OCSP delegado (es decir, cuando la propia CA no firma una respuesta OCSP) DEBE tener un EKU con OID 1.3.6.1.5.5.7.3.9 (consulte RFC 2560 , sección 4.2.2.2).
El certificado para una Autoridad de sello de tiempo DEBE tener un EKU con OID 1.3.6.1.5.6.7.3.8 (consulte RFC 3161 , sección 2.3, que también insiste en la presencia de solo ese OID en la extensión EKU, sin incluir ningún otro OID).

Para otros roles, la presencia de la extensión EKU no es obligatoria, pero se respetará si está presente. Consulte, por ejemplo, Manejo de certificados S / MIME , sección 4.4.4: si la extensión está presente En todo caso, el certificado debe considerarse apto para el uso de S / MIME solo si el OID 1.3.6.1.5.5.7.3.4 está presente, o el OID especial 2.5.29.37.0 está presente (esta es la "cualquier extensión uso de la clave "). Pero la falta de la extensión se considera equivalente a un EKU con el OID "cualquier uso de clave extendida".

No hay "uso de clave extendida" para la firma de CA o CRL (para estos, la extensión básica de "Uso de clave" se considera suficiente).

Algunos sistemas pueden tener requisitos adicionales específicos del sistema. Por ejemplo, para el inicio de sesión con tarjeta inteligente en un contexto de Active Directory, los certificados en la tarjeta inteligente y los certificados emitidos al controlador de dominio en sí deben presentar el 1.3.6.1.4.1.311.20.2.2 específico de Microsoft . Microsoft son fanáticos totales de EKU; incluso diseñaron su propia extensión ("políticas de aplicación", aparentemente no documentada) que duplica la información de la extensión EKU.