Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ikreymer
Copy link
Member

Copy link

@makew0rld makew0rld left a 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.

@ikreymer
Copy link
Member Author

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:
https://github.com/webrecorder/authsign/blob/main/authsign/signer.py#L49
While this isn't strictly necessary in the signing phase, we just want to make sure that we do indeed have a valid signature before we return it to the user, otherwise its not very useful. The signing cert (along with the domain cert) is returned as part of the response and stored in the WACZ: https://specs.webrecorder.net/wacz-auth/0.1.0/#domain-ownership-identity-signed-timestamp. I think this is especially important for TSA certs, since there is no clear way to obtain them from a domain, and no CT-equivalent for TSA certs out there. To verify, one needs the timeSignature and the timeSignatureCert and then they can decide to if they trust the cert using their existing trust chain.

In this case, having TSACertificate.cer is critical to being able to verify this later - since we don't know if it might be rotated out in the future, etc..

@makew0rld
Copy link

The TSA certificate is used by the RemoteTimestamper to verify the signature immediately after it's received

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, DigiCertTrustedG4RSA4096SHA256TimeStampingCA.cer. This could even be done just by matching against a fingerprint, and verifying all the sigs in the chain. This seems as effective, but simpler. Up to you of course though.

As for returning it to the user, I definitely agree that TSACertificate.cer and all the other certs in the chain are required (although maybe not the root since the user must already trust that). However, I don't think this means authsign itself needs to store anything. I would think it could just take the cert chain that arrives with DigiCert's response, and return that to the user.

@makew0rld
Copy link

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 authsign/trusted/ts-chain.pem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants