Mi piacerebbe avere un'identità GnuPG che possa usare entrambi per un lungo periodo (in modo da poter creare una vasta rete di fiducia) e immediatamente con quante più persone possibile. Ad oggi, il secondo obiettivo si incontra meglio con una chiave RSA (o DSA), perché è supportata anche da versioni molto vecchie di GnuPG. Tuttavia, riguardo al primo obiettivo a lungo termine, sono personalmente più favorevole a una chiave ECC. Pertanto, per raggiungere entrambi gli obiettivi, la mia idea era di mantenere contemporaneamente sia una chiave RSA che una chiave ECC (con gli stessi UID) e lasciare che la prima scadesse una volta che il supporto per ECC fosse abbastanza diffuso.
A livello delle chiavi principali, questo non dovrebbe essere un problema: posso firmare ogni chiave con l'altra, in modo che le firme su una chiave contribuiscano anche alla rete di fiducia dell'altra chiave. I contatti possono quindi firmare entrambe le chiavi se supportano entrambi, o solo la chiave RSA se non sono ancora in grado di gestire l'ECC.
Per facilità d'uso, mi piacerebbe avere solo un set di sottochiavi, perché vorrei memorizzarli su una singola smart card. Quindi, la mia idea era di condividere lo stesso insieme di sottochiavi tra le due chiavi principali. Ciò dovrebbe consentirmi di decodificare, firmare e autenticarsi per entrambe le chiavi principali con un solo set di sottochiavi, il che eviterebbe il fastidio di scegliere la chiave giusta per ogni scambio di comunicazioni.
Q: La mia idea di condividere sottochiavi è ragionevole e possibile, o ho trascurato alcuni aspetti del design di GnuPG che impediscono questo o sollevano problemi pratici?
Per quanto ho capito tecnicamente, ciò che rende una chiave una sottochiave è fondamentalmente un certificato dalla chiave principale che appartiene alla chiave principale. Tali certificati (o firme) possono essere estratti da una chiave con
gpg --export-secret-keys <your keyid> | gpgsplit
Ho trovato un post piuttosto vecchio che descrive l'importazione di una sottochiave in un chiave master esistente, ma non è stato possibile applicarla al mio scopo perché non so come emettere manualmente il "certificato sottochiave" per la chiave master per la quale la sottochiave non è stata originariamente creata.
Più specificamente, ho esportato e scomposto ogni chiave in una directory usando il comando sopra. Quindi, ho la sottochiave e il "certificato sottochiave" per la prima chiave in key1/000004-007.secret_subkey
e key1/000005-002.sig
, rispettivamente. Per importare questa sottochiave nella seconda chiave master, ho provato i seguenti tre approcci, combinando e importando il risultato con
cat key2/* > key2/key.gpg
gpg --import key2/key.gpg
dopo ogni approccio:
-
Copia la sottochiave senza modifiche (ad es.
cp key1/000004-007.secret_subkey key2/
), sperando che GnuPG mi chieda se dovrebbe emettere un certificato all'importazione. -
Oltre a 1, copia il certificato senza modifiche (cioè
cp key1/00000{4-007.secret_subkey,5-002.sig} key2/
), sperando che GnuPG mi chieda se è necessario sostituire il certificato con la prima chiave attraverso una emessa dalla seconda chiave. -
Oltre a 2, modifica il certificato sostituendo l'impronta digitale della prima chiave con l'impronta digitale della seconda chiave, sperando che GnuPG scarichi il certificato contraffatto e mi chieda se dovrebbe invece emettere uno valido.
In tutti i casi, né la prima né la seconda chiave erano nel mio mazzo di chiavi prima dell'importazione. Il risultato è sempre lo stesso, però:
gpg: key 0x<id of key2>: secret key imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: secret keys imported: 1
gpg: secret keys unchanged: 1
Q : come posso rilasciare un certificato valido per la sottochiave con la seconda chiave principale, in modo da poter importare la sottochiave in questa chiave principale?