요약

  • RFC 1505는 메시지 파트에 대한 순서화된 설명과 디코딩 절차를 선택적 메일 헤더에 담았다. 올바른 파싱은 어떤 변환을 시도할지 식별할 수 있었지만, 그 결과가 안전하고 신뢰되며 인가되었는지는 증명할 수 없었다.
  • 동일한 형식은 셸 아카이브를 설명하거나 파일 시스템 소유자, 그룹, ACL, 비밀번호, 애플리케이션 속성을 담을 수 있었다. 규격은 자동 SHAR 실행을 경고하고, 보호 조치의 적용 여부는 디코더를 제어하는 애플리케이션 도메인의 판단으로 남겼다.
  • 줄 수, 디코딩된 바이트 수와 CRC, 등록된 키워드, 심지어Signature라는 단어조차 서로 다른 종류의 근거였다. 어느 하나만으로 발신자 권위, 로컬 정책, 실제 실행, 관찰된 효과를 연결할 수 없었다.

디코딩 성공 후 기다리던 명령

1993년 메일 리더가SHAR로 표시된 파트를 받는 장면을 상상해 보자. 프로그램은 파트에 할당된 줄 수를 세고, 텍스트 래핑을 제거해 셸 아카이브를 드러낸다. 형식 수준의 모든 검사는 성공할 수 있다. 그러나 그것이 절차의 끝이 아니다. 그것은 전혀 다른 판단의 시작이다.

RFC 1505는 shar의 사용이 지원되기는 하지만 권장되지는 않는다고 밝혔다. 그 경고는 이례적으로 직접적이었다. 셸 아카이브는 수신자가 실행하기를 원하지 않는 명령을 포함할 수 있으므로, 디코더는 디코딩된 문장을 자동으로 실행해서는 안 된다는 것이었다. 이 경고는 수신 기계를 위한 명령을 담은 미래의 형식에도 똑같이 적용되었다.

디코딩이 하나의 연속된 동작처럼 느껴지기 때문에 이 구분은 흐려지기 쉽다. 그러나 실제로는 여러 권위가 관여한다. 메시지 작성자는 표현 방식을 설명할 수 있다. 레지스트리는 그 표현의 이름을 안정화할 수 있다. 디코더는 그것을 되돌리는 방법을 알 수 있다. 결과 프로그램이 동작할지는 로컬 애플리케이션이나 사용자가 결정한다. 운영체제는 실제로 무엇이 생성되거나 실행되었는지 기록한다. 이후의 관찰은 의도된 서비스가 변했는지를 보여준다.

RFC 1505는 앞의 세 계층을 조율할 수 있었다. 그것은 명시적으로 이들을 네 번째 계층에 통합하는 데까지는 나아가지 않았다.

표준 트랙 대안 옆에 놓인 실험적 헤더

Albert Costanzo, David Robinson, Robert Ullmann이 1993년 8월 RFC 1505를 발표했다. 이것은 실험적(Experimental) 문서였으며 인터넷 표준이 아니었고, 이들의 이전 문서인 RFC 1154를 대체했다. 첫 페이지의 IESG 노트는 이 영역에 표준 트랙 기술이 이미 존재한다고 지적했다. 바로 RFC 1341, 즉 MIME이었다.

이 당대 노트는 단순한 계승 서사를 막아선다. RFC 1505는 자연스럽게 오늘날의 MIME이 된 초기 초안이 아니었다. 그것은 MIME이 이미 표준 트랙에 존재하는 가운데 문서화된 경쟁 실험 접근이었다. RFC 2045를 포함한 이후 MIME 규격들은 RFC 1521, 1522, 1590을 거쳐 MIME 계보를 개정했다. 그들이 소급해 RFC 1505의 모든 선택을 MIME 계약의 일부로 만든 것은 아니다.

그럼에도 이 실험은 중요한 설계 질문을 보존한다. 오래된 소프트웨어가 읽을 수 있고 이질적인 메일 시스템을 통과하면서, 메시지는 얼마나 많은 구조를 압축된 헤더 안에서 선언할 수 있는가? RFC 1505는 구조적 설명을Encoding필드에 두고 본문에는 반복되는 래퍼 문법을 두지 않음으로써 이 질문에 답했다.

헤더는 파트와 변환의 지도였다

RFC 822는 빈 줄로 구분된 헤더와 본문으로 이루어진 메시지를 정의했다. RFC 1505는 본문이 하나 이상의 파트를 담을 수 있게 했고, 이 파트들 역시 빈 줄로 구분되었다.Encoding필드는 나타난 순서대로 파트를 나열했다. 각 항목은 텍스트 줄 수의 10진수로 시작해 하나 이상의 키워드가 뒤따를 수 있었다.

그 수에는 양쪽의 빈 구분 줄이 포함되지 않았다. 빈 줄이란 CRLF만 있는 줄을 뜻했다. 마지막 또는 유일한 파트는 자신의 줄 수를 생략할 수 있었다. 이 작은 규칙들이 중요했던 이유는, 수신 프로그램이 헤더를 이용해 그렇지 않으면 보통의 빈 줄과 시각적으로 구분 불가능한 경계를 찾아야 했기 때문이다.

