gnupg/doc/fr/DETAILS

Format des listings "---with-colons"
====================================

sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::

 1. Champ:  Type d'enregistrement
	    pub = clef publique
	    sub = sous-clef (clef secondaire)
	    sec = clef secrète
	    ssb = sous-clef secrète (clef secondaire)
	    uid = id d'utilisateur (seul le champ 10 est utilisé)
            sig = signature
	    fpr = fingerprint: (le champ 10 est le fingerprint)
	    pkd = données publiques de la clef
		(champ au format spécial, voir ci-dessous)

 2. Champ:  Une lettre décrivant la confiance calculée. Ce n'est qu'une
	seule lettre, mais elle fera peut-être l'objet d'une information
	supplémentaire pour les versions futures, comme décrit ici
	(ceci ne sera pas utilisé pour les clefs privées)
		o = Inconnu (cette clef est nouvelle au système)
                i = La clef est invalide (eg. il manque sa propre signature)
		d = La clef a été désactivée
		r = La clef a été révoquée
		e = La clef a expiré
		q = Non-défini (pas de valeur attribuée)
		n = Ne jamais faire confiance à cette clef
		m = Cette clef dispose d'une confiance marginale
		f = Cette clef dispose d'une confiance totale
		u = Cette clef dispose d'une confiance ultime. Cette valeur
			n'est utilisée que pour les clefs où la clef secrète est
			également disponibles.
 3. Champ:  taille de la clef en bits.
 4. Champ:  Algorithme utilisé:	1 = RSA
		       16 = ElGamal (chiffrement uniquement)
		       17 = DSA (parfois appellé DH, signature seulement)
		       20 = ElGamal (signe et chiffre)
	    (pour d'autres is, consultez include/cipher.h)
 5. Champ:  ID de clef (KeyID)
 6. Champ:  Date de création (en UTC)
 7. Champ:  Date d'expiration de la clef, vide si aucune.
 8. Champ:  ID local : numéro d'enregistrement du répertoire dans la
			trustdb. Cette valeur n'est valide que tant que la
			trustdb n'est pas effacée. Vous pouvez utiliser
			"#<local-id>" comme id d'utilisateur lorsque vous spécifiez
			la clef. Ceci est requis puisque les id de clef ne sont pas
			toujours uniques - un programme peut donc utiliser ce numéro
			pour accéder aux clefs ultérieurement.
 9. Champ:  Confiance propre (clef publiques primaires uniquement)
	    C'est une simple lettre, mais une information supplémentaire pourrait
		se voir ajoutée dans les versions futures.
10. Champ:  ID utilisateur. La valeur est placée entre guillemets comme une
		chaîne en C, par exemple : "\x3a".
11. Champ:  Classe de signature. C'est un nombre hexadécimal à deux chiffres
		suivi par la lettre "x" si la signature peut être exportée ou la
		lettre "l" si la signature est uniquement locale.
12. Champ:  Capacités de la clef :
                e = chiffrement
                s = signature
                c = certification
            Une clef peut disposer de toute combinaison de ces caractéristiques.
		La clef primaire dispose, en plus de ces lettres, une version en
		majuscule des lettres pour marquer les capacités "d'utilisation"
		de la totalité de la clef.

Toutes les dates sont affichées dans le format :

yyyy-mm-dd

Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les
dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet
d'additions dans les futures versions et les parsers doivent y être préparés.
Lorsque le parser traitera ces données, il devra s'arrêter au premier
caractère non-numérique afin que des informations supplémentaires soient
ajoutées à l'avenir.

Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci :

pkd:0:1024:B665B1435F4C2 .... FF26ABB:
    !  !   !-- la valeur
    !  !------ indicateur du nombre de bits de la valeur
    !--------- index (eg. DSA va de 0 à 3 : p,q,g,y)



Format de la sortie "--status-fd"
=================================

Chaque ligne dispose d'un préfixe :

"[GNUPG:] "

Suivie par un mot clef indiquant le type de la ligne de statut,
et quelques arguments selon le type (probablement aucun) ; une application
devrait toujours assumer que des arguments supplémentaires seront
présents dans les versions futures.

    GOODSIG	<long keyid>  <username>
	La signature keyid est valide.
	Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou
	ERRSIG seront produits et ils pourront être utilisés comme
	marqueurs pour les nouvelles signatures.

    BADSIG	<long keyid>  <username>
	La signature keyid n'a pas été vérifiée correctement.

    ERRSIG  <long keyid>  <pubkey_algo> <hash_algo> \
	    <sig_class> <timestamp> <rc>
	Il n'a pas été possible de vérifier la signature. Ceci peut provenir
	d'une clef publique manquante, ou bien à cause d'un algorithme non-
	supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique
	une clef publique manquante. Les autres champs donnent plus d'information
	sur la signature. sig_class est une valeur hexadécimale de 2 octets.

    VALIDSIG	<fingerprint in hex> <sig_creation_date> <sig-timestamp>
	La signature keyid est valide. C'est ici la même chose que GOODSIG
	mais avec le fingerprint comme argument. Les lignes de statut seront
	émises pour une bonne signature.
	sig-timestamp est la date de création de la signature en secondes
	depuis Epoch.

    SIG_ID  <radix64_string>  <sig_creation_date>  <sig-timestamp>
	N'est émis que pour les signatures de classe 0 ou 1 qui ont été
	vérifiées comme valides. Le chaîne est un identifiant d'utilisateur
	et peut être utilisée dans les applications pour détecter les
	attaques par rejeu de messages signés. Notez que seuls les
	algorithmes DLP offrent des identifiants uniques ; les autres peuvent
	produire des id dupliqués lorsqu'ils furent créés à la même seconde.

    ENC_TO  <long keyid>  <keytype>  <keylength>
	Le message est chiffré avec ce keyid.
	keytype est une valeur numérique de l'algorithme à clef publique,
	keylength est la taille de la clef ou 0 si elle n'est pas connue
	(ce qui est toujours le cas).

    NODATA  <what>
	Aucune donnée n'a été trouvée. Les codes suivants sont utilisés :
	    1 - Pas de données sous ARMOR.
	    2 - Un paquet attendu n'a pas été trouvé.
	    3 - Paquet invalide trouvé ; ceci peut indiquer un message
		non-OpenPGP. Vous devez vous attendre à une extension
		de ces lignes de statu à l'avenir.

    UNEXPECTED <what>
        Des données innatendues ont été rencontrées
            0 - pas de détail supplémentaire

    TRUST_UNDEFINED
    TRUST_NEVER
    TRUST_MARGINAL
    TRUST_FULLY
    TRUST_ULTIMATE
	Pour les signatures valides, l'une de ces lignes de statut sera produite
	pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments
	pour l'instant.

    SIGEXPIRED
	La clef de signature a expiré. Pas d'arguments pour l'instant.

    KEYREVOKED
	L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant.

    BADARMOR
	L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant.

    RSA_OR_IDEA
	Les algorithmes IDEA ont été utilisés sur les données. Un programme
	pourra basculer sur un autre programme de traitement si GnuPG échoue.
	Ce message de statut sera affiché pour le RSA aussi, mais ceci a été
	abandonné puisque le brevêt sur le RSA a expiré.
	Toutefois, nous ne pouvons modifier le nom du message.

    SHM_INFO
    SHM_GET
    SHM_GET_BOOL
    SHM_GET_HIDDEN

    GET_BOOL
    GET_LINE
    GET_HIDDEN
    GOT_IT

    NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
	Sera affiché à chaque fois qu'une phrase passe sera requise.
	keytype est la valeur numérique de l'algorithme à clef publique
	ou bien 0 si cela n'est pas applicable. keylength est la taille de la
	clef ou 0 si la taille n'est pas connue (ceci est actuellement
	toujours le cas).

    NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
	Affiché à chaque fois qu'une phrase passe pour un chiffrement
	symétrique sera requise.

    MISSING_PASSPHRASE
	Aucune phrase passe n'a été fournie. Une application qui rencontre
	ce message devrait stopper immédiatement le parsing car le prochain
	message sera probablement BAD_PASSPHRASE. Toutefois, si l'application
	n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs,
	ceci pourrait avoir un autre sens et stopper le parsing pourrait
	être incorrect, et il faudra ignorer le BAD_PASSPHRASE.

    BAD_PASSPHRASE <long keyid>
	La phrase passe fournie est soit invalide, soit n'a pas été fournie.
	Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE.

    GOOD_PASSPHRASE
	La phrase passe fournie est valide et le matériel de clefs secrète
	est utilisable.

    DECRYPTION_FAILED
	La déchiffrement symétrique a échoué. Il s'agit généralement d'une
	mauvaise phrase passe ne correspondant pas au message chiffré.

    DECRYPTION_OKAY
	Succès du déchiffrement. Ceci signifie que soit la clef secrète
	adaptée a été utilisée avec succès, soit que la phrase passe
	valide pour un chiffrement symétrique aura conduit au déchiffrement.
	Le programme pourait toutefois renvoyer un message d'erreur s'il
	n'a pas été possible de vérifier la signature.

    NO_PUBKEY  <long keyid>
    NO_SECKEY  <long keyid>
	La clef n'est pas utilisable.

    IMPORTED   <long keyid>  <username>
	Le keyid et la signature ont été importés.

    IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
	<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
	Statistiques finales sur le processus d'importation (cette ligne est longue!)

    FILE_START <what> <filename>
	Début de traitement du fichier <filename>. <what> indique l'opération
	réalisée :
	    1 - vérifier

    FILE_DONE
	Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START.

    BEGIN_DECRYPTION
    END_DECRYPTION
	Marque le début et la fin du processus de déchiffrement. Ces messages
	seront également produits lors de l'utilisation du mode --list-only.

    BEGIN_ENCRYPTION
    END_ENCRYPTION
	Marque le début et la fin du processus de chiffrement.

    DELETE_PROBLEM reason_code
	L'effacement d'une clef a échoué. Un code indique la raison de l'erreur :
	    1 - La clef spécifiée n'existe pas
	    2 - La clef privée doit être détruite avant !

    PROGRESS what char cur total
	Utilisé par les fonctions primegen et de clef publique pour indiquer
	la progression de l'opération. "char" est le caractère affiché sans
	--status-fd avec les retours à la ligne marqués par "X". "cur" indique
	la quantitité de traitement terminée et "total" indique la valeur
	finale à atteindre. Un total de 0 indique que le total n'est pas
	connu. 100/100 peut être utilisé pour détecter la fin de l'opération.

    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
	Une signature a été créée à l'aide de ces paramètres.
	    type:  'D' = détachée
		   'C' = en texte clair
		   'S' = standard
		   (seul le premier caractère doit être vérifié)
	    class: 2 chiffres hexadécimaux avec la classe de signature
        
    KEY_CREATED <type>
        Une clef a été créée
            type: 'B' = primaire et sous-clef
                  'P' = primaire
                  'S' = sous-clef

    SESSION_KEY  <algo>:<hexdigits>
	La clef de session utilisée pour déchiffrer le message. Ce message
	sera seulement affiché si l'option --show-session est utilisée.
	Le format est utilisable pour un passage direct à la fonction
	--override-session-key.

    NOTATION_NAME <name> 
    NOTATION_DATA <string>
	Le nom et la chaîne sont "escaped" à l'aide de %XX et les données
	peuvent être découpées sur plusieurs lignes notation_data.

    USERID_HINT <long main keyid> <string>
	Donne un indice sur l'ID utilisateur pour un keyID donné.

    POLICY_URL <string>
	La chaîne est "escaped" en %XX

    BEGIN_STREAM
    END_STREAM
	Produit par pipemode.


