Signature de paquets (marqueur 2)

Un paquet de signature décrit les liens entre une clé publique et des données. Les signatures les plus communes sont les signatures de fichier ou d'un bloc de texte, et les signatures certifiant l'identité de l'utilisateur [user ID].

Deux versions de signatures de paquets sont définies. La version 3 fournit des informations de base sur la signature, tandis que la version 4 fournit un format extensible avec des sous-paquets qui peuvent donner plus d'informations au sujet de la signature. PGP 2.6.x accepte seulement les signatures de version 3.

Toutes les implémentations DOIVENT accepter les signatures de version 3. Les implémentations DEVRAIENT pouvoir générer des signatures de version 4. Les implémentations PEUVENT générer une signature de version 3 qui est en mesure d'être vérifiée par PGP 2.6.x.

Remarquons que si une implémentation crée un message crypté et signé, crypté avec une clé V3, il est raisonnable de créer une signature V3.

Types de signatures

Une signature peut avoir plusieurs sens; ce sens est défini dans l'octet du type de la signature et ce dans n'importe quelle signature. Les sens possibles sont les suivants :

0x00

Signature d'un document binaire. La caractéristique de cette signature est qu'elle signifie que le document appartient au signataire, que ce dernier l'a créée ou qu'il certifie qu'il n'a pas été modifié.

0X01

Signature d'un texte de base. La caractéristique de cette signature est qu'elle signifie que le document appartient au signataire, que ce dernier l'a créé ou qu'il certifie qu'il n'a pas été modifié. La signature est calculée sur les données du texte avec conversion en < CR > < LF > des fins de lignes et suppression des blancs de fin de mots.

0x02

Signature autonome. Cette signature signe seulement le contenu de son sous-paquet. Elle est calculée de la même manière qu'une signature pour un document binaire de longueur nulle. Remarquez qu'il est absurde d'avoir une signature autonome de version 3.

0x10

Certification générique d'un identifiant utilisateur et d'un paquet de clé publique. L'utilisateur de cette certification ne donne aucune assurance particulière qu'une vérification sérieuse a été faite pour voir si le propriétaire de la clé est bien la personne décrite dans l'identifiant utilisateur [user ID]. Remarquez que toutes <<  les signatures de clés  >> PGP possèdent ce type de certification.

0x11

Certification casuelle d'un ID utilisateur et d'un paquet de clé publique. L'utilisateur de cette certification n'a effectué aucune vérification de l'affirmation donnant le possesseur de cette clé comme l'ID utilisateur spécifié.

0x12

Certification casuelle de l'ID utilisateur et du paquet de clé publique. L'utilisateur de cette certification a effectué quelques vérifications casuelle de la déclaration d'identité.

0x13

Certification positive de l'ID utilisateur et du paquet de clés publiques. L'utilisateur de cette certification a effectué des vérifications substantielles de la déclaration d'identité.

0x18 : Signature correspondant à la sous-clé

La signature est un signalement fait par la clé de haut niveau signataire indiquant que la sous-clé lui appartient. Cette signature est calculée directement sur la sous clé elle-même, et non sur aucun autre ID utilisateur ou autre sous-paquets.

0x1F : Signature directe sur une clé

Cette signature est calculée directement sur une clé. Elle fait correspondre les informations contenues dans le sous-paquets de clé avec la clé, et elle s'utilise de manière appropriée pour les sous-paquets qui fournissent des informations à propos de la clé, comme les sous-paquets de clé de révocation. Son utilisation est également appropriée pour les statuts que les certificateurs veulent effectuer au sujet de la clé elle-même, au lieu de la correspondance entre une clé et un nom.

0x20 : Signature de révocation de clé

La signature est calculée directement sur la clé en train d'être révoquée. Une clé révoquée n'est pas supposée être utilisée. Seules les signatures de révocations de la clé en train d'être révoquée, ou pour une révocation de clé autorisée, peuvent être considérées comme des signatures de révocation valides.

