5. Casi d'uso e requisiti TLSA e DANE (TLSA and DANE Use Cases and Requirements)

I diversi tipi di associazioni di certificati definiti in TLSA sono abbinati a varie sezioni di [RFC6394]. I casi d'uso dalla sezione 3 di [RFC6394] sono coperti in questo documento come segue:

3.1 Vincoli CA -- Implementato utilizzando l'utilizzo del certificato 0.
3.2 Vincoli del certificato -- Implementato utilizzando l'utilizzo del certificato 1.
3.3 Asserzione di ancoraggio di fiducia e certificati emessi dal dominio -- Implementati utilizzando rispettivamente gli utilizzi dei certificati 2 e 3.

I requisiti dalla sezione 4 di [RFC6394] sono coperti in questo documento come segue:

Porte multiple (Multiple Ports) -- I record TLSA per diversi servizi applicativi in esecuzione su un singolo host possono essere distinti attraverso il nome del servizio e il numero di porta prefissati al nome host (vedere sezione 3).

Nessun downgrade (No Downgrade) -- La sezione 4 specifica le condizioni in cui un client può elaborare e agire sui record TLSA. In particolare, se lo stato DNSSEC per il set di record di risorsa TLSA è determinato come falso, la connessione TLS (se avviata) fallirà.

Incapsulamento (Encapsulation) -- L'incapsulamento è coperto nella semantica di risposta TLSA.

Prevedibilità (Predictability) -- Le appendici di questa specifica forniscono considerazioni operative e guida all'implementazione per consentire agli sviluppatori di applicazioni di formare un'interpretazione coerente del comportamento client raccomandato.

Sicurezza opportunistica (Opportunistic Security) -- Se un client conforme a questa specifica può determinare in modo affidabile la presenza di un record TLSA, tenterà di utilizzare queste informazioni. Al contrario, se un client può determinare in modo affidabile l'assenza di qualsiasi record TLSA, tornerà all'elaborazione di TLS nel modo normale. Questo è discusso nella sezione 4.

Combinazione -- Più record TLSA possono essere pubblicati per un dato nome host, consentendo così al client di costruire più associazioni di certificati TLSA che riflettono diverse asserzioni. Non è fornito alcun supporto per combinare due associazioni di certificati TLSA in una singola operazione.

Rotazione (Roll-over) -- I record TLSA sono elaborati nel modo normale nell'ambito del protocollo DNS, compresa la scadenza del TTL dei record. Ciò garantisce che i client non si aggancino alle asserzioni fatte da record TLSA scaduti e saranno in grado di passare dall'uso di una chiave pubblica o utilizzo del certificato a un altro.

Gestione semplice delle chiavi (Simple Key Management) -- Il selettore SubjectPublicKeyInfo nel record TLSA fornisce una modalità che consente a un detentore di dominio di dover mantenere solo una singola coppia di chiavi pubblica/privata di lunga durata senza la necessità di gestire certificati. L'appendice A delinea l'utilità e i potenziali svantaggi dell'uso di questa modalità.

Dipendenze minime (Minimal Dependencies) -- Questa specifica si basa su DNSSEC per proteggere l'autenticità dell'origine e l'integrità del set di record di risorsa TLSA. Inoltre, se la convalida DNSSEC non viene eseguita sul sistema che desidera utilizzare le associazioni di certificati TLSA, questa specifica richiede che l'"ultimo miglio" sia su un trasporto sicuro. Non ci sono altre dipendenze di distribuzione per questo approccio.

Opzioni minime (Minimal Options) -- Le modalità operative corrispondono precisamente ai casi d'uso e ai requisiti DANE. L'uso di DNSSEC è obbligatorio in quanto questa specifica incoraggia le applicazioni a utilizzare solo quei record TLSA che sono stati validati.

Caratteri jolly (Wildcards) -- I caratteri jolly sono coperti in modo limitato nella sintassi della richiesta TLSA; vedere l'appendice A.

Reindirizzamento (Redirection) -- Il reindirizzamento è coperto nella sintassi della richiesta TLSA; vedere l'appendice A.