요약

  • RFC 1805는 신뢰받는 제삼자가 파일 해시, 날짜, 작성자 확인 방법을 담은 증명서에 서명해 저장 위치와 상관없이 파일 내용을 대조하도록 제안했다.
  • 작성자 확인 방식은 프로토콜이 고정하지 않았다. Bellcore의 Betsi 구현은 전화 안내에서 번호를 찾아 되걸어 등록 정보와 공개키를 확인했다.

파일을 복사하면 주소는 쉽게 바뀐다. 그 파일을 만들었다고 적힌 사람이 정말 누구인지는 복사 버튼이 해결하지 못한다. Aviel Rubin이 1995년 6월 발표한 RFC 1805는 바로 이 틈을 다뤘다. 작성자, 이용자, 신뢰받는 제삼자가 등장한다. 파일은 믿기 어려운 배포 장소를 거쳐도 좋다. 내용과 날짜는 별도로 서명한 증명서로 살핀다. 그런데 Bellcore의 Betsi 예에서 작성자의 신원을 확인하는 장면은 뜻밖에 아날로그다. 해당 도시의 전화 안내에서 번호를 얻어 다시 전화를 건다.

Rubin은 검사 프로그램마저 의심했다. 공격자가 파일뿐 아니라 그 파일을 검사하는 소프트웨어도 바꿨다면, 화면의 ‘문제없음’은 자기소개일 뿐이다. 그래서 설계는 ASCII 메시지와 널리 쓰이는 서명 방식을 이용했다. 이용자는 검사기를 직접 만들거나 독립적인 믿을 만한 경로에서 얻을 수 있다. 특정 프로그램 하나에 모든 판정권을 주지 않고, 여러 주체가 다시 확인할 수 있는 작업으로 나눴다.

절차는 작성자 등록, 신원 확인, 파일 인증, 배포, 이용자의 무결성 검증이라는 다섯 단계다. 두 번째 단계는 일부러 한 방식으로 못 박지 않았다. 상황에 따라 다른 신원 확인을 쓸 수 있지만, 어떤 방법을 썼는지는 뒤의 증명서에 밝혀야 한다. 디지털 서명은 메시지와 키를 이어 준다. 그 키의 주인이 등록된 작성자인지 판단하려면 별도의 확인이 필요하다. RFC가 설명한 미국의 Betsi 구현은 지역 전화 안내로 번호를 찾고, 전화를 걸어 등록 내용과 공개키를 확인했다. 모든 구현에 전화를 강제한 규칙은 아니었다.

등록이 끝난 작성자는 파일의 암호학적 해시를 계산해 서명한 인증 요청을 제삼자에게 보냈다. 제삼자는 요청을 확인하고, 해시와 해시 함수, 날짜, 작성자 이름, 신원 확인 방법을 넣은 증명서에 다시 서명했다. 요청서의 파일 위치는 선택 항목이었다. 이 선택 항목이 설계의 중심을 드러낸다. 인증 대상은 특정 FTP 폴더의 주소가 아니라 파일의 바이트와 시간이다. 파일과 증명서를 함께 들고 가면 배포 서버 자체를 신뢰하지 않아도 대조할 수 있다.

받는 사람은 검사를 처음부터 자기 손으로 해야 한다. 독립된 여러 출처에서 제삼자의 공개키를 확인하고, 그 키로 증명서 서명을 검증한다. 증명서에 적힌 작성자 확인 방식이 납득할 만한지도 판단한다. 실제 받은 파일을 해시해 인증된 값과 비교하고, 날짜가 중요하다면 날짜를 살핀다. 마지막으로 제삼자의 최신·완전한 서명된 폐지 목록을 확인한다. 이미 폐지된 증명서를 예쁜 도장 때문에 믿는다면 도장은 장식이 된다.

이 과정을 통과해도 말할 수 있는 범위는 구체적이다. 정해진 신원·폐지 조건 아래 손에 든 바이트가 어느 시점에 인증된 바이트와 맞는다는 것이다. 프로그램을 실행해도 안전한지까지 증명서가 대신 결정하지는 않는다. 전화 한 통이라는 세부 사항은 구식 풍경이 아니다. 파일의 위치는 자유로워졌지만, 작성자라는 이름에 책임을 붙이는 일은 여전히 현실의 확인 절차를 요구했다.