From bernhard at intevation.de Thu Dec 1 10:57:28 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 1 Dec 2022 10:57:28 +0100 Subject: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add PEP517 support In-Reply-To: References: <87mt88han1.fsf@wheatstone.g10code.de> Message-ID: <202212011057.35450.bernhard@intevation.de> Hi David, thanks for sending the DCO and for caring about the python bindings! Am Mittwoch 30 November 2022 15:31:15 schrieb David Runge: > As noted above, the sdist tarball on pypi.org was generated from the > gpgme sources (albeit from a very old version) in 2018. I remember that there were a couple of technical and administrative points which got discussed afterwards and were not fully clarified. So there is mostly likely a bit of a mess we need to figure out and then clean up. So your initiative and your explanations are well appreciated. > Please reinstate this going forward, as it allows Python projects to use > gpg in virtualenvs (which is a huge chunk of current projects) for > testing and running a project. (I guess that folks could still build stuff by themselves, which probably is considered less practical because of the needed efforts.) It would be cool to improve the python binding situation, even it is just to clarify it more. 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 felipe at neodyme.io Fri Dec 2 18:14:14 2022 From: felipe at neodyme.io (Felipe Custodio Romero) Date: Fri, 2 Dec 2022 18:14:14 +0100 Subject: [PATCH scd] scd: Fix Yubikey gpg decryption using Ed25519 Message-ID: * scd/app-openpgp.c (parse_algorithm_attribute): re-enable ECC_FLAG_DJB_TWEAK for Yubikeys with Ed25519. -- Hi, This patch fixes gpg decryption with Yubikeys using Ed25519 which has been broken since 2.3.0. Before this patch, attempting to decrypt a message with a Yubikey using Ed25519 failed with the error `decryption failed: Invalid value`. After this patch, the decryption succeeds. Regards Felipe --- scd/app-openpgp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index e445b2409..c2b4a9133 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -6292,9 +6292,11 @@ parse_algorithm_attribute (app_t app, int keyno) { app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECC; app->app_local->keyattr[keyno].ecc.curve = curve; + /* ECC_FLAG_DJB_TWEAK needs to be set for Yubikeys with Ed25519 */ if ((*buffer == PUBKEY_ALGO_EDDSA - && !strcmp (app->app_local->keyattr[keyno].ecc.curve, - "Ed25519")) + && (!strcmp (app->app_local->keyattr[keyno].ecc.curve, + "Ed25519") + || APP_CARD(app)->cardtype == CARDTYPE_YUBIKEY)) || (*buffer == PUBKEY_ALGO_ECDH && !strcmp (app->app_local->keyattr[keyno].ecc.curve, "Curve25519"))) -- 2.38.0 -- Neodyme AG Sitz der Gesellschaft / Address: Dirnismaning 55 | Halle 13 |? 85748 Garching b.M?nchen Postanschrift:??Rosenthaler Stra?e 72a |??10119 Berlin Registergericht / Registry court: M?nchen, HRB 269168 Vorstand / Management Board: Thomas Lambertz | Tobias Madl Aufsichtsratsvorsitzender / Chairman of the Supervisory Board: Hendrik Hofstadt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengyi37 at huawei.com Wed Dec 7 21:59:25 2022 From: pengyi37 at huawei.com (pengyi) Date: Thu, 8 Dec 2022 04:59:25 +0800 Subject: [PATCH] add more tests for t-printf and t-strerror Message-ID: <20221207205925.1784145-1-pengyi37@huawei.com> Hi. I found in libgpg-error, the tests/t-strerror.c didn?t include some system error case; the tests/t-printf.c didn?t test the functionality of gpgrt_fwrite() which is also a common API. So I wonder if it?s possible to add more testcases in these two tests. Signed-off-by:"pengyi" --- tests/t-printf.c | 25 +++++++++++++++++++++++++ tests/t-strerror.c | 3 ++- 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/tests/t-printf.c b/tests/t-printf.c index c261838..fa2501c 100644 --- a/tests/t-printf.c +++ b/tests/t-printf.c @@ -489,6 +489,30 @@ check_fprintf_sf (void) gpgrt_fclose (stream); } +static void +check_fwrite (void) +{ + gpgrt_stream_t stream; + const char *expect; + char *result; + + stream = gpgrt_fopenmem (0, "w+b"); + if (!stream) + die ("fopenmem failed at line %d\n", __LINE__); + + gpgrt_fwrite("[==>Niente<==]", 1, 14, stream); + expect = "[==>Niente<==]"; + result = stream_to_string (stream); + if (strcmp (result, expect)) + { + show ("expect: '%s'\n", expect); + show ("result: '%s'\n", result); + fail ("fprintf_sf failed at %d\n", __LINE__); + } + free (result); + gpgrt_fclose (stream); +} + int main (int argc, char **argv) @@ -535,6 +559,7 @@ main (int argc, char **argv) run_tests (); check_snprintf (); check_fprintf_sf (); + check_fwrite(); #ifdef __GLIBC__ return !!errorcount; diff --git a/tests/t-strerror.c b/tests/t-strerror.c index 9289066..5b749d1 100644 --- a/tests/t-strerror.c +++ b/tests/t-strerror.c @@ -49,7 +49,8 @@ main (int argc, char *argv[]) gpg_err_source_t src; gpg_err_code_t code; } list[] = { { 0, 0 }, { 1, 201 }, { 2, 2 }, { 3, 102 }, - { 4, 100 }, { 5, 99 }, { 6, 110 }, { 7, 7 }, { 8, 888 } }; + { 4, 100 }, { 5, 99 }, { 6, 110 }, { 7, 7 }, { 8, 888 } + { 1, GPG_ERR_SYSTEM_ERROR }, { 1, GPG_ERR_SYSTEM_ERROR | 2 }, { 1, GPG_ERR_SYSTEM_ERROR | 4 } }; int i = 0; while (i < sizeof (list) / sizeof (list[0])) -- 2.27.0 From bernhard at intevation.de Fri Dec 9 09:39:30 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 9 Dec 2022 09:39:30 +0100 Subject: WKD draft: suggestions Message-ID: <202212090939.38624.bernhard@intevation.de> Hi Werner, a) https://www.ietf.org/archive/id/draft-koch-openpgp-webkey-service-15.html#name-policy-flags has o "submission-address": An alternative way to specify the submission address. The value is the addr-spec part of the address to send requests to this server. If this keyword is used in addition to the "submission-address" file, both MUST have the same value. and in 4.1. The Submission Address The file consists of exactly one line [..] with the full mail address As addr-spec part != full mail address, both do not "have the same value". Maybe you can phrase it like both MUST indicate the same mail address. b) You write `PGP/MIME` in a couple of places referring to RFC3156. But RFC3156 does not use that abbreviation, `OpenPGP/MIME` seems a better fterm (and is used already once in rfc2440 and 4880). c) It is implicitely clear, but implementors may benefit from writing it explicitely that only _one_ public key, which is ready for use, MUST be returned, so that a client can use this public for encryption right away (after checking that the mail address in the user id matches the one it wants to encrypt to). d) Additional revoked pubkeys are allowed to be returned (which are not ready for usage), but this maybe suboptimal, becase if they are revoked I'd expect an implementation to not use them for calculating trust anymore. It would be more interesting to allow expired public keys (which are also not ready for use), as they could be used to establish more trust, if there is a signature by them on the current active pubkey. But for a good rollover process, overlaping pubkeys seems nice, but this would go against the simplicity of having only one pubkey ready for usage returned. So I am not sure about this one. 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 bernhard at intevation.de Fri Dec 9 09:59:59 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 9 Dec 2022 09:59:59 +0100 Subject: WKD: returns only one pubkey (and why) Message-ID: <202212091000.16718.bernhard@intevation.de> Hi David, saw that you had a question about WKD in your blog: https://sleepmap.de/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168/ You write: gpg --locate-keys dave at sleepmap.de The above only returns the new key [..], but not the old [..]. It is entirely opaque to the user as to why. The reason is that WKD only allows for returning one active public key. https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-15#name-key-discovery has The HTTP GET method MUST return the binary representation of the OpenPGP key for the given mail address. [..] a server may return revoked keys in addition to a new key. The use of _the_ and _a_ key shows that only one public key is to be returned. This makes sense because the idea is that a client can directly use the key for encryption without asking the user for choice. It seems that the version of sequoia-pgp you were using in April does not implement the WKD draft correctly by providing and downloading more than one pubkey. This may have added to your confusion. Nontheless the intentions could be written more explicit in the WKD draft, which I have meanwhile suggested to the author. Regards, Bernhard ps.: BTW there is a new group of synchronised pubkey servers, since a while, e.g. see https://social.tchncs.de/@ber/107008659842900171 -- 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 dave at sleepmap.de Fri Dec 9 13:38:01 2022 From: dave at sleepmap.de (David Runge) Date: Fri, 9 Dec 2022 13:38:01 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <202212091000.16718.bernhard@intevation.de> References: <202212091000.16718.bernhard@intevation.de> Message-ID: Hi Bernhard, On 2022-12-09 09:59:59 (+0100), Bernhard Reiter wrote: > saw that you had a question about WKD in your blog: > https://sleepmap.de/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168/ > > The reason is that WKD only allows for returning one active public > key. I believe that to be a problematic assumption. More on that below. > a server may return revoked keys in addition to a new key. And there would be a lot of reasons as to why that is good: If I cycle out an old key I want to establish the chain of trust between two keys using cross-signatures. Both (revoked and active) keys need to be returned for someone else to be able to check the chain of trust between a revoked and an active key. We currently use this mechanism in Arch Linux's WKD [1], as we must provide the signatures and revocation of signatures of main signing keys on packager keys not only for active but also for inactive keys (otherwise systems would be able to trust and install packages signed by distrusted keys). In regards to returning multiple active keys and looking at the following text from the draft, I believe that the assumption is problematic: > The HTTP GET method MUST return the binary representation of the > OpenPGP key for the given mail address. If someone loses access to their private key material and can no longer revoke their key, then we must provide both that key and any newer key. In this case there may be two (or more) keys active for a UID at the same time (for a while or indefinitely) and the old one should remain available. It is also possible to have circumstances in which it is desirable to be able to provide two (or more) active keys for a given UID, apart from not being able to revoke an old key. Again using the example of Arch Linux here: If someone loses access to their private key material (e.g. key only available on hardware token) or plainly wants to switch from one key to another, they can not revoke that key right away, as there are still (hundreds of) software packages available in the repositories, signed with that key. Only after establishing a new key and rebuilding all packages with that key (or another verifiable key), the old key can be revoked/ signatures on that key can be revoked. In the meantime, two active keys *must* exist at the same time and the old key, once revoked, must still be available via WKD, as that is the only place where we have full control over the data ourselves. > This makes sense because the idea is that a client can directly use > the key for encryption without asking the user for choice. The client using a pubkey (e.g. a mail program) should have the user choose which key to use once retrieved, if there are multiple active ones, else choose the one that is active. However, the tooling retrieving the key material should not choose for the user which key to grab, but grab all of the available ones for a given UID. Conflating both the retrieval of PGP public keys and the decision making process of which public key to use, without allowing configuration does not only sound unflexible, but also does not allow for the above mentioned use-cases to be covered. This is a problem. > It seems that the version of sequoia-pgp you were using in April does > not implement the WKD draft correctly by providing and downloading > more than one pubkey. > This may have added to your confusion. If the client implementing WKD retrieval already makes implicit choices about which key to retrieve, then that is not correct IMHO, as it also makes assumptions about how the retrieved keys are to be used further. In your described scenario, we would not be able to use WKD in a validation scenario for Arch Linux at all and additional keys besides the currently active (of which there could be several at a given time and from your notes above it would be unclear to me which exact key would be returned) would not be supported. If what you describe above is indeed intended behavior, then I am wondering what the purpose of WKD is, if it can not be fully used for key discovery. It would sound as if PGP + WKD would not be a desirable scenario for Linux distributions to rely on. > Nontheless the intentions could be written more explicit in the WKD > draft, which I have meanwhile suggested to the author. As stated above, I believe that retrieving *all* active keys is what should be done instead. > Regards, > Bernhard > ps.: BTW there is a new group of synchronised pubkey servers, since a while, > e.g. see https://social.tchncs.de/@ber/107008659842900171 Thanks for pointing them out. At least for the Arch Linux infrastructure we have completely migrated away from relying on external keyservers and maintain a curated keyring. The amount of issues we had with them (some don't provide signatures, some don't provide specific key types, others don't provide the pubkeys unless someone acknowledged them, some are only sparsely available, keys are prone to signature poisoning attacks, etc.) did not justify their use. Personally I only publish to keys.openpgp.org and keyserver.ubuntu.com apart from WKD by now, as they seem reasonably large, publicly known and available. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/ -- https://sleepmap.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From bernhard at intevation.de Fri Dec 9 13:58:31 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 9 Dec 2022 13:58:31 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> Message-ID: <202212091358.32298.bernhard@intevation.de> Hi David, Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge: > > The reason is that WKD only allows for returning one active public > > key. > > I believe that to be a problematic assumption. it can be discussed of course if WKD can be improved. But do we agree that the current version-15 only allows one non-revoked key to be delivered? (I'll probably read and respond to the rest of your email next week.) 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 Fri Dec 9 17:39:24 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 9 Dec 2022 16:39:24 +0000 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> Message-ID: On 9 Dec 2022, at 12:38, David Runge wrote: > > In regards to returning multiple active keys and looking at the > following text from the draft, I believe that the assumption is > problematic: > >> The HTTP GET method MUST return the binary representation of the >> OpenPGP key for the given mail address. > > If someone loses access to their private key material and can no longer > revoke their key, then we must provide both that key and any newer key. > In this case there may be two (or more) keys active for a UID at the > same time (for a while or indefinitely) and the old one should remain > available. If you have lost the private key material for a key, you probably should not publish it on WKD, as doing so would only encourage people to encrypt to it. WKD is a key-discovery protocol for email encryption, it is not a general-purpose keyserver replacement. > Again using the example of Arch Linux here: If someone loses access to > their private key material (e.g. key only available on hardware token) > or plainly wants to switch from one key to another, they can not revoke > that key right away, as there are still (hundreds of) software packages > available in the repositories, signed with that key. WKD is not useful for verifying signatures, as it does not support key discovery by fingerprint, only by email. In order to verify an arbitrary signature you must either look up the key by fingerprint on a keyserver that supports it, or distribute a trusted-signers keyring in advance, e.g. by installing a keyring package. 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 neal at walfield.org Fri Dec 9 20:29:14 2022 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 09 Dec 2022 20:29:14 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> Message-ID: <87o7scwf3p.wl-neal@walfield.org> On Fri, 09 Dec 2022 17:39:24 +0100, Andrew Gallagher via Gnupg-devel wrote: > WKD is not useful for verifying signatures, as it does not support key discovery by fingerprint, only by email. In order to verify an arbitrary signature you must either look up the key by > fingerprint on a keyserver that supports it, or distribute a trusted-signers keyring in advance, e.g. by installing a keyring package. A signature can include the 'Signer's User ID' subpacket. If that is included in the signature, then it is possible to use WKD to lookup the certificate. https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3.22 Further, it makes sense to follow up a key server lookup with other lookups like WKD to make it harder for an attacker to withhold some of the certificate (e.g., a revocation). Neal From bernhard at intevation.de Mon Dec 12 11:47:55 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Dec 2022 11:47:55 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> Message-ID: <202212121148.03783.bernhard@intevation.de> Hi David, Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge: > > WKD only allows for returning one active public key. > > I believe that to be a problematic assumption. More on that below. thanks for sharing your crypto use cases from Arch Linux and your feedback how the current WKD contributes to solve them. WKD and other aspects of OpenPGP can be improved, my first step is understanding of the alternatives and discussing them. In this email I respond to what WKD aims for: The design goal of WKD as it is (please see the question in my other email): Establish some minimal trust so that I can encrypt at the first message exchange, and hereby improve the usability of the end to end crypto functionality. The old user experience has been criticised rightfully for making it too hard for users to profit from some basic security attributes. You can read up quite a few of the considerations and arguments at https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept https://wiki.gnupg.org/AutomatedEncryption In the regular cases, user should not have to think about crypto and key pairs. And if they have, the only for important cases (e.g. an attack). So yes, the server and client both have to make some assumptions about how the pubkey distributed via WKD is to be used. A published pubkey via WKD simplified means: * Please use the following pubkey to encrypt a message to me. * You can use this pubkey to check a signature. (but I may have other pubkeys and you may decide otherwise with a good reason.) 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 dashohoxha at gmail.com Mon Dec 12 14:01:28 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 12 Dec 2022 14:01:28 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <202212121148.03783.bernhard@intevation.de> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> Message-ID: On Mon, Dec 12, 2022 at 11:48 AM Bernhard Reiter wrote: > > In this email I respond to what WKD aims for: > > The design goal of WKD as it is (please see the question in my other > email): > Establish some minimal trust so that I can encrypt at the first message > exchange, and hereby improve the usability of the end to end crypto > functionality. The way that I understand WKD (and how I explain it in my presentations) is that it is a way to publish your public keys (share them with your contacts). It is an alternative (and replacement) to the keyserver infrastructure. It is preferred and recommended over the keyservers, since those have some well-known problems. Also it is better than public key exchange by email attachments, since you publish only once and it can be discovered by the clients automatically. Maybe your definition is the same as this one, but formulated differently. On the other hand, if "being a replacement for keyservers" is not one of the aims of WKD, I think that it should become. My opinion is that it *can* be a replacement for keyservers. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Mon Dec 12 15:59:21 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 12 Dec 2022 14:59:21 +0000 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> Message-ID: <1582A680-09AC-4A71-8D37-4F3C56B26063@andrewg.com> On 12 Dec 2022, at 13:01, Dashamir Hoxha via Gnupg-devel wrote: > > On the other hand, if "being a replacement for keyservers" is not one of the aims of WKD, I think that it should become. My opinion is that it *can* be a replacement for keyservers. > WKD is a *partial* replacement for *some* keyserver use cases. It does not cover the following: * Search by fingerprint * Non-email User IDs In addition, only the email domain owner can set up a WKD server, so it will likely never be useful for e.g. GMail addresses. 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 dashohoxha at gmail.com Mon Dec 12 18:49:05 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 12 Dec 2022 18:49:05 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <1582A680-09AC-4A71-8D37-4F3C56B26063@andrewg.com> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <1582A680-09AC-4A71-8D37-4F3C56B26063@andrewg.com> Message-ID: On Mon, Dec 12, 2022 at 3:59 PM Andrew Gallagher wrote: > > WKD is a *partial* replacement for *some* keyserver use cases. > True. But email communication is the most important use case, in my opinion. In addition, only the email domain owner can set up a WKD server, so it > will likely never be useful for e.g. GMail addresses. > If WKD becomes popular and users need it, GMail can implement it, I believe. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From look at my.amazin.horse Mon Dec 12 17:37:16 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 12 Dec 2022 17:37:16 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <202212091000.16718.bernhard@intevation.de> References: <202212091000.16718.bernhard@intevation.de> Message-ID: <0675da00-07db-d333-2f65-173afc2a8947@my.amazin.horse> Hey Bernhard and list, On 09.12.22 09:59, Bernhard Reiter wrote: > The use of _the_ and _a_ key shows that only one public key is to be returned. > This makes sense because the idea is that a client can directly use the key > for encryption without asking the user for choice. I generally agree with this goal. Allowing one address to bind to multiple certificates places a burden on client implementations to make a choice, and folks who work more on the backend side tend to underestimate this in my experience. That is the reason why for keys.openpgp.org we decided to follow WKD and return exactly zero or one certificates per address. However, relatedly we have a new OpenPGP version (probably v6?) on the horizon, and will soon face the issue of migrating users and keys. And that will likely mean supporting at least two certificates (v4+v6) side-by-side for the same address. It's not yet clear to me what the best way is to do that, but one way or another certificate discovery mechanisms such as WKD will have to deal with it. Cheers ?- V From look at my.amazin.horse Mon Dec 12 20:01:19 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 12 Dec 2022 20:01:19 +0100 Subject: OpenPGP compatibility in GnuPG 2.3 Message-ID: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> Hey Werner and list, I had (semi-)recently asked a question on this commit at dev.gnupg.org, and was redirected by Werner to this list. https://dev.gnupg.org/rG4583f4fe2e11b3dd070066628c3f16776cc74f72 If I understood this commit correctly, it turns the behavior that was formerly part of the `--rfc4880bis` flag into the default. Specifically, that means that the packets from [draft-koch-openpgp-2015-rfc4880bis] are now used by default. This commit was merged into master, so my understanding is that it is now in the GnuPG 2.3 release line. The OpenPGP working group has decided on 2022-10-10 to base their revision of the OpenPGP standard on the packet format from crypto-refresh, rather than draft-koch-openpgp-2015-rfc4880bis. As such, the behavior that is made the default by this commit will produce certificates that will be incompatible with the upcoming OpenPGP standard. Given that this commit was merged roughly two weeks after the aforementioned decision, should this be understood that GnuPG intends to focus on its own packet format instead of standardized OpenPGP? It would be interesting to hear what the intent and roadmap of GnuPG are in this regard. Thanks in advance ?- V [draft-koch-openpgp-2015-rfc4880bis]: https://datatracker.ietf.org/doc/draft-koch-openpgp-2015-rfc4880bis/ [decided]: https://mailarchive.ietf.org/arch/msg/openpgp/yayGaIen3DW6ixwrJkP-QcAcFSQ/ From gniibe at fsij.org Tue Dec 13 04:22:49 2022 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 13 Dec 2022 12:22:49 +0900 Subject: [PATCH] add more tests for t-printf and t-strerror In-Reply-To: <20221207205925.1784145-1-pengyi37@huawei.com> References: <20221207205925.1784145-1-pengyi37@huawei.com> Message-ID: <874ju0f0mu.fsf@akagi.fsij.org> Hello, pengyi wrote: > Hi. I found in libgpg-error, the tests/t-strerror.c didn't include > some system error case; the tests/t-printf.c didn't test the > functionality of gpgrt_fwrite() which is also a common API. Thank you. It makes sense. I applied your change, modified slightly, and pushed it. Modifications are: * The string "[==>Niente<==]" is not relevant here, because it's specifically used to represent nullptr in string_filter function, but not here. So, I change it to the famous quote of Zen. * Function calls are formatted in GNU style (space before paren). * Adding missing comma for the variable LIST, using more familiar values of errors. https://dev.gnupg.org/rE72e0fb3fc858301de7b200e1c08da6904ab44bc0 If you intend to contribute to GnuPG and/or libgcrypt, please consider to send us your DCO. -- From bernhard at intevation.de Tue Dec 13 09:35:22 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Dec 2022 09:35:22 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> Message-ID: <202212130935.30386.bernhard@intevation.de> Hi Vincent, > Given that this commit was merged roughly two weeks after the > aforementioned decision, should this be > understood that GnuPG intends to focus on its own packet format instead > of standardized OpenPGP? the working group has not yet come up with a needed refresh for many years. It has to be seen if whatever the IETF workgroup comes up with is a good update to RFC4880. (At least this is my personal view on this, I am not really involved in GnuPG's nor in the working group's work in this area.) In previous IETF OpenPGP standardisation processes, it seems that well working practice was considered to a large extend, it seems natural up to a point to try and see if new things are needed and useful. (Same as you did when you have decided to made keys.openpgp.org incompatible to the existing OpenPGP standard, by not adding the necessary signature, see https://dev.gnupg.org/T4393 and blame it as defect on your page https://keys.openpgp.org/about/faq) I am referring to this, because I do not like the insinuation of your email that GnuPG would be aiming to be incompatible while you and other members of the working group did so themselves to a larger extend in the past. I do not think that this kind of "questioning" from your email is helpful for a constructive way forward. 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 bernhard at intevation.de Tue Dec 13 09:39:03 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Dec 2022 09:39:03 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <0675da00-07db-d333-2f65-173afc2a8947@my.amazin.horse> References: <202212091000.16718.bernhard@intevation.de> <0675da00-07db-d333-2f65-173afc2a8947@my.amazin.horse> Message-ID: <202212130939.03592.bernhard@intevation.de> Hi Vincent, Am Montag 12 Dezember 2022 17:37:16 schrieb Vincent Breitmoser via Gnupg-devel: > However, relatedly we have a new OpenPGP version (probably v6?) on the > horizon, will this be incompatible to old package versions and why? (Sorry could not resist, see my other email). > and will soon face the issue of migrating users and keys. And > that will likely mean supporting at least two certificates (v4+v6) > side-by-side for the same address. Another solution for WKD could be to wait with the migration until a large majority of implementations can deal with the new format and then still deliver one active pubkey. 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 bernhard at intevation.de Tue Dec 13 09:44:15 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Dec 2022 09:44:15 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> Message-ID: <202212130944.15657.bernhard@intevation.de> Hi Dashamir, Am Montag 12 Dezember 2022 14:01:28 schrieb Dashamir Hoxha via Gnupg-devel: > The way that I understand WKD (and how I explain it in my presentations) is > that it is a way to publish your public keys (share them with your > contacts). It is an alternative (and replacement) to the keyserver > infrastructure. then it is good that we have this discussion as a reminder: The current WKD draft-15 (and all previous drafts as far as I remember) allow only one active pubkey to be returned. Whatever WDK Can be in the future (which is to be discussed), as long as it is one pubkey, I hope we explain and implement it like this. (Otherwise we risk other problems.) 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 neal at walfield.org Tue Dec 13 10:07:07 2022 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 13 Dec 2022 10:07:07 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212130935.30386.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> Message-ID: <87mt7rwu2s.wl-neal@walfield.org> On Tue, 13 Dec 2022 09:35:22 +0100, Bernhard Reiter wrote: > (Same as you did when you have decided to made keys.openpgp.org incompatible > to the existing OpenPGP standard, by not adding the necessary signature, see > https://dev.gnupg.org/T4393 and blame it as defect on your page > https://keys.openpgp.org/about/faq) I think you are misreading the standard here. My reading of 4880 is the grammar for certificates explicitly says that self signatures on User ID packets are optional: - One or more User ID packets - After each User ID packet, zero or more Signature packets (certifications) ... Immediately following each User ID packet, there are zero or more Signature packets. https://www.rfc-editor.org/rfc/rfc4880#section-11.1 So, I think gpg's behavior diverges from the standard here. Can you point me to the text in 4880 that supports your view that User IDs must have self signatures? Thanks, Neal From bernhard at intevation.de Tue Dec 13 10:08:44 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Dec 2022 10:08:44 +0100 Subject: OpenPGP use cases for Arch (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> Message-ID: <202212131008.52852.bernhard@intevation.de> Hi David, == use case key rollover Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge: > If I cycle out an old key I want to establish the chain of trust between > two keys using cross-signatures. Both (revoked and active) keys need to > be returned for someone else to be able to check the chain of trust > between a revoked and an active key. it may also be possible that a user already has the old pubkey, including some established trust. It this is not the case, there is no additional trust gained, by getting the old pubkey via the same channel. One idea of using different channels for building trust for pubkeys is that an attacker would have to compromise several points in the instructure. So it can be a plus if the old pubkey has been found and verified earlier in the case of key-rollover. > We currently use this mechanism in Arch Linux's WKD [1], as we must > provide the signatures and revocation of signatures of main signing keys > on packager keys not only for active but also for inactive keys > (otherwise systems would be able to trust and install packages signed by > distrusted keys). (This usage of WKD seems okay, as long as the inactive pubkeys are revoked for other reasons than "compromised", see reasons in https://datatracker.ietf.org/doc/html/rfc4880#section-5-2-3-23 ) == lost access to private key (and needs rollover) > If someone loses access to their private key material and can no longer > revoke their key, then we must provide both that key and any newer key. > In this case there may be two (or more) keys active for a UID at the > same time (for a while or indefinitely) and the old one should remain > available. As Andrew has pointed out: Still promoting a pubkey where the private part was lost, seems a bad idea. The superceded one should be put out of use as fast as possible. BTW: I believe that modern GnuPG versions create a revocation certificate by default, which sometimes is still in a backup and can be used, even if the private material is lost. So I consider this case quite unlikely, it would be embarassing for any party to admit that they have lost the revocation certificate. == retiring a key, with old signature still out there > wants to switch from one key to another, they can not revoke > that key right away, as there are still (hundreds of) software packages > available in the repositories, signed with that key. According to the OpenPGP standard RFC4880 "old signatures are still valid" if the revocation reasons "superceded" or "retired" are given. However I do not know if implementation always honors this in practice. If they do, this use case seems feasable. It is a general problem with verification of cryptographic signatures which have been created in the past. == distributing additional pubkeys > In your described scenario, we would not be able to use WKD in a > validation scenario for Arch Linux at all and additional keys besides > the currently active (of which there could be several at a given time > and from your notes above it would be unclear to me which exact key > would be returned) would not be supported. To summarise my thinking (which will have flaws as always, which I hope someone will point out) up to this point: WKD shall distribute the one recommended pubkey to use for new communication (or verification). And because of this, it can be used for bringing in basic trust and making the whole trust building more robust. If in the Arch Linux case, this new pubkey would sign the elder ones (active and inactive) it gives them basic trust. Can you sign the existing pubkey package always with the recommended key? Then you could distribute other active keys with this package. If users need higher trust levels, they will have elder pubkeys and have verified them, so for old active keys, they can sign the recommended pubkey distributed with WKD and thus add to the basic trust. What I see as advantage in this scenario is that if the WKD server is compromised, publishing a new pubkey under Mary's control, users with higher security needs could detect this as the signature of the old keys is missing. Does this make sense to you? 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 Tue Dec 13 12:02:41 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 13 Dec 2022 11:02:41 +0000 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212130935.30386.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> Message-ID: Hi, Bernhard. On 13 Dec 2022, at 08:35, Bernhard Reiter wrote: > > Hi Vincent, > >> Given that this commit was merged roughly two weeks after the >> aforementioned decision, should this be >> understood that GnuPG intends to focus on its own packet format instead >> of standardized OpenPGP? > > the working group has not yet come up with a needed refresh for many years. > It has to be seen if whatever the IETF workgroup comes up with > is a good update to RFC4880. (At least this is my personal view on this, I am > not really involved in GnuPG's nor in the working group's work in this area.) ?It remains to be seen? is the crucial phrase there. Making 4880-bis the default behaviour in master appears to be prejudging the outcome of the standardisation process, with potentially damaging consequences for the wider ecosystem. 4880-bis differs in some crucial places, making it incompatible with the current WG draft. If GnuPG chose 4880-bis instead of the new RFC (whatever it may be), then other implementations would have to choose whether to support 4880-bis as an extra compatibility mode, break compatibility with GnuPG going forward, or find themselves bounced into abandoning the RFC process. None of those outcomes would be desirable. Several people have asked for clarification on a number of occasions but none appears to be forthcoming. Vincent?s question is valid, and we should be careful not to derail this thread with other arguments. 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 look at my.amazin.horse Tue Dec 13 12:07:20 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 13 Dec 2022 12:07:20 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212130935.30386.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> Message-ID: <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> Hey Bernhard, On 13.12.22 09:35, Bernhard Reiter wrote: > the working group has not yet come up with a needed refresh for many years. > It has to be seen if whatever the IETF workgroup comes up with > is a good update to RFC4880. (At least this is my personal view on this, I am > not really involved in GnuPG's nor in the working group's work in this area.) I'm not sure how you would qualify a "good" update here? If there is a new revision it'll be the standard by definition, and you can conform to it or not. If you have doubts it will be a "good" update, they are currently asking for a last round of feedback on it. > In previous IETF OpenPGP standardisation processes, it seems that well working > practice was considered to a large extend, it seems natural up to a point to > try and see if new things are needed and useful. Agreed. That's what the --rfc4880bis flag did, and reasonably so. But unless I misread the commit, we're talking about GnuPG emitting a GnuPG-specific certificate format by default here, so no experiment by any means? > (Same as you did when you have decided to made keys.openpgp.org incompatible > to the existing OpenPGP standard Indeed, so I did. Notably the way we made it incompatible was fairly widely discussed and thought acceptable, so much so that it was included in the [rfc4880bis-05] draft Werner specified at the time, and is now also so in the [crypto-refresh-07] draft. Should also mention that the breakage here is something that can be adapted to in GnuPG by a five lines patch, which is not quite the same as a major version step of the OpenPGP message format. What's more important however is that we were always open about this decision, gave the specific reasoning and plans, and discussed it with anyone who was interested, and did active outreach about it. Doesn't mean we ended up agreeing on the issue, but c'est la vie. > I am referring to this, because I do not like the insinuation of your email > that GnuPG would be aiming to be incompatible I'm not insinuating anything, I'm openly pointing out a commit that changes GnuPG default behavior in a significant way, and asking what the plans here are. Cheers ?- V [rfc4880bis-05]: https://gitlab.com/openpgp-wg/rfc4880bis/-/blob/main/old-drafts/draft-ietf-openpgp-rfc4880bis-05.txt#L4587 [T4393]: https://dev.gnupg.org/T4393#136751 [crypto-refresh-07]: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#section-11.1.2 From neal at walfield.org Tue Dec 13 12:33:35 2022 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 13 Dec 2022 12:33:35 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <87mt7rwu2s.wl-neal@walfield.org> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <87mt7rwu2s.wl-neal@walfield.org> Message-ID: <87k02vwnao.wl-neal@walfield.org> On Tue, 13 Dec 2022 10:07:07 +0100, Neal H. Walfield wrote: > > On Tue, 13 Dec 2022 09:35:22 +0100, > Bernhard Reiter wrote: > > (Same as you did when you have decided to made keys.openpgp.org incompatible > > to the existing OpenPGP standard, by not adding the necessary signature, see > > https://dev.gnupg.org/T4393 and blame it as defect on your page > > https://keys.openpgp.org/about/faq) > > I think you are misreading the standard here. My reading of 4880 is > the grammar for certificates explicitly says that self signatures on > User ID packets are optional: > > - One or more User ID packets > > - After each User ID packet, zero or more Signature packets > (certifications) > > ... > > Immediately following each User ID packet, there are zero or more > Signature packets. > > https://www.rfc-editor.org/rfc/rfc4880#section-11.1 > > So, I think gpg's behavior diverges from the standard here. > > Can you point me to the text in 4880 that supports your view that User > IDs must have self signatures? It was pointed out to me privately that there are actually two issues: 1. User ID-less certificates (out of spec) 2. User IDs without self signatures (in spec) 4880 allows User IDs without self signatures (2), but it does require that a certificate include at least one User ID, which needn't have a self-signature. koo is out of spec, because it delivers certificates without User IDs (1). It come into spec by inserting a null User ID without a self signature (2). As I understand it, gpg would treat that (2) the same way as it treats a certificate without any User IDs (1). Neal From bernhard at intevation.de Tue Dec 13 12:33:42 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Dec 2022 12:33:42 +0100 Subject: Does RFC4880 require a (self)-signature on the mandatory User ID packet? In-Reply-To: <87mt7rwu2s.wl-neal@walfield.org> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <87mt7rwu2s.wl-neal@walfield.org> Message-ID: <202212131233.58000.bernhard@intevation.de> Am Dienstag 13 Dezember 2022 10:07:07 schrieb Neal H. Walfield: > On Tue, 13 Dec 2022 09:35:22 +0100, Bernhard Reiter wrote: > > incompatible to the existing OpenPGP standard, by not adding the > > necessary signature, see https://dev.gnupg.org/T4393 and blame it as > > defect on your page > > https://keys.openpgp.org/about/faq) I was not precise enough, I've meant "not distributing the user ids" (and assuming that a useful user ID packet has a self-signature.) Thanks for pointing this out and sorry for the confusion. > I think you are misreading the standard here. My reading of 4880 is > the grammar for certificates explicitly says that self signatures on > User ID packets are optional: > > - One or more User ID packets > Can you point me to the text in 4880 that supports your view that User > IDs must have self signatures? The RFC mandates at least one User ID Packet. Do you think the single User ID packet is useful without any (self-)signature? Thanks, 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 simon at josefsson.org Tue Dec 13 13:17:53 2022 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 13 Dec 2022 13:17:53 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <202212130944.15657.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 13 Dec 2022 09:44:15 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> Message-ID: <87wn6vbiq6.fsf@josefsson.org> Bernhard Reiter writes: > Hi Dashamir, > > Am Montag 12 Dezember 2022 14:01:28 schrieb Dashamir Hoxha via Gnupg-devel: >> The way that I understand WKD (and how I explain it in my presentations) is >> that it is a way to publish your public keys (share them with your >> contacts). It is an alternative (and replacement) to the keyserver >> infrastructure. > > then it is good that we have this discussion as a reminder: > The current WKD draft-15 (and all previous drafts as far as I remember) > allow only one active pubkey to be returned. > > Whatever WDK Can be in the future (which is to be discussed), > as long as it is one pubkey, I hope we explain and implement it like this. > (Otherwise we risk other problems.) This thread was useful to me to understand that there really are two conflicting desired features here: 1) Use WDK to map ONE email address to ONE public key to use for email. 2) Use WDK to find ALL public keys for an email address. These are really two different use-cases, and as WDK looks now it seems it was tailored towards 1) but many people (myself included) use it for 2) since that is how you traditionally used OpenPGP keyservers, and people (myself included) like that semantics and is not ready to switch to the WDK approach of trusting the WDK mapping to produce the ONE key to use. I have to admit that I had not understood this difference until now, I thought WDK mainly was a key-server-replacement proposal. I have argued before that WDK should be modified to allow returning more than one key. I can see now why that request has not been honored: it breaks the use-case 1) above. I don't think we can or should convince people that the semantics with 1) is bad and should't be specified or implemented. To the contrary: it seems very important to allow the functionality of 1) for simple bootstrapping of encrypted email. However maybe what we can achieve is that WDK could ALSO cater to the use-case of 2). What do you think? If people who work on WDK find it acceptable to cater to people wanting the semantics of 2) while still supporting the use-case of 1) how about specifying that a plural-version of the URL returns all keys? So let's assume we have this URL to return one public key only: https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 Then we could standardize the following (note plural 's') to return ALL keys for the given email address: https://intevation.de/.well-known/openpgpkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 Alternatively, we could use URL parameters on the first URL like this: https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4?allkeys Or perhaps a compromise -- based on the observation that registering multiple 'well-known' protocols has a cost, and that URL parameters like '?allkeys' works badly with HTTPS servers serving static content, how about a URL like this: https://intevation.de/.well-known/openpgpkey/allkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 This would signal that the server should return all known keys associated with a particular email-address. While migrating to new keys is a complicated matter, at least this allows WDK to play a part of this by serving multiple keys for the same email address. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From gnupg at eckner.net Tue Dec 13 17:13:55 2022 From: gnupg at eckner.net (Erich Eckner) Date: Tue, 13 Dec 2022 17:13:55 +0100 (CET) Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87wn6vbiq6.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: On Tue, 13 Dec 2022, Simon Josefsson via Gnupg-devel wrote: > This thread was useful to me to understand that there really are two > conflicting desired features here: > > 1) Use WDK to map ONE email address to ONE public key to use for > email. > > 2) Use WDK to find ALL public keys for an email address. > [ ... snip ... ] > However maybe what we can achieve is that WDK could ALSO cater to the > use-case of 2). What do you think? just a quick comment: your proposal looks ok to me for WKD - but what about WKS? One would need a protocol to remove "old" keys from the "all keys" bundle. Does WKS already come with a mechanism for that? Or does it currently rely on replacing the old key with a new one? [ ... snip ... ] > > /Simon > regards, Erich From dashohoxha at gmail.com Tue Dec 13 22:32:59 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 13 Dec 2022 22:32:59 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87wn6vbiq6.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: On Tue, Dec 13, 2022 at 1:59 PM Simon Josefsson via Gnupg-devel < gnupg-devel at gnupg.org> wrote: > > 1) Use WDK to map ONE email address to ONE public key to use for > email. > > 2) Use WDK to find ALL public keys for an email address. > The second case, as you describe it, seems to be orthogonal to the first one, in the sense that they are independent of each-other. So, it can be implemented as a separate protocol. But probably it makes more sense to implement it as an extension of the current WKD protocol. specifying that a plural-version of the URL returns all keys? So let's > assume we have this URL to return one public key only: > > > https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 > > Then we could standardize the following (note plural 's') to return ALL > keys for the given email address: > > > https://intevation.de/.well-known/openpgpkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 > > Alternatively, we could use URL parameters on the first URL like this: > > > https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4?allkeys > > Or perhaps a compromise -- based on the observation that registering > multiple 'well-known' protocols has a cost, and that URL parameters like > '?allkeys' works badly with HTTPS servers serving static content, how > about a URL like this: > > > https://intevation.de/.well-known/openpgpkey/allkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 Does it make sense to look for a public key by its id? I mean something like this: https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9 There are two differences with the current well-known url: 1. Instead of "/hu/" (which means hashed-userid), there is "/id/" (which means the key id). 2. Instead of "it5sewh54rxz33fwmr8u6dy4bbz8itz4" which is the hash of "alice" (in case that the userid is "alice at intevation.de"), there is "847FC5C4337D9CDBD473B7A60967FD258D6414F9" which is the id of the key. In this case a client can easily ask for the public key that is needed to verify a certain signature. However I am not sure, can we find out the userids of the key that is used to sign? If not, then we cannot infer the domain of the well-known url. In this case we might need a directory service to lookup the userid(s) that are associated with a certain key id (think of it like a phone book -- you know the phone number and you can find the name of its owner). This directory service might be based on blockchains, or it might be a modified (simplified?) version of the current keyservers. However, if we have such a directory service, then we can just list the url where the public key is located, so maybe we don't need a "well-known url" format. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Tue Dec 13 22:44:25 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 13 Dec 2022 22:44:25 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: On Tue, Dec 13, 2022 at 5:54 PM Erich Eckner via Gnupg-devel < gnupg-devel at gnupg.org> wrote: > > > However maybe what we can achieve is that WDK could ALSO cater to the > > use-case of 2). What do you think? > > just a quick comment: your proposal looks ok to me for WKD - but what > about WKS? One would need a protocol to remove "old" keys from the "all > keys" bundle. Does WKS already come with a mechanism for that? Or does it > currently rely on replacing the old key with a new one? > As far as I understand, WKS is optional. It is one of the ways to build and manage a WKD. But you can also build a WKD manually, or use a web form (with authentication) where users can submit their key, etc. So, despite the way that WKS works, it cannot be an obstacle for the second use case. Can WKS be extended to cover the second use case? Maybe not; but it doesn't have to. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Wed Dec 14 09:55:30 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 14 Dec 2022 09:55:30 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: <5632828.DvuYhMxLoT@daneel> On Dienstag, 13. Dezember 2022 22:32:59 CET Dashamir Hoxha via Gnupg-devel wrote: > Does it make sense to look for a public key by its id? For WKD? No, it doesn't. For (at least) two reasons: a) A major idea of WKD is that the owner of a domain is trustworthy and therefore you can put initial trust in the keys retrieved for email addresses for this domain. b) How would you know which of the thousands (millions?) of domains to ask for the key by id? WKD is not a replacement for keyservers. It's an addition which eases the lookup of encryption keys by email address. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Wed Dec 14 11:31:40 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 Dec 2022 10:31:40 +0000 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: <2BE69EB4-63F1-44AF-9AA0-612BC16BE14D@andrewg.com> On 13 Dec 2022, at 21:32, Dashamir Hoxha via Gnupg-devel wrote: > > However I am not sure, can we find out the userids of the key that is used to sign? If not, then we cannot infer the domain of the well-known url. See Neal?s earlier comment. We can in principle, but only if the signer has added that subpacket to their signature, which cannot be relied upon. > In this case we might need a directory service to lookup the userid(s) that are associated with a certain key id (think of it like a phone book -- you know the phone number and you can find the name of its owner). This directory service might be based on blockchains, or it might be a modified (simplified?) version of the current keyservers. If you think keyservers are prone to abuse and spam, you *do not* want a blockchain. > However, if we have such a directory service, then we can just list the url where the public key is located, so maybe we don't need a "well-known url" format. Or we could just serve the key directly from the directory? ;-) A -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Wed Dec 14 12:20:40 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 14 Dec 2022 12:20:40 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <2BE69EB4-63F1-44AF-9AA0-612BC16BE14D@andrewg.com> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <2BE69EB4-63F1-44AF-9AA0-612BC16BE14D@andrewg.com> Message-ID: On Wed, Dec 14, 2022 at 11:31 AM Andrew Gallagher wrote: > However I am not sure, can we find out the userids of the key that is used > to sign? If not, then we cannot infer the domain of the well-known url. > > > See Neal?s earlier comment. We can in principle, but only if the signer > has added that subpacket to their signature, which cannot be relied upon. > Thanks for pointing this out. I did see the Neal's message but did not grasp its meaning. https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035177.html Indeed, when we sign something, we can also include the user's id with the option "--sender": https://www.gnupg.org/documentation/manuals/gnupg/GPG-Key-related-Options.html For example: `gpg --sign -a --sender alice at example.com file-to-be-signed` If the signer wants the people to be able to verify his signature, then he can certainly include his ID on the signature. We can rely on this. The client that is trying to verify the signature can find both the key id and the user id, so he can construct a valid well-known url for retrieving the public key. In this case we might need a directory service to lookup the userid(s) that > are associated with a certain key id (think of it like a phone book -- you > know the phone number and you can find the name of its owner). This > directory service might be based on blockchains, or it might be a modified > (simplified?) version of the current keyservers. > > > If you think keyservers are prone to abuse and spam, you *do not* want a > blockchain. > You are right. A blockchain may not be able to ensure even the uniqueness of the published key (several records for the same key id, and you don't know which one is valid). Probably other problems as well. However, if we have such a directory service, then we can just list the url > where the public key is located, so maybe we don't need a "well-known url" > format. > > > Or we could just serve the key directly from the directory? ;-) > It is not the same, in my opinion, because you cannot delete the key from a keyserver, but you can delete the key from a web directory (which is under your control). Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Dec 14 13:42:57 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 Dec 2022 12:42:57 +0000 Subject: WKD: returns only one pubkey (and why) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <2BE69EB4-63F1-44AF-9AA0-612BC16BE14D@andrewg.com> Message-ID: <7E5B8E93-D7A0-4178-BFC6-EF6F6BD7A3D3@andrewg.com> On 14 Dec 2022, at 11:20, Dashamir Hoxha wrote: > > If the signer wants the people to be able to verify his signature, then he can certainly include his ID on the signature. We can rely on this. The client that is trying to verify the signature can find both the key id and the user id, so he can construct a valid well-known url for retrieving the public key. That?s not what I meant by ?rely upon?. The sender subpacket is not mandatory, therefore we must still handle cases where it doesn?t exist. >>> However, if we have such a directory service, then we can just list the url where the public key is located, so maybe we don't need a "well-known url" format. >> >> >> Or we could just serve the key directly from the directory? ;-) > > It is not the same, in my opinion, because you cannot delete the key from a keyserver, but you can delete the key from a web directory (which is under your control). That depends on the keyserver. You can?t delete a key from sks-keysever, but almost nobody runs that any more. Other keyservers do implement some form of deletion (although the UX currently isn?t great). A hypothetical ?indirect" keyserver could send you to the authoritative source; or it could just cache the contents of the authoritative source and serve it directly (no less trustworthy, and slightly more robust). A -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Thu Dec 15 09:11:24 2022 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Dec 2022 09:11:24 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: (Erich Eckner via Gnupg-devel's message of "Tue, 13 Dec 2022 17:13:55 +0100 (CET)") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: <87r0x1gk7n.fsf@josefsson.org> Erich Eckner via Gnupg-devel writes: > On Tue, 13 Dec 2022, Simon Josefsson via Gnupg-devel wrote: > >> This thread was useful to me to understand that there really are two >> conflicting desired features here: >> >> 1) Use WDK to map ONE email address to ONE public key to use for >> email. >> >> 2) Use WDK to find ALL public keys for an email address. >> > > [ ... snip ... ] > >> However maybe what we can achieve is that WDK could ALSO cater to the >> use-case of 2). What do you think? > > just a quick comment: your proposal looks ok to me for WKD - but what > about WKS? One would need a protocol to remove "old" keys from the > "all keys" bundle. Does WKS already come with a mechanism for that? Or > does it currently rely on replacing the old key with a new one? I'm not familiar with WKS so I don't have an opinion -- it looks like WKS was tailored towards the use-case 1) above, and I'm not sure a WKS-like protocol is useful for the use-case of 2) at all. It is not important for me at least: I just want to self-publish all trusted keys for my email address and have a protocol to specify that people should trust them, if they trust the DNS hierarchy and the HTTPS retrieval mechanism. I'm not using WKS. I'm hoping WDK could be this, but otherwise a separate protocol is needed with that semantics. Complexity is a always a security risk, so I could see the argument to declare this out of scope for WDK, but I could also easily see some small changes made to support this scenario. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From bernhard at intevation.de Thu Dec 15 09:21:41 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Dec 2022 09:21:41 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <87k02vwnao.wl-neal@walfield.org> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <87mt7rwu2s.wl-neal@walfield.org> <87k02vwnao.wl-neal@walfield.org> Message-ID: <202212150921.41792.bernhard@intevation.de> Am Dienstag 13 Dezember 2022 12:33:35 schrieb Neal H. Walfield: > koo is out of spec, because it delivers certificates without User IDs > (1). ?It come into spec by inserting a null User ID without a self > signature (2). Though that seems to be a mechanistic compliance, which does not make much sense. So I'd still consider this out of speficiation because the user ID would be useless and obviously not performing the intentions expressed in RFC4880. > As I understand it, gpg would treat that (2) the same > way as it treats a certificate without any User IDs (1). If this is the case (which I do not know for sure), it looks like a good decision for an implementation which stays in line with the purpose of what the User ID was meant for in the specification (and real use). 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 bernhard at intevation.de Thu Dec 15 09:44:21 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Dec 2022 09:44:21 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> Message-ID: <202212150944.28114.bernhard@intevation.de> Hi Andrew, Am Dienstag 13 Dezember 2022 12:02:41 schrieb Andrew Gallagher via Gnupg-devel: > ?It remains to be seen? is the crucial phrase there. Making 4880-bis the > default behaviour in master appears to be prejudging the outcome of the > standardisation process, with potentially damaging consequences for the > wider ecosystem. 4880-bis differs in some crucial places, making it > incompatible with the current WG draft. however you could ask the same questions to the WG: Why are they attempting to standardise variants that one of the main contributor to OpenPGP does not see as favourable to OpenPGP? Real usage has been an important factor to standardisation. The very long process of the WG let me conclude that there were some problems with it. I have not put in the time to look into the details, so I do not know, but just with a bit of distance something does not work out there. I do not know how much technical need there is to go beyond RFC4880 (and other RFCs) and if standardisation processes do not work out, implementations will go ahead, sometimes they even must. It can be a good thing. Dragging something out in a committee in genernal can also wear those players thin that care more for the technical part and are less well funded. Again I do not know if this is happening with the IETF WG, just pointing to a general pattern and that would match to sime extend to that what is observable from a distance. > If GnuPG chose 4880-bis instead of the new RFC (whatever it may be), then > other implementations would have to choose whether to support 4880-bis as > an extra compatibility mode, break compatibility with GnuPG going forward, > or find themselves bounced into abandoning the RFC process. None of those > outcomes would be desirable. It is in my interest to have an interoperable specification and get good end-to-end crypto implementations to users. Being associated with GnuPG/Gpg4win on the business side via my company as well, I want it to be treated fairly. I welcome competition, especially if it is Free Software and we work together towards makeing the work better for users. In recent years the field has gotten more difficult with some exchanges that I did not find fair. This is why I've jumped on this question, I am not sure that I, if I was Werner, would put in the time to answer it. Partly because it is placed and framed in a way that does not seem to seek understanding and cooperation, but to make GnuPG look bad. Why would someone answer that? > Several people have asked for clarification on a number of occasions but > none appears to be forthcoming. (BTW if those exchanges are publically available, can you point me to them?) > Vincent?s question is valid, and we should > be careful not to derail this thread with other arguments. I assume Werner has explained his plans to the WG over many years. (At least he wrote a lot of the drafts and participated.) Why does he has the burden to explain why this technically does not go together anymore? Overal I believe the way how this is asked and understood from the persons begin asked, is decisive for how they answer. 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 bernhard at intevation.de Thu Dec 15 10:11:30 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Dec 2022 10:11:30 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> Message-ID: <202212151011.43895.bernhard@intevation.de> Hey Vincent, Am Dienstag 13 Dezember 2022 12:07:20 schrieb Vincent Breitmoser via Gnupg-devel: > On 13.12.22 09:35, Bernhard Reiter wrote: > > It has to be seen if whatever the IETF workgroup comes up with > > is a good update to RFC4880. > I'm not sure how you would qualify a "good" update here? something that is useful to users (in the end) and updated RFC4880 in an interoperable and technical good way for asychronous, end-to-end cryptopgraphy. (Rough, I know, but maybe good enough for this post.) > If there is a new revision it'll be the standard by definition, > and you can conform to it or not. It still maybe a bad revision. And yes, this comes down to the question of who will be able to shape and define what OpenPGP is. Usage has always had an important influence on evolving standards, this is why I have added the case of your koo deliberate incompatibility to RFC4480 as an example. > If you have doubts it will be a "good" update, they are currently asking > for a last round of feedback on it. To put time into the committee work personally I would need to be convinced that it is well invested time. Given that Werner, Niibe-San and others will have given technical feedback already, I am not sure if it is worth the time. (See my answer to Andrew for more elaboration.) > > In previous IETF OpenPGP standardisation processes, it seems that well > > working practice was considered to a large extend, it seems natural up to > > a point to try and see if new things are needed and useful. > > Agreed. That's what the --rfc4880bis flag did, and reasonably so. But > unless I misread the commit, we're talking about GnuPG emitting a > GnuPG-specific certificate format by default here, so no experiment by any > means? I don't know. But what were the reasons the current working group did decide to go with a different package format? Do you think it was the better choice? > > (Same as you did when you have decided to made keys.openpgp.org > > incompatible to the existing OpenPGP standard > > Indeed, so I did. [rest of the example cut out] > I'm not insinuating anything, I'm openly pointing out a commit that changes > GnuPG default behavior in a significant way, and asking what the plans here > are. When I have read your email, the subject and the "will be incompatible with the upcoming OpenPGP standard." and your remark at https://dev.gnupg.org/rG4583f4fe2e11b3dd070066628c3f16776cc74f72#75449 leans my understanding towards a non constructive question, because it frames the burden of answering it onto GnuPG's devs. It is the little things in your phrasing a) The WG does not yet has a new spec on "OpenPGP" only proposal. b) The WG does not define alone what "OpenPGP" is in the wild. And the framing and omissions: c) you do understand that there are good reasons for going ahead in an implementation, even if it is not ahereing to the standardised protocols. But you are not displaying that you have given the potential reasons a deep thought in the question or on the list here. d) You do not explain or ask what and why the WG is going a way to be incompatible to a useful and widely deployed implementation (and long time contributors to the WGs.) 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 bernhard at intevation.de Thu Dec 15 10:43:06 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Dec 2022 10:43:06 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <87wn6vbiq6.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> Message-ID: <202212151043.13759.bernhard@intevation.de> Am Dienstag 13 Dezember 2022 13:17:53 schrieb Simon Josefsson via Gnupg-devel: > This thread was useful to me to understand that there really are two > conflicting desired features here: > > 1) Use WDK to map ONE email address to ONE public key to use for > email. > > 2) Use WDK to find ALL public keys for an email address. > > These are really two different use-cases, and as WDK looks now it seems > it was tailored towards 1) but many people (myself included) use it for > 2) since that is how you traditionally used OpenPGP keyservers, and > people (myself included) like that semantics and is not ready to switch > to the WDK approach of trusting the WDK mapping to produce the ONE key > to use. Thanks for the good summary. > I have to admit that I had not understood this difference until > now, I thought WDK mainly was a key-server-replacement proposal. Some history: When WKD was designed in 2016 [1], the old (aka SKS) keyservers where not yet in big trouble if I remember correctly, so there was less need for case 2). Another design goal was simplicity (often called "lean" in process speak) to allow for an easier uptake. So further uses are were not ruled out, but the most important design goal(s) for the main user experience should be reached quickly. > I have argued before that WDK should be modified to allow returning more > than one key. I can see now why that request has not been honored: it > breaks the use-case 1) above. I don't think we can or should convince > people that the semantics with 1) is bad and should't be specified or > implemented. To the contrary: it seems very important to allow the > functionality of 1) for simple bootstrapping of encrypted email. > > However maybe what we can achieve is that WDK could ALSO cater to the > use-case of 2). What do you think? So far I am still makeing up my mind. A few thoughts: Given that we want a pubkey exchange even without email provider and email addresses, the next important thing I see is to improve the keyservers. (To allow carrying third party signatures again.) Being forced to use different channels for other pubkeys, except the current active one, has its merits: it may potentially help to detect malice done to the email provider's web server infrastructure. In addition the calculation of trust for several pubkeys has to become better in implementations, if not just for cases of key rollover. Also for detecting attacks and to cater for different levels of security needs. If there is a good calculation of trust, you could get the currently active pubkey and then sign others with it, which could be fetched elsewhere (keyserver, homepage, etc.). If so, one current pubkey via WKD could be enough to jumpstart 2). == Ways to deliver several pubkeys via WKD Again thanks for the technical ideas. Two more ideas: a) Allow for several pubkeys to be returned, but indicate which one is the "primary" one among the active ones. Could be the order, could be something else. However should be easy to use from the client side (and is potentially not backwards compatible :/ ). b) Add an URL somehow (maybe as pubkey user attribute) for the other pubkeys to be fetched. Best, Bernhard [1] https://wiki.gnupg.org/EasyGpg2016 has details, I was part of the team. -- 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 bernhard at intevation.de Thu Dec 15 11:07:54 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 Dec 2022 11:07:54 +0100 Subject: Allowing import of pubkeys without User ID (was: potential IETF WG incompatibility with GnuPG 2.3) In-Reply-To: <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> Message-ID: <202212151108.08889.bernhard@intevation.de> Hi Vincent, [splitted out, because the details of the example are not important to the main discussion point where it was made] https://dev.gnupg.org/T4393 Am Dienstag 13 Dezember 2022 12:07:20 Vincent wrote: > Notably the way we made it incompatible was fairly widely > discussed and thought acceptable, so much so that it was included in the > [rfc4880bis-05] draft Werner specified at the time, and is now also so > in the [crypto-refresh-07] draft. > Should also mention that the breakage here is > something that can be adapted to in GnuPG by a five lines patch, which is > not quite the same as a major version step of the OpenPGP message format. Two and a half years ago, I've started getting this process going again or at least see where the disagreement is in detail. As you can see in https://dev.gnupg.org/T4393 it has not been followed up a lot by koo people. And the last anwer in https://keys.openpgp.org/about/faq does not represent the situation fairly. It introduces the term "bug" and leaves the impression that GnuPG team is on the wrong here. A nicer way to phrase it would be "Why is that so?" or "What can be the reason?". It would be cool if the reasons given (e.g. in T4293) were explained in the FAQ so to show the disagreement in more detail. The patch in T4393 was not a five lines patch and the suggested way forward was not followed up (as far as I know). As you have written, it looked like the change could have been made. Addressing some of the concerns of the GnuPG team or at least repesenting the concerns in a respectful way can help (I believe). 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 Thu Dec 15 12:12:54 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Dec 2022 11:12:54 +0000 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212150944.28114.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <202212150944.28114.bernhard@intevation.de> Message-ID: <25815376-1A0E-42D8-8493-567D0D8515E2@andrewg.com> On 15 Dec 2022, at 08:44, Bernhard Reiter wrote: > > In recent years the field has gotten more difficult with some exchanges > that I did not find fair. This is why I've jumped on this question, I am not > sure that I, if I was Werner, would put in the time to answer it. Partly > because it is placed and framed in a way that does not seem to seek > understanding and cooperation, but to make GnuPG look bad. > Why would someone answer that? I agree, the tone of some exchanges recently has been less than ideal. I?m involved in the WG mainly to speak up for the keyservers, and to offer native-English-speaking proofreading whenever I have the time. I?m also agnostic on many of the technical arguments leading up to this particular incident. I?m *not* agnostic on the need for a unified spec, or the need to get crypto-refresh resolved so we can finalise sig attestations (which are vital for the survival of the keyservers but are currently out of scope in the WG). If all the implementors are still invested in the standardisation process, then let?s find a way to work through whatever disagreements remain. Otherwise, let?s (reluctantly) accept that and manage the consequences. But we should know which of these cases applies. At the moment there is a lot of wild speculation, accusations of bad faith, and unprofessional language going around which is not helping. >> Several people have asked for clarification on a number of occasions but >> none appears to be forthcoming. > > (BTW if those exchanges are publically available, can you point me to them?) https://mailarchive.ietf.org/arch/msg/openpgp/q7wl70rBx1I89ThFc-o2zOIPez0/? A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: image/vnd.microsoft.icon Size: 3638 bytes Desc: not available URL: From look at my.amazin.horse Thu Dec 15 12:18:16 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 15 Dec 2022 12:18:16 +0100 Subject: Allowing import of pubkeys without User ID (was: potential IETF WG incompatibility with GnuPG 2.3) In-Reply-To: <202212151108.08889.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> Message-ID: <3b18050d-4d64-f667-d32e-ca4e30a8a9f0@my.amazin.horse> Hey Bernhard, As far as I'm concerned, that issue is in the past, and either way unrelated to the question at hand here. Cheers ?- V From dashohoxha at gmail.com Thu Dec 15 12:44:26 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 15 Dec 2022 12:44:26 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <202212151043.13759.bernhard@intevation.de> References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: On Thu, Dec 15, 2022 at 10:43 AM Bernhard Reiter wrote: > Am Dienstag 13 Dezember 2022 13:17:53 schrieb Simon Josefsson via > Gnupg-devel: > > This thread was useful to me to understand that there really are two > > conflicting desired features here: > > > > 1) Use WDK to map ONE email address to ONE public key to use for > > email. > > > > 2) Use WDK to find ALL public keys for an email address. > > > > These are really two different use-cases, and as WDK looks now it seems > > it was tailored towards 1) but many people (myself included) use it for > > 2) since that is how you traditionally used OpenPGP keyservers, and > > people (myself included) like that semantics and is not ready to switch > > to the WDK approach of trusting the WDK mapping to produce the ONE key > > to use. > > Thanks for the good summary. > I would like to add that there are two basic use-cases of OpenPGP: 1) encryption 2) signature These use-cases have different requirements. When we send an encrypted message to an email address, we need to know the most recent public key (only one). For verifying a signature (of an email, package, document, etc) the most recent public key might not be enough, since the signature may be done with an old key. Another difference is that in the "encryption" use-case we only know the email address (user id), and most probably don't not know the key ID. But in the "signature" use-case we certainly know the key ID, and we may also know the user id (email address), if the signer has included it in the signature. > I have to admit that I had not understood this difference until > > now, I thought WDK mainly was a key-server-replacement proposal. > The same for me, but as explained in this thread, WKD was built to facilitate the "encryption" use-case. In this case you know only the mail address, and you need the public key that is the most qualified for sending encrypted messages to this email address. From the email address you (your mail client) can construct a well-known url and can (potentially) find the public key automatically. Given that we want a pubkey exchange even without email provider and email > addresses, the next important thing I see is to improve the keyservers. > This is certainly good, but not related to WKD. == Ways to deliver several pubkeys via WKD > Again thanks for the technical ideas. > > Two more ideas: > a) Allow for several pubkeys to be returned, but indicate which one > is the "primary" one among the active ones. Could be the order, > could be something else. However should be easy to use from the client > side (and is potentially not backwards compatible :/ ). > I suggested a proposal before (alternative to the Simons' proposals), but it was not described clearly, so let me summarize it again: The idea is that the current WKD well-known url does not change at all, but in addition we add another type of well-known url like this: https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9 The public key is located in the directory "/id/", and the name of the file is the same as the ID of the key. When the user publishes a new public key on WKD, it is stored on the "/hu/" directory, same as before, but in addition it is also stored on the "/id/" directory. The same thing is done when another public key replaces the old one, and now on the "/hu/" directory there is only one (corresponding) key, but on the "/id/" directory there are two (corresponding) keys, the new one and the old one. Of course, since everything is under user's control, the user may decide to not publish keys on the "/id/" directory, or to make a symbolic link from "/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4" to "/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9", etc. (depending on his use-cases, whether he is using WKD for encryption, for signature verification, or for both). This proposal seems to me easy to be implemented (to build a WKD), and completely backwards compatible with the current version of WKD (the mail clients don't need to change anything at all, and they will still be able to get the public key for encryption). Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Thu Dec 15 12:46:04 2022 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Dec 2022 12:46:04 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <202212151043.13759.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 15 Dec 2022 10:43:06 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: <87ilichoub.fsf@josefsson.org> Bernhard Reiter writes: >> I have to admit that I had not understood this difference until >> now, I thought WDK mainly was a key-server-replacement proposal. > > Some history: When WKD was designed in 2016 [1], the old (aka SKS) keyservers > where not yet in big trouble if I remember correctly, so there was less need > for case 2). > > Another design goal was simplicity (often called "lean" in process speak) to > allow for an easier uptake. So further uses are were not ruled out, but the > most important design goal(s) for the main user experience should be reached > quickly. Thanks, this helps to understand the driving forces behind things. >> I have argued before that WDK should be modified to allow returning more >> than one key. I can see now why that request has not been honored: it >> breaks the use-case 1) above. I don't think we can or should convince >> people that the semantics with 1) is bad and should't be specified or >> implemented. To the contrary: it seems very important to allow the >> functionality of 1) for simple bootstrapping of encrypted email. >> >> However maybe what we can achieve is that WDK could ALSO cater to the >> use-case of 2). What do you think? > > So far I am still makeing up my mind. A few thoughts: > > Given that we want a pubkey exchange even without email provider and email > addresses, the next important thing I see is to improve the keyservers. > (To allow carrying third party signatures again.) > > Being forced to use different channels for other pubkeys, except the current > active one, has its merits: it may potentially help to detect malice done to > the email provider's web server infrastructure. > > In addition the calculation of trust for several pubkeys has to become better > in implementations, if not just for cases of key rollover. Also for detecting > attacks and to cater for different levels of security needs. If there is > a good calculation of trust, you could get the currently active pubkey and > then sign others with it, which could be fetched elsewhere (keyserver, > homepage, etc.). If so, one current pubkey via WKD could be enough to > jumpstart 2). I think keyservers are useful, but to me being able to self-publish PGP keys from your own domain is important: it avoids relying on centralized key servers. In the old days, centralized key servers worked well enough so that this wasn't really an issue, but today I think being able to self-host PGP key discovery is important so we have options. > == Ways to deliver several pubkeys via WKD > Again thanks for the technical ideas. > > Two more ideas: > a) Allow for several pubkeys to be returned, but indicate which one > is the "primary" one among the active ones. Could be the order, > could be something else. However should be easy to use from the client > side (and is potentially not backwards compatible :/ ). Yes -- that seems like a really simple solution. Specify that the FIRST key is the ONE key to use when the application just wants one key to use directly. Say that if more than one key is available, the client MAY import the others too, saving them for future use. This requires OpenPGP packet parsing in the client, but I'm not sure that is a problem? > b) Add an URL somehow (maybe as pubkey user attribute) for the other pubkeys > to be fetched. I would like to avoid adding more things to my pubkey's just for this use-case. My OpenPGP keys cross-certify each other, so that could be sufficient reason for cross-trust between them, but I can see some environments where cross-cerifying keys is difficult (say for role-based keys like security at gnu.org if multiple independent keys for that adress is valid and used). /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From andrewg at andrewg.com Thu Dec 15 12:52:53 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Dec 2022 11:52:53 +0000 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel wrote: > > When the user publishes a new public key on WKD, it is stored on the "/hu/" directory, same as before, but in addition it is also stored on the "/id/" directory. The same thing is done when another public key replaces the old one, and now on the "/hu/" directory there is only one (corresponding) key, but on the "/id/" directory there are two (corresponding) keys, the new one and the old one. I?d suggest something along the lines of `archive` rather than `id`, since both directories are referenced by the hashed userid but one contains current info and the other secondary or historical info. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Thu Dec 15 13:02:55 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 15 Dec 2022 13:02:55 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: On Thu, Dec 15, 2022 at 12:53 PM Andrew Gallagher wrote: > On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel < > gnupg-devel at gnupg.org> wrote: > > > When the user publishes a new public key on WKD, it is stored on the > "/hu/" directory, same as before, but in addition it is also stored on the > "/id/" directory. The same thing is done when another public key replaces > the old one, and now on the "/hu/" directory there is only one > (corresponding) key, but on the "/id/" directory there are two > (corresponding) keys, the new one and the old one. > > > I?d suggest something along the lines of `archive` rather than `id`, since > both directories are referenced by the hashed userid but one contains > current info and the other secondary or historical info. > The name "/archive/" certainly makes sense and would be a good one. But the file names in this directory do not correspond to the hashed userid, but to the key ID. So, each file in this directory contains only one public key, and there are several files (public keys) that correspond to the same userid. This could make the management of this directory easier (compared to having several keys in one file). Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Thu Dec 15 13:24:39 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Dec 2022 12:24:39 +0000 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: <600D9922-A458-4C92-AEEE-4B68CBCFC6DC@andrewg.com> On 15 Dec 2022, at 12:02, Dashamir Hoxha wrote: > > On Thu, Dec 15, 2022 at 12:53 PM Andrew Gallagher > wrote: >> On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel > wrote: >>> >>> When the user publishes a new public key on WKD, it is stored on the "/hu/" directory, same as before, but in addition it is also stored on the "/id/" directory. The same thing is done when another public key replaces the old one, and now on the "/hu/" directory there is only one (corresponding) key, but on the "/id/" directory there are two (corresponding) keys, the new one and the old one. >> >> I?d suggest something along the lines of `archive` rather than `id`, since both directories are referenced by the hashed userid but one contains current info and the other secondary or historical info. > > The name "/archive/" certainly makes sense and would be a good one. But the file names in this directory do not correspond to the hashed userid, but to the key ID. So, each file in this directory contains only one public key, and there are several files (public keys) that correspond to the same userid. This could make the management of this directory easier (compared to having several keys in one file). I misread your spec - sorry. But this complicates the lookup process. Signatures are often made by subkeys rather than the primary key. Even if the user ID is included as a signature subpacket, you still don?t necessarily know the primary key fingerprint/id. On the other hand, if you?re using WKD for discovery you must already know the user ID - so indexing the archive by hashed-userid requires no extra information. (With the keyservers this is not an issue because you can search by subkey-id) Several keys in one file is how all OpenPGP keyrings work, and concatenation is not a particularly complex operation, so I?m not convinced this is a problem worth solving. :-) A -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Thu Dec 15 13:38:42 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 15 Dec 2022 13:38:42 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <600D9922-A458-4C92-AEEE-4B68CBCFC6DC@andrewg.com> References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> <600D9922-A458-4C92-AEEE-4B68CBCFC6DC@andrewg.com> Message-ID: On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher wrote: > I misread your spec - sorry. But this complicates the lookup process. > Signatures are often made by subkeys rather than the primary key. Even if > the user ID is included as a signature subpacket, you still don?t > necessarily know the primary key fingerprint/id. On the other hand, if > you?re using WKD for discovery you must already know the user ID - so > indexing the archive by hashed-userid requires no extra information. > Maybe you are right, I don't know enough internal details. If it is possible/easy to split a public key into its subkeys, I would still prefer to use a single file for storing each subkey. Several keys in one file is how all OpenPGP keyrings work, and > concatenation is not a particularly complex operation, so I?m not convinced > this is a problem worth solving. :-) > We should also consider the client that is downloading a key, and try to make it as easy as possible to use this key. After all, why should a client download several keys, when it needs only one, and the client already knows the ID of the key that it needs? Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu Dec 15 13:42:06 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 15 Dec 2022 13:42:06 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <202212151043.13759.bernhard@intevation.de> References: <202212091000.16718.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> Message-ID: <12115832.O9o76ZdvQC@daneel> On Donnerstag, 15. Dezember 2022 10:43:06 CET Bernhard Reiter wrote: > == Ways to deliver several pubkeys via WKD > Again thanks for the technical ideas. > > Two more ideas: > a) Allow for several pubkeys to be returned, but indicate which one > is the "primary" one among the active ones. Could be the order, > could be something else. However should be easy to use from the client > side (and is potentially not backwards compatible :/ ). > b) Add an URL somehow (maybe as pubkey user attribute) for the other > pubkeys to be fetched. Sounds like you want to use the "Preferred Key Server" signature subpacket for this. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.18 Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Thu Dec 15 13:47:13 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 15 Dec 2022 13:47:13 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212151043.13759.bernhard@intevation.de> Message-ID: <2267663.ElGaqSPkdT@daneel> On Donnerstag, 15. Dezember 2022 12:44:26 CET Dashamir Hoxha via Gnupg-devel wrote: > The idea is that the current WKD well-known url does not change at all, but > in addition we add another type of well-known url like this: > https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967 > FD258D6414F9 The public key is located in the directory "/id/", and the name > of the file is the same as the ID of the key. You still haven't answered this crucial question: How do you know that you have to ask intevation.de for the key with the fingerprint (or key ID) 847FC5C4337D9CDBD473B7A60967FD258D6414F9 if all you know is the fingerprint (or key ID)? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From dashohoxha at gmail.com Thu Dec 15 14:16:28 2022 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 15 Dec 2022 14:16:28 +0100 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <2267663.ElGaqSPkdT@daneel> References: <202212091000.16718.bernhard@intevation.de> <202212151043.13759.bernhard@intevation.de> <2267663.ElGaqSPkdT@daneel> Message-ID: On Thu, Dec 15, 2022 at 1:47 PM Ingo Kl?cker wrote: > > You still haven't answered this crucial question: > How do you know that you have to ask intevation.de for the key with the > fingerprint (or key ID) 847FC5C4337D9CDBD473B7A60967FD258D6414F9 if all > you > know is the fingerprint (or key ID)? > I had doubts about this as well, but it was clarified that it is possible to include the signer's userid in the signature: https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035200.html If you ask me, this should be the default option, because a signature without a name does not make much sense. The problem might be that a key may have several userid-s attached to it, and you don't know which one to use, unless the user tells you. Basically, the signer should use the option "--sender", like this: `gpg --sign -a --sender alice at intevation.de file-to-be-signed` Then the verifier will know both the key ID and the userid (email address of the signer). From the userid you can derive that the domain of WKD well-known url is "intevation.de". This depends on the signer using the option "--sender" when he makes a signature, but he has to use it if he wants his signature to be verified automatically through the WKD well-known url (as well as publish his public keys on the WKD). Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalzer at 59.ca Thu Dec 15 13:24:27 2022 From: bwalzer at 59.ca (Bruce Walzer) Date: Thu, 15 Dec 2022 06:24:27 -0600 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212150921.41792.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <87mt7rwu2s.wl-neal@walfield.org> <87k02vwnao.wl-neal@walfield.org> <202212150921.41792.bernhard@intevation.de> Message-ID: On Thu, Dec 15, 2022 at 09:21:41AM +0100, Bernhard Reiter wrote: > Am Dienstag 13 Dezember 2022 12:33:35 schrieb Neal H. Walfield: > > koo is out of spec, because it delivers certificates without User IDs > > (1). ?It come into spec by inserting a null User ID without a self > > signature (2). That is interesting. Where then would things like user preferences, which are normally kept in the self signatures, reside? Bruce From andrewg at andrewg.com Thu Dec 15 14:28:21 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Dec 2022 13:28:21 +0000 Subject: WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why)) In-Reply-To: References: <202212091000.16718.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <202212151043.13759.bernhard@intevation.de> <600D9922-A458-4C92-AEEE-4B68CBCFC6DC@andrewg.com> Message-ID: On 15 Dec 2022, at 12:38, Dashamir Hoxha wrote: > > On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher > wrote: >> I misread your spec - sorry. But this complicates the lookup process. Signatures are often made by subkeys rather than the primary key. Even if the user ID is included as a signature subpacket, you still don?t necessarily know the primary key fingerprint/id. On the other hand, if you?re using WKD for discovery you must already know the user ID - so indexing the archive by hashed-userid requires no extra information. > > Maybe you are right, I don't know enough internal details. > If it is possible/easy to split a public key into its subkeys, I would still prefer to use a single file for storing each subkey. But a subkey is meaningless without its primary and userid. An arbitrary key may have both a signing-capable primary and a signing-capable subkey. Does this mean the same material gets stored twice, under the two (sub)key ids? Surely this makes the management more complex, not less? >> Several keys in one file is how all OpenPGP keyrings work, and concatenation is not a particularly complex operation, so I?m not convinced this is a problem worth solving. :-) > > We should also consider the client that is downloading a key, and try to make it as easy as possible to use this key. > After all, why should a client download several keys, when it needs only one, and the client already knows the ID of the key that it needs? We?re not exactly talking gigabytes of data here. We can safely assume that any client capable of verifying OpenPGP signatures also understands keyrings. IMO this is a non-problem. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From look at my.amazin.horse Thu Dec 15 15:05:38 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 15 Dec 2022 15:05:38 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212151011.43895.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> Message-ID: Hey Bernhard, we can spend a long time arguing about context here, but I'd rather not remove the thread further from the core of it: The quoted commit is a big decision for GnuPG. It will have a large effect on GnuPG, its users, and the wider ecosystem. This justifiably leaves people wondering what GnuPG's plans are for the future. ?- V From raj.khem at gmail.com Thu Dec 15 17:55:43 2022 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 15 Dec 2022 08:55:43 -0800 Subject: [PATCH] posix-io.c: Use off_t instead of off64_t Message-ID: <20221215165543.636403-1-raj.khem@gmail.com> configure.ac checks for largefile support via AC_SYS_LARGEFILE already, therefore use off_t and ino_t instead of 64bit variants. Musl e.g. does not define them without _LARGEFILE64_SOURCE and error is not seen on glibc because _GNU_SOURCE defines _LARGEFILE64_SOURCE Fixes errors like below on 32-bit musl systems ../../../../../../../../workspace/sources/gpgme/src/posix-io.c:77:3: error: unknown type name 'ino64_t'; did you mean 'int64_t'? ino64_t d_ino; ^~~~~~~ int64_t ^ ../../../../../../../../workspace/sources/gpgme/src/posix-io.c:78:3: error: unknown type name 'off64_t'; did you mean 'off_t'? off64_t d_off; ^~~~~~~ Signed-off-by: Khem Raj --- src/posix-io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/posix-io.c b/src/posix-io.c index 0d0a98b..286a626 100644 --- a/src/posix-io.c +++ b/src/posix-io.c @@ -74,8 +74,8 @@ * define it ourselves. */ struct linux_dirent64 { - ino64_t d_ino; - off64_t d_off; + ino_t d_ino; + off_t d_off; unsigned short d_reclen; unsigned char d_type; char d_name[]; -- 2.39.0 From bernhard at intevation.de Mon Dec 19 10:16:18 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 19 Dec 2022 10:16:18 +0100 Subject: keys.openpgp.org FAQ stays negativ on GnuPG devs (was:Re: Allowing import of pubkeys without User ID ) In-Reply-To: <3b18050d-4d64-f667-d32e-ca4e30a8a9f0@my.amazin.horse> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <3b18050d-4d64-f667-d32e-ca4e30a8a9f0@my.amazin.horse> Message-ID: <202212191016.39913.bernhard@intevation.de> Hey Vincent, Am Donnerstag 15 Dezember 2022 12:18:16 schrieb Vincent Breitmoser via Gnupg-devel: > As far as I'm concerned, that issue is in the past, so you decide to keep the information tha missrepresents GnuPG's efforts to resolve this on the current page? My suggestion (quoted below) was to phrase the status more respectfully. > and either way unrelated to the question at hand here. As explained before: It is an example showing why the way you are phrasing the first question is likely to be understood as a framing to put the burden on GnuPG devs and to make them look bad on this. You have also not answered why you haven't asked the question ths other way around to the WG or what your stance on the technical differences is. Anyway, I've splitted this out and open a email subject with this as a new question. If this is a question of the past to you, why not correct the missrepresenting FAQ entry? Regards, Berhard Am Donnerstag 15 Dezember 2022 11:07:54 schrieb Bernhard Reiter: > As you can see in > https://dev.gnupg.org/T4393 > it has not been followed up a lot by koo people. > And the last anwer in > https://keys.openpgp.org/about/faq > does not represent the situation fairly. > > It introduces the term "bug" and leaves the impression that GnuPG team > is on the wrong here. A nicer way to phrase it would be "Why is that so?" > or "What can be the reason?". > > It would be cool if the reasons given (e.g. in T4293) were explained > in the FAQ so to show the disagreement in more detail. > > The patch in T4393 was not a five lines patch and the suggested way > forward was not followed up (as far as I know). As you have written, > it looked like the change could have been made. Addressing some > of the concerns of the GnuPG team or at least repesenting the concerns > in a respectful way can help (I believe). -- 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 bernhard at intevation.de Mon Dec 19 10:19:04 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 19 Dec 2022 10:19:04 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> Message-ID: <202212191019.05244.bernhard@intevation.de> Hey Vincent, Am Donnerstag 15 Dezember 2022 15:05:38 schrieb Vincent Breitmoser via Gnupg-devel: > The quoted commit is a big decision for GnuPG. and the WG decision to become incompatible with the previous drafts were a big decision for the working group affecting OpenPGP users, implementations and the wider ecosystem. What are their plans for this problem? 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 Mon Dec 19 18:29:09 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 19 Dec 2022 17:29:09 +0000 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212191019.05244.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> <202212191019.05244.bernhard@intevation.de> Message-ID: <0421C7D1-2C85-46C3-A921-C5FC07474EDB@andrewg.com> On 19 Dec 2022, at 09:19, Bernhard Reiter wrote: > > Signed PGP part > Hey Vincent, > > Am Donnerstag 15 Dezember 2022 15:05:38 schrieb Vincent Breitmoser via > Gnupg-devel: >> The quoted commit is a big decision for GnuPG. > > and the WG decision to become incompatible with the previous drafts > were a big decision for the working group affecting > OpenPGP users, implementations and the wider ecosystem. > > What are their plans for this problem? To be fair to Vincent, he doesn?t answer for the WG (and neither do I). The chairs have recommended that all reasonable effort be made to remove breaking incompatibilities between -bis and crypto-refresh: https://mailarchive.ietf.org/arch/msg/openpgp/yayGaIen3DW6ixwrJkP-QcAcFSQ/? However this has not prevented a lot of unhelpful and premature speculation about forking the standard or skipping version numbers to avoid dealing with the issue. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: image/vnd.microsoft.icon Size: 3638 bytes Desc: not available 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 steffen at sdaoden.eu Mon Dec 19 20:07:32 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 19 Dec 2022 20:07:32 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <0421C7D1-2C85-46C3-A921-C5FC07474EDB@andrewg.com> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> <202212191019.05244.bernhard@intevation.de> <0421C7D1-2C85-46C3-A921-C5FC07474EDB@andrewg.com> Message-ID: <20221219190732.8ezT4%steffen@sdaoden.eu> This entire shit is disgusting to the core, in the IETF group and anywhere else. My wish would be that noone is able to hammer its piolet sufficiently deep due to all this. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Tue Dec 20 10:46:59 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2022 10:46:59 +0100 Subject: [Announce] GnuPG 2.4.0 released (silver anniversary) Message-ID: <87sfhao19o.fsf@wheatstone.g10code.de> Hello! Exactly 25 years ago the very first release of GnuPG was published. We are pleased to take this opportunity to announce the availability of a new stable GnuPG release: version 2.4.0. This release has a few new features and the binary releases come with an updated Libksba to fix another vulnerability related to CVE-2022-3515. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different series of GnuPG are actively maintained: - Version 2.4 is the current stable version with a lot of new features compared to 2.2. This announcement is about the latest release of this series; the previous release was 2.3.8. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. Only a small subset of features from 2.4 has been back-ported to this series. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is only maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Please use 1.4 only for this purpose. Noteworthy changes in version 2.4.0 =================================== * The key database daemon is now a fully supported feature. Keys are stored in a SQLite database to make key lookups much faster. Enable it by adding "use-keyboxd" o common.conf. See also the README file. * gpg: New command --quick-update-pref. [rGd40d23b233] * gpg: New list-options show-pref and show-pref-verbose. [rG811cfa34cb] * gpg: New option --list-filter to restrict key listings like gpg -k --list-filter 'select=revoked-f && sub/algostr=ed25519' [rG1324dc3490] * gpg: New --export-filter export-revocs. [rGc985b52e71] * gpg: Also import stray revocation certificates. [rG7aaedfb107] * gpg: Add a notation to encryption subkeys in de-vs mode. [T6279] * gpg: Improve signature verification speed by a factor of more than four. Double detached signing speed. [T5826] * gpg: Allow only OCB for AEAD encryption. [rG5a2cef801d] * gpg: Fix trusted introducer for mbox only user-ids. [T6238] * gpg: Report an error via status-fd for receiving a key from the agent. [T5151] * gpg: Make --require-compliance work without the --status-fd option. [rG2aacd843ad] * gpg: Fix verification of cleartext signatures with overlong lines. [T6272] * agent: Fix import of protected OpenPGP v5 keys. [T6294] * gpgsm: Change the default cipher algorithm from AES128 to AES256. Also announce support for this in signatures. [rG2d8ac55d26] * gpgsm: Always use the chain validation model if the root-CA requests this. [rG7fa1d3cc82] * gpgsm: Print OCSP revocation date and reason in cert listings. [rGb6abaed2b5] * agent: Support Win32-OpenSSH emulation by gpg-agent. [T3883] * scd: Support the Telesec Signature Card v2.0. [T6252] * scd: Redact --debug cardio output of a VERIFY APDU. [T5085] * scd: Skip deleted pkcs#15 records in CARDOS 5. [rG061efac03f] * dirmngr: Fix build with no LDAP support. [T6239] * dirmngr: Fix verification of ECDSA signed CRLs. [rG868dabb402] * wkd: New option --add-revocs for gpg-wks-client. [rGc3f9f2d497] * wkd: Ignore expired user-ids in gpg-wks-client. [T6292] * card: New commands "gpg" and "gpgsm". [rG9c4691c73e] Release-info: https://dev.gnupg.org/T6303 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.0.tar.bz2 (7487k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.0.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.0_20221216.exe (4816k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.0_20221216.exe.sig The source used to build this Windows installer can be found in the same directory with a ".tar.xz" suffix. A link to GnuPG Desktop?, an AppImage for Linux, featuring this version of GnuPG along with the advanced graphical user interface Kleopatra is available from the download page: https://gnupg.org/download/index.html#binary A new release of Gpg4win (version 4.1.0) including this version of GnuPG is available at https://gpg4win.org Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.4.0.tar.bz2 you would use this command: gpg --verify gnupg-2.4.0.tar.bz2.sig gnupg-2.4.0.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.4.0.tar.bz2, you run the command like this: sha1sum gnupg-2.4.0.tar.bz2 and check that the output matches the next line: 63dde155a8df0d5e1987efa5fc17438beca83ac1 gnupg-2.4.0.tar.bz2 f8b5aaf759fa311e60d34823be342d7e15d1e752 gnupg-w32-2.4.0_20221216.tar.xz 5195ff17de15ffd8629bfd0f0b5dd2b2774295f2 gnupg-w32-2.4.0_20221216.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T6303 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- 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: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From look at my.amazin.horse Tue Dec 20 11:38:51 2022 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 20 Dec 2022 11:38:51 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <202212191019.05244.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> <202212191019.05244.bernhard@intevation.de> Message-ID: Hi Bernhard and list, > and the WG decision to become incompatible with the previous drafts > were a big decision for the working group affecting > OpenPGP users, implementations and the wider ecosystem. That is true. And the decision has not been made lightly. As any WG work, this is a public process: There has been a lot of discussion, over a lengthy period of time, with input from many individuals and projects. https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/ It's a complex topic and hard to do justice in summary. In particular for Werner's side I'll admit I didn't really understand what's going on. Hence the concrete question here what the plans are for the future of his concrete project. Cheers ?- V From lists at sapience.com Tue Dec 20 13:00:39 2022 From: lists at sapience.com (Genes Lists) Date: Tue, 20 Dec 2022 07:00:39 -0500 Subject: GnuPG 2.4.0 vs libksba 1.6.3 Message-ID: <6d647412-00b2-77a1-29fb-8ab62b1cf47a@sapience.com> Small comment and maybe it's me. 2.4.0 requires libksba 1.6.3+ but this has last tag of libksba-1.6.2 and NEWS says 1.6.3 is unreleased [1]. The download section of gnupg.org does show 1.6.3 - so perhaps I'm looking in wrong git repo. gene [1] git://git.gnupg.org/libksba.git From wk at gnupg.org Tue Dec 20 15:55:58 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2022 15:55:58 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: (Vincent Breitmoser via Gnupg-devel's message of "Tue, 20 Dec 2022 11:38:51 +0100") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> <202212191019.05244.bernhard@intevation.de> Message-ID: <87fsdanmyp.fsf@wheatstone.g10code.de> On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said: > As any WG work, this is a public process: There has been a lot of Which is not entirely true. The crypto-refresh folks worked in a closed design team and presented their results to the WG. Comments from WG members which challenged the outcome were mostly rejected or ignored. For the records: I had been part of the design team. Actually Stephen called me once to setup this DT so to solve the blocks we mainly had due to some bike shedding. It took a bit longer then expected to set it up but we were then able to solve the blocking issues in a way which all participants could agreed on - including me (as GnuPG author and assigned editor of the WG). Due to time constrains I quiet the DT which had only editorial tasks open. Unfortunately they the started to revamp the entire specification and presented that as the new crypto-refresh. > In particular for Werner's side I'll admit I didn't really understand > what's going on. I described this too often to repeat it again. But anyway in short: The OpenPGP WG turned into design-by-commitee mode. Which is yet another tombstone for the IETF. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 20 15:59:35 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2022 15:59:35 +0100 Subject: GnuPG 2.4.0 vs libksba 1.6.3 In-Reply-To: <6d647412-00b2-77a1-29fb-8ab62b1cf47a@sapience.com> (Genes Lists via Gnupg-devel's message of "Tue, 20 Dec 2022 07:00:39 -0500") References: <6d647412-00b2-77a1-29fb-8ab62b1cf47a@sapience.com> Message-ID: <87bknynmso.fsf@wheatstone.g10code.de> On Tue, 20 Dec 2022 07:00, Genes Lists said: > 2.4.0 requires libksba 1.6.3+ but this has last tag of libksba-1.6.2 > and NEWS says 1.6.3 is unreleased [1]. Thanks for the reminder. I forgot to push to the public repo. I think this was the first time we exercised a responsible disclosure process with all of our affected software published more or less at the same time. In the past we had freely pushed things to public repos but in this case we delayed 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: 227 bytes Desc: not available URL: From fundawang at yeah.net Tue Dec 20 15:07:44 2022 From: fundawang at yeah.net (Wang Peng) Date: Tue, 20 Dec 2022 22:07:44 +0800 (CST) Subject: Build Error for gnupg2-2.4.0 Message-ID: <297fdb7.fa1.1852fdc9925.Coremail.fundawang@yeah.net> Hello, I'm building gnupg 2.4.0, and it failed while 'make check'ing [1]. It seems that there are mistakes inside tests/gpgme/Makefile.am. It reads: xcheck: @$(MKDIR_P) setup.scm/tests \ tests/gpg lang/qt/tests lang/python/tests But "setup.scm" itself is a regular file, I think none of distros allows creating subdir under a file. Will the mistake be fixed in the near future? Thanks. [1]: http://build.openanolis.cn/kojifiles/work/tasks/3643/483643/build.log -------------- next part -------------- An HTML attachment was scrubbed... URL: From heiko.schaefer at posteo.de Wed Dec 21 01:40:28 2022 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=c3=a4fer?=) Date: Wed, 21 Dec 2022 00:40:28 +0000 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <87fsdanmyp.fsf@wheatstone.g10code.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151011.43895.bernhard@intevation.de> <202212191019.05244.bernhard@intevation.de> <87fsdanmyp.fsf@wheatstone.g10code.de> Message-ID: On 12/20/22 15:55, Werner Koch via Gnupg-devel wrote: > On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said: > >> As any WG work, this is a public process: There has been a lot of > Which is not entirely true. The crypto-refresh folks worked in a closed > design team and presented their results to the WG. Comments from WG > members which challenged the outcome were mostly rejected or ignored. I'm confused by the characterization of the work as "closed". As an interested outside observer I could easily follow the group's process via the mailing list (https://mailarchive.ietf.org/arch/browse/openpgp/), and I notice that you have also posted to that list on a number of occasions. Obviously a consensus-based process will reject some inputs. That fact by itself does not seem unusual to me. If you have pointers to important input that you feel was unreasonably rejected on the mailing list, I'd be interested to see those. Thanks, Heiko From kloecker at kde.org Wed Dec 21 10:19:20 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 21 Dec 2022 10:19:20 +0100 Subject: Build Error for gnupg2-2.4.0 In-Reply-To: <297fdb7.fa1.1852fdc9925.Coremail.fundawang@yeah.net> References: <297fdb7.fa1.1852fdc9925.Coremail.fundawang@yeah.net> Message-ID: <2864060.e9J7NaK4W3@daneel> On Dienstag, 20. Dezember 2022 15:07:44 CET Wang Peng via Gnupg-devel wrote: > Hello, > > I'm building gnupg 2.4.0, and it failed while 'make check'ing [1]. It > seems that there are mistakes inside tests/gpgme/Makefile.am. It reads: > > xcheck: > @$(MKDIR_P) setup.scm/tests \ > tests/gpg lang/qt/tests lang/python/tests > > But "setup.scm" itself is a regular file, I think none of distros allows > creating subdir under a file. The problem only occurs if you try to build in source tree. We recommend not to build in source tree, and, while building in source tree should work, we don't test this (we never build in source tree) and thus do not guarantee that it works. > Will the mistake be fixed in the near future? Thanks. https://dev.gnupg.org/T6313 Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Wed Dec 21 10:30:39 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 21 Dec 2022 10:30:39 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <87fsdanmyp.fsf@wheatstone.g10code.de> Message-ID: <10199374.nUPlyArG6x@daneel> On Mittwoch, 21. Dezember 2022 01:40:28 CET Heiko Sch?fer via Gnupg-devel wrote: > On 12/20/22 15:55, Werner Koch via Gnupg-devel wrote: > > On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said: > >> As any WG work, this is a public process: There has been a lot of > > > > Which is not entirely true. The crypto-refresh folks worked in a closed > > design team and presented their results to the WG. Comments from WG > > members which challenged the outcome were mostly rejected or ignored. > > I'm confused by the characterization of the work as "closed". As an > interested outside observer I could easily follow the group's process > via the mailing list > (https://mailarchive.ietf.org/arch/browse/openpgp/), That's the mailing list of the WG and not the closed one (with open archive) used by the DT. > and I notice that > you have also posted to that list on a number of occasions. https://mailarchive.ietf.org/arch/msg/openpgp/9uPRgtbWMQZoho-AfxdBlSpGPZc/ reads " For those less familiar with the IETF's design team (DT) concept, a DT is a group selected by chairs who do some work that is then an input to the WG - whether or not the WG have rough consensus on the DT output is up to the WG and not the DT. For this DT, we'll have a closed mailing list with an open archive, and, as stated, roughly monthly calls. " Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Dec 21 12:29:44 2022 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2022 12:29:44 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <10199374.nUPlyArG6x@daneel> ("Ingo \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22\?\= \=\?utf-8\?Q\?'s\?\= message of "Wed, 21 Dec 2022 10:30:39 +0100") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <87fsdanmyp.fsf@wheatstone.g10code.de> <10199374.nUPlyArG6x@daneel> Message-ID: <877cylngev.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2022 10:30, Ingo Kl?cker said: > That's the mailing list of the WG and not the closed one (with open archive) > used by the DT. And lots of video calls not all covered by the minutes. 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: 227 bytes Desc: not available URL: From kloecker at kde.org Thu Dec 22 14:34:22 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 22 Dec 2022 14:34:22 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <87cz8bwsu3.fsf@europ.lan> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <877cylngev.fsf@wheatstone.g10code.de> <87cz8bwsu3.fsf@europ.lan> Message-ID: <1919838.PYKUYFuaPT@daneel> Hi Justus, On Donnerstag, 22. Dezember 2022 13:01:08 CET Justus Winter wrote: > Werner Koch via Gnupg-devel writes: > > On Wed, 21 Dec 2022 10:30, Ingo Kl?cker said: > >> That's the mailing list of the WG and not the closed one (with open > >> archive) used by the DT. > > For the record, said archive is here: > https://mailarchive.ietf.org/arch/browse/openpgp-dt/ > > I'm not sure why the list has been characterized as closed. The DT itself has characterized their mailing list as closed: " For this DT, we'll have a closed mailing list with an open archive, and, as stated, roughly monthly calls. " https://mailarchive.ietf.org/arch/msg/openpgp/9uPRgtbWMQZoho-AfxdBlSpGPZc/ Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Dec 23 12:15:59 2022 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Dec 2022 12:15:59 +0100 Subject: [PATCH] posix-io.c: Use off_t instead of off64_t In-Reply-To: <20221215165543.636403-1-raj.khem@gmail.com> (Khem Raj via Gnupg-devel's message of "Thu, 15 Dec 2022 08:55:43 -0800") References: <20221215165543.636403-1-raj.khem@gmail.com> Message-ID: <87bknul6a8.fsf@wheatstone.g10code.de> Hi! On Thu, 15 Dec 2022 08:55, Khem Raj said: > struct linux_dirent64 > { > - ino64_t d_ino; > - off64_t d_off; > + ino_t d_ino; > + off_t d_off; The getdents(2) man page from 2020-11-01 still says to define it as we did. Changing this just for non-conforming libc will for sure break other applications. Please fix musl or provide a way to relible detect the correct type for an 64 bit inode number within musl. 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: 227 bytes Desc: not available URL: