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).
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.
Related
I've been reading the official PDFBox examples to visually sign a PDF document, especifically the example from CreateVisualSignature2.java, which generates an empty document as a template to define the signature appearance and then sets it to the real document by calling SignatureOptions.setVisibleSignature().
In my case, I've been using an HSM service to do the signing for me, so I don't have direct access to private keys or certificates. I send the document hash to this service and it returns a PKCS7 byte array which I add to my document using ExternalSigningSupport.setSignature().
The code, which is based on the PDFBox example linked above, looks like this:
// Read the document and prepare a signature.
PDDocument document = PDDocument.load( "path/to/file.pdf" );
PDSignature signature = new PDSignature();
signature.setFilter( PDSignature.FILTER_ADOBE_PPKLITE );
signature.setSubFilter( PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED );
signature.setReason( "Test" );
InputStream template = createVisualSignatureTemplate( document ); // Implementation defined below.
SignatureOptions options = new SignatureOptions();
options.setVisibleSignature( template );
options.setPage( 0 );
document.addSignature( signature, options );
// Get the content to sign using PDFBox external signing support.
FileOutputStream outputStream = new FileOutputStream();
ExternalSigningSupport externalSigning = document.saveIncrementalForExternalSigning( outputStream );
byte[] content = IOUtils.toByteArray( externalSigning.getContent() );
// Send the content to the HSM service and get the response.
byte[] hash = MessageDigest.getInstance( "SHA-256" ).digest( content );
byte[] pkcs7 = MyHSMService.getSignedHash( hash );
// Add the signature to the PDF.
externalSigning.setSignature( pkcs7 );
document.close();
And my template method, based on the method of the same name in the linked PDFBox example, simplified:
PDDocument emptyDocument = new PDDocument();
emptyDocument.addPage( new PDFPage( document.getPage(0).getMediaBox() ) );
// Create the PDAcroForm, PDSignatureField, PDAppearanceDictionary, etc,
// just like in the official example.
(...)
// Define the content stream of the visual signature.
PDPageContentStream content = new PDPageContentStream( emptyDocument, appearanceStream );
content.beginText();
content.showText( "Signed by: ... " ); // The signer name should be here.
content.newLine();
content.showText( "Date: ..." ); // The signature datetime should be here.
content.endText();
content.close();
// Convert the empty document as an input stream and return it, just like the example.
(...)
This works fine and I can add valid visual signatures without issues. My problem is that I need to add the signer name and sign date in the signature appearance, but since I create the template BEFORE calling my HSM service to sign, I don't have access to that data yet, which is why I need to define the content AFTER signing the document.
Is there a way to achieve this? I'm new to PDF signing, so my understanding of the fundamentals is pretty poor.
Thanks in advance!
The in-document visualization of a pdf signature is a pdf widget annotation and as such it is part of the signed content. Thus, it must be added before signing and only information can be used in it which is known before signing.
There is one option, though, most signature types allow changing annotations in a revision after the signed revision. Read here about allowed and disallowed changes to signed pdf documents.
But a pdf viewer then still may warn that changes have been applied to the document after signing. Such a warning would look like this:
(Here the signature appearance has been changed to a red diagonal cross.)
If you sign this changed document again, you can even get rid of the warning in the signature ribbon at the top:
(Images are from this answer where changes to signature appearances using itext have been tested.)
When it comes to the datetime, I could show the date of the PDSignature object itself, but in this case the time shown in the visualization won't be the same as the time shown in the signatures panel in the PDF viewer, since the actual signature will happen a few seconds later when I call the HSM service. In this case I have no other choice than to make a new revision just to correct the time, right?
Well, first of all there is no need for a signing time attribute in the CMS signature container embedded in a pdf signature because the signing time can also be given in the M entry if the signature dictionary.
Thus, one choice is to try and retrieve a signature container without signing time attribute. In that case the PDSignature signing time will be shown in the signature panel.
If you use digital time stamps, though, to document the signing time, it is part of the CMS signature container or even a separate document time stamp, so this's option wouldn't work.
Furthermore, you mention the signature panel. As the exact information can be found there, do you really need the signing time in the signature visualization? The visualization is only cosmetic in nature, it may contain arbitrary information, so nobody should trust it anyways. Adobe had warned about this already many years ago, even before pdf became an ISO standard...
Thus, another choice is simply to put a nice looking logo there and that's it!
I am signing a pdf with digital certificate using iText. Now I can sign, and add LTV, but CertificateLevel can just be:
signatureAppearance.setCertificationLevel(PdfSignatureAppearance.CERTIFIED_FORM_FILLING_AND_ANNOTATIONS);
I just want to set PdfSignatureAppearance.CERTIFIED_NO_CHANGES_ALLOWED. The final result should look like this:
sap.setCertificationLevel(PdfSignatureAppearance.CERTIFIED_NO_CHANGES_ALLOWED);
MakeSignature.signDetached(signatureAppearance, privateKey, "SHA-512", chain, null, ocspClient, tsaClient, 0, MakeSignature.CryptoStandard.CADES);
If i use the above code to sign, then using AdobeLtvEnabling.java to add LTV will prompt the signature to be invalid when using ACROBAT check, because the file is modifying the unmodifiable PDF file when adding LTV. Thus, what can i do to approach the final effect.
To get a result like in your snapshot, i.e. both "No changes are allowed" and "Signature is LTV enabled" without any later signature or document timestamp, you have to
either already include all LTV material the Adobe validator requires into your original signed revision
or use a signing mode which allows you to append LTV material in spite of no changes being allowed.
Unfortunately the latter variant seems not yet to be properly supported by Adobe Acrobat Reader.
For details see the following sections.
Include all LTV material into the original signed revision
First of all, this is not always possible. If you want to have the LTV material in the original signed revision, it must be part of the signed data, so you have to collect it before signing. In many setups using remote signing services, though, you don't know which signing certificate exactly will be used before actually requesting the signature.
If it is possible, though, i.e. if you know the signing certificate in advance, you can use the class AdobeLtvEnabling from this stack overflow answer to include the information like this:
PdfStamper stamper = PdfStamper.createSignature(...);
AdobeLtvEnabling adobeLtvEnabling = new AdobeLtvEnabling(stamper);
OcspClient ocsp = new OcspClientBouncyCastle();
CrlClient crl = new CrlClientOnline();
adobeLtvEnabling.addLtvForChain(YOUR_SIGNER_CERTIFICATE, ocsp, crl, PdfName.A);
adobeLtvEnabling.outputDss();
[...preparing your signature...]
MakeSignature.signDetached(...);
(CreateSignatureComodo test testCreateLtvNoChangesAllowedCertification)
You might have to make the AdobeLtvEnabling methods addLtvForChain and outputDss public for this as AdobeLtvEnabling originally wsn't intended to be used like this.
The result:
Use a signing mode which allows appending LTV material but nothing else
Alternatively you can sign your PDF in a way that allows later addition of LTV material in spite of a "no changes allowed" certification.
To start with, it is necessary to make use of a mechanism first specified for PAdES signatures if you want to add LTV material to a PDF after applying the signature it is meant for. While this mechanism has meanwhile been included in ISO 32000-2, it is not available in a plain ISO 32000-1 context. As your screenshot is of a Adobe Acrobat, though, that shouldn't be an issue for you.
This mechanism are the document security stores. Both the iText class LtvVerification and the class AdobeLtvEnabling from this stack overflow answer fill such stores in a PDF.
Is it allowed to add these document security stores in spite of a "no changes allowed" certification? — It depends...
If your PDF is a PDF-2.0: yes. ISO 32000-2 characterizes the changes allowed or disallowed by some certification like this:
Changes to a PDF that are incremental updates which include only the data necessary to add DSS’s 12.8.4.3, "Document Security Store (DSS)" and/or document timestamps 12.8.5, "Document timestamp (DTS) dictionary" to the document shall not be considered as changes to the document as defined in the choices below.
(ISO 32000-2, Table 257 — Entries in the DocMDP transform parameters dictionary)
If your PDF is a PDF-1.x with the PAdES extensions enabled: yes. ETSI EN 319 142-1 requires
DocMDP restrictions (see ISO 32000-1 1, clause 12.8.2.2) shall not apply to incremental updates to a PDF document
containing a DSS dictionary and associated VRI, Certs, CRLs and OCSPs.
...
When evaluating the DocMDP restrictions (see ISO 32000-1 1, clause 12.8.2.2) the presence of a Document
Time-stamp dictionary item shall be ignored.
(ETSI EN 319 142-1 V1.1.1, section 5.4 Validation data and archive validation data attributes)
If your PDF is a plain PDF-1.x, though: no!
If you want to use this option and add LTV information after signing, therefore, make sure your originally certified PDF is a PDF-2 or has at least the PAdES extensions enabled.
While iText 5 does not support PDF-2, creating a PAdES style signature with it adds the PAdES extensions.
Thus, if you certify PAdES-style, you should be able to LTV-enable the signature even if the certification is "no changes allowed".
Support by Adobe Acrobat Reader DC 2019.008.20080
Having done some tests extending a no-changes allowed certified PDF with only LTV information, the PDF being either marked as PDF-1.7 with the appropriate ETSI and Adobe extensions or as PDF-2.0, it appears that Adobe Acrobat supports neither ETSI EN 319 142-1 nor ISO 32000-2 fully yet: In all tests it considered the certification as broken, cf. CreateSignatureComodo test testCreateNoChangesAllowedCertificationAndLtv.
For the time being, therefore, to get a document with LTV enabled no-changes-allowed certification and to have Adobe Acrobat recognize this, one only has the first option above, i.e. including all LTV material into the original signed revision.
A work-around might be to create the certification with form-filling-allowed, then adding LTV information, and then signing with another (approval) signature which changes the document to no-changes-allowed via its field lock dictionary and its FieldMDP transform, cf. CreateSignatureComodo test testCreateCertificationAndLtvAndNoChangesAllowed. As the incremental update of that signature can be removed by a knowledgeable person, though, this is far from perfect.
The result for the work-around:
I'm using itextsharp and I guess the following will be useful for your Java code too.
If you call MakeSignature.SignDetached with CrlClient and OcspClient (instead of passing null as parameter), you'll get a LTV-enabled signature after the first step. Then you needn't do the second step to add a document timestamp after.
var stamper = PdfStamper.CreateSignature(reader, stream, '\0', null, true);
var appearance = stamper.SignatureAppearance;
appearance.CertificationLevel = PdfSignatureAppearance.CERTIFIED_NO_CHANGES_ALLOWED;
...
var privateKey = ...
var chain = ...
var crlClient = new CrlClientOnline(chain);
var ocspClient = new OcspClientBouncyCastle();
var tsaClient = new TSAClientBouncyCastle("http://....");
MakeSignature.SignDetached(appearance, privateKey, chain,
new[] { crlClient },
ocspClient,
tsaClient,
0,
CryptoStandard.CMS);
stamper.Close();
Hope this works for you.
Is not so clear to me how to check and parse value passed by this partial response envelope in SAML 2.0:
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#ID_ce8c62aa-08e4-4a21-a89a-af4fbd7a9f50">
<dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>ImUVGjTf7WTCmboAbAtjx7WKQhI=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>CDk+O/3PPh57l84pjFW0xwiPYJ+yinYJciBowT3nkPaAXeMYCH1AopZl7ZP+swPiK+oYuW9STPSlJVuEuDao5VbSU2WlQR7Ed9nZMt9PNY19/eKtkAqbMk01ZY8YH6OyTQm17w6IzNRbY4sJcHSRz9eDUsTzAYVhV9PEBgT1ouZsghklMCe0iYBjK5LmRS88jGmCN5sZ5+L8+KimTCakWSJ8CLntEAFx1SBL50Or4e8j6nHiW7g==</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>4Gvzu2dCYGhdWr9Er/WtgbWRqAR798IPCfAubx8NeBKG/X6P7sM91zbD2LEH4tJS2vkMCnQFidoLdeh1SHp7+GLHnVsgTcj6NPOit0EOHz10tdRmFMwoRCh5hcMFEisFUgSdaS8bO2wSXBmLENfLDUOSYKKLP0JGtTqnAZ0A99UNrVWKemx/EnHopH+Q7M+zmbj8VWFVlCK6rDfXJLUBr+kGSlw==</dsig:Modulus>
<dsig:Exponent>AQAB</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</dsig:KeyInfo>
</dsig:Signature>
So basically the RSAKeyValue should contain the "public key" to read the DigestedValue?
So what's the purpose of the Signature value?
I would like to implement a Java class to decrypt (I have the proper keystore and pass to do that...). Please point me in the right direction.
As written in the comment, it's an XML signature. The signature allows you to validate the XML has been signed by a trusted party and the element hasn't been modified. So you can trust the SAML response is really from the IdP you can trust. It is not encryption.
I would like to implement a Java class to decrypt
As I stated there's nothing to decrypt, you can only validate integrity of the signed XML element.
For that I suggest you use an out of box library to process the XML (it will be boring to implement all canonization options, etc..). I suggest you use an out of box library ( OpenSAML, spring-security-saml2) to validate the signature.
if you want to do it yourself, just read search/about the XML signatures.
What you have there:
<dsig:Reference URI="#ID_ce8c62aa-08e4-4a21-a89a-af4fbd7a9f50">
There must be an element in your XML with id attribute of "#ID_ce8c62aa-08e4-4a21-a89a-af4fbd7a9f50" and the signature ensures integrity of the refered XML element. Make sure the signature is refered to the whole SAML message or an assertion element. If not, you're code would be prone to signature injection attacks. That's why I suggest you use a mature library for that.
<dsig:DigestValue>ImUVGjTf7WTCmboAbAtjx7WKQhI=</dsig:DigestValue>
RSA doesn't work with messages of arbitrary (any) length, so a message digest (sha-1 hash) is created and that is signed. The DigestValue is value of the hash created from the signed XML element and its content. (how to create a whole content to be hashed is depending on the parameters stated in the CanonicalizationMethod, Transforms, DigestMethod, you can read about it in the first link)
<dsig:SignatureValue>
This is the RSA/PKCS1.5 signature of the DigestValue
I hope that clarifies your question.
We 're trying to sign a PDF document using the CAdES method and the examples in dss-cookbook as a starting point using the latest version (4.6.RC1).
Following the example from SignPdfPadesBDetached.java, we have succesfully signed a PDF document using PAdES. However, since there is no example for CAdES, we tried adapting the above example to use CAdES, but
it doesn't work. Specifically the generated PDF document has a size of only 7k instead of the expected 2.5MB and the following error is displayed when trying to open the PDF: We assume the 7k is actually only the signature so that the actual document is not included. The settings we use are:
SignatureLevel.CAdES_BASELINE_B
SignaturePackaging.DETACHED
DigestAlgorithm.SHA256
And the relative's method code is currently this:
public static void signPdfWithCades(DSSDocument toSignDocument) {
LOG.info("Signing PDF with CADES B");
try {
AbstractSignatureTokenConnection signingToken = new Pkcs12SignatureToken("password", KEYSTORE_PATH);
DSSPrivateKeyEntry privateKey = signingToken.getKeys().get(0);
// Preparing parameters for the CAdES signature
CAdESSignatureParameters parameters = new CAdESSignatureParameters();
// We choose the level of the signature (-B, -T, -LT, -LTA).
parameters.setSignatureLevel(SignatureLevel.CAdES_BASELINE_B);
// We choose the type of the signature packaging (ENVELOPING, DETACHED).
parameters.setSignaturePackaging(SignaturePackaging.DETACHED);
// We set the digest algorithm to use with the signature algorithm. You must use the
// same parameter when you invoke the method sign on the token. The default value is
// SHA256
parameters.setDigestAlgorithm(DigestAlgorithm.SHA256);
// We set the signing certificate
parameters.setSigningCertificate(privateKey.getCertificate());
// We set the certificate chain
parameters.setCertificateChain(privateKey.getCertificateChain());
// Create common certificate verifier
CommonCertificateVerifier commonCertificateVerifier = new CommonCertificateVerifier();
// Create PAdES xadesService for signature
CAdESService service = new CAdESService(commonCertificateVerifier);
// Get the SignedInfo segment that need to be signed.
ToBeSigned dataToSign = service.getDataToSign(toSignDocument, parameters);
// This function obtains the signature value for signed information using the
// private key and specified algorithm
DigestAlgorithm digestAlgorithm = parameters.getDigestAlgorithm();
SignatureValue signatureValue = signingToken.sign(dataToSign, digestAlgorithm, privateKey);
// We invoke the cadesService to sign the document with the signature value obtained in
// the previous step.
DSSDocument signedDocument = service.signDocument(toSignDocument, parameters, signatureValue);
LOG.info("Signed PDF size = " + signedDocument.getBytes().length);
//We use the DSSUtils to Save to file
DSSUtils.saveToFile(signedDocument.openStream(), "target/signedPdfCadesBDetached.pdf");
} catch (Exception e) {
LOG.error(e.getMessage(), e);
}
}
The corresponding method for signing with PAdES is similar to the above, adjusted to PAdES (that is, we there used PAdESSignatureParameters, SignatureLevel.PAdES_BASELINE_B and PAdESService) classes.
Please note that the SD-DSS project is not hosted in the Maven Central repository, so we had to make an explicit reference to it:
<repositories>
<repository>
<id>europa</id>
<url>https://joinup.ec.europa.eu/nexus/content/groups/public/</url>
</repository>
</repositories>
In addition, I believe we included all of the required/corresponding dependencies in our pom.xml:
<dependency>
<groupId>eu.europa.ec.joinup.sd-dss</groupId>
<artifactId>dss-token</artifactId>
<version>4.6.RC1</version>
</dependency>
<dependency>
<groupId>eu.europa.ec.joinup.sd-dss</groupId>
<artifactId>dss-pades</artifactId>
<version>4.6.RC1</version>
</dependency>
<dependency>
<groupId>eu.europa.ec.joinup.sd-dss</groupId>
<artifactId>dss-cades</artifactId>
<version>4.6.RC1</version>
</dependency>
<dependency>
<groupId>eu.europa.ec.joinup.sd-dss</groupId>
<artifactId>dss-document</artifactId>
<version>4.6.RC1</version>
</dependency>
Prior to this, we also gave a try to PDFBox, but the documentation wasn't so helpful, according to what we want to accomplish.
Any idea what is wrong here? Changing the packaging ENVELOPING makes no difference either. Is the method for signing with CAdES so different that the PAdES example should not be used as a guide?
In general,
PAdES signatures are specifically profiled signatures embedded into a PDF. Thus, your PAdES signed PDF can be opened in Adobe Reader, and Adobe Reader can recognize the signature, verify it, and display the result of that in its signature panel.
CAdES signatures are specifically profiled signatures which either are in a separate file or which contain the signed data. Neither of these formats is recognized by Adobe Reader, in case of the separate file you can open the original PDF but the Reader does not see the signature, in case of the contained PDF the Reader either cannot open the file at all or (as the Reader ignores some leading and trailing extra bytes) considers the signature ignorable trash.
You only need a PDF aware library (like PDFBox) for PAdES signatures, for CAdES signatures the PDF is treated like generic data bytes.
In your case, therefore, i.e. for
SignatureLevel.CAdES_BASELINE
SignaturePackaging.DETACHED
your 7K indeed is the mere signature in a separate file and you have to keep or forward both the PDF and the signature, the PDF for viewing and the signature for verification.
Thus,
Specifically the generated PDF document has a size of only 7k instead of the expected 2.5MB ...
We assume the 7k is actually only the signature so that the actual document is not included.
Your assumption is correct, and also the behavior is correct. Yout expectations are the issue.
Some confusion might result from the facts that the signature container embedded into a PDF in case of a PAdES signature, when extracted, proves to be in CAdES format, that the matching PDF subfilter is called ETSI.CAdES.detached, and that (at least in the most recent draft at hand) the PDF 2.0 specification will treat the PAdES signatures in a section titled "12.8.3.4 CAdES signatures as used in PDF (PDF 2.0)".
Nonetheless, if you are talking about PAdES signatures, you are talking about ETSI AdES signatures integrated in PDFs. If you are talking about CAdES signatures, you are talking about ETSI AdES CMS signatures independant of a specific document format which may be detached from the signed data or which may wrap them.
According to your comments, in particular this one
Signing the PDF using ETSI.CAdES.DETACHED filter is the exact requirement
you in the end do not want to create a CAdES signature but instead a PAdES signature, more exactly you want to do so according to the Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles and not according to Part 2: PAdES Basic - Profile based on ISO 32000-1 which uses the subfilters adbe.pkcs7.detached and adbe.pkcs7.sha1.
(To get the requirement straight, that is the subfilter value, not the filter value.)
This is exactly what the dss cookbook examples SignPdfPadesB, SignPdfPadesBDetached, and SignPdfPadesBVisible should be all about:
they all in their JavaDoc class comment claim to show How to sign PDF Document with PAdES-BASELINE-B,
the cookbook asciidoc/dss-documentation.adoc for PAdES Baseline profiles refers to ETSI TS 103 172,
and that standard specifies:
6 Requirements for B-Level Conformance
This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil.
The current clause specifies compliance requirements for short-term electronic signatures. This clause actually profiles
PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures
that do incorporate signature-policy-identifier) signatures.
(ETSI TS 103 172 V2.1.1 (2012-03))
Unfortunately I cannot now verify that the samples do what they claim as my eclipse dss projects are all red with problems.
If they do, though, it looks like you in the beginning already had what you wanted:
Following the example from SignPdfPadesBDetached.java, we have succesfully signed a PDF document using PAdES.
You may share a sample PDF signed with that example for analysis to be sure.
I have a servlet and the content type of my request is of type : application-pkcs-7
And how do i decode the request ?
Any ideas ?
I learnt that i can use openssl to decode , but not much docs on that .
That's probably a signature or an encrypted piece of data. It's old name is PKCS-7 (of RSA labs, publicly available standard) but it is also known as CMS (Cryptographic Message Syntax, publicly available RFC). CMS is a container format for different kinds of encryption. You can parse it in Java using the open source Bouncy Castle libraries - "bcmail" in particular, but you probably need some kind of key if it is encrypted. If it is signed, you could simply parse the plain text data from it and ignore the signature, I guess, depends on the application really.
[UPDATE] Since 1.47 the necessary functionality is in the PKIX library of Bouncy Castle.
Should work in this way
CMSSignedData cmsSignedData = new CMSSignedData(byte[] signedData);
CMSProcessable cmsProcessable = cmsSignedData.getSignedContent();
In my case it didn't though, because of unknown tag entry while parsing data