요약

  • 11월 2일 나온 draft-ietf-rpp-core-01은 IETF 작업반의 RESTful Provisioning Protocol 초안에 리디렉션 규칙을 추가했다. 아직 RFC가 아닌 인터넷 초안이다.
  • 서버는 절대 HTTPS 주소를 담은 HTTP 307 또는 308만 사용할 수 있다. 클라이언트가 따라가면 요청 본문과 헤더, 거래 식별자 RPP-Cltrid를 그대로 유지해야 한다.
  • 목적지가 다른 출처라면 Authorization과 RPP-Authorization은 자동으로 따라가지 않는다. 알려진 별칭 관계나 새 출처에서 유효한 별도 인증 정보가 있어야 한다.

새 창구를 가리킨다고 금고 열쇠를 받는 것은 아니다

등록소가 도메인 등록 서비스를 다른 서버로 옮기는 일은 흔한 설비 변경처럼 들린다. 하지만 등록대행자가 보내는 요청은 도메인 기록을 만들고 바꾸거나 이전할 수 있다. 기존 서버가 새 주소를 알려줄 때, 같은 거래가 온전히 넘어가는지와 새 서버가 인증 정보를 받아도 되는지는 별개의 문제다. RPP 핵심 초안의 이번 개정은 그 분리를 문장으로 못 박았다.

우선 이동 방식부터 제한한다. 서버는 메서드를 유지하는 HTTP 307 또는 308만 사용하고, Location에 절대 HTTPS URL을 넣어야 한다. 클라이언트는 따라갈 수 있다. 그때 요청 본문과 헤더를 그대로 보내고 RPP-Cltrid도 보존해야 한다. 우회해도 동일한 거래로 취급하기 위한 규칙이다. 중간 장비가 돌려준 것을 포함해 다른 리디렉션 코드는 프로토콜 오류가 된다.

민감한 부분은 인증 정보다. 출처가 달라지면 클라이언트는 두 인증 헤더를 보내서는 안 된다. 새 출처가 원래 출처의 별칭이라는 사실을 알고 있거나, 새 출처에 유효한 인증 정보를 따로 갖고 그 정보를 쓰는 경우에만 예외가 생긴다. 서버가 보낸 주소 표시는 길 안내일 뿐, 그 주소의 주인에게 등록대행자의 비밀을 받을 자격을 주지 않는다.

개정안은 요청을 보내기 전 TLS 인증서 체인과 URL 호스트 이름의 일치도 확인하도록 요구한다. 검증에 실패하면 요청 자체를 보내지 않는다. 서비스 위치를 발견하는 일, 응답 서버를 확인하는 일, 어느 인증 정보를 내어줄지 정하는 일은 서로 다른 승인 단계다.

이 문서는 작업반이 다듬는 초안이다. 공식 자료에는 실제 배포나 사고 사례가 없다. 확인된 변화는 운영 권한의 경계다. 등록소가 접속 주소를 바꿀 수 있다는 사실만으로 등록대행자의 자격 증명까지 움직일 수는 없다.

원문 자료