Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt]

Guillem Jover <> Fri, 19 February 2021 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE5883A11DE; Fri, 19 Feb 2021 09:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Status: No, score=-1.107 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, PDS_RDNS_DYNAMIC_FP=0.01, RCVD_IN_SORBS_DUL=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D7ugWx7cMdgu; Fri, 19 Feb 2021 09:08:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE6993A11E0; Fri, 19 Feb 2021 09:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; ; s=201908; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:From:Reply-To:Subject:Content-Transfer-Encoding: Content-ID:Content-Description:X-Debbugs-Cc; bh=/LnYSaIO6ynX4Xmj2J6eXN5m/eOK40jHkV6CnqMBqpc=; b=Y984C6e9O2jjsEHp0HLZasAp24 DyYcrRBZQ01MROWTntu8wbWllyEkpzrz8hBTusRJZyNWpt4lIYT0vV+6SMeUOvb39Ing/O4fF7LaE 4JSRLO3Ah4BubmbNvrPBsQ2sMfXC34mjiuasngQTpb7HyKTs31cmBu8evGMjfeaF88hSgCdkK+L/z 1Wkld8Ez4UN8AsNMwJP0gWwIXWHdwQ5bGc4uSI/pgK7k5YUxP1/fFJ/dpNeyAVMpViqc85NK959L1 6vegoRYgUJ05nDWOGcfdTk4YaX22XnIIcFhlaQC9Q3bYf4WEWwRj5VIXbMIUvNuXngLlBO2MVp5Lw B//rVXcg==;
Received: from guillem by with local (Exim 4.92) (envelope-from <>) id 1lD9G5-0001y5-J2; Fri, 19 Feb 2021 18:08:01 +0100
Date: Fri, 19 Feb 2021 18:08:01 +0100
From: Guillem Jover <>
To: Daniel Kahn Gillmor <>
Cc: Guillem Jover <>, Andrew Gallagher <>,
Message-ID: <YC/>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt]
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: Fri, 19 Feb 2021 17:08:13 -0000

On Mon, 2021-02-15 at 18:56:34 -0500, Daniel Kahn Gillmor wrote:
> It seems clear to me that the text about whitespace that was merged into
> -01 doesn't have WG consensus at the moment -- iiuc, it may address the
> original concern raised by Guillem, but is unintentionally overbroad,
> and might introduce further incompatibilities between implementations if
> they try to follow the spec as written.


> In the meantime, so we don't lose sight of the legitimate problem that
> Guillem wants addressed, I've opened

Thanks. I think there are three related issues here:

  * Non-uniform definition and usage of "whitespace/blank" in the RFC.
    This makes it difficult to understand and interpret what's intended,
    and affects how people implement. (Clarifying this was my main intent.)

  * Consideration on what set of whitespace should be accepted as valid,
    even reducing or augmenting. This is going to create a potential
    tension between interop, backwards compatibility and security
    concerns when chaining various implementations. (I don't mind greatly
    about this one, as for dpkg I'd need to decide based on the least
    common denominator from the implementations supported anyway.)

  * Documenting that regardless of the set of characters defined as
    valid whitespace, accepting a non-reduced set of characters can have
    security implications when chaining various implementations with
    different acceptance checks. (I think this would also be useful
    for glue implementations and "users", such as dpkg.)

> If someone from the group wants to propose alternate text that addresses
> the issue but doesn't introduce the inconsistencies identified by Andrew
> and others, then please propose that text on-list here (in a different
> thread?)  -- and if you can also make it as a merge request on gitlab
> that'd be a bonus.

I might try, but I'm not sure I'll have the immediate time for this.