1. Introduction (Introduzione)

1. Introduction (Introduzione)

Tradizionalmente, le chiavi pubbliche del client e del server TLS sono ottenute in contenitori PKIX in banda come parte della procedura di handshake TLS e sono convalidate utilizzando ancore di fiducia (trust anchors) basate su un'autorità di certificazione (CA) [PKIX]. Questo metodo può aggiungere una relazione di fiducia complicata che è difficile da convalidare. Esempi di tale complessità possono essere visti in [Defeating-SSL]. TLS è, tuttavia, comunemente usato anche con certificati autofirmati (self-signed certificates) in implementazioni più piccole in cui i certificati autofirmati sono distribuiti fuori banda a tutti gli endpoint del protocollo coinvolti. Questa pratica richiede tuttavia ancora il sovraccarico della generazione del certificato anche se nessuna delle informazioni trovate nel certificato viene effettivamente utilizzata.

Sono disponibili metodi alternativi che consentono a un client/server TLS di ottenere la chiave pubblica del server/client TLS:

• Il client TLS può ottenere la chiave pubblica del server TLS da un record di risorse protetto da DNSSEC utilizzando l'autenticazione basata su DNS delle entità denominate (DANE) [RFC6698].

• La chiave pubblica del client o del server TLS è ottenuta da una catena di certificati [PKIX] da un server Lightweight Directory Access Protocol [LDAP] o da una pagina web.

• La chiave pubblica del client e del server TLS viene fornita nell'immagine del firmware del sistema operativo e aggiornata tramite aggiornamenti software. Ad esempio:

  Alcuni oggetti intelligenti (smart objects) utilizzano il protocollo di applicazione vincolato basato su UDP [CoAP] per interagire con un server Web per caricare i dati del sensore a intervalli regolari, come le letture della temperatura. CoAP può utilizzare DTLS per proteggere la comunicazione client-server. Come parte del processo di produzione, il dispositivo integrato può essere configurato con l'indirizzo e la chiave pubblica di un server CoAP dedicato, nonché una coppia di chiavi pubblica/privata per il client stesso.

Questo documento introduce l'uso di chiavi pubbliche grezze (raw public keys) in TLS/DTLS. Con le chiavi pubbliche grezze, viene utilizzata solo una parte delle informazioni trovate nei certificati tipici: vale a dire, la struttura SubjectPublicKeyInfo di un certificato PKIX che trasporta i parametri necessari per descrivere la chiave pubblica. Altri parametri trovati nei certificati PKIX vengono omessi. Omettendo varie strutture relative ai certificati, la chiave pubblica grezza risultante viene mantenuta piuttosto piccola rispetto al certificato originale e il codice per elaborare le chiavi può essere più semplice. È necessario solo un parser ASN.1 minimalista; il codice per la convalida del percorso del certificato e altre elaborazioni relative a PKIX non è richiesto. Si noti, tuttavia, che la struttura SubjectPublicKeyInfo è ancora in un formato ASN.1. Per ridurre ulteriormente le dimensioni delle informazioni scambiate, questa specifica può essere combinata con l'estensione TLS Cached Info [CACHED-INFO], che consente ai peer TLS di scambiare solo le impronte digitali delle loro chiavi pubbliche.

Il meccanismo qui definito fornisce l'autenticazione solo quando viene utilizzato anche un meccanismo fuori banda per associare la chiave pubblica all'entità che presenta la chiave.

La Section 3 definisce la struttura delle due nuove estensioni TLS, client_certificate_type e server_certificate_type, che possono essere utilizzate come parte di un handshake TLS esteso quando devono essere utilizzate chiavi pubbliche grezze. La Section 4 definisce il comportamento del client TLS e del server TLS. Esempi di scambi sono descritti nella Section 5. La Section 6 descrive le considerazioni sulla sicurezza con questo approccio. Infine, nella Section 7 questo documento registra un nuovo valore nel registro secondario IANA "TLS Certificate Types" (Tipi di certificato TLS) per il supporto di chiavi pubbliche grezze.