2. Il record di risorsa TLSA (The TLSA Resource Record)

Il record di risorsa DNS TLSA (RR) viene utilizzato per associare un certificato del server TLS o una chiave pubblica con il nome di dominio in cui viene trovato il record, formando così un'"associazione di certificato TLSA". La semantica di come viene interpretato il RR TLSA è fornita più avanti in questo documento.

Il valore del tipo per il tipo RR TLSA è definito nella sezione 7.1.

Il RR TLSA è indipendente dalla classe.

Il RR TLSA non ha requisiti speciali di Time to Live (TTL).

2.1. Formato wire RDATA TLSA (TLSA RDATA Wire Format)

L'RDATA per un RR TLSA è composto da un campo di utilizzo del certificato di un ottetto, un campo selettore di un ottetto, un campo di tipo di corrispondenza di un ottetto e il campo dati di associazione del certificato.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Uso Cert.    |   Selettore   | Tipo Corrisp. |               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 Dati associazione certificato                 /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. Il campo di utilizzo del certificato (The Certificate Usage Field)

Un valore di un ottetto, chiamato "utilizzo del certificato", specifica l'associazione fornita che verrà utilizzata per corrispondere al certificato presentato nell'handshake TLS. Questo valore è definito in un nuovo registro IANA (vedere sezione 7.2) per facilitare l'aggiunta di ulteriori utilizzi dei certificati in futuro. Gli utilizzi dei certificati definiti in questo documento sono:

0 -- Vincolo CA: L'utilizzo del certificato 0 viene utilizzato per specificare un certificato CA, o la chiave pubblica di tale certificato, che DEVE essere trovato in uno qualsiasi dei percorsi di certificazione PKIX per il certificato dell'entità finale fornito dal server in TLS. Questo utilizzo del certificato è talvolta chiamato "vincolo CA" perché limita quale CA può essere utilizzata per emettere certificati per un determinato servizio su un host. Il certificato presentato DEVE superare la convalida del percorso di certificazione PKIX e un certificato CA che corrisponde al record TLSA DEVE essere incluso come parte di un percorso di certificazione valido. Poiché questo utilizzo del certificato consente sia ancoraggi di fiducia che certificati CA, il certificato potrebbe avere o meno l'estensione basicConstraints presente.

1 -- Vincolo del certificato di servizio: L'utilizzo del certificato 1 viene utilizzato per specificare un certificato dell'entità finale, o la chiave pubblica di tale certificato, che DEVE corrispondere al certificato dell'entità finale fornito dal server in TLS. Questo utilizzo del certificato è talvolta chiamato "vincolo del certificato di servizio" perché limita quale certificato dell'entità finale può essere utilizzato da un determinato servizio su un host. Il certificato di destinazione DEVE superare la convalida del percorso di certificazione PKIX e DEVE corrispondere al record TLSA.

2 -- Asserzione di ancoraggio di fiducia: L'utilizzo del certificato 2 viene utilizzato per specificare un certificato, o la chiave pubblica di tale certificato, che DEVE essere utilizzato come ancoraggio di fiducia durante la convalida del certificato dell'entità finale fornito dal server in TLS. Questo utilizzo del certificato è talvolta chiamato "asserzione di ancoraggio di fiducia" e consente a un amministratore di nome di dominio di specificare un nuovo ancoraggio di fiducia -- ad esempio, se il dominio emette i propri certificati sotto la propria CA che non si prevede sia nella raccolta di ancoraggi di fiducia degli utenti finali. Il certificato di destinazione DEVE superare la convalida del percorso di certificazione PKIX, con qualsiasi certificato corrispondente al record TLSA considerato un ancoraggio di fiducia per questa convalida del percorso di certificazione.

3 -- Certificato emesso dal dominio: L'utilizzo del certificato 3 viene utilizzato per specificare un certificato, o la chiave pubblica di tale certificato, che DEVE corrispondere al certificato dell'entità finale fornito dal server in TLS. Questo utilizzo del certificato è talvolta chiamato "certificato emesso dal dominio" perché consente a un amministratore di nome di dominio di emettere certificati per un dominio senza coinvolgere una CA di terze parti. Il certificato di destinazione DEVE corrispondere al record TLSA. La differenza tra l'utilizzo del certificato 1 e l'utilizzo del certificato 3 è che l'utilizzo del certificato 1 richiede che il certificato superi la convalida PKIX, ma la convalida PKIX non viene testata per l'utilizzo del certificato 3.

