B_BES (baseline) profile and invalid signature

[heikih]

I'm trying to create BDOC container with B_EPES profile and tested adding invalid signature.

I have following code for signing:

var dataToSign  = SignatureBuilder
                .aSignature(bDocContainer)
                .withSignatureProfile(SignatureProfile.B_EPES)
                .withSigningCertificate(certificate)
                .withSignatureDigestAlgorithm(DigestAlgorithm.SHA256)
                .buildDataToSign();

Signature signature = dataToSign.finalize(signatureBytes);

bDocContainer.addSignature(signature);

If signatureBytes is invalid then bDocContainer.addSignature(signature) doesnt throw exception, same line throws exception if using LT_TM profile.

Is this so by design or is it a bug?

[naare]

Hello,

Could you please clarify what do you mean by invalid signature? In example code you do not show actual signing. You just inserted random bytes (signatureBytes)?

[heikih]

Tried both random bytes and empty byte array:

dataToSign.finalize(new byte[0]);
bDocContainer.addSignature(signature);

Looks like in case of baseline profile signature is not checked at all.
In case of LT_TM or LT profile following error is thrown:
eu.europa.esig.dss.model.DSSException: Cryptographic signature verification has failed / Signature verification failed against the best candidate.

[Marten332]

Thank you for bringing it to our attention.

The exception should be thrown at dataToSign.finalize(signatureBytes); not at addSignature(signature); as in your previous statement.

This behavior is by design and originates from the DSS library. Signatures with the B_EPES/B_BES profile (baseline profile) skip the validation process. Validation is done only on signature extension to "higher" profiles (LT/LT_TM/LTA).

We will look into this further to assess whether this should be changed.

[naare]

We have removed the support of B_EPES and LT_TM profile in Digidoc4j version 5.2.0. However the same behavior is still present for B_BES profile. I have modified the heading.