Coexistence with OpenPGP/IETF

[Andre Heinecke]

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: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20231206/61eb9a75/attachment.sig>