Signing with OCSP by using iText

问题

I can sign a pdf document without problem. My app logic is; 1- create an empty field for signature in pdf 2- send the hash code of the field to the signature webservice 3- get signature object 4- embedded this object into the field.

Here is my code Signature is Invalid for PDF File with iText
Thank to @mlk, helped me regarding it.

But I i realize that I have problem with Revocation.

As can bee seen in the image, my signature does not contain OCSP. and in the trust section, 'Certify documents' option is failed (red cross)

The response of the webservice already contains crl and ocsp

<sc:RevocationInformation>
 <sc:CRLs>
  <sc:CRL> .... CRL .... </sc:CRL>
 </sc:CRLs>
 <sc:OCSPs>
  <sc:OCSP> ..... ocsp content..... </sc:OCSP>
 </sc:OCSPs>
</sc:RevocationInformation>

But I only use signature object.

My question is that how I can embed CRL and OCSP into the pdf.

As I see some examples, SignDetached method has been used instead of SignDeferred method. If I have to use also SignDetached method then should I create a field in the pdf file. Because I will need this field's hash code. How the process works.

Edit: When I open my test pdf file and a pdf which has been signed by swisscom, I see this windows.

For swisscom

And this is my test pdf

As can bee seen, there is a difference regarding validation.. So I click the signatue field and validate so I got this window.

This is the same to swisscom original signed file. but I need to do extra 'validate'. What is missing in my signature that I need to validate?

Edit 2:

Signed by Swisscom http://documents.swisscom.com/product/1000255-Digital_Signing_Service/Documents/Reference_Guide/Reference_Guide-All-in-Signing-Service-en.pdf

and my signed test file

https://app.box.com/s/ju7xgkxucw0rwif7k3052rx5n8f9omwq

回答1:

There actually are two separate aspects to your question, on one hand you want to know why the two documents (the one you created and the one the Swisscom provided) behave differently in your Adobe Reader, and on the other hand you ask how to embed CRL and OCSP into the pdf.

Differences between the signed documents

A matter of Adobe Reader versions

First of all, the different Adobe Reader behavior you observed for the two documents only occurs on old Adobe Reader versions, both your files in Adobe Reader DC are validated immediately with green ticks.

So, not only does the Reader not behave differently anymore, the signatures now out of the box are considered valid! The trust anchor is obtained from the Adobe Approved Trust List.

Furthermore, you can see that both signatures are considered "LTV-enabled". Thus, all information required for validation by Adobe Reader, in particular revocation information (CRLs and OCSP responses), are included.

Different signature Filter values

The major difference between the two signatures is the Filter of the PDF signature,

• 5.PDF_1_.pdf has a signature Filter value ETSI.RFC3161 and
• Reference_Guide-All-in-Signing-Service-en.pdf has a signature Filter value Adobe.PPKLite.

The Filter value ETSI.RFC3161 in the file you signed does not make sense: This value is a reserved SubFilter value for document time stamps! The Filter value Adobe.PPKLite in the file signed by SwissCom is indeed a filter name, it's the name of the Adobe signature handler.

According to the PDF specifications ISO 32000-1 and ISO 32000-2:

The name of the preferred signature handler to use when validating this signature. If the Prop_Build entry is not present, it shall be also the name of the signature handler that was used to create the signature. If Prop_Build is present, it may be used to determine the name of the handler that created the signature (which is typically the same as Filter but is not needed to be). A conforming reader may substitute a different handler when verifying the signature, as long as it supports the specified SubFilter format. Example signature handlers are Adobe.PPKLite, Entrust.PPKEF, CICI.SignIt, and VeriSign.PPKVS.

The meaning of the Filter value has diminished over time. Earlier Adobe Reader versions (and also versions of other signature validators) only handled signatures with certain Filter values automatically while nowadays the Filter value is essentially ignored.

Thus, the Adobe Reader version with which you observed that differing behavior must be an older version which still only handles signatures with known filters immediately and such with unknown filters only on demand.

You reference this question for your source code which in particular contains

IExternalSignatureContainer external = new ExternalBlankSignatureContainer(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);
PdfSignature external2 = new PdfSignature(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);//ADBE_PKCS7_SHA1);
//as pdf name I tried also PdfName.ETSI_RFC3161