Génération de clef
==================

La génération de clef marque sa progression à l'aide de différents caractères, dont
voici la signification :

"." : les 10 derniers tests Miller-Rabin ont échoué.
"+" : réussite du test Miller-Rabin.
"!" : Rechargement du pool avec des nombres premiers frais.
"^" : Vérification d'une nouvelle valeur pour le générateur.
"<" : La taille d'un facteur a été réduite.
">" : La taille d'un facteur a été augmentée.

Le nombre premier pour l'ElGamal est généré de la manière suivante :

1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille
	de la clef).
2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit
	au moins de la taille de q et on calcule le nombre de facteurs premiers
	requis.
3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée
	à l'étape 2.
4. On obtient une nouvelle permutation du pool et nous continuons avec
	l'étape 3 une fois toutes les permutations testées.
5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1
6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer
	q s'il ne semble pas possible de produire un premier de la taille voulue)
7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par
	le test de Miller-Rabin.
8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7.
9. On trouve un générateur pour ce premier.

Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260).

Génération de clef innatendue
=============================

Cette fonction est actuellement expérimentale et permet la production de
clefs innatendues avec un contrôle depuis un fichier de paramètres.
Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne
PAS vous plaindre si nous décidons d'apporter des modifications importantes
à cette commande.

Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en
combinaison avec --batch et fournir les paramètres soit depuis stdin,
soit depuis un fichier dont le nom est fourni en ligne de commande.

