Re: [openpgp] review of the SOP draft

Clint Adams <clint@debian.org> Sat, 16 November 2019 17:08 UTC

Return-Path: <clint@debian.org>
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 9A45412008C for <openpgp@ietfa.amsl.com>; Sat, 16 Nov 2019 09:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hcBcaie8ybHa for <openpgp@ietfa.amsl.com>; Sat, 16 Nov 2019 09:08:55 -0800 (PST)
Received: from thumb.scru.org (thumb.scru.org [IPv6:2600:3c00:e000:227::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F70912001A for <openpgp@ietf.org>; Sat, 16 Nov 2019 09:08:55 -0800 (PST)
Received: by thumb.scru.org (Postfix, from userid 1000) id ECD8541476; Sat, 16 Nov 2019 17:08:53 +0000 (UTC)
Date: Sat, 16 Nov 2019 17:08:53 +0000
From: Clint Adams <clint@debian.org>
To: openpgp@ietf.org
Message-ID: <20191116170853.GA10240@scru.org>
References: <87mud28fds.fsf@curie.anarc.at> <87h83arpby.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87h83arpby.fsf@fifthhorseman.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7Jrmf6CncfdaVAbWscEVMtx9uFo>
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: Sat, 16 Nov 2019 17:08:57 -0000

> >> armor: armor: Add ASCII Armor
> >> -----------------------------
> >
> > [...]
> >
> >> If the incoming data is already armored, and the `--allow-nested` flag
> >> is not specified, the data MUST be output with no modifications.
> >> Data is considered ASCII armored iff the first 14 bytes are exactly
> >> `-----BEGIN PGP`. This operation is thus idempotent by default.
> >  
> > Explain why we want idempotent and why we want to do this guessing game.
> 
> I'm at a bit of a loss here, because these seem obvious to me.
> 
> We want a guessing game because users who don't know what they want are
> going to guess anyway, and they're likely to guess wrong.  We might as
> well guess on their behalf if they don't know.
> 
> We want idempotent because "ensure this thing is armored" is a
> reasonable semantic request -- indeed, it's probably the *only*
> reasonable semantic request.  Perhaps we could drop --allow-nested?

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.

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.

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).