PKI et certificats : comment une clé publique reçoit un nom

Le problème : n’importe qui peut créer une clé et se réclamer d’un nom

Dans l’article 1, Ibrahima a vérifié la signature de Mariama sur un contrat de prêt avec sa clé publique. Cette vérification prouvait une chose précise : le détenteur de la clé privée correspondante a signé exactement ces octets.

Elle ne prouvait pas que ce détenteur était Mariama. La clé publique était arrivée jointe à un e-mail, et n’importe qui peut générer une paire de clés, écrire « Mariama Diallo » dans un message et l’envoyer. FIPS 186-5 nomme ce risque : sans assurance que le signataire possède la paire de clés, « le problème de la falsification d’une signature se ramène à celui d’une usurpation d’identité ». Il nomme aussi le remède : cette assurance « ne peut être apportée que si l’identité du propriétaire et la clé publique sont liées, par exemple dans un certificat émis par une infrastructure à clé publique » (FIPS 186-5, §3).

Cet article porte sur ce lien : ce que contient un certificat, qui le délivre, comment Mariama en demande un et comment Ibrahima le contrôle.

Les normes de l’IETF et du NIST citées ici n’existent qu’en anglais : leurs citations sont traduites par nos soins.

Ce qu’est un certificat

Quiconque s’appuie sur une clé publique doit pouvoir se fier au fait que la clé privée correspondante appartient au bon sujet, une personne ou un système. La RFC 5280, le profil Internet de X.509, apporte cette assurance au moyen de certificats : des structures de données qui lient une clé publique à un sujet. Une autorité de certification (certification authority) (AC) de confiance atteste ce lien en signant numériquement chaque certificat (RFC 5280, §3.1).

C’est le « signer puis vérifier » de l’article 1, appliqué à un nouveau type de document. « En produisant cette signature, une AC certifie la validité des informations du champ tbsCertificate. En particulier, l’AC certifie le lien entre les éléments de clé publique et le sujet du certificat » (§4.1.1.3).

Deux conséquences en découlent. D’abord, un certificat se protège lui-même : quiconque dispose de la clé publique de l’AC peut contrôler sa signature et ses dates, si bien qu’il peut circuler par des canaux non fiables (§3.1). Mariama peut envoyer le sien par e-mail.

Ensuite, un certificat ne vaut que par les contrôles que l’AC a faits avant de le signer, et la RFC 5280 ne fixe pas ces contrôles. L’AC peut s’appuyer sur une preuve technique que le sujet détient la clé privée, sur la présentation de la clé privée, ou simplement sur la déclaration du sujet lui-même (§3.1). La RFC 5280 demande donc à ceux qui se fient à un certificat d’« examiner la politique de certification établie par l’autorité de certification (AC) avant de se fier aux services d’authentification ou de non-répudiation », et précise qu’elle « ne prescrit pas de règles ni d’obligations juridiquement contraignantes » (§2).

Dans un certificat X.509

X.509 est une norme de l’UIT-T et de l’ISO publiée pour la première fois en 1988 ; la version 3, de 1996, y a ajouté les extensions (§3.1). Un certificat compte trois champs : le contenu à signer (tbsCertificate), l’algorithme de signature de l’AC (signatureAlgorithm), qui doit correspondre à l’identifiant répété dans le contenu, et la valeur de signature (signatureValue), calculée sur l’encodage DER du contenu (§4.1, §4.1.1). Le contenu renferme ce que lit un vérificateur :

Un nom peut aussi figurer dans l’extension subjectAltName. Les nouveaux certificats doivent y placer les adresses e-mail ; un attribut e-mail dans le DN est « déprécié mais autorisé » (§4.1.2.6).

Les extensions : ce que la clé a le droit de faire

Chaque extension est critique ou non. Un système doit rejeter un certificat qui porte une extension critique qu’il ne reconnaît pas ou ne sait pas traiter (§4.2).

L’usage de la clé (key usage) est un ensemble de bits qui nomment les finalités de la clé, parmi lesquels digitalSignature, nonRepudiation, keyEncipherment, keyCertSign et cRLSign (§4.2.1.3). digitalSignature couvre les signatures autres que celles apposées sur des certificats et des CRL. nonRepudiation est positionné lorsque la clé vérifie des signatures dans un service qui protège contre le fait qu’un signataire nie à tort une action ; la RFC 5280 note que les éditions récentes de X.509 l’ont renommé contentCommitment, et laisse aux politiques de certification les distinctions plus fines entre ces deux bits. keyCertSign concerne les clés qui vérifient d’autres certificats, et exige que le certificat soit marqué comme celui d’une AC.

