Aller au contenu principal

2.7. Replace Section 5.2.2 - Encrypted Values

2.7. Replace Section 5.2.2 - Encrypted Values​

La Section 5.2.2 de [RFC4210] décrit l'utilisation d'EncryptedValue pour transporter des données chiffrées. Ce document étend le chiffrement des données pour utiliser de préférence EnvelopedData.

Remplacez le texte de la section par le texte suivant:

5.2.2. Encrypted Values​

Lorsque des données chiffrées (dans cette spécification, clés privées, certificats ou phrase de révocation) sont envoyées dans des messages PKI, la structure de données EncryptedKey est utilisée.

EncryptedKey ::= CHOICE {
   encryptedValue        EncryptedValue, -- deprecated
   envelopedData     [0] EnvelopedData }

Voir Certificate Request Message Format (CRMF) [RFC4211] pour la syntaxe EncryptedKey et EncryptedValue et Cryptographic Message Syntax (CMS) [RFC5652] pour la syntaxe EnvelopedData. L'utilisation de la structure de données EncryptedKey offre le choix d'utiliser soit EncryptedValue (pour la compatibilité descendante uniquement) soit EnvelopedData. L'utilisation de la structure EncryptedValue a été dépréciée en faveur de la structure EnvelopedData. Par conséquent, il est RECOMMANDÉ d'utiliser EnvelopedData.

Note: La structure EncryptedKey définie dans CRMF [RFC4211] est réutilisée ici, ce qui rend la mise à jour rétrocompatible. L'utilisation de la nouvelle syntaxe avec le choix par défaut non étiqueté EncryptedValue est compatible au niveau des bits sur le fil avec l'ancienne syntaxe.

Pour indiquer le support d'EnvelopedData, le pvno cmp2021 a été introduit. Les détails sur l'utilisation du numéro de version du protocole (pvno) sont décrits dans la Section 7.

La structure de données EncryptedKey est utilisée dans CMP pour transporter une clé privée, un certificat ou une phrase de révocation sous forme chiffrée.

EnvelopedData est utilisé comme suit:

  • Il ne contient qu'une seule structure RecipientInfo car le contenu n'est chiffré que pour un seul destinataire.

  • Il peut contenir une clé privée dans la structure AsymmetricKeyPackage, telle que définie dans [RFC5958], qui est enveloppée dans une structure SignedData, comme spécifié dans la Section 5 de CMS [RFC5652] et [RFC8933], et signée par l'autorité de génération de clés (Key Generation Authority).

  • Il peut contenir un certificat ou une phrase de révocation directement dans le champ encryptedContent.

Le contenu de la structure EnvelopedData, comme spécifié dans la Section 6 de CMS [RFC5652], DOIT être chiffré en utilisant une clé de chiffrement de contenu symétrique nouvellement générée. Cette clé de chiffrement de contenu DOIT être fournie de manière sécurisée au destinataire en utilisant l'une des trois techniques de gestion de clés.

Le choix de la technique de gestion de clés à utiliser par l'expéditeur dépend des informations d'identification disponibles chez le destinataire:

  • certificat du destinataire avec un identificateur d'algorithme et une clé publique qui prend en charge le transport de clés et où toute extension d'utilisation de clé donnée permet keyEncipherment: La clé de chiffrement de contenu sera protégée en utilisant la technique de gestion de clés de transport de clés, comme spécifié dans la Section 6.2.1 de CMS [RFC5652].

  • certificat du destinataire avec un identificateur d'algorithme et une clé publique qui prend en charge l'accord de clés et où toute extension d'utilisation de clé donnée permet keyAgreement: La clé de chiffrement de contenu sera protégée en utilisant la technique de gestion de clés d'accord de clés, comme spécifié dans la Section 6.2.2 de CMS [RFC5652].

  • un mot de passe ou un secret partagé: La clé de chiffrement de contenu sera protégée en utilisant la technique de gestion de clés basée sur mot de passe, comme spécifié dans la Section 6.2.4 de CMS [RFC5652].

Dernière mise à jour le