(a) your old key should sign your new key
(b) write a transition statement, stating that you're moving from
an old to a new key, and that you want your new key to be signed
(c) sign that transition statement
Isn't the act of signing another key that has the same UID/email
address, sufficient to prove that all trust placed in the old key
should be inherited by the new key?
No. La firma della chiave fornirà solo le metriche di attendibilità determinate dalla politica di fiducia di un altro utente dopo aver importato quella chiave.
That is: (a) is sufficient, (b) is perhaps useful (though could be
replaced by other unauthenticated channels), and (c) is
unnecessary.
Questo non raggiungerà lo scopo una volta che le informazioni sono state ricevute da altri utenti di OpenPGP e l'efficacia varierà interamente in base alle proprie politiche. Se si firma solo la nuova chiave con la vecchia chiave, la nuova chiave otterrà solo i valori di fiducia, solitamente con un flusso di valore leggermente ridotto da quella firma. Questi valori di fiducia, tuttavia, sono non determinati da te, sono determinati da ciascun utente all'interno del loro portachiavi.
Una facile dimostrazione di ciò, ovviamente, è confrontare il valore di fiducia della propria chiave segreta con qualsiasi altra cosa nel portachiavi pubblico; il tuo dovrebbe essere "definitivo" e tutti gli altri saranno inferiori. Probabilmente la maggior parte di loro sarà "sconosciuta" o altrimenti non specificata.
Se si firma solo la nuova chiave con quella vecchia, non c'è sostanzialmente alcuna differenza tra quella e qualsiasi altra chiave che si firma, come ad esempio un evento di firma della chiave. Lo scopo di un'istruzione di transizione è di confermare esplicitamente che la nuova chiave sostituisce la vecchia chiave e che chiunque abbia firmato la vecchia chiave dovrebbe essere in grado di utilizzare l'istruzione per confermare la transizione e firmare la nuova chiave. Che non è qualcosa che farebbero per qualsiasi chiave che ti è capitato di firmare che non ti appartiene, indipendentemente dai conflitti UID (che possono contenere o meno indirizzi email).
Per fornire la necessaria garanzia e le informazioni pertinenti alle persone a cui stai essenzialmente inviando una richiesta per firmare la tua nuova chiave, dovresti davvero fornire tutte le informazioni. Direi "deve" qui, ma non voglio confondere le persone usando la terminologia simile a RFC.
Una cosa che è normalmente raccomandata con le istruzioni di transizione che non sono state incluse nell'elenco qui sopra, tuttavia, è che (c) sign that transition statement dovrebbe essere la doppia firma dell'istruzione di transizione. Cioè, il documento dell'istruzione di transizione è firmato entrambi la vecchia chiave e la nuova chiave.
Alcuni anni fa sono passato dalla mia vecchia chiave ( 0x371AC5BFA04AE313 ) alla mia chiave attuale ( 0x321E4E2373590E5D ) e utilizzato questo documento di transizione ) con cui è possibile visualizzare l'intero processo. Se importi le mie vecchie e nuove chiavi e poi verifichi l'affermazione vedrai che i dati della firma contengono due firme piuttosto che una, anche se con lo stesso timestamp. L'istruzione di transizione contiene tutte le informazioni necessarie per verificare una chiave che normalmente verrebbe verificata di persona o tramite un altro canale fidato (cioè di solito in una key signing party o CryptoParty), la doppia firma indica ai destinatari che entrambe le chiavi rimangono sotto la stessa persona controllo e che non credono che la vecchia chiave sia stata compromessa nel momento in cui è stata fatta la dichiarazione di transizione.
Vedrai anche che ho eliminato la maggior parte del testo del mio documento di transizione da DKG. ;)