Stai proponendo che, invece di usare una PKI standard, dove qualcuno (governante o meno) controlla una CA che firma i certificati, sarebbe più semplice avere solo una (grande) lista di chiavi pubbliche riconosciute dal governo associate alla persona correlata . In altre parole, un grande elenco ricercabile di contenuti del certificato. Sostenete che ciò eviterebbe "il difficile problema della fiducia nelle CA comuni (o nei loro equivalenti)"
Prima di tutto, per essere sicuri di controllare l'elenco corretto e attendibile, il server di ricerca dovrebbe essere autenticato in qualche modo (per evitare completamente PKI, che è usato in TLS / SSL, probabilmente dovresti mettere il certificato del server nella tua fiducia e controlla i fuori campo se è valido). Non è chiaro come risolveresti questo in modo scalabile senza utilizzare PKI. È possibile, ovviamente, ma non è più facile o più semplice delle normali sfide di fiducia con PKI.
BTW, parte del mio lavoro di tesi principale riguarda il modo in cui un PKI potrebbe essere quello di risolvere alcuni dei problemi di PKI standard, e usiamo i server online per fornire lo stato del certificato e discutere molti problemi con gli PKI standard. In molti modi la tua proposta si adatta alla nostra, tranne che non è mirata a risolvere i problemi di fiducia di PKI, ma altri problemi. Parte del lavoro è disponibile qui: link
Sebbene NON risolva il problema di affidabilità, la tua proposta aggiunge molti altri problemi:
1) Non è offline verificabile. Si può affermare che questo non è un problema al giorno d'oggi, quando tutto è sempre online, e mentre non è strettamente vero, sono d'accordo che per la maggior parte delle applicazioni non c'è un grande vantaggio sulle caratteristiche offline di PKI x509 (ecco perché abbiamo proposto anche NBPKI)
2) Per la firma / verifica, è necessario essere in grado di verificare in qualsiasi momento in futuro se un legame chiave è valido al momento della firma. Per alcuni scenari che possono richiedere anni e decenni tra la firma e l'ultima verifica necessaria. Ciò significa che anche se il legame tra la persona x chiave viene perso, il server deve ancora in qualsiasi momento in futuro essere in grado di fornire la chiave valida in un determinato momento nel passato. Quindi, la lista cresce solo; Questo non va bene perché non salirà in scala, non sarà efficiente;
3) Hai un singolo punto di fiducia da attaccare. Non va bene affatto;
4) Per risolvere tutti questi problemi è esatto il motivo per cui PKI è come è. Invece di una lista, hai le prove di collegamento tra ogni chiave e ogni persona. Quelli sono piccoli, e in realtà più FACILI da validare (costano meno potenza e risorse computazionali). Queste prove hanno una validità presunta solitamente basata sulla protezione della chiave privata e possono essere revocate se necessario utilizzando un elenco di certificati revocati (che tende ad essere più piccolo di un elenco di quelli validi e può essere ridotto utilizzando OCSP).
Hai menzionato il problema di cui è difficile avere fiducia nelle CA comuni. Questo non è assolutamente vero, e può essere risolto in alcuni modi: Federated CAs, o TSL (Trusted Services List, usato in Europa) o semplicemente avere una CA nazionale come in Brasile che firma tutte le altre CA di fiducia, quindi è necessario solo per fidarsi di un singolo punto di fiducia. Se questo è il motivo principale per scegliere la tua proposta, non vedo un vero vantaggio tra avere una singola CA nazionale e la tua proposta. Oltre a questo, PKI ha così tanti vantaggi rispetto alla tua proposta su scenari di utilizzo reali, che spiegano perché è largamente usato fino ad ora.
Detto questo, il PKI ha i suoi problemi, ma la maggior parte di essi si trova esattamente nella centralizzazione della fiducia nei punti di debolezza, e può essere risolta con approcci più decentralizzati. Il tuo oggetto sta andando in direzione opposta, proponendo di centralizzare ancora di più la fiducia in una singola lista.