Re: [openpgp] crypto-refresh finished? (again;-)

[Paul Schaub <[e-mail]>]

Hi,

Am 21.06.23 um 19:06 schrieb Werner Koch:
> Hi!
>
> Given that question and suggestions from major implementors have not
> been properly discussed and taken in account, I doubt that there is
> sufficient consensus in the WG for a new RFC or even an IETF Last Call.
>
> In particular Kai Eggert's mail from 8 Oct 2022 "Re: [openpgp] a new
> draft overlapping the WG draft" [1] had well thought out suggestions
> which were never seriously discussed.

Perhaps that demonstrates that the majority of involved parties did not 
see the need to discuss these points in more depth ¯\_(ツ)_/¯.

But let's give it a try anyways.

(quotes below from Kai's mail)

> Maybe the following could be done:
>
> * introduce the concepts of openpgp specification versions, and minimum
> supported openpgp versions
See key format versions (4,5,6) and feature flags[1].
> * Declare that a public key packet can specify the minimum OpenPGP
> version the key owner's software supports (define how public key packets
> could signal that). Find a way to encode that in a way that doesn't make
> public key packets incompatible with current GnuPG. If it's necessary to
> define an evolution of public key packets, try to reach consensus with
> GnuPG developers on how to do that.
Same as above. If there is a v4 key without the SEIPDv2 feature flag, 
implementations can produce artifacts compatible to rfc4880,rfc5581,rfc6637.
> * Release crypto-refresh as a new OpenPGP version 5, not as a successor
> for RFC 4880.
s/v5/v6
> * For public keys that lack the new OpenPGP version flag, assume the key
> owner is limited to RFC 4880 features, only.
See my comment above.
> * Declare that for messages that are signed, only, the signature packet
> should be limited to RFC 4880, or a future universally accepted
> successor (which is currently not in sight). The reason is that for
> signed-only messages, it isn't necessary to have public keys for all
> recipients, and thus the version signaling information may be absent.
> (Optionally the presence of public keys for all message recipients could
> be used to conclude that a newer signature package can be used.)
If the sender uses v5/v6 keys there is not much to do, since recipients 
cannot use the key to verify the signature anyways. Implementers could 
still opt to create v4 signatures if v4 keys are among the recipients in 
an attempt to have compatibility with v4 implementations that understand 
v5/v6 key packet formats.
> * Declare that in order to make use of any of the features from
> crypto-refresh, it's required to have a recipient public key that
> signals support for version 5.
s/v5/v6, but yes, an implementation that strives to be backwards 
compatible can do that.
> * If a message is to be sent to multiple recipients, which signal
> different supported OpenPGP versions, the sender is required to produce
> the appropriate number of different messages, one for each group of
> recipients supporting the same version.
That might be a solution, although it feels like a clumsy workaround.
> * For transparency reasons, each message somehow signal the additional
> reicpients, which will be handled with a separate openpgp message
> (different version). Maybe this could be done by reusing the existing
> "Public-Key Encrypted Session Key Packets" with a key identifier, but
> dummy data.
There now is an Intended Recipient Fingerprint subpacket to solve this 
issue.
> This means GnuPG would continue to use its existing packets, it would
> always use what's defined in version 4.
That's up to the GnuPG developers ;)
> Applications that support crypto-refresh would be required to also
> support RFC 4880.
That's up to implementers that support v6.
> When applications that support crypto-refresh need to send data to
> owners of public keys that lack the version information, then data
> that's compatible with GnuPG and old applications would be sent.
Sounds sensible.
> Disclaimer: This is a high level attempt to find a middle ground for the
> current conflict. I haven't read the full details of the RFCs, I might
> have missed if my suggestions are already specified, or that they are
> not doable.
>
> Kai
Thank you for your thoughts Kai. I think some of your ideas can be used 
to achieve interoperability between implementations with different 
levels of sophistication.

[1]: https://openpgp-wg.gitlab.io/rfc4880bis/#name-features