Più CA che firmano un singolo Cert / CSR?

Sulle modifiche a SSL / TLS: il protocollo SSL / TLS invia i certificati come anonimi blob che possono avere qualsiasi dimensione, fino a circa 16 MB (che è ridicolo). Il protocollo stesso non deve essere modificato se si desidera utilizzare alcuni nuovi formati di certificato.

Le implementazioni SSL / TLS prevedono che i BLOB siano codificati certificati X.509 . Tale certificato ha spazio per un singolo emittente (il nome della CA è scritto in esso) e una singola firma. Quindi non è possibile avere un "certificato multi-firmato" entro i limiti dello standard X.509 esistente. potresti ottenere diversi certificati, con la stessa chiave pubblica in ciascuno, e quindi ti servirebbe solo una sorta di convenzione in modo che il software client SSL non si occupi di ricevere più di un certificato per il server, e li controlla tutti.

Informazioni sull'emissione dei certificati: una richiesta di certificato è solo una nave per la chiave pubblica del richiedente, il suo nome previsto e qualsiasi tipo di informazione che la CA è libera replicare, o meno, nel certificato rilasciato. Non ci sono problemi teorici nell'avere più certificati, anche da CA distinte, che contengono tutti il tuo nome e la tua chiave pubblica; in realtà, qualsiasi CA potrebbe rilasciare tale certificato senza che sia necessaria alcuna interazione con te. Potrebbero tutti usare la stessa richiesta di certificato. In pratica , richiederebbe alcune modifiche, poiché i certificati di emissione CA esistenti come parte di scenari basati sul Web, in cui il browser dell'acquirente viene istruito per generare una nuova coppia di chiavi e inviano la parte pubblica alla CA senza alcuna interazione con il compratore umano. Dal momento che l'idea di avere almeno tre certificati proprietari di ciascun server triplica fondamentalmente il mercato dei certificati server, sono abbastanza sicuro che l'AC commerciale sarebbe disposta a implementare le modifiche rilevanti alla propria piattaforma.

Sulla solidità dell'idea: richiedere più convalide è un'idea valida (il OpenPGP formato lo fa già, principalmente per gestire l'inaffidabile inerente di una CA della web-of-trust) ma potrebbe ritorcersi contro: se avere un singolo ladro o una CA compromessa non ha impatto sulla sicurezza generale, è probabile che il prossimo evento simile a Comodo riceverà meno pubblicità, probabilmente nessuna. La convalida multipla tende a incoraggiare l'indulgenza generale e la perdita di responsabilità.

On Convergence: di cui parla la citazione di slashdot è Convergence . Questo è un nuovo sistema che cerca di prendere piede. Vedi questa risposta per alcuni dettagli e indicazioni sul protocollo.

In realtà penso che questa sarebbe davvero una buona idea. Ma richiederebbe una nuova versione di SSL e TLS da supportare. Attualmente tutto è progettato con l'ipotesi che esista esattamente un'ancora di trust. Il che significa che probabilmente non succederà mai. Ho ancora discussioni con persone che affermano che "abbiamo bisogno" di supportare Windows 98.

Dubito che questa idea possa funzionare. Le CA richiederebbero una API tra loro per automatizzare la firma del certificato. Per cosa controllerebbero? Se non controllano le reciproche richieste, un hacker che ha ottenuto l'accesso a un'API CA (come nei casi Comodo e DigiNotar), avrebbe comunque vinto. Se fa controlla le richieste di firma tra le CA, cosa controllare?

Ciò che l'approccio multi-CA potrebbe impedire, è un utente malintenzionato che ottiene i certificati per domini di alto profilo come * .google.com, se una seconda AC di firma contrassegna quelli in cui il primo è fallito.

Personalmente, tuttavia, mi piace l'approccio alla prospettiva di rete di Moxie. Soprattutto dal momento che rimette la decisione di fiducia nelle mani dell'utente, senza renderlo una soluzione esclusivamente tecnica.

Probabilmente sono in ritardo di alcuni anni ma comunque ...
Un problema che viene in mente è che un mitm può impedire al client di negoziare per più certs e ottenere solo quello che ha violato da una CA.
La soluzione facile IMO è usare un'altra porta o semplicemente creare un altro nome di protocollo in modo che il cliente sappia che dovrebbe ottenere più di un certificato.

Un modo migliore è già nelle opere sotto forma di DNSSEC e DANE. La vulnerabilità principale nell'attuale sistema di certificati del sito è che qualsiasi CA può emettere certificati per qualsiasi nome di dominio. Quindi, basta una sola CA cattiva per compromettere qualsiasi dominio. Al contrario, è possibile specificare la chiave che firma i certificati del sito per un determinato dominio:

Da link (la specifica DANE):

"Il modello CA pubblico da cui è dipeso TLS è fondamentalmente vulnerabile perché consente a ciascuna di queste CA di rilasciare un certificato per qualsiasi nome di dominio. Una singola CA attendibile che tradisce la propria fiducia, volontariamente o fornendo meno di una protezione energica per i suoi segreti e le sue capacità, può compromettere la sicurezza offerta da tutti i certificati utilizzati con TLS Questo problema deriva dal fatto che una CA compromessa può emettere un certificato sostitutivo contenente una chiave falsa. a problemi di sicurezza molto gravi, come i governi di più paesi che tentano di intercettare e / o sovvertire i principali siti Web protetti da TLS fidati da milioni di utenti. "