Ce fichier devra utiliser le format suivant :

 o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères.
 o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII.
 o Les lignes vides seront ignorées.
 o Les espaces en début et fin de ligne seront ignorés.
 o Un signe "-" en tant que premier caractère "non white space" marque
	une ligne de commentaire.
 o Les commandes sont marquées par un signe "%" en début de ligne,
	suivi par la commande et ses arguments sont séparés par des espaces.
 o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les
	arguments sont séparés par des espaces.
 o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent
	être placés à votre discrétion.
 o La génération de clef aura lieu soit à la fin du fichier de paramètres,
	soit lorsque le premier "Key-Type" est rencontré au sein du fichier,
	dans un ensenble de contrôle "%commit".
 o Les ensembles de contrôle sont :
	%echo <texte>
	Affiche <texte>

	%dry-run
	Ne réalise pas la production de clef (pratique pour vérifier la
	syntaxe).

	%commit
	Réalise la production de clef. Un commit implicite est produit
	à chaque rencontre de "Key-Type".

    %pubring <filename>
    %secring <filename>
	Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
	indiqué en ligne de commande, mais vers le fichier <filename>. Ce
	contrôle doit être utilisé avant que le commit ne soit rencontré.	
	Toute double mention sera ignorée et le dernier nom de fichier
	rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce
	qu'un nouveau fichier soit spécifié (au points de commit) sinon
	toutes les clefs seront placées dans le même fichier. Si un nouveau
	nom de fichier est indiqué, le fichier sera créé (et tout ancien
	fichier sera alors écrasé). Les deux indications doivent être
	fournies au contrôle.

 o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui
	doit être le premier paramètre rencontré. Les paramètres ne sont
	destinés qu'au bloc keybloc généré et les paramètres des productions
	précédentes de clefs ne seront pas pris en compte. Certaines
	vérifications syntaxiques seront mises en place et peuvent être
	ou non actives. Les paramètres actuellement définis sont :

     Key-Type: <algo-number>|<algo-string>
	Débute un nouveau bloc de paramètres indiquant le type de la clef
	primaire à produire. L'algorithme doit être capable de produire
	des signatures. Ce paramètre est indispensable !

     Key-Length: <length-in-bits>
	Indique la taille de la clef, en bits. La valeur par défaut est
	1024.

     Subkey-Type: <algo-number>|<algo-string>
	Permet de produire une clef secondaire. Actuellement, seule une
	sous-clef peut être gérée.

     Subkey-Length: <length-in-bits>
	Taille de la sous-clef en bits. La valeur par défaut est
	1024.

     Passphrase: <string>
	Si vous souhaitez spécifier une phrase passe pour la clef
	secrète vous pouvez utiliser cette commande. Par défaut,
	aucune phrase passe ne sera associée aux clefs privées.

     Name-Real: <string>
     Name-Comment: <string>
     Name-Email: <string>
	Voici les trois composantes d'une clef. Vous devez ici
	n'utiliser que de l'UTF-8. Si vous ne fournissez aucune
	de ces indications, aucun ID d'utilisateur ne sera créé.

     Expire-Date: <iso-date>|(<number>[d|w|m|y])
	Spécifie la date d'expiration de la clef (et de sa sous-clef)
	La date doit être entrée sous la forme d'une date au format
	ISO (année-mois-jour) ou bien sous forme d'un nombre de
	jours, de semaines, de mois ou d'années. Si vous n'utilisez
	pas de lettre pour indiquer la durée, des "jours" sont
	assumés par défaut.

