Résumé

  • Publiée le 2 novembre, la version draft-ietf-rpp-core-01 ajoute des règles de renvoi au protocole RPP proposé par un groupe de travail IETF. Le texte reste un Internet-Draft.
  • Le serveur doit employer 307 ou 308 et une adresse HTTPS absolue. Si le client suit, il reprend le contenu et les en-têtes de la requête, notamment RPP-Cltrid.
  • Une autre origine ne reçoit pas les en-têtes d'autorisation, sauf si le client connaît une relation d'alias ou possède des identifiants valables pour cette nouvelle origine.

La nouvelle porte ne possède pas les clés

Un registre peut déménager son guichet technique. Pour un bureau d'enregistrement qui y envoie une opération sur un nom de domaine, le détail décisif n'est pourtant pas l'adresse affichée. C'est le moment où un logiciel décide d'envoyer la requête, puis les secrets qui l'accompagnent, à la machine indiquée.

La révision du 2 novembre pose d'abord une discipline sur le trajet. Le serveur ne peut renvoyer qu'avec les codes HTTP 307 ou 308, qui conservent la méthode, et une adresse HTTPS absolue. Le client peut suivre cette indication. S'il le fait, il doit garder le contenu ainsi que les en-têtes, dont RPP-Cltrid. Une opération ne doit pas perdre son identité transactionnelle pendant le détour. Tout autre code de redirection, même produit par un intermédiaire, devient une erreur de protocole.

Vient ensuite la question que les déménagements informatiques aiment escamoter. Si l'origine change, le client ne doit pas transmettre Authorization ni RPP-Authorization. Le texte prévoit deux cas précis: il sait que la destination est un alias de l'origine initiale, ou il dispose d'identifiants valides pour cette destination et emploie alors ces derniers. Un renvoi n'est donc pas une délégation de confiance que le registre peut s'accorder à lui-même.

La vérification du serveur forme un troisième verrou. Avant d'envoyer une requête, le client doit valider la chaîne du certificat TLS et la correspondance entre certificat et nom d'hôte de l'URL. S'il échoue, rien ne part. Le protocole prévoit une découverte des serveurs; découvrir une adresse, authentifier celui qui répond et décider de lui confier des identifiants restent trois actes différents.

RPP est ici un projet de groupe de travail, sans publication en RFC ni déploiement attesté dans ces sources. Son apport vérifiable est plus net qu'une promesse de modernisation: il définit qui peut déplacer la requête et qui garde la main sur ses secrets.

Sources originales