도메인이 메시지에 서명했다. 개인은 여전히 이름이 없었다: RFC 3183

요약

• RFC 3183은 조직 경계가 사용자를 위해 수행할 수 있는 실험적 S/MIME 서비스를 기술했지만, 유효한 도메인 서명이 외부 수신자에게 개인 이름이 밝혀진 발신자를 반드시 드러내지는 않았다.
• 기원(originator), 도메인, 검토, 추가 속성 서명은 서로 다른 행위를 나타냈으며, 도메인 암호화와 복호화는 다시 관리 주체를 바꾸었다. 이 모든 것을 '메시지가 서명되고 안전하다'로 묶어 버리면 이 설계가 보존하려던 증거가 파괴된다.

2001년 10월 한 수신자가 서명된 메시지를 연다고 상상해 보자. 암호학적 검증은 통과한다. 인증서는 도메인 서명자의 이름을 담고 있다. 메시지는 발신 조직의 검사를 통과했다. 그럼에도 인터페이스에는 Alice, Carlos, Fatima를 인증서에 묶인 발신자로 표시할 정당한 근거가 없다. 표시될 수 있는 것은 도메인뿐일 수 있다.

이것은 RFC 3183의 우연한 공백이 아니었다.Domain Security Services using S/MIME는 실험적(Experimental) RFC로 공표되며, 메시지 전송 에이전트, 가드, 방화벽, 프로토콜 변환 게이트웨이를 위한 체계를 정의했다. 이러한 시스템은 사용자가 데스크톱 공개키 인프라를 갖지 않았거나, 내부 형식이나 PKI가 상호운용되지 않았거나, 메일 저장소가 메일을 재형식화하거나, 정책상 경계에서 선별과 감사를 요구하는 조직을 지원할 수 있었다. 이 문서는 종단 간 데스크톱 보안과 도메인 기반 개입 사이의 정치적·아키텍처적 경쟁을 해결하지 않았다. 서로 다른 정책을 조립할 수 있는 부품들을 명시했을 뿐이다.

가장 시사적인 부분은 모든 서명이 같은 의미를 갖도록 하지 않은 점이다.

기원 서명(originator signature)은 발신자와 서명된 콘텐츠를 식별한다.도메인 서명(domain signature)은 사용자를 대신해 생성되는 프록시 서명이다. 도메인 서명자는 이를 발행하기 전에 발신자를 인증해야 한다. 내부 기원 서명을 검증하거나, 인증된 링크 같은 S/MIME 외부의 증거를 통해 인증하며, 의존하는 다른 서명들을 검증해야 한다. 이 검사가 실패하면 도메인 서명을 생성해서는 안 된다.

그러나 내부 인증과 외부 명명은 동일하지 않다. RFC 3183은 도메인 서명의 성공적 검증이 발신자를 인증할 수 있다고 말한 뒤, 표시 경계를 그린다. 기원 서명이 존재하면 수신자는 그 인증서가 담고 있는 개인 신원을 사용할 수 있다. 존재하지 않으면 수신자의 정당한 가정은 메시지가 기원한 도메인뿐이다. 도메인이 그 직원을 실제로 알았을 수 있다. 그럼에도 외부 수신자가 보유한 것은 해당 직원의 독립적으로 검증 가능한 인증서 신원이 아니라 도메인의 증명이다.

이 구분은 일반적인 제품 언어가 자주 하나로 뭉개는 적어도 네 가지를 분리한다. 사람이나 시스템이 어떤 콘텐츠를 만들었다. 발신 조직이 로컬 방식으로 누군가를 인증했다. 도메인 권한이 메시지의 표현을 공개하기로 결정했다. 수신자가 검증 가능한 도메인 서명을 관찰했다. 한 사건이 다음 사건을 뒷받침할 수 있지만, 어느 것도 나머지 전부의 동의어는 아니다.

검토 서명(review signature)은 또 다른 경계를 표시한다. 이는 명명된 검토자 또는 검토 권한이 메시지의 계속 전송을 승인했음을 말한다. 가드는 메일을 공개하기 전에 그 승인을 요구할 수 있다. 이 서명은 검토자를 저자로 만들지 않으며, RFC 3183은 이것이 발신자를 인증하지 않는다고 명시적으로 부정한다. 콘텐츠가 참이거나 안전하거나 법적으로 충분하거나, 전달되거나 접수되었음을 증명하지도 않는다. 이것이 증명하는 것은 더 좁은 행위, 즉 식별된 권한이 어떤 정책에 따라 계속 전송을 승인했다는 사실이다.

