3. Protocol Elements (Elementi di protocollo)

L'operazione DKIM coinvolge due ruoli: il Signer (firmatario) e il Verifier (verificatore). Il Signer crea il campo di intestazione DKIM-Signature per il messaggio quando lascia l'ADMD, e il Verifier lo verifica quando il messaggio arriva. Signer e Verifier possono essere un MTA, MSA o MUA, ma sono più probabilmente un modulo invocato da uno di questi.

3.1. Selectors (Selettori)

Per supportare più chiavi pubbliche simultanee sotto un singolo SDID e migliorare la comodità della gestione delle chiavi, DKIM utilizza un meccanismo "selector". Proprio come le etichette vengono utilizzate nei nomi di dominio DNS, il selector viene inserito nella stringa di query.

Ad esempio, supponiamo che l'amministratore di example.com installi due sistemi DKIM paralleli. Potrebbero scegliere di utilizzare "marketing.example.com" e "engineering.example.com" come nomi di dominio per i due sistemi. Tuttavia, tale schema presenta un serio problema operativo: richiede di stabilire e mantenere un'associazione tecnica tra i nomi di dominio dei due sistemi e i domini utilizzati sotto i loro nomi. Al contrario, uno schema più semplice è utilizzare un singolo nome di dominio "example.com" come fonte dell'identità rivendicata e distinguere le chiavi pubbliche dei due sistemi.

A questo scopo è stato introdotto il meccanismo selector. L'uso più semplice consiste nell'avere diversi record di chiavi, ciascuno utilizzando un selector diverso. Invece di avere due nomi di dominio diversi, utilizzare due selector diversi "nyc" e "sf" per distinguere i dipartimenti. In questo caso, i due record di chiavi verrebbero referenziati in "nyc._domainkey.example.com" e "sf._domainkey.example.com" rispettivamente.

Più selector consentono a un singolo dominio di detenere più chiavi DKIM, realizzando così più coppie di chiavi simultanee. Il Verifier non si preoccupa di quanti selector utilizza un determinato dominio; l'architettura DKIM garantisce che l'identificazione delle chiavi sia univoca. Esempi di modi in cui gli utenti possono utilizzare più selector includono: mantenere chiavi MSA e MTA separate, chiavi per utente, chiavi prima e dopo l'aggiornamento (sovrapposizione di chiavi) e supporto per firme di terze parti. In tutti i casi, il selector è una stringa casuale, non correlata all'operazione e quindi non può essere dedotta. I record di chiavi possono fornire commenti leggibili dall'uomo (tag n=) per scopi di gestione delle chiavi.

3.2. Tag=Value Lists (Liste Tag=Valore)

DKIM utilizza una semplice sintassi "tag=valore" per esprimere varie strutture, per fornire firme e record di chiavi. Ogni tag-spec consiste in un nome di tag seguito da "=" e un valore. Più tag-spec sono separati da punti e virgola. La sintassi dei nomi di tag e dei valori segue l'ABNF di [RFC2822], con una sintassi specifica definita nelle sezioni successive.

tag-list  =  tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
              ; Vieta WSP e FWS all'inizio e alla fine
tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
              ; EXCLAMATION a TILDE tranne SEMICOLON
ALNUMPUNC =  ALPHA / DIGIT / "_"

3.3. Signing and Verification Algorithms (Algoritmi di firma e verifica)

DKIM supporta più algoritmi di firma digitale. Sono supportate due classi di algoritmi: (1) algoritmi richiesti che devono essere supportati per garantire l'interoperabilità; (2) algoritmi opzionali che consentono di implementare nuovi algoritmi quando necessario.

Il Signer sceglie quale algoritmo utilizzare. Il Verifier deve essere in grado di verificare le firme utilizzando qualsiasi algoritmo richiesto.

L'algoritmo di firma è definito nel tag "a=" del campo di intestazione DKIM-Signature, con la seguente sintassi:

sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k     = "rsa" / x-sig-a-tag-k
sig-a-tag-h     = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)
                  ; per estensione futura
x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)
                  ; per estensione futura

"rsa-sha1" e "rsa-sha256" devono essere supportati e implementati. Le specifiche di altri algoritmi sono lasciate per definizione futura.

