Re: [openpgp] To bind or not to bind

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2024-03-22 21:57:04 +0100, Kai Engert wrote:
> If we find that it works, and if it were decided that v4-pqc keys shall 
> be supported, we could consider to enable the flag, in the hope that it 
> doesn't introduce other side effects. However, it would be preferable to 
> get an updated version of RNP that fixes the intolerance problem.

This isn't just for v4-pqc keys -- it's for any new pubkey algorithm,
PQC or otherwise.  One of the weird things about the semantics of this
flag is that it seems to mix semantics about storage with semantics
about use.

Presumably a rigorous stateful OpenPGP implementation would want to do
something like (ignoring questions about third-party certifications for
the purposes of this discussion):

 - on ingesting a certificate with self-signed material, only ingest the 
   self-signed components that actually cryptographically verify.
   
 - avoid discarding unknown-but-verified self-signed components (unless
   you run into storage constraints) -- those components might be useful
   later, after an upgrade

 - if the application layer wants to know whether the certificate is
   usable for a given purpose or not (e.g. signature verification,
   encryption), only report on the *known* components, even though the
   unknown components are stored.

 - on upgrade, a given certificate might suddenly become usable, that's
   good!

But the RNP_LOAD_SAVE_PERMISSIVE semantics are a strange combination
that doesn't really match the above reasoning that i can tell, whether
it is set or cleared.

You might want to weigh in on https://github.com/rnpgp/rnp/issues/2204
where i'm trying to raise the issue directly with RNP folks.

      --dkg