5. Signer Actions (Azioni del firmatario)

I seguenti passaggi vengono eseguiti in ordine dai Signer.

5.1. Determine Whether the Email Should Be Signed and by Whom (Determinare se l'e-mail deve essere firmata e da chi)

Un Signer può ovviamente firmare solo e-mail per domini per i quali possiede una chiave privata e le necessarie conoscenze della chiave pubblica corrispondente e delle informazioni del selettore. Tuttavia, ci sono una serie di altri motivi oltre alla mancanza di una chiave privata per cui un Signer potrebbe scegliere di non firmare un'e-mail.

NOTA INFORMATIVA: Un Signer può essere implementato come parte di qualsiasi porzione del sistema di posta ritenuta appropriata, inclusi un MUA, un server SUBMISSION o un MTA. Ovunque sia implementato, i Signer devono fare attenzione a firmare (e quindi ad assumersi la responsabilità di) messaggi che potrebbero essere problematici. In particolare, all'interno di un'enclave fidata, il dominio di firma potrebbe essere derivato dall'intestazione secondo la policy locale; i server SUBMISSION potrebbero firmare solo messaggi da utenti correttamente autenticati e autorizzati.

CONSIGLIO INFORMATIVO AGLI IMPLEMENTATORI: I server SUBMISSION non dovrebbero firmare i campi di intestazione Received se il gateway MTA in uscita offusca i campi di intestazione Received, ad esempio per nascondere i dettagli della topologia interna.

Se un'e-mail non può essere firmata per qualche motivo, è una decisione di policy locale decidere cosa fare con quell'e-mail.

5.2. Select a Private Key and Corresponding Selector Information (Selezionare una chiave privata e le informazioni del selettore corrispondenti)

Questa specifica non definisce la base su cui un Signer dovrebbe scegliere quale chiave privata e quali informazioni del selettore utilizzare. Attualmente, tutti i selettori sono uguali per quanto riguarda questa specifica, quindi la decisione dovrebbe essere principalmente una questione di convenienza amministrativa. La distribuzione e la gestione delle chiavi private sono anche al di fuori dell'ambito di questo documento.

CONSIGLIO INFORMATIVO SULLE OPERAZIONI: Un Signer non dovrebbe firmare con una chiave privata quando il selettore contenente la chiave pubblica corrispondente è previsto essere revocato o rimosso prima che il Verifier abbia l'opportunità di validare la firma. Il Signer dovrebbe anticipare che i Verifier possono scegliere di differire la validazione, forse fino a quando il messaggio non viene effettivamente letto dal destinatario finale. In particolare, quando si ruota verso una nuova coppia di chiavi, la firma dovrebbe iniziare immediatamente con la nuova chiave privata, e la vecchia chiave pubblica dovrebbe essere mantenuta per un ragionevole intervallo di validazione prima di essere rimossa dal server delle chiavi.

5.3. Normalize the Message to Prevent Transport Conversions (Normalizzare il messaggio per prevenire conversioni di trasporto)

Alcuni messaggi, in particolare quelli che utilizzano caratteri a 8 bit, sono soggetti a modifiche durante il transito, in particolare alla conversione in forma a 7 bit. Tali conversioni romperanno le firme DKIM. Al fine di minimizzare le possibilità di tale rottura, i Signer DOVREBBERO convertire il messaggio in una codifica di trasferimento del contenuto MIME appropriata come quoted-printable o base64 come descritto in [RFC2045] prima di firmare. Tale conversione è al di fuori dell'ambito di DKIM; il messaggio effettivo DOVREBBE essere convertito in MIME a 7 bit da un MUA o MSA prima della presentazione all'algoritmo DKIM.

Se il messaggio viene inviato al Signer con qualsiasi codifica locale che verrà modificata prima della trasmissione, tale modifica alla forma canonica [RFC5322] DEVE essere effettuata prima della firma. In particolare, i caratteri CR o LF nudi (utilizzati da alcuni sistemi come convenzione di separatore di riga locale) DEVONO essere convertiti nella sequenza CRLF standard SMTP prima che il messaggio venga firmato. Qualsiasi conversione di questo tipo DOVREBBE essere applicata al messaggio effettivamente inviato ai destinatari, non solo alla versione presentata all'algoritmo di firma.

Più in generale, il Signer DEVE firmare il messaggio come è previsto che venga ricevuto dal Verifier piuttosto che in qualche forma locale o interna.

5.3.1. Body Length Limits (Limiti di lunghezza del corpo)

Un conteggio della lunghezza del corpo PUÒ essere specificato per limitare il calcolo della firma a un prefisso iniziale del testo del corpo, misurato in ottetti. Se il conteggio della lunghezza del corpo non è specificato, viene firmato l'intero corpo del messaggio.

RAZIONALE INFORMATIVO: Questa capacità è fornita perché è molto comune per le mailing list aggiungere trailer ai messaggi (ad es., istruzioni su come uscire dalla lista). Fino a quando anche questi messaggi vengono firmati, il conteggio della lunghezza del corpo è uno strumento utile per il Verifier poiché può, come questione di policy, accettare messaggi con firme valide con dati estranei.

La lunghezza effettivamente sottoposta a hash dovrebbe essere inserita nel tag "l=" del campo di intestazione DKIM-Signature. (Vedi Sezione 3.5.)

Il conteggio della lunghezza del corpo consente al Signer di un messaggio di permettere che i dati vengano aggiunti alla fine del corpo di un messaggio firmato. Il conteggio della lunghezza del corpo DEVE essere calcolato seguendo l'algoritmo di canonicalizzazione; ad esempio, qualsiasi spazio bianco ignorato da un algoritmo di canonicalizzazione non è incluso come parte del conteggio della lunghezza del corpo.

Un conteggio della lunghezza del corpo pari a zero significa che il corpo è completamente non firmato.

I Signer che desiderano garantire che non possa verificarsi alcuna modifica di alcun tipo dovrebbero specificare l'algoritmo di canonicalizzazione "simple" sia per l'intestazione che per il corpo e omettere il conteggio della lunghezza del corpo.

Vedi Sezione 8.2 per ulteriori discussioni.

5.4. Determine the Header Fields to Sign (Determinare i campi di intestazione da firmare)

Il campo di intestazione From DEVE essere firmato (cioè, incluso nel tag "h=" del campo di intestazione DKIM-Signature risultante). I Signer NON DOVREBBERO firmare un campo di intestazione esistente che è probabile venga legittimamente modificato o rimosso in transito. In particolare, [RFC5321] permette esplicitamente la modifica o la rimozione del campo di intestazione Return-Path in transito. I Signer POSSONO includere qualsiasi altro campo di intestazione presente al momento della firma a discrezione del Signer.

NOTA INFORMATIVA SULLE OPERAZIONI: La scelta di quali campi di intestazione firmare non è ovvia. Una strategia consiste nel firmare tutti i campi di intestazione esistenti non ripetibili. Una strategia alternativa consiste nel firmare solo i campi di intestazione che sono probabilmente visualizzati o che probabilmente influenzano l'elaborazione del messaggio al ricevitore. Una terza strategia consiste nel firmare solo intestazioni "ben note". Si noti che i Verifier potrebbero trattare i campi di intestazione non firmati con estremo scetticismo, incluso il rifiuto di visualizzarli all'utente finale o persino ignorare la firma se non copre determinati campi di intestazione. Per questo motivo, è altamente consigliato firmare i campi presenti nel messaggio come Date, Subject, Reply-To, Sender e tutti i campi di intestazione MIME.

Il campo di intestazione DKIM-Signature è sempre implicitamente firmato e NON DEVE essere incluso nel tag "h=" tranne per indicare che anche altre firme preesistenti sono firmate.

I Signer POSSONO dichiarare di aver firmato campi di intestazione che non esistono (cioè, i Signer POSSONO includere il nome del campo di intestazione nel tag "h=" anche se quel campo di intestazione non esiste nel messaggio). Quando si calcola la firma, il campo di intestazione inesistente DEVE essere trattato come la stringa nulla (inclusi il nome del campo di intestazione, il valore del campo di intestazione, tutta la punteggiatura e il CRLF finale).

RAZIONALE INFORMATIVO: Questo consente ai Signer di affermare esplicitamente l'assenza di un campo di intestazione; se quel campo di intestazione viene aggiunto successivamente, la firma fallirà.

NOTA INFORMATIVA: Un nome di campo di intestazione deve essere elencato solo una volta in più rispetto al numero effettivo di quel campo di intestazione in un messaggio al momento della firma per impedire ulteriori aggiunte. Ad esempio, se c'è un singolo campo di intestazione Comments al momento della firma, elencare Comments due volte nel tag "h=" è sufficiente per impedire l'aggiunta di un numero qualsiasi di campi di intestazione Comments; non è necessario (ma è legale) elencare Comments tre o più volte nel tag "h=".

Fare riferimento alla Sezione 5.4.2 per una discussione della procedura da seguire quando si canonicalizza un'intestazione con più di un'istanza di un particolare nome di campo di intestazione.

I Signer devono fare attenzione a firmare campi di intestazione che potrebbero avere istanze aggiuntive aggiunte successivamente nel processo di consegna, poiché tali campi di intestazione potrebbero essere inseriti dopo l'istanza firmata o altrimenti riordinati. I campi di intestazione di traccia (come Received) e i blocchi Resent-* sono gli unici campi proibiti da [RFC5322] di essere riordinati. In particolare, poiché i campi di intestazione DKIM-Signature possono essere riordinati da alcuni MTA intermedi, firmare campi di intestazione DKIM-Signature esistenti è soggetto a errori.

AMMONIMENTO INFORMATIVO: Nonostante il fatto che [RFC5322] non proibisca il riordino dei campi di intestazione, il riordino dei campi di intestazione firmati con più istanze da parte di MTA intermedi causerà la rottura delle firme DKIM; tale comportamento antisociale dovrebbe essere evitato.

NOTA DELL'IMPLEMENTATORE INFORMATIVA: Sebbene non richiesto da questa specifica, tutti i campi di intestazione visibili all'utente finale dovrebbero essere firmati per evitare possibili "spam indiretti". Ad esempio, se il campo di intestazione Subject non è firmato, uno spammer può reinviare una mail precedentemente firmata, sostituendo il subject legittimo con uno spam di una riga.

5.4.1. Recommended Signature Content (Contenuto della firma raccomandato)

Lo scopo dell'algoritmo crittografico DKIM è di apporre un identificatore al messaggio in un modo che sia sia robusto contro i normali cambiamenti legati al transito sia resistente ai tipi di attacchi replay. Un aspetto essenziale per soddisfare questi requisiti è scegliere quali campi di intestazione includere nell'hash e quali campi escludere.

La regola di base per scegliere i campi da includere è selezionare quei campi che costituiscono il "nucleo" del contenuto del messaggio. Quindi, qualsiasi attacco replay dovrà includerli per far sì che la firma abbia successo; tuttavia, con questi inclusi, il nucleo del messaggio è valido, anche se inviato a nuovi destinatari.

Esempi comuni di campi con indirizzi e campi con contenuto testuale relativo al corpo sono:

From (RICHIESTO; vedi Sezione 5.4)
Reply-To
Subject
Date
To, Cc
Resent-Date, Resent-From, Resent-To, Resent-Cc
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

Se il tag di firma "l=" è in uso (vedi Sezione 3.5), anche il campo Content-Type è un candidato per essere incluso poiché potrebbe essere sostituito in modo da causare la visualizzazione di contenuti completamente diversi all'utente ricevente.

Ci sono compromessi nella decisione di ciò che costituisce il "nucleo" del messaggio, che per alcuni campi è un concetto soggettivo. Includere campi come "Message-ID", ad esempio, è utile se si considera un meccanismo per poter distinguere istanze separate dello stesso messaggio come contenuto principale. Allo stesso modo, "In-Reply-To" e "References" potrebbero essere desiderabili da includere se si considera il threading dei messaggi come parte centrale del messaggio.

Un'altra classe di campi che potrebbero essere di interesse sono quelli che trasmettono informazioni relative alla sicurezza sul messaggio, come Authentication-Results [RFC5451].

La regola di base per scegliere i campi da escludere è selezionare quei campi per i quali esistono più campi con lo stesso nome e campi che vengono modificati in transito. Esempi di questi sono:

Return-Path
Received
Comments, Keywords

Si noti che anche il campo DKIM-Signature è escluso dall'hash dell'intestazione perché la sua gestione è specificata separatamente.

Tipicamente, è meglio escludere altri campi opzionali a causa del potenziale che campi aggiuntivi con lo stesso nome vengano legittimamente aggiunti o riordinati prima della verifica. È probabile che ci siano eccezioni legittime a questa regola a causa dell'ampia varietà di campi di intestazione specifici dell'applicazione che potrebbero essere applicati a un messaggio, alcuni dei quali sono improbabili da duplicare, modificare o riordinare.

I Signer DOVREBBERO scegliere algoritmi di canonicalizzazione in base ai tipi di messaggi che elaborano e alla loro avversione al rischio. Ad esempio, i siti di e-commerce che inviano principalmente ricevute di acquisto, che non sono previsti essere elaborati da mailing list o altro software che probabilmente modificherà i messaggi, generalmente preferiranno la canonicalizzazione "simple".

I siti che inviano principalmente e-mail da persona a persona probabilmente preferiranno essere più resilienti alle modifiche durante il trasporto utilizzando la canonicalizzazione "relaxed".

A meno che la posta non venga elaborata attraverso intermediari, come mailing list che potrebbero aggiungere istruzioni di "annullamento iscrizione" in fondo al corpo del messaggio, il tag "l=" è probabile che non trasmetta alcun beneficio aggiuntivo fornendo al contempo un'avenue per l'aggiunta non autorizzata di testo a un messaggio. L'uso di "l=0" porta questo all'estremo, consentendo l'alterazione completa del testo del messaggio senza invalidare la firma. Inoltre, un Verifier avrebbe il diritto di considerare un corpo di messaggio parzialmente firmato come inaccettabile. Si consiglia un uso giudizioso.

5.4.2. Signatures Involving Multiple Instances of a Field (Firme che coinvolgono più istanze di un campo)

I Signer che scelgono di firmare un campo di intestazione esistente che si verifica più di una volta nel messaggio (come Received) DEVONO firmare l'ultima istanza fisica di quel campo di intestazione nel blocco di intestazione. I Signer che desiderano firmare più istanze di tale campo di intestazione DEVONO includere il nome del campo di intestazione più volte nel tag "h=" del campo di intestazione DKIM-Signature e DEVONO firmare tali campi di intestazione in ordine dalla parte inferiore del blocco di campo di intestazione alla parte superiore. Il Signer PUÒ includere più istanze di un nome di campo di intestazione in "h=" rispetto a quanti sono i campi di intestazione corrispondenti effettivi in modo che la firma non verifichi se vengono aggiunti campi di intestazione aggiuntivi di quel nome.

ESEMPIO INFORMATIVO:

Se il Signer desidera firmare due campi di intestazione Received esistenti, e l'intestazione esistente contiene:
Received: <A>
Received: <B>
Received: <C>
allora il campo di intestazione DKIM-Signature risultante dovrebbe essere:
DKIM-Signature: ... h=Received : Received :...
e i campi di intestazione Received <C> e <B> verranno firmati in quell'ordine.

5.5. Compute the Message Hash and Signature (Calcolare l'hash e la firma del messaggio)

Il Signer DEVE calcolare l'hash del messaggio come descritto nella Sezione 3.7 e quindi firmarlo utilizzando l'algoritmo a chiave pubblica selezionato. Questo risulterà in un campo di intestazione DKIM-Signature che includerà l'hash del corpo e una firma dell'hash dell'intestazione, dove quell'intestazione include il campo di intestazione DKIM-Signature stesso.

Entità come i gestori di mailing list che implementano DKIM e che modificano il messaggio o un campo di intestazione (ad esempio, inserendo informazioni di annullamento dell'iscrizione) prima di ritrasmettere il messaggio DOVREBBERO controllare qualsiasi firma esistente in input e DEVONO effettuare tali modifiche prima di ri-firmare il messaggio.

5.6. Insert the DKIM-Signature Header Field (Inserire il campo di intestazione DKIM-Signature)

Infine, il Signer DEVE inserire il campo di intestazione DKIM-Signature creato nel passaggio precedente prima di trasmettere l'e-mail. Il campo di intestazione DKIM-Signature DEVE essere lo stesso di quello utilizzato per calcolare l'hash come descritto sopra, tranne che il valore del tag "b=" DEVE essere l'hash appropriatamente firmato calcolato nel passaggio precedente, firmato utilizzando l'algoritmo specificato nel tag "a=" del campo di intestazione DKIM-Signature e utilizzando la chiave privata corrispondente al selettore dato nel tag "s=" del campo di intestazione DKIM-Signature, come scelto sopra nella Sezione 5.2.

Il campo di intestazione DKIM-Signature DEVE essere inserito prima di qualsiasi altro campo DKIM-Signature nel blocco di intestazione.

NOTA DI IMPLEMENTAZIONE INFORMATIVA: Il modo più semplice per ottenere questo è inserire il campo di intestazione DKIM-Signature all'inizio del blocco di intestazione. In particolare, può essere posizionato prima di qualsiasi campo di intestazione Received esistente. Questo è coerente con il trattamento di DKIM-Signature come un campo di intestazione di traccia.