Résumé

  • Le bit SEP indique l’usage opérationnel prévu d’une clé DNSKEY. Il peut aider un outil à préparer un DS ou à gérer une clé, mais ne prouve ni son authenticité ni l’existence d’une chaîne de confiance.
  • Les RFC 4034 et 4035 interdisent aux validateurs de modifier leur comportement parce que le bit 15 est activé. Une clé marquée SEP doit aussi porter le bit Zone Key pour vérifier les signatures de RRsets.
  • Edward Lewis est l’un des trois coauteurs de la RFC 3757. Cette trace atteste une contribution à la norme, sans démontrer une paternité individuelle, une implémentation précise ou un emploi actuel.

Une indication n’est pas une preuve

Lorsqu’un opérateur remplace une clé DNSSEC, la mise à jour ne s’arrête pas dans la zone qu’il contrôle : le parent doit aussi publier le DS correspondant. Si les deux côtés ne concordent pas, un résolveur qui valide DNSSEC peut refuser de valider la délégation. Le bit SEP ne répare pas ce passage; il ne fait qu’indiquer à certains outils quelle clé l’opérateur entend utiliser. Cette limite donne un enjeu concret à la contribution d’Edward Lewis.

La RFC 3757, publiée en avril 2004 et cosignée par Olaf Kolkman, Jakob Schlyter et Edward Lewis, introduit SEP dans le champ des indicateurs DNSKEY. Le texte propose qu’il aide à produire des DS ou à repérer une clé destinée à une configuration statique. Il précise aussi que la vérification DNS ne s’appuie pas sur ce bit. Le nom peut donc sembler plus autoritaire que sa fonction réelle: SEP marque une intention de traitement, non un certificat.

Le parcours d’une clé montre où la distinction compte. L’opérateur de la zone enfant publie les DNSKEY. Un outil peut privilégier une clé signalée SEP lorsqu’il prépare le DS à transmettre au parent. Mais le parent doit encore vérifier puis publier le DS correspondant; l’indicateur de l’enfant ne peut ni confirmer cette correspondance ni prouver que la publication a eu lieu. Le résolveur, lui, doit suivre les règles DNSSEC applicables, indépendamment de l’intention encodée dans SEP.

Les RFC 4034 et 4035, qui remplacent la RFC 3757 en 2005, donnent à cette limite sa portée normative. La RFC 4034 qualifie SEP d’indication utile aux logiciels de signature ou de débogage. La RFC 4035 dit que le comportement de validation ne doit pas changer lorsque ce bit est activé. Une clé SEP doit toujours avoir le bit Zone Key pour pouvoir vérifier les signatures des ensembles d’enregistrements. Les deux bits répondent donc à des questions différentes: traitement souhaité d’un côté, rôle admissible dans la validation de l’autre.

La RFC 6781 décrit une convention fréquente: SEP sur la clé de signature de clé, ou KSK, et pas sur la clé de signature de zone, ou ZSK. Mais un déploiement à type de clé unique peut employer la même catégorie de clé pour plusieurs fonctions; les outils qui supposent toujours une séparation KSK/ZSK peuvent alors mal classer les enregistrements. C’est une raison d’inspecter le comportement réel des outils, non la preuve d’incidents ou d’une validation erronée.

SEP ne doit pas non plus être confondu avec le bit REVOKE de la RFC 5011. Cette dernière définit un mécanisme automatisé de mise à jour des ancres de confiance et son propre état de révocation. Les deux indicateurs se situent dans des opérations DNSSEC différentes.

La RFC 3757 situe Lewis parmi trois coauteurs. Son profil IETF répertorie cette RFC; sa page de contributeur à Internet Society apporte un contexte professionnel limité. Ces sources n’établissent ni qu’il aurait conçu seul SEP, ni qu’il aurait implémenté un déploiement particulier. La mention historique d’ARIN dans la RFC ne renseigne pas sur son emploi actuel. Et les normes décrivent le mécanisme, sans mesurer sa fréquence d’usage, ses taux d’erreur ou ses conséquences en production.

La conclusion sûre reste étroite: SEP peut guider un opérateur; seule la chaîne DNSSEC et les contrôles du parent peuvent établir ce que le réseau accepte comme confiance.

Sources