¿PKCS # 7 (CMS) agrega seguridad a un correo electrónico si se incluye una respuesta CRL / OCSP y luego se revoca?

3

Supongamos que emito un certificado de firma en enero y que se emita una CRL diaria (caduca en 1 día) para verificar la validez de esa firma.

Luego, en algún momento de julio, necesito revocar ese certificado.

Mi objetivo es no invalidar todos los correos electrónicos anteriores firmados con esa clave, sino dar a los destinatarios cierta seguridad de que la clave era válida y correcta cuando recibieron el mensaje. CMS / PKCS7 podría hacer lo que necesito SI:

  • El cliente que envía incluye la respuesta de revocación en el mensaje
  • La infraestructura PKI firmante es correcta y no tiene defectos
  • El validador verá la firma SMIME, la validará y también validará la firma.
  • ¿Se derrumba todo este concepto si cuando el certificado caduca o se sustituye y no se pierde debido a un robo / pérdida de integridad de la clave privada?

Dado el soporte inconsistente para SMIME (por ejemplo, gmail y todas las cosas de Google), ¿hay algún software o tecnología que se valide de la manera que resuelva mis necesidades?

¿Es viable lo que estoy buscando o estoy utilizando la tecnología equivocada para el propósito equivocado?

    
pregunta random65537 26.02.2015 - 06:39
fuente

1 respuesta

4

Lo que está buscando es teóricamente viable, siempre que agregue la pieza extra faltante, es decir, alguna forma de sellado de tiempo. Sin embargo, es probable que el comportamiento de las implementaciones implementadas existentes sea un problema.

La idea conceptual es que si verifica una firma en la fecha T en algún mensaje, luego, en una fecha posterior T ', todavía puede recordar que la firma fue correcta, y actúe según esa creencia, incluso si la firma ya no es verificable en la fecha T ', por ejemplo, porque el certificado del firmante fue revocado mientras tanto.

En el caso de revocación, cada información de revocación (ya sea en una CRL o en una respuesta de OCSP) viene con una fecha de revocación . El campo se llama revocationDate en una CRL y está definido de la siguiente manera:

The date on which the revocation occurred is specified.

Entonces, cuando una CRL dice que un certificado fue revocado el 17 de junio, a las 14:10 +00: 00, también dice implícitamente que el 15 de junio, el certificado fue no revocado. Por lo tanto, si el destinatario puede asegurarse de alguna manera que recibió el correo electrónico (y su firma) en una fecha anterior a la fecha de revocación, y que el correo electrónico almacenado no fue alterado de ninguna manera, entonces la firma es, en concepto, verificable.

Un grave agujero en la teoría anterior es que las CA existentes no necesariamente escriben las fechas de revocación con toda la precisión necesaria. Por ejemplo, si revoca dos veces el mismo certificado con PKI de Microsoft (Servicios de certificados de Active Directory), entonces la fecha de revocación será la fecha de la revocación de segundo , no la primera. Pero si administra certificados en tarjetas inteligentes con el producto FIM CM de Microsoft (Forefront Identity Management - Certificate Management), entonces realizará tales revocaciones duplicadas.

En general, las pruebas de la existencia de algún dato en una fecha anterior se basan en sellos de tiempo . Para el archivado a largo plazo de documentos firmados, aún verificables años después (no solo después de que haya expirado el certificado del firmante, sino también después de que también haya caducado parte del certificado de CA intermedio), debe aplicar sellos de tiempo de forma regular, como Capa de pintura fresca. Existen algunos estándares para eso, pero son un poco más complejos que el simple CMS (CAdES se basa en el CMS, pero con algunos atributos adicionales bastante peludos). Consulte esta respuesta para obtener más información y sugerencias.

    
respondido por el Thomas Pornin 03.03.2015 - 00:31
fuente

Lea otras preguntas en las etiquetas