From nobody Fri Oct 7 07:11:37 2022 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A4BC14F740 for ; Fri, 7 Oct 2022 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU3-MPuMbitX for ; Fri, 7 Oct 2022 07:11:35 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562B4C14CF04 for ; Fri, 7 Oct 2022 07:11:35 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id a13so7258810edj.0 for ; Fri, 07 Oct 2022 07:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WTOkdiFes2pA+zQip/UbE9Ga0mT9SBg2iRoIvx6wcUg=; b=jyDyLhilmLzHbH4XRuXFiJBFAZYcxNkEliHMmb+zY60idp6JPX6j3FqfMYTDHWjFd3 v3jh/diJQzabFxXFHZcAT/aQFPnResmfdp+4bas42SG+bWeJJ8ge0cDga5Oqy78dL1p+ +7eiKslglT47vuj0VbczxNqSkRjX4eO2qOT5u1LZWcI3XzGVZ8+Dja51qnN1FqSCv54J Sv6SRbVfFU6ktrftE9YuXXeSg9/ChLmnSNMF+SRtEtPlMtn3wLPSFmRC3zAvTsw+Br9G BJCfL2QQU17ew7BjVRQySrKdi9ik90b3RuYft4V8MrZct6jLNEuDCTri/3Z6YB4gadcP h9zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WTOkdiFes2pA+zQip/UbE9Ga0mT9SBg2iRoIvx6wcUg=; b=Rhy7X0fiiRX+FO/8bpKa15nfNh6mNjmqsMFvR4JX+JeujuqyK8I+FDj8soqepXsi3E 8gVA4PI5KFmznpnBXfvztWiEVNrYKlvvxLMUtVZaecR6KFCeA66Xpr8tsokYijEG43wZ zs36I1YBanzQnTLjt+JuJhA3rjsXI22pU0JHhSTDce7ACpLQ/Xh1Js5XW3cN82liIsMK Ahtr3eeasr1n28pgm0mAkiyb2NLSSIP9jzGmfubF0hKM7szU2f7eZWgcBRK34Srp1K79 kfOqHztD1C2fur3y1ai9PkLwKi3+1zlb6v9vs7QWZaI8iPEJ1xS7bNJA9kMGP+nshLaM xqoA== X-Gm-Message-State: ACrzQf2sHno3pm4i4gSUXY0HqBCdzNufspVCPx0cgQRdQNUbSVqwVg11 D8YEjK3aYvTVrX2USjiqGQihiC0cCk5xOcrOt481V2d9 X-Google-Smtp-Source: AMsMyM67nhg/x8n2UMRhpA7FDbnyNg+YR5U3gpFWYjR+KjQMatCthcZ61RTKJAoHF0zvEjwbQQ8i3XyZunbn170TOzw= X-Received: by 2002:a05:6402:278e:b0:45a:35dc:ebc8 with SMTP id b14-20020a056402278e00b0045a35dcebc8mr1661822ede.314.1665151892568; Fri, 07 Oct 2022 07:11:32 -0700 (PDT) MIME-Version: 1.0 References: <086DCEE6-1AB7-4453-9EEA-AFCDFD1715F4@mit.edu> <8414860D-5CE6-407E-A78A-E21A03CDCC52@andrewg.com> <657A76B3-0037-4471-A380-15603BE198FA@andrewg.com> In-Reply-To: <657A76B3-0037-4471-A380-15603BE198FA@andrewg.com> From: Wyllys Ingersoll Date: Fri, 7 Oct 2022 10:11:19 -0400 Message-ID: To: Andrew Gallagher Cc: openpgp@ietf.org Content-Type: multipart/alternative; boundary="0000000000000dc19f05ea726337" Archived-At: Subject: Re: [openpgp] a new draft overlapping the WG draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2022 14:11:36 -0000 --0000000000000dc19f05ea726337 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a developer and maintainer of an independent implementation of the OpenPGP spec for iOS (iPGMail app), I am strongly in favor of a unified single standard that all implementers can follow without having to add lots of exceptional edge case handlers to be compatible with one particular implementation, regardless of that implementations widespread installed user base. I've always strived to maintain compatibility against GnuPG as that is what most of the user's have come to expect. If someone sends a message using GnuPG, they expect it to be accepted and processed by their OpenPGP app of choice, and vice-versa. Anything that breaks this trust with the end-users is detrimental to the community as a whole, obviously. PGP in general is already held in low regard by many due to its complexity and difficulty to manage. Adding more complexity and confusion to the mix isn't helping anyone. I support the crypto-refresh document as the way forward, but am still holding out hope that Werner will come back to the table and the parties can hammer out some sort of compromise and avoid an ugly situation for everyone. Delivering ultimatums and essentially giving the finger to the folks that put in all of the work over the past MANY years to get the spec to the place it is in now is really shocking to see at this point in a process that has gone on for painfully far too long already. -Wyllys Ingersoll On Fri, Oct 7, 2022 at 9:39 AM Andrew Gallagher wrote= : > On 7 Oct 2022, at 13:33, Tom wrote= : > > > I do praise this sentiment, but, you'll note from the conversation above, > if the standard is to be "whatever GnuPG wants since they made unilateral > decision to deploy un-standardized algorithm in the past", then exactly > what do we have a working group for? > > > I very carefully did *not* say this. What I did say was that users=E2=80= =99 needs > should be the metric by which we judge how to move forward. If the > consensus is that the only option is a fork, then I want to see it spelle= d > out in black and white why this is the best *for users*, and how this wil= l > not mean the end for OpenPGP as a common standard. > > And by =E2=80=9Cwe=E2=80=9D I mean *everyone* here. If any implementer is= seriously > proposing to not support the new standard, then I want them to explain wh= y, > on the same user-driven basis as above. If it is not a serious proposal > however, then say so now and let=E2=80=99s draw a line under it. > > I do wonder what developers of applications that rely on GnuPG (say, othe= r > than Gpg4win. Projects like Enigmail for Thunderbird used to be when it > still relied on GnuPG.. I believe there are quire a few others still) > have to say about the matter. > > > It may also be worth canvassing the opinion of the major OS distributions= . > They rely heavily on the existing installed base on a day to day basis (f= or > code verification). > > A > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --0000000000000dc19f05ea726337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As a developer and maintai= ner of an independent implementation of the OpenPGP spec for iOS (iPGMail a= pp), I am strongly in favor of a unified single standard that all implement= ers=C2=A0can follow without having to add lots of exceptional edge case han= dlers to be compatible with one particular implementation, regardless of th= at implementations widespread installed user base.=C2=A0=C2=A0
I've always strived to maintain compatibility against GnuP= G as that is what most of the user's have come to expect.=C2=A0 If some= one sends a message using GnuPG, they expect it to be accepted and processe= d by their OpenPGP app of choice, and vice-versa.=C2=A0 Anything that break= s this trust with the end-users is detrimental to the community as a whole,= obviously.=C2=A0 PGP in general is already held in low regard by many due = to its complexity and difficulty to manage.=C2=A0 Adding more complexity an= d confusion to the mix isn't helping anyone.

I= support the crypto-refresh document as the way forward, but am still holdi= ng=C2=A0out hope that Werner will come back to the table and the parties ca= n hammer out some sort of compromise and avoid an ugly situation for everyo= ne.=C2=A0 Delivering ultimatums and essentially giving the finger to the fo= lks that put in all of the work over the past MANY years to get the spec to= the place it is in now is really shocking to see at this point in a proces= s that has gone on for painfully far too long already.

=
-Wyllys Ingersoll



On Fri, Oct 7, 2022 at = 9:39 AM Andrew Gallagher <andrewg= @andrewg.com> wrote:
On 7 Oct 2022, at 13:= 33, Tom <tom=3D40flowcrypt.com@dmarc.ietf.org> wrote:

I do wonder what developers of applications that rely on GnuPG (say,=C2= =A0other than=C2=A0Gpg4win. Projects like Enigmail for Thunderb= ird used to be when it still relied on GnuPG.. I believe there are quire a = few others still) have to say about the matter.

It may also be worth canvassing the opinion of the majo= r OS distributions. They rely heavily on the existing installed base on a d= ay to day basis (for code verification).

A

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--0000000000000dc19f05ea726337--