6.5 Certificate Revocation (Revoca dei certificati)

6.5 Certificate Revocation (Revoca dei certificati)

Le seguenti considerazioni e raccomandazioni rappresentano lo stato dell'arte attuale riguardo alla revoca dei certificati, anche se non esiste una soluzione completa ed efficiente per il problema della verifica dello stato di revoca dei certificati a chiave pubblica comuni [RFC5280]:

• Sebbene le Certificate Revocation List (CRL) siano il meccanismo più ampiamente supportato per distribuire informazioni di revoca, hanno problemi di scalabilità noti che limitano la loro utilità (nonostante soluzioni alternative come le CRL partizionate e le CRL delta).

• I meccanismi proprietari che incorporano le liste di revoca nel database di configurazione del browser Web non possono scalare oltre un piccolo numero dei server Web più utilizzati.

• Il protocollo On-Line Certification Status Protocol (OCSP) [RFC6960] presenta problemi sia di scalabilità che di privacy. Inoltre, i client tipicamente effettuano un "soft-fail", il che significa che non interrompono la connessione TLS se il server OCSP non risponde. (Tuttavia, questo potrebbe essere una soluzione alternativa per evitare attacchi denial-of-service se un risponditore OCSP viene messo offline.)

• L'estensione TLS Certificate Status Request (Sezione 8 di [RFC6066]), comunemente chiamata "OCSP stapling", risolve i problemi operativi con OCSP. Tuttavia, è ancora inefficace in presenza di un attaccante MITM perché l'attaccante può semplicemente ignorare la richiesta del client per una risposta OCSP stapled.

• L'OCSP stapling come definito in [RFC6066] non si estende ai certificati intermedi utilizzati in una catena di certificati. Sebbene l'estensione Multiple Certificate Status [RFC6961] affronti questa carenza, è un'aggiunta recente senza molta distribuzione.

• Sia le CRL che l'OCSP dipendono da una connettività relativamente affidabile a Internet, che potrebbe non essere disponibile per certi tipi di nodi (come dispositivi appena provisionati che devono stabilire una connessione sicura per avviarsi per la prima volta).

Per quanto riguarda i certificati a chiave pubblica comuni, i server DOVREBBERO supportare quanto segue come best practice dato lo stato attuale dell'arte e come base per una possibile soluzione futura:

1. OCSP [RFC6960]

2. Sia l'estensione status_request definita in [RFC6066] che l'estensione status_request_v2 definita in [RFC6961] (Questo potrebbe consentire l'interoperabilità con la più ampia gamma di client.)

3. L'estensione OCSP stapling definita in [RFC6961]

Le considerazioni in questa sezione non si applicano agli scenari in cui il record di risorsa DANE-TLSA [RFC6698] viene utilizzato per segnalare a un client quale certificato un server considera valido e idoneo per l'uso con connessioni TLS.