요약

  • RFC 3125는 서명자가 전역적으로 고유한 정책 식별자와 확정적 정책 명세의 해시를 서명 과정에 결합하도록 요구하여, 검증자가 어떤 정확한 정책 바이트가 검증을 지배했는지 확립할 수 있게 했다.
  • 서명과 정책 해시의 일치가 판단의 끝이 아니었다. 서명 기간, 커밋먼트 유형, 인증서 및 폐기 규칙, 타임스탬프와 속성 신뢰, 알고리즘 제약, 기관적 승인, 거래 결과는 여전히 별개의 검사였다.

서명에는 서명 값 바깥의 규칙이 있었다

전자 서명은 좁고 강력한 질문 하나에 답할 수 있다. 선택된 알고리즘과 키 하에서 이 바이트들이 검증되는가? 그러나 비즈니스 거래는 더 많은 것을 묻는다. 이 인증서가 이 목적에 적합했는가? 서명이 허용된 기간 내에 만들어졌는가? 서명자가 승인, 저작 또는 수령을 주장했는가? 타임스탬프가 요구되었는가? 어떤 폐기 증거가 유효하게 계수되었는가? 알고리즘이 여전히 허용되는가? 누가 결과를 인정할 자격이 있는가?

2001년 9월에 실험적(Experimental) 문서로 발행된 RFC 3125는 이러한 질문들을 서명 정책(signature policy)으로 다루었다. 정책은 서명 유효성을 판단할 수 있는 일련의 생성·검증 규칙이었다. 법적 또는 계약적 맥락이 특정 정책을 자신의 요건을 충족하는 것으로 인정할 수 있었다. 신중한 동사는 "할 수 있었다(might)"였다. RFC의 발행이 그 어휘로 구축된 모든 정책에 법적 효력을 부여한 것은 아니었다.

이 문서는 여러 권한 주체를 명명했다. 서명 정책 발행자(Signature Policy Issuer), 서명자, 하나 이상의 검증자, 중재자(arbitrator), 그리고 지원하는 신뢰 서비스 제공자들이다. 발행자는 비즈니스 요구를 위한 기술적·절차적 요건을 정의한다. 서명자는 참조된 정책에 대해 서약한다. 검증자는 그 정책 하에서 검증해야 한다. 중재자는 분쟁 시 검증을 다시 수행할 수 있다. 이러한 역할들은 하나의 산출물을 공유하면서도 권한은 통합되지 않는다.

OID는 규칙을 가리켰지만 규칙 자체는 아니었다

RFC 3125는 참조된 정책이 개체 식별자(주체 Identifier)로 식별 가능하도록 요구했다. 또한 정책 명세가 실제로 존재하고, 그 확정적 형식 하나가 고유한 이진 인코딩을 갖도록 요구했다. 서명자는 합의된 알고리즘으로 그 확정적 명세의 해시를 제공했고, 검증자가 이를 확인했다.

이 체계는 실제의 모호성을 다루었다. "송장 서명 정책" 같은 이름은 여러 판본, 요약본, 번역본을 가질 수 있다. OID는 정체성을 선택할 수 있고, 해시는 거래를 정확한 확정적 바이트에 결합할 수 있다. 선택적 ASN.1 표현에서는 DER이 구조화된 형식에 대한 결정적 인코딩을 제공했다.

그러나 OID는 참조이지 승인 도장이 아니다. 일치하는 해시는 검증자와 서명자가 동일하게 인코딩된 정책 명세를 참조하고 있음을 확립한다. 그것은 발행자가 이 거래를 지배할 자격이 있었는지, 직원이 시스템 외부 절차를 따랐는지, 법원이나 거래 상대방이 정책을 인정하는지를 보여주지 않는다. 그것은 한 계층에서 정체성과 무결성을 해결할 뿐이다.

그리하여 문서는 기계 판독 가능한 형식을 허용하는 동시에 사람이 읽을 수 있는 형식도 요구했다. 소프트웨어가 규칙을 적용할 수 있었다. 사람들과 기관은 여전히 그 규칙이 법적·계약적 필요를 충족하는지 판단해야 했다.

하나의 정책은 여러 종류의 유효성을 담을 수 있었다

구조화된 검증 정책은 서명 기간, 공통 규칙, 커밋먼트 규칙으로 시작했다. 서명 기간은 서명 생성을 위한 not-before 시각과 선택적 not-after 시각을 명시했다. 암호학적으로 올바른 서명이라도 그 기간 밖에서는 수학적으로는 옳으면서 정책의 생성 규칙에는 부합하지 않을 수 있었다.

