Resumen

  • La revisión draft-ietf-rpp-core-01, fechada el 2 de noviembre, incorpora una sección sobre redirecciones al protocolo RPP que estudia un grupo de trabajo del IETF. Sigue siendo un borrador.
  • Un servidor RPP solo puede responder con 307 o 308 y una URL HTTPS absoluta. Si el cliente continúa, conserva el contenido y las cabeceras, incluido RPP-Cltrid.
  • Ante un origen diferente, el cliente retiene Authorization y RPP-Authorization, salvo que conozca un alias o tenga credenciales válidas para el nuevo destino.

El atajo no firma la autorización

Una solicitud de aprovisionamiento de dominios no es una visita a una página web. Puede cambiar un registro y dejar una huella contractual. Si el servidor de un registro manda al registrador a otra dirección, importa qué operación llega allí y con qué credenciales. La versión del 2 de noviembre del núcleo de RPP escribe esas dos preguntas por separado.

Para la primera, fija un camino estrecho: 307 o 308, con una dirección HTTPS absoluta en Location. Esos códigos mantienen el método HTTP. El cliente puede seguir la indicación, pero debe reenviar el mismo cuerpo y las mismas cabeceras, incluido el identificador RPP-Cltrid. Así conserva la identidad de la transacción para el tratamiento de duplicados. Una redirección de otro tipo, incluso si sale de un intermediario, es un error de protocolo.

La segunda pregunta tiene más filo. El nuevo servidor no hereda las credenciales por aparecer en una cabecera Location. Si cambia el origen, el cliente no debe enviar las cabeceras Authorization ni RPP-Authorization. Puede hacerlo cuando sabe que el destino es un alias del original, o cuando posee credenciales válidas para el destino nuevo y usa esas credenciales. Es el registrador quien debe conocer esa relación, no la redirección quien debe inventarla.

La revisión también obliga al cliente a comprobar, antes de cada solicitud, la cadena del certificado TLS y su coincidencia con el nombre de host de la URL. Si falla, la solicitud no sale. Encontrar un servidor, verificarlo y confiarle un secreto son decisiones distintas. El registro controla la dirección que anuncia; el software del registrador controla la entrega del secreto.

El texto pertenece a un grupo de trabajo y todavía no es un RFC. Sus fuentes no documentan una implantación ni un incidente. La noticia está en una regla concreta de diseño: la comodidad de trasladar el servicio tiene un límite en el punto donde empieza la autoridad del cliente.

Fuentes originales