From bernhard at intevation.de Tue Jan 2 10:54:23 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 2 Jan 2024 10:54:23 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <1881877.tdWV9SEqCh@teutates> References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> <1881877.tdWV9SEqCh@teutates> Message-ID: <202401021054.24451.bernhard@intevation.de> Hello, a happy new year! Am Mittwoch 06 Dezember 2023 10:45:48 schrieb Andre Heinecke via LibrePGP-discuss: > 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". A main point as I've understood is about how to introduce a new format for public keys in a way to have a good user experience. GnuPG and RNP implemented reading v5 key packages a few years ago, so when they switch to create pubkeys files in that format, implementation are already widespread. This is best for usability as many users will not notive much. It is interesting so see how large the user base for reading v5 pubkeys already. Is does somebody know in which release GnuPG and RNP and thus email applications like Outlook, KMail, Claws and Thunderbird can read v5 pubkeys? Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Jan 2 14:24:31 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jan 2024 14:24:31 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <202401021054.24451.bernhard@intevation.de> (Bernhard Reiter via LibrePGP-discuss's message of "Tue, 2 Jan 2024 10:54:23 +0100") References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> <1881877.tdWV9SEqCh@teutates> <202401021054.24451.bernhard@intevation.de> Message-ID: <87wmsr50mo.fsf@jacob.g10code.de> On Tue, 2 Jan 2024 10:54, Bernhard Reiter said: > GnuPG and RNP implemented reading v5 key packages a few years ago, > so when they switch to create pubkeys files in that format, Actually the key format is not the main controversial thing but the AEAD mode which changed in crypto-refresh-post-fall-2021. Nevertheless there are also points with the key and signature packet formats. In particular the removal of meta data signing is a severe issue which does not allow us to implement that signature format. Frankly, I would like to use the v6 signature format because it allows for larger subpackets. But not at the cost of losing the meta data signing. However, the larger sub-packets are not a really issue right now - even not with PQC. Please remember that v5 is not just *PGP v5 because each packet type has its own version number and they do not necessary need to match. Hallpy new year, 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 wk at gnupg.org Tue Jan 2 15:22:07 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jan 2024 15:22:07 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <614F479F-127E-49E3-8B40-BE2981DAC0C1@andrewg.com> (Andrew Gallagher's message of "Tue, 2 Jan 2024 13:31:15 +0000") References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> <1881877.tdWV9SEqCh@teutates> <202401021054.24451.bernhard@intevation.de> <87wmsr50mo.fsf@jacob.g10code.de> <614F479F-127E-49E3-8B40-BE2981DAC0C1@andrewg.com> Message-ID: <87h6jv4xyo.fsf@jacob.g10code.de> On Tue, 2 Jan 2024 13:31, Andrew Gallagher said: > Hi, Werner. Would allowing type 40 subpackets in v6 sigs as well as v4 > address this concern? The Literal Data Meta Hash is specified as This subpacket MAY be used to protect the meta data from the Literal Data Packet with V4 signatures. [...] and as such a band-aid for a long standing problem. Sure, you may use it for v6 signatures. But after all why should you do it, given that it was removed from crypto-refresh for some incomprehensible reason. Shalom-Salam, 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 andrewg at andrewg.com Tue Jan 2 15:32:48 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jan 2024 14:32:48 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87h6jv4xyo.fsf@jacob.g10code.de> References: <87h6jv4xyo.fsf@jacob.g10code.de> Message-ID: On 2 Jan 2024, at 14:23, Werner Koch wrote: > > Sure, you may use it > for v6 signatures. But after all why should you do it, given that it > was removed from crypto-refresh for some incomprehensible reason. IIRC it was left out because people couldn?t agree and they ran out of time. I?m suggesting now that we put it back in, and use the same scheme for v4 and v6 because it only requires one implementation and not two. Is there any technical problem with this idea? A From andrewg at andrewg.com Tue Jan 2 14:31:15 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jan 2024 13:31:15 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87wmsr50mo.fsf@jacob.g10code.de> References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> <1881877.tdWV9SEqCh@teutates> <202401021054.24451.bernhard@intevation.de> <87wmsr50mo.fsf@jacob.g10code.de> Message-ID: <614F479F-127E-49E3-8B40-BE2981DAC0C1@andrewg.com> On 2 Jan 2024, at 13:24, Werner Koch via LibrePGP-discuss wrote: > > Frankly, I would like to use the v6 signature format because it allows > for larger subpackets. But not at the cost of losing the meta data > signing. However, the larger sub-packets are not a really issue right > now - even not with PQC. Hi, Werner. Would allowing type 40 subpackets in v6 sigs as well as v4 address this concern? A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Tue Jan 2 16:09:30 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jan 2024 16:09:30 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: (Andrew Gallagher's message of "Tue, 2 Jan 2024 14:32:48 +0000") References: <87h6jv4xyo.fsf@jacob.g10code.de> Message-ID: <87cyuj4vrp.fsf@jacob.g10code.de> On Tue, 2 Jan 2024 14:32, Andrew Gallagher said: > scheme for v4 and v6 because it only requires one implementation and > not two. Is there any technical problem with this idea? Complexity. 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 andrewg at andrewg.com Tue Jan 2 16:42:58 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jan 2024 15:42:58 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87cyuj4vrp.fsf@jacob.g10code.de> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> Message-ID: <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> On 2 Jan 2024, at 15:09, Werner Koch wrote: > > On Tue, 2 Jan 2024 14:32, Andrew Gallagher said: > >> scheme for v4 and v6 because it only requires one implementation and >> not two. Is there any technical problem with this idea? > > Complexity. Are you saying that implementing the same integrity check method for both v4 and v6 sigs is *more* complex than the alternative? I don?t understand... A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Jan 3 10:52:47 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jan 2024 10:52:47 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> (Andrew Gallagher's message of "Tue, 2 Jan 2024 15:42:58 +0000") References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> Message-ID: <874jfu4uc0.fsf@jacob.g10code.de> On Tue, 2 Jan 2024 15:42, Andrew Gallagher said: > Are you saying that implementing the same integrity check method for > both v4 and v6 sigs is *more* complex than the alternative? I don?t Iff we want this feature also for v4 we need to add this complexity. However, in the long run v5 will take over and gives this for free and it will then be mandatory. 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 andrewg at andrewg.com Wed Jan 3 11:05:54 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jan 2024 10:05:54 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <874jfu4uc0.fsf@jacob.g10code.de> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> Message-ID: <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> On 3 Jan 2024, at 09:52, Werner Koch wrote: > > On Tue, 2 Jan 2024 15:42, Andrew Gallagher said: > >> Are you saying that implementing the same integrity check method for >> both v4 and v6 sigs is *more* complex than the alternative? I don?t > > Iff we want this feature also for v4 we need to add this complexity. > However, in the long run v5 will take over and gives this for free and > it will then be mandatory. OK, but by this point everyone will presumably have implemented it for v4, so the implementation will be a sunk cost. Also, if we store an unhashed copy of the metadata in the subpacket rather than a hashed copy, it simplifies the implementation of the subpacket, and means we don?t need the metdatata in the literal data packet at all, so we can zero it, which makes the treatment of detached and attached signatures identical, as well as the treatment of v4 and v6 sigs. We could even make the subpacket mandatory in v6 if that reduces the number of combinations we need to handle. It?s a different way of approaching the problem, sure. I?m not convinced it?s necessarily more complex overall. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From heiko at schaefer.name Fri Jan 5 23:18:14 2024 From: heiko at schaefer.name (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Fri, 5 Jan 2024 23:18:14 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> Message-ID: <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> On 1/3/24 11:05, Andrew Gallagher via LibrePGP-discuss wrote: > On 3 Jan 2024, at 09:52, Werner Koch wrote: >> Iff we want this feature also for v4 we need to add this complexity. >> However, in the long run v5 will take over and gives this for free and >> it will then be mandatory. > OK, but by this point everyone will presumably have implemented it for > v4, so the implementation will be a sunk cost. Also, if we store an > unhashed copy of the metadata in the subpacket rather than a hashed > copy, it simplifies the implementation of the subpacket, and means we > don?t need the metdatata in the literal data packet at all, so we can > zero it, which makes the treatment of detached and attached signatures > identical, as well as the treatment of v4 and v6 sigs. We could even > make the subpacket mandatory in v6 if that reduces the number of > combinations we need to handle. > > It?s a different way of approaching the problem, sure. I?m not > convinced it?s necessarily more complex overall. While we discuss complexity tradeoffs, I wonder: How common is the use case of having meaningful metadata for a literal data packet? In which scenarios do applications make use of these metadata fields? From andrewg at andrewg.com Sat Jan 6 10:46:39 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 6 Jan 2024 09:46:39 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> References: <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> Message-ID: On 5 Jan 2024, at 23:13, Heiko Sch?fer via LibrePGP-discuss wrote: > > How common is the use case of having meaningful metadata for a literal data packet? > In which scenarios do applications make use of these metadata fields? That?s a good question, and I don?t have the numbers to hand (perhaps Werner does?). The crypto-refresh draft assumes this use case is not common, and recommends that non-pgp methods be used instead. That?s still probably the best way to design a greenfield app; this proposal is about fixing the integrity of these fields in the cases where that isn?t possible, say where we need backwards compatibility with an existing app that expects them to exist. A From wk at gnupg.org Sat Jan 6 14:47:44 2024 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Jan 2024 14:47:44 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> ("Heiko =?utf-8?Q?Sch=C3=A4fer?= via LibrePGP-discuss"'s message of "Fri, 5 Jan 2024 23:18:14 +0100") References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> Message-ID: <877ckm375r.fsf@jacob.g10code.de> On Fri, 5 Jan 2024 23:18, Heiko Sch?fer said: > How common is the use case of having meaningful metadata for a literal > data packet? The major problem here is the one of surprise: You get a report that the data has been signed and the report also shows the file name as meta information. It is entirely counter-intuitive that the file name is not covered by the signature. It is further hard to explain in a report that one can't rely on the file name or its creation date. Yes, there are real world scenarios. The use cases come from scenarios where existing systems are secured by digital signatures or encryption. Sometimes for messages which are valid only for a few minutes and where MitM are a real concern due to broadcasting, dead zones, and relaying. Shalom-Salam, 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 verbuecheln at posteo.de Sat Jan 6 18:29:19 2024 From: verbuecheln at posteo.de (Stephan =?ISO-8859-1?Q?Verb=FCcheln?=) Date: Sat, 06 Jan 2024 17:29:19 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <877ckm375r.fsf@jacob.g10code.de> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> <877ckm375r.fsf@jacob.g10code.de> Message-ID: <26fd879819baf8ffa8f4e816c6740c9a97230fcb.camel@posteo.de> What about malicious filenames? What about ?document.pdf.gpg? decrypting to ?malware.exe?, because that is what the metadata filename field says? What about ?../../../../../dangerous/file? in the metadata filename field? It seems that filenames in metadata open all kinds of problems that we already know from tar, zip etc. These tools already do a lot of effort to deal with all the edge cases. It appears to be an unnecessary risk to have this redundant feature in PGP as well. Regards Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: This is a digitally signed message part URL: From heiko at schaefer.name Sun Jan 7 02:52:27 2024 From: heiko at schaefer.name (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Sun, 7 Jan 2024 02:52:27 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <877ckm375r.fsf@jacob.g10code.de> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> <877ckm375r.fsf@jacob.g10code.de> Message-ID: <9c4831d3-cc16-4ad9-8990-785094a7c803@schaefer.name> On 1/6/24 14:47, Werner Koch wrote: > On Fri, 5 Jan 2024 23:18, Heiko Sch?fer said: > >> How common is the use case of having meaningful metadata for a literal >> data packet? > The major problem here is the one of surprise: You get a report that the > data has been signed and the report also shows the file name as meta > information. It is entirely counter-intuitive that the file name is not > covered by the signature. It is further hard to explain in a report that > one can't rely on the file name or its creation date. > > Yes, there are real world scenarios. The use cases come from scenarios > where existing systems are secured by digital signatures or encryption. > Sometimes for messages which are valid only for a few minutes and where > MitM are a real concern due to broadcasting, dead zones, and relaying. Right, that all makes sense to me, thanks! It seems to me that everyone agrees there should be a mechanism to secure this metadata, when it is set. But clearly there are currently multiple ideas for how best to address this problem. I think Andrew is trying to figure out which paths exist to avoid redundant mechanisms between *PGP flavors, and I'd also very much like to see this happen. As you pointed out, the crypto-refresh draft doesn't currently define a mechanism for securing literal metadata (presumably because this was not covered by the charter). However, discussion on the IETF list [1] seems to indicate that after rechartering, a mechanism will be worked on. Do you see room for adjusting/aligning the LibrePGP draft to be wire-format compatible, as the WG specifies an approach for literal packet metadata? That would seem like a big step towards removing complexity between the drafts. Thanks! Heiko [1]: https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/ From wk at gnupg.org Sun Jan 7 15:29:30 2024 From: wk at gnupg.org (Werner Koch) Date: Sun, 07 Jan 2024 15:29:30 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <26fd879819baf8ffa8f4e816c6740c9a97230fcb.camel@posteo.de> ("Stephan =?utf-8?Q?Verb=C3=BCcheln?= via LibrePGP-discuss"'s message of "Sat, 06 Jan 2024 17:29:19 +0000") References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> <877ckm375r.fsf@jacob.g10code.de> <26fd879819baf8ffa8f4e816c6740c9a97230fcb.camel@posteo.de> Message-ID: <8734v92p4l.fsf@jacob.g10code.de> On Sat, 6 Jan 2024 17:29, Stephan Verb?cheln said: > What about malicious filenames? What about other malicious content in spreadsheet and other documents? That is even worse. But at least you are able to know the origin due to the signature. Nobody with a sane mind uses the metadata to directly save to a file with that name without taking necessary precautions. However, having it covered by the signatures puts the meta data at the same security level as the actual data. Salam-Shalom, Werner p.s. Please don't extend this discussion. The whole thing has been discussed more than 25 years ago and we all agreed that this is a but which should eventually be fixed. With the v5 sigature this was possible and has been done - 5 years ago. -- 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 wk at gnupg.org Sun Jan 7 15:59:10 2024 From: wk at gnupg.org (Werner Koch) Date: Sun, 07 Jan 2024 15:59:10 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <9c4831d3-cc16-4ad9-8990-785094a7c803@schaefer.name> ("Heiko =?utf-8?Q?Sch=C3=A4fer=22's?= message of "Sun, 7 Jan 2024 02:52:27 +0100") References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> <877ckm375r.fsf@jacob.g10code.de> <9c4831d3-cc16-4ad9-8990-785094a7c803@schaefer.name> Message-ID: <87y1d1196p.fsf@jacob.g10code.de> On Sun, 7 Jan 2024 02:52, Heiko Sch?fer said: > As you pointed out, the crypto-refresh draft doesn't currently define > a mechanism for securing literal metadata (presumably because this was To get the record straight: It was willfully removed after the implementers had implemented v5 signatures more than 2 years ago. There is a reason that we listed this as one of the critique points on the crypto-refresh draft updates and the forthcoming RFC. FWIW, the V5 signature format was first specified in draft-ietf-openpgp-rfc4880bis-06.txt (November 2018). A sample signature was then posted the next March. This was at a time the WG was bike-shedding over chunk sizes and discussing a proposal to remove compression support. Shalom-Salam, 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 o.nickolay at gmail.com Sun Jan 7 16:47:56 2024 From: o.nickolay at gmail.com (Nickolay Olshevsky) Date: Sun, 7 Jan 2024 17:47:56 +0200 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> References: <87h6jv4xyo.fsf@jacob.g10code.de> <87cyuj4vrp.fsf@jacob.g10code.de> <80DF829F-F3EB-4462-BF47-2646428D8F86@andrewg.com> <874jfu4uc0.fsf@jacob.g10code.de> <4FC64B6F-1B1A-4C02-A50A-8ABA4E1FA76F@andrewg.com> <37330cdc-b183-4bce-8777-aa08f2eddc87@schaefer.name> Message-ID: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> Hi Heiko, I cannot say about the exact number but during my experience on some commercial OpenPGP library we had a lot of clients, including banking, financial and even military, who used to transfer data via automated and semi-automated processes, and it included usage of filename/mtime in the literal data packet. And even in the 2008-2010 those processes were already running for years and I doubt that something would rapidly change there if change at all. On 06.01.2024 00:18, Heiko Sch?fer via LibrePGP-discuss wrote: > While we discuss complexity tradeoffs, I wonder: > > How common is the use case of having meaningful metadata for a literal > data packet? > In which scenarios do applications make use of these metadata fields? > > -- Best regards, Nickolay Olshevsky o.nickolay at gmail.com From andrewg at andrewg.com Sun Jan 7 19:28:10 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 7 Jan 2024 18:28:10 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> Message-ID: <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> On 7 Jan 2024, at 16:41, Nickolay Olshevsky via LibrePGP-discuss wrote: > > > I cannot say about the exact number but during my experience on some commercial OpenPGP library we had a lot of clients, including banking, financial and even military, who used to transfer data via automated and semi-automated processes, and it included usage of filename/mtime in the literal data packet. And even in the 2008-2010 those processes were already running for years and I doubt that something would rapidly change there if change at all. Thanks, Nickolay. So at this point my understanding is: 1. It is desirable to protect the literal metadata 2. v5 sigs differ from other versions because they include the metadata (for 0x0 and 0x1 sig types only) 3. Gnupg/librepgp would like to implement v6 sigs but will not do so without metadata protection 4. A method exists (subpacket 40) to add metadata protection to v4 sigs 5. A similar method could be used to add metadata protection to v6 sigs Please correct me if any of the above are inaccurate? A From wk at gnupg.org Mon Jan 8 09:19:57 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jan 2024 09:19:57 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> (Andrew Gallagher via LibrePGP-discuss's message of "Sun, 7 Jan 2024 18:28:10 +0000") References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> Message-ID: <87le901bki.fsf@jacob.g10code.de> On Sun, 7 Jan 2024 18:28, Andrew Gallagher said: > 3. Gnupg/librepgp would like to implement v6 sigs but will not do so > without metadata protection The only reason for this is to allow for a longer subpacket area. This _might_ eventually be useful but I am not sure whether this will be needed any time soon. This is why I tried to implement this and at that opportunity figured that the meta data hashing was removed. Shalom-Salam, 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 andrewg at andrewg.com Mon Jan 8 11:04:04 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 8 Jan 2024 10:04:04 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87le901bki.fsf@jacob.g10code.de> References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> <87le901bki.fsf@jacob.g10code.de> Message-ID: <45000899-5657-4C32-B18C-D651E187E6FD@andrewg.com> On 8 Jan 2024, at 08:19, Werner Koch wrote: > > On Sun, 7 Jan 2024 18:28, Andrew Gallagher said: > >> 3. Gnupg/librepgp would like to implement v6 sigs but will not do so >> without metadata protection > > The only reason for this is to allow for a longer subpacket area. There is one more reason, and that is to help prevent a schism between implementations. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From o.nickolay at gmail.com Mon Jan 8 12:20:57 2024 From: o.nickolay at gmail.com (Nickolay Olshevsky) Date: Mon, 8 Jan 2024 13:20:57 +0200 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> Message-ID: <5f6e465f-96d5-4e07-9bd1-70c2d7f04a24@gmail.com> Hi Andrew, 1. Yes. 2. Yes. 3. I cannot speak for GnuPG, but Werner already answered this. 4. Yes. 5. Yes, however this brought the following discussion, which, as for me, dramatically overcomplicate things: https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/ On 07.01.2024 20:28, Andrew Gallagher wrote: > So at this point my understanding is: > > 1. It is desirable to protect the literal metadata > 2. v5 sigs differ from other versions because they include the metadata (for 0x0 and 0x1 sig types only) > 3. Gnupg/librepgp would like to implement v6 sigs but will not do so without metadata protection > 4. A method exists (subpacket 40) to add metadata protection to v4 sigs > 5. A similar method could be used to add metadata protection to v6 sigs > > Please correct me if any of the above are inaccurate? > > A -- Best regards, Nickolay Olshevsky o.nickolay at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Mon Jan 8 18:25:21 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 8 Jan 2024 17:25:21 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <5f6e465f-96d5-4e07-9bd1-70c2d7f04a24@gmail.com> References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> <5f6e465f-96d5-4e07-9bd1-70c2d7f04a24@gmail.com> Message-ID: On 8 Jan 2024, at 11:20, Nickolay Olshevsky wrote: > > 5. Yes, however this brought the following discussion, which, as for me, dramatically overcomplicate things:https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/ I agree, which is why I proposed an alternative format for the Literal Data Meta packet in https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-literal-metadata : ? The first octet of the subpacket contents indicates the encoding of the subpacket. A value of 0 indicates Hashed encoding, and a value of 1 indicates Verbatim encoding. The remaining octets of the subpacket are encoding-dependent. ? 3.2. Literal Data Meta (Verbatim) The remainder of the packet contains a verbatim copy of the metadata as specified above. When an implementation has successfully validated a signature containing a Literal Data Meta (Verbatim) subpacket in its hashed-subpackets area, the metadata section of the Literal Data Packet that is signed over MUST be replaced with the copy from the Literal Data Meta subpacket. ? I believe this addresses the technical concerns raised in the linked discussion. It moves the canonical location of the metadata from the beginning of the Literal Data packet to a signature subpacket, but leaves the content unchanged. As a subpacket in the hashed area, it is automatically protected by the signature, and being a verbatim copy it is lossless (and thus re-attachable), unlike the hashed encoding specified by the current librepgp draft. Since it is merely a rearrangement of the fields on the wire, nothing should need to be changed at the application layer - the signature either validates, in which case the subpacket metadata is (transparently) returned to the application instead of the literal packet metadata, or it does not, in which case it should be treated like any other verification failure. (Alternatively, we could put the metadata in a notations subpacket, which would be functionally equivalent but more flexible, and wouldn?t require a new subpacket type) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From o.nickolay at gmail.com Mon Jan 15 17:37:00 2024 From: o.nickolay at gmail.com (Nickolay Olshevsky) Date: Mon, 15 Jan 2024 18:37:00 +0200 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: References: <73c140a2-0e83-47c6-8eaf-82cb988d9579@gmail.com> <4F209A2F-4D82-42A9-B858-CB97FB994D2C@andrewg.com> <5f6e465f-96d5-4e07-9bd1-70c2d7f04a24@gmail.com> Message-ID: <1e18eebc-874e-41a3-8133-7f19ea9fec7d@gmail.com> Hi Andrew, Sorry, somehow missed that draft (it's easy to miss things at Jan, 2). As for me it looks good as would solve problems brought up in the list (however, I doubt whether those problems are real). On 08.01.2024 19:25, Andrew Gallagher wrote: > On 8 Jan 2024, at 11:20, Nickolay Olshevsky wrote: >> 5. Yes, however this brought the following discussion, which, as for me, dramatically overcomplicate things:https://mailarchive.ietf.org/arch/msg/openpgp/lqvsd0aw-OiMnpyZSqU_fIqWSCE/ > I agree, which is why I proposed an alternative format for the Literal Data Meta packet in https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-literal-metadata : > > ? > The first octet of the subpacket contents indicates the encoding of the subpacket. A value of 0 indicates Hashed encoding, and a value of 1 indicates Verbatim encoding. The remaining octets of the subpacket are encoding-dependent. > > ? > > 3.2. Literal Data Meta (Verbatim) > > The remainder of the packet contains a verbatim copy of the metadata as specified above. When an implementation has successfully validated a signature containing a Literal Data Meta (Verbatim) subpacket in its hashed-subpackets area, the metadata section of the Literal Data Packet that is signed over MUST be replaced with the copy from the Literal Data Meta subpacket. > ? > > I believe this addresses the technical concerns raised in the linked discussion. It moves the canonical location of the metadata from the beginning of the Literal Data packet to a signature subpacket, but leaves the content unchanged. As a subpacket in the hashed area, it is automatically protected by the signature, and being a verbatim copy it is lossless (and thus re-attachable), unlike the hashed encoding specified by the current librepgp draft. > > Since it is merely a rearrangement of the fields on the wire, nothing should need to be changed at the application layer - the signature either validates, in which case the subpacket metadata is (transparently) returned to the application instead of the literal packet metadata, or it does not, in which case it should be treated like any other verification failure. > > (Alternatively, we could put the metadata in a notations subpacket, which would be functionally equivalent but more flexible, and wouldn?t require a new subpacket type) > > A > -- Best regards, Nickolay Olshevsky o.nickolay at gmail.com From andrewg at andrewg.com Mon Jan 15 19:51:17 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 15 Jan 2024 18:51:17 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <1e18eebc-874e-41a3-8133-7f19ea9fec7d@gmail.com> References: <1e18eebc-874e-41a3-8133-7f19ea9fec7d@gmail.com> Message-ID: <6C3CBCCF-206A-4091-965F-B1578B6377E5@andrewg.com> On 15 Jan 2024, at 16:37, Nickolay Olshevsky wrote: > > Sorry, somehow missed that draft (it's easy to miss things at Jan, 2). Of course! :-) > As for me it looks good as would solve problems brought up in the list (however, I doubt whether those problems are real). Which particular problems do you mean? At least one implementation says they implement reattachment of detached signatures; I?m not sure about the rest though. A From o.nickolay at gmail.com Tue Jan 16 12:48:47 2024 From: o.nickolay at gmail.com (Nickolay Olshevsky) Date: Tue, 16 Jan 2024 13:48:47 +0200 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <6C3CBCCF-206A-4091-965F-B1578B6377E5@andrewg.com> References: <1e18eebc-874e-41a3-8133-7f19ea9fec7d@gmail.com> <6C3CBCCF-206A-4091-965F-B1578B6377E5@andrewg.com> Message-ID: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> I mean problems which were brought in the aforementioned thread (quoting Daniel): > - it's not clear how to populate the fields in an encrypt-then-sign > scenario > - they make it impossible to be able to cleanly detach and reattach > signatures > - when those fields are sometimes signed (v5) and sometimes not (v4), > it's difficult to act on them safely All of these may be resolved on implementation level, not the standard level. From my side there are no additional problems: compared with rfc 4880, where literal fields are not signed at all, this brings at least no less security. On 15.01.2024 20:51, Andrew Gallagher wrote: >> As for me it looks good as would solve problems brought up in the list (however, I doubt whether those problems are real). > Which particular problems do you mean? At least one implementation says they implement reattachment of detached signatures; I?m not sure about the rest though. > > A -- Best regards, Nickolay Olshevsky o.nickolay at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jan 16 18:19:30 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jan 2024 18:19:30 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> (Nickolay Olshevsky via LibrePGP-discuss's message of "Tue, 16 Jan 2024 13:48:47 +0200") References: <1e18eebc-874e-41a3-8133-7f19ea9fec7d@gmail.com> <6C3CBCCF-206A-4091-965F-B1578B6377E5@andrewg.com> <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> Message-ID: <87edehnql9.fsf@jacob.g10code.de> Hi! although I don't want to open such a discussion again, here is my stance on the items obviously raised in the IETF WG: >> - it's not clear how to populate the fields in an encrypt-then-sign >> scenario Why? There is still a literal data packet even if that is first encrypted. Nothing than a hash of that data leaks - and if you don't want that use dummy meta data (i.e. those you would also use when you read from a pipe). >> - they make it impossible to be able to cleanly detach and reattach >> signatures It does not as long as the meta data is the same. And protecting the meta data of the literal data packet is the whole point of the exercise. If that is about an oddity in PGP/MIME where you can try to convert a plain signature into a PGP/MIME signature, it is good if that can be inhibited. After all it only worked in certain situations (depending on the canonization of line endings) and this method was never suggested. >> - when those fields are sometimes signed (v5) and sometimes not (v4), >> it's difficult to act on them safely Improving the security of a protocol takes time and is not easy. But it is better to provide the mechanisms now so that they can be used in the future. > All of these may be resolved on implementation level, not the standard > level. Right. 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 andrewg at andrewg.com Wed Jan 17 09:37:10 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2024 08:37:10 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87edehnql9.fsf@jacob.g10code.de> References: <87edehnql9.fsf@jacob.g10code.de> Message-ID: <90CE625F-688A-4309-A181-29BD2FBF5A8B@andrewg.com> On 16 Jan 2024, at 17:19, Werner Koch wrote: > > >>> - they make it impossible to be able to cleanly detach and reattach >>> signatures > > It does not as long as the meta data is the same. How to ensure that it stays the same is the real trick though. Putting it in a signature subpacket guarantees that it is always available and correct, no matter what transformations are done. A From andrewg at andrewg.com Wed Jan 17 09:58:06 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2024 08:58:06 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> Message-ID: On 16 Jan 2024, at 11:48, Nickolay Olshevsky wrote: > > From my side there are no additional problems: compared with rfc 4880, where literal fields are not signed at all, this brings at least no less security. The metadata signing in v5 sigs is sufficient in itself, however we also have to consider the Obeneur downgrade attack, which forces us to drop support for v3 sigs in order to safely handle v5 sigs. It is obviously easier to port metadata protection to v6 than to fix the downgrade attack in v5, and v3 sigs are still widespread in the wild - rpm was generating them until last year, and there are thousands of published v4 keys containing v3 sbinds. A From wk at gnupg.org Wed Jan 17 17:39:10 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2024 17:39:10 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: (Andrew Gallagher via LibrePGP-discuss's message of "Wed, 17 Jan 2024 08:58:06 +0000") References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> Message-ID: <87zfx3nccx.fsf@jacob.g10code.de> On Wed, 17 Jan 2024 08:58, Andrew Gallagher said: > drop support for v3 sigs in order to safely handle v5 sigs. It is > obviously easier to port metadata protection to v6 than to fix the In LibrePGP we don't support v6. Period. > rpm was generating them until last year, and there are thousands of > published v4 keys containing v3 sbinds. v3 signature don't have subpackets and thus they can't be used to create v4 keys. v3 keys are anyway deprecated and in GnuPG there is even no more support for them. 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 wk at gnupg.org Wed Jan 17 17:40:39 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2024 17:40:39 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <90CE625F-688A-4309-A181-29BD2FBF5A8B@andrewg.com> (Andrew Gallagher's message of "Wed, 17 Jan 2024 08:37:10 +0000") References: <87edehnql9.fsf@jacob.g10code.de> <90CE625F-688A-4309-A181-29BD2FBF5A8B@andrewg.com> Message-ID: <87v87rncag.fsf@jacob.g10code.de> On Wed, 17 Jan 2024 08:37, Andrew Gallagher said: > How to ensure that it stays the same is the real trick though. Putting > it in a signature subpacket guarantees that it is always available and > correct, no matter what transformations are done. Transformations are what signatures should detect. Shalom-Salam, 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 andrewg at andrewg.com Wed Jan 17 17:54:58 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2024 16:54:58 +0000 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87zfx3nccx.fsf@jacob.g10code.de> References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> Message-ID: <56A26383-EA84-440D-B07A-42B92A49C087@andrewg.com> On 17 Jan 2024, at 16:39, Werner Koch wrote: > > On Wed, 17 Jan 2024 08:58, Andrew Gallagher said: > >> drop support for v3 sigs in order to safely handle v5 sigs. It is >> obviously easier to port metadata protection to v6 than to fix the > > In LibrePGP we don't support v6. Period. That?s not what it says in draft-koch-librepgp-00 section 5.2.3: > The body of a V4, V5, and V6 Signature packet contains: > ? One-octet version number. This is 4 for V4 signatures, 5 for V5 signatures, and 6 vor V6 signature. https://datatracker.ietf.org/doc/html/draft-koch-librepgp#section-5.2.3 >> rpm was generating them until last year, and there are thousands of >> published v4 keys containing v3 sbinds. > > v3 signature don't have subpackets and thus they can't be used to create > v4 keys. v3 keys are anyway deprecated and in GnuPG there is even no > more support for them. Encryption subkey sbinds don?t need subpackets (they can?t generate primary key binding sigs), and I recently had to soft-fork go-crypto in order to correctly parse wild v4 keys containing v3 encryption subkey sbinds. Yes, v3 keys are deprecated but v3 signatures will (unfortunately) be with us for some time yet. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Jan 17 18:07:38 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jan 2024 18:07:38 +0100 Subject: Reading new key packages In-Reply-To: <56A26383-EA84-440D-B07A-42B92A49C087@andrewg.com> (Andrew Gallagher's message of "Wed, 17 Jan 2024 16:54:58 +0000") References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> <56A26383-EA84-440D-B07A-42B92A49C087@andrewg.com> Message-ID: <87il3rnb1h.fsf_-_@jacob.g10code.de> On Wed, 17 Jan 2024 16:54, Andrew Gallagher said: > Encryption subkey sbinds don?t need subpackets (they can?t generate > primary key binding sigs), and I recently had to soft-fork go-crypto Huh? How do you specify an expiration date or key usage? Any software which does this is bogus. It 26 years since the introduction of v4 signatures. All that old stuff anyway used MD5 which we should not use anymore. 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 andrewg at andrewg.com Wed Jan 17 18:24:38 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jan 2024 17:24:38 +0000 Subject: Reading new key packages In-Reply-To: <87il3rnb1h.fsf_-_@jacob.g10code.de> References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> <56A26383-EA84-440D-B07A-42B92A49C087@andrewg.com> <87il3rnb1h.fsf_-_@jacob.g10code.de> Message-ID: <6155BAEB-53C4-4C65-AA41-D04AD20E3D73@andrewg.com> On 17 Jan 2024, at 17:07, Werner Koch wrote: > > On Wed, 17 Jan 2024 16:54, Andrew Gallagher said: > >> Encryption subkey sbinds don?t need subpackets (they can?t generate >> primary key binding sigs), and I recently had to soft-fork go-crypto > > Huh? How do you specify an expiration date or key usage? You don?t. And yet such keys exist. I'm as shocked as you. https://github.com/hockeypuck/hockeypuck/issues/205 > Any software > which does this is bogus. It 26 years since the introduction of v4 > signatures. All that old stuff anyway used MD5 which we should not use > anymore. It?s certainly true that people _shouldn?t_ be using them. But this is OpenPGP after all? :-( A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Thu Jan 18 08:43:46 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Jan 2024 08:43:46 +0100 Subject: Reading new key packages In-Reply-To: <6155BAEB-53C4-4C65-AA41-D04AD20E3D73@andrewg.com> (Andrew Gallagher's message of "Wed, 17 Jan 2024 17:24:38 +0000") References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> <56A26383-EA84-440D-B07A-42B92A49C087@andrewg.com> <87il3rnb1h.fsf_-_@jacob.g10code.de> <6155BAEB-53C4-4C65-AA41-D04AD20E3D73@andrewg.com> Message-ID: <87edefm6h9.fsf@jacob.g10code.de> On Wed, 17 Jan 2024 17:24, Andrew Gallagher said: > You don?t. And yet such keys exist. I'm as shocked as you. Probably due to Disastry's hacked up pgp 2. Shalom-Salam, 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 heiko at schaefer.name Thu Jan 18 22:10:32 2024 From: heiko at schaefer.name (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Thu, 18 Jan 2024 22:10:32 +0100 Subject: Reading new key packages (Re: Coexistence with OpenPGP/IETF) In-Reply-To: <87zfx3nccx.fsf@jacob.g10code.de> References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> Message-ID: <8a73309b-f600-41f2-9986-861036456de8@schaefer.name> Hello Werner, On 1/17/24 17:39, Werner Koch via LibrePGP-discuss wrote: > In LibrePGP we don't support v6. Period. Apologies for this additional inquiry. I'd like to understand your perspective and plans a bit better: My current understanding is that GnuPG has opted to take the LibrePGP route, as outlined in draft-koch-librepgp-00, in order to roll out new features quickly, by making only relatively small and incremental changes. I can see the reasoning behind this. Also, I fully agree that the LibrePGP draft should not include specifications for v6 artifacts. However, as an independent question, I wonder if GnuPG might in the future consider including some support for formats from draft-ietf-openpgp-crypto-refresh. For example enabling GnuPG users to verify signatures made by crypto-refresh users? Thank you, Heiko From wk at gnupg.org Fri Jan 19 09:47:26 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Jan 2024 09:47:26 +0100 Subject: Reading new key packages In-Reply-To: <8a73309b-f600-41f2-9986-861036456de8@schaefer.name> ("Heiko =?utf-8?Q?Sch=C3=A4fer?= via LibrePGP-discuss"'s message of "Thu, 18 Jan 2024 22:10:32 +0100") References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> <8a73309b-f600-41f2-9986-861036456de8@schaefer.name> Message-ID: <87plxxlnfl.fsf_-_@jacob.g10code.de> Hi Heiko, On Thu, 18 Jan 2024 22:10, Heiko Sch?fer said: > draft-ietf-openpgp-crypto-refresh. For example enabling GnuPG users to > verify signatures made by crypto-refresh users? Actually I tried to implement that and even have some wording in the latest LibrePGP draft for this. However, I had stopped this effort after I realized that the crypto-refresh dropped that bug fix to cover the meta data from the literal data packet by the signature. If we would implement that we need to do this if (signature version < 5 or is 6 and has meta data) Print warning that meta data is not protected else No need to print a warning becuase it is covered by the signature. Further the presence of a signature salt would also render the signature bad given that GnuPG tries to help organizations to protect their communication also from insiders by minimizing covert channels. The involved complexity for the above check is not that high so, thus it might eventually be done. 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 andrewg at andrewg.com Fri Jan 19 15:11:54 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 19 Jan 2024 14:11:54 +0000 Subject: Reading new key packages In-Reply-To: <87plxxlnfl.fsf_-_@jacob.g10code.de> References: <4e8c9796-a888-4093-9e62-b5c9122096a5@gmail.com> <87zfx3nccx.fsf@jacob.g10code.de> <8a73309b-f600-41f2-9986-861036456de8@schaefer.name> <87plxxlnfl.fsf_-_@jacob.g10code.de> Message-ID: <0CCEA18D-9A6A-4434-BCA7-330CE76AC812@andrewg.com> On 19 Jan 2024, at 08:47, Werner Koch via LibrePGP-discuss wrote: > > If we would implement that we need to do this > > if (signature version < 5 or is 6 and has meta data) > Print warning that meta data is not protected That sounds reasonable to me, if the metadata is populated with something. In crypto-refresh, it is recommended that the literal packet filename and timestamp fields are not populated, so in practice this warning should not be triggered very often with v6 sigs. > Further the presence of a signature salt would also render the signature > bad given that GnuPG tries to help organizations to protect their > communication also from insiders by minimizing covert channels. How do you currently tackle data leakage in signatures, e.g. via hashed-area subpackets? Would any of these techniques be more broadly applicable? > The involved complexity for the above check is not that high so, thus it > might eventually be done. Would you be willing to accept a patch for this? Thanks, A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Tue Jan 30 10:05:17 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2024 10:05:17 +0100 Subject: From openpgp-2015-rfc4880bis-02 to librepgp-00 Message-ID: <877cjrgpiq.fsf@jacob.g10code.de> Hi! Last November I published an updated draft of openpgp-2015-rfc2015-02 which is named librepgp-00. See https://datatracker.ietf.org/doc/draft-koch-librepgp/ for the actual text and its history. Here comes a description of the changes: - Replaced the term "OpenPGP" by "LibrePGP" and briefliy explained the new name. - Minor copy edits - Added algorithm specific parts for ML-KEM (Kyber) along with a note that this part is still subject to change. - Added brief description of Kyber. This needs to be extended. - Added a note on when a message will be post-quantume secure. - Mentioned version 6 signatures because of its 4 octet subpacket area length headers. Added description of the salt parameter. - Changed the encryption mode number number from a "SHOULD be 2" to a "MUST be 2." That is to make OCB mandatory for the new AEAD packet. - Added reference to FIPS-203. - Moved the former authors into the acknowledgments section. Made Ron and me the current authors. - Credited the authors from the Wussler draft for PQC. All in all these are minor changes except for v6 signature and PQC. My idea with implementing and thus describing the v6 signatures was to only allow a salt of length 0 and thus giving us the opportunity to eventually increase the size of the subpacket areas. Only when implementing this I realized that the hashing of the metadata from the Literal Data Packet had been removed from the v5 signatures. So it turned out that it is not possible to use the v6 specification to increase the size of the subpacket area. I would thus suggest to remove the v6 signature specification and come up with a new signature format only iff we need to increase the subpacket area size. The PQC things are just a start and I will write another mail to discuss it. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- --- previous.txt 2024-01-30 09:08:18.123955859 +0100 +++ current.txt 2024-01-30 09:11:14.155950353 +0100 @@ -3,25 +3,21 @@ Network Working Group W. Koch -Internet-Draft GnuPG e.V. -Obsoletes: 4880, 5581, 6637 (if approved) B. Carlson -Intended status: Standards Track -Expires: 1 December 2023 R.H. Tse - Ribose - D.A. Atkins - - D.K. Gillmor - 30 May 2023 +Internet-Draft g10 Code GmbH +Obsoletes: 4880, 5581, 6637 (if approved) R. H. Tse +Intended status: Standards Track Ribose +Expires: 1 June 2024 29 November 2023 OpenPGP Message Format - draft-koch-openpgp-2015-rfc4880bis-02 + draft-koch-librepgp-00 Abstract - This document specifies the message formats used in OpenPGP. OpenPGP - provides encryption with public-key or symmetric cryptographic - algorithms, digital signatures, compression and key management. + This document specifies the message formats used in OpenPGP. + OpenPGP is an extension of the OpenPGP format which provides + encryption with public-key or symmetric cryptographic algorithms, + digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the @@ -32,8 +28,8 @@ It does, however, discuss implementation issues necessary to avoid security flaws. - This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in - OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). + This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in + OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). Status of This Memo @@ -49,8 +45,8 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 1 December 2023. + This Internet-Draft will expire on 1 June 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the @@ -75,13 +71,19 @@ replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440] [RFC4880]. - This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia - cipher) and RFC 6637 (ECC for OpenPGP). + OpenPGP is fully compatible to the OpenPGP specification it is based + on: RFC 4880 (OpenPGP), RFC 5581 (Camellia cipher), and RFC 6637 (ECC + for OpenPGP). 1.1. Terms + * OpenPGP - This is a term for security software that is based on + OpenPGP with updates for newer algorithms and an advertency to + long-term stability and critical deployments. It is formalized in + this document. + * OpenPGP - This is a term for security software that uses PGP 5 as - a basis, formalized in this document. + a basis. * PGP - Pretty Good Privacy. PGP is a family of software systems developed by Philip R. Zimmermann from which OpenPGP is based. @@ -95,16 +96,18 @@ community. It has new formats and corrects a number of problems in the PGP 2 design. It is referred to here as PGP 5 because that software was the first release of the "PGP 3" code base. + * GnuPG - GNU Privacy Guard, also called GPG, is the leading Open - Source implementation of OpenPGP and has been developed along with - the OpenPGP standard since 1997. + Source implementation of OpenPGP and OpenPGP and has been + developed along with the OpenPGP standard since 1997. - * RNP - Ribose Network PGP is a newer OpenPGP implemention and - prominently used by the mail client Thunderbird. + * RNP - Ribose Network PGP is a newer OpenPGP and OpenPGP + implemention and prominently used by the mail client Thunderbird. "PGP" is a trademark of CA, INC. The use of this, or any other, - marks is solely for identification purposes. The term "OpenPGP" - refers to the protocol described in this and related documents. + marks is solely for identification purposes. The terms "OpenPGP" and + "OpenPGP" refer to the protocol described in this and related + documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -157,8 +160,8 @@ 5. The receiving OpenPGP decrypts the session key using the recipient's private key. - 6. The receiving OpenPGP decrypts the message using the session key. - If the message was compressed, it will be decompressed. + 6. The receiving OpenPGP decrypts the message using the session + key. If the message was compressed, it will be decompressed. With symmetric-key encryption, an object may be encrypted with a symmetric key derived from a passphrase (or other shared secret), or @@ -198,8 +201,8 @@ the signature but before encryption. If an implementation does not implement compression, its authors - should be aware that most OpenPGP messages in the world are - compressed. Thus, it may even be wise for a space-constrained + should be aware that most OpenPGP and OpenPGP messages in the world + are compressed. Thus, it may even be wise for a space-constrained implementation to implement decompression, but not compression. Furthermore, compression has the added side effect that some types of @@ -345,7 +348,7 @@ key. If the hash size is less than the key size, multiple instances of the - hash context are created -- enough to produce the required key data. + hash context are created --- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two @@ -357,11 +360,10 @@ hashed, the output data from the multiple hashes is concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded. - 3.7.1.2. Salted S2K - This includes a "salt" value in the S2K specifier -- some arbitrary - data -- that gets hashed along with the passphrase string, to help + This includes a "salt" value in the S2K specifier --- some arbitrary + data --- that gets hashed along with the passphrase string, to help prevent dictionary attacks. Octet 0: 0x01 @@ -442,14 +445,14 @@ These are followed by an Initial Vector of the same length as the block size of the cipher for the decryption of the secret values, if they are encrypted, and then the secret-key values themselves. - 3.7.2.2. Symmetric-Key Message Encryption - OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet - at the front of a message. This is used to allow S2K specifiers to - be used for the passphrase conversion or to create messages with a - mix of symmetric-key ESKs and public-key ESKs. This allows a message - to be decrypted either with a passphrase or a public-key pair. + OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) + packet at the front of a message. This is used to allow S2K + specifiers to be used for the passphrase conversion or to create + messages with a mix of symmetric-key ESKs and public-key ESKs. This + allows a message to be decrypted either with a passphrase or a + public-key pair. PGP 2 always used IDEA with Simple string-to-key conversion when encrypting a message with a symmetric algorithm. This is deprecated, @@ -465,7 +469,8 @@ tag specifying its meaning. An OpenPGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other OpenPGP packets (for example, a - compressed data packet, when uncompressed, contains OpenPGP packets). + compressed data packet, when uncompressed, contains OpenPGP + packets). Each packet consists of a packet header, followed by the packet body. The packet header is of variable length. @@ -723,10 +727,27 @@ Algorithm-Specific Fields for ECDH encryption: - MPI of an EC point representing an ephemeral public key. - - a one-octet size, followed by a symmetric key encoded using the method described in Section 13.5. + Algorithm-Specific Fields for ML-KEM (Kyber) encryption: {Note: + This part is not finalized and subject to change} + + - A fixed-length octet string representing an ECC ephemeral + public key in the format associated with the curve. For ML- + KEM-768+X25519 these are 32 octets, for ML-KEM-1024+X448 these + are 56 octets. + + - A fixed-length octet string of the ML-KEM ciphertext, whose + length depends on the algorithm. For ML-KEM-768+X25519 these + are 1088 octets, for ML-KEM-1024+X448 these are 1568 octets. + + - A one-octet algorithm identifier which must indicate one of the + AES algorithms (7, 8, or 9). + + - a one-octet size, followed by a symmetric key wrapped using the + method described in Section 14.1. + The value "m" in the above formulas is derived from the session key as follows. First, the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption @@ -735,17 +756,21 @@ sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to - form the "m" value used in the formulas above. See Section 14.1 of + form the "m" value used in the formulas above. See Section 15.1 of this document for notes on OpenPGP's use of PKCS#1. + Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, - the implementation MUST make a new PKCS#1 encoding for each key. + the implementation MUST make a new PKCS#1 encoding or for each key. An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages. + Note that the confidentiality of a message is only post-quantum + secure when encrypting to multiple recipients iff only ML-KEM + algorithms are used for all recipients. 5.2. Signature Packet (Tag 2) A Signature packet describes a binding between some public key and @@ -753,14 +778,15 @@ block of text, and a signature that is a certification of a User ID. Three versions of Signature packets are defined. Version 3 provides - basic signature information, while versions 4 and 5 provide an + basic signature information, while versions 4, 5, and 6 provide an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures. Implementations MUST generate version 5 signatures when using a - version 5 key. Implementations SHOULD generate V4 signatures with - version 4 keys. Implementations MUST NOT create version 3 - signatures; they MAY accept version 3 signatures. + version 5 key. Version 6 signature MAY be generated if larger + subpacket data needs to be used. Implementations SHOULD generate V4 + signatures with version 4 keys. Implementations MUST NOT create + version 3 signatures; they MAY accept version 3 signatures. 5.2.1. Signature Types @@ -804,22 +829,25 @@ 0x13 Positive certification of a User ID and Public-Key packet. The issuer of this certification has done substantial verification of - the claim of identity. Most OpenPGP implementations make their - "key signatures" as 0x10 certifications. Some implementations can - issue 0x11-0x13 certifications, but few differentiate between the - types. + the claim of identity. + + Most OpenPGP implementations make their "key signatures" as 0x10 + certifications. Some implementations can issue 0x11-0x13 + certifications, but few differentiate between the types. 0x16 Attested Key Signature. This signature is issued by the primary key over itself and its User ID (or User Attribute). It MUST contain an "Attested Certifications" subpacket and a "Signature Creation Time" subpacket. This type of key signature does not replace or override any standard certification - (0x10-0x13). Only the most recent Attestation Key Signature is - valid for any given pair. If more than one - Certification Attestation Key Signature is present with the same - Signature Creation Time, the set of attestations should be treated - as the union of all "Attested Certifications" subpackets from all - such signatures with the same timestamp. + (0x10-0x13). + + Only the most recent Attestation Key Signature is valid for any + given pair. If more than one Certification + Attestation Key Signature is present with the same Signature + Creation Time, the set of attestations should be treated as the + union of all "Attested Certifications" subpackets from all such + signatures with the same timestamp. 0x18 Subkey Binding Signature. This signature is a statement by the top-level signing key that indicates that it owns the subkey. @@ -992,10 +1020,10 @@ 5.2.3. Version 4 and 5 Signature Packet Formats - The body of a V4 or V5 Signature packet contains: + The body of a V4, V5, and V6 Signature packet contains: - * One-octet version number. This is 4 for V4 signatures and 5 for - V5 signatures. + * One-octet version number. This is 4 for V4 signatures, 5 for V5 + signatures, and 6 vor V6 signature. * One-octet signature type. @@ -1003,21 +1031,30 @@ * One-octet hash algorithm. * Two-octet scalar octet count for following hashed subpacket data. - Note that this is the length in octets of all of the hashed - subpackets; a pointer incremented by this number will skip over - the hashed subpackets. + For V6 signatures this is a four-octet field. Note that this is + the length in octets of all of the hashed subpackets; a pointer + incremented by this number will skip over the hashed subpackets. * Hashed subpacket data set (zero or more subpackets). * Two-octet scalar octet count for the following unhashed subpacket - data. Note that this is the length in octets of all of the - unhashed subpackets; a pointer incremented by this number will - skip over the unhashed subpackets. + data. For V6 signatures this is a four-octet field. Note that + this is the length in octets of all of the unhashed subpackets; a + pointer incremented by this number will skip over the unhashed + subpackets. * Unhashed subpacket data set (zero or more subpackets). * Two-octet field holding the left 16 bits of the signed hash value. + * Only for V6 signatures, a variable-length field containing: + + - A one-octet salt size. If salted signatures are used the value + SHOULD match the digest length of the hash algorithm. The + common use case is not to use salted signatures. + + - The salt; a random value of the specified size. + * One or more multiprecision integers comprising the signature. This portion is algorithm specific: @@ -1436,15 +1472,16 @@ (1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets of fingerprint) - V4 keys use the full 20 octet fingerprint; V5 keys use the full 32 - octet fingerprint - + V4 keys use the full 20 octet fingerprint; V4 keys with the Class + octet bit 0x20 set use the extended 32 octet v4 fingerprint; V5 keys + use the full 32 octet fingerprint. Authorizes the specified key to issue revocation signatures for this key. Class octet must have bit 0x80 set. If the bit 0x40 is set, - then this means that the revocation information is sensitive. Other - bits are for future expansion to other kinds of authorizations. This - is only found on a direct-key self-signature (type 0x1f). The use on - other types of self-signatures is unspecified. + then this means that the revocation information is sensitive. Bit + 0x20 is used as described above. Other bits are for future expansion + to other kinds of authorizations. This is only found on a direct-key + self-signature (type 0x1f). The use on other types of self- + signatures is unspecified. If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world @@ -1634,8 +1671,9 @@ subpacket applies only to User ID packets. When appearing on a self- signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is to say, there are two different and - independent "primaries" -- one for User IDs, and one for User + independent "primaries" --- one for User IDs, and one for User Attributes. + 5.2.3.22. Policy URI (String) @@ -1681,15 +1718,16 @@ The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on - who is making the statement -- for example, a certification signature - that has the "sign data" flag is stating that the certification is - for that use. On the other hand, the "communications encryption" - flag in a self-signature is stating a preference that a given key be - used for communications. Note however, that it is a thorny issue to - determine what is "communications" and what is "storage". This - decision is left wholly up to the implementation; the authors of this - document do not claim any special wisdom on the issue and realize - that accepted opinion may change. + who is making the statement --- for example, a certification + signature that has the "sign data" flag is stating that the + certification is for that use. On the other hand, the + "communications encryption" flag in a self-signature is stating a + preference that a given key be used for communications. Note + however, that it is a thorny issue to determine what is + "communications" and what is "storage". This decision is left wholly + up to the implementation; the authors of this document do not claim + any special wisdom on the issue and realize that accepted opinion may + change. The "split key" (1st,0x10) and "group key" (1st,0x80) flags are placed on a self-signature only; they are meaningless on a @@ -1928,9 +1967,8 @@ of class 0x00, 0x01, or 0x02. It MUST contain the key used to create the signature; either as the primary key or as a subkey. The key SHOULD contain a primary or subkey capable of encryption and the - entire key must be a valid OpenPGP key including at least one User ID - packet and the corresponding self-signatures. - + entire key must be a valid OpenPGP key including at least one User + ID packet and the corresponding self-signatures. Implementations MUST ignore this subpacket if the first octet does not have a value of zero or if the key data does not represent a valid transferable public key. @@ -1960,6 +1999,8 @@ All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. + When a V6 signature with a salt is made, the salt is hashed first. + For binary document signatures (type 0x00), the document data is hashed directly. For text document signatures (type 0x01), the document is canonicalized by converting line endings to , and @@ -1967,16 +2008,15 @@ When a V4 signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body - of the key packet; when a V5 signature is made over a key, the hash - data starts with the octet 0x9a, followed by a four-octet length of - the key, and then body of the key packet. A subkey binding signature - (type 0x18) or primary key binding signature (type 0x19) then hashes - the subkey using the same format as the main key (also using 0x99 or - 0x9a as the first octet). Primary key revocation signatures (type - 0x20) hash only the key being revoked. Subkey revocation signature - (type 0x28) hash first the primary key and then the subkey being - revoked. - + of the key packet; when a V5 or V6 signature is made over a key, the + hash data starts with the octet 0x9a for V5 and 0x9b for V6, followed + by a four-octet length of the key, and then body of the key packet. + A subkey binding signature (type 0x18) or primary key binding + signature (type 0x19) then hashes the subkey using the same format as + the main key (also using 0x99 or 0x9a as the first octet). Primary + key revocation signatures (type 0x20) hash only the key being + revoked. Subkey revocation signature (type 0x28) hash first the + primary key and then the subkey being revoked. A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute @@ -2022,10 +2063,9 @@ - the hashed subpacket body, - the two octets 0x04 and 0xFF, - - a four-octet big-endian number that is the length of the hashed data from the Signature packet stopping right before the 0x04, - 0xff octets. + 0XFF octets. The four-octet big-endian number is considered to be an unsigned integer modulo 2^32. @@ -2047,23 +2088,20 @@ - Only for document signatures (type 0x00 or 0x01) the following three data items are hashed here: - - o the one-octet content format, - - o the file name as a string (one octet length, followed by the - file name), - - o a four-octet number that indicates a date, - + - the one-octet content format, + - the file name as a string (one octet length, followed by + the file name), + - a four-octet number that indicates a date, - the two octets 0x05 and 0xFF, - - a eight-octet big-endian number that is the length of the - hashed data from the Signature packet stopping right before the - 0x05, 0xff octets. - - The three data items hashed for document signatures need to - mirror the values of the Literal Data packet. For detached and - cleartext signatures 6 zero bytes are hashed instead. + - a eight-octet big-endian number that is the length + of the hashed data from the Signature packet + stopping right before the 0x05, 0XFF octets. + + The three data items hashed for document signatures need to mirror + the values of the Literal Data packet. Note that for a detached + signatures this means to hash 6 0x00 octets and for a cleartext + signature this means to hash a 't' followed by 5 0x00 octets. After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at @@ -2082,7 +2119,7 @@ generous in what they accept, while putting pressure on a creator to be stingy in what they generate. - Some apparent conflicts may actually make sense -- for example, + Some apparent conflicts may actually make sense --- for example, suppose a keyholder has a V3 key and a V4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an @@ -2142,7 +2179,7 @@ * A one-octet cipher algorithm. - * A one-octet encryption mode number which SHOULD be 2 to indicate + * A one-octet encryption mode number which MUST be 2 to indicate OCB. * A string-to-key (S2K) specifier, length as defined above. @@ -2175,7 +2211,8 @@ The body of this packet consists of: - * A one-octet version number. The current version is 3. + * A one-octet version number. The currently specified versions are + 3 and 6. * A one-octet signature type. Signature types are described in Section 5.2.1. @@ -2179,11 +2216,26 @@ * A one-octet signature type. Signature types are described in Section 5.2.1. + * A one-octet number describing the hash algorithm used. * A one-octet number describing the public-key algorithm used. - * An eight-octet number holding the Key ID of the signing key. + * Only for V6 signatures, a variable-length field containing: + + - A one-octet salt size. If salted signatures are used the value + SHOULD match the digest length of the hash algorithm. The + common use case is not to use salted signatures. + + - The salt; a random value of the specified size. The value MUST + match the salt field of the corresponding Signature packet. + + * Only for V3 signatures: an eight-octet number holding the Key ID + of the signing key. + + * Only for V6 sigmatures: a one octet key version number and N + octets of the fingerprint of the signing key. Note that the + length N of the fingerprint for a version 6 key is 32. * A one-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another @@ -2537,6 +2588,35 @@ * MPI of an integer representing the secret key, which is a scalar of the public EC point. + +5.6.7. Algorithm-Specific Part for ML-KEM Keys + + {Note: This part is not finalized and subject to change} + + The public key is this series of values: + + * A fixed-length octet string representing an ECC public key in the + format associated with the curve. For ML-KEM-768+X25519 these are + 32 octets, for ML-KEM-1024+X448 these are 56 octets. + + * A fixed-length octet string containing the ML-KEM public key, + whose length depends on the algorithm. For ML-KEM-768+X25519 + these are 1184 octets, for ML-KEM-1024+X448 these are 1568 octets. + + The secret key is this series of values: + + * A fixed-length octet string of the encoded secret scalar, whose + encoding and length depend on the algorithm. For ML-KEM- + 768+X25519 these are 32 octets, for ML-KEM-1024+X448 these are 56 + octets. + + * A fixed-length octet string containing the ML-KEM secret key, + whose length depends on the algorithm. For ML-KEM-768+X25519 + these are 2400 octets, for ML-KEM-1024+X448 these are 3168 octets. + + Observe that the format of the ECC keys differ from the format used + with ECDH. This has been chosen to avoid prefix octets. + 5.7. Compressed Data Packet (Tag 8) The Compressed Data packet contains compressed data. Typically, this @@ -2769,10 +2849,9 @@ examination of the image data if it is unable to handle a particular version of the image header or if a specified encoding format value is not recognized. - 5.13.2. User ID Attribute Subpacket - A User ID Attribute subpacket has type [IANA -- assignment TBD1]. + A User ID Attribute subpacket has type [IANA --- assignment TBD1]. A User ID Attribute subpacket, just like a User ID packet, consists of UTF-8 text that is intended to represent the name and email @@ -2790,8 +2869,8 @@ The Symmetrically Encrypted Integrity Protected Data packet is a variant of the Symmetrically Encrypted Data packet. It is a new - feature created for OpenPGP that addresses the problem of detecting a - modification to encrypted data. It is used in combination with a + feature created for OpenPGP that addresses the problem of detecting + a modification to encrypted data. It is used in combination with a Modification Detection Code packet. There is a corresponding feature in the features Signature subpacket @@ -3138,10 +3215,10 @@ 6.2. Forming ASCII Armor When OpenPGP encodes data into ASCII Armor, it puts specific headers - around the Radix-64 encoded data, so OpenPGP can reconstruct the data - later. An OpenPGP implementation MAY use ASCII armor to protect raw - binary data. OpenPGP informs the user what kind of data is encoded - in the ASCII armor through the use of the headers. + around the Radix-64 encoded data, so OpenPGP can reconstruct the + data later. An OpenPGP implementation MAY use ASCII armor to + protect raw binary data. OpenPGP informs the user what kind of data + is encoded in the ASCII armor through the use of the headers. Concatenating the following data creates ASCII Armor: * An Armor Header Line, appropriate for the type of data @@ -3183,17 +3260,17 @@ line. That is to say, there is always a line ending preceding the starting five dashes, and following the ending five dashes. The header lines, therefore, MUST start at the beginning of a line, and - MUST NOT have text other than whitespace -- space (0x20), tab (0x09) - or carriage return (0x0d) -- following them on the same line. These + MUST NOT have text other than whitespace --- space (0x20), tab (0x09) + or carriage return (0x0d) --- following them on the same line. These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see below). The Armor Headers are pairs of strings that can give the user or the - receiving OpenPGP implementation some information about how to decode - or use the message. The Armor Headers are a part of the armor, not a - part of the message, and hence are not protected by any signatures - applied to the message. + receiving OpenPGP implementation some information about how to + decode or use the message. The Armor Headers are a part of the + armor, not a part of the message, and hence are not protected by any + signatures applied to the message. The format of an Armor Header is that of a key-value pair. A colon (: 0x38) and a single space (0x20) separate the key and value. @@ -3214,9 +3291,9 @@ * "Version", which states the OpenPGP implementation and version used to encode the message. - * "Comment", a user-defined comment. OpenPGP defines all text to be - in UTF-8. A comment may be any UTF-8 string. However, the whole - point of armoring is to provide seven-bit-clean data. + * "Comment", a user-defined comment. OpenPGP defines all text to + be in UTF-8. A comment may be any UTF-8 string. However, the + whole point of armoring is to provide seven-bit-clean data. Consequently, if a comment has characters that are outside the US- ASCII range of UTF, they may very well not survive transport. @@ -3431,9 +3508,9 @@ "- " if it occurs at the beginning of a line, and SHOULD warn on "-" and any character other than a space at the beginning of a line. - Also, any trailing whitespace -- spaces (0x20), tabs (0x09) or - carriage returns (0x0d) -- at the end of any line is removed when the - cleartext signature is generated and verified. + Also, any trailing whitespace --- spaces (0x20), tabs (0x09) or + carriage returns (0x0d) --- at the end of any line is removed when + the cleartext signature is generated and verified. 8. Regular Expressions @@ -3479,36 +3556,37 @@ 9.1. Public-Key Algorithms - +=========+===================================================+ + +=======+===================================================+ | ID | Algorithm | - +=========+===================================================+ + +=======+===================================================+ | 1 | RSA (Encrypt or Sign) [HAC] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 2 | RSA Encrypt-Only [HAC] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 3 | RSA Sign-Only [HAC] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 18 | ECDH public key algorithm | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 19 | ECDSA public key algorithm [FIPS186] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 20 | Reserved (formerly Elgamal Encrypt or Sign) | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 21 | Reserved for Diffie-Hellman (X9.42, as defined | | | for IETF-S/MIME) | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 22 | EdDSA [RFC8032] | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 23 | Reserved for AEDH | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ | 24 | Reserved for AEDSA | - +---------+---------------------------------------------------+ - | 100-110 | Private/Experimental algorithm | - +---------+---------------------------------------------------+ + +-------+---------------------------------------------------+ + | 100-- | Private/Experimental algorithm | + | 110 | | + +-------+---------------------------------------------------+ Table 6 @@ -3517,8 +3595,8 @@ implement EdDSA (22) keys. RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD - NOT be generated, but may be interpreted. See Section 14.5. See - Section 14.9 for notes on Elgamal Encrypt or Sign (20), and X9.42 + NOT be generated, but may be interpreted. See Section 15.5. See + Section 15.9 for notes on Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm. Note that implementations conforming to previous versions of this @@ -3587,44 +3665,46 @@ 9.3. Symmetric-Key Algorithms - +=========+======================================+ + +=======+======================================+ | ID | Algorithm | - +=========+======================================+ + +=======+======================================+ | 0 | Plaintext or unencrypted data | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 1 | IDEA [IDEA] | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 2 | TripleDES (DES-EDE, [SCHNEIER] [HAC] | | | - 168 bit key derived from 192) | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 3 | CAST5 (128 bit key, as per | | | [RFC2144]) | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 4 | Blowfish (128 bit key, 16 rounds) | | | [BLOWFISH] | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 5 | Reserved | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 6 | Reserved | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 7 | AES with 128-bit key [AES] | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 8 | AES with 192-bit key | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 9 | AES with 256-bit key | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 10 | Twofish with 256-bit key [TWOFISH] | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 11 | Camellia with 128-bit key [RFC3713] | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 12 | Camellia with 192-bit key | - +---------+--------------------------------------+ + +-------+--------------------------------------+ | 13 | Camellia with 256-bit key | - +---------+--------------------------------------+ - | 100-110 | Private/Experimental algorithm | - +---------+--------------------------------------+ + +-------+--------------------------------------+ + | 100-- | Private/Experimental algorithm | + | 110 | | + +-------+--------------------------------------+ Table 8 + Implementations MUST implement AES-128. Implementations SHOULD implement AES-256. Implementations that interoperate with RFC-4880 implementations need to support TripleDES and CAST5. Implementations @@ -3634,19 +3714,19 @@ 9.4. Compression Algorithms - +=========+================================+ + +==========+================================+ | ID | Algorithm | - +=========+================================+ + +==========+================================+ | 0 | Uncompressed | - +---------+--------------------------------+ + +----------+--------------------------------+ | 1 | ZIP [RFC1951] | - +---------+--------------------------------+ + +----------+--------------------------------+ | 2 | ZLIB [RFC1950] | - +---------+--------------------------------+ + +----------+--------------------------------+ | 3 | BZip2 [BZ2] | - +---------+--------------------------------+ - | 100-110 | Private/Experimental algorithm | - +---------+--------------------------------+ + +----------+--------------------------------+ + | 100--110 | Private/Experimental algorithm | + +----------+--------------------------------+ Table 9 @@ -3657,39 +3737,39 @@ 9.5. Hash Algorithms - +=========+================================+=============+ + +==========+================================+=============+ | ID | Algorithm | Text Name | - +=========+================================+=============+ + +==========+================================+=============+ | 1 | MD5 [HAC] | "MD5" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 2 | SHA-1 [FIPS180] | "SHA1" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 4 | Reserved | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 5 | Reserved | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 6 | Reserved | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 7 | Reserved | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 8 | SHA2-256 [FIPS180] | "SHA256" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 9 | SHA2-384 [FIPS180] | "SHA384" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 10 | SHA2-512 [FIPS180] | "SHA512" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 11 | SHA2-224 [FIPS180] | "SHA224" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 12 | SHA3-256 [FIPS202] | "SHA3-256" | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 13 | Reserved | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ | 14 | SHA3-512 [FIPS202] | "SHA3-512" | - +---------+--------------------------------+-------------+ - | 100-110 | Private/Experimental algorithm | | - +---------+--------------------------------+-------------+ + +----------+--------------------------------+-------------+ + | 100--110 | Private/Experimental algorithm | | + +----------+--------------------------------+-------------+ Table 10 @@ -3721,16 +3802,15 @@ of considerations for allocating parameters for extensions. This section describes how IANA should look at extensions to the protocol as described in this document. - { FIXME: Also add forward references, like "The list of S2K specifier types is maintained by IANA as described in Section 10." } 10.1. New String-to-Key Specifier Types - OpenPGP S2K specifiers contain a mechanism for new algorithms to turn - a string into a key. This specification creates a registry of S2K - specifier types. The registry includes the S2K type, the name of the - S2K, and a reference to the defining specification. The initial + OpenPGP S2K specifiers contain a mechanism for new algorithms to + turn a string into a key. This specification creates a registry of + S2K specifier types. The registry includes the S2K type, the name of + the S2K, and a reference to the defining specification. The initial values for this registry can be found in Section 3.7.1. Adding a new S2K specifier MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126]. @@ -3896,13 +3976,13 @@ Adding a new feature-implementation flag MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126]. - Also see Section 14.12 for more information about when feature flags + Also see Section 15.12 for more information about when feature flags are needed. 10.2.4. New Packet Versions - The core OpenPGP packets all have version numbers, and can be revised - by introducing a new version of an existing packet. This + The core OpenPGP packets all have version numbers, and can be + revised by introducing a new version of an existing packet. This specification creates a registry of packet types. The registry includes the packet type, the number of the version, and a reference to the defining specification. The initial values for this registry @@ -3937,7 +4017,7 @@ +====+============================+========================+ | ID | Algorithm | Reference | +====+============================+========================+ - | 22 | EdDSA public key algorithm | This doc, Section 14.8 | + | 22 | EdDSA public key algorithm | This doc, Section 15.8 | +----+----------------------------+------------------------+ | 23 | Reserved for AEDH | This doc | +----+----------------------------+------------------------+ @@ -4084,15 +4164,15 @@ 11.2. Transferable Secret Keys - OpenPGP users may transfer secret keys. The format of a transferable - secret key is the same as a transferable public key except that - secret-key and secret-subkey packets are used instead of the public - key and public-subkey packets. Implementations SHOULD include self- - signatures on any User IDs and subkeys, as this allows for a complete - public key to be automatically extracted from the transferable secret - key. Implementations MAY choose to omit the self-signatures, - especially if a transferable public key accompanies the transferable - secret key. + OpenPGP users may transfer secret keys. The format of a + transferable secret key is the same as a transferable public key + except that secret-key and secret-subkey packets are used instead of + the public key and public-subkey packets. Implementations SHOULD + include self- signatures on any User IDs and subkeys, as this allows + for a complete public key to be automatically extracted from the + transferable secret key. Implementations MAY choose to omit the + self-signatures, especially if a transferable public key accompanies + the transferable secret key. 11.3. OpenPGP Messages @@ -4262,8 +4342,8 @@ f.4) MPI of DSA public-key value y (= g**x mod p where x is secret). - Note that it is possible for there to be collisions of Key IDs -- two - different keys with the same Key ID. Note that there is a much + Note that it is possible for there to be collisions of Key IDs --- + two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint. @@ -4352,7 +4432,7 @@ A key derivation function (KDF) is necessary to implement the EC encryption. The Concatenation Key Derivation Function (Approved Alternative 1) [SP800-56A] with the KDF hash function that is - SHA2-256 [FIPS180] or stronger is REQUIRED. See Section 16 for the + SHA2-256 [FIPS180] or stronger is REQUIRED. See Section 17 for the details regarding the choice of the hash function. For convenience, the synopsis of the encoding method is given below @@ -4430,7 +4510,7 @@ The key wrapping method is described in [RFC3394]. KDF produces a symmetric key that is used as a key-encryption key (KEK) as specified - in [RFC3394]. Refer to Section 15 for the details regarding the + in [RFC3394]. Refer to Section 16 for the details regarding the choice of the KEK algorithm, which SHOULD be one of three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394]. @@ -4531,9 +4611,26 @@ Table 16 -14. Notes on Algorithms +14. Post-Quantum Cryptography -14.1. PKCS#1 Encoding in OpenPGP + {Note: This part is not finalized and subject to change} + + This section descripes algorithms and parameters used with post- + quantum cryptography. Specifically, it defines composite public-key + encryption based on ML-KEM. + +14.1. Kyber Algorithm + + ML-KEM [FIPS203], which is also known as CRYSTALS-Kyber, is based on + the hardness of solving the learning-with-errors problem in module + lattices (MLWE). The scheme is believed to provide security against + cryptanalytic attacks by classical as well as quantum computers. + This specification defines ML-KEM only in composite combination with + ECC-based encryption schemes in order to provide a pre-quantum + security fallback. + +15. Notes on Algorithms +15.1. PKCS#1 Encoding in OpenPGP This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions @@ -4545,7 +4642,8 @@ contained document that avoids problems in the future with needed changes in the conventions. -14.1.1. EME-PKCS1-v1_5-ENCODE +15.1.1. EME-PKCS1-v1_5-ENCODE + Input: k = the length in octets of the key modulus. @@ -4573,8 +4671,7 @@ 4. Output EM. -14.1.2. EME-PKCS1-v1_5-DECODE - +15.1.2. EME-PKCS1-v1_5-DECODE Input: EM = encoded message, an octet string @@ -4595,10 +4692,10 @@ second octet of EM does not have hexadecimal value 0x02, if there is no octet with hexadecimal value 0x00 to separate PS from M, or if the length of PS is less than 8 octets, output "decryption error" and - stop. See also the security note in Section 15 regarding differences + stop. See also the security note in Section 16 regarding differences in reporting between a decryption error and a padding error. -14.1.3. EMSA-PKCS1-v1_5 +15.1.3. EMSA-PKCS1-v1_5 This encoding method is deterministic and only has an encoding operation. @@ -4652,7 +4749,7 @@ 6. Output EM. -14.2. Symmetric Algorithm Preferences +15.2. Symmetric Algorithm Preferences The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts. Since it is found on a self-signature, @@ -4687,7 +4784,7 @@ warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway. -14.3. Other Algorithm Preferences +15.3. Other Algorithm Preferences Other algorithm preferences work similarly to the symmetric algorithm preference, in that they specify which algorithms the keyholder @@ -4695,7 +4792,7 @@ be made about, though, the compression preferences and the hash preferences. -14.3.1. Compression Preferences +15.3.1. Compression Preferences Compression has been an integral part of PGP since its first days. OpenPGP and all previous versions of PGP have offered compression. @@ -4719,7 +4816,7 @@ compressed message, since all implementations can handle messages that have not been compressed. -14.3.2. Hash Algorithm Preferences +15.3.2. Hash Algorithm Preferences Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer rarely knows who is @@ -4735,14 +4832,14 @@ explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. -14.4. Plaintext +15.4. Plaintext Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data. -14.5. RSA +15.5. RSA There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a @@ -4752,7 +4849,7 @@ An implementation SHOULD NOT implement RSA keys of size less than 1024 bits. -14.6. DSA +15.6. DSA An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less @@ -4783,12 +4880,12 @@ able to handle signatures with a different q size or a truncated hash. -14.7. Elgamal +15.7. Elgamal An implementation SHOULD NOT implement Elgamal keys of size less than 1024 bits. -14.8. EdDSA +15.8. EdDSA Although the EdDSA algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message is used as input @@ -4796,7 +4893,7 @@ details. Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm. -14.9. Reserved Algorithm Numbers +15.9. Reserved Algorithm Numbers A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are @@ -4814,7 +4911,7 @@ An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. -14.10. OpenPGP CFB Mode +15.10. OpenPGP CFB Mode OpenPGP does symmetric encryption using a variant of Cipher Feedback mode (CFB mode). This section describes the procedure it uses in @@ -4829,8 +4926,8 @@ index of 1 (unlike the C language, which assumes arrays start with a zero index). - OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and - prefixes the plaintext with BS+2 octets of random data, such that + OpenPGP CFB mode uses an initialization vector (IV) of all zeros, + and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets. @@ -4879,7 +4976,7 @@ the next BS octets of ciphertext. These are loaded into FR, and the process is repeated until the plaintext is used up. -14.11. Private or Experimental Parameters +15.11. Private or Experimental Parameters S2K specifiers, Signature subpacket types, User Attribute types, image format types, and algorithms described in Section 9 all reserve @@ -4891,7 +4988,7 @@ However, implementations need to be careful with these and promote them to full IANA-managed parameters when they grow beyond the original, limited system. -14.12. Meta-Considerations for Expansion +15.12. Meta-Considerations for Expansion If OpenPGP is extended in a way that is not backwards-compatible, meaning that old implementations will not gracefully handle their @@ -4909,7 +5006,7 @@ explanation of why such an extension is unnecessary, the proposal SHOULD be rejected. -15. Security Considerations +16. Security Considerations * As with any technology involving cryptography, you should check the current literature to determine if any algorithms used here @@ -4967,8 +5064,8 @@ small vulnerabilities. For example, if an implementation does not compress a message before encryption (perhaps because it knows it was already compressed), then that message is vulnerable. Because - of this happenstance -- that modification attacks can be thwarted - by decompression errors -- an implementation SHOULD treat a + of this happenstance --- that modification attacks can be thwarted + by decompression errors --- an implementation SHOULD treat a decompression error as a security problem, not merely a data problem. @@ -5152,9 +5249,9 @@ makes sense to combine the ID and image into a single signed packet with a single signature. -16. Compatibility Profiles +17. Compatibility Profiles -16.1. OpenPGP ECC Profile +17.1. OpenPGP ECC Profile A compliant application MUST implement NIST curve P-256, SHOULD implement NIST curve P-521, SHOULD implement brainpoolP256r1 and @@ -5166,7 +5263,7 @@ SHA2-384 and SHA2-512. A compliant application MUST implement AES-128 and SHOULD implement AES-256. - A compliant application SHOULD follow Section 15 regarding the choice + A compliant application SHOULD follow Section 16 regarding the choice of the following algorithms for each curve: * the KDF hash algorithm, @@ -5180,7 +5277,7 @@ It is recommended that the chosen symmetric algorithm for message encryption be no less secure than the KEK algorithm. -17. Implementation Nits +18. Implementation Nits This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous @@ -5246,9 +5343,9 @@ requirement for ASCII armor so those implementations will necessarily have support. -18. References +19. References -18.1. Normative References +19.1. Normative References [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", November 2001, @@ -5286,7 +5383,12 @@ Hash and Extendable-Output Functions, FIPS 202", August 2015, . - [HAC] Menezes, A.J., Oorschot, P.v., and S. Vanstone, "Handbook + [FIPS203] National Institute of Standards and Technology, U.S. + Department of Commerce, "Module-Lattice-Based Key- + Encapsulation Mechanism Standard", August 2023, + . + + [HAC] Menezes, A. J., v Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", 1996. [IDEA] Lai, X., "On the design and security of block ciphers", @@ -5304,87 +5406,87 @@ [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based Cryptography Standard", 25 March 1999. - [RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, - . + . + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, - . + . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, DOI 10.17487/RFC2144, May 1997, - . + . [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001, - . + . [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, - . + . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, - September 2002, . + September 2002, . [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February - 2003, . + 2003, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November - 2003, . - + 2003, . [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, DOI 10.17487/RFC3713, April 2004, - . + . + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, - . + . [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, DOI 10.17487/RFC5639, March 2010, - . + . [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, - . + . [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May - 2014, . + 2014, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January - 2016, . + 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, - . + . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, - . + . [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996. @@ -5394,12 +5496,12 @@ Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 1, March 2007. - [TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, C., and N. Ferguson, "The Twofish Encryption Algorithm", 1999. -18.2. Informative References +19.2. Informative References + [BLEICHENBACHER] Bleichenbacher, D., "Generating ElGamal Signatures Without Knowing the Secret Key", Lecture Notes in Computer @@ -5422,21 +5524,21 @@ [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August - 1996, . + 1996, . [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, - November 1998, . + November 1998, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, - . + . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, - . + . [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", September 2000. @@ -5719,7 +5821,17 @@ * Added alternative OIDs for Ed25519 and Curve25519. -Appendix D. The principal authors of RFC-4880 + Changes since draft-koch-openpgp-2015-rfc4880bis-02: + + * Add ML-KEM parts from draft-wussler-openpgp-pqc-03.txt + + * Changed name of the specification to OpenPGP. +Appendix D. Acknowledgments + + There have been a number of authors involved with the development of + the OpenPGP specification as described by RFC-4880, RFC-5581, and + RFC-6637: + Jon Callas EMail: jon at callas.org @@ -5734,30 +5846,15 @@ Rodney Thayer EMail: rodney at canola-jones.com -Authors' Addresses - - Werner Koch - GnuPG e.V. - Rochusstr. 44 - 40479 Duesseldorf - Germany - Email: wk at gnupg.org - URI: https://gnupg.org/verein + Andrey Jivsov + EMail: Andrey_Jivsov at symantec.com + The work to update RFC-4880 was mainly conducted by the authors of + this document and the following authors: brian m. carlson Email: sandals at crustytoothpaste.net - - Ronald Henry Tse - Ribose - Suite 1111, 1 Pedder Street - Central, Hong Kong - Hong Kong - Email: ronald.tse at ribose.com - URI: https://www.ribose.com - - Derek Atkins Email: derek at ihtfp.com @@ -5761,6 +5858,28 @@ Derek Atkins Email: derek at ihtfp.com - Daniel Kahn Gillmor Email: dkg at fifthhorseman.net + + The PQC algorithm extension was conducted by the following authors: + + Stavros Kousidis + Email: stavros.kousidis at bsi.bund.de + + Falko Strenzke + Email: falko.strenzke at mtg.de + + Aron Wussler + Email: aron at wussler.it + +Authors' Addresses + Werner Koch + g10 Code GmbH + Germany + Email: wk at gnupg.org + + + Ronald Henry Tse + Ribose + Hong Kong + Email: ronald.tse at ribose.com -------------- 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 wk at gnupg.org Tue Jan 30 10:25:04 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2024 10:25:04 +0100 Subject: From openpgp-2015-rfc4880bis-02 to librepgp-00 In-Reply-To: <877cjrgpiq.fsf@jacob.g10code.de> (Werner Koch via LibrePGP-discuss's message of "Tue, 30 Jan 2024 10:05:17 +0100") References: <877cjrgpiq.fsf@jacob.g10code.de> Message-ID: <8734ufgolr.fsf@jacob.g10code.de> Hi! Somehow I lost the comments I planned to insert at the op of the attachment. The attached diff was generated by removing some standard strings: sed '/^[A-Z].*Expires /d;/^Internet-Draft.*PGP/d' \ | awk '/^$/ && skip {skip--;next} /^$/ {count++; next} /\f/ {count=0;skip=2;next} {while (count) {print ""; count--};print}' \ | sed '/^Table of Contents/,/Author.*Address/d' and replacing "LibrePGP" by "OpenPGP" so that the diff is not flooded with this naming change. Don't mind funny things like "OpenPGP and OpenPGP" which is actually "LibrePGP and OpenPGP". 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 bernhard at intevation.de Thu Feb 1 15:15:14 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 1 Feb 2024 15:15:14 +0100 Subject: AEAD differences to v6 (was: Reading new key packages)) In-Reply-To: <87wmsr50mo.fsf@jacob.g10code.de> References: <09c60c89-dca3-49a1-939f-1c3e0a7ed09b@kuix.de> <202401021054.24451.bernhard@intevation.de> <87wmsr50mo.fsf@jacob.g10code.de> Message-ID: <202402011515.14897.bernhard@intevation.de> Am Dienstag 02 Januar 2024 14:24:31 schrieb Werner Koch: > Actually the key format is not the main controversial thing but the AEAD > mode which changed in crypto-refresh-post-fall-2021. Assmuning this means OCB versus EAX and GCM: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/13 Implementations MUST implement OCB. Implementations MAY implement EAX, GCM and other algorithms. https://datatracker.ietf.org/doc/draft-koch-librepgp/00/ Implementations MUST implement OCB [..] Implementations MAY implement EAX only for decryption and only for backward compatibility with former drafts of this specification. So draft-ietf-openpgp-crypto-refresh/13 seems to almost adhere to https://librepgp.org/ 01 Symmetric Mode turn OCB into MUST and EAX into MAY (only for backward compatibility with deployed implementations). Signaling capabilities via the pubkeys would make the optional ("MAY") modes usable enough or do you see a different kind of problem? Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Feb 8 14:08:13 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Feb 2024 14:08:13 +0100 Subject: PQC public key format specification Message-ID: <87a5obcddu.fsf@jacob.g10code.de> Hi! Librepgp-00 has some preliminary specifications for the Kyber (ML-KEM) algorithms. This has been lifted from draft-wussler-openpgp-pqc-03.txt by Stavros Kousidis, Falko Strenzke, and Aron Wussler. There is currently a discussion on the IETF WG list regarding PQC but given that they ignore the v5 key format entirely we are anyway free to improve on this draft. The idea of assigning a separate algorithm id to each variant of the Kyber does not fit nicely into the PGP model of having an identifier for the general algorithm and use the parameters to distinguish between variants. For example, with RSA the length of the modulus directly gives the strengths of the algorithm and with the 3 ECC algorithms the curve name and thus its strength is given by a separate parameter (the curve's OID). Right now the Kyber public key is this series of values: 1. A fixed-length octet string representing an ECC public key in the format associated with the curve. For ML-KEM-768+X25519 these are 32 octets, for ML-KEM-1024+X448 these are 56 octets. 2. A fixed-length octet string containing the ML-KEM public key, whose length depends on the algorithm. For ML-KEM-768+X25519 these are 1184 octets, for ML-KEM-1024+X448 these are 1568 octets. In contrast an ECDH key is this series of values: 1. A variable-length field containing a curve OID, formatted as: a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, the octets representing a curve OID 2. A MPI of an EC point representing a public key; 3. A variable-length field containing KDF parameters, formatted as follows: [...] For Kyber we could just add item 2 to an ECC key and remove the KDF parameters because they are fixed. Thus I propose to change the Kyber public key to: 1. A variable-length field containing a curve OID, formatted as: a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, the octets representing a curve OID 2. A MPI of an EC point representing a public key; 3. A four-octet scalar octet count of the followed by an octet string containing the ML-KEM public key. Note that valid octet counts are 1184 for ML-KEM-768 and 1568 for ML-KEM-1024. This would be a general framework for Kyber (ML-KEM). We would then give a table of valid combinations: | Curve | OID | ML-KEM-n | requirement | |--------+-------------+----------+-------------| | X25519 | 1.3.102.110 | 768 | MUST | | X448 | 1.3.101.111 | 1024 | SHOULD | The advantages of this scheme is that it allows to introduce other combinations iff a need ever arises. Back then when we introduced ECC with RFC6637, the OID specified curve allowed us to add the highly demanded Brainpool curves without any problems and even the deployment of ed25519 and cv25519 went pretty smooth. Not that I introduced a four-octet scalar count instead of an MPI. This count is required for the variants of Kyber and also better fits into the OpenPGP scheme of storing all parameters with their respective length. Given the size of a Kyber key it should not matter whether we use a four instead of a sufficient two-octet count. I consider four-octet easier. Another option would be to use an extended definition of MPI; i.e., define a 32 bit MPI (or its Simple Octet String variant). Using a DER style length encoding would be more similar to the funny Huffman encoding of the PGP packet length - but I doubt that anyone likes this. Keeping the encoding similar to other parameters makes it easier to re-use existing code. For the algorithm ID I suggest to use 29 as suggested in the Wussler draft for ML-KEM-768+X25519 but of course use that also for all other combinations. Even if the crypto-refresh folks settle for a different scheme, we won't run into a conflict because we will use this only with v5 keys. Backporting PQC for v4 keys does not make any sense because it is a new algorithm and, like X448, a new implementation is anyway required. The format for the secret key parameter and for the encryption packet needs to be adjusted similar to the above suggested. But let us first finalize the public key format. The use of the MPIs should be replaced by its extended but compatible defintion of Simple Octet Strings. But this is a separate task. Shalom-Salam, 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 andrewg at andrewg.com Fri Feb 9 01:06:57 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 9 Feb 2024 00:06:57 +0000 Subject: PQC public key format specification Message-ID: <5D885B78-673C-42DF-B0AB-12DC581BC1F2@andrewg.com> Apologies for breaking the thread, I missed the OP due to a mail deliverability issue and had to find it in the archive. Werner Koch Thu Feb 8 14:08:13 CET 2024: > There is currently a discussion on the IETF WG list regarding PQC but > given that they ignore the v5 key format entirely we are anyway free to improve on this draft. ? > The idea of assigning a separate algorithm id to each variant of the Kyber does not fit nicely into the PGP model of having an identifier for the general algorithm and use the parameters to distinguish between variants. For example, with RSA the length of the modulus directly gives the strengths of the algorithm and with the 3 ECC algorithms the > curve name and thus its strength is given by a separate parameter (the curve's OID). ? > The advantages of this scheme is that it allows to introduce other > combinations iff a need ever arises. Any new combination would have to be defined in a document, and such a document could trivially allocate a new algorithm id, so the only significant advantage of this scheme is a slightly denser allocation of the algorithm id namespace. But given that non-librepgp implementations will still use the other algorithm ids, it?s not clear that anything is achieved other than repainting the bikesheds. > For the algorithm ID I suggest to use 29 as suggested in the Wussler > draft for ML-KEM-768+X25519 but of course use that also for all other > combinations. Even if the crypto-refresh folks settle for a different scheme, we won't run into a conflict because we will use this only with v5 keys. Backporting PQC for v4 keys does not make any sense because it > is a new algorithm and, like X448, a new implementation is anyway > required. It?s not just v5 keys that will contain this algorithm ID, but v3 PKESKs. And since draft-wussler specifically allows for PQC algorithms to be used with v4 keys, it is more or less guaranteed that other implementations will generate (and expect to parse) v3 PKESKs with clashing identifiers. This will cause particular problems for implementers who want to support both standards (e.g. gopenpgp) and will therefore have to use other means to determine which algorithm is actually being used. While this is not the end of the world, it adds avoidable extra complexity for no real reason that I can determine. The interop fallout of overloading the algorithm ID is not worth it for such a minor change. If an incompatible format is absolutely necessary (and I still don?t see how it is), it should use a distinct identifier. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Feb 9 11:13:44 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Feb 2024 11:13:44 +0100 Subject: PQC public key format specification In-Reply-To: <5D885B78-673C-42DF-B0AB-12DC581BC1F2@andrewg.com> (Andrew Gallagher via LibrePGP-discuss's message of "Fri, 9 Feb 2024 00:06:57 +0000") References: <5D885B78-673C-42DF-B0AB-12DC581BC1F2@andrewg.com> Message-ID: <87h6iiaqsn.fsf@jacob.g10code.de> On Fri, 9 Feb 2024 00:06, Andrew Gallagher said: > Any new combination would have to be defined in a document, and such a > document could trivially allocate a new algorithm id, so the only Experience has show that this does not work. I already mentioned that the way the Wussler draft used the algorithm IDs is alien to the OpenPGP way where we use the algorithm ID for a specific algorithm (or in this case for an ECC+Kyber combinations) and not for a variant of the algorithm like the RSA size or the ECC curve. This is the reason why I suggested the use of just one algorithm ID. >> this only with v5 keys. Backporting PQC for v4 keys does not make >> any sense because it >> is a new algorithm and, like X448, a new implementation is anyway >> required. > > It?s not just v5 keys that will contain this algorithm ID, but v3 > PKESKs. And since draft-wussler specifically allows for PQC algorithms > to be used with v4 keys, it is more or less guaranteed that other See above. This is not useful because a v4 key uses a SHA-1 fingerprint and we should take that cheap opportunity to use a SHA-256 fingerprint. The crypto-refresh draft anyway uses a version 6 of their PKESK packet. > implementers who want to support both standards (e.g. gopenpgp) and > will therefore have to use other means to determine which algorithm is I have no problem to use another ID but given the state of discussion on crypto-refresh there will soon be no non-assigned id available. Thus 29 is as good as any other id. Shalom-Salam, 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 andrewg at andrewg.com Fri Feb 9 15:41:51 2024 From: andrewg at andrewg.com (andrewg) Date: Fri, 09 Feb 2024 14:41:51 +0000 Subject: PQC public key format specification In-Reply-To: <87h6iiaqsn.fsf@jacob.g10code.de> References: <5D885B78-673C-42DF-B0AB-12DC581BC1F2@andrewg.com> <87h6iiaqsn.fsf@jacob.g10code.de> Message-ID: <0fde9a32232b45e0756ee5bf4348666b@andrewg.com> On 2024-02-09 10:13, Werner Koch wrote: > On Fri, 9 Feb 2024 00:06, Andrew Gallagher said: > >> Any new combination would have to be defined in a document, and such a >> document could trivially allocate a new algorithm id, so the only > > Experience has show that this does not work. Crypto-refresh changes the algorithm ID registry from IETF CONSENSUS to SPECIFICATION REQUIRED, so this should not be an issue in future. > I already mentioned that the way the Wussler draft used the algorithm > IDs is alien to the OpenPGP way where we use the algorithm ID for a > specific algorithm (or in this case for an ECC+Kyber combinations) and > not for a variant of the algorithm like the RSA size or the ECC curve. > This is the reason why I suggested the use of just one algorithm ID. Past practice was in many ways *too* flexible: see all the ridiculous 2047- and 16384-bit RSA keys out in the wild. It also failed to store all the required ECC parameters in the private key, meaning that ECC decryption (uniquely) is not possible without the public key. The "OpenPGP Way" is not a shining example of correctness. >> It?s not just v5 keys that will contain this algorithm ID, but v3 >> PKESKs. And since draft-wussler specifically allows for PQC algorithms >> to be used with v4 keys, it is more or less guaranteed that other > > See above. This is not useful because a v4 key uses a SHA-1 > fingerprint > and we should take that cheap opportunity to use a SHA-256 fingerprint. > > The crypto-refresh draft anyway uses a version 6 of their PKESK packet. But only for v6 keys. PQC with v4 keys uses a v3 PKESK, just like any other v4 key material. If you're absolutely determined to use a parallel namespace for PQC algorithms, please at least define a v5 PKESK to go with v5 keys so that the separation is clean. > I have no problem to use another ID but given the state of discussion > on > crypto-refresh there will soon be no non-assigned id available. Thus > 29 > is as good as any other id. Consensus appears to be in favour of one lattice and one non-lattice hybrid construction for each of encryption and signing, with perhaps two strength ratings per construction. That's eight, leaving ~74 non-assigned IDs. How quickly do you predict these will run out? A From kaie at kuix.de Mon Feb 12 09:43:16 2024 From: kaie at kuix.de (Kai Engert) Date: Mon, 12 Feb 2024 09:43:16 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional Message-ID: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> As I understand it, LibrePGP wants to be treated completely separately from the upcoming OpenPGP/IETF (crypto-refresh) specification. I haven't seen initiative from the LibrePGP side to respond to my past requests for reaching compromises. Werner's recent email about "PQC public key format specification" (on this list) also suggests that LibrePGP will treat PQC using v5 keys differently, with even a clash in namespaces of identifiers as a potential consequence. In my opinion it will be too complicated to handle both specifications in parallel in Thunderbird with a unified user experience. I think it will become necessary that email applications, which want to support both specifications, will be required to clearly distinguish between the OpenPGP and LibrePGP technologies. While I don't plan to rush, this very unfortunate topic keeps my mind busy. I'm continously brainstorming how this could be handled in a reasonable way. I'd like to present you a potential approach that Thunderbird (TB) could use in the future. As you may know, as of today (e.g. as implemented in TB version 115.x), TB uses integrated key management, and internal trust management for all public keys. It offers a fallback to optionally use the GnuPG software, but only for secret keys, and the fallback only works if the user configured extra pfererences, and has GnuPG and the GPGME library installed. TB could potentially handle LibrePGP by treating it as a completely optional technology and message format, only available for users who install GnuPG and GPGME and use special settings in TB. The idea is that TB could introduce a LibrePGP mode of operation. For each email account, TB could offer the user to set a preference whether the email account (or identity) will be used with LibrePGP or with OpenPGP/IETF. As part of this model, TB would stop offering any integrated support for key or trust management for LibrePGP public keys. Users would be required to use an external application (either gpg or a related UI tool). When using only the TB application, without having GnuPG/GPGME installed or configured, TB would offer integrated support OpenPGP (v6) support, only. If RNP implements full support for OpenPGP v6 keys and messages, then TB could eventually enable support for it. TB would be careful to disable any LibrePGP related v5 keys or features when using the integrated mode. Let me write that idea as a bullet list to make it easier to understand: TB by default: - only OpenPGP v4 + v6 support - integrated key and trust management of v4 + v6 keys, only - user can configure (in account settings) which key to use (same as today) - when reading an email, TB would look at the configured account, and if it is configured as OpenPGP, would route the message through the v4+v6 processing code. If the message is actually in the LibrePGP format, processing will fail with an error. - when composing an email, TB would only consider the list of public keys from TB's internal keyring, same as today. - when composing, the UI technology choice would offer OpenPGP and S/MIME only. All users of TB would have the above available. Only users who manually install and configure GnuPG/GPGME may optionally use the following: TB with GnuPG/GPGME: - If a user wishes to make use of GnuPG, they will have to say so in the settings for a TB account/identity. - the user will have to specify which external GnuPG secret key should be used with this account/identity (same as today) - when reading an email, the message would be routed through external gnupg, only. (And processing will fail with an error if it's a v6 message, or if the required secret key is not available in the LibrePGP keyring.) - when viewing the status of an email, TB might offer reduced information. For example, it might report the signature status based on feedback from GnuPG, and report the fingerprint of the signer key. But maybe it will not report anything else. Because TB would not offer key management for LibrePGP keys, there might be no viewer for those keys inside of TB. - when composing an email, TB might try to query GPGME for the availability of keys, and maybe it could show in advance whether an email can be encrypted or not. However, TB wouldn't offer any assistance for resolving issues with missing keys. The user would be required to manually resolve such trouble with their external tool for LibrePGP key management. GnuPG's trust settings for public keys would be used. - when composing, the technology offered in the menus would be limited to LibrePGP/GnuPGP and S/MIME (based on the configuration of the from/sender identity for the current email). General: - the internal key and trust management of TB would make it clear in the UI that it's limited to OpenPGP keys, and exclude GnuPG/LibrePGP keys Summary: - using OpenPGP/IETF would work in TB in the same way as today - LibrePGP would be available in TB only after manual efforts to configure it, and its usability would be very limited and probably inconvenient. This isn't yet a plan, but just a potential way to handle the separate specifications in TB, and still give a users a minimal workaround to use LibrePGP, if they have to. I assume that in the upcoming TB release in 2024, TB will limits its *PGP support to RFC 4880, and not yet attempt to support any enhancements from the LibrePGP or OpenPGP/crypto-refresh specifications. Regards Kai From bernhard at intevation.de Mon Feb 12 11:14:33 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Feb 2024 11:14:33 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> Message-ID: <202402121114.33955.bernhard@intevation.de> Hi Kai, as the integrated trust handling is one of the most important parts of the end to end crypto experience: Am Montag 12 Februar 2024 09:43:16 schrieb Kai Engert via LibrePGP-discuss: > - the internal key and trust management of TB would make it clear > ? ?in the UI that it's limited to OpenPGP keys, and exclude > ? ?GnuPG/LibrePGP keys .. means that LibrePGP is very degraded in the UX. Not good for users. Gru? Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Mon Feb 12 12:34:58 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 12 Feb 2024 11:34:58 +0000 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <202402121114.33955.bernhard@intevation.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121114.33955.bernhard@intevation.de> Message-ID: On 12 Feb 2024, at 10:14, Bernhard Reiter via LibrePGP-discuss wrote: > Am Montag 12 Februar 2024 09:43:16 schrieb Kai Engert via LibrePGP-discuss: >> - the internal key and trust management of TB would make it clear >> in the UI that it's limited to OpenPGP keys, and exclude >> GnuPG/LibrePGP keys > > .. means that LibrePGP is very degraded in the UX. > Not good for users. At this point I don?t think any of the available options are good for users, short of a reconciliation. If LibrePGP insists on using non-standard code points outside of the space reserved for it, I don?t see how it is possible to cleanly and safely support both LibrePGP and OpenPGP in the same application, unless the dual-support implementations find some magic way of resolving the ambiguities (and I wouldn?t blame them for not wasting any more time on it). Allowing GnuPG to do its own thing in its own sandbox is probably therefore the only safe way to enable the full suite of LibrePGP features. It will probably therefore be impossible for hockeypuck to support both v5 and v6 PQC keys, given our dependency on upstream library support. I realise this puts Intevation in a particularly uncomfortable position, given that upstream GnuPG has more or less declared keyservers obsolete, and seems unwilling to make any further concessions for our benefit. I had hoped for a more inclusive outcome, and up until last week I honestly believed it was still possible. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bernhard at intevation.de Mon Feb 12 13:00:48 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Feb 2024 13:00:48 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121114.33955.bernhard@intevation.de> Message-ID: <202402121300.57561.bernhard@intevation.de> Am Montag 12 Februar 2024 12:34:58 schrieb Andrew Gallagher: > At this point I don?t think any of the available options are good for > users, short of a reconciliation. My point was specific about what Kai's proposal would mean: It is not really making LibrePGP "optional", but would be making it unusable (IIUC) I am not sure if this is what he wanted to propose. As for other points I think it would be best to see what the response is first. Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Mon Feb 12 13:50:29 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 12 Feb 2024 12:50:29 +0000 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <202402121300.57561.bernhard@intevation.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121114.33955.bernhard@intevation.de> <202402121300.57561.bernhard@intevation.de> Message-ID: On 12 Feb 2024, at 12:00, Bernhard Reiter via LibrePGP-discuss wrote: > > My point was specific about what Kai's proposal would mean: > It is not really making LibrePGP "optional", > but would be making it unusable (IIUC) > I am not sure if this is what he wanted to propose. Kai's proposal for v5 support is effectively a reversion to the classic Enigmail behaviour - where both private and public key operations are delegated to gnupg. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bernhard at intevation.de Tue Feb 13 08:26:35 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Feb 2024 08:26:35 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121300.57561.bernhard@intevation.de> Message-ID: <202402130826.43440.bernhard@intevation.de> > Kai's proposal for v5 support is effectively a reversion to the classic > Enigmail behaviour - where both private and public key operations are > delegated to gnupg. It is good if GnuPG were to be used as crypto backend (though there is RNP which also plans to support v5 AFAIK). The important part is to integrate the pubkey management and the trust display into the user interface to make end to end cryptography usable. Like that a search for the pubkey including trying WKD automatically if an email address is entered. And a display if for a recipient a pubkey is found and at which "confidence". Best, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From kaie at kuix.de Tue Feb 13 10:44:32 2024 From: kaie at kuix.de (Kai Engert) Date: Tue, 13 Feb 2024 10:44:32 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <202402130826.43440.bernhard@intevation.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121300.57561.bernhard@intevation.de> <202402130826.43440.bernhard@intevation.de> Message-ID: On 13.02.24 08:26, Bernhard Reiter via LibrePGP-discuss wrote: > It is good if GnuPG were to be used as crypto backend GnuPG cannot be used as Thunderbird's default crypto backend. Because the licenses are incompatible, Thunderbird must not bundle GnuPG. But Thunderbird (TB) wants an easy out-of-the-box experience, that's why it needs a crypto backend with a compatible license that can be bundled. That's why TB currently uses RNP. > (though there is RNP which also plans to support v5 AFAIK). At this time, RNP doesn't yet support smartcards. Also, we have users who want to use private keys from GnuPG's software keyring. If TB offers optional support for GnuPG anyway, then we already have a way to (optionally) cover v5. Because v5 is incompatible with the other parts of the ecosystem, handling it needs to be treated separately anyway. And if we already have a way to handle v5 separately (with GnuPG), then RNP's support for v5 wouldn't be necessary. > The important part is to integrate the pubkey management > and the trust display into the user interface > to make end to end cryptography usable. Thunderbird already has that integrated. But users shouldn't be required to learn that owning two separate keypairs of different versions is necessary for being compatible with any potential correspondent (who might be using a client that supports only v5 keys or supports only v6 keys). If Alice doesn't know which client Bob is using, and Alice wants to send her public key to Bob (to enable Bob to send an encrypted reply), then Alice shouldn't be required to send both a v5 key and a v6 key. If Bob wants to verify Alice's fingerprint, then it should be obvious which fingerprint Alice needs to give to Bob. She should haven't to guess, and she shouldn't have to ask "which of my fingerprints do you need?", and she shouldn't have to say "here is the list of my fingerprints, please check if one of them matches". If v5 and v6 keys are incompatible, then I want to limit TB's integrated key management to one type of new key, only. > Like that a search for the pubkey including trying WKD automatically if an > email address is entered. And a display if for a recipient a pubkey is found > and at which "confidence". And the key returned by WKD should be in a format that all PGP email clients can use easily, not just a subset of clients. If the supporters of LibrePGP want to benefit from this convenience, they could consider to adopt the v6 key format, or work with the OpenPGP IETF working group to define a common key format, that's acceptable to both groups. Kai From wk at gnupg.org Tue Feb 13 11:10:26 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Feb 2024 11:10:26 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> (Kai Engert via LibrePGP-discuss's message of "Mon, 12 Feb 2024 09:43:16 +0100") References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> Message-ID: <871q9gbrot.fsf@jacob.g10code.de> On Mon, 12 Feb 2024 09:43, Kai Engert said: > Werner's recent email about "PQC public key format specification" (on > this list) also suggests that LibrePGP will treat PQC using v5 keys > differently, with even a clash in namespaces of identifiers as a This is just a discussion on how to do things in a better way than defined in the initial PQC draft. As stated, we work together with Ribose on LibrePGP and thus Thunderbird should not have any problem given that it uses RNP. > I assume that in the upcoming TB release in 2024, TB will limits its > *PGP support to RFC 4880, and not yet attempt to support any So you are removing support for ed25519 et al.? Your user's won't appreciate this. 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 Tue Feb 13 11:15:09 2024 From: kaie at kuix.de (Kai Engert) Date: Tue, 13 Feb 2024 11:15:09 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <871q9gbrot.fsf@jacob.g10code.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <871q9gbrot.fsf@jacob.g10code.de> Message-ID: <8c967a6f-4b67-4419-8324-00811507d202@kuix.de> On 13.02.24 11:10, Werner Koch wrote: > On Mon, 12 Feb 2024 09:43, Kai Engert said: > >> I assume that in the upcoming TB release in 2024, TB will limits its >> *PGP support to RFC 4880, and not yet attempt to support any > > So you are removing support for ed25519 et al.? Your user's won't > appreciate this. I apologize for being imprecise. A better high level description of my intention for the short term release is to avoid support for functionality that's newly introduced in either draft-libprepgp or crypto-refresh. Kai From kaie at kuix.de Tue Feb 13 11:21:12 2024 From: kaie at kuix.de (Kai Engert) Date: Tue, 13 Feb 2024 11:21:12 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: <871q9gbrot.fsf@jacob.g10code.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <871q9gbrot.fsf@jacob.g10code.de> Message-ID: On 13.02.24 11:10, Werner Koch wrote: > On Mon, 12 Feb 2024 09:43, Kai Engert said: > >> Werner's recent email about "PQC public key format specification" (on >> this list) also suggests that LibrePGP will treat PQC using v5 keys >> differently, with even a clash in namespaces of identifiers as a > > This is just a discussion on how to do things in a better way than > defined in the initial PQC draft. As stated, we work together with > Ribose on LibrePGP and thus Thunderbird should not have any problem > given that it uses RNP. Thunderbird has a problem if it's incompatible with implementations other than GnuPG and RNP. Kai From wk at gnupg.org Tue Feb 13 11:20:37 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Feb 2024 11:20:37 +0100 Subject: PQC public key format specification In-Reply-To: <0fde9a32232b45e0756ee5bf4348666b@andrewg.com> (andrewg@andrewg.com's message of "Fri, 09 Feb 2024 14:41:51 +0000") References: <5D885B78-673C-42DF-B0AB-12DC581BC1F2@andrewg.com> <87h6iiaqsn.fsf@jacob.g10code.de> <0fde9a32232b45e0756ee5bf4348666b@andrewg.com> Message-ID: <87wmr8acne.fsf@jacob.g10code.de> On Fri, 9 Feb 2024 14:41, andrewg said: > Past practice was in many ways *too* flexible: see all the ridiculous > 2047- and 16384-bit RSA keys out in the wild. It also failed to store I consider some keys ridiculous too. However, there have been valid reasons to use not-so common RSA key sizes. Or DSA or other other Weierstrass curves. > all the required ECC parameters in the private key, meaning that ECC > decryption (uniquely) is not possible without the public key. The Please explain? You mean the parameters required for ECDH? Surely we can't assign different algo ids for the KDF params due to combinatorial explosion. > But only for v6 keys. PQC with v4 keys uses a v3 PKESK, just like any I already explained why using PQC with v4 is a bad idea. I don't want to repreat this. Let's stop here. > parallel namespace for PQC algorithms, please at least define a v5 > PKESK to go with v5 keys so that the separation is clean. Why should we - there is no need for it. Even the full fingerprint in the crypto-refresh PKESK is superflous - a 64 bit keyid is sufficient here - because it is about the private key. > Consensus appears to be in favour of one lattice and one non-lattice > hybrid construction for each of encryption and signing, with perhaps I watch the discussion and there is no clear consensus for anything. Shalom-Salam, 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 wk at gnupg.org Tue Feb 13 11:36:35 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Feb 2024 11:36:35 +0100 Subject: LibrePGP in Thunderbird, maybe treat it as optional In-Reply-To: (Kai Engert via LibrePGP-discuss's message of "Tue, 13 Feb 2024 10:44:32 +0100") References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <202402121300.57561.bernhard@intevation.de> <202402130826.43440.bernhard@intevation.de> Message-ID: <87sf1wabws.fsf@jacob.g10code.de> On Tue, 13 Feb 2024 10:44, Kai Engert said: > On 13.02.24 08:26, Bernhard Reiter via LibrePGP-discuss wrote: >> It is good if GnuPG were to be used as crypto backend > > GnuPG cannot be used as Thunderbird's default crypto backend. Because > the licenses are incompatible, Thunderbird must not bundle GnuPG. But Just for the records: That is simply not true. Thunderbird already uses LGPL-2+ code and thus there is no reason not to use GPGME which uses the same license. Of course TB should not bundle GnuPG - no other mail client on Unix does this either and adding a suggestion or automatic install of Gpg4win, as Enigmail did, is not much of a problem. I am actually glad to see that TB uses RNP. I'd only wish that TB makes uses of the RNP features and implements OpenPGP as well as Enigmail did. That is way ore important than discussing details of packet formats which are anyway handled by RNP for TB. > Because v5 is incompatible with the other parts of the ecosystem, Please don't spread such BS. v5 support has long been deployed by the major implementations. We just don't yet create keys in that format for improved backward compatibility. However, if you see an X448 key it will be a v5 key. > If the supporters of LibrePGP want to benefit from this convenience, > they could consider to adopt the v6 key format, or work with the > OpenPGP IETF working group to define a common key format, that's We have all seen that working with the IETF OpenPGP WG is not possible and the sole reason why we had to establish a new name for OpenPGP. [please take any further discussion on this to other mailing lists] 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 andrewg at andrewg.com Tue Feb 13 13:49:19 2024 From: andrewg at andrewg.com (andrewg) Date: Tue, 13 Feb 2024 12:49:19 +0000 Subject: PQC public key format specification Message-ID: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> ?On 2024-02-13 10:20, Werner Koch wrote: > On Fri, 9 Feb 2024 14:41, andrewg said: >> all the required ECC parameters in the private key, meaning that ECC >> decryption (uniquely) is not possible without the public key. The > Please explain? You mean the parameters required for ECDH? Yes. If somebody has their secret key material on a smartcard but has lost their public key (for whatever reason) they cannot decrypt their historic data. The extra parameters (OIDs and KDFs) are stored elsewhere. They could have been stored on the card (plenty of room since ECC keys are smaller than RSA) or they could have been stored in the spec (by defining fixed values) but the practice that emerged was neither. It retained algorithmic agility but at the cost of added failure modes (and a combinatoric explosion). Was this in the spirit of the OpenPGP way of doing things? It's certainly arguable that it was not and that we shouldn't repeat that mistake. A From bernhard at intevation.de Tue Feb 13 15:19:14 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Feb 2024 15:19:14 +0100 Subject: Thunder could bundle GnuPG (Re: LibrePGP in Thunderbird, maybe treat it as optional) In-Reply-To: <87sf1wabws.fsf@jacob.g10code.de> References: <7af54742-5771-45d2-ab16-282dd5edb882@kuix.de> <87sf1wabws.fsf@jacob.g10code.de> Message-ID: <202402131519.22997.bernhard@intevation.de> Am Dienstag 13 Februar 2024 11:36:35 schrieb Werner Koch: > On Tue, 13 Feb 2024 10:44, Kai Engert said: > > GnuPG cannot be used as Thunderbird's default crypto backend. Because > > the licenses are incompatible, Thunderbird must not bundle GnuPG. > > Just for the records: That is simply not true. ?Thunderbird already uses > LGPL-2+ code and thus there is no reason not to use GPGME which uses the > same license. ?Of course TB should not bundle GnuPG - no other mail > client on Unix does this either and adding a suggestion or automatic > install of Gpg4win, as Enigmail did, is not much of a problem. I second this. From the license point of view Thunderbird could bundle GnuPG without problems. (Whether it should is a different question.) Here is the reference I know of for the presumed problem: https://wiki.gnupg.org/EMailClients/Thunderbird "It is unknown in public what the main reasons for doing a new implementation instead of using GnuPG (and Gpg4win) were. One Mozilla developer wrote about licensing concerns [1], but other people have pointed out that GPGME is GNU LGPL and the GNU GPL of GnuPG itself allows for a combined distribution of Thunderbird and GnuPG." [1] https://mail.mozilla.org/pipermail/tb-planning/2019-December/007287.html Do you know of any other concern regarding the license? Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Feb 13 18:43:34 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Feb 2024 18:43:34 +0100 Subject: PQC public key format specification In-Reply-To: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> (andrewg@andrewg.com's message of "Tue, 13 Feb 2024 12:49:19 +0000") References: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> Message-ID: <878r3o9s55.fsf@jacob.g10code.de> On Tue, 13 Feb 2024 12:49, andrewg said: > Yes. If somebody has their secret key material on a smartcard but has > lost their public key (for whatever reason) they cannot decrypt their That is why gpg records the creation time (and if ever needed) the KDF parameters along with the stub file. This allows to re-create the public key but this is only a hack for the rare case that a public key gets lost and the card still works. Further, this is only a concern for the OpenPGP card because when Achim and me designed them, the space on the cards (and the I/O speed) where pretty limited. > historic data. The extra parameters (OIDs and KDFs) are stored You need to translate from the card OS's representation to the one defined by OpenPGP anyway. We even need to modify the RSA parameters to get or store them opn the card. > since ECC keys are smaller than RSA) or they could have been stored in Actually we store them on most cards and in general they are anyway fixed. > failure modes (and a combinatoric explosion). Was this in the spirit > of the OpenPGP way of doing things? It's certainly arguable that it > was not and that we shouldn't repeat that mistake. Pretty please no OpenPGP WG discussion style and don't accidentally trick us getting into this either. See the rules posted at https://lists.gnupg.org/pipermail/librepgp-discuss/2023/000000.html (copied below) Salam-Shalom, Werner =-=-=-=-= 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. -- 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 andrewg at andrewg.com Tue Feb 13 19:19:06 2024 From: andrewg at andrewg.com (andrewg) Date: Tue, 13 Feb 2024 18:19:06 +0000 Subject: PQC public key format specification In-Reply-To: <878r3o9s55.fsf@jacob.g10code.de> References: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> <878r3o9s55.fsf@jacob.g10code.de> Message-ID: <9d93ff1cff6333949758b17f56334195@andrewg.com> On 2024-02-13 17:43, Werner Koch wrote: > > Pretty please no OpenPGP WG discussion style and don't accidentally > trick us getting into this either. See the rules posted at > https://lists.gnupg.org/pipermail/librepgp-discuss/2023/000000.html > (copied below) I'm unsure how to "avoid a discussion style as introduced around 2018 in the OpenPGP working group mailing list". So I will refrain from further comment, just in case. A From bernhard at intevation.de Wed Feb 14 10:55:09 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Feb 2024 10:55:09 +0100 Subject: Please write respectfully on this list (Re: PQC public key format specification) In-Reply-To: <9d93ff1cff6333949758b17f56334195@andrewg.com> References: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> <878r3o9s55.fsf@jacob.g10code.de> <9d93ff1cff6333949758b17f56334195@andrewg.com> Message-ID: <202402141055.38156.bernhard@intevation.de> Am Dienstag 13 Februar 2024 19:19:06 schrieb andrewg via LibrePGP-discuss: > Was this in the spirit of the OpenPGP way of doing things? > It's certainly arguable that it was not and > that we shouldn't repeat that mistake. > On 2024-02-13 17:43, Werner Koch wrote: > > Pretty please no OpenPGP WG discussion style and don't accidentally > > trick us getting into this either. See the rules posted at > > https://lists.gnupg.org/pipermail/librepgp-discuss/2023/000000.html > > (copied below) > > I'm unsure how to "avoid a discussion style as introduced around 2018 in > the OpenPGP working group mailing list". My take on it: Do not presume what is or was a mistake or a good spririt and what wasn't. The first quote above can be understood this way. Instead some could present a more concrete argument or a specific question. Assume that implementors and designers had a good reason (or may have made a specific oversight). If you say that arguments can be made, make them or refer to them. I believe that rules are okay to ask for a technical mailinglist and to occasionally remind or address the issue. > So I will refrain from further comment, just in case. I welcome further comments of you as I find the vast majority of your writing constructive in style and contents. What the rules mean in a case at hand will have to developed anyway, so you can just try and we'll figure it out. Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From heiko.schaefer at posteo.de Thu Feb 15 10:35:53 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Thu, 15 Feb 2024 09:35:53 +0000 Subject: Please write respectfully on this list (Re: PQC public key format specification) In-Reply-To: <202402141055.38156.bernhard@intevation.de> References: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> <878r3o9s55.fsf@jacob.g10code.de> <9d93ff1cff6333949758b17f56334195@andrewg.com> <202402141055.38156.bernhard@intevation.de> Message-ID: On 2/14/24 10:55, Bernhard Reiter via LibrePGP-discuss wrote: >> I'm unsure how to "avoid a discussion style as introduced around 2018 in >> the OpenPGP working group mailing list". > My take on it: > Do not presume what is or was a mistake or a good spririt and what > wasn't. The first quote above can be understood this way. I apologize in advance for being extremely confused by this guidance, and would like to ask for clarification. Just a bit up in this same thread, Werner explained that the design of draft-wussler is "alien to the OpenPGP way", which I understand as: considering the design a "mistake", because the design is "not in the spirit" of OpenPGP. Andrew's reply picked up the structure of this argument, and made a counterpoint to it. That seemed reasonable to me, at the time. Could you please clarify why statements such as: > the way the Wussler draft used the algorithm IDs is alien to the > OpenPGP way or, for that matter: > Nobody with a sane mind uses the metadata to directly save to a file > with that name without taking necessary precautions apparently conform to the social norms of this list, while Andrew's message > [..] Was this in the spirit > of the OpenPGP way of doing things? It's certainly arguable that it > was not and that we shouldn't repeat that mistake. does not? Thanks, Heiko From bernhard at intevation.de Thu Feb 15 12:06:22 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Feb 2024 12:06:22 +0100 Subject: Please write respectfully on this list (Re: PQC public key format specification) In-Reply-To: References: <14739DDD-5584-42B2-B0EC-42CA41144B4D@andrewg.com> <202402141055.38156.bernhard@intevation.de> Message-ID: <202402151206.44098.bernhard@intevation.de> Am Donnerstag 15 Februar 2024 10:35:53 schrieb Heiko Sch?fer via LibrePGP-discuss: > Just a bit up in this same thread, Werner explained that the design of > draft-wussler is "alien to the OpenPGP way", which I understand as: > considering the design a "mistake", because the design is "not in the > spirit" of OpenPGP. > > Andrew's reply picked up the structure of this argument, and made a > counterpoint to it. That seemed reasonable to me, at the time. There was more context to Andrew's statement: | They could have been stored on the card (plenty of room since ECC keys are | smaller than RSA) or they could have been stored in the spec (by defining | fixed values) but the practice that emerged was neither. It retained | algorithmic agility but at the cost of added failure modes (and a | combinatoric explosion). Was this in the spirit of the OpenPGP way of doing | things? It's certainly arguable that it was not and that we shouldn't repeat | that mistake. That statement assumes that not storing the the parameters on the card was a mistake without reason and can be misread (over the full comment) that making mistakes or not correcting them would be "the spirit of the OpenPGP way". I do not think that Andrew meant it this way, but I'll find it okay for Werner to remind the list that going more down that direction will at some point be subject to moderation. But again this is just my take on it, trying to increase the understanding. I am not the moderator on this list and I haven't made the rules. (This is why I gave "my take" on it.) > Could you > please clarify why statements such as: > > the way the Wussler draft used the algorithm IDs is alien to the > > OpenPGP way I did understand this as a technical history, that IDs have been used differently in OpenPGP in previous years. > or, for that matter: > > Nobody with a sane mind uses the metadata to directly save to a file > > with that name without taking necessary precautions Again that seems to be specific technical consensus. Like documented here https://www.rfc-editor.org/rfc/rfc6266#page-5 about the filename parameter of the Content-Disposition header in mails: It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the desired information. I am not sure if Werner assumed that anyone here had proposed doing that different specifically and thus meant this person would not have "a sane mind". If that were a likely missread I would also consider it outside of the proposed mailinglist rules. Regards Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Sat Apr 27 11:54:18 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 27 Apr 2024 10:54:18 +0100 Subject: Typo in draft-koch-librepgp Message-ID: Hi, There appears to be a typo in Section 9.2, Table 7 of https://datatracker.ietf.org/doc/html/draft-koch-librepgp#ecc-curve-oid : > 1.3.101.112 | 3 | 2B 65 70 | Ed25519(1) > 1.3.102.110 | 3 | 2B 65 6E | Curve25519(1) > 1.3.101.113 | 3 | 2B 65 71 | Ed448 > 1.3.101.111 | 3 | 2B 65 6F | X448 The Curve25519 OID in the first column should be 1.3.101.110 (the byte representation in column 3 appears to be correct though). ( Ref: RFC8410 Section 3 https://www.rfc-editor.org/rfc/rfc8410 ) Thanks, A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Mon Apr 29 12:08:51 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Apr 2024 12:08:51 +0200 Subject: Typo in draft-koch-librepgp In-Reply-To: (Andrew Gallagher via LibrePGP-discuss's message of "Sat, 27 Apr 2024 10:54:18 +0100") References: Message-ID: <87bk5s8or0.fsf@jacob.g10code.de> Hi! > The Curve25519 OID in the first column should be 1.3.101.110 (the byte > representation in column 3 appears to be correct though). Pretty obvious. Thanks for reporting. 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 wk at gnupg.org Mon May 6 13:17:22 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 13:17:22 +0200 Subject: Updated PQC specification Message-ID: <8734qv42bh.fsf@jacob.g10code.de> Hi! Please find attached a draft version of the next LibrePGP draft specification which describes the new KEM algorithms used for quantum-resistant encryption. Before a new draft is published some minor things need to be fixed but it should nevertheless allow to implement the same thing as we did in GnuPG master. Note that here and in in GnuPG we use the term "Kyber" instead of "ML-KEM" because that is easier to recognize. [1] As long as the crypto primitives are available adding that support is straightforward because existing parser code may partly be re-used and all variants are covered by just one algorithm id. Support for quantum-resistant signature schemes is not not yet available and far less urgent than encryption: The goal is to protect encrypted data at rest (or being wiretapped). Also new signature schemes need more real world experience before they can be taken in use. The migration plan to quantum-resistant encryption is to add new Kyber subkeys so that implementation with support for them can start to use them. If at some point in the future a wide deployment as been achieved an option (e.g. --require-pqc-encryption for gpg) can be used to force encryption with a quantum-resistant algorithm (i.e. Kyber). The scheme we use is as flexible as other algorithms in OpenPGP but an implementaion is of course free to limit allowed algorithm combinations. For example, only supporting the SHOULD combinations of algorithms is perfectly fine. In the current development stage and before the final ML-KEM specification (FIPS203-final is expected this summer) having no restrictions might be helpful, though. In contrast to the original draft by wussler et al. we don't assign separate code point to all algorithm combinations because that would diverts from existing OpenPGP protocol behaviour. In *PGP there is one code point for RSA, one for DSA, one for Elgamal, one for ECDH, one for ECDSA, one for EdDSA, and now one for Kyber. They all have different parameters: either direct specification of the parameters or an OID for the curve parameters (which would be too large to include in all keys, as it is allowed in X.509). Thus it is natural for *PGP to do the same for Kyber. *PGP is a different protocol and has a different specification history than TLS with its hundreds of codepoints for algorithm combinations. Adding more codepoints to TLS is also the natural way - but for TLS. Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for their draft on adding PQC to OpenPGP. The algorithms used by LibgrePGP are the same except for the fixed info. I took the freedom to remove the rationale parts which are not helpful for an implementer and was thus able to make the description more concise. Shalom-Salam, Werner [1] In GnuPG's Git master as of today we use an algo name of "kyber" as a shortcut for ky768_bp256 (ML-KEM-768 + BrainpoolP256r1) and "kyber1024" as a shortcut for ky1024_bp384 (ML-KEM-768 + BrainpoolP256r1). -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: draft-koch-librepgp-2024-05-06.txt.gz Type: application/gzip Size: 80682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: