# Notary v2 - Signature Expiry

[Notary Issue #81](https://github.com/notaryproject/notaryproject/issues/81)

###### tags: `notary`

Signatures generally expires when the certificate of the signing key expires, which is not always desirable since the signed data has different timeliness.

In this section, artifact signatures are focused. Thus
- The signed data of the signature is the hash of the artifact.
- The signed data of the certificate is the public key / verification key of the publisher.

General speaking, artifacts have shorter timeline than the public key of the publisher. Furthermore, artifact publishers MAY publish artifacts with different life-cycle. Some artifacts are in preview and have short-term support. Others are generally available (GA) and have long-term support (LTS). Therefore, configurable signature expiry is desirable for individual artifacts.

An added benefit is to defend against [freeze attack](https://doi.org/10.1145/1455770.1455841). Since the signature expires in a short time although the signing key can live longer, verifiers have to obtain the latest signature to verify, which implies that verifies have access to the latest content.

> **Freeze Attack** Similar to a replay attack, a freeze attack works by providing metadata that is not current. However, in a freeze attack, the attacker freezes the information a client sees at the current point in time to prevent the client from seeing updates, rather than providing the client older versions than the client has already seen. As with replay attacks, the attacker’s goal is ultimately to compromise a client who has vulnerable versions of packages installed. A freeze attack may be used to prevent updates in addition to having an installed package be out of date.

### Scenarios

With explicit signature expiry in addition to the key expiry, publishers are able to control the life-cycle of various published artifacts at a fine-grained level.

Artifacts can be categorized into
- Nightly built artifacts
- Preview artifacts
- Instances are `alpine/helm:3.5.0-rc.1`, `python:3.10-rc` ...
- Current artifacts
- Instances are `ubuntu:20.10`, `ubuntu:21.04` ...
- Artifacts with long-term support (LTS)
- Instances are `ubuntu:20.04`, `mcr.microsoft.com/dotnet/sdk:3.1` ...

If the artifact signature expires, it implies that the artifact is no longer supported by the publisher. On reaching the signature expiry, artifact consumers have the following options:

- Find artifacts with valid signatures
- Update to a newer version
- Fallback to an older version
- It is possible since `ubuntu:19.10` reached the end of life on July 17, 2020 but users can still fallback to `ubuntu:18.04` since it is supported till April 2028.
- Ask the publisher for a new signature with extended expiry
- Stop using artifacts and optionally find alternatives
- Re-sign the artifact using consumers own keys with caution
- The resulted signature may not be trusted by others
- Suppress the signature verification (insecure)

Here is an example how signature expiry helps both publishers and deployers stay in a healthy ecosystem.

1. A publisher wants to release an artifact `net-monitor:v1`. Thus it publishes an release candidate `net-monitor:v1-rc` on `2021-04-02T08:00:00Z` with signature expiry on `2021-05-01T00:00:00Z`.
2. A deployer picks up `net-monitor:v1-rc` on `2021-04-10T12:34:56Z`, and verifies its signature regularly. Since the current time `2021-04-10T12:34:56Z` is before the signature expiry `2021-05-01T00:00:00Z`, the signature is valid and the artifact is accepted.
3. The publisher later fixes bugs in `net-monitor:v1-rc`, including security vulnerability fixes, and releases `net-monitor:v1` on `2021-04-15T08:00:00Z` with signature expiry on `2022-05-01T00:00:00Z`.
4. After 1 month, the deployer continues to deploy `net-monitor:v1-rc` on `2021-05-10T12:34:56Z`. Since the current time `2021-05-10T12:34:56Z` is after the signature expiry `2021-05-01T00:00:00Z`, the signature is invalid. Thus the deployment is failed and an alert is sent to the deployer admin.
5. The deployer admin updates the artifact version from `v1-rc` to `v1` either manually or automatically.
6. The deployer picks up `net-monitor:v1` on `2021-05-11T12:34:56Z`, and verifies its signature regularly. Since the current time `2021-05-11T12:34:56Z` is before the signature expiry `2022-05-01T00:00:00Z`, the signature is valid and the artifact is accepted.

Without signature expiry, the deploy may stick with `net-monitor:v1-rc` till the signing key expires, which could be several years later.

1. A publisher wants to release an artifact `net-monitor:v1`. Thus it publishes an release candidate `net-monitor:v1-rc` on `2021-04-02T08:00:00Z`.
2. A deployer picks up `net-monitor:v1-rc` on `2021-04-10T12:34:56Z`, verifies its signature regularly, and accepts the artifact on its validity.
3. The publisher later fixes bugs in `net-monitor:v1-rc`, including security vulnerability fixes, and releases `net-monitor:v1` on `2021-04-15T08:00:00Z`.
4. After 1 month, the deployer continues to deploy `net-monitor:v1-rc` on `2021-05-10T12:34:56Z`. Since the signature for `net-monitor:v1-rc` is still valid, the deployer proceeds without alerts.

At this point, the deployer always uses a version without bug fix. The publisher may not be aware of that `net-monitor:v1-rc` is still in use even after several years. Since using the release candidate `v1-rc` for a long time is harmful to the software ecosystem, all players enter a no-win situation.

### Pros and Cons

Pros:
- Signatures can have shorter expiry time than the signing key
- The life-cycle of the artifacts are fine-controlled by the publishers
- Freeze attack is defended
- Artifact support timeline is indicated by the signature expiry
- The deployers can choose the most suitable version in advance
- Healthier software ecosystem
- Publishers can safely retire older artifact releases

Cons:
- Publishers have to sign the artifact more often

### Requirements and Recommendation

The artifact signature SHOULD have signature expiry. If the signature expiry does not present, it is implied by the key expiry.

An example of the signature expiry for different artifact categories could be:

| Artifact Category | Recommended Expiry |
| ----------------- | ------------------ |
| Nightly built | 1 week |
| Preview | 1 - 3 months |
| Current | 9 - 12 months |
| LTS | 3 years |