Les contraintes de base (basic constraints) indiquent si le sujet est une AC. Si l’indicateur cA est absent, la clé ne doit pas servir à vérifier des signatures de certificats. Une contrainte facultative de longueur de chemin limite le nombre d’AC intermédiaires qui peuvent suivre ; zéro signifie que seuls des certificats d’entité finale peuvent suivre (§4.2.1.9).

Les identifiants de clé aident les logiciels à trouver le bon certificat d’émetteur. L’identifiant de clé du sujet est généralement une empreinte de la clé publique ; l’identifiant de clé de l’autorité désigne la clé de l’émetteur (§4.2.1.1, §4.2.1.2).

Les politiques de certification portent des identifiants qui, dans un certificat d’entité finale, « indiquent la politique selon laquelle le certificat a été émis et les usages auxquels il peut servir » (§4.2.1.4). C’est là que celui qui se fie au certificat apprend comment l’AC a contrôlé le sujet. L’article 4 traite des documents de politique eux-mêmes.

L’usage étendu de la clé (extended key usage) peut ajouter ou restreindre des finalités. Quand il coexiste avec l’usage de la clé, le certificat ne peut servir qu’à une finalité compatible avec les deux (§4.2.1.12).

Qui fait quoi dans une PKI

La RFC 5280 décrit une infrastructure à clé publique (PKI) à travers quelques rôles (§3) : l’entité finale (end entity), sujet d’un certificat (Mariama) ; l’AC, qui émet les certificats et répond de leur statut de révocation ; l’autorité d’enregistrement (registration authority) (AE), un système facultatif auquel une AC délègue certaines fonctions de gestion ; l’émetteur de CRL ; et le dépôt, qui conserve certificats et CRL.

Trois fonctions les relient (§3.5). L’enregistrement est « le processus par lequel un utilisateur se fait d’abord connaître d’une AC (directement ou par l’intermédiaire d’une AE), avant que cette AC ne lui émette un certificat ». L’initialisation fournit au client la clé publique de l’AC de confiance, et généralement sa propre paire de clés. La certification est l’émission du certificat par l’AC, qui le renvoie, le publie dans un dépôt, ou les deux. Aucune de ces étapes n’a à se dérouler en ligne, et elles peuvent être réunies en un seul échange.

L’enrôlement : la CSR et la preuve de possession

Mariama demande un certificat au moyen d’une demande de signature de certificat (certificate signing request) (CSR), définie par PKCS #10. Elle rassemble son nom distinctif, sa clé publique et des attributs facultatifs, signe leur encodage DER avec sa clé privée, et regroupe le tout (RFC 2986, §3, §4.1, §4.2). La demande contient la clé publique, jamais la clé privée. Elle ne comporte ni nom d’émetteur, ni numéro de série, ni période de validité : c’est l’AC qui les choisit (§3, note 4).

Pourquoi signer une demande ? La signature « empêche une entité de demander un certificat avec la clé publique d’un tiers » (§3, note 2). Sans elle, un attaquant pourrait copier la clé publique de Mariama, mettre son propre nom sur une demande et obtenir un certificat qui présente la clé de Mariama comme la sienne. La RFC 4211 appelle l’idée générale preuve de possession (proof of possession) (POP) : le demandeur montre qu’il peut utiliser la clé privée correspondant à la clé publique de la demande, ce qui permet à l’AC ou à l’AE de contrôler le lien entre le sujet et la paire de clés (RFC 4211, §4). La signature de la CSR est l’une des façons de l’apporter.

La preuve de possession n’est pas une preuve d’identité. PKCS #10 décrit le travail de l’AC en deux temps : elle satisfait la demande « en authentifiant l’entité demandeuse et en vérifiant la signature de l’entité » (RFC 2986, §3). La signature montre que le demandeur détient la clé. Vérifier qu’il s’agit bien de Mariama est une tâche distincte, menée selon la politique de l’AC ; la RFC 4211 laisse de même la méthode de POP à la politique locale et permet à l’AE, à l’AC ou aux deux d’effectuer le contrôle (§4). La façon dont la demande est acheminée sort du champ de PKCS #10 : « Les formes papier et électronique sont toutes deux possibles » (§3, note 3).

