Passa al contenuto principale

5. URL dei certificati client

5.1. Elaborazione del messaggio Hello del client​

Per indicare il supporto di più tipi di certificati, i client POSSONO includere un'estensione di tipo "client_certificate_url" nel client hello (esteso). Il campo "extension_data" di questa estensione DEVE contenere "CertChainType", dove:

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

struct {
    CertChainType type;
} CertificateURL;

Se viene inviata l'estensione client_certificate_url, DEVE contenere un valore dall'elenco enumerato CertChainType. I client che inviano questa estensione DEVONO essere preparati a gestire messaggi CertificateURL contenenti sia il tipo individual_certs che pkipath.

L'estensione client_certificate_url può essere considerata come un'indicazione al server che il client si preparerà, se il server accetta, a inviare URL che puntano ai certificati nel suo messaggio Certificate invece dei certificati stessi. In questo modo, i server possono evitare di ricevere un grande messaggio Certificate dal client (ad esempio tramite un collegamento dial-up a banda stretta).

5.2. Elaborazione del messaggio Hello del server​

Un server che riceve un'estensione client_certificate_url nel client hello PUÒ scegliere di consentire al client di inviare URL di certificati invece di certificati includendo un'estensione di tipo "client_certificate_url" nel server hello (esteso). Se il server supporta più codifiche della catena di certificati per gli URL, può utilizzare il CertChainType nell'estensione client_certificate_url per determinare quale dei tipi è preferito dal client. Il campo "extension_data" di questa estensione DEVE essere vuoto.

I client che ricevono un'estensione client_certificate_url nel server hello indicante che il server è pronto ad accettare URL di certificati POSSONO scegliere di inviare URL di certificati come descritto nella Sezione 5.3 invece di inviare certificati.

5.3. Messaggio Certificate del client​

Normalmente, se viene richiesta l'autenticazione del client basata su certificati dal server, il client DEVE inviare il messaggio Certificate contenente la sua catena di certificati. Tuttavia, se il server ha accettato l'estensione client_certificate_url, il client PUÒ invece inviare il messaggio CertificateURL (esteso), dove:

enum {
    X509(0), OpenPGP(1), (255)
} CertificateType;

struct {
    CertificateType cert_type;
    uint16 url_and_hash_len;
    URLAndOptionalHash url_and_hash_list[1..2^16-1];
} CertificateURL;

struct {
    opaque url<1..2^16-1>;
    unint1 padding;
    opaque SHA1Hash[20];
} URLAndOptionalHash;

unint1 URLAndOptionalHash.padding = 0;

Qui, "url_and_hash_list" contiene una sequenza di URL (e hash opzionali) in ordine crescente di preferenza. Ciascuno di questi URL dovrebbe puntare a un singolo certificato o a una sequenza di certificati contenente la catena di certificati del client. I server DEVONO essere preparati a gestire URL HTTP [RFC2616] che puntano a URL HTTP non validi, e POSSONO supportare altri schemi come FTP [RFC0959] e HTTPS [RFC2818] (che possono essere utilizzati per identificare e autenticare i server che ospitano gli URL dei certificati). Gli URL NON DEVONO specificare una porta diversa dalla porta predefinita per lo schema dell'URL. Il CertificateType DEVE essere X509. Se sono presenti altri valori di CertificateType, questi POSSONO essere ignorati dal server.

Quando vengono utilizzati gli URL, esistono due modi in cui la catena di certificati può essere strutturata. Il tipo individual_certs indica che ogni URL di certificato punta a un singolo certificato in formato DER [X690]. Il tipo pkipath indica che la sequenza di URL punterà a una sequenza di certificati, nell'ordine descritto da PkiPath [RFC4366] e [RFC3280]. Tale sequenza può essere prodotta codificando la sequenza pkiPath [RFC3280], Sezione 10.1, utilizzando le convenzioni di codifica DER [X690].

Il server deve decidere se accetterà di utilizzare gli URL o se richiederà al client di inviare il normale messaggio Certificate contenente i certificati. Se il server accetta gli URL, l'elaborazione del server dipende dal tipo di catena di certificati che riceve.

