Hi there. This is because of security reasons.
Every new release has its own new key.
Have a look here:
https://getfedora.org/en/security/
Scroll down, there are the finger prints, like:
Fedora 34
id:
4096R/45719A39 2020-08-06
Fingerprint:
8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39
Your message probably means that the new fingerprint was not yet stored in the rpm data base.
In the first step you download the new files, by dnf system-upgrade download --releasever=34
With the second step you actually install the new version, by dnf system-upgrade clean.
I’m not sure when exactly the finger print is being checked. Could also be done by refreshing the repo the first time.
Edit
The Finger Print can be found in the dnf.logs under
/var/log/dnf.log*
Mine says, the new GPG has been added right after the new fedora 34 files has been downloaded (first step) and before dnf system-upgrade clean has been executed.
Does this information help?
To your second output, this probably means, that your keys are already installed in the gpg keyring and did not change. This did not happen for me. I didn’t had the fedora 34 finger print in the gpg keyring after upgrading and updating. You may have added it manually.
So you Public GPG Key of Fedora 34 already was imported.
Basically there is a public and a private part of the signature.
The finger print should be a hash of the public part.
https://en.wikipedia.org/wiki/Public_key_fingerprint
Most interesting part, regarding your question might be:
Using public key fingerprints for key authentication
Further information: key authentication
When a public key is received over an untrusted channel, such as the Internet, the recipient often wishes to authenticate the public key. Fingerprints can help accomplish this, since their small size allows them to be passed over trusted channels where public keys won’t easily fit.
For example, if Alice wishes to authenticate a public key as belonging to Bob, she can contact Bob over the phone or in person and ask him to read his fingerprint to her, or give her a scrap of paper with the fingerprint written down. Alice can then check that this trusted fingerprint matches the fingerprint of the public key. Exchanging and comparing values like this is much easier if the values are short fingerprints instead of long public keys.
Fingerprints can also be useful when automating the exchange or storage of key authentication data. For example, if key authentication data needs to be transmitted through a protocol or stored in a database where the size of a full public key is a problem, then exchanging or storing fingerprints may be a more viable solution.
In addition, fingerprints can be queried with search engines in order to ensure that the public key that a user just downloaded can be seen by third party search engines. If the search engine returns hits referencing the fingerprint linked to the proper site(s), one can feel more confident that the key is not being injected by an attacker, such as a Man-in-the-middle attack.
PGP developed the PGP word list to facilitate the exchange of public key fingerprints over voice channels.
Since you said that you got your request for the new key long after the upgrade, it might be advised to double check integrity. Would it have been possible to upgrade to Fedora 34 without accepting the key? You may have accidentally chosen “No” in the process? Not sure if I’d look for my tinfoil hat in such a situation. :-/
However I think the new public key is not necessarily added to the gpg keyring during the upgrade process.
I’d check the logs.
grep -r "8C5B A699 0BDB" /var/log/dnf.*
To find the corresponding log and the go in and search for “8C5B”.
Dnf/yum use their own key space
https://www.redhat.com/sysadmin/rpm-gpg-verify-packages
This is not the same place then the gpg keyring. They use their own places and infrastructure, commands like rpm --import and rpm -qa gpg-pubkey*…
Its key locations stored in the repo files. The finger prints are stored in the rpm database.
thank you for helping out!