Catena di certificati e permesso di revoca

Risposta breve: NO, Z non può revocare direttamente X. Eccezione: SI, se i CRL di Z sono, a causa di un accordo precedente tra Z & Y, nell'elenco dei punti di distribuzione CRL del certificato X rilasciato da Y.

L'RFC5280 si riferisce a questo come " CRL indiretto " - dove Z può emettere un CRL che include certificati emesso da Y. Funziona solo se il verificatore sa dove controllare. L'' estensione dei punti di distribuzione CRL "dei certificati è il posto in cui dovrebbero essere (dovrebbero).

È ben noto, tuttavia, che la maggior parte degli algoritmi di verifica della certificazione non sono rigorosamente controllati dalla qualità rispetto agli standard - e quindi questo sistema è fallibile in misura non trascurabile.

[Le due risposte esistenti sono buone, ma visto che non hanno alcun upvotes, cercherò di fornire una risposta canonica]

In generale, No . Voglio dire, Z può revocare Y , che revoca automaticamente X e tutti gli altri certificati emessi da Y , ma con PKIs e motori TLS comunemente usati Z non ha alcun meccanismo per revocare X direttamente.

In generale, ogni CA tiene traccia solo dei certificati che emette; in un tipico PKI Z non saprà dell'esistenza di X , e la maggior parte dei motori di verifica cert controllerà il numero di serie di X su Y s CRL e il numero di serie Y su% CRL diZ. Potresti immaginare un sistema in cui Y riporta tutti i certificati che invia alla CA padre in modo che Z non sappia X e potrebbe includerlo in un CRL (anche se dovresti preoccuparti della collisione dei numeri seriali e disporre di uno schema per garantire che non vi siano due CA nella gerarchia che emetteranno lo stesso numero di serie). Quindi devi ancora preoccuparti dei clienti che cercano effettivamente il numero di serie di X sul CRL di Z , che non è un comportamento standard.

Come @ Sas3 cita nella loro risposta, RFC5280 fornisce un meccanismo per farlo, chiamato " CRL indiretti "(anche se sembra che sia più indicato per Y copiare Z 'd revocations, o per una CA delegare la gestione CRL a un" CRL signing server "fuori bordo piuttosto che questo scenario di avere radici in grado di bypassare i loro subordinati). Detto questo:

1. Affermare che questo è sicuro, è necessario avere la certezza che tutti i motori di convalida del CERT che consumano i certificati supportano i CRL indiretti.
2. Sono uno sviluppatore del software PKI che alimenta la CA affidata ad Entrust, nonché molte altre CA, e nonostante il nostro nome sia presente nell'elenco degli autori di tale RFC, per quanto ne so, anche il nostro software non supporta i CRL indiretti.
3. RFC 5280 è stato aggiornato da RFC 6818 , che non fa menzione di "CRL indiretto", quindi direi che mentre questo meccanismo è tecnicamente standardizzato, a nessuno importa davvero.

Breve storia: in un ambiente chiuso in cui hai il pieno controllo di tutte le CA e tutti i client che consumano cert, potresti probabilmente escogitare uno schema in cui Z può revocare X , ma in una PKI pubblica o qualsiasi ambiente utilizzando i motori TLS disponibili, questo non è certamente ampiamente supportato.

Se Z viene revocato, Y e X non vengono revocati, ma non possono più essere considerati attendibili, quindi possiamo dire che è stato revocato. Dato che Z non ha firmato X, non può revocarlo direttamente nel suo CRL. A proposito, nessuno guarderà a Z CRL se X viene revocato lì ma a X CRL. Quello che puoi teoricamente fare è unire sia i CRL X che quelli Z, ma il problema è con la firma. Chi firmerà tale CRL? Z o X? O entrambi? Dato che non è standard, direi che non può funzionare.

Se dai un'occhiata a wiki troverai quasi tutto ciò che riguarda i CRL lì.