3.4. Canonicalization (Canonicalizzazione)

Alcuni sistemi di trasferimento della posta Internet modificano i messaggi, ad esempio riformattando le righe di intestazione o aggiungendo/rimuovendo spazi iniziali o finali. Tali modifiche possono causare il fallimento della verifica della firma.

Per risolvere questo problema, DKIM definisce due algoritmi di canonicalizzazione per normalizzare i messaggi: "simple" e "relaxed". "simple" consente poche o nessuna modifica; "relaxed" consente modifiche comuni come la riformattazione degli spazi. Il Signer può scegliere quale algoritmo utilizzare. I due algoritmi vengono applicati rispettivamente all'intestazione e al corpo.

L'algoritmo di canonicalizzazione è specificato nel tag "c=" del campo di intestazione DKIM-Signature, con la seguente sintassi:

sig-c-tag       = "simple" / "relaxed" /
                  (sig-c-tag-h "/" sig-c-tag-b)
sig-c-tag-h     = "simple" / "relaxed" / x-sig-c-tag
sig-c-tag-b     = "simple" / "relaxed" / x-sig-c-tag
x-sig-c-tag     = hyphenated-word  ; per estensione futura

3.4.1. Algoritmo di canonicalizzazione dell'intestazione simple

L'algoritmo di canonicalizzazione dell'intestazione "simple" non modifica i campi di intestazione in modo da influenzare la verifica.

3.4.2. Algoritmo di canonicalizzazione dell'intestazione relaxed

L'algoritmo di canonicalizzazione dell'intestazione "relaxed" deve applicare i seguenti passaggi in sequenza:

Convertire tutti i nomi dei campi di intestazione (incluso prima dei due punti) in minuscolo. Ad esempio, convertire "SUBJect: AbC" in "subject: AbC".
Rimuovere tutti i caratteri WSP dopo i due punti.
Convertire tutte le sequenze consecutive di caratteri WSP in un singolo carattere SP. I caratteri WSP sono i caratteri SP e HTAB, come definito nell'Appendice B.1 di [RFC5234].
Rimuovere tutti i WSP alla fine del valore del campo.
Rimuovere qualsiasi sequenza CRLF di fine riga, senza necessità di aggiungere al confine del corpo.

3.4.3. Algoritmo di canonicalizzazione del corpo simple

L'algoritmo di canonicalizzazione del corpo "simple":

Ignora tutte le righe vuote alla fine del corpo del messaggio. Una riga vuota è definita come una riga contenente solo CRLF; altri caratteri WSP non possono apparire da soli su una riga. Se il corpo è completamente vuoto, viene utilizzata una versione canonicalizzata di un singolo CRLF, in cui le righe vuote finali sono state rimosse.

3.4.4. Algoritmo di canonicalizzazione del corpo relaxed

L'algoritmo di canonicalizzazione del corpo "relaxed" deve applicare i seguenti passaggi:

Ridurre tutte le sequenze consecutive di caratteri WSP (incluso dopo CRLF) a un singolo SP.
Ignorare tutte le righe in cui i caratteri WSP appaiono alla fine della riga nel corpo del messaggio. Le implementazioni non devono rimuovere CRLF dopo l'ultimo carattere non WSP.
Ignorare tutte le righe vuote alla fine del corpo del messaggio.

3.4.5. Canonicalization Examples (Esempi di canonicalizzazione)

I seguenti esempi mostrano la canonicalizzazione dell'intestazione e del corpo. Qui "<SP>" rappresenta un carattere spazio, "<HTAB>" rappresenta una tabulazione orizzontale e "<CRLF>" rappresenta una coppia ritorno a capo/avanzamento riga.

Messaggio originale:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>
\<CRLF\>
\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Messaggio dopo canonicalizzazione simple:

Intestazione:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>

Corpo:

\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Messaggio dopo canonicalizzazione relaxed:

Intestazione:

a:\<SP\>X\<CRLF\>
b:\<SP\>Y\<SP\>Z\<CRLF\>

Corpo:

\<SP\>C\<CRLF\>
D\<CRLF\>