Time Stamp Tokens (TST) TAC encoding and binding

Supporting RFC3852 and RFC3126 requires optional encoding formats for RFC3161 TST. This relates to how the TAC is stored in the TST and how the TAC is cryptographically bound to the signature.

CertificateChoices1 with ESSCertID/ESSCertIDv2 (compatibility mode)

This is the current implementation. The TAC is encoded in the CHOICE [1] field in the CertificateChoices and the hash of the TAC is stored in the ESSCertID/ESSCertIDv2.

CertificateChoices2 with ESSCertID/ESSCertIDv2 (RFC3369 & 3852)

This option puts the TAC into the CHOICE [2] field in the CertificateChoices and sets the CMS version of the time-stamp token to 4 (because a V2 attribute certificate is present).

Adobe Acrobat time-stamping support rejects CMS V4 as a bad version number. If you are using Adobe Acrobat time-stamping, we recommend continuing to use an older option that is Acrobat-compatible until a fix from Adobe is made available.

Signer Attribute (RFC3126 & ETSI)

This option puts the entire TAC into a signed attribute. In this case, the hash of the TAC is not included in the ESSCertID/ESSCertIDv2 because it would be redundant and RFC3126 requires it not to be present. This option also adds the SigningTime signed attribute (which is redundant but required by the RFC) and the SignaturePolicyId signed attribute. The policy is NULL because a time-stamp token must already include a PolicyID in the TSTInfo.