Re: [openpgp] OpenPGPv5 wish list

Philippe Cerfon <> Mon, 29 April 2013 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F13721F9ABA for <>; Mon, 29 Apr 2013 10:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9FGI0fh2FeuY for <>; Mon, 29 Apr 2013 10:53:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) by (Postfix) with ESMTP id CECFF21F9AB9 for <>; Mon, 29 Apr 2013 10:53:40 -0700 (PDT)
Received: by with SMTP id aq17so7552847iec.37 for <>; Mon, 29 Apr 2013 10:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=CEOlh4VxbCAYzpTRi9v9tjSkBfONk4E/+MavXtMbYDo=; b=px2kS/zbRhRv+Krc5sF8FkeB6bFYmtylGLc5oaVGsbaihnvBAKDKdlulyba0NAFUV/ BsjSLdPIeavQ8OPqShZiNXrlJWw4pbeMXWfolMaL/BiBdF69ITvJffvibByJBhucwB1o cs0dOW4YFYQSshUz28jRC9F9xP6gw7LEg6SY4y04az8EHdDjN8LKXB20W/szaZnrJ2yc 7sfo2WgJ51dLItlMPTiOEZ5AvIQtEPm69vRUkoAjCcF1WXXNa2HQmxNktEZG4uqsmLfo ht8SZySsGoTqqtbGx9wAaO1LSmYvAJmr38PI3JijGYLXaWPInKLOxBT/y++vMaCfVGlo 8mrg==
MIME-Version: 1.0
X-Received: by with SMTP id p1mr8091290igw.36.1367258020408; Mon, 29 Apr 2013 10:53:40 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 10:53:40 -0700 (PDT)
Date: Mon, 29 Apr 2013 19:53:40 +0200
Message-ID: <>
From: Philippe Cerfon <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [openpgp] OpenPGPv5 wish list
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Apr 2013 17:59:54 -0000

Moving over to from gnupg-devel.

On Mon, Apr 29, 2013 at 1:52 PM, Werner Koch <>; wrote:
> I don't want the whole X.509 mess introduced in a protocol we tried to
> keep clean for real use.
Well actually the contrary seems to be the case... OpenPGP is rather
only used for mail and plain file encryption/signing, which covers of
course already many fields, but nothing advanced.
It would never have any chance to be used for government ID cards, or
similar projects.

> Please read 5.11:
> There is nothing which enforces how you represet the name, you may put
> arbitrary data into the UID.  However, it is common to use a mail
> address and thus GnuPG (by default) checks for that.
Yeah I knew... but right now it's also used for the name of the user,
which is the primary identification property... and it shouldn't be
used for that (from a design POV).

> Why should we change somthing which has not shown problems in the
> past.  If you want X.509, use X.509 for example with gpgsm.
Obviously I don't want X.509 or I'd use it.
And I don't see how this is touched by X.509 anyway.
Of course there showed never problems up with the critical flag,
simply as no-one uses it... yeah I know, gpg understands it... but one
cannot even set it, can one?

On Mon, Apr 29, 2013 at 4:37 AM, Hauke Laging
<>; wrote:
>> 1) much more property fields that describe the key holder
> That's easy as it can be done with notations; no need to change the protocol.
Well technically,... but there need such common notification to be
defined, for all these properties, which is the important part here.

> 1) How secure is the key?
> 2) What is the key used for?
> 3) How was the identity checked when certifying, how the email address and how
> the comment?
Absolutely agreed... especially in a machine understandable way.

> 4) What statement does this signature make?
That could be done via policy sig subpackets... even though this is
not exactly defined right now.

> You should not be forced to sign a UID as a whole.
In principle yes... it’s handy though to have a unique identifier
(which is not the fingerprint) on keys... whether this needs to be
signed by other users or just by the key itself is another question.

> 1) For compatibility with the signature laws: We really need the option to
> extend certifications from UIDs to subkeys. That way you could have a "normal"
> key and a CA could be sure that a certain subkey is on a smartcard only.
> 2) Officially supported offline main keys. Currently just a GnuPG extension.
> IMHO the most important feature with respect to security (for everyday usage
> keys).

> 3) Double-digest signatures and double-cipher encryption in case one gets
> broken.
Absolutely agreed, though it would be even better to allow arbitrary
number of such.
Maybe one could even think of doing the same with differen crypto
systems (i.e. one that was not vulnerable to Shore ;) )

> 4) Signature weight: Limit the signing power of a key (to 1/n) so that
> signatures of n different keys are enforced for paranoid applications.

> 5) Seperate header files for encryption. We have detached signatures. Today
> you have to rewrite a huge encrypted file if you want to add (or remove)
> recipients.
Not so sure about this... to me the rationale behind the detached sigs
is rather that you can keep the signed-only file in clean text.
The encrpyted file is unreadable anyway, so you can also include the
session key in it... and that you can re-encrypt quite fast at a later
point for different users.

On Mon, Apr 29, 2013 at 7:17 AM, Robert J. Hansen <>; wrote:
> I'll make my own wish list simple:
> I don't want *anything* new included in the standard unless there exists
> at least one user who says, "the absence of this feature is a
> showstopper for me and is blocking my adoption of GnuPG."  This user
> needs to be able to show a real-world use case and be willing to
> volunteer to run trials in a real-world environment.
> No real-world user?  No feature.
Well that's kinda stupid as it boils down to the hen egg problem, ain't it?
Especially that OpenPGP looses ground in most areas (unless perhaps
OpenSource) against X.509 should already show, that there are many