Eve potrebbe firmare un certificato indicando "a.com" come nome, con la sua chiave privata, ma il browser di Bob non lo accetterà. Quando il browser di Bob convalida una catena di certificati, verifica tutte le firme, ma non solo la firma. L'algoritmo di convalida completo è complesso; vedi lo standard . In questo caso, il browser di Bob solleverà un sopracciglio metaforico quando si applica check (k) dalla sezione 6.1.4: Il certificato di Eve è un certificato "versione 3", ma non contiene un'estensione Basic Constraints
, o la sua estensione Basic Constraints
ha il flag cA
impostato su FALSE
.
In breve, anche se la certificazione è una sorta di delega di potere, la potenza di emettere certificati viene specificata per richiedere una delega esplicita e non viene eseguita per impostazione predefinita. Come dice @Terry, CA commerciale può garantire i certificati di sub-CA, con il flag cA
impostato su TRUE
, ma si caricheranno molto per quello. In effetti, vincoleranno contrattualmente la CA secondaria al rispetto della Dichiarazione sulla certificazione della CA (vedere ci per il CPS di Verisign). Gli obblighi contrattuali comprendono un sacco di chiacchiere con assicurazioni e cose del genere, in modo che una CA-CA che emette certificati falsi verrebbe buttata nel dimenticatoio dalla rappresaglia legale di Verisign. Non fanno prigionieri.
Le cose non funzionavano in quel modo nel passato. La prima versione di X.509 non supportava le estensioni, quindi i client dovevano trovare un altro modo per verificare se una determinata entità avesse o meno la potenza CA. Ciò era inopportuno, poiché i browser dovevano scegliere tra l'incorporamento di un elenco crescente di "CA subordinata consentita" o semplicemente affidarsi a tutti i certificati con CA power (consentendo così l'attacco). Si noti che fino all'anno 2003 o giù di lì, c'era un bug in Internet Explorer: IE non controllava affatto l'estensione Basic Constraints
! Quando questo è stato scoperto, è stato prontamente aggiornato, naturalmente ...