요약

  • 2025년 8월에 Informational RFC로 공개된 RFC 9787은 미완성 초안을 보호하는 것과 최종 수신자를 위한 메시지를 보호하는 것을 명확히 구분합니다. 보호된 초안은 작성자만을 위한 것이며, 수신자 대상 암호화는 실제 전송 시점에 이루어져야 합니다.
  • 상호운용성 경계에서 어려운 문제는 기기 간 키 보관입니다. 다른 메일 사용자 에이전트(MUA)가 암호화된 초안을 이어서 작업하려면 메일박스와 적절한 사용자 소유 복호화 키 자료에 모두 접근할 수 있어야 합니다. RFC 9787은 MUA 간 보안 인증서와 비밀 키 공유의 필요성을 인정하면서도 그 조율 문제를 미해결로 남겨두었습니다.
  • 준수하는 MUA는 초안에 사용자의 평상시 서명 키를 적용해서는 안 됩니다. RFC가 우려하는 것은 작성자에게 일반적으로 연결되는 서명이 초안이 유출될 경우 작성자가 아직 의사표시로 선택하지 않은 내용이 마치 확정된 것처럼 보이게 할 수 있다는 점입니다. 이는 의미와 증거에 관한 프로토콜 설계상의 우려이며, 법적 효과에 대한 보편적 진술이 아닙니다.
  • IMAP과 JMAP은 초안 상태를 식별하고 전송으로의 전환을 모델링할 수 있지만, 이러한 저장 메커니즘 자체가 암호학적 권한 경계를 정의하지는 않습니다. 운영자는 여전히 어떤 객체가 비공개 작성물이었는지, 어떤 클라이언트가 이를 변경할 수 있었는지, 최종 수신자 대상 객체가 실제로 언제 존재하게 되었는지 알아야 합니다.

명시적으로 가설적인 전환을 상상해 보겠습니다. 사용자가 한 기기에서 여러 단락을 입력합니다. 클라이언트가 이를 원격으로 자동 저장합니다. 이후 다른 기기가 같은 메일박스를 열고 그 단락들이 작성 화면에 다시 나타납니다. 이러한 연속성은 유용하지만, 두 가지는 여전히 거짓이어야 합니다. 잠정적으로 수신자로 나열된 사람들이 아직 그 단락을 읽을 수 있는 권한을 얻어서는 안 되며, 다시 나타난 텍스트가 의도적으로 전송되어 평상시 서명된 메시지가 가질 수 있는 작성자 의사표시의 암호학적 신호를 동일하게 지녀서는 안 됩니다.

바로 이것이RFC 9787 섹션 9.5가 다루는 좁지만 중요한 경계입니다.

RFC 9787은 2025년 8월에 공개된Informational문서입니다. 표준 트랙(Standards Track) 사양이 아닌 구현 지침입니다. 그러나 이 초안 지침은 준수하는 MUA에 대해 규범적 요구 언어를 사용하며, 그 구분은 이례적으로 명확합니다. 저장, 재개, 전송은 하나의 암호학적 객체를 둘러싼 단순히 세 가지 사용자 인터페이스 시점이 아닙니다. 서로 다른 접근 범위와 서로 다른 의도의 증거를 요구할 수 있습니다.

초안은 작성자 전용 보안 상태입니다

많은 MUA가 미완성 메시지를 Drafts 폴더에 저장합니다. 이 폴더가 원격인 경우 — IMAP 메일박스가 RFC가 드는 명백한 예입니다 — 미완성 메시지를 평문으로 저장하면 사용자의 직접 통제 밖 인프라에 내용이 노출될 수 있습니다.

시점이 중요합니다. 작성이 진행 중일 때 MUA는 완성된 메시지가 결국 보호될지 알지 못할 수 있습니다. 사용자는 그 결정을 늦게 내릴 수 있습니다. 따라서 RFC 9787은 MUA가 완성된 메시지가 평문이 될 것임을 알거나 Drafts 폴더를 잠재적 공격자가 읽을 수 없음을 알지 않는 한, 모든 초안을 암호화해야 한다(SHOULD)고 규정합니다.

이때 암호화 대상은 예상 수신자 집합보다 의도적으로 좁습니다. 보호된 초안은 사용자 자신의 인증서, 또는 그 사용자만 소유한 동등한 비밀 키 자료로만 암호화되어야 하며(MUST), 의도된 수신자는 자신의 주소가 이미 작성 화면에 나타나 있다는 이유만으로 복호화할 수 없어야 합니다.

이것은 유용한 권한 모델을 만듭니다.

작성 중에는 암호화가 미완성 콘텐츠의 보관을 보호합니다. 아직 접근을 분배하지는 않습니다.

전송 시점에는 암호화를 실제 수신자를 위해 재구성할 수 있습니다.

이 두 가지는 서로 다른 주체를 가진 서로 다른 행위입니다. 이를 하나의 작업으로 취급하면 RFC가 보존하려는 구분이 무너집니다.

