¿Es posible crear una PKI solo para SMIME que * no pueda * usarse para SSL?

Question

¿Es posible crear una PKI solo para SMIME que * no pueda * usarse para SSL?

#1 de Thomas Pornin (1 votos)

0

Supongamos que tengo una CA raíz que quiero compartir con terceros no confiables hostiles.

Luego restringe esta raíz usando EKU específicos en la raíz.

 OID=1.3.6.1.5.5.7.3.4        ; Secure Email

A continuación, cree una CA de política (controlada por la raíz) para restringir los permisos otorgados a las CA que no son de confianza usando Path = 1, y Restricciones de nombre (consulte también esto ).

Resultado ideal

Me gustaría emitir certificados SMIME que sean solo para firmar y otro para el cifrado (entiendo que el soporte varía en esto)

Pregunta

¿Es posible restringir el nombre, el uso mejorado de la clave y el uso de la clave para que una CA hostil delegue el poder para no poder crear certificados HTTPS y no pueda crear certificados SMIME para otros dominios?

Si lo anterior es cierto; Creo que es posible crear una PKI solo para SMIME (corríjame si me equivoco).

Estoy particularmente preocupado por la capacidad (o falta de la misma) para restringe el campo de uso de clave en la CA, de modo que cualquier persona (o cliente ampliamente desplegado) verá que la cadena de CA no está permitida para emitir certificados HTTPS, y rechazará uno si se ofrece.

La extensión de uso de clave se describe en la sección 4.2.1.3 de X.509, con las siguientes marcas posibles:

KeyUsage ::= BIT STRING {
   digitalSignature        (0), -- Needed for SMIME and (EC)DHE TLS implementations
   nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
                                -- Accepted in some TLS implementations if (0) is missing
   keyEncipherment         (2),  Used in RSA based TLS
   dataEncipherment        (3),  Accepted in some TLS implementations if (2) is missing
   keyAgreement            (4),  Accepted in some TLS implementations if (2) is missing
   keyCertSign             (5),
   cRLSign                 (6),
   encipherOnly            (7),
   decipherOnly            (8) }

public-key-infrastructure tls certificates certificate-authority

pregunta random65537 18.06.2014 - 18:35

fuente

1 respuesta

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

Seguridad de este sistema de inicio de sesión de cuenta sitio web malicioso bloqueado - en un programa legítimo?

score 1 · Answer 1

Es posible crear una CA raíz que no se puede usar para SSL al ... ¡no usarlo para SSL!

Cuando una CA emite un certificado para una sub-CA, lo hace dentro del contexto de un contrato de confianza dado. La sub-AC acepta emitir certificados solo de acuerdo con una serie de reglas que se explicitan en la Política de Certificación y la Declaración de Práctica del Certificado: estos son documentos legales destinados al consumo humano. Si desea una CA raíz que se puede usar para S / MIME pero no para SSL, la CA raíz debe indicar en su CP y CPS que los certificados que se relacionan con esta CA raíz no deben usarse para SSL. En particular, la sub-CA toma el juramento formal de no emitir nunca certificados con capacidad SSL (es decir, no pondrán los nombres de las máquinas en la extensión del Nombre alternativo del sujeto o en la parte del nombre común del SubjectDN) y pondrán un uso crítico de clave extendida extensión que dice "solo para S / MIME").

En X.509, hay dos categorías de tales "reglas PKI":

Reglas que se aplican mediante el algoritmo de validación. Las restricciones de nombres, por ejemplo, pueden (teóricamente) usarse para evitar la validación de certificados de manera que el nombre del certificado de entidad final no sea parte de un espacio de nombres de nombres permitidos debidamente especificados en uno de los certificados de CA intermedios.
Reglas que no se aplican por el algoritmo de validación. La regla "sin SSL" sería tal regla.

En la pura teoría X.509, no hay una necesidad real de hacer cumplir las reglas en el algoritmo de validación; La revocación se utiliza para mantener el orden y castigar a las entidades que se comportan mal. Sin embargo, en la práctica, la revocación es asíncrona y demasiado lenta para reaccionar ante los "ataques repentinos". Un atacante que quiera ejecutar un servidor falso solo necesita diez minutos más o menos para realizar un daño considerable; ver su certificado revocado dos días después no lo disuadirá. Esta es la razón por la que ahora se aplican varias reglas de PKI en el nivel de validación, la primera de las cuales está encarnada por la extensión de Restricciones Básicas: a un propietario de certificado no se le otorga poder de CA.

(Actualmente) no existe tal aplicación automática de las reglas relacionadas con el uso de clave extendida. Si una CA desea imponer una regla sin SSL, no debe emitir certificados que puedan usarse para SSL, y debe hacer que la sub-CA jure cumplir con la misma regla. La falta de tal cumplimiento es un problema solo si una sub-CA se comporta mal, y el certificado obtenido se puede usar como un certificado de servidor SSL para perpetrar algún delito odioso antes de que la revocación correcta anule a la sub-CA ofensiva.

(Tenga en cuenta que la extensión de uso de clave solo cubre un puñado de casos de uso genéricos, como "cifrado" o "firma", y esto no está relacionado con el uso de clave extendida. Además, la extensión de uso de clave ya no se hereda a lo largo de un ruta del certificado que la extensión del uso de clave extendida.)

Hay otro punto en el que se pueden grabar las reglas: en clientes . Los clientes confían en la CA raíz (eso es lo que los hace "CA raíz"), pero solo pueden confiar en ellos para roles específicos. Vea, por ejemplo, esta captura de pantalla del visor de certificados en las preferencias de Firefox:

Lalistade"usos" es configurable y permite al cliente restringir una CA dada a ciertas situaciones específicas.

Este mecanismo:

no está respaldado por información escrita en el propio certificado raíz de CA, sino por metadatos que deben ser mantenidos por algún mecanismo fuera de banda;
no está estandarizado (cada sistema tiene su propia noción de "roles");
es específico de la CA raíz (anclajes de confianza) y no se puede adjuntar a una CA intermedia;
vale cualquier cosa solo en la medida en que las aplicaciones relevantes tengan en cuenta las restricciones y las apliquen.

Sin embargo, funciona. Si desea una CA raíz solo para S / MIME, distribúyala y pídale que la instalen en clientes con la etiqueta "solo para S / MIME". Esto es tan bueno como una extensión EKU automática de ruta completa (si existiera tal cosa).