Aller au contenu principal

2.1. New Section 1.1 - Changes Since RFC 4210

2.1. New Section 1.1 - Changes Since RFC 4210

La sous-section suivante décrit les mises à jour des fonctionnalités de [RFC4210]. Elles sont toujours liées à la spécification de base. Par conséquent, les références aux sections originales dans [RFC4210] sont utilisées dans la mesure du possible.

Insérez cette section après la Section 1 actuelle de [RFC4210]:

1.1. Changes Since RFC 4210

Les mises à jour suivantes sont effectuées dans ce document:

  • Ajout de nouvelles utilisations de clés étendues (extended key usages) pour divers types de serveurs CMP, par exemple, autorité d'enregistrement et autorité de certification, pour exprimer l'autorisation de l'entité identifiée dans le certificat contenant l'extension d'utilisation de clé étendue respective qui agit en tant qu'entité de gestion PKI indiquée.

  • Extension de la description de la protection multiple (multiple protection) pour couvrir des cas d'utilisation supplémentaires, par exemple, le traitement par lots de messages.

  • Offrir EnvelopedData comme choix préféré à côté d'EncryptedValue pour mieux supporter l'agilité cryptographique (crypto agility) dans CMP. Notez que, selon [RFC4211], Section 2.1, point 9, l'utilisation de la structure EncryptedValue a été dépréciée en faveur de la structure EnvelopedData. [RFC4211] offre à la structure EncryptedKey un choix entre EncryptedValue et EnvelopedData pour la migration vers EnvelopedData. Pour des raisons de complétude et de cohérence, le type EncryptedValue a été échangé dans toutes les occurrences dans [RFC4210]. Cela inclut la protection des clés privées générées de manière centralisée, le chiffrement des certificats et la protection des phrases de révocation. Pour différencier correctement le support d'EnvelopedData au lieu d'EncryptedValue, la version 3 de CMP est introduite dans le cas où une transaction est censée utiliser EnvelopedData.

  • Offrir un champ hashAlg optionnel dans CertStatus qui prend en charge la confirmation des certificats signés avec des algorithmes de signature, par exemple, en préparant les algorithmes post-quantiques à venir, n'indiquant pas directement un algorithme de hachage spécifique à utiliser pour calculer le certHash.

  • Ajout de nouveaux types de messages généraux pour demander des certificats CA, une mise à jour de CA racine, un modèle de demande de certificat ou une mise à jour de liste de révocation de certificats (Certificate Revocation List, CRL).

  • Extension de l'utilisation du polling à p10cr, certConf, rr, genm et messages d'erreur.

  • Suppression du profil d'algorithme obligatoire dans l'Annexe D.2 de [RFC4210] et référence à la Section 7 de CMP Algorithms [RFC9481].