Quando un certificato viene revocato, il CRL contiene la data di revoca che indica a quale data il certificato è diventato "non valido". Indirettamente, specifica che il certificato era valido fino a quella data. Ad esempio, se una chiave privata viene compromessa dopo un furto, le registrazioni delle telecamere di sicurezza verranno utilizzate per determinare a quale ora è stata rubata la chiave e quella sarà la data di revoca specificata nel CRL.
Se un certificato TSA viene quindi revocato, la validità dell'archivio può ancora essere verificata a condizione che un timestamp di un'altra TSA copra il timestamp del certificato revocato e specifichi una data anteriore alla data di revoca. Ad esempio, considera una catena che funziona così:
- Data / ora S 1 afferma che la firma (e il certificato del firmatario e così via) esisteva alla data T 1 .
- Indicatore orario S 2 afferma che la firma (e il certificato del firmatario e così via) e il timestamp S 1 e il certificato TSA per S 1 e il CRL associato e così via, tutti esistevano alla data T 2 .
- E così via.
Se la chiave privata TSA utilizzata per firmare S 1 è compromessa, o la TSA ha avuto un fallimento, o qualsiasi altra situazione simile, si verifica alla data T , quindi l'archivio è ancora sicuro fintanto che T '> T 2 : grazie al timestamp S 2 , è possibile validare S 1 come se la data corrente fosse T 2 , ea quella data la TSA andava bene e il timestamp esisteva già.
Per una maggiore resilienza, si desidera utilizzare due TSA distinti con timbri temporali sovrapposti intercalati:
- Data / ora S 1 , S 3 , S 5 ... sono di TSA A .
- Data / ora S 2 , S 4 , S 6 ... sono di TSA B .
- Applica sempre i timestamp a coppie. Quando il timestamp più in alto è S n e uno di S n-1 o S n approcci scadenza, ottieni due timestamp, da A e B , e quindi aumenta la catena di lunghezza n + 2 .
Con uno schema di questo tipo, è ancora possibile recuperare un compromesso scoperto di A o B , perché nella catena di timestamp è possibile "saltare" il timbro orario scadente.
(I dettagli crittografici sono relativamente intricati, un punto importante è che un timestamp, come per RFC 3161 , è un CMS SignedData con un attributo firmato esplicito che contiene il valore hash dei dati che sono timestampati, ne consegue che la marcatura temporale di un timestamp codificato è anche un timestamp indiretto per i dati originali. Se ciò non fosse vero, potresti incorrere in problemi di crittografia sulla proprietà esclusiva , vale a dire che un valore di firma non è necessariamente buono come un hash. Quando capisci cosa intendo qui, ne saprai abbastanza per implementare la convalida dell'archivio CAdES-A.)
Il "periodo di prova" è un altro meccanismo per migliorare la resilienza. La sua premessa è che i compromessi vengono scoperti dopo il fatto, ma di solito non sono lunghi dopo il fatto. Applicare un periodo di grazia di una settimana (ad esempio) significa che ti permetti di aspettare una settimana, nel caso in cui venga scoperto un compromesso passato. Se dopo una settimana le cose sembrano ancora buone, allora inizi a supporre che, sebbene un compromesso possa essere successo negli ultimi cinque minuti (e non lo sapresti ancora), la situazione era molto probabilmente pulita una settimana fa. Con i timestamp ottenuti al momento giusto, questo può dare un sacco di resilienza extra, a scapito della complessità aggiunta.