Timestamping enricher manually verify

[djhmateer]

I used the timestamping_enricher with http://timestamp.digicert.com successfully on a file with a single image.

Then I tried to manually verify the response

openssl ts -reply -in e32e6e537c8f4e3c84488748 -text

# errors
Using configuration from /usr/lib/ssl/openssl.cnf
40A749A3FC7E0000:error:068000A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1188:
40A749A3FC7E0000:error:0688010A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:349:Type=TS_STATUS_INFO
40A749A3FC7E0000:error:0688010A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:685:Field=status_info, Type=TS_RESP
dave@DESKTOP-3GDSG0D:/mnt/e/Backups/DigitalOcean/testhashing/dia018c$

All looks good with the files produced

• .txt file contains the same hash value as the single jpg
• 3 crt files that make up the chain
• e32e6e537c8f4e3c84488748 file (the timestamp response)

Could be all manner of things (filesystem endings - am using WSL2)... just wondering if anything obvious!

[pjrobertson]

It's possible that this is an issue with the digicert server, it's known to return invalid (not RFC 3161 compliant) responses (more info)

If you try switching to one of the servers listed here with a green tick, does it work?

We are working on a rewrite of the timestamping enricher, also see #186

[djhmateer]

Thank you Patrick. This isn't important for me (am just experimenting).. but perhaps for @msramalho?

I gave it another shot with http://timestamp.identrust.com with similar results.

I noticed I can parse the file fine.

# prse the file works
openssl asn1parse -inform DER -in 5f73a60bb02944e48b6c88aa

# view certs works
openssl pkcs7 -inform DER -in 5f73a60bb02944e48b6c88aa -text -print_certs

# verifying doesn't
openssl ts -verify \
    -data 9643583e12ed4428992dd84f.txt \
    -in 5f73a60bb02944e48b6c88aa \
    -CAfile 9474f1e70d304ebeb780cfdb.crt \
    -untrusted d472eee1ed6f48d5a395c383.crt \
    -untrusted c3a350b3a08c497fbdc9dbf2.crt

According the ChatGPT below.:

That error appears because openssl ts -reply expects an RFC 3161 “TimeStampResp” structure (TS_RESP) at the top level, whereas the file you have is a PKCS #7 “signedData” time-stamp token. Although both formats contain TST information, they’re not identical wrappers.

openssl ts -reply wants a TS response (TSResp), which starts with a PKIStatusInfo (the “status_info”) and may include the full time-stamp token as a separate field.
Your file, however, is simply the PKCS #7 “signedData” object holding the TST (Time-Stamp Token). It does not include the TSResp’s outer structure with the status block.
Hence openssl ts -reply throws an error looking for the TSResp’s “status_info” element (which isn’t there) and fails with “wrong tag.”

If your goal is just to examine the token contents, you can do so with:

openssl asn1parse -inform DER -in 5f73a60bb02944e48b6c88aa

or:

openssl pkcs7 -inform DER -in 5f73a60bb02944e48b6c88aa -text -print_certs

If you want to verify this time-stamp token against an original request and trusted certificates, you’d typically use the openssl ts -verify command, but you must supply the original time-stamp request and the correct trust chain.