Chaînes et ancres de confiance

Le logiciel d’Ibrahima ne peut pas détenir la clé publique de chaque AC. Il part de quelques clés d’AC auxquelles il se fie et construit une chaîne jusqu’au certificat de Mariama. La RFC 5280 appelle cette chaîne un chemin de certification (certification path) : le certificat de l’entité finale plus zéro, un ou plusieurs certificats d’AC (§3.2).

Les certificats d’entité finale sont délivrés à des sujets qui n’ont pas le droit d’émettre de certificats. Parmi les certificats d’AC figurent des certificats autosignés, dont la signature se vérifie avec la clé publique qu’ils contiennent ; ce sont eux qui transmettent la clé publique par laquelle commence un chemin (§3.2). Cette clé de départ est l’ancre de confiance (trust anchor). Les chemins valides commencent par des certificats émis par une ancre de confiance, et le choix de l’ancre relève de la politique (§6.1). On fait confiance à l’ancre parce qu’elle est parvenue au vérificateur par une procédure hors bande digne de confiance (§6.1.1(d)), et non à cause de sa signature : la signature d’un certificat autosigné « prouve que l’émetteur possède à la fois la clé publique et la clé privée » (§4.2.1.1), et ne dit rien de l’identité de cet émetteur. Quand l’ancre est fournie sous forme de certificat autosigné, elle ne fait pas partie du chemin validé (§6.1). Le certificat autosigné d’un serveur, créé par une entité qui n’est pas une AC, sort du champ de la RFC 5280 (RFC 6818, §2).

La validation part de l’ancre et descend (§6.1.3, §6.1.4). Pour chaque certificat, le vérificateur contrôle que sa signature se vérifie avec la clé du niveau supérieur, que l’heure courante se situe dans sa période de validité, qu’il n’est pas révoqué, et que son émetteur correspond au sujet du niveau supérieur. Pour chaque AC intermédiaire, il contrôle en outre que les contraintes de base la désignent comme AC, qu’aucune limite de longueur de chemin n’est dépassée, et que keyCertSign est positionné si l’usage de la clé est présent. La RFC 5280 ne spécifie que la validation ; la façon dont un logiciel trouve les certificats pour construire le chemin sort de son champ (§6.1).

Mariama s’enrôle, Ibrahima vérifie

Revenons au contrat de prêt, cette fois avec une PKI générique comme celle de la partie pratique ci-dessous.

1. Mariama génère une paire de clés P-256 et construit une CSR avec son nom et sa clé publique, signée avec sa clé privée.
2. Elle s’enregistre auprès de l’AE et envoie la CSR. L’AE vérifie son identité selon la politique de l’AC, et vérifie la signature de la CSR.
3. L’AC émettrice fixe l’émetteur, le numéro de série, la validité et les extensions (CA:FALSE, usages de clé digitalSignature et nonRepudiation), signe le certificat et le renvoie.
4. Mariama signe le contrat comme dans l’article 1, et envoie le contrat, la signature, son certificat et celui de l’AC émettrice.
5. Le magasin de confiance d’Ibrahima contient déjà la racine. Son logiciel construit le chemin racine → AC émettrice → Mariama, contrôle chaque signature, chaque date et chaque contrainte, puis vérifie la signature du contrat avec la clé publique tirée du certificat de Mariama.

Si Ibrahima ne faisait confiance qu’à la racine d’un inconnu, l’étape 5 échouerait : aucun chemin ne mène de cette ancre au certificat de Mariama. Un certificat racine transmis dans le message n’y changerait rien non plus. L’ancre de confiance est le choix d’Ibrahima, pas celui de l’expéditeur.

À vous : une PKI jouet avec OpenSSL

Le script crée une AC racine et une AC émettrice, génère la clé et la CSR de Mariama, lui émet un certificat de signature, puis le vérifie avec la bonne racine, et ensuite avec une racine sans rapport. Il s’exécute dans un conteneur jetable et n’écrit rien sur votre machine. Ne réutilisez jamais ces clés ni ces certificats.

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