0x28 : Signature de révocation de sous-clé

La signature est calculée directement sur la sous-clé en cours de révocation. Une sous-clé révoquée ne doit pas être utilisée. Seules les signatures de révocation par les clés de signatures de haut niveau qui sont attachées à cette sous-clé, ou par une clé de révocation autorisée, doivent être considérées comme des signatures de révocation valide.

0x30 : Signature de révocation de sous-clé

La signature révoque une signature de certification d'ID utilisateur précédente (les signatures de la classe 0x10 à 0X13). Elle doit être issue de la même clé que celle qui est issue de la signature de révocation ou d'une clé de révocation autorisée. La signature doit avoir une date de création plus ancienne que celle de la signature qu'elle révoque.

0x40 : Signature de temps

Cette signature n'a de sens que pour la référence de temps qu'elle contient.

Format d'un paquet de signature version 3

Le corps d'un paquet de signature version 3 contient :

Champs spécifiques à l'algorithme pour les signatures de type RSA :

Champs spécifiques à l'algorithme pour les signatures de type DSA :

Le calcul de la signature est basé sur un hachage des données signées, comme décrit ci-dessous. Les détails des calculs pour les signatures DSA sont différents de ceux des RSA.

Pour les signatures RSA, la valeur hachée est codée comme décrit dans la section 10.1.2 de PKCS-1 nommée << Codage des données >>, en produisant une valeur ASN.1 de type DigestInfo, et ensuite étoffée en utilisant des blocs PKCS-1 de type 01 [RFC2313]. Cela nécessite l'insertion de la valeur hachée comme chaîne d'octets dans une structure ASN.1. L'identifiant d'objet pour le type de hachage utilisé est inclus dans la structure. Les représentations hexadécimales pour les algorithmes de hachage définis ici sont :

Les OID ASN.1 sont :

Les préfixes complets de hachage pour ces derniers sont :

MD2:

0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, 0x04, 0x10

MD5:

0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 0x10

RIPEMD-160:

0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14

SHA-1:

0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14

Les signatures DSA DOIVENT utiliser des hachages d'une taille de 160 bits, pour correspondre à q, la taille du groupe généré par la valeur de générateur de la clé DSA. Le résultat de la fonction de hachage est traitée comme un nombre de 160 bits et utilisé directement dans l'algorithme de signature DSA.

Format de la version 4 de la signature de paquet

Le corps d'un paquet de signature version 4 contient :

Les données en train d'être hachées sont signées, puis les données de signature depuis le numéro de version jusqu'au sous-paquet de données hachées (inclus) sont hachées. La valeur de hachage qui en résulte est signée. Les 16 bits de gauche du hachage sont inclus dans le paquet de signature pour fournir un test rapide pour rejeter les signatures invalides.

Il y a deux champs constitués de sous-paquets de signature. Le premier champs est haché et contient le reste des données de signature, tandis que le second n'est pas haché. Le second ensemble de sous-paquets n'est pas protégé de manière cryptographique par la signature et ne doit inclure que des renseignements.

Les algorithmes pour la conversion en signature du résultat de la fonction de hachage sont décrits un peu plus bas.

Spécifications des sous-paquets de signature

Les champs de sous-paquets consistent en aucun ou plusieurs sous-paquets de signature. Chaque ensemble de sous-paquets est précédé par un compteur scalaire de deux octets de la grandeur de l'ensemble des sous-paquets.

Chaque sous-paquet comporte un en-tête de sous-paquet et un corps. L'en-tête comporte :

  • La longueur de sous-paquet (1, 2 ou 5 octets)

  • Le type de sous-paquet (1 octet)

et est suivie par les données spécifiques au sous-paquet.