RFC 9787은 전송 경계를 명시합니다. 메시지는 실제 전송 시에만 수신자에게 암호화되어야 합니다. 그 근거는 직관적입니다. 사람들은 일반적으로 발신자가 작성을 끝내고 전송하기 전에 수신자가 메시지에 접근할 수 있다고 기대하지 않습니다.

더 어려운 문제는 두 번째 클라이언트입니다

단일 기기 초안 보호는 개념적으로 단순합니다. 원격 사본을 같은 클라이언트가 나중에 사용할 수 있는 키 자료로 암호화하면 됩니다.

아키텍처가 까다로워지는 지점은 기기 간 사례입니다.

한 MUA에서 저장한 암호화된 초안이 다른 곳에서 다시 열리려면, 두 번째 MUA는 메일박스 자격 증명만으로는 부족합니다. 그 보호된 초안에 적합한 복호화 가능 비밀 키에도 접근할 수 있어야 합니다. 그렇지 않으면 메일박스는 암호문을 동기화하면서 사용자의 편집 상태는 이식 불가능하게 됩니다.

RFC 9787은 이 조율 문제가 해결되었다고 주장하지 않습니다.부록 A.4.1은 로컬 인증서와 비밀 키의 MUA 간 공유를 미래 과제로 명시합니다. 같은 메일박스에 연결된 여러 MUA가 사용자의 암호학적 자료를 효율적이고 안전하게 공유할 방법이 필요하다는 것입니다. 문서는 세부 사항을 현재 범위 밖으로 남겨둡니다.

부록 A.4.2는 휴대 가능한 하드웨어 기반 비밀 키를 또 다른 가능성으로 검토하면서 마찬가지로 세부 지침을 범위 밖으로 둡니다.

이 미해결 경계를 성숙한 메시지 암호학의 존재 뒤에 숨겨서는 안 됩니다.S/MIME 4.0과OpenPGP는 메시지를 위한 암호학적 기제를 제공합니다. 그 존재가 초안 전용 기기 간 키 조율이 광범위하게 배포되었거나, 일관되게 구현되었거나, 제품 간 상호운용 가능하다는 것을 입증하지는 않습니다. 이 근거 집합에서 검토된 어떤 출처도 그러한 보편성을 확립하지 않습니다.

따라서 운영상의 질문은 단순히 "이 메일박스가 암호화된 이메일을 저장할 수 있는가?"가 아닙니다. 질문은 이것입니다. 승인된 모든 작성 클라이언트가 동일한 진화하는 초안을 식별하고, 최신 유효 버전을 복호화하고, 다른 클라이언트의 작업을 잃지 않고 갱신하며, 작성자 전용 초안 보호와 전송 시점의 수신자 대상 보호 사이의 구분을 유지할 수 있는가?

서명은 다른 종류의 경계를 만듭니다

암호화는 누가 초안을 읽을 수 있는지를 통제합니다. 서명은 별개의 질문을 제기합니다. 서명의 소유가 다른 당사자에게 작성자에 대해 어떤 진술을 할 수 있도록 허용하는가?

RFC 9787은 좁게 답합니다. 준수하는 MUA는 사용자의 평상시 서명 키로 초안에 서명해서는안 됩니다(MUST NOT). RFC는 미완성 텍스트에 부인 불가능한 서명을 붙이면, 초안이 의도된 보관에서 벗어났을 때 의사표시를 함축할 수 있다고 설명합니다.

이것을 모든 서명이 모든 관할권과 맥락에서 동일한 효과를 가진다는 보편적 법률 규칙으로 확대해서는 안 됩니다. 검토된 자료는 그러한 명제를 확립하지 않습니다. 구현상의 요점은 더 단순합니다. 평상시 작성자 서명은 "이 바이트 시퀀스가 일시적으로 내 작성 화면에 존재했다"는 것보다 더 많은 것을 의미하도록 의도되었습니다.

같은 사용자의 MUA 간 암호학적 조율을 위해, RFC 9787은 초안 서명용으로 별도의 키가 협상될 수 있다고 제안합니다. 그러나 그 메커니즘은 정의하지 않습니다.

이 구분이 중요합니다. "평상시 서명 키를 사용하지 말라"는 것은 명시된 지침입니다. "여기 표준화된 다중 기기 초안 서명 시스템이 있다"는 것은 아닙니다.

초안 플래그는 유용한 상태이지 완전한 의사표시 모델이 아닙니다

기존 메일 프로토콜은 이미 초안 메커니즘을 노출합니다.

IMAP4rev2는 작성이 완료되지 않은 메시지를 위한\Draft시스템 플래그를 정의합니다.RFC 6154는 초안 메시지를 위한\Drafts특수 용도 메일박스를 정의합니다.