Se il server ha ricevuto un elenco di tipo individual_certs, DOVREBBE tentare gli URL nell'ordine in cui sono stati ricevuti fino a quando non ottiene con successo i certificati richiesti. Se un URL non può essere memorizzato in cache in una posizione accessibile al server (ad esempio, perché il protocollo di recupero non consente la memorizzazione nella cache), il server dovrebbe tentare l'URL successivo nell'elenco; la decisione di riprovare con l'URL originale dopo un ritardo dovrebbe dipendere dal protocollo utilizzato per recuperare l'URL e dal codice di risposta ricevuto.

Se il server ha ricevuto un elenco di tipo pkipath, DOVREBBE tentare gli URL in ordine fino a quando non ottiene con successo un set completo di certificati. Le considerazioni sulla memorizzazione nella cache sono le stesse dell'elaborazione individual_certs. È possibile che un server riceva più URL pkipath in cui un sottoinsieme dei certificati è lo stesso tra diversi PkiPath. In questo caso, il server PUÒ utilizzare i certificati che ha già memorizzato nella cache durante l'elaborazione di un URL pkipath successivo.

Uno degli elementi in url_and_hash_list PUÒ avere un hash associato (vedere la discussione nella Sezione 5.4 per i dettagli). I server che ricevono un messaggio CertificateURL contenente almeno un hash DEVONO verificare che l'hash del certificato recuperato (o del set di certificati per pkipath) corrisponda all'hash fornito. Se il certificato (o il set di certificati) non corrisponde all'hash fornito, il server DEVE abortire la connessione con un avviso bad_certificate_hash_value(114).

5.4. Informazioni sull'hash del certificato​

L'URL del certificato può anche contenere un hash SHA-1 [SHA] dei dati codificati DER che corrispondono all'URL. Ciò consente al server di abbinare un certificato che ha già memorizzato nella cache con gli URL nel messaggio. Se il server ha memorizzato nella cache il/i certificato/i corrispondente/i, non è necessario recuperare il certificato dall'URL. Quando il padding ha valore zero, l'hash è presente; se il padding ha un valore diverso da zero, non è presente alcun hash e il resto di URLAndOptionalHash dopo l'URL è assente.

Quando l'hash è presente per il tipo individual_certs, l'hash viene calcolato sui dati codificati DER che corrispondono all'URL (cioè, il singolo certificato recuperato dall'URL). Quando l'hash è presente per il tipo pkipath, l'hash viene calcolato sulla sequenza completa codificata pkiPath; cioè, l'hash copre l'intera sequenza di byte di dati codificati DER per la sequenza di certificati.

L'URL e l'hash, se presente, consentono al server di identificare facilmente un certificato memorizzato nella cache anche quando la catena è di tipo individual_certs. Si noti che il recupero del certificato potrebbe fallire sia perché il server non può accedere all'URL sia perché il certificato è stato spostato da quando il client lo ha visto l'ultima volta. In quest'ultimo caso, potrebbe essere necessario che il client ricarichi il certificato e rifaccia l'handshake per fornire al server un hash del certificato aggiornato.

5.5. Elaborazione lato server del messaggio CertificateURL​

Quando il server riceve un messaggio CertificateURL, DEVE validare che il messaggio sia correttamente formato in conformità alla specifica nella Sezione 5.3. In particolare:

  • Ogni URL DEVE avere uno schema di recupero supportato.
  • Gli URL NON DEVONO specificare una porta diversa dalla porta predefinita per lo schema.
  • Il CertificateType DEVE essere un valore che il server comprende. I server DEVONO comprendere il tipo X509.

Se il server determina che il messaggio CertificateURL è malformato, DEVE abortire la connessione con un avviso decode_error.

Il server PUÒ tentare di recuperare i certificati referenziati nel messaggio CertificateURL. Se questo recupero fallisce per tutti gli URL contenuti nel messaggio, il server PUÒ abortire la connessione con un avviso certificate_unobtainable(111).

Il server DEVE eseguire le verifiche del certificato descritte in [RFC5246], utilizzando il/i certificato/i recuperato/i. Se le verifiche falliscono, il server DEVE abortire la connessione con un avviso appropriato come definito in [RFC5246].

Se il server seleziona un certificato memorizzato nella cache sulla base di un hash del certificato, e il contenuto di tale certificato differisce dal certificato che sarebbe stato recuperato da un URL, il server DEVE considerare questo scenario come un attacco e PUÒ abortire la connessione con un avviso bad_certificate_hash_value(114).

Ultimo aggiornamento il