Gruppi di utenti (cerchi) all'interno di una rete di fiducia

Question

Gruppi di utenti (cerchi) all'interno di una rete di fiducia

#1 da (3 voti)

4

Supponiamo di avere un universo di utenti U. Ogni utente ha la sua chiave privata. Voglio creare gruppi di utenti aggiungendo una sottochiave aziendale al suo set di chiavi. Ora gli utenti possono firmare la sua sottochiave aziendale con le sottochiavi aziendali.

Ora l'utente si dimette dalla società. È pigro e non revocherà immediatamente la sua sottochiave, o suona non giusto, e non lo revocherà mai. Ok, altri potrebbero revocare le loro firme dopo che sono stati informati che ha lasciato la compagnia, ma altri potrebbero non revocare mai le loro firme.

Come posso assicurare che dopo le dimissioni, verrà licenziato / negato l'accesso al gruppo?

Aggiornamento: Ho scoperto che PGP supporta qualcosa chiamato "Designated revoker". La definizione per questo è:

A designated revoker in OpenPGP is a partner key that we trust and that can be used to revoke our public key in the case when we have lost our own private key and cannot do the revocation ourselves.

Potrebbe essere una soluzione al mio problema?

pgp certificate-revocation

posta esskar 30.04.2013 - 04:32

fonte

1 risposta

Leggi altre domande sui tag pgp certificate-revocation

Come può il browser selezionare i suggerimenti per le mie ricerche private? Dominio dei rapporti sugli incidenti o sulla politica di notifica?

score 3 · Accepted Answer

Ci sono due punti generici che devono essere fatti:

PKI è per autenticazione , non per autorizzazione . "Certificati", che si tratti di X.509 o OpenPGP "key signing" (stesso concetto, formato diverso), hanno lo scopo di associare le identità alle chiavi pubbliche; trasmettono l'informazione "La chiave pubblica di Bob è X". I certificati non funzionano bene per gestire informazioni di tipo "autorizzazione" come "Bob può firmare il nome della società Y".

La revoca è il soggetto in cui questa distinzione è più facilmente visibile. La revoca è asincrona; non è efficiente come propagare le modifiche rapidamente . Se Bob viene licenziato, vuoi revocare i suoi "diritti di firma" immediatamente , preferibilmente cinque minuti prima di informare Bob stesso che non è più il benvenuto. Non vuoi rimuovere i diritti alcune ore o giorni dopo l'atto, perché c'è un sacco di danno che un Bob contrariato potrebbe fare.
Non puoi imporre l'oblio. Nella crittografia, il potere è conoscenza: puoi firmare o decifrare in virtù della conoscenza della chiave privata corrispondente. Quando un partecipante ha questo potere, in qualche modo "conosce" la chiave privata, se possibile solo potenzialmente (ad esempio, la chiave è nel suo computer). Se sceglie di ricordare la chiave per sempre, beh, può farlo. Non puoi assicurarti che non abbia tenuto un backup da qualche parte.

Per rimuovere la potenza della firma da un utente, devi rendere la sua chiave obsoleta. Ciò significa generare una chiave di firma nuova e assegnarla a tutti i restanti firmatari (escluso Bob).

La condivisione delle chiavi di firma non è comunque raccomandata. Quando un segreto è noto a più di due persone, non è più segreto, solo in qualche modo discreto. Se si desidera consentire a un gruppo di eseguire firme nel nome del gruppo, una soluzione solida assumerebbe la forma di un elenco firmato, datato, di breve durata e autorevole di "firmatari autorizzati". Un documento che dice "Il 30 aprile 2013, Alice, Charlie e Donald possono firmare il nome del gruppo Y"; il documento viene quindi firmato da un manager di gruppo. I verificatori controlleranno la firma su questo documento per vedere se il firmatario fa veramente parte dell'elenco corrente dei firmatari consentiti.

Il "manager di gruppo" deve essere un'entità che può decidere chi fa parte del gruppo e chi no. Questo è intrinsecamente centralizzato, quindi in contrasto con il modello decentralizzato del Web of Trust.