Résumé

  • Une consultation finale ouverte le 2 septembre porte sur la version 29 du projet d’attestation dans les demandes de certificat. Les commentaires sont attendus avant le 16 septembre.
  • Si plusieurs vérificateurs prennent en charge le même identifiant de format, la règle permettant de choisir le destinataire doit être précisée dans la spécification de ce format.

Une liste de formats acceptés paraît être une bonne fiche de compatibilité. Pour une demande de certificat accompagnée de preuves sur un équipement, elle peut pourtant laisser une question entière sans réponse : à quel service ces preuves seront-elles confiées ?

Le dernier appel à commentaires annoncé par IESG le 2 septembre offre un cas précis. Il concerne la version 29 de draft-ietf-lamps-csr-attestation, proposée pour le statut Proposed Standard. L’échéance est le 16 septembre. Le texte demeure un projet ; ni son approbation comme RFC ni son déploiement ne découlent de l’annonce.

Il propose une structure commune pour transporter des attestations dans les demandes PKCS#10 et CRMF. Les formats normalisés comme propriétaires peuvent y trouver place. Une autorité de certification ou d’enregistrement, CA ou RA, peut vérifier les éléments elle-même ou faire intervenir un vérificateur externe.

Le destinataire ne se déduit pas toujours du format

La section 4.3 de la version 29 envisage plusieurs vérificateurs compatibles avec le même identifiant d’objet, ou OID, de format d’attestation. Elle recommande soit des OID distincts pour les types de vérificateur ou de vérification, même lorsque la structure est identique, soit une enveloppe comportant une indication explicite. Le mécanisme précis d’acheminement et de choix du nonce revient à la spécification du format.

Un OID n’est donc pas présenté comme une adresse de serveur. Il indique une représentation que plusieurs destinataires peuvent comprendre. Il faut encore une convention pour sélectionner le contexte de traitement attendu. Le projet commun désigne le lieu où cette convention doit être définie, sans l’imposer uniformément à tous les formats.

Dans une intégration, cette répartition attribue une responsabilité tangible à l’auteur du format et à l’équipe qui en maintient la correspondance opérationnelle. Modifier cette correspondance peut changer le service chargé d’évaluer les preuves. Une déclaration de compatibilité gagne ainsi à expliquer la convention utilisée et le traitement d’une indication manquante ou contradictoire, au-delà du simple décodage.

Ne pas confondre les deux niveaux d’identifiants

Le registre IANA des attributs S/MIME affiche encore la valeur 59 sous le nom id-aa-evidence. Le projet demande de conserver ce numéro en le renommant id-aa-attestation. Il s’agit de l’attribut extérieur de la demande, pas d’un annuaire de services de vérification.

Pour les OID des formats transportés à l’intérieur, la section 4.2 laisse l’attribution aux auteurs des spécifications, à partir d’une branche d’identifiants qu’ils contrôlent. Les deux niveaux n’ont pas la même fonction ni le même responsable. Consulter l’enregistrement extérieur ne permet pas de reconstituer les règles d’orientation d’un déploiement.

RFC 9334 explique l’enjeu de cette orientation : le propriétaire du vérificateur définit la politique d’évaluation des preuves ; celui de la partie utilisatrice définit comment exploiter le résultat. Choisir un service peut donc sélectionner un cadre d’évaluation, et non seulement un lecteur du bon format. Une même organisation peut cumuler les rôles sans effacer leur différence.

Pour un exploitant, un essai utile consisterait à varier les conditions d’orientation prévues tout en gardant le format constant, puis à vérifier le destinataire retenu. C’est une proposition de contrôle, pas une obligation supplémentaire attribuée à l’IETF. Le projet conserve par ailleurs à la CA ou RA la responsabilité de vérifier le lien entre l’attestation et la clé publique demandée.

Les sources consultées ne documentent ni incident d’acheminement ni coût de changement de prestataire. Elles montrent une frontière de conception soumise à consultation : un transport commun facilite l’échange, tandis que la sélection du service repose encore sur un accord explicite.

Sources

  1. Appel final d’IESG
  2. Projet d’attestation des CSR, version 29
  3. Architecture RATS, RFC 9334
  4. Attributions SMI d’IANA