docker run --rm -w /w alpine:3.22 sh -c '
apk add --no-cache openssl >/dev/null && openssl version &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key &&
openssl req -x509 -new -key root.key -sha256 -days 3650 \
  -subj "/C=GN/O=Demo PKI/CN=Demo Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out root.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out issuing.key &&
openssl req -new -key issuing.key \
  -subj "/C=GN/O=Demo PKI/CN=Demo Issuing CA" \
  -out issuing.csr &&
printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign\n" > issuing_ext.cnf &&
openssl x509 -req -in issuing.csr -CA root.pem -CAkey root.key -CAcreateserial \
  -days 1825 -sha256 -extfile issuing_ext.cnf -out issuing.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out mariama.key &&
openssl req -new -key mariama.key \
  -subj "/C=GN/CN=Mariama Diallo" \
  -out mariama.csr &&
printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,digitalSignature,nonRepudiation\n" > mariama_ext.cnf &&
openssl x509 -req -in mariama.csr -CA issuing.pem -CAkey issuing.key -CAcreateserial \
  -days 365 -sha256 -extfile mariama_ext.cnf -out mariama.pem &&
echo "--- verify: root + issuing chain ---" &&
openssl verify -CAfile root.pem -untrusted issuing.pem mariama.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out stranger.key &&
openssl req -x509 -new -key stranger.key -sha256 -days 3650 \
  -subj "/C=GN/O=Acme Corp/CN=Acme Corp Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out stranger-root.pem &&
echo "--- verify: strangers unrelated root (expect failure) ---";
openssl verify -CAfile stranger-root.pem -untrusted issuing.pem mariama.pem; echo "exit=$?";
echo "--- Mariama certificate, decoded ---";
openssl x509 -in mariama.pem -text -noout'

• openssl req -x509 crée le certificat autosigné de la racine ; -addext fixe ses extensions et -days remplace la durée par défaut de 30 jours. openssl req -new crée une CSR PKCS #10 à partir d’une clé existante (openssl-req).
• openssl x509 -req -CA … -CAkey … joue le rôle de « micro-AC » : il reprend le sujet du certificat d’AC comme nouvel émetteur et signe avec la clé de l’AC. -CAcreateserial démarre un numéro de série aléatoire. Les extensions demandées dans une CSR ne sont pas recopiées par défaut ; elles viennent de -extfile, si bien que c’est l’AC, et non le demandeur, qui décide que le certificat de Mariama est CA:FALSE (openssl-x509). OpenSSL écrit toujours ce bit nonRepudiation (x509v3_config).
• openssl verify -CAfile root.pem charge la racine comme certificat de confiance. -untrusted issuing.pem fournit le certificat intermédiaire pour construire la chaîne, sans lui accorder de confiance. OpenSSL lui-même ne livre aucun jeu d’ancres de confiance par défaut, mais de nombreuses distributions Linux en configurent un (openssl-verification-options). Le conteneur nu utilisé ici n’en a aucun.

OpenSSL 3.5.8 25 Aug 2026 (Library: OpenSSL 3.5.8 25 Aug 2026)
Certificate request self-signature ok
subject=C=GN, O=Demo PKI, CN=Demo Issuing CA
Certificate request self-signature ok
subject=C=GN, CN=Mariama Diallo
--- verify: root + issuing chain ---
mariama.pem: OK
--- verify: strangers unrelated root (expect failure) ---
C=GN, O=Demo PKI, CN=Demo Issuing CA
error 20 at 1 depth lookup: unable to get local issuer certificate
error mariama.pem: verification failed
exit=2
--- Mariama certificate, decoded ---
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            64:42:dd:13:40:18:75:59:8c:e8:82:db:bc:7f:b6:73:22:77:c4:0b
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=GN, O=Demo PKI, CN=Demo Issuing CA
        Validity
            Not Before: Sep 23 08:32:24 2026 GMT
            Not After : Sep 23 08:32:24 2027 GMT
        Subject: C=GN, CN=Mariama Diallo
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:7b:44:39:62:a6:95:25:c7:04:ac:59:3a:ca:87:
                    52:5f:cf:40:d4:1a:1b:16:f4:a6:f5:63:e7:4a:1a:
                    93:58:72:38:cd:7d:15:33:01:ad:6d:39:0d:1d:1c:
                    6d:db:2e:d6:a6:47:bd:69:3e:ab:86:cb:cf:60:a6:
                    1d:13:2f:9b:56
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Subject Key Identifier:
                3A:44:B3:81:0E:C9:B2:60:78:C5:91:42:0D:30:68:01:C3:47:9B:57
            X509v3 Authority Key Identifier:
                29:B0:17:79:A7:33:74:A1:CA:2E:4D:1A:CB:1A:BC:40:6F:9A:10:C6
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:cf:c5:b2:b6:ab:e3:e7:c2:ea:89:ff:be:c3:
        c5:04:78:cc:03:d4:5a:9f:ec:73:3d:d9:3c:2d:3b:ae:63:f4:
        a1:02:21:00:87:e1:f7:74:77:e0:0c:c1:ef:7d:c4:22:ea:b2:
        1b:d5:6a:93:3a:a8:ee:8f:86:69:6e:44:3f:89:06:c6:8b:f0

