Résumé

  • PrivateKeyInfo de RFC 5208 et OneAsymmetricKey de RFC 5958 organisent les octets d’une clé privée. Dans leur forme non chiffrée, ils ne prouvent ni la confidentialité, ni le contrôle d’accès, ni la présence dans un HSM.
  • Déchiffrer, valider, faire correspondre une clé publique, importer, autoriser, exécuter puis faire accepter une opération sont des événements indépendants. Le parseur n’a d’autorité que sur le premier.

La grammaire a fait son travail

PKCS #8 apporte une enveloppe commune à des clés dont la structure interne dépend de l’algorithme. RFC 5208 place dans PrivateKeyInfo une version, un identifiant d’algorithme, une OCTET STRING privée et des attributs facultatifs. L’enregistrement de l’algorithme précise le sens des octets internes.

Ce contrat est précieux parce qu’il est limité. Il permet à deux logiciels de s’accorder sur une représentation. Il ne raconte pas où les octets ont été produits, s’ils ont séjourné dans un fichier temporaire, qui les a copiés ou si un journal les a capturés. « ASN.1 valide » est un reçu de syntaxe, pas une chaîne de garde.

RFC 5958 renomme la structure OneAsymmetricKey, ajoute une clé publique facultative et définit un paquet pouvant transporter plusieurs clés. Le texte qualifie ce contenu de clés asymétriques en clair et précise qu’il n’est pas protégé. Une couche CMS peut assurer signature, authentification ou chiffrement. La protection est un acte supplémentaire, non une propriété magique du conteneur.

Le libellé ne doit pas mentir

RFC 7468 emploie PRIVATE KEY pour la forme non chiffrée et ENCRYPTED PRIVATE KEY pour EncryptedPrivateKeyInfo. Dans RFC 5208, cette seconde structure contient l’algorithme de chiffrement et les données chiffrées. L’information privée est d’abord encodée, puis le résultat est chiffré.

Une piste d’audit sérieuse conserve donc deux étapes. Elle note que l’enveloppe protégée était lisible, puis documente les paramètres du KDF et du chiffrement, le secret présenté, le contrôle d’intégrité et le sort du clair. Un statut unique importé efface le moment où la protection a cessé.

L’identifiant cryptographique ne mesure pas sa propre robustesse. RFC 8018 rappelle qu’un mot de passe provient souvent d’un espace réduit ; sel, coût, fonction de dérivation et limites d’essai déterminent la résistance pratique. Afficher un OID ne prouve ni la qualité du mot de passe ni l’application de la politique.

Le risque change sans modifier le fichier

Le même objet PKCS #8 peut passer de la mémoire du générateur à un disque, une pièce jointe, un coffre logiciel, un service KMS puis un HSM. Sa syntaxe reste identique tandis que son propriétaire opérationnel et sa surface d’exposition changent à chaque transfert.

L’extension .p8, le type application/pkcs8 ou une frontière PEM correcte ne démontrent donc pas la résidence matérielle. Même un identifiant d’objet HSM ne garantit pas l’absence d’une copie en clair, la non-exportabilité, l’équivalence des sauvegardes ou l’autorisation du prochain appelant.

Le reçu de garde doit relier empreinte source, canal protégé, opérateur d’import, slot, identifiant, attribut d’export, réplication, journal d’usage et suppression des copies transitoires. Il ne faut pas cacher ce parcours derrière le feu vert du parseur.

Une clé lisible peut être une autre clé

RFC 5958 autorise un champ de clé publique ; certaines structures algorithmiques contiennent déjà des éléments publics. Cela facilite l’emballage mais ne prouve pas la correspondance avec le certificat, le compte ou l’identité attendue. Il faut dériver ou valider la clé publique et la comparer à la référence indépendante.

RFC 8479 illustre une autre limite utile. Un attribut peut conserver la graine et l’algorithme nécessaires à la validation de certains paramètres RSA ou DSA. La disponibilité des entrées n’est pas le reçu d’une validation exécutée, encore moins d’un verdict positif.

Après la validation viennent l’autorisation et l’effet. Une clé correcte peut être refusée par la politique. Une signature produite peut être rejetée par l’application à cause du message, du contexte, de l’heure, de la chaîne de certificats ou de la politique algorithmique. Chaque étape peut réussir sans la suivante.

Une référence moderne ne migre pas le parc

RFC 5208 est un document Informational de 2008. RFC 5958, Standards Track en 2010, l’a remplacé avec un nouveau nom, un champ public facultatif, des règles de version et un type CMS. La compatibilité maintient cependant la forme v1 historique.

Une ligne d’inventaire « RFC 5958 » ne prouve donc pas que les exporteurs, importeurs, sauvegardes et outils de restauration utilisent le même chemin. Il faut observer les encodages, tester les versions, les champs inconnus, les échecs, les allers-retours et la restauration réelle. Le numéro de RFC exprime une intention ; le code exécuté apporte le reçu.

Gouverner les reçus, pas les symboles

Pour chaque déplacement, distinguer : octets et provenance ; décodage texte ; parse ASN.1 ; type clair ou protégé ; paramètres KDF/chiffrement ; déchiffrement et intégrité ; validation mathématique ; correspondance publique ; destination et exportabilité ; autorisation ; opération ; vérification ; acceptation applicative ; révocation et suppression.

PRIVATE KEY nomme une représentation. Le déchiffrement prouve l’accès au clair. La comparaison publique prouve une correspondance. Le journal HSM prouve une opération dans une enceinte donnée. La vérification prouve un résultat sur un message. Aucun reçu ne doit absorber l’autorité du suivant.

La décision de direction consiste à garder le format commun minimal, rendre explicites les politiques locales de garde et d’accès, et prendre les opérations vérifiables du code en fonctionnement comme preuve principale. La provenance explique le chemin ; elle ne remplace pas le résultat.

Sources

  1. Informations RFC 5208
  2. RFC 5208 HTML
  3. RFC 5208 texte
  4. Datatracker IETF : RFC 5208
  5. Historique RFC 5208
  6. Références RFC 5208
  7. Errata RFC 5208
  8. Informations RFC 5958
  9. RFC 5958 HTML
  10. RFC 5958 texte
  11. Datatracker IETF : RFC 5958
  12. Historique RFC 5958
  13. Références RFC 5958
  14. Errata RFC 5958
  15. RFC 8018 — cryptographie par mot de passe
  16. RFC 8351 — type média EncryptedPrivateKeyInfo
  17. RFC 7468 — encodages textuels
  18. RFC 8479 — paramètres de validation PKCS #8
  19. RFC 5915 — structure de clé privée EC
  20. Heng Lu — couches de réalité et pouvoir symbolique
  21. Heng Lu — spécification initiale minimale
  22. Heng Lu — primauté du code en fonctionnement