Résumé

  • RFC 9879 place PBMAC1 et l’ensemble de ses paramètres dans le DigestAlgorithmIdentifier de MacData.
  • PBKDF2 avec HMAC-SHA-256, une longueur de clé keyLength explicitement indiquée et des mots de passe convertis directement en UTF-8 forment la base de l’interopérabilité.
  • Les RFC décrivent une syntaxe et des contrôles, sans démontrer un support universel, une certification de produit ou une sécurité valable pour tout modèle de menace.

La limite d’intégrité du PFX est le MAC calculé sur le contenu d’authSafe. Lorsque PBMAC1 est utilisé, le DigestAlgorithmIdentifier de MacData l’identifie et ses paramètres imbriqués transportent deux choix distincts : la fonction de dérivation fondée sur le mot de passe et le schéma d’authentification du message. Ces paramètres doivent être traités comme des entrées de sécurité.

Les champs hérités macSalt et iterations de MacData sont le principal point de confusion. RFC 9879 les ignore pour le traitement PBMAC1, tout en conseillant aux producteurs d’écrire des valeurs non vides et non nulles afin de franchir les contrôles préalables de certains lecteurs anciens. Ces valeurs de compatibilité ne deviennent pas pour autant le sel ou le nombre d’itérations actifs de PBMAC1. Les utiliser comme tels produit des dérivations différentes.

La base obligatoire est PBKDF2 avec HMAC-SHA-256. Dans ce profil, le paramètre keyLength doit être indiqué explicitement dans les paramètres PBKDF2 ; son omission ne doit pas être acceptée et un lecteur ne doit pas en inventer la valeur. Le mot de passe est encodé directement en octets UTF-8, sans caractère nul final ni marque d’ordre des octets. Cette règle ne doit pas être confondue avec l’encodage historique des mots de passe PKCS #12.

Le choix du KDF et celui du MAC restent séparés. Les identifiants et les paramètres des deux algorithmes doivent être validés. HMAC-SHA-1 est déconseillé et les fonctions de hachage dont la sortie est inférieure ou égale à 160 bits sont interdites pour PBMAC1. Une clé dérivée de moins de 20 octets devrait être rejetée. Il s’agit de contrôles de conformité, non d’une promesse qu’un mot de passe faible devient robuste, ni d’une protection de confidentialité : le sujet est l’intégrité.

scrypt est facultatif. Son acceptation exige néanmoins la validation de ses paramètres et de son coût en ressources : mémoire, calcul, parallélisme et limites opérationnelles. Aucune valeur de coût n’est déclarée suffisante pour tous les environnements. Les sources ne prouvent pas non plus que les implémentations PKCS #12 déployées prennent en charge PBMAC1.

La migration doit être coordonnée entre producteurs et lecteurs. Les producteurs génèrent les paramètres PBMAC1 imbriqués, keyLength, les octets UTF-8 directs et des algorithmes conformes. Ils peuvent conserver des champs hérités non vides pour la compatibilité, mais ceux-ci ne sont pas des entrées de sécurité PBMAC1. Les lecteurs valident avant la dérivation, refusent les paramètres faibles ou ambigus et bornent le coût. Une fenêtre de compatibilité documentée et limitée est préférable à une acceptation indéfinie.

Sources