4

I'm stumped trying to figure out Esig DSS java suite just from docs and source. (eu.europa.esig.dss.* tree)

We connect to Swedish BankID to sign PDF's and simple plain texts. Response is a SOAP XML with fields for the signature and an OCSP response.

The end goal is to combine these two parts into a single object "a valid signature" that can be embedded in a PDF (using DSS and PDFbox).

The contents of the BankID Soap fields seems to have the right format for DSS tools:

The signature can be loaded with

DSSDocument sigDoc = new InMemoryDocument(xmlSignature)
SignedDocumentValidator documentValidator = SignedDocumentValidator.fromDocument(sigDoc);
// ...
AdvancedSignature advancedSignature = documentValidator.getSignatures().get(0);

and the OCSP response can be read with

ExternalResourcesOCSPSource source = new ExternalResourcesOCSPSource(ocspBytes);
BasicOCSPResp basicOCSPResp = source.getContainedOCSPResponses().get(0);

I can print out various info from the objects, find embedded certificates etc, so the format seems legit.

Question: How do I get a valid OCSPToken from the ExternalResourcesOCSPSource?

I keep running in circles trying to combining the two into a single AdvancedSignature (if that's what I can use to embed into a PDF).

pedrofb
  • 37,271
  • 5
  • 94
  • 142
user1394389
  • 43
  • 6

1 Answers1

0

An advanced digital signature provided by a third system can not be used to create a valid signed PDF

A PAdES signature is always enveloped into a PDF document, so it is not possible for the signature service to be returning a detached PAdES signature that is considered valid by DSS.

It probably provides a detached CAdES or XAdES signature into the SOAP message that can be processed by DSS( DSS provides a high level API to sign documents using XAdES, CAdES, PAdES and aSiCS formats).

Both formats support embedding the OCSP responses, but it requires to add a TimeStamp too, which make more difficult to build the final format. It could be the reason to use a custom field into the SOAP message to return the OCSP response

XAdES and PAdES are conceptually similar but structurally different. A XAdES signature is XML and PAdES is binary. A XML signature can not be converted to PAdES

PAdES and CAdES use CMS, both are binary and they use ASN.1 syntax. But the signed message is different, CAdES signature is calculated on the entire document (and some othe attributes) and PAdes use certain data of the PDF document. Therefore a cades signature could not be converted to PAdes either.

pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • Thanks for this, it answers the title well! – user1394389 Sep 13 '18 at 21:14
  • (cont'd) Thanks for this, it answers the title well! Text goes off to ask about combining signature and ocsp, which seems prerequisite for anything. Anyway we also have the option to send hidden message digest to be signed with BankID. Would you suggest this couldn't work either? If we create digest from the PDF, couldn't the signature value match the PDF bytes in a real PAdES? Otherwise we'll try for embedded Xades, but that's probably food for a dozen different questions. – user1394389 Sep 13 '18 at 21:21
  • Make a digest of the PDF and attributes to sign, sign it externally in BankId and then compose the result document is feasible. In fact the signature process of the DSS API works like this, so you could use it directly without adaptations. But it is imperative that BankID make a basic signature PKCS#1, not an advanced signature (An advanced signature format includes a PKCS#1 signature but the digest to sign is recalculated so you can not extract and reuse it). I suggest you talk to the service provider to see if you have that option – pedrofb Sep 14 '18 at 06:26
  • Thanks for reply again, this helps our investigations! – user1394389 Sep 14 '18 at 14:54