장기 검증

Spec: ETSI EN 319 142-1 Spec: RFC 6960 Spec: ISO 32000-2, §12.8.4 Evidence: Standard-backed

한눈에 보기

오늘 검증되는 서명은 영구적으로 유지되지 않는 사실에 의존합니다. 만료되는 인증서, 오프라인 상태가 되는 폐기 서버, 약해지는 해시 알고리즘이 그런 사실입니다. 장기 검증은 증거를 아직 확보할 수 있을 때 문서 안에 기록합니다. 그러면 몇 년이 지난 뒤에도 그 서명을 누구에게도 아무것도 묻지 않고 확인할 수 있습니다.

왜 중요한가

디지털 서명의 위험한 점은 겉보기에는 변하지 않은 채 조용히 검증 불가능한 상태가 될 수 있다는 것입니다. 파일 자체는 아무것도 바뀌지 않습니다. 인증 기관은 오래전에 만료된 인증서에 대한 질의에 더 이상 응답하지 않게 됩니다. 그 응답이 필요했던 검증기는 더 이상 답을 얻을 수 없습니다. 서명된 날에는 의심할 여지 없이 유효했던 계약이 10 년 후에는 “판정 불가” 상태가 됩니다. 그때가 바로 분쟁이 가장 일어나기 쉽고 이해관계가 가장 큰 시점입니다. 보관 의무가 여러 해에 걸친다면, 장기 검증이 없는 서명은 나중에야 드러나는 위험입니다.

요약

서명의 유효성은 시간에 민감한 외부 사실에 의존합니다. 예를 들면 인증서의 유효 기간과 서버가 제공하는 폐기 상태입니다.
이러한 사실은 인증서가 만료된 뒤에는 확보할 수 없게 됩니다. 기관이 영원히 응답해야 하는 것은 아닙니다.
장기 검증은 서명 시점에 증거를 확보합니다 — 인증서, OCSP 응답, CRL — 그리고 이를 문서의 **Document Security Store(DSS)**에 임베드합니다.
그런 다음 문서 타임스탬프가 증거 자체가 그 시점에 존재했고 유효했음을 증명하며, 자체 보호가 약해지기 전에 갱신할 수 있게 합니다.
그 결과 문서는 자체 증거를 갖게 됩니다. 검증은 더 이상 서버가 여전히 존재하는지에 의존하지 않습니다.

NextPDF의 접근 방식

원칙은 “할 수 있을 때 증거를 모으고, 그런 다음 봉인하라”입니다. NextPDF가 장기 서명을 생성할 때는 서명 시점에 서명 인증서가 정상 상태였음을 증명하는 인증서 체인과 폐기 응답을 수집합니다. 그리고 이를 링크가 아니라 임베드된 값으로 DSS에 기록합니다. 그런 다음 전체에 문서 타임스탬프를 추가합니다. 핵심은 임베드된 값입니다. 폐기 서버로 연결되는 링크는 장기 검증이 없애려는 바로 그 의존성입니다.

장기 계층은 별도의 문서 리비전으로 기록되며, 원본 서명의 바이트 범위를 건드리지 않고 추가됩니다. 첫 번째 서명은 계속 검증됩니다. 장기 자료는 서명 안에 넣는 것이 아니라 서명 주위에 추가됩니다. 문서 타임스탬프 자체의 보호가 노후화되면, 아카이브 수준은 그 위에 또 다른 타임스탬프를 겹쳐 쌓을 수 있게 합니다. 그 결과 각 타임스탬프가 그 아래의 모든 것을 보증하는 체인이 됩니다.

Sign The signature and its signed attributes are written (B-B).
Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.

장기 검증이 시간이 지나도 서명을 검증 가능하게 유지하는 방법: 서명이 생성되고, 증거가 아직 확보할 수 있는 동안 확보되며, 증거는 문서 타임스탬프로 봉인되고, 봉인은 약해지기 전에 갱신됩니다.

증거가 말하는 것

Evidence: Standard-backed 그 필요성은 다음에서 명확하게 드러납니다. Spec: RFC 6960, §4.4.4 : OCSP 응답자는 인증서 만료 이후에도 폐기 정보를 보유할 수 있으며, 아카이브 컷오프 날짜는 애플리케이션이 서명 시점의 신뢰성 여부를 — 신뢰할 수 있었는지 또는 없었는지 — 증명할 수 있게 합니다. 이를 검증하는 데 필요한 인증서가 오래전에 만료되었더라도 그렇습니다. 이 내용이야말로 장기 검증이 존재하는 이유입니다. 폐기 응답은 제한된 기간에만 확보 가능한 상태로 남아 있으므로, 그 기간이 끝나기 전에 확보해야 합니다.

이 메커니즘은 ETSI에서 정의합니다. Spec: ETSI EN 319 142-2, §5.5 에 따르면 장기 동작에는 검증 데이터를 값으로 담은 Document Security Store와 그 뒤에 이어지는 문서 타임스탬프가 필요합니다. Spec: ISO 32000-2, §12.8.3.3 는 이를 하나로 엮습니다: PAdES는 CAdES CMS를 장기 검증(§12.8.4) 및 문서 타임스탬프 딕셔너리(§12.8.5)와 결합한 것입니다. 그리고 Spec: ETSI EN 319 142-2, §6.3.2.2 는 타임스탬프가 일찍 적용되어야 하는 이유를 설명합니다. 기록된 시간이 실제 시간에 최대한 가깝도록 서명 직후에 적용해야 합니다.

NextPDF의 엔진은 이를 B-LT 및 B-LTA 수준으로 구현합니다. DSS에 임베드된 폐기 값, 이를 봉인하는 문서 타임스탬프, 그리고 봉인을 갱신하는 아카이브 루프가 그 구성 요소입니다 — 원본 서명의 바이트 범위는 그대로 둔 추가 리비전으로 기록됩니다.

실용 예제

선택한 수준 자체가 장기적인 결정입니다. API는 확정하기 전에 요구 사항을 명시적으로 드러냅니다.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

위에 표시된 고수준 연결 지점 — setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save() — 은 이제 처음부터 끝까지 연결되어 있습니다. 이전 릴리스에서는 수준 열거형은 노출했지만 이를 실제로 생성하는 연결 지점은 노출하지 않았습니다. 이 호출이 기록하는 것은 구조입니다. DSS 딕셔너리와 Spec: ISO 32000-2, §12.8 에 기술된 DocTimeStamp 리비전이 그것입니다. 이 구조는 프로파일 적합성 테스트를 거치지 않으며, 이 연결 지점은 ETSI 적합성이나 법적 유효성에 대해 아무것도 단언하지 않습니다. B-LT 및 B-LTA 수준은 Pro와 Enterprise 모두가 필요합니다. 다른 어떤 등급에서도 이 연결 지점은 부분 결과를 만들지 않고 실패 시 닫힌 상태로 처리됩니다. 암호화된 문서 역시 B-LT 및 B-LTA에 대해 실패 시 닫힌 상태로 처리됩니다 — DSS와 문서 타임스탬프는 잘못 기록되는 대신 암호화된 콘텐츠 위에는 기록되지 않습니다.

이 선택은 나중에 저렴하게 소급 적용할 수 있는 것이 아닙니다. 폐기 증거는 응답이 아직 존재하는 동안, 서명 시점에 확보해야 합니다. “장기 검증은 나중에 추가하자”고 결정하는 것은 대개 “필요할 때 증거를 갖지 못할 것”이라고 결정하는 것을 의미합니다.

흔한 오해

첫 번째 오해는 “장기 검증이 서명을 영원히 유효하게 만든다”는 것입니다. 장기 검증은 그 무엇도 유효하게 만들지 않습니다. 장기 검증은 서명 시점에 성립한 유효성을 확인할 수 있는 능력을 보존합니다. 문서가 서명될 때 인증서가 이미 폐기되어 있었다면, 그 사실을 임베드한다고 해서 서명이 구제되지는 않습니다. 오히려 그 실패를 영구적으로 기록할 뿐입니다. 장기 검증은 증거 보존 메커니즘이지 증거 생성 메커니즘이 아닙니다. 두 번째 오해는 B-LTA가 “설정해 두고 잊어버리면 되는 것”이라고 믿는 것입니다. 아카이브 타임스탬프 자체도 시간이 지나며 노후화되는 알고리즘으로 보호됩니다. 갱신하지 않으면, B-LTA 파일은 결국 벗어나려 했던 바로 그 취약성을 다시 물려받게 됩니다.

한계와 경계

NextPDF는 증거를 수집하여 임베드하고 타임스탬프를 기록합니다. 증거의 진위나 갱신 일정은 NextPDF의 소관이 아닙니다. 폐기 응답의 신뢰성은 이를 발급한 기관과 가져온 시점에 달려 있습니다. 서명 시점에 해당 기관에 연결할 수 있어야 하는 책임은 배포 측에 있습니다. 엔진은 확보할 수 없었던 폐기 응답을 만들어 낼 수 없습니다. 아카이브 갱신은 운영상의 프로세스입니다. 엔진은 또 다른 타임스탬프를 추가할 수 있지만, 보관 정책상 그것이 언제 필요한지는 결정할 수 없습니다. 임베드된 데이터가 나중에 충분하다고 판정될지는 검증기와 정책의 문제이며, 이는 서명을 올바르게 검증하기에서 다룹니다. 이 페이지는 법적 증거능력을 단언하지 않습니다. 법적 증거능력은 관할권, 서명자, 인증서에 따라 달라집니다.

장기 검증의 등급별 제공 여부:

Long-term validation (DSS embedding and the archival timestamp loop) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — 서명 값에 대한 신뢰할 수 있는 타임스탬프 — 는 제공되지만, 임베드된 검증 자료(DSS)는 B-T의 일부가 아닙니다.
Enterprise	PAdES B-LT 및 B-LTA: DSS에 임베드된 인증서 및 폐기 값, 이를 봉인하는 문서 타임스탬프, 그리고 갱신 가능한 아카이브 루프.

용어집

장기 검증(LTV) — 나중에 검증이 외부 서비스에 의존하지 않도록, 서명을 검증하는 데 필요한 증거를 임베드하는 것.
Document Security Store(DSS) — 장기 검증을 위해 임베드된 인증서와 폐기 데이터를 담는 PDF 구조.
OCSP 응답 — 특정 시점의 인증서 폐기 상태를 나타내는 서명된 진술(Online Certificate Status Protocol, RFC 6960).
CRL — Certificate Revocation List; 폐기된 인증서의 서명된 목록.
문서 타임스탬프 — 문서 전체에 적용되는 RFC 3161 타임스탬프로, 임베드된 증거가 그 시점에 존재했고 유효했음을 증명하는 것.
아카이브 루프 — 이전 타임스탬프의 보호가 약해지기 전에 새 문서 타임스탬프를 반복적으로 추가하여 검증 가능성을 연장하는 것.