Voici un exemple :
$ cat >foo <<EOF
     %echo Génération d'une clef standard
     Key-Type: DSA
     Key-Length: 1024
     Subkey-Type: ELG-E
     Subkey-Length: 1024
     Name-Real: Joe le testeur
     Name-Comment: ma phrase passe est stupide
     Name-Email: joe@foo.bar
     Expire-Date: 0
     Passphrase: abc
     %pubring foo.pub
     %secring foo.sec
     # Un commit est requis ici, pour pouvoir afficher un "done" :-)
     %commit
     %echo done
EOF
$ gpg --batch --gen-key -a foo
 [...]
$ gpg --no-default-keyring --secret-keyring foo.sec \
				  --keyring foo.pub --list-secret-keys
/home/wk/work/gnupg-stable/scratch/foo.sec
------------------------------------------
sec  1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <joe@foo.bar>
ssb  1024g/8F70E2C0 2000-03-09



Composition de la TrustDB
=========================

La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier
octet décrit le type d'enregistrement. Toutes les valeurs numériques sont
conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement
est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1
et c'est le seul enregistrement de ce type.

  Record type 0:
  --------------

	Cet enregistrement n'est pas utilisé. Il peut être utilisé
	à votre discrétion.

  Record type 1:
  --------------

	Indique la version de la TrustDB. Cet enregistrement doit toujours être
	le premier enregistrement de la base de données et c'est le seul
	enregistrement de type 1.

     1 octet valeur : 1
     3 octets 'gpg'  valeur "magic"
     1 octet Version de la TrustDB (2)
     1 octet marginales requises
     1 octet complètes requises
     1 octet max_cert_depth

	Ces trois éléments sont utilisés pour vérifier si la valeur de validité
	mise en cache dans l'enregistrement du répertoire peut être utilisée :

     1 u32  locked flags
     1 u32  datation de la création de la trustdb
     1 u32  datation de la dernière modification

	Cette datation pourrait affecter la validité des clefs dans la base de
	données. Cette valeur sera comparée à celle de la datation de validité
	des enregistrements dir :

     1 u32  datation de la dernière validation

	Cette valeur sera utilisée pour stocker le passage du temps, lorsque
	cette TrustDB sera comparée au trousseau de clefs publiques :

     1 u32  numéro de l'enregistrement du keyhashtable
     1 u32  premier enregistrement libre
     1 u32  numéro de l'enregistrement répertoire shadow de la table de hachage

	Cette table ne devrait pas être combinée avec la table de clefs car le
	keyid n'est pas dans chaque cas un élément du fingerprint.

     4 bytes réservés pour l'enregistrement d'extension de version


  Record type 2: (enregistrement répertoire)
  --------------

	Regroupe les informations sur un certificat de clef publique.
	Ces valeur sont statiques et ne sont jamais modifiées sans une
	interaction avec l'utilisateur :

     1 octet valeur : 2
     1 octet  réservé
     1 u32   LID     .	(numéro d'enregistrement de cet enregistrement)
     1 u32   Liste de key-records (le premier est la clef primaire)
     1 u32   Liste de uid-records
     1 u32   cache record
     1 octet  ownertrust
     1 octet  dirflag
     1 octet  validité maximale de tous les id utilisateurs
     1 u32   datation de la dernière vérification de validité
     1 u32   Vérification requise lorsque cette datation sera atteinte
	     (0 = pas de vérification requise)


  Record type 3:  (enregistrement de clef)
  --------------

	Regroupe les informations sur une clef publique primaire.
	(ces informations sont principalement utilisées pour réaliser les lookup
	dans l'enregistrement trust)

     1 octet valeur : 3
     1 octet  réservé
     1 u32   LID
     1 u32   next   - prochain enregistrement
     7 octets réservés
     1 octet  keyflags
     1 octet  algorithme de la clef publique
     1 octet  taille du fingerprint (en octets)
     20 octets fingerprint de la clef publique
	      (Cette valeur est utilisée pour identifier toute clef)

  Record type 4: (enregistrement uid)
  --------------

	Regroupe les informations sur un id utilisateur (un "uid").
	Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire.

     1 octet valeur : 4
     1 octet réservé
     1 u32  LID  pointe vers l'enregistrement directory
     1 u32  next   le userid suivant
     1 u32  pointeur vers l'enregistrement preference
     1 u32  siglist  liste de signatures valides
     1 octet uidflags
     1 octet validité de la clef calculée pour cet userid
     20 bytes ripemd160 hachage du nom de l'utilisateur


  Record type 5: (enregistrement pref)
  --------------

	Regroupe les informations formant les préférences.

     1 octet valeur : 5
     1 octet   réservé
     1 u32  LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!)
	    (égal à 0 pour un enregistrement de préférences standard)
     1 u32  suivant
     30 byte données de préférences

  Record type 6  (sigrec)
  -------------

	Cet enregistrement est utilisé pour traquer les signatures de clefs. Les
	auto-signatures ne sont pas conservées. Si une clef publique ne se trouve
	pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme,
	lequel contient une liste des enregistrements qui seraient intéressés
	par cette clef (et l'enregistrement signature en fait partie).

     1 octet   valeur : 6
     1 octet   réservé
     1 u32    LID	    pointe en retour vers l'enregistrment dir
     1 u32    next   prochain sigrec de cet uid ou bien 0 pour indiquer que ce
					sigrec est le dernier.
     6 times
	1 u32  Local_id des dir signatures ou de l'enregistrement dir fantôme
	1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un
				véritable enregistrement directory)
			 1 = valide est vrai (mais pourrait être révoqué)



  Record type 8: (enregistrement répertoire (dir) fantôme)
  --------------

	Cet enregistrement est utilisé pour réserver un LID pour une clef publique.
	Nous avons besoin de cet enregistrement pour créer les enregistrements sigs
	des autres clefs, même si nous ne disposons pas d'une signature de la clef
	publique.
	Cet enregistrement (le numéro d'enregistrement pour être plus précis)
	sera réutilisé dans l'enregistrement dir lorsque nous importerons la
	véritable clef publique.

     1 octet valeur : 8
     1 octet  réservé
     1 u32   LID      (Ceci est simplement le numéro d'enregistrement de ce record.)
     2 u32   keyid
     1 octet  algorithme de la clef publique
     3 octets réservé
     1 u32   hintlist

	hintlist contient la liste des enregistrements qui ont des références qui pointent
	vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès
	des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces
	données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels	
	pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le
	code du programme saura prendre soin de tout cela.

    18 octets réservés



  Record Type 10 (table de hachage)
  --------------

	Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons
	implémenter un accès rapide en utilisant des méthodes de hachages simples,
	afin d'éviter une surcharge de gdbm. La propriété des fingerprint
	est qu'ils permettent un usage direct en tant que valeurs hachées (ils
	peuvent être considérés comme des nombres aléatoires cryptographiquement
	forts).
	Nous utilisons une architecture à multiples niveaux dynamique, qui combine
	les tables de hachage, les listes d'enregistrements et les listes
	chaînées.

	Cet enregistrement est une table de hachages de 256 entrées ; une propriété
	spéciale est que tous les enregistrements sont stockés consécutivement
	pour produire une grande table. La valeur hachée est simplement le 1er,
	2nd.. octet du fingerprint (selon le niveau d'indirection).

	Lorsque nous les utilisons pour hacher les enregistrements de répertoires
	shadow, une différente table est utilisée, et elle se trouve indexée
	par le keyid.

     1 octet valeur : 10
     1 octet réservé
     n u32  recnum; n dépend de la taille de l'enregistrement :
	    n = (reclen-2)/4  ce qui donne 9 pour la taille actuelle
		d'enregistrement de 40 octets.

	Le nombre total de ces enregistrements constituant la table est :

	 m = (256+n-1) / n

	ce qui donne 29 pour une taille d'enregistrement de 40.

	Pour rechercher une clef, nous utilisons le premier octet du fingerprint
	pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement
	adressé :

	o Si cet enregistrement est une autre table de hachage, nous pouvons
	utiliser le second octet pour indexer cette table de hachage et continuer.

	o Si cet enregistrement est une liste de hachages, nous pouvons parcourir
	toutes les entrées jusqu'à trouver la bonne.

	o Si cet enregistrement est un enregistrement de clef, nous comparons
	le fingerprint avec celui recherché et nous déterminons s'il s'agit
	de la clef recherchée.



  Record type 11 (liste hachée)
  --------------

	Consultez la table hachée pour une explication.
	Ceci sera également utilisé à d'autres fins.

    1 octet valeur : 11
    1 octet réservé
    1 u32  next 	 enregistrement de liste hachée suivant
    n times		 n = (reclen-5)/5
	1 u32  recnum

	Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7.




  Record type 254 (enregistrement libre)
  ---------------

Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés.

     1 octet  valeur 254
     1 octet  réservé (0)
     1 u32   next_free



En-têtes de paquets
===================

GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre
les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens
en-têtes de paquets :

Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées
dans la table suivante :

      00 - 1-octet champ packet-length
      01 - 2-octets champ packet-length
      10 - 4-octets champ packet-length
      11 - pas de taille de paquet fournie, taille inconnue

Comme indiqué dans cette table, selon la taille du packet-length les
octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont
un "champ packet-length". Ce champ est une valeur numérique à part entière.
La valeur du champ packet-length est définie par la valeur de la
totalité du champ numérique.

La valeur 11 est actuellement utilisée dans un cas : les données
compressées. C''est à dire qu'un bloc de données compressées
ressemble à : <A3 01 .. .. > où A3 est le binaire "10 1000 11" et
produit ici un paquet de taille non-définie. L'interprétation
correcte en est : "jusqu'à la fin de la structure englobante"
bien qu'en fait la structure englobante soit généralement
le fichier.

+ Ceci sera modifié dans une future version, où la signification de la
+ valeur 11 (voir ci-dessous) aura aussi sa place.
+
+ Une valeur de 11 pour d'autres paquets active un codage spécial
+ de la taille, où la taille du paquet suivant ne pourra pas être
+ déterminée avant l'écriture du paquet, en particulier ceci sera
+ utilisé si de grande quantités de données sont à traiter dans
+ un mode filtre.
+
+ Ceci fonctionne de la manière suivante : après le CTB (qui est un
+ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera
+ alors la taille du bloc de données suivant. C'est un simple champ
+ de deux octets (MSB en premier) contenant la quantité de données qui
+ suivent le champ, sans inclure le champ de taille toutefois. Après
+ ce bloc de données un autre champ de taille suivra, qui donnera la taille
+ du bloc de données suivant. Une valeur de 0 indique une fin de paquet.
+ La taille maximale d'un bloc de données est limitée à 65534, ce qui
+ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de
+ taille devront être insérés dans le flux de données avant que les
+ données ne soient envoyées en sortie.
+
+ Ce champ de deux octets est largement suffisant, car l'application
+ doit placer en tampon cette quantité de données pour précéder le
+ marqueur de taille avant de produire une sortie. Les blocs de données
+ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra
+ également être utilisé pour les flux de données compressées, mais
+ nous devrons alors utiliser une autre version de paquet afin de dire à
+ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet.


Extensions GNU à l'algorithme S2K
=================================

Le S2K mode 101 est utilisé pour identifier ces extensions.
Après l'algorithme de hachage les trois octets "GNU" sont utilisés
pour indiquer clairement qu'il s'agit d'extensions GNU et les octets
qui suivent donnent le mode de protection GNU utilisé : 1000. Les
modes définis sont :

  1001 - ne pas conserver du tout de partie secrète



Usage des fichiers gdbm pour les trousseaux de clefs
====================================================

La clef utilisé pour stocker le keyblock est son propre fingerprint,
les autres enregistrements sont utilisés pour les clefs secondaires.
Les fingerprint font toujours 20 octets où 16 bits de fingerprint
sont suivis par 0. Le premier octet de chaque clef indique une
information sur le type de clef :

      1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0)
	  les données sont le keyblock
      2 = la clef est un keyid complet de 8 octets
	  les données sont une liste de 20 octets fingerprints
      3 = la clef est un keyid court de 4 octets
	  les données sont une liste de 20 octets fingerprints
      4 = la clef est une adresse email
	  les données sont une liste de 20 octets fingerprints

	Les données sont pre-appended (précédées) par un octet de type :

      1 = keyblock
      2 = liste de 20 octets fingerprints "paddés"
      3 = liste de liste de fingerprints ("but how to we key them?")



Pipemode
========

Ce mode est utilisé pour réaliser des opérations multiples avec un
unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier
un grand nombre de signatures. Actuellement nous n'avons qu'un support
des signatures détachées. Ce mode est une astuce qui permet d'éviter
de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain
Sockets pour lui faire passer les données. Il n'existe aucun moyen
pratique de portabilité de ce concept sous Windows, alors nous utilisons
des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous
n'avons aucun moyen de signaler des EOF multiples dans un pipe nous
devons laisser le contrôle s'insérer dans le flux de données lui-même.
Nous réalisons alors une distinction entre les données du flux et un
état de contrôle. A son lancement, le système se trouve dans un état
de données mais n'acceptera aucune donnée. Il attend en fait une
transition vers un mode de contrôle qui s'obtient en envoyant un simple
caractère '@'. Une fois dans le mode de contrôle, des commandes sont
attendues et ces commandes sont à un octet après lequel le système
revient au mode de données (mais cela n'implique pas qu'il acceptera
des données immédiatement). La commande de contrôle la plus simple
est '@' qui permet d'insérer ce caractère dans le flux de données.

Voici le format que nous utilisons pour les signatures détachées :

"@<"  - Début d'un nouveau flux
"@B"  - La signature détachée suit.
        Ceci émet le paquet de contrôle (1,'B')
<detached_signature>
"@t"  - Le texte signé suit. 
        Ceci émet le paquet de contrôle (2, 'B')
<signed_text>
"@."  - Fin de l'opération. Le paquet de contrôle final force la
	vérification de la signature.
"@>"  - Fin du flux.



Autres notes
============

Dans la version* 3 de version de paquet nous calculons les keyid de cette manière :

RSA : les 64 bits de poids faible de n
ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99)
	et nous calculons une valeur hachée rmd160 à partir de ce paquet.
	Il est utilisé comme fingerprint avec les 64 bits de poids faible
	qui produisent le keyid.

* Les certificats de révocation ne comportent qu'un paquet de signature ;
"import" sait comment traiter ces paquets. L'idée derrière ce principe
est de conserver une petite taille de paquet.



Format des messages Keyserver
=============================

Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP.

Le format des requêtes est :

====
command-tag
"Content-length:" digits
CRLF
=======

Où le command-tag est :

NOOP
GET <user-name>
PUT
DELETE <user-name>


Le format de réponse utilisé est :

======
"GNUPG/1.0" status-code status-text
"Content-length:" digits
CRLF
============

suivi par <digits> octets de données.


Les codes de statut utilisés sont :

     o	1xx: Information: requête reçue, traitement en cours.

     o	2xx: Succès - L'action a été reçue, comprise et acceptée.

     o	4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe
		ou demande irréalisable.

     o	5xx: Erreur serveur - Le serveur n'a pu traiter une demande
		qui semble valide.


Documentation sur HKP (le protocol de serveurs de clefs http)
=============================================================

Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET
pour /pks/lookup. Les paramètres standard encodés URL de la requête
sont toujours ceux-ci : (toujours key=valeur)

- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme
  pgp -kxa)

- search=<stringlist>. Nous avons ici une liste de mots qui doivent
	apparaître dans la clef. Ces mots sont séparés par des espaces,
	points, @, etc. Les délimiteurs ne feront pas partie de la
	recherche et l'ordre des mots n'a aucune importance (mais consultez
	l'option suivante).

- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit
	rechercher que les correspondances exactes. Dans ce cas, les
	délimiteurs et l'ordre des mots sera considéré.

- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé
	avec 'index' ou 'vindex'

Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add.
Vous utilisez ceci pour envoyer des clefs au serveur.

Le mieux pour produire une requête reste :

   /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>

Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd.
Toutefois, nous pensons que les traitements du serveur de clef doivent
faire l'objet d'une refonte.