Gli utilizzi dei certificati definiti in questo documento si applicano esplicitamente solo ai certificati in formato PKIX con codifica DER [X.690]. Se TLS consente altri formati in seguito, o se vengono apportate estensioni a questo RRtype che accettano altri formati per i certificati, tali certificati avranno bisogno dei propri valori di utilizzo del certificato.

2.1.2. Il campo selettore (The Selector Field)

Un valore di un ottetto, chiamato "selettore", specifica quale parte del certificato TLS presentato dal server verrà confrontata con i dati di associazione. Questo valore è definito in un nuovo registro IANA (vedere sezione 7.3). I selettori definiti in questo documento sono:

0 -- Certificato completo: la struttura binaria del certificato come definita in [RFC5280]

1 -- SubjectPublicKeyInfo: struttura binaria codificata DER come definita in [RFC5280]

(Si noti che l'uso di "selettore" in questo documento è completamente indipendente dall'uso di "selettore" in DomainKeys Identified Mail (DKIM) [RFC6376].)

2.1.3. Il campo del tipo di corrispondenza (The Matching Type Field)

Un valore di un ottetto, chiamato "tipo di corrispondenza", specifica come viene presentata l'associazione del certificato. Questo valore è definito in un nuovo registro IANA (vedere sezione 7.4). I tipi definiti in questo documento sono:

0 -- Corrispondenza esatta sul contenuto selezionato

1 -- Hash SHA-256 del contenuto selezionato [RFC6234]

2 -- Hash SHA-512 del contenuto selezionato [RFC6234]

Se il tipo di corrispondenza del record TLSA è un hash, avere il record che utilizza lo stesso algoritmo di hash utilizzato nella firma nel certificato (se possibile) aiuterà i client che supportano un numero limitato di algoritmi di hash.

2.1.4. Il campo dati di associazione del certificato (The Certificate Association Data Field)

Questo campo specifica i "dati di associazione del certificato" da confrontare. Questi byte sono dati grezzi (cioè, il certificato completo o il suo SubjectPublicKeyInfo, a seconda del selettore) per il tipo di corrispondenza 0, o l'hash dei dati grezzi per i tipi di corrispondenza 1 e 2. I dati si riferiscono al certificato nell'associazione, non all'oggetto certificato ASN.1 TLS.

2.2. Formato di presentazione RR TLSA (TLSA RR Presentation Format)

Il formato di presentazione della porzione RDATA (come definito in [RFC1035]) è il seguente:

• Il campo di utilizzo del certificato DEVE essere rappresentato come un intero senza segno a 8 bit.
• Il campo selettore DEVE essere rappresentato come un intero senza segno a 8 bit.
• Il campo del tipo di corrispondenza DEVE essere rappresentato come un intero senza segno a 8 bit.
• Il campo dati di associazione del certificato DEVE essere rappresentato come una stringa di caratteri esadecimali. Gli spazi bianchi sono consentiti all'interno della stringa di caratteri esadecimali, come descritto in [RFC1035].

2.3. Esempi di RR TLSA (TLSA RR Examples)

Nei seguenti esempi, il nome di dominio è formato utilizzando le regole nella sezione 3.

Un esempio di associazione hash (SHA-256) di un certificato CA PKIX:

_443._tcp.www.example.com. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

Un esempio di associazione di chiave pubblica soggetto hash (SHA-512) di un certificato entità finale PKIX:

_443._tcp.www.example.com. IN TLSA (
   1 1 2 92003ba34942dc74152e2f2c408d29ec
         a5a520e7f2e06bb944f4dca346baf63c
         1b177615d466f6c4b71c216a50292bd5
         8c9ebdd2f74e38fe51ffd48c43326cbc )

Un esempio di associazione di certificato completo di un certificato entità finale PKIX:

_443._tcp.www.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )