요약

  • RFC 1036은 중재 뉴스그룹 게시물에Approved:줄을 요구했고, 중재자가 메일 주소를 추가해 승인이 뉴스 소프트웨어에 보이도록 해야 한다고 규정했다.
  • 이 헤더는 암호학적 자격 증명이 아니라 라우팅과 입장 신호였다. 훗날의 역사적 초안은 명시적으로, 표시된 승인은 인증될 수 없다고 밝혔다.

결정은 게시물과 함께 이동해야 했다

Usenet은 최종 중앙 승인본을 받는 단일 서버가 아니었다. 게시물은 각자 선별한 뉴스그룹을 교환하고 자체 로컬 저장소를 유지하는 사이트들 사이를 이동했다. 따라서 중재 규칙은 중재자를 직접 아는지 여부와 무관하게 소프트웨어를 거쳐 전파될 수 있어야 했다. 게시물에는 일반 전파가 가능한 상태인지, 아니면 여전히 검토 대기열에 있어야 하는지를 기계가 판독할 수 있는 표시가 필요했다.

1987년 12월 Usenet 메시지 교환 표준으로 발행된 RFC 1036은 이 표시에 짧은 이름을 부여했다:Approved. 이 필드는 선택 헤더의 일반 목록에 나왔지만, 중재 그룹에 대한 규칙에서는 필수였다. 중재자가 이를 “추가해야 하며(should)”, 값은 중재자의 메일 주소여야 한다. 주소는 유용했다. 책임 있는 사람에게 되돌아가는 경로를 식별하고 소프트웨어가 인식할 수 있었기 때문이다. 그러나 이 문서는 수신 사이트가 그 주소를 검증할 수 있는 서명, 키 또는 신뢰할 수 있는 디렉터리를 설명하지 않았다.

이 문구는 독자가 쉽게 혼동할 수 있음에도 두 가지 역할을 분리해 놓았다. 중재된 게시물은 인간의 결정 지점을 통과했을 것으로 기대됐다. 헤더는 소프트웨어에 그 결정이 게시물 안에 표현되었음을 알렸다. 그러나 검토 자체를 보여주거나, 중재자가 적용한 기준을 말하거나, 결정을 내린 사람이 누구인지 증명하지는 않았다. “Approved”는 상태를 명명했고, 주소는 연락처를 명명했다. 어느 쪽도 인증된 행위의 영수증이 아니었다.

하나의 필드가 게시물과 그룹 제어 메시지를 모두 커버했다

RFC 1036의 예시는 이 표식에 구체적인 형태를 부여한다. 1986년 10월 1일자 독자 요약 게시물이news.lists와news.groups에 크로스포스팅된 형태로 등장하며,Approved필드에 중재자의 주소가 적혀 있다. 함께 실린Xref는seismo호스트의 로컬 게시물 번호를 기록한다. 이 예시는 주소 모양의 승인 표식이 일반 뉴스 게시물의 일부로 이동하는 모습을 보여줄 뿐, 중재자들이 이 필드를 얼마나 자주 사용했는지, 각 사이트가 이를 어떻게 확인했는지는 알려주지 않는다.

이 헤더는 더 중대한 상황에서도 나타났다. RFC 1036은 그룹 생성을 요청할 수 있는newgroup제어 메시지를 설명하며, 중재 그룹으로 생성하는 옵션도 포함한다. 사이트들은 헤더에Approved가 포함되지 않은 그런 메시지는 무시하도록 지시받았다. 모든 호스트에서 그룹을 제거할 것을 요청하는rmgroup메시지도 같은 요건을 적용받았다. RFC는 제거가 네트워크 전체에 영향을 미치기 때문에 주의를 강조했다. 여기서 이 표식은 뉴스 소프트웨어가 일반 제어 메시지와 승인 주장이 담긴 메시지를 구별하도록 도왔다. 그럼에도 암호학적으로 검증된 권한을 식별하지는 못했다.

