Perché non utilizzare la stessa CA emittente subordinata per generare certificati che verranno utilizzati per cose diverse?

Esiste un principio generale secondo cui le chiavi dovrebbero essere utilizzate per un solo scopo. In base alle linee guida per l'utilizzo delle chiavi NIST (vedere la sezione 5.2 a pagina 42),

In general, a single key should be used for only one purpose (e.g., encryption, authentication, key wrapping, random number generation, or digital signatures). There are several reasons for this:

1. The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.
2. Limiting the use of a key limits the damage that could be done if the key is compromised.
3. Some uses of keys interfere with each other. For example, consider a key pair used for both key transport and digital signatures. In this case, the private key is used as both a private key-transport key to decrypt data-encryption keys and a private signature key to apply digital signatures. It may be necessary to retain the private key-transport key beyond the cryptoperiod of the corresponding public key-transport key in order to decrypt the data-encryption keys needed to access encrypted data. On the other hand, the private signature key shall be destroyed at the expiration of its cryptoperiod to prevent its compromise (see Section 5.3.6). In this example, the longevity requirements for the private key-transport key and the private digital-signature key contradict each other.

Gli stessi motivi per cui le chiavi ordinarie dovrebbero avere un unico scopo si applicano anche alla chiave di firma CA o alla chiave di firma CA subordinata (SCA).

Non riesco a pensare a una specifica vulnerabilità nei certificati che il motivo # 1 potrebbe creare, ma abbiamo visto abbastanza vulnerabilità crittografiche che si sono verificate ogni volta che i principi vengono violati, quindi non lo escluderei completamente.

Riguardo al n. 2, ovviamente si vuole limitare il danno che si potrebbe fare se un server di firma è compromesso. Quando inizi a gestire il tuo PKI, ti rendi conto di quanto i sistemi possano essere fragili e di quanto sia facile fare errori impercettibili.

Il motivo n. 3 entra nella flessibilità del sistema. Ad esempio, qualcuno nella gestione della proprietà può acquistare una soluzione di sicurezza preconfezionata per la creazione del controllo degli accessi e potrebbe avere i propri requisiti per i certificati di emissione SCA che non corrispondono alla gerarchia di certificati SCA corrente. Anziché interrompere gli altri processi di emissione del certificato, puoi isolare la modifica solo al dominio interessato.

Ovviamente, non puoi semplicemente impilare certificati CA subordinati come blocchi predefiniti. Ogni collegamento SCA nella catena di trust indica che un altro certificato deve essere convalidato e che esistono limiti pratici a quanti certificati possono essere convalidati prima che il processo diventi troppo gravoso per i client. Per questo motivo vedrai che le CA principali attendibili non delegano ai certificati SCA sui loro server di lavoro, anche se sarebbe meglio separare la loro infrastruttura. Ma le CA radice di fiducia hanno molta esperienza sul campo e hanno progettato i loro sistemi focalizzati sulla sicurezza della loro architettura; tutti ci fidiamo di loro per fare bene il loro lavoro. (La realtà cinica è che ogni volta che una CA radice ha commesso un errore ed è stata compromessa in passato, la perdita di fiducia significa che la società tende a chiudere la propria attività rapidamente.)

L'utilizzo di diverse CA intermedie ti consentirà di differenziare i certificati dell'entità finale dal loro emittente. Ciò rende possibile creare regole di fiducia che limiteranno l'utilizzo dei certificati in base al loro emittente.

Rilasciando tutti i tuoi certificati dalla stessa iCA, sarà facile consentire l'utilizzo errato di un certificato per qualcosa di non voluto.

Ciò consentirà, ad esempio, di generare un certificato di autenticazione wifi dal certificato di connessione client iCA1 e TLS (servizi Web) da iCA2 e quindi di configurare il punto di accesso Wi-Fi in modo che si possa fidare di qualsiasi certificato emesso da iCA1. Ciò impedirà il riutilizzo del certificato che emetti per i tuoi servizi web per accedere alla tua rete wifi (e viceversa) senza dover confondere con OID nei certificati (che potrebbero non essere nemmeno supportati dal software che utilizza questi certificati).

Potresti fare esattamente la stessa cosa con CA separate, tranne per il fatto che questo richiede un maggiore sforzo di gestione.