Re: [openpgp] review of the SOP draft

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sun, 17 November 2019 14:21 UTC

Return-Path: <dkg@fifthhorseman.net>
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 9C1F512010D for <openpgp@ietfa.amsl.com>; Sun, 17 Nov 2019 06:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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=afHgcmwD; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=M9P9JQX+
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 iQeGUZ4V9NQT for <openpgp@ietfa.amsl.com>; Sun, 17 Nov 2019 06:21:57 -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 B5BFC12006D for <openpgp@ietf.org>; Sun, 17 Nov 2019 06:21:57 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1574000515; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=V/+bfCsdqaKsGaB/SqBbHRAzU7SWvQqN63FlgL1PMoA=; b=afHgcmwDsgXQ2YY/GBCVz9V+NWWjYj/SX+/evQ6sMnvyVxjkv5oyf/gp xEBPuT9bZ9hjWCLuwT29wAD0wDxtDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1574000515; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=V/+bfCsdqaKsGaB/SqBbHRAzU7SWvQqN63FlgL1PMoA=; b=M9P9JQX+VdU+doF+8aNFuu6h1DzVMfJzEE9jb8ypMgAa6I/qSvOndB3q bfZBw58q++SfpDaLeW+1LKzZSQTSCq8p5EiUze1k0cRVjaw6+1kKzs1tGN SvBQKTJ2GhdT12C+Jzxh/l3OLc89kfjiytiSS35ysW58aQl5NxSRFWvGSo U6lqdkoQUqwFQI+Ab3B8lcy3mqTie/kfuck6ZfE8xW64WezeqsUbAqp+bj Eu4Z3ae1Y3lw64zTnqapJ/kjPP7EMD+ZwQPB+BIXymInW0MQ3n5/VWzvUr m7OtMgRFBmWz6LlMS83D+SGkYmxzsvvAaV+u6MCDQcV3vtqH9tfiuQ==
Received: from fifthhorseman.net (unknown [182.55.86.21]) (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 88C79F9A9; Sun, 17 Nov 2019 09:21:55 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 048DF2058E; Sun, 17 Nov 2019 16:19:06 +0200 (EET)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Clint Adams <clint@debian.org>, openpgp@ietf.org
In-Reply-To: <20191116170853.GA10240@scru.org>
References: <87mud28fds.fsf@curie.anarc.at> <87h83arpby.fsf@fifthhorseman.net> <20191116170853.GA10240@scru.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: Sun, 17 Nov 2019 22:19:05 +0800
Message-ID: <87mucumvqe.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/x-i08HfSEsniAkkJxtOUOiAAXZE>
Subject: Re: [openpgp] review of the SOP draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2019 14:22:00 -0000

Hi Clint--

Thanks for your feedback!

On Sat 2019-11-16 17:08:53 +0000, Clint Adams wrote:
> As an implementer, I don't want this because this kind of run-time
> detection is annoying, though it would be more annoying if the check
> weren't explicit.

I understand that you'd like to implement something more minimal, but
sop is trying to supply plausible interfaces for use cases for a
developer who doesn't know all the grubby details of OpenPGP but still
wants to work with confidential data as framed by OpenPGP.

> As a user, I don't want this because it violates the POLA.  Why would
> I be directing something to "ensure this thing is armored"?  If I piped
> something to base64 and it came out unchanged I would be shocked and
> horrified.

The only use case i'm currently imagining for using `sop armor` is that
the user has come across some OpenPGP content in some environment, and
they want to transmit it over a channel that is not 8-bit clean (or
perhaps they want to put it into a text-based revision control system
that would rather not host binary blobs).

They have two choices:

 - detect whether it is already armored, and if not, invoke `sop armor`
 - unconditionally invoke `sop armor`, to ensure that it is armored.

The latter sounds simpler and easier, and it really isn't surprising or
astonishing, so i'm not sure it really violates POLA.

Vincent Breitmoser proposed the idempotency requirement over in
https://gitlab.com/dkg/openpgp-stateless-cli/merge_requests/3 and i
merged it because it seemed plausible to me.

I'm currenly thinking of dropping --allow-nested entirely, but i see
you've given that a thumbs-down on
https://gitlab.com/dkg/openpgp-stateless-cli/issues/15

if you want me to consider that more, a clearer use for nested armoring
would be welcome.

Do you have another use case that we should consider?

> Along those lines, having some subcommands default to binary output
> and others default to ASCII Armor also seems confusing except in cases
> like `armor` and `dearmor` where the intent would seem obvious
> (modulo this whole idempotency thing).

I believe all the subcommands default to armored output (with the
exception of "sop dearmor").  Are you seeing somewhere where that's not
the case?

    --dkg