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

On 21/11/2025 15:58, Paul Wouters wrote:
> On Fri, 21 Nov 2025, Petr Menšík wrote:
>
> [ removed dance@ from the thread ]
>
> I clearly misunderstood your idea. I thought you wanted to publish
> hashes of keys only to reduce pulling in full keys via DNS?

Yes! Because at least how this is used by Fedora, you always get 
installed the key itself on the media or from the repository. It is 
often the case you have the keys, but are not sure they are considered 
(still) trusted by its owner.

That is full fingerprint in gpg, or unique identificator of the key. You 
can change UID for the key owner, but not the key fingerprint.

>
>> My primary motivation was to provide easy check whether that user has 
>> changed his key.
>
> If they migrated keys from one to another, presumbly you have to fetch
> the new key. So the only optimization is when they key is unchanged and
> you want to see if it is still the current key. I guess what you could
> do is provide a hash-of-key CNAME to the actual OPENPGPKEY record?
> Although querying CNAMEs through proxies might still cause all the work,
> so perhaps just a TXT record where you don't care about RRdata could be
> used. I am not sure this effort is worth it though. You are installing
> a few GB of new RPMs - I don't think a single large DNS query is making
> much of a difference here?

Yes. I think you potentially can have multiple large keys on single 
owner name. For example one post-quantum key, one ED25519. Their 
combined size would require always fetching over TCP. Would be 
inefficient in cache if refresh of key were tried every time dnf 
repository were refreshed. That is ideal state I would like to archieve. 
DNSSEC works again even with systemd-resolved in the way. libunbound 
could be used to verify the chain to the key fingerprint. Fingerprints 
will work okay with UDP responses only. Keys usually won't.

It should be shared by multiple instance on the same network. It think 
it will be making a difference.  You can try if for a large number of 
keys potentially. Such as:

sq network dane search --all

I would like to use it also as proof of ownership, if the record is 
signed, it could set trusted to some degree:

  sq cert list --gossip

I would like these  hexadecimal characters in FP to be used only in a 
presentation form. On wire binary form, they should be binary-only and 
compact. Then it should not use TXT. That would not allow 
case-insensitive comparison. DS or CDS records from DANE would be more 
appropriate, but they serve a different purpose and for different kinds 
of key. Because PGP keys do not have only different KEY/DNSKEY algorithm 
ID, I think a new record type is needed. Adding a new key type should 
not be too much work, or is it? I hope DANCE WG will be more receptive 
for such updates than dnsop. That seems busy with different topics.

>
>>>  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.
>
>> 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.
>
> I misunderstood your original proposal and did not recognise the
> hash-of-email :)
>
> Paul
>
-- 
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]