È una buona idea generare CRL specifici per certificato? Come si chiama questa tecnica?

4

Supponiamo di creare 3 certificati con i seguenti CRL

Cert1    http://crl.server.com/batch1/root1.crl    
Cert2    http://crl.server.com/batch2/root2.crl
Cert3    http://crl.server.com/batch3/root3.crl

Supponiamo che il CRL sia formato correttamente, che il prossimo aggiornamento sia valido e che sia firmato correttamente dalla CA (qui chiamato "root"). Il contenuto di root*.crl può contenere solo un certificato. (supponiamo che il software del server lo supporti, o che il CRL sia formato da un comando openssl)

Domanda

Questo risolverebbe i seguenti obiettivi:

  • "Nascondere" lo stato di revoca di un certificato a meno che qualcuno non lo possieda e quindi debba conoscerlo. (Supponiamo che la parola "batch" sia un GUID assegnato)

  • Riduci le dimensioni del CRL durante la manutenzione in corso

Quali sono i vantaggi aggiuntivi di questo approccio?

Esistono altre / migliori soluzioni che possono soddisfare questa esigenza o incorporare la riduzione delle dimensioni del CRL e / o la privacy?

Come si chiama questo approccio?

(entrambi gli obiettivi di efficienza e privacy non sono requisiti ... questo è un esperimento mentale per me)

    
posta random65537 08.01.2013 - 02:44
fonte

1 risposta

7

La segmentazione dello spazio dei certificati in modo che il CRL "parziale" possa essere calcolato è possibile e supportato, ma deve essere eseguito correttamente. Un principio di base di CRL è che un CRL dovrebbe essere suscettibile di essere elaborato indipendentemente da come è stato ottenuto: questo è il punto principale di avere oggetti firmati. Poiché un certificato è considerato non revocato in virtù di non visualizzato nel CRL, deve essere possibile verificare senza ambiguità se un dato CRL si applica a un determinato certificato o meno - nella terminologia X.509 , se il certificato è nell'ambito del CRL.

L'estensione da utilizzare è CRL Distribution Points - consulta la sezione 4.2.1.13 di RFC 5280 . Questa estensione ha due ruoli distinti: documenta l'URL dove è possibile ottenere CRL e implementa la segmentazione dello spazio dei certificati. Per la segmentazione (quella che ti interessa), l'estensione deve essere contrassegnata critica e deve esserci una corrispondenza tra un "punto di distribuzione" e la struttura corrispondente nell'estensione Issuing Distribution Point del CRL . In effetti, ogni punto di distribuzione caratterizza un sub-spazio dello spazio del certificato; ogni certificato è contrassegnato con lo spazio secondario a cui appartiene e ogni CRL è contrassegnato con lo spazio secondario a cui si applica. Come per tutte le cose X.509, i dettagli sono intricati e sono necessari alcuni test approfonditi per valutare la realtà del supporto delle applicazioni esistenti.

Tale segmentazione è utile per mantenere bassa la dimensione del CRL. Potrebbe essere usato per creare CRL con certificato singolo, anche se questo dovrebbe essere bilanciato con il costo di firmare tutti questi CRL (le firme non sono costose, ma un milione di firme può diventare un peso - non proprio le firme in sé, ma tutta la codifica e il trasferimento di file ha qualche overhead).

Non ci si può aspettare molto guadagni per la privacy in questo modo: i certificati sono intrinsecamente elementi pubblici, che viaggiano senza protezione in molti protocolli. Non possono essere considerati segreti. C'è poco di più che può essere ottenuto da CRL; in realtà, un CRL completo è già discreto poiché parla solo di certificati revocati: non dice nulla sui certificati non revocati e non fa nemmeno cenno alla loro esistenza.

In definitiva, il CRL con certificato singolo esiste già ma si chiama risposte OCSP .

    
risposta data 08.01.2013 - 03:39
fonte