Thanks for your summary, Andreas, I found it very helpful. This guide appeared to be the newest from NIST that I could find on the topic of key lengths https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf -- page 21 (marked 11 on the page) appears to say n=1024 is still fine for "legacy use": "The algorithm or key length may only be used to process already protected information (e.g., decrypt ciphertext data or verify a digital signature)". A very literal reading would probably suggest that *old* InRelease files would be fine but *new* InRelease files wouldn't be. There'd be no reliable way to tell the age without actually validating the signature, so maybe it's academic, but I don't imagine they intended to allow installing software protected solely by rsa1024.
I would prefer if we asked users to make this change themselves if they still have rsa1024 repositories somewhere. Noble has been out for almost a year. Ubuntu 24.04.1 was released over six months ago. If the >=rsa2048 restrictions were brand new, and we saw a deluge of complaints, maybe relaxing it would make sense. But what we've seen is a decade of people asking us how to prevent rsa1024 from being used. I don't understand why today is the right day to allow weaker RSA keys. All the other changes seem fine to me. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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. The change in behavior of APT::Key::Assert-Pubkey-Algo _may_ cause a regression if you purposefully override `APT::Key::Assert-Pubkey-Algo` to *NOT* include algorithms that you actually use; which seems highly unlikely given that you'd be introducing warnings to your system. If you don't have a custom value set (or no warnings with your custom value), you have no regression there. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2073126/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
