Tâche #36802
Mis à jour par Emmanuel GARETTE il y a 11 mois
> Proposition : utiliser la clé publique des dépôts dont seul le PCLL dispose de la clé privée.
Si je regarde les clefs publiques en question :
<pre>
root@amonecole:~# gpg --keyring /etc/apt/trusted.gpg.d/eole-archive-eole-2.9-jammy-jellyfish.gpg --list-keys
/etc/apt/trusted.gpg.d/eole-archive-eole-2.9-jammy-jellyfish.gpg
----------------------------------------------------------------
pub rsa4096 2022-01-19 [SC]
06EE28059F3152E87B618743F7D6DCB146E68BDF
uid [ inconnue] EOLE Repository (EOLE 2.9/Jammy Jellyfish) <repository@listeseole.ac-dijon.fr>
</pre>
Si j'en crois https://lists.gnupg.org/pipermail/gnupg-users/2009-March/035929.html
<pre>
> What do the letters to the right of the words "usage" mean?
> (S,C,A,E) I can only guess |S|ign, |E|ncrypt, ....
(S)ign: sign some data (like a file)
(C)ertify: sign a key (this is called certification)
(A)uthenticate: authenticate yourself to a computer (for example,
logging in)
(E)ncrypt: encrypt data
</pre>
Il manque un ligne qui ressemblerait à :
<pre>
sub xxxxxx 20XX-XX-XX [E]
</pre>
Donc on peut signer mais pas chiffrer avec ces clefs publique.
D'une façon plus général je ne crois pas que GPG soit l'outil le plus adapté au besoin :
- comment gérer la confiance ?
-- comment organiser l'échange de clef ?
-- est-ce que l'organisme doit faire un clé GPG pour l'organisme + une clef par serveur (bof) qu'il sur-signe ?
-- est-ce que l'organisme doit faire un clé GPG pour l'organisme + une clef par technicien qu'il sur-signe ?
- comment gérer la protection des clefs (je parle en plus de la passphrase) : comment partager les clefs ? Via Zéphir ? Sur tous les serveurs ?
Je ne vois pas du tout l'intérêt de s'embêter avec le partage de clef publique.
Je propose donc :
- EOLE créer un certificat avec l’algorithme RSA (via openssl par exemple) et diffuse la clef publique sur tous les serveurs
- gen_rpt chiffre le fichier sans avoir besoin d'une clef privée
- EOLE peut déchiffer le fichier mais cela ne garanti pas que l’émetteur est bien celui qu'il prétend être.
Si je regarde les clefs publiques en question :
<pre>
root@amonecole:~# gpg --keyring /etc/apt/trusted.gpg.d/eole-archive-eole-2.9-jammy-jellyfish.gpg --list-keys
/etc/apt/trusted.gpg.d/eole-archive-eole-2.9-jammy-jellyfish.gpg
----------------------------------------------------------------
pub rsa4096 2022-01-19 [SC]
06EE28059F3152E87B618743F7D6DCB146E68BDF
uid [ inconnue] EOLE Repository (EOLE 2.9/Jammy Jellyfish) <repository@listeseole.ac-dijon.fr>
</pre>
Si j'en crois https://lists.gnupg.org/pipermail/gnupg-users/2009-March/035929.html
<pre>
> What do the letters to the right of the words "usage" mean?
> (S,C,A,E) I can only guess |S|ign, |E|ncrypt, ....
(S)ign: sign some data (like a file)
(C)ertify: sign a key (this is called certification)
(A)uthenticate: authenticate yourself to a computer (for example,
logging in)
(E)ncrypt: encrypt data
</pre>
Il manque un ligne qui ressemblerait à :
<pre>
sub xxxxxx 20XX-XX-XX [E]
</pre>
Donc on peut signer mais pas chiffrer avec ces clefs publique.
D'une façon plus général je ne crois pas que GPG soit l'outil le plus adapté au besoin :
- comment gérer la confiance ?
-- comment organiser l'échange de clef ?
-- est-ce que l'organisme doit faire un clé GPG pour l'organisme + une clef par serveur (bof) qu'il sur-signe ?
-- est-ce que l'organisme doit faire un clé GPG pour l'organisme + une clef par technicien qu'il sur-signe ?
- comment gérer la protection des clefs (je parle en plus de la passphrase) : comment partager les clefs ? Via Zéphir ? Sur tous les serveurs ?
Je ne vois pas du tout l'intérêt de s'embêter avec le partage de clef publique.
Je propose donc :
- EOLE créer un certificat avec l’algorithme RSA (via openssl par exemple) et diffuse la clef publique sur tous les serveurs
- gen_rpt chiffre le fichier sans avoir besoin d'une clef privée
- EOLE peut déchiffer le fichier mais cela ne garanti pas que l’émetteur est bien celui qu'il prétend être.