La longueur inclut l'octet de type mais pas cette longueur. Son format est similaire aux longueurs d'en-tête de paquet dans le << nouveau >> format, mais ne peut pas avoir de longueurs de corps partielles. C'est à dire :
	    si le premier octet < 192, alors
	    longueurDeLongueur = 1
	    LongueurDeSousPaquet = premier_octet

	    si le premier octet >= 192 et < 255, alors
	    longueurDeLongueur = 2
	    LongueurDeSousPaquet = ((premier_octet - 192) << 8) + (second_octet) + 192

	    si le premier octet = 255, alors
	    longueurDeLongueur = 5
	    LongueurDeSousPaquet = [scalaire de quatre octets commençant au second_octet]
	  
La valeur de l'octet de type de sous-paquet peut être :

  • 2 = heure de la création de la signature

  • 3 = heure d'expiration de la signature

  • 4 = certification exportable

  • 5 = signature de confiance

  • 6 = expression normale

  • 7 = révocable

  • 9 = temps d'expiration de clé

  • 10 = maintien de position pour rester compatible avec les anciennes versions

  • 11 = algorithmes symétriques préférés

  • 12 = clé de révocation

  • 16 = Identifiant de la clé de l'expéditeur/ de l'émetteur

  • 20 = données de notation

  • 21 = algorithmes de hachage préférés

  • 22 = algorithmes de compression préférés

  • 23 = préférences du serveur de clés

  • 24 = serveur de clés préféré

  • 25 = identifiant utilisateur primaire

  • 26 = politique de gestion des URL

  • 27 = paramètres de clé

  • 28 = identifiant utilisateur du signataire

  • 29 = raison de la révocation

  • 100 à 110 = interne ou défini par l'utilisateur

Une implémentation DOIT ignorer tous les sous-paquets de type inconnu.

Le bit 7 du type de sous-paquet est le bit << critique >>. S'il est positionné, il informe que le sous-paquet fait partie de ceux qu'il est primordial pour l'évaluateur de la signature de reconnaître. Si un sous-paquet signalé comme critique se présente mais n'est pas reconnu par le programme d'évaluation, l'évaluateur DOIT considérer la signature comme erronée.

Un évaluateur peut << reconnaître >> un sous paquet , mais ne pas l'implémenter. Le but du bit critique est de permettre au signataire d'avertir l'évaluateur qu'il préférerait une autre caractéristique inconnu pour générer une erreur que d'être ignorée.

Les implémentations DOIVENT implémenter les << préférences >>.

Types de sous paquets de signatures

Un nombre de sous-paquets est couramment défini. Certains sous-paquets s'appliquent à la signature elle-même et d'autres sont des attributs de la clé. Les sous-paquets trouvés sur une auto-signature sont placés sur une certification d'identifiant utilisateur effectuée par la clé elle-même. Remarquez qu'une clé peut avoir plus d'un identifiant utilisateur, et dans ce cas peut avoir plus d'une auto-signature, et des sous-paquets différents.

Une auto-signature est une signature de liaison faite par la clé à laquelle la signature se réfère. Il y a trois types d'auto-signatures, les signatures de certification (types 0x10-0x13), les signatures de clés direct (type 0x1F), et les signatures de liaison de sous clé (type 0x18). Pour les auto-signatures de certification, chaque identifiant utilisateur peut posséder une auto-signature, et donc des sous-paquets différents dans ces auto-signatures. Pour les signatures de liaison de sous-clé, chaque sous-clé possède, en fait, une auto-signature. Les sous-paquets qui apparaissent dans une auto-signature de certificat s'applique au nom d'utilisateur, et les sous-paquets qui apparaissent dans l'auto-signature de la sous-clé s'applique à la sous-clé. Enfin, les sous-paquets sur la signature de clé directe s'applique à la clé entière.

Les programmes implémentés doivent interpréter les sous-paquets de préférences d'auto-signature aussi rigoureusement que possible. Par exemple, supposons qu'une clé a deux noms d'utilisateurs, Alice et Bob. Supposons qu'Alice préfère l'algorithme symétrique CAST5, et Bob préfère l'IDEA ou le Tripple-DES. Si le programme repère cette clé par le biais du nom d'Alice, dans ce cas l'algorithme préféré est CAST5, si le programme trouve la clé grâce au nom de Bob, alors l'algorithme préféré est IDEA. Si la clé est repérée par l'identifiant de clé, l'algorithme symétrique par défaut est celui de l'identifiant d'utilisateur par défaut.

