Poprawna walidacja podpisu

SpecSpec: RFC 5280, §6RFC 5280 §6SpecSpec: RFC 6960RFC 6960SpecSpec: RFC 5652RFC 5652

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:

1. 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.)
2. Autentyczność — czy podpis kryptograficzny weryfikuje się względem klucza publicznego z certyfikatu podpisującego, dla podpisanych atrybutów?
3. Ścieżka certyfikacji — czy ten certyfikat tworzy łańcuch do kotwicy zaufania wybranej przez Ciebie, przy czym każde ogniwo jest prawidłowe?
4. 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?
5. 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. W przypadku znacznika czasu podpisu jeden z tych kroków nie jest opcjonalny ani ogólny: odcisk wiadomości tokenu musi wiązać podpis, który rzekomo obejmuje — skrót zawarty w tokenie musi być równy skrótowi wartości podpisu samego podpisującego, w przeciwnym razie token poświadcza inne bajty. NextPDF udostępnia to jako dedykowaną kontrolę verifySignatureTimestamp, która przyjmuje wartość podpisu jako wymagane dane wejściowe, więc nie można jej pominąć, i zawodzi bezpiecznie przy pustych danych wejściowych, nierozpoznanym lub słabym (SHA-1) algorytmie odcisku, zniekształconym odcisku albo skrócie, który się nie zgadza. 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ź.

1. IntegrityRecompute the byte-range digest and compare it to the value the signature covers.
2. AuthenticityVerify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
3. Certificate pathBuild and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
4. TimeConfirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
5. RevocationConfirm 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.

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.
• Powiązanie odcisku (znacznik czasu podpisu) — kontrola sprawdzająca, że odcisk wiadomości znacznika czasu podpisu jest równy skrótowi wartości podpisu z SignerInfo podpisującego, którą obejmuje, tak aby znacznik czasu dowodnie odnosił się do tego podpisu, a nie do innych bajtów.