4. Semantics of Multiple Signatures (Semantica delle firme multiple)

4.1. Example Scenarios (Scenari di esempio)

Ci sono molte ragioni per cui un messaggio potrebbe avere più firme. Ad esempio, supponiamo che SHA-256 venga in futuro ritenuto insufficientemente forte e che l'uso di DKIM passi a SHA-1024. Un Signer potrebbe immediatamente firmare utilizzando il nuovo algoritmo ma anche continuare a firmare utilizzando l'algoritmo più vecchio per l'interoperabilità con i Verifier che non sono ancora stati aggiornati. Il Signer lo farebbe aggiungendo due campi di intestazione DKIM-Signature, uno per ciascun algoritmo. I Verifier più vecchi che non riconoscono SHA-1024 come algoritmo accettabile salteranno quella firma e utilizzeranno l'algoritmo più vecchio; i Verifier più recenti potrebbero utilizzare una delle due firme a loro scelta e, a parità di altre condizioni, potrebbero persino non tentare di verificare l'altra firma.

Allo stesso modo, un Signer potrebbe firmare un messaggio includendo tutti i campi di intestazione e nessun tag "l=" (per soddisfare i Verifier rigorosi) e una seconda volta con un insieme limitato di campi di intestazione e un tag "l=" (in previsione di possibili modifiche al messaggio in rotta verso altri Verifier). I Verifier potrebbero quindi scegliere quale firma preferiscono.

Naturalmente, un messaggio potrebbe anche avere più firme perché è passato attraverso più Signer. Un caso comune dovrebbe essere quello di un messaggio firmato che passa attraverso una mailing list che firma anche tutti i messaggi. Supponendo che entrambe queste firme vengano verificate, un destinatario potrebbe scegliere di accettare il messaggio se una di queste firme è nota per provenire da fonti affidabili.

In particolare, i destinatari potrebbero scegliere di mettere in whitelist le mailing list a cui si sono iscritti e che hanno politiche anti-abuso accettabili in modo da accettare messaggi inviati a quella lista anche da autori sconosciuti. Potrebbero anche iscriversi a mailing list meno affidabili (ad es., quelle senza protezione anti-abuso) ed essere disposti ad accettare tutti i messaggi da autori specifici ma insistere nel fare scansioni anti-abuso aggiuntive per altri messaggi.

Un altro esempio correlato di più Signer potrebbero essere i servizi di inoltro, come quelli comunemente associati ai siti di ex studenti accademici. Ad esempio, un destinatario potrebbe avere un indirizzo presso members.example.org, un sito che ha una protezione anti-abuso un po' meno efficace di quanto il destinatario preferirebbe. Tale destinatario potrebbe avere autori specifici i cui messaggi sarebbero assolutamente fidati, ma i messaggi da autori sconosciuti che hanno superato il controllo del forwarder avrebbero solo una fiducia media.

4.2. Interpretation (Interpretazione)

Un Signer che sta aggiungendo una firma a un messaggio crea semplicemente un nuovo header DKIM-Signature, utilizzando la semantica usuale dell'opzione "h=". Un Signer PUÒ firmare campi di intestazione DKIM-Signature precedentemente esistenti utilizzando il metodo descritto nella Sezione 5.4 per firmare i campi di intestazione di traccia.

Si noti che i Signer dovrebbero essere consapevoli che la firma di campi di intestazione DKIM-Signature può causare fallimenti di firma con intermediari che non riconoscono che i campi di intestazione DKIM-Signature sono campi di intestazione di traccia e li riordinano involontariamente, rompendo così tali firme. Per questo motivo, la firma di campi di intestazione DKIM-Signature esistenti è sconsigliata, sebbene legale.

NOTA INFORMATIVA: Se viene firmato un campo di intestazione con più istanze, tali campi di intestazione vengono sempre firmati dal basso verso l'alto. Pertanto, non è possibile firmare solo specifici campi di intestazione DKIM-Signature. Ad esempio, se il messaggio in fase di firma contiene già tre campi di intestazione DKIM-Signature A, B e C, è possibile firmarli tutti, solo B e C, o solo C, ma non solo A, solo B, solo A e B, o solo A e C.

Un Signer PUÒ aggiungere più di un campo di intestazione DKIM-Signature utilizzando parametri diversi. Ad esempio, durante un periodo di transizione, un Signer potrebbe voler produrre firme utilizzando due algoritmi di hash diversi.

I Signer NON DOVREBBERO rimuovere alcun campo di intestazione DKIM-Signature dai messaggi che stanno firmando, anche se sanno che le firme non possono essere verificate.

Quando si valuta un messaggio con più firme, un Verifier DOVREBBE valutare le firme indipendentemente e in base ai loro meriti. Ad esempio, un Verifier che per politica sceglie di non accettare firme con algoritmi crittografici deprecati considererebbe tali firme non valide. I Verifier POSSONO elaborare le firme in qualsiasi ordine di loro scelta; ad esempio, alcuni Verifier potrebbero scegliere di elaborare le firme corrispondenti al campo From nell'intestazione del messaggio prima di altre firme. Vedere Sezione 6.1 per ulteriori informazioni sulle scelte delle firme.

NOTA DI IMPLEMENTAZIONE INFORMATIVA: I tentativi del Verifier di correlare firme valide con firme non valide nel tentativo di indovinare perché una firma è fallita sono sconsigliati. In particolare, non esiste un modo generale in cui un Verifier possa determinare che una firma non valida sia mai stata valida.

I Verifier DOVREBBERO continuare a controllare le firme fino a quando una firma non verifica con successo con soddisfazione del Verifier. Per limitare potenziali attacchi denial-of-service, i Verifier POSSONO limitare il numero totale di firme che tenteranno di verificare.

Se un modulo Verifier segnala firme le cui valutazioni hanno prodotto risultati PERMFAIL, gli Identity Assessor DOVREBBERO ignorare tali firme (vedere Sezione 6.1), agendo come se non fossero presenti nel messaggio.