Assumi la seguente infrastruttura a chiave pubblica:
| Root CA (RSA)
| -Sub CA (RSA)
| -Sub CA (ECC)
C'è qualche razionale che spiega perché questa non sarebbe un'implementazione accettabile?
L'implementazione preferita è una PKI per RSA e una PKI separata per ECC?
Come per X.509 , nessun problema. È possibile combinare algoritmi a volontà. Ogni firma è indipendente.
(X.509 include una disposizione speciale per quando una CA utilizza DSS e emette un certificato che utilizza anche DSS con gli stessi parametri di gruppo , nel qual caso il certificato emesso può omettere i parametri del gruppo. Questa è chiamata "ereditarietà dei parametri", che non è mai stata utilizzata nella pratica, ed è stata non portata su ECDSA, anche se era una possibilità e apparentemente era stata immaginata ad un certo punto. le mie conoscenze, in cui gli algoritmi di firma a vari livelli della catena hanno una relazione qualsiasi.)
Tuttavia , devi capire che, utilizzando diversi algoritmi distinti, costringi le "parti relying" (sistemi che devono convalidare queste catene) per implementarle tutte. Anche se questo normalmente non rappresenta un problema per i sistemi desktop, i server e gli smartphone, questo potrebbe essere un problema per i piccoli dispositivi embedded che vogliono risparmiare sulle dimensioni del codice e preferirebbe non includere il codice per RSA e per ECDSA.
Questo tipo di problema è incarnato per es. in SSL , dove client e server si dicono reciprocamente quale tipo di algoritmo supportano per la convalida delle firme sui certificati (si veda ad esempio il Certificate Request messaggio). Questo ha lo scopo di supportare meglio i piccoli dispositivi con poco spazio nel codice. Fare una miscela di RSA e ECDSA nelle tue catene di certificati ti mette un po 'in contrasto con quel principio. A seconda del contesto, questo può o meno importare (sarà probabilmente non importa).
In ogni caso, questo tipo di catena mista è previsto per una transizione . Supponiamo che inizi con un mondo completamente RSA; la CA radice è stata distribuita a tutti i sistemi client (probabilmente a costi elevati). Ora, prendi la decisione di passare a ECDSA, perché il software client è all'altezza (ad esempio, è fornito con normali aggiornamenti del sistema operativo / browser), ma la creazione di una nuova radice ECDSA e la sua implementazione su tutti i client richiederà molto tempo. Quindi, per iniziare a utilizzare ECDSA senza rompere le cose per la base installata, fai i certificati incrociati:
Questo certificato incrociato consente ai sistemi che conoscono newRoot come root attendibile di convalidare un certificato con un percorso "newRoot- > cert" e sistemi che sanno solo oldRoot utilizzerà "oldRoot- > newRoot- > cert" (in quest'ultimo caso, passando attraverso il certificato incrociato). In altre parole, newRoot ha due certificati, uno autofirmato (con ECDSA), l'altro firmato da oldRoot (che rende newRoot una intermedia CA).
Questo è un metodo abbastanza standard per gestire i rinnovi con modifiche chiave, ma implica necessariamente, nel caso di una transizione da RSA a ECDSA, catene di algoritmi misti. Pertanto, la situazione che descrivi non è solo supportata ma prevista.
Per riassumere: l'utilizzo di PKI completamente separati consente la PKI a singolo algoritmo, che può aiutare i dispositivi incorporati (solo un algoritmo da implementare). Tuttavia, PKI a algoritmi misti sono una cosa normale, ben supportata e prevista in caso di transizioni PKI a livello di nuovi algoritmi.
A mia conoscenza, non vi sono requisiti sull'algoritmo per la CA subordinata diversa da quella che la CA radice desidera applicare.
In realtà, piuttosto che cercare un motivo per cui sarebbe inaccettabile, vorrei esaminare perché è accettabile. Qualsiasi certificato CA subordinato deve essere firmato dalla CA principale. E la CA radice rappresenta la fiducia ultima. Se la CA radice si fida della CA subordinata con un certificato di algoritmo ECC / RSA / qualunque, allora va bene. La CA radice firma il certificato e ne estende la fiducia.
Tuttavia, dovresti probabilmente fornire un criterio della CA, in cui dichiari ciò che tu, come CA, autorizzi, in modo che i tuoi clienti possano valutare se vogliono fidarsi della CA principale o meno. Guarda quale algoritmo è deprecato o rotto e non accettarlo mai nei tuoi certificati.
Leggi altre domande sui tag public-key-infrastructure certificates rsa ecc