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.

Sign up for GitHub

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

Jump to bottom

Discuss signing key expiry #87

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+29 −0
Open

Discuss signing key expiry #87

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions key-revocation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,35 @@ Cons:
* Keys can't be revoked before expiration
* Artifacts must be re-signed after expiration, unless a timestamping service is used.

### Approaches

Developers can have keys with different expiry times.

Expiry time more than or equal to 1 year is generally considered as **long term**, and expiry time less than or equal to 1 day is generally considered as **short term**. Other expiry time ranges falls in to long term or short term depending on various scenarios.

In some scenarios, the developers can use self-signed certificates or even deploy using the public key directly without a third party. When the public key is directly used, it means life-time validity.

#### Long Term

Longer expiry can make the private key exposed for a longer time, which implies larger blast radius. In other words, more artifacts are impacted when a key with longer key duration is rescinded.

Long term keys are generally associated with roots, used infrequently, kept offline when not in use, and need additional protections (e.g. [HSMs](https://en.wikipedia.org/wiki/Hardware_security_module)) against compromise. Thus long term keys SHOULD not be used as signing keys.

#### Short Term

Since the key has short expiry that expires in days or even in minutes, the signer has to generate the key pair and get the public key certified more often by a issuing CA. This requires a robust and secure signing infrastructure that is online and can issue certificates at a higher frequency. Community developers can choose a common trusted public CA to authenticate themselves and certify their short-term ephemeral keys.

* As the key expiry is shorter, timestamping MUST be used where the artifact is expected to be consumed beyond the key expiry.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically key expiry is used to limit how long a signed artifact would be considered valid before requiring it to be resigned. One advantage of this is the CA signing the key's certificate can choose how long to trust that key which gives an upper limit on how long a breached key's signed artifacts may be encountered in the wild. If we allow a TSA to arbitrarily extend that limit, that removes the control the CA has on how long signed artifacts from that key are trusted.

This is trading off the fixed trust on both the key and artifact, for a short trust on the key and a potentially unlimited trust on the artifacts that short term key signs. I personally won't want to trust a TSA extended artifact unless there's some assurance the organization issuing the original signing key has some control on the max lifetime of those signed artifacts.

* Lowers risks of signing key compromise due to lower blast radius, when used along with timestamping.
* Key storage can be simpler as compromised keys have limited blast radius and does not need to be protected for longer periods.
Copy link
Contributor

@priteshbandi priteshbandi Aug 9, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless all artifacts signed by the key are not timestamped or If the artifact are timestamped, all Deployers are validating timestamp with configured trusted TSAs, the compromise of short term key can have high blast radius as malicious actor can backdate the signing time and select a local TSA to sign the artifact. Thus they needs to be protected all the time(until deleted).


### Recommendation

* Publishers should decide whether long term or short term keys are suitable for their use case based on their internal threat assessment.
* Timestamping SHOULD be used for both long term and short term keys for added protection against compromised keys.
* When artifacts are consumed beyond signing key expiry (more common for short term keys), timestamping MUST be used.
* Deployer MUST be able to specify whether timestamp signature is required, and if expired signatures are allowed.


## Key revocation lists (Deny lists)

Expand Down