Teoricamente, le catene X.509 sono illimitate. L'estensione Vincoli di base può applicare un limite per catena; questo è usato principalmente per CA che accetta di rilasciare un certificato CA secondario ma desidera limitare tale CA secondaria a emettere solo certificati di entità finale.
Le implementazioni potrebbero avere limitazioni. In effetti, con alcuni certificati accuratamente elaborati, è possibile creare un'applicazione per la creazione di percorsi per esplorare n ! potenziali percorsi di profondità n , e poiché i fattoriali aumentano abbastanza velocemente, ciò può portare a enormi attacchi denial-of-service. Corrispondentemente, le implementazioni tendono a imporre una lunghezza massima relativamente bassa (so che ho usato "8" per le mie implementazioni).
In termini concettuali generali , i trust si diluiscono abbastanza velocemente sulla delega. Quando una CA rilascia un certificato a una CA secondaria, non solo asserisce che la chiave pubblica sub-CA è di proprietà di tale CA secondaria, ma consente anche di eseguire tale tipo di verifica per conto della CA principale. Quando una CA rilascia un certificato per un'entità finale, ne verifica l'identità; quando emette un certificato per una CA secondaria, anche deve assicurarsi che la CA secondaria non sia ingenua. Con un terzo livello, la CA deve garantire che la CA secondaria non sia ingenua e non emetterà un certificato per una CA secondaria subordinata credulona.
Quindi il riflesso sarebbe cercare di mantenere le catene brevi anziché lunghe.
Diffida dell'espressione "single point of failure". Normalmente si applica alla continuità operativa. Qui parliamo di sicurezza: una singola CA canaglia compromette la sicurezza, indipendentemente da quanti altri percorsi crei. Questo va in qualche modo in senso inverso rispetto alla regola SPOF: si evita SPOF aggiungendo ridondanza, ma nel caso della certificazione, qualsiasi CA coinvolta è di natura in grado di compromettere le cose - più CA si aggiunge nel mescolare, più vulnerabile si ottiene.