1. Introduction (Introduzione)
Il framework delle estensioni Transport Layer Security (TLS) (Sicurezza del Livello di Trasporto) [RFC6066] definisce, tra le altre estensioni, l'estensione Certificate Status (Stato del Certificato) (nota anche come "OCSP stapling") che i client possono utilizzare per richiedere la copia del server dello stato corrente del suo certificato. I vantaggi di questa estensione includono un numero ridotto di roundtrip e ritardi di rete per il client per verificare lo stato del certificato del server e un carico ridotto sui server di risposta dello stato dell'emittente del certificato, risolvendo così un problema che può diventare significativo quando il certificato emesso è presentato da un server visitato frequentemente.
Ci sono due problemi con l'estensione Certificate Status esistente. In primo luogo, non fornisce funzionalità per richiedere informazioni sullo stato dei certificati delle Certification Authority (Autorità di Certificazione, CA) intermedie, il che significa che il client deve richiedere informazioni sullo stato attraverso altri metodi, come le Certificate Revocation Lists (Liste di Revoca dei Certificati, CRL), introducendo ulteriori ritardi. In secondo luogo, il formato corrente dell'estensione e i requisiti nel protocollo TLS impediscono a un client di offrire al server metodi di stato multipli.
Molte CA stanno ora emettendo certificati CA intermedi che non solo specificano il punto di pubblicazione per le loro CRL in un CRL Distribution Point (Punto di Distribuzione CRL) [RFC5280], ma specificano anche un URL per il loro server OCSP [RFC6960] nell'Authority Information Access (Accesso alle Informazioni dell'Autorità) [RFC5280]. Dato che le CRL memorizzate nella cache del client sono spesso obsolete, i client trarrebbero vantaggio dall'utilizzo di OCSP per accedere a informazioni sullo stato aggiornate sui certificati CA intermedi. Il vantaggio per la CA emittente è meno chiaro, poiché fornire la larghezza di banda per il responder OCSP può essere costoso, specialmente per le CA con molti siti abbonati ad alto traffico, e questo costo è una preoccupazione per molte CA. Ci sono casi in cui le richieste OCSP per un singolo sito ad alto traffico hanno causato problemi di rete significativi per la CA emittente.
I client trarranno vantaggio dal fatto che il server TLS fornisca informazioni sullo stato del certificato indipendentemente dal tipo, non solo per il certificato del server ma anche per i certificati CA intermedi. Combinare i controlli di stato in un'unica estensione ridurrà i roundtrip necessari per completare l'handshake da parte del client solo a quelli necessari per negoziare la connessione TLS. Inoltre, per le Certification Authority, il carico sui loro server dipenderà dal numero di certificati che hanno emesso, non dal numero di visitatori a quei siti. Inoltre, l'utilizzo di questa estensione riduce significativamente le preoccupazioni sulla privacy riguardo ai client che informano l'emittente del certificato sui siti che stanno visitando.
Affinché un tale nuovo sistema venga introdotto in modo trasparente, i client devono essere in grado di indicare il supporto per il metodo OCSP Certificate Status esistente e una nuova modalità multiple-OCSP (OCSP multiplo).
Sfortunatamente, la definizione dell'estensione Certificate Status consente solo che una singola estensione Certificate Status venga definita in un singolo record di estensione nell'handshake, e il protocollo TLS [RFC5246] consente solo un singolo record nell'elenco delle estensioni per qualsiasi estensione data. Ciò significa che non è possibile per i client indicare il supporto per nuovi metodi pur continuando a supportare metodi più vecchi, il che causerebbe problemi di interoperabilità tra client più recenti e server più vecchi. Questo non sarà solo un problema per la modalità di richiesta di stato multiplo proposta sopra, ma anche per qualsiasi altro metodo di stato futuro che potrebbe essere introdotto. Questo sarà vero non solo per l'attuale infrastruttura PKIX [RFC5280] ma anche per strutture PKI alternative.
La soluzione a questo problema è definire una nuova estensione, "status_request_v2", con un formato esteso che consenta al client di indicare il supporto per metodi di richiesta di stato multipli. Questo è implementato utilizzando un elenco di record CertificateStatusRequestItemV2 nel record di estensione. Poiché il server selezionerà il singolo metodo di stato in base alla cipher suite selezionata e al certificato presentato, non sono necessarie modifiche significative nel formato dell'estensione del server.