[openpgp] Re: [Dance] Key digest companion for RFC 7929 OPENPGPKEY

On 21/11/2025 11:49, Andrew Gallagher wrote:
> Hi, Petr.
>
> When you say "changed his key" do you mean "updated his existing key", 
> or "published a new key"? These use cases are quite different and will 
> probably need to be tackled separately.

By changed his key, I meant that he might have published a new key and 
no longer is using the old one. For whatever reason. It might also mean 
he stopped using PGP key completely and wants to indicate that. IE. he 
might have revoked the key without any replacement.

What I were thinking about was primary key id. No modification of user 
ID, photo or additional data published in the key.

>
>> I think there is no need to create different owner name to different 
>> record type, they are closely related. But I propose to publish two 
>> records on that name. Both OPENPGPKEY and OPENPGPFP. For checking 
>> validity of existing keys OPENPGPFP record query would be enough. 
>> Once you get information your keyid has not changed, you do not have 
>> to query the key data (again). If you will get NXDOMAIN response to 
>> OPENPGPFP query on the shared owner name, then you do not have to 
>> query OPENPGPKEY record anymore. You already know it is not there.
>
> Note that when someone modifies their public key, it will have the 
> same "key ID" (we should probably use "fingerprint", because "key ID" 
> has a specific, slightly different meaning in OpenPGP). Any mechanism 
> that returns just a fingerprint will not be able to represent modified 
> states of an existing key.
Yes, that is exactly what I wanted. That is why I propose to publish 
fingerprint used as key handle by software I use. Key data modification 
should not change the id presented by OPENPGPFP. Only generation of 
different key should cause that. That should provide strong indication 
to user he should fetch a new key again. I am only user of PGP, do not 
know correct terminology for important details. I have read couple of 
DNS RFCs, but never read any PGP RFC. Sorry if my terms are little 
misguiding.
>
> I do see value in being able to publish a "last modified" or 
> "unchanged" state to reduce network traffic, but maybe it's better 
> represented by a timestamp?
>
> A

Ah, okay, timestamp of last the change might be enough. Except it 
depends on correct time of the machine storing that change. At least gpg 
--list-keys does not print any timestamp of last modification. I think 
it does not have to be full cryptographic usable digest. Shortened form 
would be enough, just some indication of "version". It might have used 
digest on the extensions used in published OPENPGPKEY data. It would 
need some sorting to be stable. Perhaps it is safer to include only key 
fingerprint. UID change will likely need a different owner name. It 
would make sense to use CNAMEs to share multiple UID data pointing to 
single key instance. Additions to metadata are not important when 
checking key trust. Key trust verification is what I would like to have 
implemented by this.

Regards,
Petr

-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]