RemoveFromCRL y DeltaCRL

Question

RemoveFromCRL y DeltaCRL

#1 de Thomas Pornin (3 votos)

3

Tengo una pregunta sobre DeltaCRL con una entrada que contiene RemoveFromCRL reason.
Al principio, PKI ha revocado el certificado con certificateHold reason.

Y crea la siguiente CRL:

Last Update: May 28 13:14:09 2015 GMT 
Next Update: Jun 27 13:14:09 2015 GMT
Revoked Certificates:
    Serial Number: 12
    Revocation Date: Aug 14 14:44:00 2014 GMT 
    CRL entry extensions:
            X509v3 CRL Reason Code: 
                certificateHold

Más tarde, nuestra PKI no revocó el certificado, eliminó el certificado de CRL y creó la siguiente CRL de Delta:

Last Update: May 30 12:51:40 2015 GMT 
    Next Update: May 30 15:00:00 2015 GMT
    Revoked Certificates:
        Serial Number: 12
        Revocation Date: May 30 12:51:40 2015 GMT 
        CRL entry extensions:
                X509v3 CRL Reason Code: 
                    RemoveFromCRL

¿Qué valor puedo usar para RevocationDate para DeltaCRL y por qué?
¿Debo usar la hora actual o revocationDate de la primera revocación?

public-key-infrastructure x.509 crl

pregunta YBW 31.05.2015 - 00:29

fuente

1 respuesta

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

Forzar https sin 301 mailto correo electrónico encabezados IP de rastreo

score 3 · Accepted Answer

El código de razón 'removeFromCRL' indica que el certificado, de hecho, no ha sido revocado. La idea detrás de 'certificateHold' es hacer una suspensión , no una revocación: la PKI declara que el certificado no debe usarse hasta que haya más información disponible (en un delta posterior o CRL completo), mientras No revocar completamente el certificado, porque la revocación es un viaje de ida. En ese sentido, el certificado nunca fue revocado, y por lo tanto tampoco fue "no revocado".

Esto implica que la "fecha de revocación" para un código 'removeFromCRL' se ignora por completo. Esa fecha califica el instante desde el cual el certificado debe considerarse como revocado, hasta el final de los tiempos; el código 'removeFromCRL' lo cancela.

Si observa RFC 5280 , verá que la fecha de revocación no se usa en absoluto en el algoritmo de validación. . Su propósito principal es admitir la validación de pasado , cuando se quiere saber si un certificado dado era válido en alguna fecha pasada (esto se usa en algunos formatos de firma, junto con sellos de tiempo). Cuando una CRL enumera que un certificado ha sido revocado en la fecha T , esto significa que después de la fecha T el certificado no debe considerarse válido, sino también que antes de la fecha T está bien. Por ejemplo, si el certificado estaba en una tarjeta inteligente que se ha perdido, entonces la "fecha de revocación" debería ser la última vez que su propietario haya visto la tarjeta inteligente, ya que en cualquier fecha posterior la tarjeta podría estar en las manos equivocadas. Para el par de CertificateHold / removeFromCRL, el punto es que la clave privada nunca se comprometió y el certificado nunca se revocó, por lo que no hay una "fecha de revocación".

(Podría decirse que los códigos de razón 'certificateHold' y 'removeFromCRL' son un truco que alienta a los propietarios de PKI a utilizar la revocación como un mecanismo de suspensión de emergencia, es decir, un sustituto de la autorización , y eso es un mal La revocación es, por naturaleza, un mecanismo asíncrono, y no funciona bien para eso. Cuando surge una situación en la que se quiere poner un certificado "en espera", lo más sensato es revocar el certificado y emitir un certificado. nuevo.)