-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
set default timestampping service to digicert instead of freetsa #7
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently ts-digicert.pem
contains TSACertificate.cer
, which is the last step in the certificate chain that gets rotated (at least) every 15 months. To me this is analogous to the domain certificate of a website.
I don't think that's the way you are supposed to set up your trust chain. Maybe I misunderstand how this is being used by authsign, but the way I would set this up is to use DigiCertTrustedG4RSA4096SHA256TimeStampingCA.cer
to verify, since that is the CA in this case. You can even use the system/browser CA store to verify if you really want to, since DigiCertTrustedG4RSA4096SHA256TimeStampingCA.cer
is signed by DigiCertTrustedRootG4.cer
.
I think TSACertificate.cer
is an runtime detail and should just be verified in the chain instead of stored, in the same way browsers don't try and have a trust list for the domain cert of every single website.
The TSA certificate is used by the RemoteTimestamper to verify the signature immediately after it's received: In this case, having |
I think my recommendation would be to take the cert chain sent by DigiCert as part of the signature, and just verify all of that against the unchanging CA cert, As for returning it to the user, I definitely agree that |
Note that in any case, currently the full cert chain is not stored in this PR, and so no one will be able to verify things. No matter how this gets implemented, users will need at least two certs, not the one currently stored. Similar to |
add digicert ts cert chain (from: https://knowledge.digicert.com/general-information/rfc3161-compliant-time-stamp-authority-server)