Après lecture de pas mal de documentation, voilà ma manière de faire.
Générer la clé primaire
Choisir `(8) RSA (set your own capabilities)`
Ne garder que la capacité `Certify`
Taille de clé : *4096*
Durée de vie : 2 ans maximum
Identité : Prénom Nom, pas d'adresse, commentaire : `born 1900-00-00 in Muche, France`
Générer les clés secondaires
Faire une clé par usage : *Encrypt*, *Signature* et *Authentification*
Ajouter des identités
Ajouter des adresses emails et des identités
Sélectionner `uid 3` puis `primary` et boucler pour mettre dans l'ordre
Éventuellement ajouter une photo en .jpg, chemin absolu avec `addphoto`
Créer le certificat de révocation
Ne garder que les sous-clés
Pour exporter chaque sous-clé, on ajoute simplement son KEYID avec un `!` à la fin : `KEYID!`.
Le signe `#` dans `sec#` montre que la clé primaire n'est pas dans le trousseau. N'utiliser que le fichier `KEYID.subkeys-private.asc` ou une sous-clé particulière (nécessite généralement deux sous-clés : *Encrypt* et *Signature*) dans Thunderbird, OpenKeyChain, etc., de telle sorte que même si un attaquant a accès à ces sous-clés, on pourra les révoquer.
**Note 16/11/2023 :** Thunderbird enregistre la phrase de passe de la clé privée *principale*, mais pas celle des sous-clés, même si l'on ajoute un mot de passe de session. Autrement dit, si l'on ne veut pas avoir à taper la phrase de passe à chaque fois que l'on envoie un email signé (c'est-à-dire tout le temps), il faut ou bien importer la clé privée *complète*, ou bien utiliser une saisie automatique Keepass. OpenKeyChain n'a pas ce problème avec K9 Mail puisqu'il ne signe pas les messages non-chiffrés, et qu'il permet de garder en mémoire la phrase de passe pendant un temps défini par l'utilisateur.
En cas d'urgence
Utiliser `key 2` pour sélectionner la sous-clé à révoquer puis `revkey` pour enfin `save` et republier sur le serveur.
Changer la date d'expiration
Puis `expire`, `save` et republier sur le serveur.
Publier sur le serveur
Il est également recommandé pour une première clé de la téléverser sur https://keys.openpgp.org/, de sorte de pouvoir contrôler la recherche d'identité.
Mettre en place WKD
Pour que la clé soit accessible via WKD à l'adresse `https://domain.tld/.well-known/openpgpkey/hu/HASH` il faut placer un fichier vide nommé `policy` à l'adresse `https://domain.tld/.well-known/openpgpkey/policy` puis :
Ici le hash sera `s8y7oh5xrdpu9psba3i5ntk64ohouhga` (la partie avant le @). Autre manière ne fonctionnant pas toujours (zbase32 pas dans les dépôts) :
Dernière manière : utiliser l'outil de Keyoxide.
Le contenu du fichier est juste la clé publique en `plain text` (même si la spécification exige du binaire, seul OpenPGP.js est strict là-dessus). Penser à l'exporter en version minimale (sans les signatures) :
Keyoxide exige non seulement du binaire, mais également que la première identité soit une adresse email. Pour garder la compatibilité avec Keyoxide, on devra donc placer une adresse email en principale puis :
Après coup, on peut remettre l'identité principale telle qu'elle était dans le trousseau de clé.
Ajouter la clé à une vCard
La plupart des implémentations permettent l'ajout d'une clé avec le protocole `openpgp4fpr` sous le format `openpgp4fpr:FINGERPRINT` (doc) :
Annonce de changement de clé
Pour un changement de clé, utiliser ce modèle dans un fichier `https://domain.tld/.well-known/openpgpkey/key-change.txt` :