GetValid qualified validation service report content
- Download the document – Validation Report [PDF]
INTRODUCTION #
This document contains a description of the contents of the GetValid service validation report presenting the results of validation of electronic signatures and seals of an electronic document.
The description is based on an example of the original report, for which the possible content and meaning of the various fields of the report are presented and discussed.
Since technically there are no differences between an electronic signature and an electronic seal, all information relating to signatures also applies to seals, unless an explicit distinction between the two cases is made in the body of the document.
VALIDATION REPORT #
REPORT HOMEPAGE #
Report headline
- Report number – a number uniquely identifying the report.
- Date of document submission for validation – the date specifying the moment when the GetValid service server received the document for validation[1]. The date is given both in RP official time and in UTC time.
- Report issue date – the date that determines when the validation report was generated.
- Date of existence of the document declared by the user – information about the date of existence of the document appears in the report only if the user, when entering the document for validation, indicated a specific date on which the signed document, according to the user, already existed. What is the meaning of this date and when it should be entered is described in section 3.1.
File name and SHA-256 hash of the file
The section contains a list of files that make up the signed document (the document signature may be in a separate file or the document may have attachments). The report presents file names and SHA-256 hashes from their contents. This data allows you to associate a document with a validation report, however, in order to be sure that a given report applies to the indicated document, you need to use a dedicated application available on Cencert websites, which performs such a check.
Warnings related to the document
The GetValid service examines not only the validity of signatures and seals, but tries to warn the user against such manipulations, which, without violating the validity of the signature, can mislead the user about the content of the document. For example, an additional paragraph can be added to a signed PDF contract without violating the signature and thus attempt to manipulate its content. For a detailed description of possible warnings, see Section 3.2.
List of signatures, seals and validation results
The section contains basic information on signatories, signatures and their validation results.
| Kolumna | Znaczenie |
|---|---|
| Sygnatariusz |
Dla podpisów, kolumna zawiera:
Dla pieczęci, kolumna zawiera wszystkie pola identyfikatora wyróżniającego właściciela certyfikatu użytego do złożenia podpisu. |
| Rodzaj podpisu |
Określa rodzaj podpisu. Pełna lista znajduje się w rozdziale 3.4. |
| Status walidacji podpisu |
Zawiera wynik walidacji danego podpisu:
Wyniki „pozytywny” i „negatywny” są ostateczne i nie należy oczekiwać, że przy powtórzeniu walidacji możemy otrzymać inny rezultat, chyba że zmieni się informacja na temat daty podpisania dokumentu tj. użytkownik ponowi walidację samodzielnie wprowadzając inną datę istnienia podpisanego dokumentu. Wynik „nieokreślony” oznacza, że usługa nie jest w stanie zdecydować ani o ważności danego podpisu, ani o jego nieważności. Dalsze działania użytkownika powinny zależeć od informacji, opisanych w polu Szczegóły statusu walidacji w części raportu zawierającej szczegóły walidacji danego podpisu (patrz rozdziały 2.2 i 3.5). |
Signature validation details #
Signatory
The field contains full information about the distinguishing identifier of the owner of the certificate used for the signature.
The pseudonym used was
The field indicates whether the certificate owner’s ID includes an alias in place of the first and last name. Possible values: Yes, No
Type of signature
For a full list of available signature types, see Section 3.4.
Signature format for XAdES, PAdES, CAdES, ASiC standards.
Signature validation status
The possible values are described in the section “List of signatures, seals and validation results” in section 3.4.
Validation status details
The field is filled in for the case of a validation status other than positive, and indicates the reason for the invalid validation, such as certificate revocation or the use of a compromised SHA-1 algorithm. For a detailed list of reasons with a discussion of their meaning, see section 3.5. For more information on the acceptance of signatures submitted using the SHA-1 algorithm, see section 3.8.
Integrity verification
The field specifies the document integrity verification status. Possible values:
- Positive – the content of the document has not been modified after the signature has been submitted
- Negative – the content of the document or the signature has been modified after the signature has been affixed
Certificate verification
The field specifies the validity verification status of the certificate used to verify the signature. Possible values:
- Positive – the certificate is valid for the accepted date of proof of existence of the signature
- Negative – the certificate is invalid for the accepted date of proof of the existence of the signature
- Indefinite – the validity of the certificate cannot be determined for the accepted date of proof of the existence of the signature
The status may be accompanied by additional information:
- Source of information on cancellations:
- OCSP + [data wystawienia odpowiedzi OCSP] – the source is the OCSP server
- CRL + [data wystawienia listy CRL] – the source is the CRL
- Source + date of proof of existence of the signature. Possible values are:
- Qualified timestamp
- Non-qualified timestamp
- Date provided by user
- Date of submission for validation
Timestamp
The “Timestamp” field specifies whether the signature has been timestamped, with only timestamps that have been successfully verified and are applicable to the signature type[2] shown. Possible values:
- No – the signature was not timestamped.
- Qualified + [data ze znacznika czasu] – the signature has been marked with a qualified time stamp.
- Unqualified + [data ze znacznika czasu] – the signature has been marked with a non-qualified timestamp.
If a signature is marked with multiple timestamps, the date from the earliest timestamp, i.e. made at the moment closest to the time of the signature, is presented.
For more on the qualified timestamp, see section 3.6. System signature timing
The field contains information about the time of the signature placed in the signature structures by the signing application, based on the current time of the computer on which the signature was placed. This field has informational value only and is not used during validation, as the current time of the computer on which the signature was placed may have been erroneous or intentionally manipulated.
Verified signature time
Currently, technology does not allow to determine the exact date of the signature. The qualified timestamp that the document was stamped with after the signature was affixed only makes it possible to determine that the signature was affixed “no later than” the date of the qualified timestamp. However, it is possible to determine the time frame in which the signature was affixed, provided that the document was also previously (before the signature in question) affixed with a qualified timestamp. Such an earlier timestamp makes it possible to establish that the signature was made “not earlier than” the date of that timestamp.
Since the accuracy of the date of the signature may be of significant evidentiary or legal importance to users, the GetValid service presents in the “Verified signature time” field the time interval in which the signature was placed, determined by the closest qualified timestamps to the signature, with which the document was stamped before and after the signature was placed. Possible values:
- No – no qualified time stamps in the document
- No later than + [data ze znacznika czasu] – if the document has been timestamped with a qualified timestamp only after the signature has been affixed
- No earlier than + [data ze znacznika czasu]; no later than + [data ze znacznika czasu] – if the document has been stamped with a qualified before and after signature
For a given signature, the qualified timestamps (prior and subsequent) closest to the time of the signature are taken into account.
For the greatest accuracy in determining the time of the signature, we suggest following the guidelines in Section 3.6.
Cancellation information obtained from
This field indicates based on which source the GetValid service tested whether the certificate is valid. Possible values:
- OCSP + [data wystawienia odpowiedzi OCSP] – the source is the OCSP server
- CRL + [data wystawienia listy CRL] – the source is the CRL
Date of cancellation
If the certificate has been revoked or suspended, this field contains information about the date of revocation or suspension.
Reason for cancellation
If the certificate has been revoked, this field contains information about the reason for certificate revocation. This information is of little practical importance, since regardless of the reason, certificate revocation results in the invalidity of signatures submitted afterwards.
Signatory certificate number
The fields specify the serial number of the signer’s certificate and the identifier of the entity that is the issuer of the certificate used to verify the signature.
Expiration dates
The field contains the validity interval of the signer’s certificate used to verify the signature.
A digest of the signed data
The field contains information about the algorithm and hash value of the signed data.
Warnings
The field contains warnings related to a given signature, which do not affect the result of signature validation, but of which the user should be informed. For a description of available warnings, see Section 3.3.
PARTICULARS #
Date of existence of the document declared by the user #
By law, a signature is considered valid if it was submitted when the certificate used for that purpose was valid. If the certificate was revoked, the service would compare the date of the signature with the date the certificate was revoked. If the signature was submitted before the moment of revocation, the signature is valid. If it was submitted after the moment of revocation, the signature is invalid.
How does the validation service know when the signature was submitted? The source to determine the date of the signature[3] can be:
- Qualified timestamp.
- The timing of document submission for validation.
- User-declared date.
The surest solution is to stamp the document with a qualified timestamp at the time of the signature, or as soon as possible thereafter. Then the validation service is sure that the signature was submitted no later than the date of the qualified timestamp, and it will verify the validity of the signature certificate at that point (more on qualified timestamp in Section 3.6).
If the document has not been time-stamped, then the validation service will verify the validity of the signature certificate as of the time the document is submitted for validation. If a long time has elapsed between the time of the signature and the time the document is submitted for validation, the signature certificate may have expired or been invalidated, in which case the validation result will not be positive.
In such a situation, the only way to obtain a positive validation result will be for the user to enter (declare) the date of existence of the signed document. However, it should be remembered that the burden of proving the correctness of this date lies with the user. The validation report will be valid, provided that if doubts arise about the fact that a document existed on a certain date, the user will be able to prove this fact based on other evidence.
Warnings related to the document #
| Ostrzeżenie | Znaczenie |
|---|---|
| Brak | Nie wykryto żadnych problemów z dokumentem. |
| Dokument zawiera aktywną zawartość, która może wpływać na prezentowaną treść. | W dokumencie PDF znajduje się JavaScript, który może wpływać na prezentowaną użytkownikowi treść podczas wyświetlania dokumentu np. prezentując różną zawartość dokumentu w zależności od daty. JavaScript może jednak pełnić pożyteczne funkcje np. walidować poprawność pól formularza. |
|
W dokumencie, na stronach |
Dokument PDF zawiera zawartość, która nie jest objęta przez wszystkie podpisy. Może to być celowa próba manipulacji, ale może być to również działanie całkowicie zamierzone i nieszkodliwe np.:
|
Signature-related warnings #
| Ostrzeżenie | Znaczenie |
|---|---|
| Brak podpisanego atrybutu: 'SigningCertificate'. | Ostrzeżenie to dotyczy konkretnego podpisu i oznacza, że w podpisanych danych nie zamieszczono wskazania na certyfikat do weryfikacji podpisu. Oznacza to, że gdyby istniało dwa lub więcej certyfikatów wystawionych na ten sam klucz, ale zawierających różniące się od siebie dane właściciela certyfikatu, to nie można by rozstrzygnąć którym certyfikatem wykonano faktyczny podpis. Byłaby więc możliwość wskazania jako autora innego subskrybenta posługującego się tym samym kluczem. Oprogramowanie Acrobat Reader, które często jest używane do podpisywania dokumentów PDF posiada opcję, która ustawia zastosowanie formatu podpisu (PKCS#7) niezgodnego z europejskim prawem i niezawierającego wymaganego atrybutu. Niestety opcja ta domyślnie jest włączona, co może oznaczać, że wiele dokumentów PDF jest podpisywanych bez zamieszczenia tego atrybutu. Ryzyko akceptacji dokumentu bez atrybutu ‘SigningCertifiate’ wydaje się małe, gdyż uzyskanie certyfikatów kwalifikowanych zawierających różne dane subskrybenta na ten sam klucz publiczny jest mało prawdopodobne, a potencjalne ataki są ograniczone. |
Types of signatures and seals #
- Qualified signature
- Qualified stamp
- Personal Signature – an advanced electronic signature made using the keys found on an ID card
- EPUAP signature – an advanced electronic signature applied using the EPUAP platform
- Advanced signature verified with a qualified certificate
- Advanced seal verified with a qualified certificate
- Advanced Signature
- Advanced stamp
- Seal of the qualified Signature and Seal Validation Service
- Stamp of qualified Registered Electronic Mail service
- Stamp of qualified Electronic Delivery service
- Seal of a qualified Signature and Seal Maintenance Service
Validation status details #
Details for the validation status case “invalid“
| Wartość | Opis |
|---|---|
| Skrót z dokumentu nie zgadza się z podpisanym skrótem | Dokument lub podpis został zmodyfikowany po wykonaniu podpisu lub podpis nie jest do tego dokumentu. |
| Podpis złożony certyfikatem po okresie ważności |
Podpis został złożony po okresie ważności certyfikatu. Możliwe działanie: Rozważyć, czy istnieje dowód na istnienie podpisanego dokumentu wcześniej, w okresie ważności certyfikatu; jeśli tak – wprowadzić datę z tego dowodu przy powtórnym wywołaniu usługi walidacji |
| Podpis złożony unieważnionym certyfikatem |
Podpis został złożony po unieważnieniu certyfikatu. Możliwe działanie: Rozważyć, czy istnieje dowód na istnienie podpisanego dokumentu wcześniej, przed datą unieważnienia certyfikatu; jeśli tak – wprowadzić datę z tego dowodu przy powtórnym wywołaniu. |
| Błędny format podpisu | Przekazany do walidacji dokument posiada podpis, którego format jest niepoprawny co uniemożliwia jego walidację. |
| Podpis nie może być zweryfikowany kluczem publicznym z certyfikatu podpisu | Dokument lub podpis został zmodyfikowany po wykonaniu podpisu lub podpis nie jest do tego dokumentu. |
Detailed information for the case of validation status “unspecified“
| Wartość | Opis |
|---|---|
| Atrybut wskazujący certyfikat do weryfikacji podpisu wskazuje na inny certyfikat niż użyty do złożenia podpisu | Błąd struktury podpisu (fałszerstwo lub błąd oprogramowania podpisującego) |
| Błąd weryfikacji ścieżki certyfikatów | Usługa nie jest w stanie zweryfikować ścieżki zaufania dla certyfikatu użytego do weryfikacji podpisu. Pojawienie się tego błędu jest skrajnie mało prawdopodobne gdyż oznaczałoby błąd leżący po stronie wystawcy certyfikatu. |
| Nie można zbudować ścieżki certyfikacji dla certyfikatu podpisu | Nie da się zbudować ścieżki zaufania do certyfikatu użytego do złożenia podpisu, na podstawie posiadanych list TSL. Przyczyną jest to, że wystawca certyfikatu nie znajduje się na liście zaufanych wystawców certyfikatów kwalifikowanych i niekwalifikowanych uznanych przez EU. |
| Algorytm kryptograficzny nie spełnia warunków walidacji |
Do złożenia podpisu lub do wystawienia jednego z analizowanych certyfikatów i list CRL został użyty algorytm kryptograficzny, co do którego są wątpliwości, czy jest wystarczająco bezpieczny. Więcej informacji o akceptacji podpisów złożonych z użyciem algorytmu SHA-1 znajduje się w rozdziale 3.8 |
| Niepoprawna kolejność znaczników czasu | Co najmniej jeden ze znaczników czasu dołączonych do dokumentu wskazuje niepoprawną datę (został dodany później, a mimo to wskazuje na wcześniejszą datę). Pojawienie się tego błędu jest skrajnie mało prawdopodobne gdyż oznaczałoby błąd leżący po stronie dostawcy usługi znakowania czasem. |
| Niedostępny certyfikat podpisu | Certyfikat użyty do złożenia podpisu nie został załączony do dokumentu i nie jest dostępny dla usługi walidacji. |
| Certyfikat podpisu został unieważniony natomiast nie określono daty dowodu istnienia podpisu lub Certyfikat wystawcy certyfikatów został unieważniony natomiast nie określono daty dowodu istnienia podpisu lub Certyfikat podpisu jest poza okresem ważności natomiast nie określono daty dowodu istnienia podpisu |
Dokument przekazany do walidacji nie został oznakowany czasem ani użytkownik nie wskazał manualnie daty istnienia dokumentu w związku tym usługa przyjęła jako datę istnienia podpisu czas bieżący. Dla tak przyjętej daty występuje wskazany problem z ważnością certyfikatu, który być może nie występował w momencie składania podpisu. Możliwe działanie: Rozważyć, czy istnieje dowód na istnienie podpisanego dokumentu wcześniej, przed datą unieważnienia lub przeterminowania certyfikatu; jeśli tak – wprowadzić datę z tego dowodu przy powtórnym wywołaniu walidacji. |
| Algorytm kryptograficzny nie spełnia obecnych warunków walidacji natomiast nie określono daty dowodu istnienia podpisu |
Dokument przekazany do walidacji nie został oznakowany czasem ani użytkownik nie wskazał manualnie daty istnienia dokumentu w związku tym usługa przyjęła jako datę istnienia podpisu czas bieżący. Dla tak przyjętej daty występuje problem z bezpieczeństwem wskazanego algorytmu, który być może nie występował w momencie składania podpisu. Możliwe działanie: |
| Certyfikat podpisu zawieszony lub Certyfikat wystawcy certyfikatów zawieszony |
Certyfikat został zawieszony przez wystawcę więc ważność podpisu nie może zostać określona do czasu uchylenia zawieszenia lub unieważnienia certyfikatu. Możliwe działania: |
| CRL/OCSP niedostępny lub ARL/OCSP niedostępny |
Usługa walidacji nie ma dostępu do informacji o unieważnieniach, którą powinien publikować wystawca certyfikatu, w związku tym nie można zweryfikować ważności certyfikatu użytego do weryfikacji podpisu. Brak dostępu może być spowodowany awarią po stronie wystawcy certyfikatu podpisu. Możliwe działania: |
| CRL/OCSP przeterminowany oraz brak daty dowodu istnienia podpisu. lub ARL/OCSP przeterminowany oraz brak daty dowodu istnienia podpisu |
Dokument przekazany do walidacji nie został oznakowany czasem ani użytkownik nie wskazał manualnie daty istnienia dokumentu w związku tym usługa przyjęła jako datę istnienia podpisu czas bieżący. Dla tak przyjętej daty występuje problem ze świeżością posiadanej przez usługę informacji o unieważnieniach, który być może nie występował w momencie składania podpisu. Brak odpowiednio świeżej informacji o unieważnieniach może być spowodowany awarią po stronie wystawcy certyfikatu podpisu. Możliwe działania: |
| CRL/OCSP wystawiony przed datą złożenia podpisu lub ARL/OCSP wystawiony przed datą złożenia podpisu |
Usługa walidacji nie ma dostępu do wystarczająco świeżej informacji o unieważnieniach, którą powinien publikować wystawca certyfikatu, w związku tym nie można zweryfikować ważności certyfikatu użytego do weryfikacji podpisu. Brak dostępu może być spowodowany awarią po stronie wystawcy certyfikatu podpisu. Możliwe działania: |
Qualified timestamp #
In accordance with EU Regulation 910/2014 (eIDAS) qualified electronic time stamp:
- is based on a precise time source linked to Coordinated Universal Time,
- ties the date and time to the data so as to sufficiently exclude the possibility of undetectable data changes, and
- is signed using an advanced electronic signature or affixed with the advanced electronic seal of a qualified trust service provider, or by other equivalent means.
Thus, it enjoys, in accordance with eIDAS, a presumption of the accuracy of the date and time it indicates and the integrity of the data to which the indicated date and time are linked.
In addition, according to Polish law, the stamping of an electronic document with a qualified time stamp is tantamount to giving that document the value of a date certain within the meaning of Article 81 §2(3) of the Civil Code.
Exact date of signature #
In order for the GetValid service to show the exact date of the signature, a conscious action by the person signing the document is required. The signer must proceed as follows (the method works only for documents in PDF format):
- Label the sometimes prepared PDF document.
- Sign the document.
- Mark sometimes a signed document.
In this case, the GetValid service will show that the signature was made in the date range between the first and second timestamps. Since the execution of the sequence: time-stamping – signature – time-stamping, can be done in single seconds, the resulting date of the signature will be known with such accuracy.
Acceptance of signatures with SHA-1 algorithm #
The SHA-1 algorithm has been widely used for electronic signatures, but over time, effective attacks have been discovered, including ones that enable the demonstration of the ability to forge an electronic signature created using SHA-1. The practical execution of this forgery is still quite difficult, as the attacker must specifically produce two specially crafted versions of a PDF document, one of which he gives to an authorized person to sign, and then he can substitute the signed document for the other version without compromising the signature. The attack thus requires advance preparation and requires the forger to be a trusted person for the signer and be able to plant the crafted document for signature. It is still not possible to forge any signed document, but the attacks discovered are serious enough to now rule out the use of SHA-1 for signatures.
Due to these weaknesses, in the standards for electronic signatures and in the legal systems of various countries, the SHA-1 algorithm is no longer considered secure and now SHA-2 family algorithms (SHA-256, SHA-512, etc.) are used for signatures. It is difficult to indicate unequivocally the exact date of the end of the usefulness of the SHA-1 algorithm, as this is a legal issue and may depend on the context and specific application of the signature. The GetValid service adopts the date specified in Article 137(1) of the Law of September 5, 2016 on trust services and electronic identification, i.e. July 1, 2018. – signatures validated for a date before July 1, 2018. (i.e., signatures submitted before that date), are validated positively (at that time, the attack on SHA-1 was not known, so there was no practical possibility of its execution), and signatures submitted later, are validated with a status of “Unspecified.”
[1] In fact, no documents are sent to the GetValid server, but only abbreviations from the documents and the signatures themselves.
[2] In case the verified qualified signature bears a non-qualified timestamp, such timestamp is not taken into account during validation and is not shown on the report.
[3] In fact, the service specifies the date of the signature with some approximation (no later than). It follows from the property of electronic signatures that if a certificate was valid at a certain point in time, it was also valid at any point earlier, and in particular at the point in time in which it was actually used to make the signature. Therefore, for signature validation, it is sufficient to demonstrate the validity of the certificate at any time later than the signature.
