Cannot verify TSR returned without using -untrusted

[Nicholas Amorim]

First of all: thanks for this project, @trbs.

Here's my problem, which to be honest I'm not even sure if it's related to this library.

I need to be able to verify the signatures using OpenSSL. However, I can't verify the tsr that I save using the library without using -unstrusted.

But if I manually create the tsq and sign it using curl I can verify it without using -untrusted. Why is that?

$ openssl ts -query -data data.json -no_nonce -sha256 -cert -out file.tsq
$ curl -H "Content-Type: application/timestamp-query" --data-binary '@file.tsq' http://localhost:2020 > file.tsr
$ openssl ts -verify -in file.tsr -queryfile file.tsq -CAfile bundle.pem
VERIFICATION: OK

This works just fine. But if I perform the request through this library:

with open('cert1.tsr', 'wb') as f:
    f.write(encoder.encode(tsr))

Then it only works if the verify command has -untrusted:

$ openssl ts -verify -data data.json -in cert1.tsr -CAfile bundle.pem -untrusted cert.pem
VERIFICATION:OK

If I don't pass untrusted, this is what happens:

4803200620:error:21FFF080:PKCS7 routines:func(4095):signer certificate not found:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/crypto/pkcs7/pk7_smime.c:470:

The tsq used in both cases is the same generated with openssl ts -query -data data.json -no_nonce -sha256 -cert -out file.tsq

The size of the tsr is very different as well when using curl and when using the library: curl's tsr has 6k and the library's tsr has 709 bytes.

My TSA is uts-server, if that matters.

Am I doing something wrong?

[Nicholas Amorim]

I've actually figured this out.

The only thing I could think of is that when using openssl the -cert option is used, thus changing the output as it includes the certificate. But I didn't know that the timestamper class accepted such parameter, digging into the code I found it: include_tsa_certificate.

After setting this to true, it work as expected!

Again, thanks for this amazing library!

[trbs]

Great, happy that the library is helpful for you.

(Most credits go to the original authors :-) )

Also happy to merge PR's if there is anything you can add to make this easier / more useful or more documented.

[Nicholas Amorim]

@trbs I actually have a fork with Tornado support (and plan to test/add AioHttp support).

I'd love to merge it here, but the changes are a bit fundamental, if you know what I mean. Hard to avoid async-creep if not using threads.

If you're interested, you could look at my changes and propose a course of action.

https://github.com/nicholasamorim/rfc3161ng_async

[trbs]

@nicholasamorim sorry for the way to long overdue reply.

It would be awesome to merge your changes into rfc3161ng, but restricting the package to 3.7+ is giving me mixed feelings ;-)

Guessing the even more ideal solution would be to merge everything back into the rfc3161 package since it's also a bit of a shame that we now get a bunch of different packages doing the same thing in different stages of activeness...