From nobody Mon Dec 2 13:58:31 2019 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 3DB8E12008C for ; Mon, 2 Dec 2019 13:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km0kknhyXn9u for ; Mon, 2 Dec 2019 13:58:28 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014FA12008B for ; Mon, 2 Dec 2019 13:58:27 -0800 (PST) Received: from virulha.pair.com (localhost [127.0.0.1]) by virulha.pair.com (Postfix) with ESMTP id B1BF86D5DE; Mon, 2 Dec 2019 16:58:26 -0500 (EST) Received: from plata.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 47FC66D5D7; Mon, 2 Dec 2019 16:58:26 -0500 (EST) To: openpgp@ietf.org References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> From: iang Message-ID: <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> Date: Mon, 2 Dec 2019 23:58:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:58:29 -0000 On 28/10/2019 22:40, Santiago Torres-Arias wrote: > On Mon, Oct 28, 2019 at 04:20:39PM -0400, Daniel Kahn Gillmor wrote: >> Hi OpenPGP folks-- >> >> The recently-announced OpenPGP test suite [0] inspired me to try >> drafting a spec for a purely-functional, stateless OpenPGP command line >> interface. The idea is that different implementers could provide the >> same interface, focusing specifically on the object security aspect of >> OpenPGP (leaving aside identity management). >> ... > I think this is a *phenomenal* idea. I wonder if this could mature in a > well-defined API that e.g., gpgme could adopt? Concur! iang From nobody Mon Dec 2 14:27:26 2019 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 DAF6A12008B for ; Mon, 2 Dec 2019 14:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzVdU_1EfAnF for ; Mon, 2 Dec 2019 14:27:22 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDF4120018 for ; Mon, 2 Dec 2019 14:27:22 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id i18so1319244qkl.11 for ; Mon, 02 Dec 2019 14:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sh59Q05HdgxnLy9+GGj5+b0oVP5ccP0QKQmmDZ4xxec=; b=Ji7d7RvuE2kXVIQXw+HiP4ZqARFjmR0HSW4S8qvPe0TfWzCxHOUucS2qqfCUFkKFiD /vnxfCpenjreR7EacoU/5wUCFnGQVw6uybRHb4UNXPkrfMj2VoAshQNvAiZdw/Uvu6a7 rQ3JQrAe+MBZIj73PcutE3ztVN0NeQxjI6DIQsuq1a77zwAAxXwjZUHnwbJsXOT6RYlx 4tk9vo2e84HC9OwWB4uh98LFd1uF77rcbX97hwUaO1f0vmpwMoHswMgh+9uP19ink8Q9 sI1LdhhlqgVPqsUI4pmhB2Z0CYL+DtI8kvMqKk/KZG2rFOTYkUhNfeQ1cyU1jHHtFYtZ w4yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sh59Q05HdgxnLy9+GGj5+b0oVP5ccP0QKQmmDZ4xxec=; b=qkroL1MBX1UUFrZP0DnxdEIStmKRhK5Ga0kRHL6gdOnWIU3KB/TulrNIP8gO24KeM5 dCL3B1KO6OTYmKHaCeRGsw4xj6AM4iGtaZqP0NSV9bYMHnRC6VebDAqJrzvpLceQ72GN lumUblAaTriaYGDfvWb/3OAULCd6D1WPlnWazhX+K5ojFnaOnzfeWwDM57L+mS74/DyL kzAvdaESaJKsb9mLRH+fr+O/4OeKkt/QSAI5BF40VQOrLvxE5yiAlvxnxUtklI2IXjn5 CfhBWKhT43AvMYt/7FnlwdejZpPDO14LKANrJieeaSECIK/2ZomR+QdD7pnalAwd0SN4 olxw== X-Gm-Message-State: APjAAAXW+S/K9soiXeEge5esdU601zncoBi+LvkrOEn4vxZzrUk+nMhV d+zHGJaCm2cZTDju8EE4ZwhFnS2P8U6bxFI+2GelOO3G X-Google-Smtp-Source: APXvYqzwaDTLC0O8eyDquFuJG2P67fomW6rxHtCPgi55QL515CPeuwltTlUQn6xKj9vKEWlsyqkM1hLYN7F8SvVoS0c= X-Received: by 2002:a37:4fd0:: with SMTP id d199mr1610126qkb.103.1575325640985; Mon, 02 Dec 2019 14:27:20 -0800 (PST) MIME-Version: 1.0 References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> In-Reply-To: <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> From: Wyllys Ingersoll Date: Mon, 2 Dec 2019 17:27:09 -0500 Message-ID: To: "openpgp@ietf.org OpenPGP" Content-Type: multipart/alternative; boundary="0000000000003c92420598c0158f" Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 22:27:25 -0000 --0000000000003c92420598c0158f Content-Type: text/plain; charset="UTF-8" Does anyone have a good estimate of how many command-line oriented OpenPGP applications are actually in use beyond GnuPG? Im really just curious, I was under the impression that GnuPG is sort of the de-facto standard implementation for the majority of OpenPGP users on a computer with a keyboard. I know there are implementations for a variety of other languages, but I wonder if they have significantly motivated development teams that would take this on and implement it in practice. Has the GnuPG team indicated an interest in writing an entirely new CLI ? For mobile applications and other OpenPGP implementations that do not even have a CLI this is obviously not going to be of interest, but I understand that that's not the target audience for this sort of document anyway. Im not trying to throw cold water on the efforts to standardize a more friendly interface on an increasingly complicated protocol, I just wonder how far it will go beyond becoming an interesting specification. -Wyllys Ingersoll On Mon, Dec 2, 2019 at 4:58 PM iang wrote: > > On 28/10/2019 22:40, Santiago Torres-Arias wrote: > > On Mon, Oct 28, 2019 at 04:20:39PM -0400, Daniel Kahn Gillmor wrote: > >> Hi OpenPGP folks-- > >> > >> The recently-announced OpenPGP test suite [0] inspired me to try > >> drafting a spec for a purely-functional, stateless OpenPGP command line > >> interface. The idea is that different implementers could provide the > >> same interface, focusing specifically on the object security aspect of > >> OpenPGP (leaving aside identity management). > >> ... > > I think this is a *phenomenal* idea. I wonder if this could mature in a > > well-defined API that e.g., gpgme could adopt? > > > Concur! > > > iang > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --0000000000003c92420598c0158f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Does anyone have a good es= timate of how many command-line oriented OpenPGP applications are actually = in use beyond GnuPG? Im really just curious, I was under the impression tha= t GnuPG=C2=A0is sort of the de-facto standard implementation for the majori= ty of OpenPGP users on a computer with a keyboard.=C2=A0 I know there are i= mplementations=C2=A0for a variety of other languages, but I wonder if they = have significantly motivated development teams that would take this on and = implement=C2=A0it in practice. Has the GnuPG team indicated an interest in = writing an entirely new CLI ?=C2=A0 For mobile applications and other OpenP= GP implementations that do not even have a CLI this is obviously not going = to be of interest, but I understand that that's not the target audience= for this sort of document anyway.

