Résumé

  • La RFC 10004 ne définit pas une conformité CMC unique : elle distribue les exigences entre entités, clients, serveurs, entités finales, autorités d’enregistrement et autorités de certification.
  • La preuve exploitable relie version, rôles, fonctions conditionnelles, algorithmes, configuration, trajet de la transaction et résultat. Une case cochée au niveau du produit ne couvre pas cette chaîne.

Trois autorités d’enregistrement séparaient les demandeurs de l’autorité de certification. La première filtrait selon le type de demande, la deuxième validait certaines identités et la troisième intervenait pour des clés particulières. Chacune disposait d’une attestation de conformité CMC. Aucune attestation ne disait quelle demande avait traversé quelle autorité.

Ce scénario est hypothétique. Il ne décrit ni prestataire ni infrastructure réelle. Il éclaire une phrase structurante de la RFC 10004 : quand plusieurs RA existent, le routage peut dépendre du contenu et il est normal que toutes ne voient pas toutes les demandes.

CMC commence par une relation client-serveur. Dans le cas simple, l’entité finale demande et la CA émet. Dès qu’une RA s’interpose, elle devient serveur envers le demandeur et client envers l’émetteur. Plusieurs RA peuvent s’enchaîner. Le mot « conforme » doit donc recevoir un complément : conforme dans quel rôle, sur quel côté de quelle relation et pour quelles fonctions ?

La RFC 10004 distingue six ensembles d’exigences : toutes les entités, tous les clients, tous les serveurs, les EE, les RA et les CA. Ces ensembles se superposent. Un appareil n’est pas placé une fois pour toutes dans une colonne ; sa place dépend de l’arête observée et de l’usage configuré.

Les structures de messages et de contrôles appartiennent à la RFC 10002, tandis que la RFC 10003 traite du transport. La RFC 10004 ajoute les obligations de mise en œuvre. Sa fiche RFC Editor et la recherche d’errata fixent l’édition exacte à laquelle rattacher une conclusion.

Le socle commun est substantiel. Toutes les entités doivent prendre en charge les requêtes PKI complètes, les réponses simples et complètes, la syntaxe CRMF et le transport HTTP. Les serveurs devraient accepter les requêtes simples et la syntaxe PKCS numéro 10. Mais ce socle ne décrit pas encore le parcours acheté par l’exploitant.

Le tableau des contrôles répartit MUST, SHOULD, MAY et obligations conditionnelles entre EE, RA et CA. Certaines fonctions deviennent impératives lorsque la CA est conçue pour travailler avec des RA. Une entité finale doit renforcer sa prise en charge de Response Body quand une RA valide l’identité ou génère une clé. Encrypted POP et Decrypted POP varient avec l’accord de clés, le matériel incapable de signer et la délégation de la preuve de possession.

La conformité peut donc changer à configuration constante du logiciel. Activer une fonction, ajouter une RA ou déplacer la validation d’identité fait entrer de nouvelles exigences dans le périmètre. Le binaire peut être identique et le verdict différent.

La matrice cryptographique porte la même logique. RSA-SHA256, AES, AES-GCM avec tailles prescrites et transport de clé RSA forment une base. DH, PBKDF2, AES Key Wrap et HMAC-SHA256 apparaissent selon les chemins employés. RFC 5652 fournit CMS, RFC 5754 l’usage de SHA-2 et RFC 5084 l’enveloppe authentifiée.

Une liste de primitives installées n’est pas une trace d’exécution. Elle ne dit pas quel algorithme a été négocié ou sélectionné, quel contrôle a été traité, ni si le message a atteint l’agent compétent. Elle ne dit pas davantage si la CA a autorisé l’émission.

La preuve de possession rend cette responsabilité visible. La CA doit l’imposer avant l’émission, mais peut la déléguer à une RA dans des cas bornés. La méthode DH est détaillée par la RFC 6955. Une preuve d’audit doit donc identifier l’agent, la méthode, la demande, la règle de délégation et ce que l’autorité suivante a reçu.

Le temps modifie encore le verdict. La RFC 10004 remplace la RFC 5274 et intègre la RFC 6402. Elle élève notamment le socle cryptographique vers SHA-256. Elle autorise une offre d’algorithmes plus anciens pour compatibilité, tout en recommandant la transition des certificats concernés. La compatibilité est une population à réduire, pas un droit sans échéance.

Après l’enrôlement commence un autre régime de preuve. La RFC 5280 encadre les certificats et la validation de chemin. Une implémentation CMC conforme ne prouve ni le droit substantiel à l’identité, ni l’acceptation du chemin par un relying party, ni l’autorisation applicative.

Les couches de réalité de Heng Lu empêchent de fondre standard, capacité, configuration, transaction, émission et usage dans un seul voyant. La primauté du code exécuté demande d’observer le comportement. La spécification initiale minimale réserve le noyau commun à des éléments contrôlables et laisse les décisions futures à l’opérateur identifiable.

Le bon livrable n’est donc pas un certificat de conformité général. C’est un reçu par rôle : version logicielle, RFC et errata, graphe EE-RA-CA, direction client-serveur, fonctions conditionnelles, algorithmes actifs, version de politique, route de la demande, contrôles traités, décision POP et réponse finale. Une absence d’observation doit rester une absence, pas devenir une validation implicite.

Sources