| 2024-07-15 14:28:03 |
Julian Andres Klode |
bug |
|
|
added bug |
| 2024-07-15 14:28:18 |
Julian Andres Klode |
tags |
|
foundations-todo |
|
| 2024-07-15 14:28:44 |
Julian Andres Klode |
apt (Ubuntu): assignee |
|
Julian Andres Klode (juliank) |
|
| 2024-07-15 17:31:40 |
Julian Andres Klode |
summary |
Only revoke RSA explicitly |
More nuanced public key algorithm revocation |
|
| 2024-07-15 17:31:50 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Noble |
|
| 2024-07-15 17:31:50 |
Julian Andres Klode |
bug task added |
|
apt (Ubuntu Noble) |
|
| 2024-07-15 17:31:50 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-07-15 17:31:50 |
Julian Andres Klode |
bug task added |
|
apt (Ubuntu Oracular) |
|
| 2024-07-15 17:31:57 |
Julian Andres Klode |
apt (Ubuntu Noble): milestone |
|
ubuntu-24.04.1 |
|
| 2024-07-15 17:41:37 |
Julian Andres Klode |
description |
APT 2.9.x and 2.8.0 revoke any of the non-asserted algorithms, we should modify the mechanism such that only RSA1024 is raised to an error to avoid unwanted regressions while still keeping the set of fully supported algorithms small. |
[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.
[Solution]
Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
APT::Key::Assert-Pubkey-Algo
">=rsa2048,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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
|
| 2024-07-15 17:52:34 |
Julian Andres Klode |
description |
[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.
[Solution]
Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
APT::Key::Assert-Pubkey-Algo
">=rsa2048,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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
[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.
[Solution]
Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
APT::Key::Assert-Pubkey-Algo
">=rsa2048,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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
|
| 2024-07-15 17:52:47 |
Julian Andres Klode |
description |
[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.
[Solution]
Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
APT::Key::Assert-Pubkey-Algo
">=rsa2048,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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
[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.
[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";
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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
|
| 2024-07-15 17:52:54 |
Julian Andres Klode |
description |
[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.
[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";
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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
[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.
[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";
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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
|
| 2024-07-15 18:38:46 |
Julian Andres Klode |
description |
[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.
[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";
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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
[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.
[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";
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.
A spot check with a 1024-bit RSA repository and a 4096 RSA repository would still be nice.
[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. |
|
