Modello gerarchico di attendibilità PKI

Penso che tu debba essere più specifico su cosa intendi con "Cosa succede se Alice non si fida esplicitamente di C." Alice, e solo Alice, ha deciso di non fidarsi di C, o A ha revocato il certificato di C?

La mia comprensione del processo (astratto) di Alice è:

// trova una firma che può verificare

1 . Alice vedrà che cert_Doris è firmata da cert_C e chiede "ho una chiave di verifica per cert_C ?" .... No .

2 . cert_C è firmato da cert_A , "ho una chiave di verifica per cert_A ?" ... Sì .

// quindi torna indietro lungo la catena che esegue verifiche

3 . La firma su cert_A controlla, ed è valido il certificato (cioè non revocato)? ... Sì

4 . La firma su cert_C controlla, ed è valido il certificato (cioè non revocato)? ... Sì

5 . La firma su cert_Doris controlla, ed è valido il certificato (cioè non revocato)? ... Sì

6 . Ora Alice si fida di Doris perché hanno un'ancora comune di fiducia.

I dettagli di questo processo dipenderanno ovviamente dal software PKI utilizzato dall'organizzazione.

Come sottolinea @MaartenBodewes: nota che questo processo non richiede che Alice sia connessa ad A, infatti, quel processo funzionerebbe bene per Eric che non ha nemmeno i certificati, fintanto che ha deciso di fidarsi A. (Questo è il modo in cui il blocco dei certificati nei browser funziona, poiché i client di TLS in genere non hanno certificati, sono come Eric.)

Come per

What happens if Alice explicitly does not trust C.

È del tutto possibile che il tuo software PKI consenta ad Alice (oa qualsiasi CA sopra Alice) di mettere in blacklist un utente specifico o una CA specifica, senza revocare globalmente il certificato, sebbene non abbia mai sentito parlare di una PKI che lo offre.

Come per

Does Alice need to have a certificate of D, B and C as well?

Tecnicamente no, avere la chiave di verifica per A è crittograficamente sufficiente, anche se per grandi organizzazioni, come un governo, con molte CA e utenti dipartimentali, fare una ricerca completa ogni volta può essere molto lento, così Alice può localmente memorizzare i certificati una volta che li ha ritenuti affidabili in modo che le ricerche future siano più veloci. Questo potrebbe portare a problemi di sicurezza se la revoca non viene verificata fino alla radice ogni volta. Dipende dal software specifico e dalle politiche dell'organizzazione per decidere se quel rischio valga l'inconveniente delle ricerche lente.

L'idea che ci sia bisogno di un percorso da Alice a Doris è errata. Deve solo essere una catena di certificati valida da Doris a un certificato attendibile nel trust store di Alice. E Doris - ovviamente - deve dimostrare di possedere la chiave privata che appartiene al certificato di Doris stessa.

Quindi tutto ciò che Alice richiede è un certificato attendibile A o C. Ha bisogno di recuperare tutti i certificati intermedi se non ha una catena completa (se ha appena A ha bisogno di recuperare C - di solito è inviata ad Alice da Doris). Deve essere in grado di verificare la firma dei certificati e la validità dei certificati nella catena. La procedura di convalida può verificare l'utilizzo delle chiavi, le estensioni delle chiavi, il periodo di validità e, naturalmente, lo stato / la revoca del certificato ecc. La catena può anche consistere semplicemente nel certificato di Doris se è considerato attendibile (blocco del certificato).

Infine, la firma della chiave privata deve essere verificata utilizzando la chiave pubblica del certificato Doris. Oppure potrebbe essere necessario utilizzare la chiave privata per decodificare una chiave di sfida o di sessione.

Alice non ha nemmeno bisogno di un certificato / chiave privata lei stessa. Attualmente il mio browser non ha nemmeno il mio certificato. Solo le entità che devono autenticarsi devono avere una chiave privata e un certificato corrispondente.