요약

  • RFC 3029는 데이터 검증·인증 서버(Data Validation and Certification Server)를 정의했으며, 서버가 서명한 결과는 검증이 실패했다는 사실을 진실하게 담을 수 있었습니다. 서비스 실행, 응답의 진본성, 대상의 유효성은 서로 별개의 사실이었습니다.
  • 데이터 검증 인증서(Data Validation Certificate)는 요청 또는 메시지 인쇄본(imprint), 시각, 일련번호, 정책, 집계 상태, 상세 결과를 결합했으므로, 의존하는 쪽은 응답 자체와 그 판정의 의미를 모두 검증해야 했습니다.

‘certificate(인증서)’라는 단어는 위험한 지름길을 유혹합니다. 들어보면 휴대 가능한 승인처럼 들립니다. 그러나 공개키 체계에서 인증서는 매우 다양한 종류의 주장을 담을 수 있으며, 그중에는 신중하게 인증된 ‘부정적’ 주장도 포함됩니다. RFC 3029는 검증 서비스의 서명된 산출물을 “데이터 검증 인증서”, 곧 DVC라고 불렀습니다. DVC는 제출된 객체가 건전하다는 약속이 아니었습니다. 서버가 정책으로 한정된 진술을 그 객체에 대해 산출했다는 약속이었습니다.

이 구분은 이례적으로 솔직했습니다. 규격은DVCSCertInfo구조가 데이터 검증 서비스의 성공적인 실행 이후 반환된다고 명시한 직후, 실행의 성공이 검증의 성공을 함축하지는 않는다고 경고합니다. 이 구조는 유효한 결과도 유효하지 않은 결과도 담을 수 있습니다. 요청은 형식에 맞고 접수되어 처리될 수 있고, 응답은 서버에 의해 올바르게 서명될 수 있으며, 그럼에도 대상 서명이나 인증서는 실패할 수 있습니다.

네 가지 서비스, 네 가지 서로 다른 명제

RFC 3029는 데이터 검증·인증 서버를 신뢰된 제3자로 기술하고 네 가지 서비스를 제시했습니다. 이름은 비슷했지만 각 서비스가 뒷받침할 수 있는 사실은 호환되지 않았습니다.

데이터 보유 인증(Certification of Possession of Data,cpd)은 실제 데이터를 제출해야 했습니다. 그 결과는 요청자가 표시된 시각에 해당 바이트를 보유하고 서버에 전달했다는 명제를 뒷받침할 수 있었습니다. 데이터 보유 주장 인증(Certification of Claim of Possession of Data,ccpd)은 대신 메시지 다이제스트를 접수했습니다. 서버는 요청자가 그 인쇄본을 제출했다는 사실은 인증할 수 있지만, 원본 바이트를 관찰한 것은 아니었습니다. 서비스 유형 없이 두 결과를 모두 “보유 증명”이라고 부르면 가장 중요한 증거적 차이가 지워집니다.

디지털 서명 문서 검증(Validation of a Digitally Signed Document,vsd)은 수학적 서명 확인을 넘어섰습니다. 서버는 적용 가능한 정책 아래에서 인증서 경로, 상태 정보, 신뢰를 점검할 수 있었습니다. 공개키 인증서 검증(Validation of Public Key Certificates,vpkc)은 경로 및 폐기 정보를 포함하여 지정된 시각의 하나 이상의 인증서를 평가했습니다. DVCS는 CRL, OCSP, 디렉터리 또는 다른 검증 서비스를 참조할 수 있었지만, RFC 3029는 대규모 개방형 환경에서 DVCS를 CRL이나 OCSP의 확장 가능한 대체물로 제시하지 않았음을 분명히 했습니다.

따라서 네 서비스는 서로 다른 질문에 답했습니다. 바이트가 제출되었는가, 인쇄본이 제출되었는가, 서명된 문서가 선택한 검증 규칙을 충족하는가, 인증서가 특정 시각의 경로·상태 규칙을 충족하는가. 하나의 초록색 “검증됨” 배지는 이 넷을 하나로 뭉개 버렸을 것입니다.

서명된 응답은 구조화된 영수증이었다

DVC는 CMSSignedData객체였습니다. 그 안에서 RFC 3029는 판정의 여러 조각을 분리해 두었습니다. 요청 정보는 서비스와 관련 요청 맥락을 식별했습니다. 메시지 인쇄본은 결과를 제출된 자료에 결합했습니다. 엄격히 증가하는 일련번호가 인증서를 구별했습니다. 응답 시각은 행위를 기준에 고정하며, 그 자체가 외부 타임스탬프 토큰이나 다른 DVC에서 올 수 있었고, 그 경우 서버는 그것을 검증해야 했습니다. 정책 필드는 사용된 규칙을 식별했습니다. 집계 상태가 결과를 요약하며, 인증서별·서명별 요소가 개별 결과와 이유를 보존할 수 있었습니다.

이 해부가 중요한 이유는, 봉투에 대한 서명이 클라이언트가 의도한 질문을 물었는지도, 답이 애플리케이션이 가정하는 의미를 갖는지도 증명하지 않기 때문입니다. RFC 3029는 요청자에게 수용 가능한 시각, DVCS 신원, 요청 정보, 메시지 인쇄본, 서명, 상태, 서비스, 정책을 점검하라고 지시했습니다. 요청자는 또한 DVCS 서명 인증서를 평가해야 했습니다. 그 점검을 마친 후에야 응답을 인증된 검증 진술로 사용할 수 있었습니다.

