Résumé
- RFC 9939 attribue deux types de contenu CMS aux structures
PrivateKeyInfoetEncryptedPrivateKeyInfode RFC 5958. - Un OID rend la forme attendue identifiable; il ne démontre ni la possession d’une clé privée, ni sa protection effective, ni le droit de l’utiliser.
Dans une revue de transfert, l’étiquette id-ct-encrPrivateKeyInfo a été lue comme une approbation. Pourtant, elle dit d’abord quel objet CMS est annoncé. Elle ne dit pas si quelqu’un dispose du secret de déchiffrement, si la clé obtenue correspond à une identité utile, ni si la demande d’usage relève de sa compétence.
RFC 9939 fixe cette portée. Il réserve dans l’arc des types de contenu CMS le décimal 52 pour id-ct-privateKeyInfo et le 53 pour id-ct-encrPrivateKeyInfo. Il ajoute aussi un identifiant de module et les deux noms d’inner content type pour application/cms. L’enregistrement facilite l’interopérabilité entre producteurs et parseurs; il ne transforme pas le registre en autorité de garde ou de politique.
RFC 5958 précise ce qui est structuré. PrivateKeyInfo, compatible avec OneAsymmetricKey, porte une version, un identifiant d’algorithme, des octets de clé privée, des attributs éventuels et parfois une clé publique. EncryptedPrivateKeyInfo porte un identifiant d’algorithme de chiffrement et des données chiffrées. Ces champs apportent une grammaire et des paramètres. Ils ne portent pas une preuve de déchiffrement réussi, de conservation légitime, de finalité autorisée ou d’acceptation par un système tiers.
La protection est une couche à établir, non une propriété magique du nom. RFC 5652 présente CMS comme une enveloppe pouvant signer, authentifier ou chiffrer; les protocoles qui l’emploient choisissent les algorithmes adaptés à leur environnement. RFC 5959 décrit des conventions algorithmiques pour les informations de clé privée chiffrées. RFC 5958 rappelle qu’une divulgation peut permettre une usurpation et que le contenu du paquet n’est pas protégé par son seul type.
Conservez donc un reçu plutôt qu’un adjectif: OID, hachage de l’objet, résultat de parsing, algorithmes, enveloppe et éléments destinataire/gestion de clés, intégrité, déchiffrement autorisé, correspondance utile avec une clé publique ou un certificat, finalité, destinataire, rétention et décision distincte du système qui s’en remet. Le code qui reconnaît une forme ne peut pas décider à la place du responsable de l’usage.
Sources
- https://www.rfc-editor.org/rfc/rfc9939.html
- https://www.rfc-editor.org/rfc/rfc5958.html
- https://www.rfc-editor.org/rfc/rfc5959.html
- https://www.rfc-editor.org/rfc/rfc5652.html
- https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

