From wk at gnupg.org Wed Nov 29 10:00:39 2023 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Nov 2023 10:00:39 +0100 Subject: Welcome to LibrePGP technical discussions Message-ID: <87wmu19bns.fsf@jacob.g10code.de> Hello! Welcome to this new mailing list. The intended audience for this mailing list are implementers of the LibrePGP specification. This ML provides a place to discuss technical matters of the LibrePGP (formerly known as OpenPGP) encryption standard. Rules for this mailing lists are: - Be friendly. - Be technically focused. - Everything written here is in the Public Domain except for code snippets which are under their respective licenses. - No top posting and please strip qoutes to a sensible size. - Avoid posting only URLs. If this can't be avoided please also post a summary. - Keep the S/N ratio high and avoid a discussion style as introduced around 2018 in the OpenPGP working group mailing list. - Posters which don't stick to these rules may be set on moderation. Background: The major implementers of the OpenPGP standard as specified by RFC-4880 came together and agreed that the planned updates of the IETF to RFC-4880 are harmful for the existing deployment of OpenPGP software. The majority of its users are expecting long-term stability and a real world focus instead of disruptive changes as recently been proposed the IETF OpenPGP working group. RNP (known from the Mozilla Thunderbird mailer) and GnuPG (used by the majority of other mail programs) are by far the most widely used implementations with a track record of more than 25 years. Back in 2018 both did interoperability testing of new OpenPGP features and rolled out these features in their software to prepare a smooth migration to the new features. LibrePGP is based on these OpenPGP updates with minor additional updates in the same way, this has been done over the 25 years lifetime of OpenPGP. The current LibrePGP specification is https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-02.txt which is also known as LibrePGP version 0.8.2. Update notification with diffs will be posted here. The next work item for LibrePGP should be the introduction of post-quantum encryption due to forthcoming encryption policies. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From kaie at kuix.de Mon Dec 4 16:38:16 2023 From: kaie at kuix.de (Kai Engert) Date: Mon, 4 Dec 2023 16:38:16 +0100 Subject: Coexistence with OpenPGP/IETF Message-ID: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> Hello, what is the position of the developers of the LibrePGP specification regarding co-existence with the OpenPGP/IETF specification? As I understand it, both OpenPGP and LibrePGP share a common part of its protocol, which we could describe as the OpenPGP legacy format (or v4). I assume the developers of the LibrePGP specification expect that this data format will be used with email, please correct me if I'm wrong. As of today, the PGP/MIME specification is used to specificy how to transport PGP data in email messages. Do you expect that MUAs will use the same content-types as defined in the PGP/MIME specification? (RFC 3156). Or do you suggest that new, different content-types shall be used for LibrePGP? If both will use the same content-types, a MUA that implements only one specification will have to attempt to parse the data, and it will either succeed, or it will find data packets that it doesn't support. It would help implementations to be able to clearly identify whether a data stream of PGP packets follows either the OpenPGP or the LibrePGP specification. Are the developers of the LibrePGP specification willing to coordinate with the developers of the OpenPGP specification, to ensure the specifications will have no clashes in the specification of the wire format? Regards Kai From aheinecke at gnupg.org Wed Dec 6 10:45:48 2023 From: aheinecke at gnupg.org (Andre Heinecke) Date: Wed, 06 Dec 2023 10:45:48 +0100 Subject: Coexistence with OpenPGP/IETF In-Reply-To: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> Message-ID: <1881877.tdWV9SEqCh@teutates> Hello On Monday, 04 December 2023 16:38:16 CET Kai Engert via LibrePGP-discuss wrote: > what is the position of the developers of the LibrePGP specification > regarding co-existence with the OpenPGP/IETF specification? > > As I understand it, both OpenPGP and LibrePGP share a common part of its > protocol, which we could describe as the OpenPGP legacy format (or v4). Yes, we see LibrePGP as basically was what agreed upon and building on the established RFC4880 Standard with some adaptations to modernize it where required. But without some of the proposed changes in the "Crypto Refresh". > I assume the developers of the LibrePGP specification expect that this > data format will be used with email, please correct me if I'm wrong. Yes sure. > As of today, the PGP/MIME specification is used to specificy how to > transport PGP data in email messages. > > Do you expect that MUAs will use the same content-types as defined in > the PGP/MIME specification? (RFC 3156). Or do you suggest that new, > different content-types shall be used for LibrePGP? No we will of course continue to use PGP/MIME. > If both will use the same content-types, a MUA that implements only one > specification will have to attempt to parse the data, and it will either > succeed, or it will find data packets that it doesn't support. There is currently several "Should" parts of the implementations where there is the need to fall back on common features. I guess the MUA should not much care about this and leave it to the PGP backend. > It would help implementations to be able to clearly identify whether a > data stream of PGP packets follows either the OpenPGP or the LibrePGP > specification. In my opinion that is what the Version indicates. > Are the developers of the LibrePGP specification willing to coordinate > with the developers of the OpenPGP specification, to ensure the > specifications will have no clashes in the specification of the wire format? Since LibrePGP is mostly a subset, a modernization of RFC4880, but without parts of the crypto refresh there might be incompatibilities when implementations decide not to implement features of crypto refresh, but for backwards compatibility we do not expect much problems with LibrePGP. There has been much contention about the AEAD / AES-OCB feature packet but in my opinion it is not much different then having a preference on a key that says e.g. that a client / key may support a cipher mode that is not implemented in your client and you then have to fallback to something else. Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, B.Reiter, A.Heinecke Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 5655 bytes Desc: This is a digitally signed message part. URL: