Poprawna walidacja podpisu

Spec: RFC 5280, §6 Spec: RFC 6960 Spec: RFC 5652 Evidence: Test-backed

W skrócie

„Podpis jest prawidłowy” zwykle oznacza, że sprawdzono jedną rzecz: wynik obliczeń się zgadzał. Poprawna walidacja obejmuje co najmniej pięć niezależnych kontroli, a każda z nich może zawieść w sposób, który pozbawia znaczenia zielony znacznik. Ta strona przedstawia pełny zestaw kontroli oraz wyjaśnia, dlaczego odpowiedź częściowa jest niebezpieczna.

Dlaczego to istotne

Pojedyncza wartość logiczna to najbardziej niebezpieczny wynik w całym tym zagadnieniu. Skłania czytelnika do traktowania „prawidłowy” jako „godny zaufania”, podczas gdy „prawidłowy” może oznaczać jedynie, że bajty nie zostały zmienione — kluczem z certyfikatu, który wygasł trzy lata temu, został unieważniony w zeszłym miesiącu i nie tworzy łańcucha do żadnego urzędu rozpoznawanego przez Ciebie. Każde z tych zagadnień wymaga osobnej kontroli. Oprogramowanie, które zwraca jedną wartość logiczną, po cichu zdecydowało, które kontrole mają znaczenie, i zdecydowało za Ciebie. W kontekście regulowanym lub umownym stwierdzenie „narzędzie uznało to za prawidłowe” nie stanowi obrony, jeśli narzędzie zweryfikowało tylko najtańszą do sprawdzenia właściwość.

Najważniejsze w skrócie

Pełna walidacja odpowiada na pięć odrębnych pytań. Są niezależne — pozytywny wynik jednej kontroli nic nie mówi o pozostałych:

Integralność — czy podpisane bajty nadal dają skrót zgodny z wartością objętą podpisem? (Przelicz ponownie skrót dla zakresu bajtów i porównaj.)
Autentyczność — czy podpis kryptograficzny weryfikuje się względem klucza publicznego z certyfikatu podpisującego, dla podpisanych atrybutów?
Ścieżka certyfikacji — czy ten certyfikat tworzy łańcuch do kotwicy zaufania wybranej przez Ciebie, przy czym każde ogniwo jest prawidłowe?
Czas — czy certyfikat mieścił się w swoim okresie ważności w istotnym momencie i czy ten czas jest zaufany, a nie zadeklarowany samodzielnie?
Unieważnienie — czy certyfikat nie był unieważniony w tym momencie, na podstawie dowodów (OCSP/CRL), które faktycznie możesz uzyskać lub które są osadzone?

„Prawidłowy” bez wszystkich pięciu kontroli to odpowiedź niepełna, która wygląda jak pełna.

Jak podchodzi do tego NextPDF

Stanowisko NextPDF jest takie, że każde pytanie jest odrębne i na każde należy odpowiedzieć wprost. Żadnego pytania nie sprowadza się do jednej optymistycznej flagi ani nie pomija po cichu tylko dlatego, że dana kontrola była niewygodna. Egzekwują to testy. Dlatego ta strona jest oznaczona jako poparta testami, a nie standardem: zachowanie utrzymuje zestaw testów, nie tylko wniosek wyprowadzony z klauzuli.

Integralność i autentyczność są testowane od początku do końca. Znany certyfikat podpisuje rzeczywistą strukturę podpisanych atrybutów, a zestaw testów weryfikuje podpis odpowiadającym kluczem publicznym dla wielu wektorów czasu. Dlatego zmiana, która narusza strukturę kanoniczną, powoduje niepowodzenie testu. Walidację ścieżki certyfikacji utrzymują testy, które celowo modyfikują bajt podpisu i potwierdzają, że wynik nie jest prawidłowy, ze strukturalnym uzasadnieniem — nie jako rzucony wyjątek, lecz jako jednoznacznie zarejestrowane niepowodzenie. Weryfikacja tokenu znacznika czasu jest podzielona na odrębne kroki — dekodowanie, informacje o podpisującym, podpisane atrybuty, skrót wiadomości, powiązanie z certyfikatem, przeznaczenie klucza, podpis, czas wytworzenia — a każdy krok jest testowany osobno, więc „znacznik czasu zweryfikowany” oznacza, że zweryfikowano każdy krok. Miękkie niepowodzenie sprawdzenia unieważnienia (nieosiągalny serwer odpowiedzi) jest odróżniane, w kodzie i w testach, od jednoznacznego „unieważniony”. Tych dwóch przypadków nigdy nie łączy się w tę samą odpowiedź.

Integrity Recompute the byte-range digest and compare it to the value the signature covers.
Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Pięć niezależnych pytań, na które po kolei odpowiada poprawna walidacja podpisu PDF. Każde z nich jest odrębne: przejście jednego nic nie mówi o pozostałych, a pominięcie któregokolwiek czyni cały wynik niepełnym.

Co mówią dowody

Evidence: Test-backed Zachowanie jest zakotwiczone w testach, a te testy realizują wymagania standardów.

Integralność to Spec: ISO 32000-2, §12.8.1 : skrót jest przeliczany ponownie dla zakresu bajtów i porównywany z zapisaną wartością, a każda różnica oznacza, że podpis jest nieprawidłowy. Autentyczność dla podpisanych atrybutów obejmuje test integracyjny, który podpisuje rzeczywisty zestaw podpisanych atrybutów i weryfikuje go odpowiadającym kluczem publicznym dla kilku wektorów czasu. Kwestia ścieżki certyfikacji to Spec: RFC 5280, §6.1 : prawidłowe ścieżki rozpoczynają się od kotwicy zaufania, a Spec: RFC 5280, §6.2 stwierdza, że ten algorytm definiuje minimalne warunki uznania ścieżki za prawidłową — test jednostkowy walidatora ścieżki potwierdza, że zmodyfikowany podpis daje valid = false z jednoznacznym uzasadnieniem, nigdy z cichym zaakceptowaniem.

Kolejność sprawdzania unieważnienia to Spec: RFC 6960, §3.2 : zanim klient zaakceptuje podpisaną odpowiedź dotyczącą unieważnienia jako prawidłową, MUSI potwierdzić, że podpis samej odpowiedzi jest prawidłowy i że podpisujący jest aktualnie upoważniony — a Spec: RFC 6960, §4.2.2.2 definiuje to upoważnienie jako delegację id-kp-OCSPSigning wystawioną bezpośrednio przez dany urząd CA. Dlatego odpowiedź dotycząca unieważnienia, której nie zweryfikowano względem upoważnionego, weryfikowalnego podpisującego, jest pozbawiona znaczenia. Sprawdzenie powiązania certyfikatu to Spec: RFC 5035, §5.4.2 : jeśli skrót certyfikatu w podpisanym atrybucie signing-certificate-v2 nie odpowiada certyfikatowi użytemu do weryfikacji podpisu, podpis musi zostać uznany za nieprawidłowy. Zamyka to lukę podstawienia, w której podpis weryfikuje się względem certyfikatu wybranego przez atakującego. Własny token znacznika czasu jest weryfikowany jako obiekt CMS zgodnie z Spec: RFC 5652 , krok po kroku, przy czym każdy krok jest testowany osobno.

Przykład praktyczny

Najważniejsza część to nie wywołanie API. To pytania, na które musisz umieć odpowiedzieć, zanim podejmiesz działanie na podstawie wyniku. Potraktuj to jako listę kontrolną, z której zostaniesz rozliczony podczas przeglądu.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Jeśli przy którymkolwiek wierszu odpowiedź brzmi „nie wiem”, uczciwym statusem nie jest „prawidłowy”. Jest nim „jeszcze nieustalony” — a traktowanie tych dwóch stanów jako tożsamych to błąd, któremu ta strona ma zapobiegać.

Częste nieporozumienie

Pułapką jest utożsamianie „prawidłowy kryptograficznie” z „godny zaufania”. Integralność i autentyczność razem dowodzą jedynie, że te bajty zostały podpisane przez posiadacza tego klucza. Nic nie mówią o tym, czy certyfikat tego klucza był zaufany, aktualny ani nieunieważniony. Dokument podpisany samodzielnie wygenerowanym certyfikatem może być „prawidłowy kryptograficznie” i nic niewart. Odwrotną pułapką jest traktowanie nieokreślonego sprawdzenia unieważnienia (serwer odpowiedzi niedostępny) jako przejścia — albo jako niepowodzenia. Nie jest ani jednym, ani drugim. Jest nieznany, a poprawny walidator zgłasza go jako nieznany, zamiast zgadywać w którąkolwiek stronę. Zielony znacznik, który ukrywa, które z pięciu kontroli faktycznie zostały wykonane, nie jest wynikiem walidacji. To decyzja, którą ktoś inny podjął w Twoim imieniu.

Ograniczenia i granice

NextPDF wykonuje i testuje kontrole strukturalne oraz kryptograficzne. Nie wybiera Twoich kotwic zaufania ani nie gwarantuje polityki na nich opartej. To, którym certyfikatom ufasz, jest decyzją wdrożeniową, której silnik nie może podjąć. Łańcuch, który waliduje się do kotwicy, której nie powinieneś był ufać, to wciąż walidacja, na której nie możesz polegać. Dowody unieważnienia można sprawdzić tylko wtedy, gdy są możliwe do uzyskania lub osadzone. Niedostępny serwer odpowiedzi daje wynik „nieokreślony”, a przekształcenie go w werdykt jest decyzją polityki, a nie silnika. Ta strona opisuje zestaw kontroli, a nie wystarczalność prawną. To, czy zwalidowany podpis wywołuje określony skutek prawny, zależy od certyfikatu, podpisującego, jurysdykcji oraz zobowiązania. To, jak osadzone dowody utrzymują rozliczalność tych kontroli w czasie, omówiono w Walidacja długoterminowa; mechanizm zakresu bajtów stojący za sprawdzeniem integralności opisano w Jak podpisy są osadzone w pliku PDF.

Dostępność obszaru walidacji w poszczególnych poziomach:

Signature validation checks — edition availability
Edition	Availability
Core	Integralność i autentyczność dla podpisanych atrybutów oraz walidacja ścieżki certyfikacji RFC 5280 §6 względem dostarczonej kotwicy zaufania.
Pro	Dodaje weryfikację tokenu znacznika czasu RFC 3161 — pytanie o zaufany czas, rozłożone na niezależnie sprawdzane kroki.
Enterprise	Dodaje ocenę unieważnienia (OCSP/CRL) oraz walidację względem osadzonego materiału długoterminowego, z odróżnieniem wyników nieokreślonych od wyników jednoznacznych.

Powiązana dokumentacja

Walidacja długoterminowa — jak osadzone dowody sprawiają, że kontrole czasu i unieważnienia pozostają rozliczalne po latach.
Jak podpisy są osadzone w pliku PDF — mechanizm zakresu bajtów używany do ponownego przeliczenia w ramach sprawdzenia integralności.
Znaczniki czasu i zaufany czas — co sprawia, że na pytanie o „czas” można odpowiedzieć czymś innym niż zegar podpisującego.

Słowniczek

Sprawdzenie integralności — ponowne przeliczenie skrótu dla zakresu bajtów i porównanie go z wartością, którą obejmuje podpis.
Sprawdzenie autentyczności — weryfikacja podpisu kryptograficznego względem klucza publicznego certyfikatu podpisującego, dla podpisanych atrybutów.
Podpisane atrybuty — uwierzytelnione atrybuty CMS (content-type, message-digest, signing-time, signing-certificate-v2), na których podpis jest faktycznie obliczany.
Walidacja ścieżki certyfikacji — budowanie i sprawdzanie łańcucha od certyfikatu podpisującego do wybranej kotwicy zaufania (RFC 5280 §6).
Kotwica zaufania — urząd certyfikacji, któremu zdecydowałeś się zaufać; korzeń dopuszczalnej ścieżki.
Sprawdzenie unieważnienia — ustalenie, czy certyfikat był unieważniony w istotnym momencie, za pomocą OCSP lub listy CRL.
Nieokreślony — wynik sprawdzenia unieważnienia, który nie jest ani „dobry”, ani „unieważniony”, ponieważ nie udało się uzyskać dowodów; nie jest przejściem ani niepowodzeniem.