Re: [openpgp] To bind or not to bind

[Falko Strenzke <[e-mail]>]

Am 23.03.24 um 04:59 schrieb Daniel Kahn Gillmor:
> Thanks for asking this question, Aron.
>
> With no hats on, here are my preferences:
>
> On Thu 2024-03-21 20:26:26 +0000, Aron Wussler wrote:
>
>>   (1) Whether PQC encryption algorithms can be used only in v6 keys
> I am still undecided on (1).

I think the main question is how we anticipate the evolution of two 
different aspects: How fast the lack of forward compatibility regarding 
unknown algorithm IDs can be fixed in the major implementations on the 
one hand and how fast v6 will be widely supported on the other hand.

I don't want to sound negative, but currently I don't expect a fast way 
to a widely deployed support for v6. Given the well-known problem of the 
competing successors of v4, I think most of the maintainers of 
applications and Linux distributions will be conservative here because 
an unimpaired user experience has number one priority for them (else 
it's them who'll have to deal with the complaints etc.). Enabling PQC 
with v4 in a backwards compatible manner by

1) fixing the forward compatibility of the affected implementations
2) introducing v4 PQC encryption support

seems to be easier to achieve. And, in line with Aron's argument, I 
would see this as a first step towards modernization in OpenPGP 
deployments which would hopefully build the confidence and experience 
for the v6 migration as the next step.

>
>>   (2) Whether PQC encryption algorithms can be used only with SEIPDv2
> I think the answer here should be: "PQC encryption-capable subkeys MAY
> be used with SEIPDv1 when encrypting a single message to multiple
> parties, and some of the recipient parties do not support SEIPDv2".
>
> I would not object to a statement like "Binding a PQC encryption-capable
> subkey into a certificate implies setting Feature Flag 0x08 (SEIPDv2
> support)".  We basically already require implementations to impute
> Feature Flag 0x01 (SEIPDv1 support) even if it is not explicitly set,
> because SED encryption needs to go away.  And an implementation that can
> implement PQC but is incapable of implementing SEIPDv2 would be very
> surprising.  Why not couple them explicitly to move users to the more
> robust format?
This proposal sounds reasonable to me.
>
> OTOH, I would *not* want to introduce a new failure mode for a case
> where i can encrypt to two distinct certs individually, but i cannot
> encrypt to the two of them together.  That strikes me as terribly
> unfriendly to the application layer.  Does anyone think that would be an
> acceptable outcome?

No, I think it is clear that we need the compatibility to SEIPDv1 where 
it is necessary.

- Falko

>
>     --dkg
>
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
-- 

*MTG AG*
Dr. Falko Strenzke
Executive System Architect

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

<https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false>
Follow us
------------------------------------------------------------------------
<https://www.mtg.de/de/aktuelles/MTG-AG-erhaelt-Innovationspreis-des-Bundesverbands-IT-Sicherheit-e.V-00001.-TeleTrust/> 
<https://www.itsa365.de/de-de/companies/m/mtg-ag>

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>