공통 규칙은 서명자·검증자 의무, 인증서 신뢰, 타임스탬프 신뢰, 속성 신뢰, 알고리즘 제약, 확장을 정의할 수 있었다. 커밋먼트 규칙은 선택된 커밋먼트 유형에 대한 이러한 조건들을 제공할 수 있었다. 정책은 승인(approval)을 수령(receipt)과 다르게 다룰 수 있었고, 명시적 커밋먼트 유형이 없을 때는 메시지 의미론에 의존할 수 있었다.

이는 "유효"의 의미를 조건부로 만들었다. 먼저 검증자는 올바른 정책 판본이 필요했다. 다음으로 적용되는 커밋먼트 규칙이 필요했다. 한 서명이 한 커밋먼트 유형은 만족하면서 다른 유형은 만족하지 않을 수 있었다. 같은 키와 콘텐츠라도 알고리즘 기한 전에는 수용 가능하고 기한 후에는 수용 불가능할 수 있었다. 한 적용 분야에서 신뢰된 인증서 경로가 다른 분야에서는 신뢰되지 않을 수 있었다.

이 틀은 이러한 구분을 주관적 잡음으로 만들지 않았다. 오히려 처리 과정에 대한 명시적 입력으로 만들었다. 그것은 일종의 자동화였지만, 기관 전체의 자동화는 아니었다.

신뢰 제공자들은 증거를 공급했지 하나의 보편적 판정을 내리지 않았다

RFC 3125는 정책이 사용할 수 있는 지원 제공자로 인증 기관과 등록 기관, 저장소, 타임스탬프 기관, 인증서 상태 응답기, 속성 기관을 열거했다. 인증서 신뢰 트리는 신뢰 지점을 명명하고 경로 길이, 인증서 정책, 이름, 정책 처리를 제약할 수 있었다. 폐기 요건은 필요한 증거를 식별할 수 있었다. 타임스탬프와 속성 규칙은 각자 자신의 신뢰 조건을 선택할 수 있었다.

각 서비스는 경계가 정해진 질문에 답했다. 인증서는 발행자 하에서 키와 주장된 신원을 연결했다. 상태 응답은 자신의 모델과 시간 내에서 인증서 상태를 기술했다. 타임스탬프는 데이터가 보고된 신뢰 시각 이전에 존재했음을 증명했다. 속성 기관은 역할 또는 속성 증거를 공급했다. 그중 어느 하나만으로 거래의 커밋먼트 유형이나 비즈니스 권한을 증명하지 못했다.

정책은 이 영수증들을 조립했다. 검증자는 여전히 어떤 영수증이 어느 제공자로부터, 어느 시각과 규칙 하에서 사용되었는지 보존해야 했다. 정책 OID, 확정 정책 해시, 커밋먼트 규칙, 검증 입력 없는 "초록불" 결과는 이후 분쟁에서 재현하기 어렵다.

절차는 소프트웨어가 관찰한 것을 넘어설 수 있었다

정책 발행자는 기술적·절차적 요건을 정의할 수 있었다. 일부는 CMS 서명에서 직접 검증 가능했다. 필수 서명 속성, 서명되지 않은 속성, 인증서 참조, 인증서 자료. 다른 것들은 사람의 취급, 키 보관, 조직적 승인에 관한 것일 수 있었다.

일치하는 정책 해시는 규칙집이 식별되었음을 증명한다. 규칙집의 모든 절차가 수행되었음을 증명하지는 않는다. 그 증거는 키 관리 기록, 승인 시스템, 교육 통제, 증인 기록에 존재할 수 있다. RFC 3125의 서명자 표현, 즉 "데이터가 이 정책 하에서 서명되었다"는 표현은 서약이지 전지적 텔레메트리가 아니었다.

이 간극이 바로 무심한 감사 문구가 위험해지는 지점이다. "OID X 하에서 서명이 유효"라는 문구는 검증자가 명시된 시각에 명시된 증거에 대해 명시된 정책 구현을 실행했음을 뜻해야 한다. 그것이 조용히 "서명자에게 권한이 있었다", "상대방이 수용했다", "계약이 이행되었다"로 변하면 안 된다. 그것들은 소유자가 다른 이후의 판단이다.

알고리즘은 정책 유효성을 역사적 것으로 만들었다

보안 고려 사항은 개인 키 보호와 알고리즘 강도의 저하를 강조했다. 구현은 필수 알고리즘이 바뀔 수 있으므로 모듈식으로 설계하도록 권고되었다. 정책은 알고리즘과 키 길이를 제약할 수도 있었다.

따라서 유효성은 두 가지 방식으로 시간에 민감했다. 서명은 생성 시각과 증거 이력을 갖고, 정책과 의존 맥락도 허용 가능한 암호술에 대한 변화하는 관점을 갖고 있었다. 이후의 검증자는 서명 시점에 어느 규칙 판본이 적용되었는지, 어떤 타임스탬프 증거가 존재했는지, 알고리즘 전환이 미래 지향적이었는지 소급적이었는지를 알아야 할 수 있었다.

RFC 3126은 장기 전자 서명 형식을 다루었고, RFC 3161은 타임스탬프 프로토콜 증거를 규정했다. RFC 2630과 RFC 2634는 CMS와 S/MIME 보안 서비스 맥락을 제공했고, RFC 2459와 RFC 2560은 당시의 인증서 및 상태 환경을 제공했다. 이 자료들은 정책 주변의 구성 요소를 설명한다. 명명된 RFC 3125 정책이 실제 배치되었음을 증명하지는 않는다.

실험적 발행은 배치 영수증이 아니었다

RFC 3125는 실험적 틀과 선택적 ASN.1 형식을 정의했다. 그 적합성 선언은 서명자·검증자 시스템이 OID로 식별된 정책에 따라 서명을 처리하도록 요구했다. 이는 적합 참여자를 위한 프로토콜 의무지 참여자에 대한 인구조사가 아니었다.

RFC 5280과 RFC 5652를 포함한 이후의 PKIX와 CMS 명세는 현대의 독자가 인증서·서명 데이터 처리의 계보를 이해하는 데 도움이 된다. 그러나 이를 거슬러 올려가 2001년의 구현이 RFC 3125를 따랐다는 증거로, 또는 어떤 법제가 이를 채택했다는 증거로 투사해서는 안 된다.

책임 있는 역사 기록은 문서가 무엇을 가능하게 했는지를 남긴다. 명시적 정책 정체성, 정확한 정책 바이트 결합, 기계 판독 가능한 규칙 계열. 채택, 상호운용성, 법적 인정, 분쟁 결과는 별도의 기록이 필요하다.

완전한 영수증에는 그 자체의 여러 서명이 있었다

재현 가능한 판단은 서명된 객체, 서명 바이트, 서명자 인증서, 정책 OID, 확정적 정책 표현, 정책 해시와 알고리즘, 발행일, 서명 기간, 선택된 커밋먼트 규칙, 인증서 경로, 폐기 자료, 타임스탬프, 속성, 알고리즘 제약, 검증자 소프트웨어와 시각을 보존한다. 그다음 정책을 인정한 외부 문서, 즉 계약, 규정 또는 합의를 추가한다.

그것조차 근본 거래의 이행을 증명하지는 못한다. 전달, 수용, 지급, 이행 완료, 분쟁 판정은 하류의 사건이다.

RFC 3125의 역사적 기여는 거짓 이분법을 거부한 데 있다. 서명은 추상적으로 단순히 유효하거나 무효하지 않았다. 그것은 특정 정책 하에서, 특정 증거와 함께, 특정 커밋먼트와 맥락에 대해 검증되었다. 암호술이 한 방정식을 닫았다면, 정책은 어느 방정식이 중요한지를 밝혔다.

출처

  1. https://www.rfc-editor.org/rfc/rfc3125.txt
  2. https://www.rfc-editor.org/info/rfc3125
  3. https://datatracker.ietf.org/doc/rfc3125/
  4. https://www.rfc-editor.org/rfc/rfc3126.txt
  5. https://www.rfc-editor.org/rfc/rfc2630.txt
  6. https://www.rfc-editor.org/rfc/rfc2634.txt
  7. https://www.rfc-editor.org/rfc/rfc2459.txt
  8. https://www.rfc-editor.org/rfc/rfc2560.txt
  9. https://www.rfc-editor.org/rfc/rfc3161.txt
  10. https://www.rfc-editor.org/rfc/rfc2119.txt
  11. https://www.rfc-editor.org/rfc/rfc5280.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt