In short:
Can I create a signed digest without prior notice of any certificate?
In the case of SubFilter ETSI.CAdES.detached or adbe.pkcs7.detached, you can create a document digest without knowing someone's certificate in advance.
However, you generally need to know the Subscriber’s certificate before you begin creating the CMS signature container for insertion into the PDF.
More details:
(Beware, the following is somewhat simplified.)
I can (possibly) generate a digest, reserve a place for writing / Contents, and attach this PKCS # 7 object later.
If you reserve a place first and then generate a digest, this is really how it is done.
The confusion begins when I read the following:
Revocation information is a signed attribute, which means that signature software must capture revocation information before signing. A similar requirement applies to the certificate chain. Signature software must capture and verify the certificate chain before signing.
So, I did not quite understand: it is obvious that the record / content (containing the certificate and the signed digest) is not digested, but the certificate chain is a signed attribute (and therefore should be digested?).
I would be grateful if someone could clarify what exactly is being digested, and perhaps it would be better to explain the attributes signed to me.
The main fact to keep in mind is that in the case of PKCS # 7 / CMS signature signatures, a signature usually includes not only one hash calculation, but at least two!
The first hash, the hash of the document, is really calculated for the entire file, including the signature dictionary, but excluding the signature value itself ( Content entry) (you can read this answer for more details).
But this is not a hash that is immediately used when applying the signature algorithm.
When you create the PKCS # 7 / CMS signature container (if only in its most primitive form), you create a structure called "signed attributes".
You fill this structure with several attributes (pair names), among which is the already computed hash of the document, as well as others, for example. Adobe-style recall information you're reading about.
When you finish creating this structure, you will create this structure and create a signature for it.
You can then collect the PKCS # 7 / CMS signature container using these signed attributes, a signature, and other information not signed by this signature, for example. certificates, signature timestamps, ...
Read more about signature container in this answer .
Finally, you insert this signature container into the reserved space in PDF format.
The main question I want to answer may be: can I create a recognized digest without knowing any certificate in advance? (I work with a separate pkcs7 entry)
In the case of SubFilter ETSI.CAdES.detached or adbe.pkcs7.detached, you can create a document digest without knowing someone's certificate in advance.
However, depending on the CMS signature profile, you usually need to know the subscriber certificate before you start creating the signature container, because many profiles require a signed attribute that refers to the certificate of the signer.
Explanations:
The OP asked some of the following questions in a comment:
1. One of the signed attributes is a document hash (without / content), so if I understand correctly, is this an unsigned hash?
Since the “signed attributes” are finally hashed and signed, this hash hash in it is not immediately signed directly , but it is indirectly signed as part of this attribute structure. Therefore, I would not call it unsigned ...
- In the end, when the user actually creates the signature, he signs the hash of the PKCS # 7 object?
No, the hash of the Signed Attributes structure, which is only part of the PKCS # 7 object, and not all. There are several parts of the PKCS # 7 / CMS object that are unsigned.
- Is there still a PKCS # 7 object in the / Contents record that we can actually read? (To extract certificates, etc. To verify)
The Content entry contains a full-featured PKCS # 7 / CMS signature container object as a binary string. That way, yes, you can read it (by reading the value of this binary string) and (if you have code that knows how to parse such a signature container) extract information from it.
Beware, however, the signature container may not contain all the data needed for verification: for example, if you are testing using a chaining model (not a shell), you may need to extract the signing time from the corresponding PDF signature dictionary entry.
- When verifying the signature, we simply extract the embedded PKCS # 7 object, recalculate the digest, recalculate the digest of the PKCS # 7 object and verify it for signature using the certificate that we get from the PKCS # 7 object?
You also need to calculate the digest of the signed PDF byte ranges and compare this value with the signed attribute containing the original document digest. (Perhaps that meant recounting the digest.)
As mentioned in the answer to 3, you may need to get additional information from the PDF for use in PKCS # 7 validation.
In addition, you confirm that the certificate that we receive from the PKCS # 7 object, remember that there may be several certificates in the PKCS # 7 / CMS signature container. You must find the right one. For this, SignerIdentifier SignerInfo CMS and attributes signed by ESS should be used.
In addition, you must also verify the validity and trust of the subscriber certificate.
- Is there any good documentation about which authenticated attributes exist?
You can start reading