I'm using the following code for creating the hash of a pdf document which eventually is signed by a dedicated HSM. CRL and OCSP parameters are set to null here since they are not yet known. This code is executed in my own IExternalSignatureContainer.Sign implementation.
//Create the hash of the pdf for signing
byte[] sh = pkcs7Signature.GetAuthenticatedAttributeBytes(hash, null, null, PdfSigner.CryptoStandard.CMS);
using (SHA256 sha256 = SHA256.Create())
{
sh = sha256.ComputeHash(sh);
}
// >> Call HSM for creating the signature
The HSM then returns the signature, CRL and OCSP(This means i don't have access to the CRL before). Once the signature is created, i produce the PKCS7 container which in addition to the signature also contains a CRL.
pkcs7Signature.SetExternalDigest(signature, null, "RSA");
return pkcs7Signature.GetEncodedPKCS7(hash, null, null, crl, PdfSigner.CryptoStandard.CMS);
In this case, the resulting signature in the pdf is not valid. I did some testing and when i add the CRL to the GetAuthenticatedAttributeBytes, everything works.
My problem is that i don't have the CRL at that point in time.
Question: Is it possible to create the hash without a CRL and then apply the CRL on the created PKCS7 container and keeping the signature valid in the pdf?
Question: Is it possible to create the hash without a CRL and then apply the CRL on the created PKCS7 container and keeping the signature valid in the pdf?
No. At least not in a useful manner. Depending on the exact signing profile followed, though, you can afterwards append the CRL in an incremental update to the signed PDF instead.
In detail:
In plain ISO 32000-1 interoperable signatures revocation information (CRLs and OCSP responses) are added in a specific, Adobe-defined, signed attribute (aka authenticated attribute), see ISO 32000-1 section 12.8.3.3.2 Revocation Information.
A signed attribute is part of signed content, so by calculating the hash without it but later including it in the finished signature container, you get an invalid signature.
Of course one could consider adding the CRL to the CMS signature container where by CMS specification CRLs would be expected. This is an unsigned part of the container, so one can add CRLs without influence on the signature validity.
But as by PDF specification the revocation information in CMS containers embedded in PDFs are expected elsewhere, signature validators shouldn't use such CRLs, and in particular Adobe Reader doesn't.
The discussion above focused on the embedding of revocation information in PDFs according to plain ISO 32000-1.
If you can create signatures according to ISO 32000-1 plus ESIC extension level 2 or ADBE extension level 8, or according to ISO 32000-2, there is another option: You can add validation related information (like CRLs) in an incremental update of the signed PDF in a PAdES Document Security Store DSS structure.