Per semplificare le cose, uno degli obiettivi di U-Prove è di fornire una sorta di anonimato (nelle loro parole, "prevenire il tracciamento degli utenti indesiderati"). Questo rende più difficile la revoca. In un contesto X.509, in cui non esiste l'anonimato dell'utente (un certificato contiene il nome del proprietario in parole semplici), la revoca è semplice: l'autorità che decide chi è revocato e chi non è semplicemente emette dichiarazioni firmate sullo stato di revoca di un dato certificato. Può trattarsi di una risposta OCSP , che parla di un singolo certificato o di CRL , che elenca i tutti certificati revocati (da un determinato emittente o gruppo di emittenti), e quindi elenca in modo implicito tutti i non- anche certificati revocati.
Se provi a fare la stessa cosa con U-Prove, hai inventato un modo per tenere traccia degli utenti, e non va bene. Quindi la revoca in U-Prove deve utilizzare protocolli più complessi, ad es. un accumulatore crittografico. Principalmente, ciò consente a ciascun proprietario di token di calcolare una prova verificabile di un token che non viene revocato in un dato momento, senza aprire la possibilità di tracciare il proprietario del token. La revoca è ancora asserita da un'autorità specializzata, quindi deve esserci una comunicazione regolare dall'autorità ai proprietari di token; questi sono i testimoni . Ogni proprietario di token deve ottenere un nuovo testimone dall'autorità, al fine di calcolare la prova verificabile che il token specifico non venga revocato in un dato momento.
Questa non è un'ottimizzazione su X.509 CRL / OCSP. In un mondo X.509, ogni proprietario di certificati può ottenere una nuova risposta OCSP dalla CA e quindi mostrare tale risposta a terzi ; questo imita il sistema di propagazione dei testimoni ma con elementi più brevi e meno costi della CPU. Inoltre, in X.509, non è necessario che il proprietario del certificato sia coinvolto affatto; ogni entità che desidera convalidare un certificato può ottenere la risposta CRL o OCSP direttamente dalla CA.
In altre parole, gli accumulatori crittografici non rendono più efficiente la revoca classica. In effetti, lo rendono less efficiente. Ma aggiungono una nuova funzionalità, che è la possibilità di mantenere la revoca pur perseguendo un obiettivo di anonimato non tracciabile. Questo obiettivo non ha senso in X.509. Pertanto, nessun accumulatore crittografico in X.509. potresti provare a progettare e implementare un sistema di revoca per X.509 che utilizza un accumulatore crittografico, ma non fornirebbe funzionalità aggiuntive e renderebbe il sistema più complesso, costoso e limitato.
(Nelle parole più brevi, non esiste uno schema di revoca per X.509 che utilizza gli accumulatori crittografici perché sarebbe una cosa stupida da fare. Sarebbe come aggiungere un serbatoio di benzina extra per alimentare un carro trainato da cavalli: sarebbe non aiuta i cavalli ad andare più lontano, anche se avrebbe aiutato se i cavalli non fossero stati cavalli, ma un motore a combustione.)