중첩된 키워드는 여러 변환 또는 더 정밀한 유형을 설명했다. 그 순서는 의미를 가졌다. 디코더는 왼쪽에서 오른쪽으로 작동하고, 인코더는 자신이 수행한 변환의 역순으로 이름을 적었다. 예컨대uuencode LZW tar는 능력의 모음이 아니라 순서화된 복구 경로였다.

주석은 달랐다. 괄호 주석은 필드에 나타나 클라이언트에 전달될 수 있었지만, 독자들은 이를 내용 해석에 사용하지 말라고 지시받았다. RFC 1505는 따라서 같은 헤더 안에서 기계 관련 토큰과 설명하는 산문을 구분했다. 보이는 노트는 파서에 대한 통제권을 얻지 않은 채 사람을 도울 수 있었다.

“Signature”가 언제나 암호학적 증명을 뜻한 것은 아니다

어휘에는 또 다른 함정이 있었다. RFC 1505의Signature키워드는 메일이나 뉴스 메시지 끝의 보통 서명 영역을 식별했다. 거기에는 발신자 이름이나 좋아하는 문구가 들어갈 수 있었다. 이 키워드는Text Signature처럼 다른 유형 뒤에 중첩되어야 했다.

PEM, PEM-Clear, PGP는 별개의 키워드였다. 그 내부 형식은 암호화, 무결성 검사, 공개키 자료, 분리 서명을 담을 수 있었다. 그러나 거기서도 외부의 단어가 신뢰 판단을 마무리하지 않았다. PGP 예시는 어떤 프로그램이 그 블록을 이해하는지 디코더에게 알려줄 수 있었다. 검증에는 여전히 해당 바이트, 키 자료, 알고리즘 결과, 그리고 키와 주장된 이름에 대한 로컬 판단이 필요했다.

RFC 1505는 또한PGP뒤의 중첩 유형이 보이는 상태로 남아 보호된 내용이 텍스트인지 EDI 트랜잭션인지 드러낼 수 있다고 관찰했다. 성공한 암호화가 모든 트래픽 분석 신호를 지워주지는 않았다. 따라서 하나의 헤더가 형식, 변환, 표현에 대한 주장을 담으면서 기밀성, 인증, 신뢰는 서로 다른 근거에 맡길 수 있었다.

그렇기 때문에 대시보드는 이 모든 것을 녹색의 “서명됨” 배지 하나로 압축해서는 안 된다. 보통의 서명 사인오프, 암호학적 객체, 유효한 수학적 검사, 인가된 발신자는 하나의 사실을 네 가지로 적은 것이 아니다.

파일은 다른 시스템의 권한을 달고 도착했다

RFC 1505의 가장 야심적인 부분은 줄 수 헤더가 아니었다. FS 인코딩은 이질적인 운영체제 사이에서 구조화된 파일 시스템 자료를 운반하려 했다. 디렉터리는 파일, 항목, 더 깊은 디렉터리를 포함할 수 있었다. 파일은 데이터나 중첩된 세그먼트를 담을 수 있었는데, 여기에는 매킨토시 파일과 연관된 두 개의 포크도 포함되었다.

이 표현은 표시 이름, 주석, 유형, 생성 시각, 수정 시각, 접근 시각, 소유자, 그룹, 접근 제어 목록, 비밀번호, 블록 크기, 레코드 크기, 생성 애플리케이션을 운반할 수 있었다. 이것은 바이트를 옮기는 것 이상이었다. 바이트의 행정적 환경을 보존하려는 시도였다.

그러나 그 환경은 보편적 의미를 갖지 않았다. 한 컴퓨터의 수치 소유자는 다른 컴퓨터에서 무관한 계정을 가리킬 수 있었다.$GROUP이나$SYSTEM은 발신 측에서의 역할을 설명했을 뿐, 반드시 수신 주체를 뜻하지 않았다. 읽기, 쓰기, 실행, 삭제, 보호 변경을 위한 접근 문자에는 로컬 강제 모델이 필요했다. 시간조차 정밀도를 잃을 수 있었다. RFC 1505는 디코더에게 자신의 파일 시스템이 저장할 수 있는 정밀도를 넘는 부분은 무시하라고 지시했다.

따라서 디코더는 사영(projection)을 수행했다. 일부 사실은 재현할 수 있었고, 다른 것은 근사했으며, 로컬 동등물이 없는 것은 거부하거나 무시했다. 수신된 ACL은 발신자가 보호를 어떻게 설명했는지에 대한 근거였다. 수신 관리자가 내린 부여였지는 않았다.

평문 비밀번호가 드러낸 통제 경계

RFC 1505는 인코딩된 항목의 접근 비밀번호를 담는password속성을 허용했다. 항목의 내용은 어차피 뒤따르므로 평문으로 비밀번호가 나타나는 것 자체는 별도의 보안 문제로 다루지 않았다. 더 중요한 문장은 그 다음에 있었다. 디코더가 생성된 항목에 실제로 그 비밀번호를 설정한다면, 결과적으로 생기는 보안 또는 불안전은 ACL과 다른 보호 조치와 마찬가지로 디코더를 제어하는 애플리케이션 도메인의 몫이라는 것이었다.