Les deux lignes « Certificate request self-signature ok » correspondent à openssl x509 -req qui vérifie la signature de chaque CSR avant d’émettre le certificat : c’est le contrôle de preuve de possession de l’outil. mariama.pem: OK signifie qu’OpenSSL a construit un chemin jusqu’à la racine de confiance et que chaque signature et chaque date ont passé le contrôle.

Avec la racine de l’inconnu, l’erreur prend la forme error N at D depth lookup (openssl-verify). La profondeur 0 est le certificat de Mariama ; la profondeur 1 est l’AC émettrice, affichée sur la ligne du dessus. L’erreur 20, « unable to get local issuer certificate », survient quand l’émetteur d’un certificat non fiable est introuvable (openssl-verification-options). Le code de sortie est 2, qu’un script peut tester. Dans le certificat décodé, les contraintes de base valent CA:FALSE et l’usage de la clé Digital Signature et Non Repudiation, tous deux critiques. Les identifiants de clé n’ont pas été demandés : OpenSSL les ajoute par défaut (x509v3_config).

Chaque exécution génère de nouvelles clés, -CAcreateserial tire un numéro de série aléatoire, les dates suivent l’horloge, et ECDSA utilise un nouveau nombre aléatoire pour chaque signature : le numéro de série, les dates, la clé publique, les identifiants de clé et la valeur de signature seront donc différents sur votre machine. La logique de la chaîne, elle, ne change pas. alpine:3.22 suit la dernière version 3.22.x : la ligne de version d’OpenSSL dépend donc du dépôt de paquets Alpine au moment de l’installation. Si Docker doit d’abord télécharger l’image, ses lignes de progression s’affichent avant cette sortie.

OTP ≠ identité juridique

Beaucoup de parcours de signature envoient un code à usage unique (OTP) par SMS et demandent au signataire de le saisir. Il est tentant de traiter ce code comme l’identité du signataire. Les normes et la loi disent le contraire.

Le NIST distingue deux choses. La vérification d’identité (identity proofing) désigne « les processus utilisés pour recueillir, valider et vérifier des informations sur un sujet afin d’établir un niveau d’assurance quant à l’identité qu’il revendique » (SP 800-63-4, annexe B). L’authentification « démontre que le demandeur possède et contrôle un ou plusieurs authentificateurs valides liés à l’identité de l’abonné » (§2.3.2), un lien établi plus tôt, lors de la vérification d’identité et de l’enrôlement (§2.2).

Un code envoyé par SMS ou par appel vocal est, dans les termes du NIST, un authentificateur hors bande : il « établit que le demandeur contrôle l’appareil hors bande » et ne résiste pas à l’hameçonnage (SP 800-63B-4, §3.1.3). Le NIST réserve le terme « OTP » aux codes générés par un appareil qui détient une graine secrète, même si l’usage courant appelle OTP les uns comme les autres. Les codes transmis par le réseau téléphonique sont une option restreinte, et les vérificateurs devraient peser des risques tels que « le changement d’appareil, le changement de carte SIM, la portabilité du numéro » (§3.1.3.3).

Un code correct montre donc que quelqu’un contrôlait un numéro de téléphone ou un appareil à ce moment-là. Il ne dit qui est cette personne que si une vérification d’identité antérieure a rattaché ce numéro à une identité vérifiée, et même dans ce cas, il ne lie aucune clé publique à qui que ce soit.