Im not trying t= o throw cold water on the efforts to standardize a more friendly interface = on an increasingly complicated protocol, I just wonder how far it will go b= eyond becoming an interesting=C2=A0specification.

= -Wyllys Ingersoll
=C2=A0

On Mon, Dec 2, 2019 at 4:58 PM= iang <iang@iang.org> wrote:
=

On 28/10/2019 22:40, Santiago Torres-Arias wrote:
> On Mon, Oct 28, 2019 at 04:20:39PM -0400, Daniel Kahn Gillmor wrote: >> Hi OpenPGP folks--
>>
>> The recently-announced OpenPGP test suite [0] inspired me to try >> drafting a spec for a purely-functional, stateless OpenPGP command= line
>> interface.=C2=A0 The idea is that different implementers could pro= vide the
>> same interface, focusing specifically on the object security aspec= t of
>> OpenPGP (leaving aside identity management).
>> ...
> I think this is a *phenomenal* idea. I wonder if this could mature in = a
> well-defined API that e.g., gpgme could adopt?


Concur!


iang

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--0000000000003c92420598c0158f-- From nobody Mon Dec 2 17:06:49 2019 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 154A41200E5 for ; Mon, 2 Dec 2019 17:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=0Tso9Wyu; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Rxgvxxal Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkwcHHmzwjJj for ; Mon, 2 Dec 2019 17:06:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7541200E0 for ; Mon, 2 Dec 2019 17:06:46 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1575335201; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=P8HMBAumdcrKJyh53fDYOMdLWxXk6m8gvoqfhdt0hUY=; b=0Tso9WyugyC/xUGWmgRdi3DXJm84Oc6lJUy3I4LCunTqLKLsueXW6aK6 VkTC/hBQeaVVEveQ2ZLZXdhs1WDZBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1575335201; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=P8HMBAumdcrKJyh53fDYOMdLWxXk6m8gvoqfhdt0hUY=; b=RxgvxxalJPik4M33B8fHJlq9+ZMcNrl0BP+hEm9q5XzPObtZ9IKG/lAC KH55ZW3E1BSkkjL0zwmYRaLahERq+xVbp3fv9rmGtGvQxR1vloSjUHZzm4 NsQaPY+nKqYt8zcVzH539gGPjvga7STHKY/irJJO7s77dnLeKzQFinzhsK eCz+aVXm2LzHh7i8+SjniXWoNr59oY0o3V33yEARvR+WKQ22iDr/6ZxMsJ WdhP27foYeMIuS/M4IMB2REfNaHT1kCeSM7N5Ls52nNI6SE/4OKkyBM/29 VRmfLFiUOYH66v5mjJYCtdr1wwtvW0L08g9DRgZdmBGmY8CyGlBfiw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id BF684F9A5; Mon, 2 Dec 2019 20:06:40 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 14B5120524; Mon, 2 Dec 2019 20:06:38 -0500 (EST) From: Daniel Kahn Gillmor To: Wyllys Ingersoll , "openpgp\@ietf.org OpenPGP" In-Reply-To: References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 02 Dec 2019 20:06:37 -0500 Message-ID: <87tv6i6wv6.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 01:06:48 -0000 --=-=-= Content-Type: text/plain Hi Wyllys-- On Mon 2019-12-02 17:27:09 -0500, Wyllys Ingersoll wrote: > Does anyone have a good estimate of how many command-line oriented OpenPGP > applications are actually in use beyond GnuPG? In practice today, GnuPG is certainly the standard. But rnp (from Ribose) and sq (from Sequoia) are two other CLI OpenPGP mechanisms; and hopenpgp-tools 0.22 implements a piece of sop already (as "hop"). And i've been working on a command-line interface in python based on PGPy as well. Maybe there are others? I don't know whether anyone has built a CLI tool atop (for example) OpenPGP.js. But if you look at the design of sop, it's also intended to hint at an underlying API that doesn't need to be strictly CLI-driven. As https://tools.ietf.org/id/draft-dkg-openpgp-stateless-cli-01.html says: While this document identifies a command-line interface, the rough outlines of this interface should also be amenable to relatively straightforward library implementations in different languages. If an OpenPGP toolkit can orient itself toward making a simple CLI interface like sop, it will hopefully also be able to provide an idiomatic library interface that aligns pretty closely with the same simplifications. But even if this proposal doesn't end up being explicitly functional in applications, it still represents a useful frame for an interoperability test suite, which is useful in terms of ensuring that we can upgrade the ecosystem. So, i think your question is a good one, but i hope that people can see this effort as a useful stepping stone toward a healthier OpenPGP ecosystem more generally. --dkg PS as far as GnuPG goes, note that more than half of the gpg command-line interface surface complexity is devoted to key management, none of which is exposed in sop. I hope people don't see sop as a replacement for all of that stuff! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXeW1HQAKCRB2GBllKa5f +LTXAQD1jc53IPYo4SLeljF+a0VM8cQ/g9An8CPES4tauPW1XwD+K3x74gcIGhT5 x/VybKcf7sYQNf9p47EUKqkOpmuz6QQ= =0pb6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 2 18:39:52 2019 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 477201200EC for ; Mon, 2 Dec 2019 18:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIYA6-DYLQ-Y for ; Mon, 2 Dec 2019 18:39:47 -0800 (PST) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38893120052 for ; Mon, 2 Dec 2019 18:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CRt2HdsUmxYr9KjGDOTPV+mpF7RJetL9aVbw6IWpl/g=; b=mBqOkKsIEkXBsHEThhx7DDLlnU 3LXHv730lc6S2oKak6ytpG8w8pGgwFfKQXgh6zlciKg8kNnltBBg2kTZG/N1b6nsHlQY7fHmfJfO+ jj16caTXZDGSLsVzk1vsmTXxW5puN9a4tKj5qpo9k9yYrgdRxVodHx0VC46zJWOFJm5DKcslaHnNn vzlX9Qw33PzN0/ycHRsw8PpK55KnmbGBxFM/YvRfUV1PdnlJ1yMUG4AigfAPDH51bqwiZy/i+ccjJ 7RnFuvb3K/x38bpXQb/keFA3LMb8jGJiPZukgTIxhQJEHWOUBN1mY/0zVxj92XvmWqeJHsar69CsI ayOmmZCw==; Received: from 140.200.232.153.ap.dti.ne.jp ([153.232.200.140] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iby6I-000651-UG; Tue, 03 Dec 2019 03:39:44 +0100 Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Tue, 03 Dec 2019 11:39:38 +0900 From: NIIBE Yutaka To: IETF OpenPGP In-Reply-To: <87tv7pwdcb.fsf@jumper.gniibe.org> References: <87a79kmhd1.fsf@iwagami.gniibe.org> <1572452632.29750.0@smtp.gmail.com> <87tv7pwdcb.fsf@jumper.gniibe.org> Date: Tue, 03 Dec 2019 11:39:38 +0900 Message-ID: <87k17eb09h.fsf@iwagami.gniibe.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Subject: Re: [openpgp] EdDSA problem and possible change about ECC X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 02:39:49 -0000 --=-=-= Content-Type: text/plain Hello, Attached are example EdDSA public and secret key with malformed MPI. In secret part and siganature (R and S), it starts by zero octet and it says it's 256-bit. With modified GnuPG (which can show malformed MPI representation), gpg -v --list-packet shows: ========================== # off=0 ctb=94 tag=5 hlen=2 plen=88 :secret key packet: version 4, algo 22, created 1541067011, expires 0 pkey[0]: 092B06010401DA470F01 ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: 4000001F8BEA42B3C74C50AA3589B1AA065F196857DB97A75E4A54953F093E6772 skey[2]: 0000000000000000000000000000000000000000000000000000000000000024 checksum: 07b6 keyid: 603315C930792940 # off=90 ctb=b4 tag=13 hlen=2 plen=35 :user ID packet: "ECC Test Key " # off=127 ctb=88 tag=2 hlen=2 plen=148 :signature packet: algo 22, keyid 603315C930792940 version 4, created 1541115112, md5len 0, sigclass 0x13 digest algo 8, begin of digest c0 f0 hashed subpkt 33 len 21 (issuer fpr v4 F2C1264E292A298AEB4BC348603315C930792940) hashed subpkt 2 len 4 (sig created 2018-11-01) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 34 len 2 (pref-aead-algos: 2 1) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 07) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 603315C930792940) data: 00A594ACA396212AD2800C8ED426449ECABC4B561000E12B96D8EFE3BDBED153 data: 00112F614291A5C8E5548B6CACEBABA1DB95394DAC15461C21EC9AB037A77D07 ========================== In my opinion, those data (secret part, signature) are better to be defined as non-MPI. Once, I thought that it is also good for the public part (the point representation in pkey[1]) to be defined as non-MPI. However, this part is used for fingerprint computation, so, I realized that changing the definition is not easy. -- --=-=-= Content-Type: application/pgp-keys Content-Disposition: attachment; filename=ecc-test-key-sos-1-pub.asc Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptRE1FVzlyUkF4WUpLd1lCQkFI YVJ3OEJBUWRBQUFBZmkrcENzOGRNVUtvMWliR3FCbDhaYUZmYmw2ZGVTbFNWClB3aytaM0swSTBW RFF5QlVaWE4wSUV0bGVTQThaV05qTFhSbGMzUkFaWGhoYlhCc1pTNXZjbWMraUpRRUV4WUkKQUR3 V0lRVHl3U1pPS1NvcGl1dEx3MGhnTXhYSk1Ia3BRQVVDVzl1TTZBSWJBd1VMQ1FnSEFnTWlBZ0VH RlFvSgpDQXNDQkJZQ0F3RUNIZ2NDRjRBQUNna1FZRE1WeVRCNUtVREE4QUVBQUtXVXJLT1dJU3JT Z0F5TzFDWkVuc3E4ClMxWVFBT0VybHRqdjQ3MiswVk1CQUFBUkwyRkNrYVhJNVZTTGJLenJxNkhi bFRsTnJCVkdIQ0hzbXJBM3AzMEgKPXljWWIKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0st LS0tLQo= --=-=-= Content-Type: application/pgp-keys Content-Disposition: attachment; filename=ecc-test-key-sos-1-sec.asc Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgUFJJVkFURSBLRVkgQkxPQ0stLS0tLQoKbEZnRVc5clJBeFlKS3dZQkJB SGFSdzhCQVFkQUFBQWZpK3BDczhkTVVLbzFpYkdxQmw4WmFGZmJsNmRlU2xTVgpQd2srWjNJQUFR QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSkFlMnRDTkZRME1nClZH VnpkQ0JMWlhrZ1BHVmpZeTEwWlhOMFFHVjRZVzF3YkdVdWIzSm5Qb2lVQkJNV0NBQThGaUVFOHNF bVRpa3EKS1lyclM4TklZRE1WeVRCNUtVQUZBbHZiak9nQ0d3TUZDd2tJQndJRElnSUJCaFVLQ1Fn TEFnUVdBZ01CQWg0SApBaGVBQUFvSkVHQXpGY2t3ZVNsQXdQQUJBQUNsbEt5amxpRXEwb0FNanRR bVJKN0t2RXRXRUFEaEs1Ylk3K085CnZ0RlRBUUFBRVM5aFFwR2x5T1ZVaTJ5czY2dWgyNVU1VGF3 VlJod2g3SnF3TjZkOUJ3PT0KPWIwYTgKLS0tLS1FTkQgUEdQIFBSSVZBVEUgS0VZIEJMT0NLLS0t LS0K --=-=-=-- From nobody Tue Dec 3 00:06:05 2019 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 6402112012C for ; Tue, 3 Dec 2019 00:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWXDxepUA4hc for ; Tue, 3 Dec 2019 00:06:01 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBE9120024 for ; Tue, 3 Dec 2019 00:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1575360361; x=1606896361; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K5KIaj61mppTR2or5POfFwbgswIW1evvEPu4Q/m7G4g=; b=MuiRbjYEPL4pxsZsZyUnIQL/qLEAc69HDjyhd07ATAX23jSrD7Exxywe YzdWM3qQXW1PnuMweEPDldVki73/tOhrYtjl89RFL1Zg9Hi7kGbK+DPxv 7ug89qYgaQRsnuEGgFbfN6uh3+CzaPi6xc+1UKqRPNYaZaFee0gNj6zaf XyU8jn+lIQ9+RvX8b2kj2AJ2qufyr89vSOVcsHH4eOK1d3afNKxEIcsE6 wkZk9IcsolwMnN6DI8iEzgtgmuxTfnR4KtSZ3naqF4ycwTwtOP3CCDeAz usZ1bPObT2v4+KK7aNQ4+t28CTekYOUmlv1/uhpknPkTfSohT5vEb7bxR Q==; X-IronPort-AV: E=Sophos;i="5.69,272,1571655600"; d="scan'208";a="102944409" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2019 21:05:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 3 Dec 2019 21:05:56 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 3 Dec 2019 21:05:56 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , Wyllys Ingersoll , "openpgp@ietf.org OpenPGP" Thread-Topic: [openpgp] Stateless OpenPGP command line interface proposal Thread-Index: AQHVjc02Js8pCBH3uk2cv4yI2lLGpqdvqluAgDcXWoCAAAgHgIAALI6AgAFO1CE= Date: Tue, 3 Dec 2019 08:05:55 +0000 Message-ID: <1575360357529.12665@cs.auckland.ac.nz> References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> , <87tv6i6wv6.fsf@fifthhorseman.net> In-Reply-To: <87tv6i6wv6.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 08:06:03 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >Maybe there are others?=0A= =0A= I threw together a quick command-line en/decrypt tool as a CLI wrapper arou= nd=0A= the cryptlib API when I got frustrated with how complex GPG was to use, so= =0A= there's at least one more, built purely as a CLI-around-an-API app.=0A= =0A= Peter.=0A= From nobody Tue Dec 3 12:50:32 2019 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 2B2BE12003E for ; Tue, 3 Dec 2019 12:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=BiLZ7Nep; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=4knT195W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXpUpYHFnN53 for ; Tue, 3 Dec 2019 12:50:29 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711C712002F for ; Tue, 3 Dec 2019 12:50:29 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1575406224; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GkRch1dHV/ok0Zipf21AMa2zWnf1rlmw5PCyAxncav0=; b=BiLZ7Nep0IuUFTLGGY7eSfaYXHWQOtQCAlS9gclQWcfwOH1t72es33Vj yrBaeQK2hxwLmcdAht9YMdet53C5CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1575406224; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GkRch1dHV/ok0Zipf21AMa2zWnf1rlmw5PCyAxncav0=; b=4knT195WvhNLyBy+5OCteGOHr+ZMzf8azTM1V8tSCNYsqloSCo1RxqlB 6WkQn0wbvvBWfw5iKpnCQr58ANWT4gZmdHfgBSGmRVzelRpo3BzxzkZlr+ crZ7XHEi9IemvQszUtEyNXLNhh7Rq5byhpULMTtKOHByrGX37mT1BCRWrm 3Oo5AYXXD7kP8GXTqkyCqGdbdsu5/KLMcT19CbyCl4BWme7AiqJxU/GK6i Vn8W1+2haihx8VA3duVTd/6rfsr8ooQQ5A9utLc9EBccKN1gsKh/bLjis2 /n4UleIWNvrJrYXfWhzkRarADPv0JQBSEQ3sC3uoIjHyE1J6DKq8BQ== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D1E43F9A5; Tue, 3 Dec 2019 15:50:24 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3A2112029C; Tue, 3 Dec 2019 15:47:10 -0500 (EST) From: Daniel Kahn Gillmor To: Peter Gutmann , Wyllys Ingersoll , "openpgp\@ietf.org OpenPGP" In-Reply-To: <1575360357529.12665@cs.auckland.ac.nz> References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> <87tv6i6wv6.fsf@fifthhorseman.net> <1575360357529.12665@cs.auckland.ac.nz> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 03 Dec 2019 15:47:09 -0500 Message-ID: <87o8wp6ss2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 20:50:31 -0000 --=-=-= Content-Type: text/plain On Tue 2019-12-03 08:05:55 +0000, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > >>Maybe there are others? > > I threw together a quick command-line en/decrypt tool as a CLI wrapper around > the cryptlib API when I got frustrated with how complex GPG was to use, so > there's at least one more, built purely as a CLI-around-an-API app. Thanks for the observation, Peter. Does this have a name, or published documentation someplace? A direct pointer would be helpful! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXebJzQAKCRB2GBllKa5f +KH9AQDJZWJwGvm+9SrzL7nH8PBiHFc1XkB9JX6C/yqfxWDICwEAi/1aX9T3hrDi aIhxacDOM/SFQ1MaxH63wN4e4AVjKgM= =+smS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 4 16:01:18 2019 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 D49F612002F for ; Wed, 4 Dec 2019 16:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooS5fdcwj9BZ for ; Wed, 4 Dec 2019 16:01:14 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BE112004D for ; Wed, 4 Dec 2019 16:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1575504074; x=1607040074; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jU5GdTDRkA3Y7qZe33k5+177/owilHKxhhHgFW+3jIk=; b=R9WNmBy0eQPvWg7QfTKUYRg/nWzujQqKUzMwv5p0eIfmqhBIASWNd/xF QXulCUYXZihsjsy6PhXoN0RjGPKPNnJm2B3ipRqslyA0jgjymXDNBaKXj eKieggzYFw5x61gCGX/Hh2nHtZysqvwk/4D1Lzg1MKLa1saKdmsN6UZdb n3hExtCg6KaE4OjTokOjGnShTAjG5V7KWB81C02Bhz+MVfG7xyNYPhrLo FLqhLuHXIsXcY1/xnBkD67exZbyhllVQjnYnYL0QXslfWXBEVoSdOJTMx fRUHano0x5zyqAuKSc2VxjjVqZhdufNTDYi2/extyCJ0fJJXPZZH+ucHb g==; X-IronPort-AV: E=Sophos;i="5.69,279,1571655600"; d="scan'208";a="103291964" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Dec 2019 13:01:10 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Dec 2019 13:01:09 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 5 Dec 2019 13:01:09 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , Wyllys Ingersoll , "openpgp@ietf.org OpenPGP" Thread-Topic: [openpgp] Stateless OpenPGP command line interface proposal Thread-Index: AQHVjc02Js8pCBH3uk2cv4yI2lLGpqdvqluAgDcXWoCAAAgHgIAALI6AgAFO1CH///sCgIACoiJD Date: Thu, 5 Dec 2019 00:01:09 +0000 Message-ID: <1575504071480.48543@cs.auckland.ac.nz> References: <87ftjck4fc.fsf@fifthhorseman.net> <20191028204032.bubbzueti2ebpobm@LykOS.localdomain> <81f3d7c7-f19d-38ca-923d-8a828779d9dc@iang.org> <87tv6i6wv6.fsf@fifthhorseman.net> <1575360357529.12665@cs.auckland.ac.nz>,<87o8wp6ss2.fsf@fifthhorseman.net> In-Reply-To: <87o8wp6ss2.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 00:01:17 -0000 Daniel Kahn Gillmor writes:=0A= >On Tue 2019-12-03 08:05:55 +0000, Peter Gutmann wrote:=0A= >> Daniel Kahn Gillmor writes:=0A= >>=0A= >>>Maybe there are others?=0A= >>=0A= >> I threw together a quick command-line en/decrypt tool as a CLI wrapper a= round=0A= >> the cryptlib API when I got frustrated with how complex GPG was to use, = so=0A= >> there's at least one more, built purely as a CLI-around-an-API app.=0A= >=0A= >Thanks for the observation, Peter. Does this have a name, or published=0A= >documentation someplace? A direct pointer would be helpful!=0A= =0A= It doesn't really have a name (I just called the binaries "pgpencrypt" and= =0A= "pgpdecrypt") or even a public presence, it's just a quick wrapper for a=0A= handful of library calls. I commented on it to point out that you can turn= a=0A= library/API into a CLI application with very little work, since the topic o= f=0A= building an app from an API had come up.=0A= =0A= Peter.=0A= From nobody Thu Dec 19 06:36:41 2019 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 EDE4312083B for ; Thu, 19 Dec 2019 06:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_dF8rKdS6JK for ; Thu, 19 Dec 2019 06:36:38 -0800 (PST) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE72B1201CE for ; Thu, 19 Dec 2019 06:36:38 -0800 (PST) Received: by mail-oi1-f181.google.com with SMTP id i1so2848686oie.8 for ; Thu, 19 Dec 2019 06:36:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K6UK7ZX1UFp9jgJL9yQYwa8FIz44ziUKo6q8w7h3CO4=; b=ZQT+gigdLb3iOdWd9XmosTOzSh+7O30FpXuV/6xB7aZ0+Qd+OEYdQkW0JLRqZ1Wv8Q +OvYoW3Lcpn4Nu2APNd99Fgx7CspnHkBYOcdIXTP12fsGf2Xda+0AVqK/AufhPjy+hAo qahHewkvY7byxzrX1hf+n6dcJQ9z7wNHIoAKxmOjfZJkG3VNJ8t/B6sxTNYdouIQW3Bw dWDyOgDin5hGLfyGq1KPDGusQwSY54X7z9TVDY94kDR1xrfGYvvS+hKFTBw7rHTQ0saK /Qy9GgPO4YWrrT/BCY1K3zIgTygXafB1GrxcGysINhfwCEHCnDZMa2TI12G6cLobTQXs 7qPQ== X-Gm-Message-State: APjAAAUYItCt7GwQzfccteogDqmKsgUgYzXF836hKsJVauymJ9+VNwn1 i2BXlyHZzSNo6JPnCdr2rGhzDwzycMRtel5jqPQ= X-Google-Smtp-Source: APXvYqxpeRgevFtgNFWvsN5EwP8Bx6a8vF8GozDVACpDs1di7ZTMxv/M/uIBwYfy1M2V1wXmm52CQoXj+vEIwAisO2U= X-Received: by 2002:aca:cdd6:: with SMTP id d205mr2200300oig.90.1576766197872; Thu, 19 Dec 2019 06:36:37 -0800 (PST) MIME-Version: 1.0 References: <87zhgxo0bm.wl-neal@walfield.org> <20191118095001.GM32847@mit.edu> In-Reply-To: <20191118095001.GM32847@mit.edu> From: Phillip Hallam-Baker Date: Thu, 19 Dec 2019 09:36:26 -0500 Message-ID: To: Benjamin Kaduk Cc: Jon Callas , Claudio Luck , IETF OpenPGP , Jon Callas Content-Type: multipart/alternative; boundary="0000000000001e3dac059a0f7dbf" Archived-At: Subject: Re: [openpgp] Dealing with clock skew X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 14:36:40 -0000 --0000000000001e3dac059a0f7dbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Getting back to the original question, why reject a signature because it claims to be signed in the future in the first place? One of the things that held back use of S/MIME was idiot MUAs which would shout WARNING THIS MESSAGE IS DIGITALLY SIGNED. Use of TLS with self signed certificates resulted in warnings when visiting sites without TLS did not. It is highly unlikely that the time value in the document is relevant at all. So forget 5 minute windows. Applications SHOULD NOT reject messages unless they have a really good reason. The fact that a document is signed tells us nothing about the truth value of the claims made inside the document. So while I have a really hard time believing that the purported time stamp value actually matters, it is in any case the wrong technology to use in the case that it actually does. The only circumstances where a signing time is likely to matter in a protocol is when it is necessary to determine whether event A happened before or after event B. And for the reasons outlined by Jon, the only tool that is going to be able to provide that assurance reliably is some form of notary agent. There is no a priori ordering of events. It is always necessary to specify the frame of reference. OpenPGP provides a cryptographic message syntax. It is not designed to provide a security assertion capability. If people want that capability, they should use SAML (or something like it) which was built on a framework originally designed to support transactional applications. That is what the conditions and advice slots were originally designed to support in the TAXI (Trust Assertion XML Infrastructure) scheme. So just stop checking the timestamps at all. Best case is it provides no value. On Mon, Nov 18, 2019 at 4:50 AM Benjamin Kaduk wrote: > On Sat, Nov 16, 2019 at 03:06:13PM -0800, Jon Callas wrote: > > > > > > In the general case, you can't consider a time measurement to be a > scalar, it has to be at the very least a complex number of the form [time= , > skew]. As Derek noted, Kerberos used a skew of five minutes. While Neal > Walfield noted in his original post that he's seen skew of 20min, I concu= r > that that seems a bit long. My naive home set-up commonly has alarms acro= ss > devices being =C2=B12s or less, but that's because they're all getting ti= me from > some combination of NTP and cellular network time, which is ultimately GP= S > time (and of course, skew). I think five minutes is likely reasonable, bu= t > *some* skew is unavoidable. Moreover, anyone who's on satellite networks = is > seeing latency of over a second and once you throw in normal exponential > backoff, five minutes seems about as short as is reasonable. > > I believe that if Kerberos was starting over now, the 5 minutes would be > seen as excessively long, FWIW. > > -Ben > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --0000000000001e3dac059a0f7dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Get= ting back to the original question, why reject a signature=C2=A0because it = claims to be signed in the future in the first place?

One of the things that held back use of S/MIME= was idiot MUAs which would shout WARNING THIS MESSAGE IS DIGITALLY SIGNED.= Use of TLS with self signed certificates resulted in warnings when visitin= g sites without TLS did not.

It is highly unlikely that the time value in the document is relevant a= t all. So forget 5 minute windows. Applications SHOULD NOT reject messages = unless they have a really good reason.=C2=A0

The fact that a document is signed tells us nothing ab= out the truth value of the claims made inside the document. So while I have= a really hard time believing that the purported time stamp value actually = matters, it is in any case the wrong technology to use in the case that it = actually does.
=
The only c= ircumstances where a signing time is likely to matter in a protocol is when= it is necessary to determine whether event A happened before or after even= t B. And for the reasons outlined by Jon, the only tool that is going to be= able to provide that assurance reliably is some form of notary agent. Ther= e is no a priori ordering of events. It is always necessary to specify the = frame of reference.

OpenP= GP provides a cryptographic message syntax. It is not designed to provide a= security assertion capability. If people want that capability, they should= use SAML (or something like it) which was built on a framework originally = designed to support transactional applications. That is what the conditions= and advice slots were originally designed to support in the TAXI (Trust As= sertion XML Infrastructure) scheme.

So just stop checking the timestamps at all. Best case is it pro= vides no value.



On Mon, Nov 18, 2019 at 4:50 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Sat, Nov 16, 2019 at 03:06:13PM -0800, Jon Callas= wrote:
>
>
> In the general case, you can't consider a time measurement to be a= scalar, it has to be at the very least a complex number of the form [time,= skew]. As Derek noted, Kerberos used a skew of five minutes. While Neal Wa= lfield noted in his original post that he's seen skew of 20min, I concu= r that that seems a bit long. My naive home set-up commonly has alarms acro= ss devices being =C2=B12s or less, but that's because they're all g= etting time from some combination of NTP and cellular network time, which i= s ultimately GPS time (and of course, skew). I think five minutes is likely= reasonable, but *some* skew is unavoidable. Moreover, anyone who's on = satellite networks is seeing latency of over a second and once you throw in= normal exponential backoff, five minutes seems about as short as is reason= able.

I believe that if Kerberos was starting over now, the 5 minutes would be seen as excessively long, FWIW.

-Ben

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