[Bug 2073126] Re: More nuanced public key algorithm revocation

[Julian Andres Klode]

** Description changed:

- (This is uploaded to noble as 2.8.1 per
- https://wiki.ubuntu.com/AptUpdates)
+ (Please see https://wiki.ubuntu.com/AptUpdates for the versioning)
  
  [Impact]
- We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. APT 2.8.0 in noble-proposed would bump the warning to an error, breaking them.
- 
- We also revoked additional ECC curves, which may still be considered
- trusted, so we should not bump them to errors.
+ We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.
  
  Also existing users may have third-party repositories that use 1024-bit
- RSA keys and we have not adequately informed them yet perhaps.
+ RSA keys and we have not adequately informed them yet perhaps. We tried
+ to revoke them in the 2.8.0, 2.8.1, and 2.8.2 updates (see bug 2060721).
+ This has been deferred to a later update than 2.8.3 such that we can
+ solve the warnings and other bugs.
  
  [Solution]
  Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
  
-     ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
+     ">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
  
  At the same time we will also introduce a more nuanced approach to
  revocations by introducing a 'next' level that issues a warning if the
  key is not allowed in it and a 'future' level that will issue an audit
  message with the --audit option.
  
  For the next level, we will set it to:
  
      ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"
  
  This means we restrict warnings to Brainpool curves and the secp256k1
  key, which we have not received any feedback about them being used yet.
  
  For the future level, we will take a strong approach to best practices
  as it is only seen when explictly running with --audit and the intention
  is to highlight best practices. It will be set to
  
      ">=rsa3072,ed25519,ed448";
  
  Which corresponds to the NIST recommendations for 2031 (and as little
  curves as possible).
- 
- We are also introducing a mitigation for existing 24.04 systems to not
- upgrade the policy yet; by creating an apt.conf.d configuration file
- that temporarily allows the 1024-bit RSA keys if upgraded from apt
- 2.7.x; with the plan to remove them in 24.04.2.
  
  [Test plan]
  Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.
  
  The manual test cases are the same as for LP: #2060721.
  
  Test Case A: Existing noble system (warning)
  
  0. Update an existing noble container to the new APT
  1. Observe/etc/apt/apt.conf.d/00-temporary-rsa1024 being created
  2. Add a PPA with an old 1024-bit signing key
  3. Run apt update
  4. Observe that the PPA is updated with a warning
  
  Test Case B: New noble system (error)
  
  0. Bootstrap a new noble system including apt from proposed (using e.g. mmdebstrap)
  1. Observe NO /etc/apt/apt.conf.d/00-temporary-rsa1024
  2. Add a PPA with an old 1024-bit signing key
  3. Run apt update
  4. Observe that the PPA is not updated, but the other repositories are
  
  Test Case C: mantic -> noble (error)
  
  0. Upgrade mantic to noble w/ apt from proposed, observe behavior as in
  B
  
  Test Case D: jammy -> noble (error)
  
  0. Upgrade jammy to noble w/ apt from proposed, observe behavior as in B
  
  [Where problems could occur]
  There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.
  
  There cannot be any false positives: The new levels are only
  *additional* checks, anything not in the `Assert-Pubkey-Algo` list is
  still revoked.

** Description changed:

  (Please see https://wiki.ubuntu.com/AptUpdates for the versioning)
  
  [Impact]
  We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.
  
  Also existing users may have third-party repositories that use 1024-bit
  RSA keys and we have not adequately informed them yet perhaps. We tried
  to revoke them in the 2.8.0, 2.8.1, and 2.8.2 updates (see bug 2060721).
  This has been deferred to a later update than 2.8.3 such that we can
  solve the warnings and other bugs.
  
  [Solution]
  Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
  
      ">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
  
  At the same time we will also introduce a more nuanced approach to
  revocations by introducing a 'next' level that issues a warning if the
  key is not allowed in it and a 'future' level that will issue an audit
  message with the --audit option.
  
  For the next level, we will set it to:
  
      ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"
  
  This means we restrict warnings to Brainpool curves and the secp256k1
  key, which we have not received any feedback about them being used yet.
  
  For the future level, we will take a strong approach to best practices
  as it is only seen when explictly running with --audit and the intention
  is to highlight best practices. It will be set to
  
      ">=rsa3072,ed25519,ed448";
  
  Which corresponds to the NIST recommendations for 2031 (and as little
  curves as possible).
  
  [Test plan]
  Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.
  
- The manual test cases are the same as for LP: #2060721.
+ Some smoke tests:
  
- Test Case A: Existing noble system (warning)
- 
- 0. Update an existing noble container to the new APT
- 1. Observe/etc/apt/apt.conf.d/00-temporary-rsa1024 being created
- 2. Add a PPA with an old 1024-bit signing key
- 3. Run apt update
- 4. Observe that the PPA is updated with a warning
- 
- Test Case B: New noble system (error)
- 
- 0. Bootstrap a new noble system including apt from proposed (using e.g. mmdebstrap)
- 1. Observe NO /etc/apt/apt.conf.d/00-temporary-rsa1024
- 2. Add a PPA with an old 1024-bit signing key
- 3. Run apt update
- 4. Observe that the PPA is not updated, but the other repositories are
- 
- Test Case C: mantic -> noble (error)
- 
- 0. Upgrade mantic to noble w/ apt from proposed, observe behavior as in
- B
- 
- Test Case D: jammy -> noble (error)
- 
- 0. Upgrade jammy to noble w/ apt from proposed, observe behavior as in B
+ - Observe one a system with a 1024R signed repository that it keeps working and produces a warning (ensures a key listed in "next" but not in "current" warns)
+ - Sign a repository with a NIST P-256 key and ensure it does not produce warnings (ensures that a key listed in "current" and "next" does not warn)
  
  [Where problems could occur]
  There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.
  
  There cannot be any false positives: The new levels are only
  *additional* checks, anything not in the `Assert-Pubkey-Algo` list is
  still revoked.

** Description changed:

  (Please see https://wiki.ubuntu.com/AptUpdates for the versioning)
  
  [Impact]
  We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.
  
  Also existing users may have third-party repositories that use 1024-bit
  RSA keys and we have not adequately informed them yet perhaps. We tried
  to revoke them in the 2.8.0, 2.8.1, and 2.8.2 updates (see bug 2060721).
  This has been deferred to a later update than 2.8.3 such that we can
  solve the warnings and other bugs.
  
  [Solution]
  Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
  
      ">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
  
  At the same time we will also introduce a more nuanced approach to
  revocations by introducing a 'next' level that issues a warning if the
  key is not allowed in it and a 'future' level that will issue an audit
  message with the --audit option.
  
  For the next level, we will set it to:
  
      ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"
  
  This means we restrict warnings to Brainpool curves and the secp256k1
  key, which we have not received any feedback about them being used yet.
  
  For the future level, we will take a strong approach to best practices
  as it is only seen when explictly running with --audit and the intention
  is to highlight best practices. It will be set to
  
      ">=rsa3072,ed25519,ed448";
  
  Which corresponds to the NIST recommendations for 2031 (and as little
- curves as possible).
+ curves as possible). This level is unused in the 24.04 upload as the
+ corresponding "audit" log level has not been backported to it.
  
  [Test plan]
  Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.
  
  Some smoke tests:
  
  - Observe one a system with a 1024R signed repository that it keeps working and produces a warning (ensures a key listed in "next" but not in "current" warns)
  - Sign a repository with a NIST P-256 key and ensure it does not produce warnings (ensures that a key listed in "current" and "next" does not warn)
  
  [Where problems could occur]
  There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.
  
  There cannot be any false positives: The new levels are only
  *additional* checks, anything not in the `Assert-Pubkey-Algo` list is
  still revoked.

** Description changed:

  (Please see https://wiki.ubuntu.com/AptUpdates for the versioning)
  
  [Impact]
  We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.
  
  Also existing users may have third-party repositories that use 1024-bit
  RSA keys and we have not adequately informed them yet perhaps. We tried
  to revoke them in the 2.8.0, 2.8.1, and 2.8.2 updates (see bug 2060721).
  This has been deferred to a later update than 2.8.3 such that we can
  solve the warnings and other bugs.
  
  [Solution]
  Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
  
      ">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
+ 
+ Note that we still keep rsa1024 as allowed.
  
  At the same time we will also introduce a more nuanced approach to
  revocations by introducing a 'next' level that issues a warning if the
  key is not allowed in it and a 'future' level that will issue an audit
  message with the --audit option.
  
  For the next level, we will set it to:
  
      ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"
  
  This means we restrict warnings to Brainpool curves and the secp256k1
  key, which we have not received any feedback about them being used yet.
  
  For the future level, we will take a strong approach to best practices
  as it is only seen when explictly running with --audit and the intention
  is to highlight best practices. It will be set to
  
      ">=rsa3072,ed25519,ed448";
  
  Which corresponds to the NIST recommendations for 2031 (and as little
  curves as possible). This level is unused in the 24.04 upload as the
  corresponding "audit" log level has not been backported to it.
  
  [Test plan]
  Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.
  
  Some smoke tests:
  
  - Observe one a system with a 1024R signed repository that it keeps working and produces a warning (ensures a key listed in "next" but not in "current" warns)
  - Sign a repository with a NIST P-256 key and ensure it does not produce warnings (ensures that a key listed in "current" and "next" does not warn)
  
  [Where problems could occur]
  There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.
  
  There cannot be any false positives: The new levels are only
  *additional* checks, anything not in the `Assert-Pubkey-Algo` list is
  still revoked.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2073126

Title:
  More nuanced public key algorithm revocation

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Noble:
  Fix Committed
Status in apt source package in Oracular:
  Fix Released

Bug description:
  (Please see https://wiki.ubuntu.com/AptUpdates for the versioning)

  [Impact]
  We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.

  Also existing users may have third-party repositories that use
  1024-bit RSA keys and we have not adequately informed them yet
  perhaps. We tried to revoke them in the 2.8.0, 2.8.1, and 2.8.2
  updates (see bug 2060721). This has been deferred to a later update
  than 2.8.3 such that we can solve the warnings and other bugs.

  [Solution]
  Hence we will restore all elliptic curve keys of 256 or more bit to trusted:

      ">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";

  Note that we still keep rsa1024 as allowed.

  At the same time we will also introduce a more nuanced approach to
  revocations by introducing a 'next' level that issues a warning if the
  key is not allowed in it and a 'future' level that will issue an audit
  message with the --audit option.

  For the next level, we will set it to:

      ">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"

  This means we restrict warnings to Brainpool curves and the secp256k1
  key, which we have not received any feedback about them being used
  yet.

  For the future level, we will take a strong approach to best practices
  as it is only seen when explictly running with --audit and the
  intention is to highlight best practices. It will be set to

      ">=rsa3072,ed25519,ed448";

  Which corresponds to the NIST recommendations for 2031 (and as little
  curves as possible). This level is unused in the 24.04 upload as the
  corresponding "audit" log level has not been backported to it.

  [Test plan]
  Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.

  Some smoke tests:

  - Observe one a system with a 1024R signed repository that it keeps working and produces a warning (ensures a key listed in "next" but not in "current" warns)
  - Sign a repository with a NIST P-256 key and ensure it does not produce warnings (ensures that a key listed in "current" and "next" does not warn)

  [Where problems could occur]
  There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.

  There cannot be any false positives: The new levels are only
  *additional* checks, anything not in the `Assert-Pubkey-Algo` list is
  still revoked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2073126/+subscriptions