Skip to content

Latest commit

 

History

History
51 lines (34 loc) · 3.99 KB

privacy.adoc

File metadata and controls

51 lines (34 loc) · 3.99 KB
Raw

1. Privacy

1.1. Use of digested documents

Digested documents can be used during signature creation instead of the original documents to keep the latter private. In that case, the signature is created in a detached way, using the digest of the original document only.

Refer to section [DSSDocuments] for more information on digested documents, section [Packaging] for information on the detached packaging of signatures and section [DetachedSignatureDigest] for code illustrations.

1.2. Original document in the Data To Be Signed

The data to be signed (DTBS) for CAdES, XAdES and PAdES does not contain the original document on which the signature value is computed. JAdES DTBS however, when not the DTBS of a detached JAdES signature making use of the ObjectIdByURIHash referencing mechanism, does contain the whole original content.

1.3. Private information in logs

Five log levels are used in DSS:

  • ERROR - is used for the most critical issues, interrupting a normal process workflow (encoding issues, not processable signed attributes, etc.).

  • WARN - is used to indicate problems occurred during an executed process. Such issue does not stop or invalidate the process explicitly, but can have an impact on the final output.

  • INFO - returns important or useful information to the logs.

  • DEBUG - is used to print extended information, such as token binaries, attribute values, etc.

  • TRACE - is used to indicate the currently performing methods and state of objects.

When setting a log execution level to ERROR, WARN or INFO levels, no private information will be print to the log file. However, DEBUG and TRACE might potentially contain private information, as they display more information, including the source binaries of tokens.

Since the logs are hardcoded it is not possible to modify the behavior. Therefore, to avoid disclosing private information, users should not use the DEBUG and TRACE levels. It is also not recommended using these two levels in the production.

For example, when an error occurs on a certificate reading, DSS only WARN users that an error occurred. However, if the log level is set to DEBUG on the user’s side, the binaries of the failed certificate are printed.

Sometimes, DSS uses mixing rules for logging, such as it displays more information within a WARN or INFO level when DEBUG level is enabled.

1.4. Client-side signature creation with server-side remote key activation

With DSS, it is possible to sign a document without needing to send it to the signing server. This is useful for users who do not want signing servers to have access to the information contained in their documents. Such a process is possible because DSS decomposes the signature of a document in three or four atomic steps. See section [SignatureCreationThreeSteps] and [SignatureCreationFourSteps] for an extensive description of these steps.

  1. The first step is performed by the client and consists in the computation of the data to be signed (DTBS).

  2. For the XAdES, CAdES and PAdES formats, the client can optionally compute the digest of the DTBS (DTBSR). For JAdES the client should compute the digest of the DTBS to "hide" the content of the original document, given that the DTBS of this format (usually) contains the whole original content. The client sends the DTBS or the DTBSR to the server.

  3. Then, the server computes the signature value by encrypting the DTBSR (or hashing the DTBS and encrypting the resulting DTBSR in one go) using the private key. The server sends the signature value back to the client.

  4. The last step takes place at the client-side. The client adds the signature value to the appropriate field.

The following schema illustrates the different steps

client-server

For code illustrations of the different steps, refer to the [ClientServerAnnex] section in the Annex.