JMAP Mail은$draft를 정의하고, 초안 생성과 대체를 기술하며, 성공적인 전송이 초안 상태를 제거하고 메시지를 Drafts에서 Sent로 이동시키는 전송 예제를 포함합니다.

이 메커니즘은 수명 주기 상태를 관찰 가능하게 만들기 때문에 유용합니다. 그러나 그 자체로 RFC 9787이 제기하는 암호학적 질문에는 답하지 않습니다. 서버는 객체가 초안으로 표시되어 있음을 알 수 있지만, 작성자만 복호화할 수 있다는 것을 증명하지는 못합니다. 상태를 Sent 쪽으로 이동시킬 수 있지만, 작성 중에 사용자의 평상시 서명 키가 보류되었음을 증명하지는 못합니다. 초안 플래그는 두 클라이언트가 편집을 올바르게 병합했는지, 또는 전송 후 이전 초안 버전이 어딘가 복구 가능한 채 남아 있었는지도 확립하지 않습니다.

저장 상태와 권한 상태는 겹치지만, 동일하지는 않습니다.

제안: 초안 의도 보관 영수증

실용적인 구현은 메시지 자체를 기록하지 않으면서 이 전환에 관한 소량의 증거를 보존할 수 있습니다. 저는 그 증거를초안 의도 보관 영수증(draft-intent custody receipt)라고 부를 것을 제안합니다. 이것은 편집적 제안이며, RFC 9787의 요구 사항이 아니고 그러한 형식이 표준화되거나 배포되었다는 주장도 아닙니다.

영수증의 목적은 하나의 좁은 감사 질문에 답하는 것입니다. 특정 전송 이벤트가 객체를 수신자 대상 메시지로 전환하기 전까지, 객체가 작성자 전용 초안 보관 상태에 유지되었는가?

그 목적을 위해 영수증은 다음만 기록해야 합니다:

  • 초안 객체 및 버전 참조;
  • 초안을 보유한 저장 엔드포인트의 클래스;
  • 작성자 전용 암호화 범위와 관련 키 클래스;
  • 이를 복호화하고 갱신할 권한과 기술적 능력을 갖춘 클라이언트;
  • 현재 버전에 대한 최후 기록자 또는 병합 상태;
  • 사용자의평상시 서명 키가 초안 서명에 사용되지 않았다는 확인. 이는 키가 기기에 없었다는 주장과 다릅니다;
  • 전송 전에 수신자 암호화가 적용되지 않았다는 확인;
  • 실제 전송 이벤트, 발신 클라이언트, 타임스탬프, 최종 수신자 집합을 대표하는 다이제스트;
  • 제출된 객체의 해시;
  • 전송 후 초안 정리 또는 톰스톤 처리의 결과;
  • 영수증에 대한 책임 있는 소유자와 만기 또는 검토 트리거.

영수증은 메시지 본문, 제목, 제한 없는 수신자 목록, 비밀 키, 자격 증명 또는 일반 메일박스 로그를 보존해서는 안 됩니다. 이것은 보관 전환에 관한 증거이지, 메일박스 옆에 별도로 세워진 제2의 감시 아카이브가 아닙니다.

이 제한된 필드조차도 주의가 필요합니다. 일반 해시는 자동으로 익명화된 데이터가 아닙니다. 낮은 엔트로피 값은 때때로 추측될 수 있고, 별도의 기록은 상호 연관될 수 있으며, 반복되는 다이제스트는 기저 값이 직접 저장되지 않았더라도 동일성을 노출할 수 있습니다. 따라서 수신자 집합 다이제스트는 키 기반 구조가 필요하거나, 정의된 목적과 짧은 보존 기간을 갖춘 엄격하게 접근 통제된 증거 시스템 내부에 배치되어야 할 수 있습니다. 제출 객체 해시도 재사용이 원치 않는 상호 연관을 허용한다면 동일한 처우를 받아야 합니다.

중요한 속성은 절제입니다. 영수증은 초안 암호화가 비공개로 유지하려던 바로 그 정보의 내구성 있는 사본이 되지 않으면서 보안 상태 전환을 재구성할 만큼만 충분해야 합니다.

근거가 확립하지 않는 것

여기서 근거 경계는 명시적으로 유지되어야 합니다.

RFC Editor의RFC 9787 정오표 검색은 이 기사의 검토 시점 기준으로 일치하는 RFC 9787 정오표를 표시하지 않았습니다.

검토된 출처는 공급업체가 섹션 9.5를 얼마나 널리 따르는지, 원격 평문 초안이 얼마나 자주 유출되는지, 특정 제품이 상호운용 가능한 초안 전용 키를 구현하는지, 유출된 서명된 초안이 어떤 법적 효력을 받는지, 또는 표준화된 MUA 간 초안 키 교환이 등장했는지를 확립하지 않습니다.

이것들은 별개의 경험적 질문입니다. 보안 모델이 질문을 명확하게 만든다는 이유만으로 추론으로 채워서는 안 됩니다.

출처