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

Oh, okay. What I had on mind is to display key id. I think that is 
always SHA256 now.

It might make sense to have extra digest on full key published. It might 
then indicate primary key did not change, but some metadata might have 
changed.

On 21/11/2025 00:06, Paul Wouters wrote:
> On Wed, 19 Nov 2025, Petr Menšík wrote:
>
> [ Adding openpgp to CC: so we can start dropping dance from this later ]
>
>> I think it would be nice to have something like SSHFP for SSH key. 
>> Software working with PGP works by intentifying keys by their digest. 
>> PGP key can be potentially large. It is wasting of connectivity to 
>> make repeated key requests, when I am interested only in information 
>> that the key is still the latest.
>
> OpenPGP keys can have various things in them. For example other people's
> signatures vouching for the key. Or optional attributes like photos. For
> you to determine you have to same key to run the hash over to get the
> same fingerprint, you have to remove all that data and strip the key to
> its minimum. At which point, why not push that into the existing OPENPGP
> record?

My primary motivation was to provide easy check whether that user has 
changed his key. If he did, you would use the same owner name and fetch 
the key data. I do not propose to stop publishing OPENPGPKEY record in 
DNS completely. But I think if I already have a key, I would like to 
have smaller check it is still current.

That would be useful especially for any Post-Quantum algorithms, where 
key size increased.

>
>> Example:
>>
>> # [email protected]
>> 72dec291ea5c80f07dca832be132f5c6cb6d43713ec4843dff82d7ee._openpgpkey.fedoraproject.org. 
>> IN OPENPGPFP 2 C6E7F081CF80E13146676E88829B606631645531
>>
>> This could make more efficient way to query ID of current key. If you 
>> have the key already, fetching the key each time again is wasting.
>
> Such a prefix seems odd. It makes querying harder if there is a key
> update. Using the OPENPGPKEY method based on unique email address seems
> more robust to me.
>
> Paul

Uhm, this owner name is created by your own tool openpgpkey from 
python3-hash-slinger package. This is exactly the same from RFC 7929, 
where you are the author. If it should be clear what it is, I know no 
better person than you. This is email address converted to DNS owner 
name by your own algorithm, digest created from username part.

$ gpg --auto-key-locate dane --locate-external-key 
[email protected]
gpg: key 829B606631645531: "Fedora (43) 
<[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
pub   rsa4096 2024-08-10 [SCE]
       C6E7F081CF80E13146676E88829B606631645531
uid           [ unknown] Fedora (43) <[email protected]>

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.

Best 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]