3.6 Key Management and Representation (Gestione e rappresentazione delle chiavi)

3.6. Key Management and Representation (Gestione e rappresentazione delle chiavi)

Le applicazioni di firma richiedono un certo livello di garanzia che la chiave pubblica di verifica sia associata al Signer dichiarato. Molte applicazioni raggiungono questo obiettivo utilizzando certificati di chiave pubblica emessi da una terza parte fidata. Tuttavia, DKIM può raggiungere un livello sufficiente di sicurezza, con una scalabilità significativamente migliorata, semplicemente facendo interrogare dal Verifier la voce DNS del presunto Signer (o un equivalente di sicurezza) per recuperare la chiave pubblica.

Le chiavi DKIM possono potenzialmente essere archiviate in più tipi di server di chiavi e in più formati. L'archiviazione e il formato delle chiavi sono irrilevanti per il resto dell'algoritmo DKIM.

I parametri per l'algoritmo di ricerca delle chiavi sono il tipo di ricerca (il tag "q="), il dominio del Signer (il tag "d=" del campo di intestazione DKIM-Signature) e il selettore (il tag "s=").

public_key = dkim_find_key(q_val, d_val, s_val)

Questo documento definisce un singolo binding, utilizzando DNS TXT RR per distribuire le chiavi. Altri binding possono essere definiti in futuro.

3.6.1. Textual Representation (Rappresentazione testuale)

Si prevede che molti server di chiavi sceglieranno di presentare le chiavi in un formato di testo altrimenti non strutturato (ad esempio, una forma XML non sarebbe considerata testo non strutturato per questo scopo). La seguente definizione DEVE essere utilizzata per qualsiasi chiave DKIM rappresentata in forma testuale altrimenti non strutturata.

La sintassi complessiva è una tag-list come descritto nella Sezione 3.2. I tag attualmente validi sono descritti di seguito. Altri tag POSSONO essere presenti e DEVONO essere ignorati da qualsiasi implementazione che non li comprende.

v= Versione del record della chiave DKIM (testo semplice; RACCOMANDATO, predefinito "DKIM1"). Se specificato, questo tag DEVE essere impostato su "DKIM1" (senza virgolette). Questo tag DEVE essere il primo tag nel record. I record che iniziano con un tag "v=" con qualsiasi altro valore DEVONO essere scartati. Si noti che i verificatori devono eseguire un confronto di stringhe su questo valore; ad esempio, "DKIM1" non è uguale a "DKIM1.0".

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= Algoritmi di hash accettabili (testo semplice; OPZIONALE, predefinito consente tutti gli algoritmi). Un elenco separato da due punti di algoritmi di hash che potrebbero essere utilizzati. Gli algoritmi non riconosciuti DEVONO essere ignorati. Fare riferimento alla Sezione 3.3 per una discussione sugli algoritmi di hash implementati da Signer e Verifier. L'insieme di algoritmi elencati in questo tag in ciascun record è una scelta operativa effettuata dal Signer.

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; per estensione futura