정책 필드는 장식이 아니었습니다. 두 검증 서비스는 같은 객체를 받고 서로 다른 방어 가능한 결과에 도달할 수 있었습니다. 서로 다른 신뢰 루트를 믿고, 서로 다른 인증서 정책을 받아들이고, 서로 다른 수의 서명을 요구할 수 있기 때문입니다. 따라서 휴대 가능한 증거는 “객체 X는 모든 곳에서 유효하다”가 아니라 “서버 Y는 시각 T에 정책 P 아래에서 요청 및 인쇄본 Q에 대해 결과 R을 반환했다”였습니다.

집계 결과는 혼합된 집합을 감출 수 있었다

문서와 인증서 집합은 경계를 더 선명하게 만들었습니다. 인증서 검증에서 집계 실패는 하나 이상의 요소가 실패했다는 뜻일 수 있었고, 항목별TargetEtcChain데이터가 무엇이 실패했는지 식별했습니다. 서명된 문서의 경우 하나의 잘못된 서명이 문서 전체를 자동으로 무효화하지는 않았습니다. 정책은 충분한 서명 집합만 요구하고grantedWithMods를 반환할 수 있었습니다. 반대로 개별적으로 올바른 서명들이라도 정책이 더 많은 서명자나 다른 조합을 요구하면 불충분할 수 있었습니다.granted는 모든 서명이 성공적으로 검증된 경우에만 사용됩니다.

따라서 요약 상태는 판정의 대체물이 아니라 판정으로 들어가는 색인이었습니다. 집계 필드만 복사한 대시보드는 특정 의존 당사자에게 중요한 실패한 서명자를 숨길 수 있었습니다. 수학적으로 올바른 모든 서명을 표시한 대시보드도 정책 수준의 실패를 놓칠 수 있었습니다. RFC 3029는 어느 쪽도 다른 쪽을 안전하게 대신할 수 없기 때문에 두 층위를 모두 인코딩했습니다.

WAITING은 시간 차원을 더했습니다. 이는 최종 응답이 아직 없으며, 이후 처리는 서비스 정책에 맡겨져 있음을 뜻했습니다. 이는 소프트한 성공이 아니었습니다. 대기 토큰을 허가로 취급하면 불완전한 증거를 권한으로 바꾸게 됩니다.

서명된 부정 결과는 오류 응답이 아니었다

RFC 3029는 인터페이스가 흔히 합치는 두 종류의 실패도 분리했습니다. 서비스가 실행되었다면 DVC는 인증된 부정적 검증 결과를 담을 수 있었습니다. 요청을 실행할 수 없다면 — 예컨대 구문 분석이 불가능하거나 요청자 인증이 실패한 경우 — 서버는 대신 오류 통지를 반환할 수 있었습니다. 첫째는 검증 질문에 “아니오”로 답한 것이고, 둘째는 서버가 그 질문의 본체까지 도달하지 못했다는 뜻이었습니다.

더 어려운 경계도 있었습니다. DVCS가 유효한 서명을 만들 수 없다면 — 가령 서명 키가 침해된 것으로 알려진 경우 — 서명자 정보 없이 CMS 구조에 오류를 담아 반환할 수 있었습니다. 클라이언트는 그 서명되지 않은 응답을 치명적이고 결정적인 것으로 취급하고, 그 내용을 암묵적으로 신뢰해서는 안 되도록 요구받았습니다. 서명 없는 “무효” 메시지는 인증된 부정 증거가 아니었습니다. 응답 권위 자체의 실패였습니다.

이 규칙은 흔한 역전을 막습니다. 애플리케이션은 서명 없는 오류를, 그 문구가 신중하게 들린다는 이유로 신뢰하면서도, 바라는 긍정 결과가 없다는 이유로 서명된 부정 DVC를 불신임해서는 안 됩니다. 서명된 부정 결과는 귀중한 증거가 될 수 있습니다. 서명 없는 오류는 DVCS의 권위를 조용히 물려받을 수 없습니다.

실험은 신뢰를 옮겼을 뿐, 판단을 지우지 않았다

RFC 3029는 인터넷 표준이 아니라 실험적(Experimental) 문서로 공개되었습니다. 저자들은 구현을 권할 만큼 안정적이지만 표준화 절차에는 아직 이르다고 기술했습니다. 이후 RFC 3379는 위임된 경로 검증 요구사항을 분리했고, RFC 5055는 SCVP를 표준화했습니다. 이 후속 문서들은 맥락을 제공할 뿐, 2001년 프로토콜의 채택이나 성공을 증명하지 않습니다.

RFC 3029의 역사적 중요성은 다른 곳에 있습니다. 증거의 형태를 보존하면서 기술적 검증을 중앙화하려 시도했다는 점입니다. 서버에 대한 신뢰는 서명된 DVC 안으로 옮겨졌지만, 결과는 여전히 서비스, 정책, 인쇄본, 시각, 상태에 묶여 있었습니다. 의존하는 애플리케이션은 그 진술이 자신의 목적에 수용 가능한지 여전히 판단해야 했습니다.

출처

Lu Heng은 RFC 3029나 관련 PKIX 표준을 저술하거나 승인하지 않았습니다. 그의 에세이는 여기서 공개된 분석적 관점으로 사용됩니다.