Can rfc3161ng be used to validate timestamp generated by openssl ts?

[petterreinholdtsen]

Hi,

Thank you very much for documenting how to save timestamps that can be validated by openssl ts. I wonder, is it possible to use this library to go the other way, ie validate timestamps generated by openssl ts? I've tried decoding them using pyasn1.codec.der.decoder.decode(), but check() refuses the resulting stamp. :(

[petterreinholdtsen]

Here is an example to show what I try to do:

#!/usr/bin/python3

import pyasn1.codec.der
import rfc3161ng

class Test(object):
    def get_stamper(self):
        certificate_data = self.fetch('https://freetsa.org/files/tsa.crt')
        #ca_data = self.fetch('https://freetsa.org/files/cacert.pem')
        
        return rfc3161ng.RemoteTimestamper('http://freetsa.org/tsr',
                                           certificate=certificate_data)


    def fetch(self, url):
        import urllib.request
        response = urllib.request.urlopen(url)
        return response.read()


    def runtest(self):
        timestamper = self.get_stamper()
        data = b"Hello world"
        
        tsr = timestamper(data=data, return_tsr=True)
        stamp = pyasn1.codec.der.encoder.encode(tsr)
        # stamp content can be written and checked by openssl ts

        # Trying to check it myself
        tsr2 = pyasn1.codec.der.decoder.decode(stamp)
        if tsr != tsr2:
            print("back and forth did not gave the same result")
        res = timestamper.check(tsr, data=data)
        print("Check returned", res)

if '__main__' == __name__:
    t = Test()
    t.runtest()

[petterreinholdtsen]

Is this a hard problem? I would be happy to help test different approaches, if I had any idea how to move forward.

[trbs]

@petterreinholdtsen sorry for the late reply. I'm busy with other projects at the moment. So I'm afraid rfc3161ng is getting a bit rusty as well. I was hoping development of rfc3161 would pick up and rfc3161ng could be merged back upstream.

I'm sorry that this does not really helps you in any way...

[bdauvergne]

I'm interested in merging rfc3161ng upstream, did you ever contact me before for this (just discovered your fork today, someone asked me for help on it) and I forgot ? I will certainly move the repository to github.

[trbs]

@bdauvergne not sure, it's been a long time ;-)

More then happy to help merging it back upstream and deprecating rfc3161ng since it's going stale as well.

[bdauvergne]

I think I have no more time than you to work on it, but at least there will only be one reference on pypi and people will not have to choose (It's possible that I'll take the time next year to try to move from pyasn1 dependency to asn1crypto which already implement TSP ASN.1 grammars).

[petterreinholdtsen]

Any chance for you two to pick up the pieces and try to merge the code base into one great library?

[trbs]

I see there have been no commits in https://dev.entrouvert.org/projects/python-rfc3161/repository

How does it sound if we do:

• Add @bdauvergne as maintainer here
• We pick one name to make stick; I would vote for python-rfc3161 without the ng. (Then please make me co-owner in pypi if we keep doing manual releases or maintainer if we can fully automate releases in github actions)
• We can keep using my github.com/trbs but also more than happy that we move the project under github.com/rtc3161/python-rtfc3161/

[petterreinholdtsen]

[trbs]

How does it sound if we do:

Any activity and consolidation sound good to me, but I am not the one doing the work, so I guess I do not have a say here. :)

-- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

Any news with consolidating the two implementations? Will the new edition be backwards compatible with both?

I would be happy to upload a updated version to Debian.

Happy hacking Petter Reinholdtsen