Skip to content

set default timestampping service to digicert instead of freetsa - #7

Open
ikreymer wants to merge 2 commits into
mainfrom
set-default-ts-service-to-digicert
Open

set default timestampping service to digicert instead of freetsa#7
ikreymer wants to merge 2 commits into
mainfrom
set-default-ts-service-to-digicert

Conversation

@ikreymer

Copy link
Copy Markdown
Member

@makew0rld makew0rld left a comment

Copy link
Copy Markdown

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
Copy Markdown
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
Copy Markdown

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
Copy Markdown

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