You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A timestamping authority (TSA) like the one defined in the RFC-3161 protocol works as a trusted third-party providing a "proof-of-existence" that the data existed at a particular moment in time. 1
TSA servers must sign each timestamp message using a public key infrastructure reserved specifically for that purpose. Once the client receives the signed response it uses the TSA server’s root public key to verify the signature. The client verifies that the timestamp response comes from the expected party, covers the provided data and has an up-to-date time.
I'm curious if there is any use-case to implement TSA2 client in Dex to verify signed timestamps. I've surfed the source code a bit and notice Dex mostly rely on time.Now for generating oidc, oauth2 tokens. For example, verifying expirations of the certificates that were created at a certain time.
Ref: A TSA server implementation called timestamp-authority from project sigstore.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm curious if there is any use-case to implement TSA2 client in Dex to verify signed timestamps. I've surfed the source code a bit and notice Dex mostly rely on
time.Now
for generating oidc, oauth2 tokens. For example, verifying expirations of the certificates that were created at a certain time.Footnotes
https://www.chainguard.dev/unchained/how-to-sign-private-artifacts-securely ↩
https://datatracker.ietf.org/doc/html/rfc3161 ↩
Beta Was this translation helpful? Give feedback.
All reactions