Kompleksowa metodologia zaczyna się od oddzielenia procesu podpisywania od procesu walidacji, aby izolować obszary defektów. Testerzy muszą wykonać weryfikację kryptograficzną za pomocą narzędzi wiersza poleceń OpenSSL, aby potwierdzić integralność struktury CMS (Cryptographic Message Syntax) niezależnie od przeglądarek PDF. Testy regresji wizualnej powinny uchwycić elementy wyglądu podpisu w Adobe Acrobat, Firefox PDF.js, Chrome PDFium i mobilnych renderach iOS PDFKit, aby wykryć błędne interpretacje układu współrzędnych. Weryfikacja czasowa wymaga manipulacji zegarami systemowymi do dat po wygaśnięciu certyfikatu w celu potwierdzenia, że łańcuchy PAdES-LTV utrzymują ważność dzięki osadzonym odpowiedziom OCSP i tokenom TSA.
W firmie zajmującej się technologią prawną wdrożyliśmy platformę do realizacji umów wykorzystującą certyfikaty ECDSA P-256 od dostawcy usług zaufania kwalifikowanego przez eIDAS. Krytyczny defekt pojawił się, gdy dokumenty podpisane w macOS wyświetlały ważne podpisy w Preview i Adobe Acrobat, ale natywne przeglądarki PDF.js w Chrome zgłaszały "znana ważność podpisu", mimo że osadzone odpowiedzi OCSP były obecne w strukturze pliku.
Oceniliśmy trzy różne podejścia naprawcze. Pierwsze podejście polegało na migracji do kluczy kryptograficznych RSA 2048, co oferowało szerszą kompatybilność z starszymi parserami PDF, ale zwiększało rozmiar bajtów podpisów o około czterdzieści procent i znacząco pogarszało wydajność w urządzeniach mobilnych z ograniczonymi zasobami obliczeniowymi. Drugie podejście rozważało wyłączenie osadzania LTV, aby uprościć strukturę dokumentu i zmniejszyć złożoność analizy, ale spowodowałoby, że podpisy stałyby się nieważne po wygaśnięciu certyfikatu, co naruszałoby regulacyjne wymagania dotyczące dziesięcioletnich okresów przechowywania dokumentów w kontekście prawnym. Trzecie podejście skoncentrowało się na restrukturyzacji słownika DSS (Document Security Store), aby umieścić tablice odpowiedzi OCSP przed odniesieniem ByteRange w liniaryzacji pliku, co spełniało wymagania liniowego przetwarzania PDF.js bez zwiększania rozmiarów plików ani kompromisów w trwałości, chociaż wymagało skomplikowanej manipulacji obiektami PDF na niskim poziomie.
Wybraliśmy trzecie rozwiązanie, ponieważ PDF.js ściśle egzekwuje wymagania dotyczące kolejności przetwarzania liniowego, podczas gdy Adobe Acrobat stosuje bardziej liberalny model przetwarzania z dostępem losowym. Wdrożenie rozwiązało rozbieżność w ważności między platformami, osiągając spójne wskaźniki "ważny podpis" na wszystkich docelowych platformach, zachowując jednocześnie ścisłą zgodność z PDF/A-3 i trwałość PAdES-LTV dla zgodności z archiwizowaniem długoterminowym.
Jak poziom zgodności PDF/A wpływa na widoczność podpisu cyfrowego i mechanikę walidacji?
Wielu testerów błędnie traktuje zgodność PDF/A jako stan binarny, a nie jako specyfikację o różnych poziomach. PDF/A-1b zapewnia jedynie reprodukowalność wizualną, podczas gdy PDF/A-2a wymaga struktury oznaczonej i mapy znaków Unicode. Podczas tworzenia podpisu, strumienie wyglądu muszą wykorzystywać czcionki osadzone w łańcuchu DA (Default Appearance) dokumentu. Jeśli usługa podpisująca wstrzykuje czcionki systemowe, które nie są obecne w podzbiorze czcionek oryginalnego dokumentu, walidacja PDF/A kończy się niepowodzeniem po podpisaniu, nawet gdy kryptograficzny podpis pozostaje matematycznie ważny. Testerzy muszą zweryfikować, że podzbiór czcionek występuje podczas generowania widżetów podpisu i że słownik /DR (Default Resources) odnosi się tylko do wcześniej osadzonych strumieni czcionek, a nie do nazw czcionek systemowych.
Dlaczego osadzone odpowiedzi OCSP czasami nie ustanawiają statusu LTV (Long Term Validation), mimo że są kryptograficznie poprawne?
Kandydaci często potwierdzają tylko istnienie bajtów odpowiedzi OCSP w słowniku DSS, nie sprawdzając kompletności łańcucha walidacji. Ustanowienie LTV wymaga kompletnego łańcucha zaufania, w tym certyfikatu respondenta OCSP, tokena znaku czasowego i samego certyfikatu autorytetu czasowego. Jeśli odpowiedź OCSP jest podpisana certyfikatem, który wymaga własnego sprawdzenia unieważnienia, ale brakuje osadzonej odpowiedzi OCSP dla respondenta w tablicy Certs, Adobe Acrobat odmówi włączenia trybu LTV. Testerzy muszą potwierdzić, że tablica Certs w DSS zawiera wszystkie certyfikaty pośrednie, aż do wykluczonego głównego CA, i że każdy znacznik czasu obejmuje zarówno podpis, jak i odpowiedź OCSP, aby osiągnąć minimalną zgodność na poziomie PAdES-T.
Co powoduje niedopasowanie wyglądu podpisu pomiędzy Adobe Acrobat a mobilnymi przeglądarkami PDF?
Tablica Rect (prostokąt) definiująca pozycjonowanie widżetu podpisu korzysta z układów współrzędnych stron, które różni przeglądarki interpretują odmiennie. Adobe Acrobat oblicza współrzędne z dolnego lewego punktu (standardowa przestrzeń współrzędnych PDF), podczas gdy niektóre przeglądarki mobilne, takie jak iOS PDFKit, stosują obliczenia CropBox z górnego lewego początku, gdy obecne są wpisy Rotate. Jeśli widżet podpisu korzysta z ujemnych współrzędnych lub wychodzi poza granice MediaBox, przeglądarki stacjonarne mogą inaczej przycinać wygląd w porównaniu do mobilnych implementacji. Testerzy muszą zweryfikować współrzędne wobec granic CropBox i ArtBox oraz upewnić się, że wpisy Rotation w słownikach stron są respektowane przez stosowanie macierzy przekształceń do obiektu wyglądu XObject zamiast jedynie dostosowywania współrzędnych prostokąta widżetu.