요약

  • 2013년 4월의 RFC 6920은 해시 알고리즘과 결과값으로 디지털 객체를 가리키는 Named Information(ni) 이름을 정의했다. 두 이름이 같은 대상을 뜻하는지는 알고리즘, 길이, 값으로 판단하며 선택적인 호스트 이름은 그 판단에 들어가지 않는다.
  • ni 이름을 HTTP(S)의 /.well-known/ni/ 주소로 바꿔 서버에 파일을 요청할 수 있다. IANA 등록부는 알고리즘 이름과 길이를 관리한다. 파일 사본이나 사본을 가진 서버 목록을 보관하지는 않는다.
  • 클라이언트가 믿을 만한 경로로 이름을 받고, 파일을 찾아오고, 정해진 입력으로 해시를 계산해야 같은 바이트인지 알 수 있다. 특정 배포 사례에는 이 과정을 보여 주는 날짜가 확인되는 기록이 필요하다.

주소를 지켜도 내용은 바뀔 수 있었다

일반적인 URL은 어디에 물을지 알려 준다. 서버는 같은 경로에 새 파일을 놓을 수 있고, 오래된 링크는 계속 작동한다. 수시로 고치는 안내 페이지에는 좋은 성질이다. 정확한 버전의 프로그램이나 보고서를 전달할 때는 다른 문제가 된다. 예상한 호스트로 접속했다는 사실만으로는 예상한 바이트를 받았다는 결론에 닿지 못한다.

해시 결과를 이름에 넣는 방법은 이미 여러 곳에서 쓰였지만 표기는 제각각이었다. RFC 6920은 ni라는 공통 문법을 만들었다. 알고리즘 이름 뒤에 세미콜론을 넣고, 패딩 없는 base64url 형태의 해시 값을 붙인다. 기본 계산 입력은 가져올 것으로 기대하는 객체의 바이트다. 쓰는 프로토콜이 다른 입력을 원하면 그 규칙을 직접 정해야 한다.

이름과 주소는 다른 질문에 답한다. 주소는 “어느 서버를 찾아갈까”이고 해시 이름은 “어느 바이트를 받아들일까”다. 똑같은 사본이 다른 서버로 옮겨도 해시 이름은 유지된다. 한 서버가 원래 경로의 파일을 바꾸면 새 파일은 다른 값을 갖는다. 클라이언트가 검증한다면 서버는 경로를 지키면서 객체의 정체성까지 바꿀 수 없다.

RFC 6920은 두 이름의 비교에서 알고리즘, 값, 표시된 길이만 보도록 한다. 선택적인 authority와 질의 매개변수는 제외한다. 호스트가 서로 다른 ni 이름도 같은 파일을 가리킬 수 있다. 호스트는 찾는 데 도움을 주는 정보일 뿐, 바이트가 무엇인지를 결정하는 표가 아니다.

파일을 가져올 때는 다시 서버가 필요했다

지문만 들고는 보관 위치를 알 수 없다. RFC 6920은 ni 이름을 /.well-known/ni/ 경로를 쓰는 HTTP 또는 HTTPS URL로 바꾸는 방법을 제시했다. 이름에 authority가 있으면 그 호스트를 쓰고, 없으면 응용 프로그램이 상황에 맞춰 정할 수 있다. 서버는 다시 다른 주소로 안내할 수 있다. 결국 도착한 데이터에 대해 클라이언트가 계산하고 비교해야 한다.

이 URL에 파일이 있다는 보장은 없다. 표지가 맞는 빈 창고를 찾아갈 수도 있다. 아무것도 도착하지 않았다면 제공 경로의 문제다. 데이터가 도착했는데 해시가 다르면 정체성 또는 계산 입력의 문제다. 두 경우를 한꺼번에 “링크 오류”로 처리하면 누가 무엇을 고쳐야 하는지 흐려진다.

역할은 세 쪽으로 갈린다. 이름을 건네는 쪽이 기대한 바이트를 정한다. 서버 운영자가 후보 파일을 보관하고 건넨다. 클라이언트 개발자가 실제 비교 여부를 정한다. RFC 6920은 ni를 처리하는 모든 순간에 이름과 데이터의 결합을 검사하도록 강제하지 않는다. 문법을 채택한 프로그램이 곧 검증 프로그램인 것은 아니다.

문서는 짧은 전송에 맞는 바이너리 형태와 사람이 소리 내어 읽기 쉬운 nih 형태도 정의했다. nih에는 16진수와 검사 숫자가 쓰인다. 이름을 옮기는 방식이 늘어난 것이지, 그만큼 파일 보관소가 생긴 것은 아니다.

알고리즘 장부에 파일은 없다

서로 다른 구현이 같은 지문을 읽으려면 알고리즘 이름과 출력 길이에 합의해야 한다. IANA의 Named Information 등록부는 그런 이름과 길이, 참조 문서, 콘텐츠 유형을 나타내는 ct 매개변수를 싣는다. RFC 6920은 전체 SHA-256 지원을 요구하고 길이를 이름에 밝힌 짧은 형태도 허용한다. 값이 짧아질수록 충돌 여지는 커진다. 그래서 길이는 정체성 판단에 함께 실린다.

IANA의 한 줄은 알고리즘을 부르는 공통 어휘를 만든다. 거기에 어떤 문서의 사본이 저장되거나 그 문서를 가진 호스트가 기록되지는 않는다. 이 일의 범위가 좁기 때문에 공통 이름을 관리하는 곳이 모든 파일의 운영자가 되지 않는다. 실제 보관과 전송은 별도 시스템이 한다.

믿어야 할 곳도 한 군데 더 있다. RFC 6920의 보안 설명에 따르면 해시가 바이트의 일치를 보여 주는 힘은 처음 받은 이름을 얼마나 믿을 수 있느냐에 묶인다. 공격자가 악성 파일과 그 파일의 정확한 해시를 함께 주면 둘은 완벽하게 맞는다. 계산은 짝이 맞는지 알려 줄 뿐, 누가 기대값을 정했는지는 알려 주지 않는다. 공개된 해시는 추측하기 쉬운 내용의 후보를 찾는 데도 쓰일 수 있다.

공식 RFC와 등록부가 입증하는 것은 형식, 비교 규칙, HTTP 주소 변환이다. 특정 서비스가 이를 실제로 썼는지 알려면 이름을 전달받은 시점부터 가져온 파일을 계산한 결과까지 날짜가 확인되는 흔적이 필요하다. 2013년의 성과는 파일이 서버를 옮겨도 같은 파일임을 판별할 수 있는 이름을 마련한 데 있다.