Tutte le autorità di certificazione radice sono autofirmate. Il che significa che ci sentiamo costretti a credere implicitamente che la CA sia gestita in modo responsabile e sicuro. Questo non è sempre il caso ( Diginotar ).
Esistono alternative al metodo dell'autorità di certificazione. Uno di questi è la rete di fiducia , che viene utilizzata principalmente in PGP / GPG / OpenPGP implementazioni.
Ci sono situazioni che possono sorgere nelle implementazioni PKI in cui abbiamo bisogno di un PKI per "fidarsi" di un altro. Questa è chiamata cross-signing o certificazione incrociata .
Uno dei componenti chiave di una PKI è un servizio directory LDAP . È qui che i certificati firmati e le informazioni sulla revoca sono pubblicati per essere pubblicamente disponibili. La directory assume la forma di una struttura ad albero. Ogni voce nell'albero fa parte del nome distinto della voce (DName). Un esempio è CN = NRC, OU = IT, O = MyOrg, C = GB. In questo DName l'elemento radice è C, che è un paese, seguito da O, per organizzazione, unità organizzativa, unità organizzativa e CN, che è un nome comune. Ogni elemento DName è una voce nell'albero delle directory, che ha una classe oggetto dello schema specifica. La classe dell'oggetto definisce gli attributi obbligatori e facoltativi per una voce. L'elemento CN viene solitamente rappresentato in termini LDAP dalla classe dell'oggetto schema chiamata inetorgperson, tuttavia sono stati sviluppati tipi specializzati per scopi PKI. Lo schema LDAP completo per gli oggetti PKI è definito qui .
Incluso in questo è la definizione della classe oggetto CA PKI. Questo include l'attributo crossCertificatePair. Utilizzando questo attributo, i certificati aggiuntivi per la CA possono essere emessi da un'altra CA (come nel diagramma). Ciò significa che, sebbene il certificato CA principale sia autofirmato, per motivi di certificazione incrociata l'ancoraggio di trust è un'altra CA radice. Infatti, se RootCA1 firma un certificato di certificazione incrociata per RootCA2, RootCA2 può anche firmare un certificato di certificazione incrociata per RootCA1. Infatti, come specificato nella domanda, è possibile ottenere la situazione dell'anello tramite la certificazione incrociata, dove RootCA1 firma RootCA2, RootCA2 firma RootCA3 e RootCA3 firma RootCA1. La convalida delle CA certificate incrociate richiede che il processo di convalida cerchi certificati certificati incrociati nella voce LDAP per la CA, poiché non vi è alcun riferimento a questi nel certificato della CA radice (il certificato "core" autofirmato), anche se dovrebbe esserci un riferimento alla voce LDAP per la CA nell'estensione Accesso alle informazioni sui soggetti .
Se si tiene conto della certificazione incrociata, la convalida del percorso del certificato può diventare un processo incredibilmente complesso. Tuttavia, sono stati sviluppati servizi software specializzati che consentono agli utenti di "esternalizzare" il processo complesso a autorità fidate di convalida. Questi servizi sono chiamati protocollo di stato dei certificati online e server di convalida del certificato basato su server . Axway VA è un server che include sia OCSP che SCVP in uno e può essere configurato per fornire la convalida completa del percorso del certificato in ambienti CA con certificazione incrociata.
