Résumé

  • RFC 5217 décrit un chemin de PKI1 vers PKI3 passant par PKI2, membre de deux domaines. Le chemin existe, mais sa validation selon la politique du domaine 1 ne doit pas réussir, car PKI1 et PKI3 ne partagent pas ce domaine.
  • Les certificats croisés rendent une route constructible. La décision d'accepter dépend encore du point de confiance, des politiques, des contraintes de noms, de l'état d'adhésion, de la révocation et du contrôle exécuté pour l'usage précis.

Une chaîne parfaite dans la mauvaise frontière

Le journal du validateur ne signalait aucune signature fausse. Il avait trouvé un certificat pour chaque étape, remonté jusqu'au point de confiance configuré et construit une chaîne sans trou. La dernière ligne disait néanmoins : rejet.

Lire cette ligne comme un échec technique serait effacer l'information la plus importante. Dans l'exemple de RFC 5217, PKI2 appartient à deux domaines. Un chemin va de PKI1 à PKI2, un autre de PKI2 à PKI3. La composition des deux rend PKI3 accessible depuis PKI1. Mais l'accès graphique ne crée pas une appartenance commune : PKI1 et PKI3 ne sont pas membres du même domaine 1. Avec la politique de ce domaine, la validation ne doit pas aboutir.

Le logiciel a découvert une route. Il n'a pas reçu pour autant le mandat de l'emprunter.

Construire précède juger

La construction d'un chemin cherche une suite ordonnée de certificats entre un ancrage de confiance et le certificat final. La validation reprend ce candidat et vérifie les politiques, les contraintes, les dates, les usages et les informations de révocation. Confondre les deux transforme une possibilité de calcul en décision de risque.

RFC 5217 conserve aux PKI participantes leurs propres identifiants de politique et leur propre autorité principale. Elles examinent les politiques de certification et les documents de gouvernance de leurs partenaires avant de définir une correspondance. Le certificat croisé donne une forme technique à cette relation ; il ne remplace ni l'examen ni son périmètre.

Un pont de certification élargit donc le graphe. Il peut éviter une multitude d'accords bilatéraux et simplifier la découverte des chemins. Il n'unifie pas toutes les finalités, toutes les garanties ni tous les niveaux d'assurance.

Le membre commun crée un raccourci, pas un mandat

La position de PKI2 est le cœur du problème. Son double rattachement relie deux ensembles jusque-là distincts. Sans restrictions explicites, cette position peut laisser croire qu'une confiance acquise d'un côté se propage automatiquement de l'autre.

RFC 5217 demande que la frontière utile soit portée par les certificats croisés, au moyen de correspondances de politiques, de contraintes de politiques ou de noms. Un domaine qui souhaite interdire un chemin ne devrait pas compter uniquement sur une préférence locale que chaque partie utilisatrice appliquerait peut-être différemment.

L'adhésion devient ainsi un état d'exploitation. Lorsqu'une PKI rejoint ou quitte un autre domaine, elle doit en informer les domaines concernés. Ceux-ci doivent réexaminer les contraintes de leurs certificats croisés. Si l'ensemble des chemins autorisés change, l'ancien certificat doit être révoqué et remplacé.

Une signature protège un document. Elle ne fige pas les relations que ce document encadre.

Le Bridge CA ne devient pas la racine de tous

Dans le modèle à pont, le Bridge CA organise des certifications croisées et réalise des correspondances de politiques. RFC 5217 lui refuse cependant le rôle d'ancrage de confiance d'un domaine participant. Il doit rester neutre et ne pas délivrer de certificats ordinaires aux entités finales.

Cette limite est institutionnelle autant que cryptographique. Un composant central peut rendre le système moins coûteux sans acquérir l'autorité générale. Chaque partie utilisatrice commence toujours par son propre ancrage et sa propre politique. Le passage par le pont reste soumis aux contraintes signées de chaque relation.

La liste de confiance révèle qui décide

Une liste locale permet à une partie utilisatrice d'installer directement plusieurs ancrages. Le procédé est simple, sans certification croisée obligatoire, mais chaque partie porte la maintenance. Une autorité de confiance peut gérer une liste commune pour plusieurs parties, ce qui mutualise le travail sans supprimer la décision.

Avant d'ajouter une PKI, il faut examiner sa politique, le niveau d'assurance, les obligations imposées à ceux qui se fient aux certificats, les garanties proposées et les avis de révocation ou de compromission. Ce contrôle doit être répété. Si l'organisation refuse d'hériter de la confiance accordée à d'autres membres d'un domaine, elle doit inhiber la correspondance de politiques.

La liste n'est donc pas un inventaire passif. Ajouter une autorité peut autoriser de nouveaux actes ; la retirer peut interrompre un service. Son propriétaire doit être identifiable et responsable du risque créé.

Produire un reçu d'autorité d'acceptation

Pour les usages sensibles, une preuve de chaîne ne suffit pas. Le reçu devrait lier l'identité de l'application, l'heure de décision, la version du moteur de validation, l'empreinte et l'origine de l'ancrage, la politique initiale et les options d'inhibition.

Il devrait conserver le chemin candidat exact, les correspondances et contraintes traitées à chaque étape, l'état des adhésions aux domaines, la version de la liste de confiance, la fraîcheur des CRL ou réponses OCSP, puis le résultat et l'action réellement permise ou refusée.

Il faut aussi garder la chaîne rejetée. Une route complète bloquée à la bonne frontière est une preuve positive de fonctionnement, pas un déchet de journalisation.

Limite de l'analyse

RFC 5217 est un mémorandum d'information et reconnaît d'autres manières de réaliser l'interopérabilité. Un chemin refusé dans un contexte peut être valable avec un autre ancrage, une autre communauté ou une autre finalité. Aucun défaut n'est attribué ici à une autorité ou à un produit réel.

La conclusion est plus étroite : signature, chemin, appartenance et acceptation sont quatre faits. Les réunir dans un seul voyant vert fabrique une autorité que la cryptographie n'a jamais accordée.

Sources

Registre complémentaire des normes

  1. RFC 5217 en texte brut
  2. Fiche d'information RFC 5217
  3. Dossier IETF Datatracker
  4. Historique IETF Datatracker
  5. RFC 4949 : glossaire de la sécurité Internet
  6. RFC 5914 : format des ancrages de confiance
  7. RFC 5934 : exigences de gestion des ancrages
  8. RFC 6024 : exigences de protocole de gestion des ancrages
  9. RFC 5055 : validation de certificats côté serveur
  10. RFC 6818 : mises à jour de RFC 5280
  11. RFC 6960 : protocole OCSP
  12. RFC 5019 : profil OCSP léger
  13. RFC 6962 : transparence des certificats
  14. RFC 7030 : enrôlement par transport sécurisé