C'è il tempo della firma e c'è il tempo della verifica. Per prima cosa semplificiamo la situazione: supponiamo che la data attuale sia il 2009-07-08. Per quel valore di "adesso", i certificati RootCA e SubCA sono ancora validi, ma il certificato di Alice non lo è. Vedete una firma che presunta è stata prodotta da Alice nel 2009-05-01.
Se provi a convalidare il certificato di Alice, troverai che è "scaduto" e, per X.509 , questa è la fine della storia (sezione 6.1.3, passaggio a.2). Forse, potrebbe esistere una prova che la firma esisteva già in una data passata, ad es. 2009-05-02; timestamp possono essere tali prove. A quella data, il certificato di Alice era ancora valido, quindi potresti virtualmente immaginare di guardare la firma e i certificati nel 2009-05-02 e di eseguire l'algoritmo di convalida in quel momento. Se fossi convinto della validità della firma in quel momento, lo ricorderesti ancora adesso. Questa è la base della validazione precedente .
Ma puoi davvero viaggiare nel tempo in questo modo? C'è il problema con la revoca . In un modo generico, come sapresti se la chiave privata di Alice è stata rubata? Immagina che, nel 2009-04-15, un individuo malvagio (chiamiamolo Albert) abbia rubato la chiave di Alice. Sicuramente, una firma calcolata con quella chiave del 2009-05-01 non può essere attribuita indubbiamente ad Alice, poiché Albert avrebbe potuto calcolare lo stesso. In X.509, le informazioni sulle chiavi rubate ("chiavi compromesse" in gergo X.509) sono distribuite tramite revoca. Il CRL pubblicato dalla SubCA includerebbe il certificato di Alice con una "data di revoca" del 2009-04-15 (il furto potrebbe essere stato scoperto solo pochi giorni dopo, ma il formato CRL include un campo che indica la data limite). Ora è il punto delicato: un CRL prodotto alla data T include informazioni sui certificati che sono ancora validi (come per "date di validità") alla data T . Il 2009-07-08, il CRL attualmente pubblicato da SubCA non include il certificato di Alice perché il certificato di Alice è scaduto e non è possibile sapere se è stato revocato ad un certo punto o no.
Pertanto, per la convalida passata, è necessario più di un timestamp sulla firma; hai anche bisogno di un timestamp su alcuni oggetti di revoca (CRL, risposte OCSP ...) che sono stati rilasciati mentre il certificato di Alice non era ancora scaduto.
Nella discussione sopra, vedi i due strumenti essenziali:
-
I timbri consentono alcune forme di viaggio nel tempo, in cui ti sei immaginato in una data passata, operando su alcuni valori (firme, certificati, ...) che si sono dimostrati esistenti da quella data.
-
La revoca è il modo in cui tieni a conoscenza dei principali compromessi.
Se ora ci consideriamo il 2010-02-01, abbiamo due ulteriori livelli di complessità:
- Anche il certificato SubCA è scaduto. Quindi è necessario pensare alla possibilità di un furto della chiave di SubCA. Questo è lo stesso problema, a un livello superiore: il certificato SubCA è considerato valido perché era firmato dalla CA radice.
- Anche il certificato RootCA è "scaduto". Questa è una CA radice, quindi non è realmente un "certificato" (da chi è certificato?), Ma alcune a priori informazioni attendibili su un nome e una chiave pubblica. Se RootCA ha una data di scadenza, significa che oltre tale data, ritieni che non ti venga necessariamente reso noto se la chiave privata di root è stata compromessa. A rigor di termini, oltre tale data, non hai alcuna fiducia, quindi hai perso.
Tutti i "modelli" di validazione sono solo modi elaborati per danzare attorno a questi temi, ignorando alcune possibilità di compromesso chiave. Ad esempio, si considererebbe che un furto della chiave privata della radice sarebbe comunque noto, anche al di là della "scadenza" formale della radice, e che la data di fine vita della radice è solo una questione amministrativa. Se inizi a ignorare alcuni possibili problemi di sicurezza, a seconda del cosiddetto "modello", non sorprende che alcune firme siano considerate valide o non valide, a seconda del modello.
Tuttavia, come presentato, il tuo problema è molto incompleto poiché non dice nulla su timestamp, CRL e timestamp su CRL.
Traduzione:
Traduzione: