LogoSignature Service
Risk Management Toolbox

Validation Rules

This chapter describes the different rules in the Risk Management Toolbox and their configuration.

When a configuration is required, an example is shown in JSON format. The same configuration can be set in profiles using the YAML format.

Integrity validation rules

File Readable

Validates that the document is a valid PDF that can be opened and parsed.

This rule mandatory and enabled by default, it's not mandatory to add it in the validation rules list.

Rule ID: fileReadable

JSON Example

{
  "id": "fileReadable"
}

YAML Example

- id: fileReadable

PDF/A Compliance

Validates that the document is compliant with a given PDF/A standard and conformance level.

Supported standards:

  • PDF/A-1 (Use of PDF 1.4), conformance level A and B
  • PDF/A-2 (Use of Use of ISO 32000-1), conformance level A, B and U
  • PDF/A-3 (Use of Use of ISO 32000-1 with support for embedded files), conformance level A, B and U

Rule ID: pdfACompliance

Configuration:

  • compliance (String): The expected PDF/A version and conformance level (1a, 1b, 2a, 2b, 2u, 3a, 3b, 3u)

JSON Example

{
  "id": "pdfACompliance",
  "configuration": {
    "compliance": "1b"
  }
}

YAML Example

- id: pdfACompliance
  configuration:
    compliance: 1b

Maximum file size

Validates that the document's size does not exceed the maximum size.

Rule ID: maxFileSize

Configuration:

  • maxFileSize (DataSize): The maximum file size allowed with its unit (B, KB, MB, GB).

JSON Example

{
  "id": "maxFileSize",
  "configuration": {
    "maxFileSize": "100KB"
  }
}

YAML Example

- id: maxFileSize
  configuration:
    maxFileSize: 10MB

Content validation rules

Visual PDF comparison

Compares visually the PDF from a control document. PDFs are rendered and each page are compared pixel by pixel.

The rule's configuration allows to ignore some part of the document that are expected to be modified (e.g. form fields).

It's also possible to specify the rendering resolution using the resolution configuration to speed up the validation and the memory usage. The default resolution is 300 dpi. This resolution can be safely lowered to 150 without altering the quality of the comparison.

The configuration offers also the possibility to reduce the number of false positive violations by allowing a percentage of pixels that might differ. These differences may occur if the document has been compressed or modified by a different PDF tool. A page in A4 format with a 300dpi resolution is then rendered into an image of 2480 x 3508 pixels.

Rule ID: visualComparison

Configuration:

  • ignoreFormFields (Boolean): Ignore differences spotted in forms fields from the control document. Default is false.
  • ignoreAdditionalSignatureFields (Boolean): Ignore differences located in an additional signature field from the signed document. This option is useful if the signature field is added and located at signature time. Default is false.
  • resolution (Integer number between 10 and 500): Specify the DPI resolution for the image rendering. Default is 300.
  • tolerancePercentage (Floating number between 0.0 to 100.0): Percent of pixels that may differ per page. Default is 0.0.

The PDF control document must be set in controlData attribute of the request.

JSON Example

{
  "id": "visualComparison",
  "configuration": {
    "ignoreFormFields" : "true",
    "ignoreAdditionalSignatureFields" : "false",
    "tolerancePercentage" : "0.05"
  }
}

YAML Example

- id: visualComparison
  configuration:
    ignoreFormFields: true
    ignoreAdditionalSignatureFields: false
    tolerancePercentage: 0.05

Javascript Detection

Detects the presence of javascript in the document.

A violation will be reported in one more multiple scripts have been detected in the document.

The rule's configuration ignoreExisting allow to ignore scripts that are already present in the control document provided. If set to true a violation will be created only if one or more scripts have been added, removed or edited.

Rule ID: javascriptDetection

Configuration:

  • ignoreExisting (Boolean): Ignore scripts that are present in control document

If ignoreExisting is set to true, the PDF control document must be set in controlData attribute of the request.

JSON Example

{
  "id": "javascriptDetection",
  "configuration": {
    "ignoreExisting" : "true"
  }
}

YAML Example

- id: javascriptDetection
  configuration:
    ignoreExisting: true

Signature validation rules

Signatures integrity

Validates that the signature(s) are correctly formatted and match the signed revision (document has not been altered between signatures).

If the control document is provided to the request, the rule also validates that all signatures from the control document are still present in the actual document. It's also possible to specify the number of expected new signature(s) to verify that the exact number of signatures have been applied to the control document.

Configuration:

  • expectedNewSignatures (Integer): Specifies the expected number of signatures applied to the control document.

If expectedNewSignatures is set, the PDF control document must be set in controlData attribute of the request.

Rule ID: signatureIntegrity

JSON Example

{
  "id": "signatureIntegrity",
  "configuration": {
    "expectedNewSignatures" : "1"
  }
}

YAML Example

- id: signatureIntegrity
  configuration:
    expectedNewSignatures: 1

Trusted Timestamps

Validates that the timestamp(s) embedded in signature(s) were issued by a trusted Certificate Authority (CA). By default, the validation will be successful if one of the certificate from the chain (including intermediate certificates) is issued by one of the trusted CA.

The validation will fail if a signature does not have an embedded timestamp.

The trusted CAs can be either specified with the Public Keys (publicKeys) or with X509 certificates (x509Certificates).

Rule ID: trustedTimestamp

Configuration:

  • publicKeys: An array of Base64 encoded trusted public keys
  • x509Certificates: An array of Base64 encoded X509 certificates

JSON Example

{
  "id": "trustedTimestamp",
  "configuration": {
    "publicKeys": [
      "MIIBIjANBg...",
      "MIIBIjDKds..."
    ],
    "x509Certificates": [
      "MIIFuTCC...",
      "MIIFuTCF..."
    ]
  }
}

YAML Example

- id: trustedTimestamp
  configuration:
    publicKeys:
    - MIIBIjANBg...
    - MIIBIjDKds...
    x509Certificates:
    - MIIFuTCC...
    - MIIFuTCF...

Trusted Certificate Authorities

Validates that the certificate(s) used for the signature(s) were issued by a trusted Certificate Authority (CA). By default, the validation will be successful if one of the certificate from the chain (including intermediate certificates) is issued by one of the trusted CA. It's possible to restrict validation to the root certificate only by setting the configuration validateRootCertificateOnly.

The trusted CAs can be either specified with the Public Keys (publicKeys) or with X509 certificates (x509Certificates).

Rule ID: trustedRootCa

Configuration:

  • publicKeys: An array of Base64 encoded trusted public keys
  • x509Certificates: An array of Base64 encoded X509 certificates
  • validateRootCertificateOnly (Boolean): Validate that only root certificate matches one of the trusted CA. Default is false.

JSON Example

{
  "id": "trustedRootCa",
  "configuration": {
    "publicKeys": [
      "MIIBIjANBg...",
      "MIIBIjDKds..."
    ],
    "x509Certificates": [
      "MIIFuTCC...",
      "MIIFuTCF..."
    ],
    "validateRootCertificateOnly" : "false"
  }
}

YAML Example

- id: trustedRootCa
  configuration:
    publicKeys:
    - MIIBIjANBg...
    - MIIBIjDKds...
    x509Certificates:
    - MIIFuTCC...
    - MIIFuTCF...
    validateRootCertificateOnly: false

Signature Content

Validates the information contained in the signature(s) of the document: signer's certificate, signature meta data and position of the signature in the document.

In case of multiple signatures, the array of signatures must be given in the same order as the signatures (first signature in first position).

Rule ID: signatureContent

Configuration:

  • signatures: An object or an array of objects defining a signature:
    • subjectDn (String): The distinguished name of the signer's certificate formatted following RFC 2253 rules.
    • sha256Fingerprint (String): The SHA256 fingerprint of the signer's certificate (case insensitive, without any spaces).
    • selfSigned (Boolean): The certificate is self-signed.
    • pageIndex (Integer): The page index where the signature field is located (starting from 0).
    • fieldName (String): The name of the field where the signature is located.
    • visible (Boolean): Verifies that the signature field is visible on a page (with or without content).
    • name (String): The value of the signature's name field.
    • reason (String): The value of the signature's reason field.
    • location (String): The value of the signature's location field.
    • certificateAttributes (String, String object): List of the attributes that the distinguished name of the signer's certificate must contain. The attribute's name must match the full name as described here in the oidref.com/2.5.4.49 reference, or the OID for any other attribute.
    • issuerCertificateAttributes (String, String object): List of the attributes that the distinguished name of the issuer's certificate must contain. The attribute's name must match the full name as described here in the oidref.com/2.5.4.49 reference, or the OID for any other attribute.

