trbs / rfc3161ng

A simple client library for cryptographic timestamping service implementing the protocol from RFC3161. Based on python-rfc3161 with some additional fixes.
Other
40 stars 20 forks source link

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

Open petterreinholdtsen opened 5 years ago

petterreinholdtsen commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

trbs commented 5 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 5 months ago

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

trbs commented 5 months ago

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

How does it sound if we do:

petterreinholdtsen commented 5 months ago

[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 commented 4 months ago

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