Cuando se revoca un certificado, la CRL contiene la fecha de revocación , que indica en qué fecha el certificado se volvió "inválido". Indirectamente, especifica que el certificado estaba bien hasta esa fecha. Por ejemplo, si se compromete una clave privada después de un robo, las grabaciones de la cámara de seguridad se utilizarán para determinar a qué hora fue robada la clave, y esa será la fecha de revocación especificada en la CRL.
Por lo tanto, si se revoca un certificado de TSA, la validez del archivo aún se puede verificar siempre que una marca de tiempo de otra TSA cubra la marca de tiempo del certificado revocado y especifique una fecha anterior a la fecha de revocación. Por ejemplo, consideremos una cadena que funciona así:
- La marca de tiempo S1 afirma que la firma (y el certificado del firmante, etc.) existían en la fecha T 1 .
- Marca de tiempo S2 afirma que la firma (y el certificado del firmante, etc.) y la marca de tiempo S 1 y el certificado TSA para S1 y la CRL asociada, etc., todos existían en la fecha T 2 .
- Y así sucesivamente.
Si la clave privada TSA utilizada para firmar S1 está comprometida, o la TSA llega a la quiebra, o cualquier situación similar, ocurre en la fecha T ', entonces el archivo sigue siendo seguro siempre que T '> T 2 : gracias a la marca de tiempo S2 , se puede validar S 1 como si la fecha actual fuera T2 , y en esa fecha la TSA estaba bien y la marca de tiempo ya existía.
Para una mayor capacidad de recuperación, desea utilizar dos TSA distintos con sellos de tiempo superpuestos intercalados:
- Marcas de tiempo S1 , S3 , S 5 ... son de TSA A .
- Marcas de tiempo S2 , S4 , S 6 ... son de TSA B .
- Siempre se aplican sellos de tiempo en pares. Cuando la marca de tiempo más alta es Sn y cualquiera de Sn-1 o S n se acerca a la expiración, obtiene dos marcas de tiempo, de A y B , y así aumenta la cadena a la longitud n + 2 .
Con tal esquema, todavía se puede recuperar un compromiso descubierto de A o B , porque en la cadena de sellos de tiempo, puede "omitir" la marca de tiempo podrido.
(Los detalles criptográficos son relativamente intrincados; un punto importante es que una marca de tiempo, según RFC 3161 , es una CMS SignedData con un atributo firmado explícito que contiene el valor de hash de los datos que están marcados con la hora, lo que indica que la marca de tiempo de una marca de tiempo codificada es también una marca de tiempo indirecta para los datos originales. Si eso no fuera cierto, entonces podría tener problemas criptográficos sobre propiedad exclusiva , es decir, que un valor de firma no es necesariamente tan bueno como un hash. Cuando entienda lo que quiero decir aquí, sabrá lo suficiente como para implementar la validación del archivo CAdES-A).
El "período de gracia" es otro mecanismo para mejorar la capacidad de recuperación. Su premisa es que los compromisos se descubren después del hecho, pero generalmente no son largos después del hecho. Aplicar un período de gracia de una semana (por ejemplo) significa que te permites esperar una semana, en caso de que se descubra un compromiso pasado. Si después de una semana las cosas todavía parecen estar bien, entonces empiezas a suponer que aunque haya ocurrido un compromiso en los últimos cinco minutos (y aún no lo sabrías), la situación probablemente estuvo limpia hace una semana. Con los sellos de tiempo obtenidos en el momento adecuado, esto puede dar mucha resistencia adicional, a costa de una mayor complejidad.