추가 속성 서명(additional-attributes signature)은 다른 방향으로 더 좁다. 이것은SignerInfo의 속성을 메시지에 바인딩한다. 올바른 검증은 어떤 서명자가 어떤 속성 바이트를 어떤 콘텐츠에 바인딩했는지 보여줄 수 있다. 그것만으로는 주장된 외부 사실이 이후의 결정에 대해 정확했는지, 최신인지, 권한이 부여되었는지를 확립할 수 없다. 암호학적 바인딩은 바인딩에 대한 증거다. 인코딩된 모든 속성을 현실로 자동 승격시키는 것이 아니다.

이 구분은 형식화된(typed) 증거에 의존했다. RFC 3183은 기원, 도메인, 추가 속성, 검토 서명을 위한 값들을 갖는 서명된SignatureType속성을 정의했다. 이후 검증된 정정(erratum) 문서인 Erratum 3757이 공표된 본문에서 누락된 속성 객체 식별자를 보충했다. PKCS 9 아치 아래1.2.840.113549.1.9.2.28에 위치한id-aa-signatureType이다. 이 수정은 구현에 중요했다. 소프트웨어가 주장을 파싱하려면 모호하지 않은 식별자가 필요하기 때문이다. 그러나 어떤 주장의 의미론도 확대하지 않았다. 라벨을 수복하는 것이 검토를 저작으로 바꾸거나 도메인 공개를 공개적으로 이름이 밝혀진 개인으로 바꾸지는 않았다.

암호화는 두 번째 권한 평면을 도입했다. RFC 3183의 도메인 기밀 권한(DCA, domain confidentiality authority)은 도메인을 위해 암호화하거나 수신자를 대신해 복호화할 수 있었다. 이는 운영 문제를 해결할 수 있었지만, 키 관리 권한과 평문을 조직 경계 너머로 옮겼다. 도메인 키는 여러 사용자에게 동시에 영향을 줄 수 있었다. 수신자의 DCA가 메시지를 복호화한 시점 이후에는 평문이 존재했다. DCA가 침해되면 최종 수신자는 권한의 보고만으로 무결성을 추론할 수 없다. 특히 수신자가 독립적으로 검증할 수 있는 서명이 남아 있지 않은 경우에 그렇다.

메일링 리스트와 중첩된 CMS 객체에 대한 이 RFC의 처리는 연산 순서가 왜 중요한지 보여준다. 게이트웨이는 한 계층을 검증하고, 봉투를 복호화하고, 선택된 서명 속성을 보존하고, 하나의 래퍼를 제거하고, 도메인 서명을 추가하고, 결과를 다시 암호화하며, 메일링 리스트 확장 이력을 또 다른 서명된 계층에 보관할 수 있다. 따라서 '서명됨'은 추상적 메시지의 안정적 속성이 아니다. 증거적 질문은 이렇다. 어떤 바이트가, 어떤 캡슐화 안에서, 어느 명명된 권한에 의해, 어떤 서명 유형으로, 어느 변환의 이전 또는 이후에 서명되었는가?

당대의 S/MIME과 Cryptographic Message Syntax 명세들이 컨테이너와 처리 어휘를 공급했다. 이후의 CMS, S/MIME, PKIX 문서들은 기준선을 변경하고 주변 표준을 명확히 했다. 이들은 RFC 3183이 광범위하게 배포되었음을 증명하지 않으며, 그 실험적 설계를 소급하여 인터넷 표준으로 만들지도 않는다. IANA 레지스트리는 할당된 식별자를 뒷받침할 수 있다. 할당은 사용의 증거가 아니다.

오래 남는 역사적 교훈은 게이트웨이가 좋았는지 나빴는지가 아니다. 권한을 구체적 행위들의 연쇄로 기록할 때 인프라가 더 잘 읽힌다는 것이다. 사람이 기원했다. 도메인이 인증했다. 검토자가 공개를 승인했다. 속성 권한이 주장을 바인딩했다. DCA가 복호화했다. 수신자가 관찰했다. 시스템이 초록 자물쇠나 불리언trusted값만 저장한다면, 메시지가 경계를 넘은 뒤 책임을 재구성하는 데 필요한 구분들을 정확히 그 자체로 버리는 것이다.