An empty or null field indicates that it can be equal to any value.

JSON Example

{
  "id": "signatureContent",
  "configuration": {
    "signatures" : [
      {
        "subjectDn" : "c=CH,o=SwissSign AG,l=Glattbrugg,cn=John Doe",
        "sha256Fingerprint" : "7431E5F4C3C1CE4690774F0B61E05440883BA9A01ED00BA6ABD7806ED3B118CF",
        "selfSigned" : "false",
        "pageIndex" : "0",
        "fieldName" : "Signature12",
        "visible" : "true"
        "name" : "username-1",
        "reason" : "accepted",
        "location" : null,
        "certificateAttributes" : {
          "commonName" : "John Doe",
          "serialNumber" : "FIB43893891"
        },
        "issuerCertificateAttributes" : {
          "commonName" : "Company - ICA 2",
          "organizationName" : "Company Name"
        },
      }
    ]
  }
}

YAML Example

- id: signatureContent
  configuration:
    signatures:
    - subjectDn: c=CH,o=SwissSign AG,l=Glattbrugg,cn=John Doe
      sha256Fingerprint: 7431E5F4C3C1CE4690774F0B61E05440883BA9A01ED00BA6ABD7806ED3B118CF
      selfSigned: false
      pageIndex: 0
      fieldName: Signature12
      visible: true
      name: username-1
      reason: accepted
      location: null
      certificateAttributes:
        commonName: John Doe
        serialNumber: FIB43893891
      issuerCertificateAttributes:
        commonName: Company - ICA 2
        organizationName: Company Name

Visible signature content

Validates that all the signatures of the document are visible and have content.

Signatures are rendered into images and pixels are analyzed. The configuration offers the possibility to reduce the number of false positive violations by specifying the percentage of pixels the signature should represents in the field.

The size of the signature field can be validated by using minWidth, maxWidth, minHeight and maxHeight attributes. Undefined value(s) will skip the validation of the property.

Rule ID: visibleSignatureContent

Configuration:

  • signatureContentPercentage (Floating number between 0.0 to 100.0): Minimum percentage of pixels filled in the signature field for a signature to be considered visible. Default is 0.5.
  • minWidth (Floating positive number): Minimum width of the signature field.
  • maxWidth (Floating positive number): Maximum width of the signature field.
  • minHeight (Floating positive number): Minimum height of the signature field.
  • maxHeight (Floating positive number): Maximum height of the signature field.

JSON Example

{
  "id": "visibleSignatureContent",
  "configuration": {
    "signatureContentPercentage" : "0.05",
    "maxWidth" : "100",
    "maxWidth" : "500"
  }
}

YAML Example

- id: visibleSignatureContent
  configuration:
    signatureContentPercentage: 0.05
    minWidth: 100
    maxWidth: 500

ETSI Validation

This validation is currently in the experimental phase and the default validation policy, as well as the APIs are subject to change in a future release.

Validates that the digital signatures follow the ETSI standard for Advanced Electronic Signature.

The default validation policy perform the following validations:

  • Signature integrity
  • Certificate chains (signature, timestamps) validated against the provived trusted sources
  • Signature contain an embedded timestamp
  • Revocation data (OCSP / CRL) available

By default, revocation data are validated using offline sources (revocation data available in the document). If the signatures are not LTV enabled (Long Term Validation), the configuration onlineRevocationSources must be set to true to perform online validation using the CRL / OCSP sources provided in the signatures.

The validation fails if the signing time is from the clock of the signer's computer (no embedded timestamp) or if the revocation data are not available.

Rule ID: etsiValidation

Configuration:

  • x509Certificates: An array of Base64 encoded X509 certificates
  • onlineRevocationSources (Boolean): Configure whether revocation data (OCSP, CRL) must be validated using online or offline sources. Default is false.

JSON Example

{
  "id": "etsiValidation",
  "configuration": {
    "x509Certificates": [
      "MIIFuTCC...",
      "MIIFuTCF..."
    ],
    "onlineRevocationSources" : "false"
  }
}

YAML Example

- id: etsiValidation
  configuration:
    x509Certificates:
    - MIIFuTCC...
    - MIIFuTCF...
    onlineRevocationSources: false

On this page