Passa al contenuto principale

3.7 Computing the Message Hashes (Calcolo degli hash dei messaggi)

3.7. Computing the Message Hashes (Calcolo degli hash dei messaggi)​

Sia la firma che la verifica delle firme dei messaggi iniziano con un passaggio di calcolo di due hash crittografici sul messaggio. I Signer sceglieranno i parametri della firma come descritto in "Signer Actions" (Sezione 5); i Verifier utilizzeranno i parametri specificati nel campo di intestazione DKIM-Signature da verificare. Nella discussione seguente, vengono utilizzati i nomi dei tag nel campo di intestazione DKIM-Signature che esiste (durante la verifica) o sarà creato (durante la firma). Si noti che la canonicalizzazione (Sezione 3.4) è utilizzata solo per preparare l'email per la firma o la verifica; non influisce sull'email trasmessa in alcun modo.

Il Signer/Verifier DEVE calcolare due hash: uno sul corpo del messaggio e uno sui campi di intestazione selezionati del messaggio.

I Signer DEVONO calcolarli nell'ordine mostrato. I Verifier POSSONO calcolarli in qualsiasi ordine conveniente per il Verifier, a condizione che il risultato sia semanticamente identico alla semantica che sarebbe il caso se fossero stati calcolati in questo ordine.

Nel passaggio di hash 1, il Signer/Verifier DEVE eseguire l'hash del corpo del messaggio, canonicalizzato utilizzando l'algoritmo di canonicalizzazione del corpo specificato nel tag "c=" e poi troncato alla lunghezza specificata nel tag "l=". Quel valore di hash viene quindi convertito in forma base64 e inserito in (Signer) o confrontato con (Verifier) il tag "bh=" del campo di intestazione DKIM-Signature.

Nel passaggio di hash 2, il Signer/Verifier DEVE passare quanto segue all'algoritmo di hash nell'ordine indicato.

  1. I campi di intestazione specificati dal tag "h=", nell'ordine specificato in quel tag, e canonicalizzati utilizzando l'algoritmo di canonicalizzazione dell'intestazione specificato nel tag "c=". Ogni campo di intestazione DEVE essere terminato con un singolo CRLF.

  2. Il campo di intestazione DKIM-Signature che esiste (verifica) o sarà inserito (firma) nel messaggio, con il valore del tag "b=" (inclusi tutti gli spazi bianchi circostanti) eliminato (cioè, trattato come stringa vuota), canonicalizzato utilizzando l'algoritmo di canonicalizzazione dell'intestazione specificato nel tag "c=", e senza un CRLF finale.

Tutti i tag e i loro valori nel campo di intestazione DKIM-Signature sono inclusi nell'hash crittografico con la sola eccezione della porzione di valore del tag "b=" (firma), che DEVE essere trattata come stringa nulla. Tutti i tag DEVONO essere inclusi anche se potrebbero non essere compresi dal Verifier. Il campo di intestazione DEVE essere presentato all'algoritmo di hash dopo il corpo del messaggio piuttosto che con il resto dei campi di intestazione e DEVE essere canonicalizzato come specificato nel tag "c=" (canonicalizzazione). Il campo di intestazione DKIM-Signature NON DEVE essere incluso nel proprio tag "h=", sebbene altri campi di intestazione DKIM-Signature POSSANO essere firmati (vedere Sezione 4).

Quando si calcola l'hash sui messaggi che verranno trasmessi utilizzando la codifica base64 o quoted-printable, i Signer DEVONO calcolare l'hash dopo la codifica. Allo stesso modo, il Verifier DEVE incorporare i valori nell'hash prima di decodificare il testo base64 o quoted-printable. Tuttavia, l'hash DEVE essere calcolato prima delle codifiche a livello di trasporto come lo "dot-stuffing" SMTP (la modifica delle righe che iniziano con un "." per evitare confusione con il marcatore di fine messaggio SMTP, come specificato in [RFC5321]).

Ad eccezione della procedura di canonicalizzazione descritta nella Sezione 3.4, il processo di firma DKIM tratta il corpo dei messaggi semplicemente come una stringa di ottetti. I messaggi DKIM POSSONO essere in testo semplice o in formato MIME; non viene fornito alcun trattamento speciale al contenuto MIME. Gli allegati dei messaggi in formato MIME DEVONO essere inclusi nel contenuto firmato.

Più formalmente, lo pseudo-codice per l'algoritmo di firma è:

body-hash    =  hash-alg (canon-body, l-param)
data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
signature    =  sig-alg (d-domain, selector, data-hash)

dove:

  • body-hash: è l'output dall'hashing del corpo, utilizzando hash-alg.
  • hash-alg: è l'algoritmo di hashing specificato nel parametro "a".
  • canon-body: è una rappresentazione canonicalizzata del corpo, prodotta utilizzando l'algoritmo del corpo specificato nel parametro "c", come definito nella Sezione 3.4 ed escludendo il campo DKIM-Signature.
  • l-param: è il valore length-of-body del parametro "l".
  • data-hash: è l'output dall'utilizzo dell'algoritmo hash-alg, per eseguire l'hash dell'intestazione incluso l'intestazione DKIM-Signature, e l'hash del corpo.
  • h-headers: è l'elenco delle intestazioni da firmare, come specificato nel parametro "h".
  • D-SIG: è il campo DKIM-Signature canonicalizzato stesso senza la porzione del valore della firma del parametro, cioè un valore di parametro vuoto.
  • signature: è il valore della firma prodotto dall'algoritmo di firma.
  • sig-alg: è l'algoritmo di firma specificato dal parametro "a".
  • d-domain: è il nome di dominio specificato nel parametro "d".
  • selector: è il valore del selettore specificato nel parametro "s".

NOTA: Molte API di firma digitale forniscono sia l'hashing che l'applicazione della chiave privata RSA utilizzando una singola primitiva "sign()". Quando si utilizza tale API, gli ultimi due passaggi dell'algoritmo verrebbero probabilmente combinati in una singola chiamata che eseguirebbe sia "a-hash-alg" che "sig-alg".

Ultimo aggiornamento il