5. Security Considerations (Considerazioni sulla sicurezza)

Affinché questo servizio sia efficace, i sistemi che utilizzano i certificati devono connettersi al fornitore del servizio di stato del certificato. Nel caso in cui tale connessione non possa essere ottenuta, i sistemi che utilizzano i certificati potrebbero implementare la logica di elaborazione delle CRL come posizione di ripiego.

Una vulnerabilità al denial of service (negazione del servizio) è evidente rispetto a un'inondazione di query. La produzione di una firma crittografica influisce significativamente sul tempo del ciclo di generazione della risposta, esacerbando così la situazione. Le risposte di errore non firmate aprono il protocollo a un altro attacco denial-of-service, in cui l'attaccante invia false risposte di errore.

L'uso di risposte precalcolate consente attacchi di replay (replay attacks) in cui una vecchia (buona) risposta viene riprodotta prima della sua data di scadenza ma dopo che il certificato è stato revocato. Le distribuzioni di OCSP dovrebbero valutare attentamente il beneficio delle risposte precalcolate rispetto alla probabilità di un attacco di replay e ai costi associati alla sua esecuzione con successo.

Le richieste non contengono il responder a cui sono dirigete. Ciò consente a un attaccante di riprodurre una richiesta a un numero qualsiasi di responder OCSP.

L'affidamento alla memorizzazione nella cache HTTP in alcuni scenari di distribuzione può comportare risultati imprevisti se i server intermedi sono configurati in modo errato o sono noti per possedere difetti di gestione della cache. Si consiglia agli implementatori di prendere in considerazione l'affidabilità dei meccanismi di cache HTTP durante la distribuzione di OCSP su HTTP.

Rispondere con uno stato "revoked" (revocato) a un certificato che non è mai stato emesso può consentire a qualcuno di ottenere una risposta di revoca per un certificato che non è ancora emesso, ma lo sarà presto, se il numero seriale del certificato che verrà emesso può essere previsto o indovinato dal richiedente. Tale previsione è facile per una CA che emette certificati utilizzando l'assegnazione sequenziale dei numeri seriali dei certificati. Questo rischio è gestito nella specifica richiedendo alle implementazioni conformi di utilizzare il codice motivo certificateHold, che evita di revocare permanentemente il numero seriale. Per le CA che supportano le risposte "revoked" alle richieste di stato per certificati non emessi, un modo per evitare completamente questo problema è assegnare valori casuali del numero seriale del certificato con elevata entropia.

5.1. Preferred Signature Algorithms (Algoritmi di firma preferiti)

Il meccanismo utilizzato per scegliere l'algoritmo di firma della risposta DEVE (MUST) essere considerato sufficientemente sicuro contro l'attacco crittoanalitico per l'applicazione prevista.

Nella maggior parte delle applicazioni, è sufficiente che l'algoritmo di firma sia almeno altrettanto sicuro dell'algoritmo di firma utilizzato per firmare il certificato originale il cui stato viene interrogato. Tuttavia, questo criterio potrebbe non valere nelle applicazioni di archiviazione a lungo termine, in cui lo stato di un certificato viene interrogato per una data nel lontano passato, molto tempo dopo che l'algoritmo di firma ha cessato di essere considerato affidabile.

5.1.1. Use of Insecure Algorithms (Uso di algoritmi non sicuri)

Non è sempre possibile per un responder generare una risposta che ci si aspetta che il client comprenda e che soddisfi gli standard contemporanei per la sicurezza crittografica. In tali casi, un operatore responder OCSP DEVE (MUST) bilanciare il rischio di impiegare una soluzione di sicurezza compromessa e il costo di imporre un aggiornamento, compreso il rischio che l'alternativa scelta dagli utenti finali offra ancora meno sicurezza o nessuna sicurezza.

Nelle applicazioni di archiviazione, è molto probabile che a un responder OCSP venga chiesto di segnalare la validità di un certificato in una data nel lontano passato. Tale certificato potrebbe impiegare un metodo di firma che non è più considerato accettabilmente sicuro. In tali circostanze, il responder NON DEVE (MUST NOT) generare una firma utilizzando un meccanismo di firma che non è considerato accettabilmente sicuro.

Un client DEVE (MUST) accettare qualsiasi algoritmo di firma in una risposta che ha specificato come algoritmo di firma preferito nella richiesta. Ne consegue, pertanto, che un client NON DEVE (MUST NOT) specificare come algoritmo di firma preferito alcun algoritmo che non è supportato o non è considerato accettabilmente sicuro.

5.1.2. Man-in-the-Middle Downgrade Attack (Attacco di downgrade Man-in-the-Middle)

Il meccanismo per supportare l'indicazione da parte del client degli algoritmi di firma preferiti non è protetto contro un attacco di downgrade man-in-the-middle. Questo vincolo non è considerato una preoccupazione di sicurezza significativa, poiché il responder OCSP NON DEVE (MUST NOT) firmare le risposte OCSP utilizzando algoritmi deboli anche se richiesto dal client. Inoltre, il client può rifiutare le risposte OCSP che non soddisfano i propri criteri per una sicurezza crittografica accettabile, indipendentemente dal meccanismo utilizzato per determinare l'algoritmo di firma della risposta.

5.1.3. Denial-of-Service Attack (Attacco Denial-of-Service)

I meccanismi di agilità dell'algoritmo definiti in questo documento introducono una superficie di attacco leggermente aumentata per gli attacchi denial-of-service in cui la richiesta del client viene alterata per richiedere algoritmi non supportati dal server. Le considerazioni sul denial-of-service come discusso nella RFC 4732 [RFC4732] sono rilevanti per questo documento.