이 문장은 위험한 추론을 막는다. 발신자는 비밀번호라 불리는 문자열을 공급할 수 있다. 그러나 이름만으로 그 문자열이 로컬 비밀로 될 것인지, 기존 보호를 덮어쓸 것인지, 계정 동등성을 만들 것인지, 수신자의 현재 정책을 충족할 것인지는 결정할 수 없다.

안전한 수신 경로는 발신 주장을 보존하고, 이를 로컬 제안으로 사상하며, 의미의 손실이 있으면 드러내고, 로컬 결정을 기록한다. 원천과 목적지의 보호 모델이 다를 때 보호 조치를 보이지 않게 복사하는 것은 충실함이 아니다. 그것은 권위의 무음 재할당이다.

카운트와 CRC는 더 좁은 것을 증명했다

RFC 1505의 LZJU90 인코딩은 ASCII-EBCDIC 변환 같은 조작을 견디도록 선택된 인쇄 가능 알파벳과 함께 압축을 결합했다. 그 출력은 원본 바이트 수와 CRC로 끝났다. 디코더는 압축 해제 중 얻은 바이트 수와 CRC와 이를 비교하도록 되어 있었다.

그 검사는 유용했다. 출력이 발신 측에서 인코딩된 바이트와 다르거나 압축 해제가 잘못되었음을 보여줄 수 있었다. 메시지 헤더의 줄 수는 다른 것을 증명했다. 파트에 속한 인코딩된 텍스트 줄이 몇 개인지였다. 어느 검사도 메시지를 보낸 사람을 인증하지 않았다. 어느 것도 키워드가 정직하게 할당되었음을 증명하지 않았다. 어느 것도 명령을 인가하거나 ACL을 수입하지 않았다.

올바른 근거 모델은 영수증을 분리해 두었다.

  • 헤더 파싱: 어떤 줄 범위와 순서화된 키워드가 선언되었는가;
  • 변환 영수증: 어떤 디코더와 버전이 어떤 바이트를 만들었는가;
  • 무결성 영수증: 길이, CRC 또는 암호학적 검사가 정의된 입력과 일치하는가;
  • 출처 영수증: 어떤 메시지, 발신자 주장, 전송 경로가 자료를 공급했는가;
  • 정책 영수증: 어떤 로컬 규칙이나 사람이 생성, 권한 사상 또는 실행을 허용했는가;
  • 효과 영수증: 어떤 파일, 프로세스 또는 서비스 상태가 실제로 변경되었는가.

영수증 하나가 빠져 있다면, 이후의 시스템은 가장 가까운 녹색 표시를 승격하는 대신 그 간극을 표시해야 한다.

등록은 방법의 이름을 붙였을 뿐 결과를 보증하지 않았다

RFC 1505는 IANA에 새 비전용 키워드를 등록하도록 요청하고, 구현 고유 용도로X-이름을 영구 예약했다. 등록은 충돌을 줄일 수 있었다. 두 구현자가 같은 문서화된 인코딩에 같은 이름을 쓸 가능성이 더 높아진다.

그러나 등록이 모든 디코더를 그 방법을 지원하게 하지는 않았다. 특정 구현이 메모리 안전한지, 공급된 바이트가 라벨과 일치하는지, 외부 참조가 계속 이용 가능한지, 활성 콘텐츠가 실행되어야 하는지를 보증하지 않았다. 레지스트리는 어휘를 조율했다. 실행되는 코드와 로컬 정책은 서로 다른 영수증을 공급했다.

이것이 이 문서의 실험 계열이 남긴 지속적 교훈이다. 이름과 순서가 공유되면 상호운용성이 개선된다. 그 공유된 설명이 명령으로 오해되지 않을 때 안전이 개선된다.

출처가 확립하지 않는 것

보존된 RFC들은 형식, 상태, 경고, 문서화된 계보를 확립한다. 그러나 얼마나 많은 시스템이 RFC 1505를 구현했는지, 어떤 특정 메일러가 그 FS 또는 SHAR 형식을 디코딩했는지, 누군가 악성 아카이브를 받았는지, 비밀번호나 ACL이 메시지로부터 실제로 설치된 적이 있는지는 보여주지 않는다.

RFC 1341과 RFC 2045는 MIME의 표준 트랙 발전을 문서화한다. 그러나 MIME이 RFC 1505를 공식적으로 폐기(obsoleted)했음을 증명하지는 않는다. RFC의 발행은 실행되는 코드를 증명하지 않는다. 체크섬의 일치는 저작을 증명하지 않는다. 등록된 키워드는 안전한 행동을 증명하지 않는다. 수신된 권한 목록은 로컬 주체를 만들어내지 않는다.

이 역사적 유물이 중요한 이유는 정확히 그것이 자신의 설명적 야망이 끝나는 지점을 명시하기 때문이다. 헤더는 기계에게 패키지를 여는 방법을 알려줄 수 있었다. 그러나 열린 패키지가 무엇을 할 수 있는지는 결정할 수 없었다.

출처