Summary

  • The 2 November draft-ietf-rpp-core-01 adds explicit redirection rules to the working group's proposed RESTful Provisioning Protocol. It is an Internet-Draft, with no RFC or deployment claim.
  • An RPP server can redirect only with HTTP 307 or 308 and an absolute HTTPS Location. A client may follow, but must preserve the request body and headers, including its transaction identifier.
  • Credentials stay under a separate rule: a different origin receives neither Authorization nor RPP-Authorization unless it is a known alias or the client has credentials valid for that new origin.

A forwarding address is not a power of attorney

A registry can change the address of its provisioning desk. That mundane operation becomes less mundane when a registrar is carrying a request that can create, update or transfer a domain record. The revised RPP core draft answers the awkward part: a new URL can receive the operation, but the redirect itself cannot authorize a new holder of the registrar's credentials.

The 2 November revision adds a redirection section. Servers must use 307 or 308, the HTTP codes that preserve the method, and put an absolute HTTPS URL in Location. A client is allowed to follow. If it does, it sends the same content and headers, including RPP-Cltrid, so the redirected operation keeps its transaction identity. A 301 or 302 from a server or intermediary is a protocol error, not an invitation to let a generic web library turn a write into a read.

The sharper clause concerns the keys. When the destination has a different origin, the client must withhold Authorization and RPP-Authorization. There are two specified routes across that boundary: the client knows the new origin is an alias of the old one, or it holds credentials valid for the new origin and uses those credentials there. That test belongs to the client. The registry's redirect cannot simply nominate a stranger as a recipient for old secrets.

The same revision adds a server-identity check. Before any request leaves, the client must validate the TLS certificate chain and confirm that the certificate matches the URL hostname. Failure stops the request. Discovery and redirection can point to a machine; certificate validation tests the machine that answers. Those are distinct receipts of authority, which is exactly why a polished migration notice cannot substitute for a working trust decision.

The draft belongs to the RPP working group and maps its proposed data objects to HTTP. It has not been published as an RFC and supplies no evidence of production deployment or a redirect incident. The news is the boundary written into the proposed protocol: the operator who controls the forwarding address does not, by that fact alone, control the registrar's credential release.

Original sources