k= Tipo di chiave (testo semplice; OPZIONALE, predefinito "rsa"). Signer e Verifier DEVONO supportare il tipo di chiave "rsa". Il tipo di chiave "rsa" indica che viene utilizzata una RSAPublicKey codificata ASN.1 DER [ITU-X660-1997] (vedere [RFC3447], Sezioni 3.1 e A.1.1) nel tag "p=". (Nota: il tag "p=" codifica ulteriormente il valore utilizzando l'algoritmo base64.) I tipi di chiave non riconosciuti DEVONO essere ignorati.

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; per estensione futura

n= Note che potrebbero essere di interesse per un essere umano (qp-section; OPZIONALE, predefinito vuoto). Nessuna interpretazione viene effettuata da alcun programma. Questo tag dovrebbe essere utilizzato con parsimonia in qualsiasi meccanismo di server di chiavi che abbia limitazioni di spazio (in particolare DNS). Questo è destinato all'uso da parte degli amministratori, non degli utenti finali.

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= Dati della chiave pubblica (base64; RICHIESTO). Un valore vuoto significa che questa chiave pubblica è stata revocata. La sintassi e la semantica di questo valore di tag prima di essere codificato in base64 sono definite dal tag "k=".

RAGIONAMENTO INFORMATIVO: Se una chiave privata è stata compromessa o altrimenti disabilitata (ad es., un contratto di outsourcing è stato terminato), un Signer potrebbe voler dichiarare esplicitamente di essere a conoscenza del selettore, ma tutti i messaggi che utilizzano quel selettore dovrebbero fallire la verifica. I Verifier DOVREBBERO restituire un codice di errore per qualsiasi campo di intestazione DKIM-Signature con un selettore che fa riferimento a una chiave revocata. (Vedere Sezione 6.1.2 per i dettagli.)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

NOTA INFORMATIVA: Un base64string può includere spazi bianchi (FWS) in posizioni arbitrarie; tuttavia, qualsiasi CRLF deve essere seguito da almeno un carattere WSP. Gli implementatori e gli amministratori sono avvertiti di garantire che i TXT RR dei selettori siano conformi a questa specifica.

s= Tipo di servizio (testo semplice; OPZIONALE; predefinito "*"). Un elenco separato da due punti di tipi di servizi a cui si applica questo record. I Verifier per un determinato tipo di servizio DEVONO ignorare questo record se il tipo appropriato non è elencato. I tipi di servizio non riconosciuti DEVONO essere ignorati. I tipi di servizio attualmente definiti sono i seguenti:

* corrisponde a tutti i tipi di servizio
email posta elettronica (non necessariamente limitato a SMTP)

Questo tag ha lo scopo di limitare l'uso delle chiavi per altri scopi, se l'uso di DKIM dovesse essere definito da altri servizi in futuro.

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; per estensione futura

t= Flag, rappresentati come un elenco separato da due punti di nomi (testo semplice; OPZIONALE, predefinito nessun flag impostato). I flag non riconosciuti DEVONO essere ignorati. I flag definiti sono i seguenti:

y Questo dominio sta testando DKIM. I Verifier NON DEVONO trattare i messaggi dai Signer in modalità test diversamente dall'email non firmata, anche se la firma non dovesse verificarsi. I Verifier POSSONO desiderare di tracciare i risultati in modalità test per assistere il Signer.
s Qualsiasi campo di intestazione DKIM-Signature che utilizza il tag "i=" DEVE avere lo stesso valore di dominio sul lato destro del "@" nel tag "i=" e il valore del tag "d=". Cioè, il dominio "i=" NON DEVE essere un sottodominio di "d=". L'uso di questo flag è RACCOMANDATO a meno che non sia richiesto il subdomaining.

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; per estensione futura

3.6.2. DNS Binding (Binding DNS)

Un binding che utilizza DNS TXT RR come servizio di chiavi è qui definito. Tutte le implementazioni DEVONO supportare questo binding.

3.6.2.1. Namespace (Spazio dei nomi)

Tutte le chiavi DKIM sono archiviate in un sottodominio denominato "_domainkey". Dato un campo DKIM-Signature con un tag "d=" di "example.com" e un tag "s=" di "foo.bar", la query DNS sarà per "foo.bar._domainkey.example.com".

3.6.2.2. Resource Record Types for Key Storage (Tipi di record di risorse per l'archiviazione delle chiavi)

Il tipo di record di risorse DNS utilizzato è specificato da un'opzione al tag di tipo di query ("q="). L'unica opzione definita in questa specifica base è "txt", che indica l'uso di un TXT RR. Un'estensione successiva di questo standard potrebbe definire un altro tipo RR.

Le stringhe in un TXT RR DEVONO essere concatenate insieme prima dell'uso senza spazi bianchi intermedi. I TXT RR DEVONO essere unici per un particolare nome di selettore; cioè, se ci sono più record in un RRset, i risultati sono indefiniti.

I TXT RR sono codificati come descritto nella Sezione 3.6.1.