Apparently you created your signature using the code from an attempt for which you tried also PdfName.ETSI_RFC3161...

Embedding CRL and OCSP into the pdf

This question in your context actually has become a moot point as your signature is recognized as LTV enabled, i.e. in particular as including all revocation information (CRLs, OCSP responses) required by the signature validator of Adobe Reader. Thus, I'll cover it only in general terms.

There essentially are two places to put revocation information in PDFs:

• a special, Adobe defined attribute in the signature container or
• a special, ETSI defined dictionary in a later incremental update.

The adbe Revocation Information attribute

The attribute in question is already specified in the PDF specification ISO 32000-1:

The PKCS#7 object should contain the following:

[...]

• Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature.

[...]

The adbe Revocation Information attribute:

adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
                              { adbe(1.2.840.113583) acrobat(1) security(1) 8 }

The value of the revocation information attribute can include any of the following data types:

• Certificate Revocation Lists (CRLs), described in RFC 3280 (see the Bibliography): CRLs are generally large and therefore should not be embedded in the PKCS#7 object.

• Online Certificate Status Protocol (OCSP) Responses, described in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP (see the Bibliography): These are generally small and constant in size and should be the data type included in the PKCS#7 object.

• Custom revocation information: The format is not prescribed by this specification, other than that it be encoded as an OCTET STRING. The application should be able to determine the type of data contained within the OCTET STRING by looking at the associated OBJECT IDENTIFIER.

adbe's Revocation Information attribute value has ASN.1 type RevocationInfoArchival:

   RevocationInfoArchival ::= SEQUENCE {
     crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL
     ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL
     otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL
   }
   OtherRevInfo ::= SEQUENCE {
     Type OBJECT IDENTIFIER
     Value OCTET STRING
   }

This way of embedding has been known even before the first ISO PDF specification ISO 32000-1 and, therefore, should be usable for most validators. The drawback is that this attribute is signed, so the information have to be retrieved early. This might not always be possible.

By the way, this also is how these information are embedded in your document, SwissCom embeds this attribute into the signature container for you.

The ETSI Document Security Store (DSS) dictionary

This dictionary and its handling is specified by ETSI, e.g. in ETSI EN 319 142-1, and has been copied into the PDF specification update ISO 32000-2:

The Document Security Store (DSS) shall be a dictionary that shall have the value DSS as key in the document catalog dictionary. This dictionary is used to provide a single place where all of the validation-related information for some or all signatures in the document should be placed.

The DSS dictionary, if present, shall contain validation-related information only for document and time-stamps signatures represented in PKCS#7 and CMS (and its derivatives) format or for XAdES signatures of forms signing dynamic XFA [i.7].

NOTE: See ETSI EN 319 142-2 [i.11] for specification of XAdES signatures of forms signing dynamic XFA.

Entries in a DSS Dictionary

Type Name (Optional) It shall be DSS for a document security store dictionary.

VRI Dictionary (Optional) This dictionary contains Signature VRI dictionaries in the document. The key of each entry in this dictionary is the base-16-encoded (uppercase) SHA1 digest of the signature to which it applies and the value is the Signature VRI dictionary which contains the validation-related information for that signature. (See additional requirements a, b, c.).

Certs Array (Optional) An array of indirect references to streams, each containing one DER-encoded X.509 certificate (that shall be as defined in IETF RFC 5280 [4]). This array contains certificates that can be used in the validation of any signatures in the document.

OCSPs Array (Optional) An array of indirect references to streams, each containing a DER-encoded Online Certificate Status Protocol (OCSP) response (that shall be as defined in IETF RFC 6960 [5]). This array contains OCSPs that can be used in the validation of any signatures in the document.

CRLs Array (Optional) An array of indirect references to streams, each containing a DER-encoded Certificate Revocation List (CRL) (that shall be as defined in IETF RFC 5280 [4]). This array contains CRLs that can be used in the validation of any signatures in the document.

As this way of embedding has not been known in the first ISO PDF specification ISO 32000-1, a number of validators might not know how to handle these information. The advantage is that this dictionary need not be signed, so the information can be retrieved after signing. This might be necessary in some use cases.

来源：https://stackoverflow.com/questions/50101388/signing-with-ocsp-by-using-itext