La loi guinéenne L/2016/035/AN traite de cette question dans plusieurs alinéas de son article 34 (art. 34). Son alinéa 5 lie la valeur d’une signature manuscrite à une signature sécurisée et à un certificat qualifié : « La signature électronique sécurisée liée à un certificat électronique qualifié, a la même force ou valeur probante que la signature est [sic] manuscrite. » Un autre alinéa présume la fiabilité d’un procédé qui met en œuvre une signature sécurisée et un certificat qualifié. L’alinéa 1 emploie lui aussi la formule de la signature manuscrite, avec des conditions différentes : un dispositif fiable et sécurisé sous le contrôle exclusif du signataire, et un « certificat numérique ». L’articulation de ces alinéas reste ouverte et relève d’un avocat guinéen. Un quatrième alinéa protège les signatures contre un rejet pur et simple : « Une signature électronique ne peut être déclarée irrecevable au seul motif : qu’elle se présente sous forme électronique ; ou qu’elle ne repose pas sur un certificat qualifié ; ou qu’elle n’est pas créée par un mécanisme sécurisé de création de signature électronique. » Les conditions d’une signature « sécurisée » sont renvoyées à un décret présidentiel, et la loi ne mentionne ni les OTP, ni les codes à usage unique, ni les SMS.

Notre lecture, qui ne constitue pas un avis juridique : les deux alinéas qui emploient la formule de la signature manuscrite comptent un certificat parmi leurs conditions, et un certificat est le lien signé par une AC entre une clé publique et un sujet. Un OTP n’est pas un certificat, et les deux alinéas en comptent un parmi leurs conditions ; savoir si un parcours OTP donné remplit l’un ou l’autre est une question pour un avocat guinéen. L’article 34 interdit toujours de refuser une signature au seul motif qu’elle est électronique ou qu’elle ne repose pas sur un certificat qualifié. Pour décider du niveau de vérification d’identité qu’exige un document, lisez quel niveau de preuve exige votre document. L’article 5 montre comment lier un code à une seule transaction, et l’article 8 traite en profondeur de l’identité et du droit.

La place de SEDEYA

Une signature PAdES transporte la chaîne de certificats dont un vérificateur a besoin pour la validation de chemin décrite plus haut. SEDEYA signe les PDF au format PAdES, jusqu’au niveau B-LTA, avec des horodatages RFC 3161 et les données de validation intégrées au fichier. Ibrahima n’a pas à assembler des chaînes avec OpenSSL : il peut déposer le PDF signé sur la page de vérification publique de SEDEYA, ou scanner le QR code imprimé dessus, et la page effectue les contrôles. Les prochains articles de cette série traitent des clés qui se trouvent derrière cette signature et de la durée pendant laquelle elle reste vérifiable.

Risques et idées reçues

En résumé

• Une clé publique seule ne dit rien de son détenteur. Un certificat la lie à un sujet, et une AC atteste ce lien par sa signature.
• Un certificat X.509 indique son émetteur, son numéro de série, sa validité, son sujet et sa clé publique ; des extensions comme l’usage de la clé et les contraintes de base limitent la clé.
• La signature d’une CSR est une preuve de possession, pas une preuve d’identité. L’AC ou l’AE authentifie le demandeur à part, selon sa politique.
• Un vérificateur construit un chemin depuis une ancre de confiance qu’il détient déjà jusqu’au signataire, en contrôlant chaque signature, chaque date, chaque nom et chaque contrainte.
• Dans la partie pratique, le certificat de Mariama s’est vérifié avec sa propre racine et a échoué avec une racine sans rapport, avec l’erreur 20.
• Un code à usage unique montre le contrôle d’un appareil. Ce n’est pas un certificat, et l’article 34 compte un certificat parmi les conditions des deux alinéas qui emploient la formule de la signature manuscrite.

Vérifiez votre compréhension

Prochaine étape

Un certificat lie le nom de Mariama à sa clé publique, mais ne dit rien de l’endroit où se trouve sa clé privée ni de qui peut s’en servir. L’article 3 traite des clés de signature, des modules matériels de sécurité et de PKCS#11. D’ici là, parlez-nous : nous vous montrerons comment un document signé avec SEDEYA transporte sa chaîne de certificats, et comment n’importe qui peut le vérifier.