On peut trouver un sous paquet aussi bien dans une section de sous-paquet haché que non haché d'une signature. Si un sous-paquet n'est pas haché, l'information contenue par ce dernier ne peut pas être considérée définitive car il ne fait pas partie de la signature elle-même.

Temps de création de la signature

(champs de temps de 4 octets)

La date à laquelle la signature à été fabriquée.

DOIT être présente dans la partie hachée.

Emetteur

(identifiant de clef de 8 octets)

L'identifiant de clef OpenPGP de la clef émettant la signature.

Date d'expiration des clés

(Champs de date de 4 octets)

La période de validité de la clef. C'est le nombre de secondes après l'heure de création de la clef après lesquelles la clef expire. Si elle n'est pas présente ou que sa valeur est zéro, la clef n'expire jamais. Ce champ n'est présent que dans les auto-signatures.

Algorithmes symétriques préférés

(Séquence de valeurs d'un octet)

Nombres d'algorithme symétriques qui indiquent quels algorithmes le détenteur de la clef préfère utiliser. Le corps de sous paquet est une liste d'octets ordonnées avec les préférés en tête de liste. On suppose que seuls les algorithmes listés sont supportés par le logiciel du destinataire. Les nombres d'algorithmes sont présentés à la section 9. Ce champs n'est présent que dans les auto-signature.

Algorithmes de hachage préférés

(tableau de valeurs d'un octet)

Nombres d'algorithme de résumé de message qui indiquent quels algorithmes le détenteur de clef préfère recevoir. Comme les algorithmes symétriques préférés, la liste est ordonnée. Les nombres d'algorithme se trouve dans la section 6. Ce champ n'est présent que dans les auto-signatures.

Algorithmes de compression préférés

(tableau de valeurs d'un octet)

Nombres d'algorithme de compression qui indiquent quel algorithme le détenteur de la clef préfère utiliser. Comme les algorithmes symétriques préférés, la liste est ordonnée. Les nombres d'algorithme se trouvent dans la section 6. Si ce sous paquet n'est pas inclus, ZIP est privilégié. Un zéro indique que des données non compressées sont préférées; il se pourrait que le logiciel du détenteur de clef n'ait pas de logiciel de compression dans cette implémentation. Ce champ n'est présent que dans les auto-signatures.

Délai d'expiration de la signature

(champs de date de 4 octets)

Période de validité de la signature. C'est le nombre de secondes après la date de création de la signature où la signature expire. Si ce champ n'est pas présent ou si sa valeur est zéro, elle n'expire jamais.

Certifications exportables

(1 octet d'exportabilité, 0 pour non, 1 pour exportable)

Ce sous paquet indique si une signature de certification est << exportable >> ou non, pour être utilisé par d'autres utilisateurs que celui qui a émis la signature. Le corps de paquet contient un drapeau booléen indiquant si la signature est exportable. Si ce paquet n'est pas présent, la signature est exportable; c'est l'équivalent du drapeau contenant 1.

Les certifications non exportables, ou << local >> sont des signatures faites par un utilisateur pour marquer une clef comme valide seulement au sein de l'implémentation de cet utilisateur. Ainsi, lorsqu'une implémentation prépare une copie de clef d'utilisateur pour la transporter à un autre utilisateur (c'est le processus << d'exportation >> de la clef), toutes les signatures de certification local sont supprimées de la clef.

Le receveur d'une clef transportée << l'importe >> et, de la même façon, supprime toutes certifications locales. Dans le déroulement normal des choses, il n'y en aura pas, en admettant que l'importation est faite sur une clef exportée. Cependant, il y a des cas ou cela peut raisonnablement se produire. Par exemple, si une implémentation autorise l'importation de clefs depuis une base de donnée de clefs en plus d'une clef exportée, dans ce cas cette situation peut se produire.

Quelques implémentations ne représentent pas l'intérêt d'un utilisateur unique (par exemple, un serveur de clefs). Ces implémentations supprimeent toujours les certifications locales de toutes les clefs qu'elles gèrent.

Révocable

(1 octet de révocabilité, 0 pour non, 1 pour révocable)

État de la révocabilité de la signature. Le corps de paquet contient un drapeau booléen indiquant si la signature est révocable. Les signatures qui ne sont pas révocables ignorent toutes les signatures de révocation ultérieures. Elles représentent un engagement du signataire comme quoi qu'il ne peut pas révoquer sa signature pour la durée de vie de sa clef. Si ce paquet n'est pas présent, la signature est révocable.

Signature de confiance

(<< niveau >> d'1 octet (profondeur), 1 octet de taux de confiance)

Le signeur annonce que la clef n'est pas seulement valide, mais aussi fiable, au niveau spécifié. Le niveau 0 a le même sens qu'une signature de validité ordinaire. Le niveau 1 signifie que la clef signée est certifiée, valide et fiable, avec le second octet du corps précisant le degré de confiance. Le niveau 2 signifie que la clef signée est certifiée fiable pour l'émission de signatures de confiance d'un niveau 1, cad que c'est un << meta laisser-passer >>. Généralement, un niveau n de signature de confiance assure que la clef est fiable pour l'émission de signatures d'un niveau de confiance n-1. Le taux de confiance est compris entre 0 et 255, et est interprétée tel que les niveau inférieur à 120 indique une confiance partielle et les valeurs de 120 et plus indique une confiance totale. Les implémentations DEVRAIENT émettre des valeurs de 60 pour une confiance partielle et de 120 pour une confiance totale.

Expression régulière

(expression régulière terminée par un caractère nul)

Elles sont utilisées conjointement avec les paquets de signature de confiance (d'un niveau > 0) pour limiter l'étendue de confiance que l'on veut élargir. Seules les signatures des clefs cibles sur les identifiants d'utilisateur qui correspondent avec l'expression régulière dans le corps du paquet ont des confiances élargies par le sous-paquet de signature de confiance. L'expression régulière utilise la même syntaxe que le package "presque dans le domaine public" d'expression régulière d'Henry Spencer. Une description de la syntaxe se trouve dans une section plus bas.

Clé de révocation

(1 octet de classe, 1 octet d'ID d'algorithme, 20 octets d'empreintes digitales)

Autorise la clef spécifiée à utiliser les signatures de révocation pour cette clef. L'octet de classe doit avoir le bit 0x80 positionné. Si le bit 0x40 est positionné, alors cela signifie que l'information de révocation est sensible. Les autres bits sont réservés pour une utilisation future pour d'autres types d'autorisations. Ce champ n'est présent que dans les auto-signatures.

Si le drapeau << sensible >> est positionné, le détenteur de clef sent que ce sous paquet contient de l'information de confiance privée qui décrit une relation sensible réelle. Si ce drapeau est positionné, les implémentations NE DOIVENT PAS exporter cette signature vers d'autres utilisateurs sauf dans les cas ou les données doivent êtres disponibles: quand la signature est en train d'être envoyée au révoqueur désigné, ou quand elle est accompagnée par une signature de révocation de ce révoqueur. Notez qu'il peut être approprié d'isoler ce sous-paquet dans une signature séparée de manière à ce qu'il ne soit pas associé a d'autres sous-paquets qui doivent être exportés.

Données de notation

(4 octets de drapeaux, 2 octets de longueur du nom (M), 2 octets de la longueur de valeur (N), M octets de donnée pour le nom, N octets de donnée de la valeur)

Ce sous-paquet décrit une << notation >> sur la signature que l'émetteur souhaite faire. La notation possède un nom et une valeur, qui sont des chaînes d'octets. Il peut y avoir plus d'une notation dans une signature. Les notations peuvent être utilisés pour n'importe quelle extension l'émetteur de la signature souhaite faire. Le champ << drapeau >> contient 4 octets de drapeaux.

Tous les drapeaux indéfinis DOIVENT IMPERATIVEMENT être à zéro. Les drapeaux définis sont :

Premier octet

0x80 = version humaine. Cette note est du texte, une note d'une personne à l'autre, et n'a pas de sens pour le logiciel.

Autres octets

Rien.

Préférences du serveur de clé

(N octets de drapeaux)

C'est une liste de drapeaux qui indiquent les préférences que le détenteur de clés a par rapport à la manière dont la clé est prise en charge par le serveur. Tous les drapeaux indéfinis DOIVENT IMPERATIVEMENT être zero.

Premier octet

0x80 = ne modifie pas. le détenteur de clé demande que cette clé ne soit modifiée ou mise à jour que par le détenteur de clef ou un administrateur du serveur de clé.

Ce champ n'est présent que dans les auto-signatures.

Serveur de clés préféré

(chaîne de caractères)

C'est une URL du serveur de clefs que le détenteur de clefs préfère pour les mises à jour. Notez que les clefs avec plusieurs identifiants d'utilisateurs peuvent avoir un serveur de clef préféré pour chaque identifiant d'utilisateur. Notez également que comme c'est une URL, le serveur de clef peut être une copie d'une clef récupérée par ftp, http, finger, etc.

ID utilisateur primaire

(1 octet, booléen)

C'est un drapeau dans une auto signature d'identifiant utilisateur qui précise si l'identifiant utilisateur est l'identifiant utilisateur principal pour cette clef. Il est raisonnable pour une implémentation de résoudre les ambiguïtés dans les préférences, etc. pour un renvoi à l'identifiant d'utilisateur primaire. Si ce drapeau est absent, sa valeur est zéro. Si plus d'un identifiant utilisateur est marqué primaire dans une clef, l'implémentation peut résoudre l'ambiguïté de n'importe quelle façon qu'elle juge bonne.

URL énonçant les règles

(chaîne de caractères)

Ce sous-paquet contient l'URL d'un document qui décrit les règles selon lesquelles la signature a été émise.

Drapeaux de clés

(chaîne d'octets)

Ce sous-paquet contient une liste de drapeaux binaires qui contiennent l'information au sujet de la clef. C'est une chaîne d'octets, et une implémentation NE DOIT ABSOLUMENT PAS adopter une taille fixe, ceci afin qu'elle puisse grandir avec le temps. Si une liste est plus courte qu'une implémentation ne le prévoit, les drapeaux inconnus sont considérés comme étant à zéro. Les drapeaux définis sont :

Premier octet

0x01 - Cette clef peut être utilisée pour certifier d'autre clefs.

0x02 - Cette clef peut être utilisée pour signer des données.

0x04 - Cette clef peut être utilisée pour crypter des communications.

0x08 - Cette clef peut être utilisée pour crypter un enregistrement.

0x10 - Le composant privé de cette clef peut avoir été fractionné par un mécanisme de partage de secrets.

0x80 - Le composant privé de cette clef peut être en possession de plus d'une personne.

Notes d'utilisation :

Les drapeaux dans ce paquet peuvent apparaître dans les auto-signatures ou dans les signatures de certification. Ils expriment différentes choses suivant la personne qui émet l'instruction -- par exemple, une signature de certification qui possède le drapeau << signer les données >> signale que la certification est dans ce but. Par contre, le drapeau << cryptage de communication >> dans une auto-signature indique la préférence pour qu'une clef donnée soit utilisée pour les communications. Notez cependant, que c'est un autre problème que de déterminer ce qu'est << une communication >> et ce qu'est un << enregistrement >>. Cette décision est laissée entièrement à l'implémentation; les auteurs de ce document ne prétendent pas avoir d'avis particulier sur la question, et se rendent compte que l'opinion généralement répandue peut changer.

Les drapeaux de << clef découpée >> (0x10) et de << clef de groupe >> (0x80) sont placés seulement sur les auto-signatures; elle n'ont aucun sens pour les signatures de certification. Elles DOIVENT seulement être placés sur les signatures de clefs directes (type 0x1f) ou les signatures de sous clef (type 0x18), une qui renvoie à la clef à laquelle le drapeau s'applique.

ID utilisateur du signataire

Ce sous-paquet autorise un détenteur de clef à déclarer quel identifiant d'utilisateur est responsable de la signature. Beaucoup de détenteurs de clef utilisent une seule clef pour différentes applications, comme les communications professionnelles aussi bien que les communications personnelles. Ce sous-paquet autorise ce type de détenteur de clefs à déclarer à quel titre il fait une signature.

Raisons de révocation

(1 octet de code de révocation, N octets de chaînes de caractères pour la raison)

Ce sous paquet est utilisé seulement dans les révocations de clefs et dans les signatures de révocation de certification. Il décrit la raison de la révocation de la clef ou du certificat.

Le premier octet contient un code lisible par la machine qui indique la raison de la révocation :

0x00

Aucune raison spécifiée (révocation de clef ou de certificat)

0x01

La clef est périmée (révocations de clef)

0x02

La clef matérielle a été compromise (révocation de clef)

0x03

La clef n'est plus utilisée (révocations de clef)

0x20

L'information d'identifiant utilisateur n'est plus valide (révocations de certificat)

Le code de révocation est suivi d'une chaîne d'octets qui fournit des informations au sujet de la raison de la révocation en langage humain (UTF-8). La chaîne peut être nulle, c'est à dire, de longueur nulle. La longueur du sous paquet est la longueur de la chaîne donnant la raison plus un.

Créer les signatures

Toutes les signatures sont formées en effectuant un hachage sur la donnée de signature, puis en utilisant dans l'algorithme de signature le hachage qui en résulte.

Les données de signature sont simples à produire pour les signatures de document (type 0x00 et 0x01), pour lesquelles le document lui même représente les données. Pour les signatures seules, c'est une chaîne vide.

Quand une signature est crée par rapport à une clef, les données hachées débutent avec l'octet 0x99, suivi par deux octets de longueurs de clef, puis le corps du paquet de clef. (Notez que ceci est un style ancien d'en-tête de paquet pour un paquet de clef de deux octets de longueur.) Une signature de sous-clef (type 0x18) hache ensuite la sous-clef, en utilisant le même format que pour la clef principale. Les signatures de révocation de clef (type 0x20 et 0x28) hache seulement la clef en cours de révocation.

Conseils pour les sous-paquets

Une implémentation DOIT mettre les deux sous-paquets obligatoires, heure de création et émetteur, comme premiers sous-paquets dans la liste des sous-paquets, simplement pour que l'implémenteur les trouve plus facilement.

Il est certainement possible qu'une signature contienne des informations contradictoires dans les sous-paquets. Par exemple, une signature peut contenir plusieurs copies d'une préférence ou des temps d'expiration multiples. Dans la plupart des cas, une implémentation DEVRAIT utiliser le dernier sous-paquet de la signature, mais PEUT utiliser tout schéma de résolution de conflit pouvant être sensé. Veuillez noter que nous laissons intentionnellement la résolution de conflit à l'implémenteur ; la plupart des conflits sont simplement des erreurs de syntaxe, et les propos un peu flou que l'on tient ici permettent au récepteur d'être généreux sur ce qu'il accepte, tout en faisant pression sur le créateur pour qu'il soit radin sur ce qu'il génère.

Quelques conflits apparents peuvent en fait se comprendre -- par exemple, supposons qu'un détenteur de clef possède une clef V3 et une clef V4 qui partagent la même clef RSA de base. L'une ou l'autre de ces clés peut vérifier une signature créée par l'autre, et il peut être raisonnable pour une signature de contenir un sous-paquet émetteur pour chaque clef, de manière à attacher explicitement ces clefs à la signature.