opensearch-build: [Question] Upcoming expiration of our current sub public key (expire on 20220511)

Our current sub private key that we use for signing detached signature (.sig), and the sub public key that we attach to website for community to verify, will expire soon. https://opensearch.org/verify-signatures.html

pub   4096R/39D319879310D3FC 2021-05-11
uid                          OpenSearch project <opensearch@amazon.com>
sub   2048R/C2EE2AF6542C03B4 2021-05-11 [expires: 2022-05-11]

pub   rsa4096/39D319879310D3FC 2021-05-11 [SC]
      C5B7498965EFD1C2924BA9D539D319879310D3FC
uid                 [ unknown] OpenSearch project <opensearch@amazon.com>
sub   rsa2048/C2EE2AF6542C03B4 2021-05-11 [S] [expired: 2022-05-11]

Once the key expired we need to do a few things to resolve this. Questions are:

1. Do we still want to add new subkey based on master private key, or do we want to expose the master public key directly. This was the strategy that we used to do in ODFE.
2. Once we add the new pair, do we still want to expire the subkey after a year. Or we can just set the subkey to not expire at all.
3. Once we add the new pair, do we still want to keep a link for the old subkey. If I understand correctly the new subkey can verify both the old/new signatures signed by old/new sub secret key. If not, then we can just override the artifact opensearch.pgp with the new sub public key.
4. Do we still want to use old key (not expired yet but very soon) to sign 2.0.0-rc1, or do we want to create a new subkey now and use that? 1.3.2 after rc1 is even more of a stretch.

Note: Do we also want to just extend the existing key so it wont expire?

Thanks.

---

Options:

1. Extend the existing subkey to be not expired.

• Pros:
  • Straight forward, no need to changes the key and rotate every year
  • All of our current existing standalone artifacts, tar, rpm, etc. are signed with this already
  • We can always revoke the subkey if we know the sub secret key leaked
• Cons:
  • No annual rotation
  • Everything is signed with the same key

2. Get a new pair of subkey from the master, no expiration.

• Pros:
  • No difference as 1
• Cons:
  • Even worse than 1 as we need to announce a new key but never expire anymore

3. Get a new pair of subkey from the master, set it to expire in 1 year.

• Pros:
  • Annual rotation
• Cons:
  • Have to announce to the public every year that we have a new pub key, and have to have documentations recording which artifact is signed with old vs new key
  • Every year we need to rotate the key and the key can expire at undesired time
  • Current signing workflow does not support rotation, everything manual

4. Get a new pair of subkey from the master for every product, or every major release of all products.

• Pros:
  • A lot of keys then less risk of leaking one affecting all artifacts
• Cons:
  • Too many keys to manage and will get very messy
  • Every year we need to rotate all the keys, if set expired in one year, for all products
  • Current signing workflow does not support more than 1 key
  • Need to have very detailed documentation record all the keys and all the products and all the versions, on which product/version/time match which key, and which one has expired or not, etc.

---

• Update 20220428:
  • Huan, Tao, David attend the meeting and our decision is to expire the current subkey for a year. This probably requires upload the updated key to S3 bucket. Not sure if we want to officially announce that we renew the key. We will write an issue to track the signing workflow to support rotation and automation soon. The security guardians think that having the subkey unexpired is not good practice, but we can still keep the expiration period longer than a year.