cerca CA per la chiave pubblica di qualcuno

Come regola generale, no, CA non consente alle persone di cercare certificati tramite chiave pubblica. In effetti, non permettono alle persone di cercare i certificati affatto , perché il punto dei certificati è proprio quello di evitare qualsiasi tipo di ricerca. La CA è stata progettata per essere, possibilmente, completamente offline, quindi irraggiungibile da chiunque.

Quando i visualizzatori verificano una firma, usano la chiave pubblica e quindi acquisiscono la certezza che il proprietario della chiave privata corrispondente ha firmato il messaggio. Chi è quel proprietario? Questo è il lavoro del certificato per dirlo. Il certificato è un'affermazione verificabile che un nome e una chiave pubblica convivono insieme.

Nel tuo caso, dal punto di vista dei clienti, non c'è firma, hash, niente; c'è solo il tuo server che dice "questo è buono" o "questo non è buono" su un elemento dati che viene fornito anche dal tuo server. Come gestisci le cose internamente è completamente opaco. In questo senso, finché vuoi che le cose siano così, allora le firme sono completamente inutili. Le firme hanno senso solo se è possibile, almeno potenzialmente, mostrarle a terzi (ad esempio, a un giudice in caso di contenzioso). E poiché una firma dimostra solo le cose relative alla chiave pubblica, non altro, è necessario mantenere i certificati, perché i certificati collegano quindi le chiavi pubbliche al concetto utile di identità (quando denunci, fai causa a qualcuno , non a una chiave pubblica).

Inoltre, nella descrizione, il tuo server sembra essere quello che firma, non il vero proprietario del certificato. Quindi, anche se mantieni una firma, sarebbe la tua firma, non quella dell'utente iniziale che ha scritto i dati nel passaggio 1.

Il concetto importante qui è che quando il tuo server autentica un client "con un certificato", questa è solo autenticazione . Non dimostra a terze parti che il suddetto cliente abbia davvero scritto i dati che archivi. Infatti, anche se si conserva una copia completa di tutti i pacchetti IP coinvolti, ciò dimostra solo che in una data passata non specificata, quel client si è connesso una volta al proprio server, ma non dice nulla sui dati inviati attraverso quella connessione. L'autenticazione è la prova solo per chi sta eseguendo l'autenticazione, cioè il server, ma non è verificabile in seguito. Se quel punto ti sembra poco chiaro, devi leggerlo di nuovo, e ancora, finché non lo afferrerai; non puoi fare alcun lavoro utile con i certificati se questo non ti sembra ovvio.

Credo che abbiate perso un passaggio, nel passaggio numero 3 è necessario che l'utente firmi l'hash con la sua chiave privata. E credo che questo sia un compito che un utente deve fare da solo (o usando javascript o qualcosa di simile in modo che la sua chiave privata non finisca nella tua piattaforma (o in qualsiasi altra).

Se lo fai, allora è più facile fare in modo che l'utente incolli la sua parte di chiave pubblica all'interno di un modulo nel suo profilo utente in modo da poterlo usare facilmente (ci sono servizi come bitbucket o github per esempio di come fare questo).

Non puoi generare la firma o parte di essa come il digest. Per fare ciò, devi avere la chiave privata dell'utente, che invalida la sua privacy.

L'utente che invia i dati deve generare la firma digitale contenente il digest utilizzando la propria chiave privata. La firma conterrà la parte pubblica verificabile del certificato dell'utente.

Chiunque visualizzi i dati può autenticarlo con due passaggi: 1) decifrare il digest nella firma usando la chiave pubblica contenuta nella firma e confrontarla con un digest dei dati creati dal visualizzatore; 2) Verificare che il certificato contenga la chiave pubblica emessa dalla CA identificata all'entità che rivendica la paternità. Diversi dettagli possono essere inclusi in una firma. Le firme più forti contengono un timestamp che conferma che la firma è stata creata in un determinato momento e data in cui il certificato è stato confermato valido dal server di timestamping.

Quanto sopra è la descrizione standard di come utilizzare PKI per disceminare i dati autenticati.

Nel tuo caso, ti suggerisco che all'utente venga richiesto di inviare un file con firma digitale e che l'applicazione convalidi la firma. Nel tentativo di catturare la firma in un processo separato come parte della vostra applicazione, state intraprendendo un lavoro non necessario e divergete dalle norme ampiamente supportate. Inoltre, sei fuori dal regno delle soluzioni standard. HTML e JavaScript, ad esempio, non forniscono alcuna assistenza. Credo che sia possibile costruire un'app Java sul lato client per accettare i dati dall'utente e quindi richiedere che il certificato esegua l'operazione di firma prima di caricare il documento firmato sul server. Sebbene non abbia mai visto una tale implementazione, OWASP fornisce il codice pertinente per utilizzare il Architettura di crittografia Java . Questo è possibile, ma non l'approccio che consiglierei.

La firma digitale dei documenti utilizzando i certificati PKI x.509 è supportata da molte applicazioni tra cui Microsoft Office . In molti casi d'uso, richiedere all'utente di firmare digitalmente un documento per la prima volta non è un grosso problema.

Alcune terze parti offrono soluzioni che potrebbero esserti utili. Potresti voler esaminare le soluzioni offerte da Adobe o Arx .

Questo suona molto simile ai servizi di directory LDAP VeriSign (ora Symantec) opera per i loro prodotti ID client dove è possibile recuperare i certificati dati l'indirizzo email o altri attributi da cercare (su ldap: //directory.verisign.com ). Per ridurre il rischio di un attacco man-in-the-middle che modifica le risposte LDAP, si utilizzerà una connessione protetta TLS, assicurandosi che il certificato del server LDAP fornito sia quello previsto.