이 재사용은 설계상 긴장을 드러냈다. 메시지 형식은 결정을 자기 인증 없이도 분산 시스템 전반에서 판독 가능하게 만들 수 있었다. 각 사이트는 필드가 존재해야 한다는 규칙을 적용할 수 있었지만, 필드의 존재 자체만으로는 표시된 메일박스가 인정된 중재자나 그룹 관리자의 것임을 입증할 수 없었다. 프로토콜은 공통 검사점을 제공했고, 그 뒤의 신뢰는 로컬 운영에 의존했다.

훗날의 초안은 신뢰 공백을 명명했다

“Son of 1036”의 역사는 연대를 신중하게 따져야 한다. RFC 1849는 1990년대 초에 널리 회람되었고 그 저자에 따르면 뉴스 소프트웨어 구현자들에게 사실상의 참고 문서가 된 초안을 보존하기 위해 2010년 3월 Historic 문서로 발행되었다. 이 문서는 자신이 현재 구현 지침이 아니라 역사적 배경임을 명시적으로 밝힌다.

이 회고적 문서는 소프트웨어 경계를 더 명확히 했다. 투고 에이전트는 로컬 사용자의 제출물을 처리한다. 게시물을 준비하고, 규격 준수 여부를 확인하며, 배포로 넘길 수 있다. 릴레이어는 다른 릴레이어로부터 이미 준비된 게시물을 받아 사본을 다음으로 옮긴다. 중재 그룹에 대해Approved가 없는 게시물은 투고 에이전트가 중재자에게 보내야 하는 독자 기고였다. 릴레이어는 승인되지 않은 게시물을 이메일 요청으로 바꾸는 대신 폐기해야 했다. 같은 프로그램이 두 역할을 모두 수행할 수 있었지만, 책임은 서로 교환 가능하지 않았다.

초안은 이 한계를 직접 서술했다.Approved헤더를 인증하여 주장된 승인이 실제로 이루어졌음을 확인할 방법이 없었고, 합법적 승인자의 현행 목록을 확립하는 유지되는 메커니즘도 없었다. 초안은 암호학적 인증을 가치 있는 확장으로 제안하면서, 실시간으로 키 서버에 접근할 수 없는 시스템에서는 문제가 어렵다고 밝혔다. 이 관찰은 초안의 서술에 한정되며, 특정 위조 사건이 발생했거나 모든 사이트가 위조된 필드를 수용했다는 증거가 아니다.

이후의 프로토콜인 RFC 5537은 주입 경로를 정형화했다. 주입 에이전트는 승인되지 않은 게시물을 가장 왼쪽의 중재 그룹 중재자에게, 관행상 이메일로 전달한다. 승인과 주입은 일상적 릴레이와 별개로 유지된다. 이 후기 명세는 분업을 명시적으로 만들 수 있음을 보여줄 뿐, 이를 1980년대 모든 뉴스 설치 환경에 그대로 투영해서는 안 된다.

표식이 이룬 것, 그리고 남겨둔 것

Approved:줄은 암호학적 증명이 없다는 이유로 무의미하지 않았다. 이는 널리 떨어진 뉴스 소프트웨어들에게 게시물 처리를 위한 공통 조건과 중재를 위한 실용적 주소를 제공했다. 편집상의 결정을 분산 출판 시스템과 함께 이동할 만큼 휴대 가능하게 만든 것이다. 그러나 그 휴대성은 헤더를 둘러싼 신뢰 구조의 가장자리에서 멈췄다.

이 구별이 바로 역사적 요점이다. 네트워크는 승인에 대한 주장을 운반할 수 있었지만, 텍스트만으로 그 주장의 배후 권한을 추론할 수는 없었다. 인간의 검토, 주소 관리, 로컬 정책, 소프트웨어 처리는 여전히 서로 다른 부분이었다. 표준은 결정이 나타날 자리를 만들었을 뿐, 누가 결정을 내렸는지 증명하는 보편적 메커니즘을 만들지 않았다.

출처