Re: [secdir] [new-work] WG Review: Open Specification for Pretty Good Privacy (openpgp)

Phillip Hallam-Baker <> Wed, 17 June 2015 15:25 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id C57CF1AD09D; Wed, 17 Jun 2015 08:25:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=ietf1; t=1434554732; bh=7dnhihq7aEEk6QCZz0YDi6jWSffC4jkoNCGXFpT0ZYg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=KzlWBvL51PDgpjLHn4LJU1NOVFEmzjypvfpTk7ohoZGIt9CK9j2Ytr5cPnMqK2StF fCuo72ChENqSBmYhcz8KHU0nAjBQtTfq+JJ32tCMs/hkV3Sf/AZSv1m1sIz4Vk8LS4 I7Rq9UQVm5uY6GNVhWwGyv6Hk4SLITA4IiVbYoFE=
Received: from localhost ( []) by (Postfix) with ESMTP id CFE7A1B366B; Tue, 16 Jun 2015 09:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jmimHPop720W; Tue, 16 Jun 2015 09:36:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D92071B3684; Tue, 16 Jun 2015 09:36:04 -0700 (PDT)
Received: by laka10 with SMTP id a10so15299419lak.0; Tue, 16 Jun 2015 09:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LU8/HrV42Xw4QOcFwC6iITU7f6cpubqrieFKiuGdooI=; b=ylVIkRbDao3cHxe4Mrgl3tcRFywqyF6efpvuK0j2Xmcf/rNdfby4b9XK8Hqhox3Pkn lUgdtSS5eJevdkQ/nqcCvS6zsJJIBg+TD8Hgy5vvyV2SYftnjv55IYTBlWMYZ0zGO4Ev AllTo0WCF4aQxzGbQ0GirfOoVPHd6ssogUx+DDHFI5XXHPivTyyvyULJfkyuARXVAV// qa+itouT/xuZc5zpAghRDyc0Iaw4+fCPora6xTV0RojZsChc8WW9CE6ARc8FDiBoIYRd dFhgWRk97A3JnekYScn1D/m+m9bYoaB0N/bYRXWsYas0mWacMcmXXHF29WrkErSEdZjE hdGQ==
MIME-Version: 1.0
X-Received: by with SMTP id zc5mr2181575lbb.91.1434472563413; Tue, 16 Jun 2015 09:36:03 -0700 (PDT)
Received: by with HTTP; Tue, 16 Jun 2015 09:36:03 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 16 Jun 2015 12:36:03 -0400
X-Google-Sender-Auth: rnlBkT0XGhJS0mwsV2TsKbd7fpg
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "" <>
Archived-At: <>
X-Mailman-Approved-At: Wed, 17 Jun 2015 08:25:31 -0700
X-Mailman-Version: 2.1.15
Precedence: list
Content-Type: multipart/mixed; boundary="===============8386657065933354256=="
Sender: "new-work" <>
Archived-At: <>
X-Mailman-Approved-At: Wed, 17 Jun 2015 09:01:42 -0700
Subject: Re: [secdir] [new-work] WG Review: Open Specification for Pretty Good Privacy (openpgp)
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jun 2015 15:25:33 -0000

It might sound like a real nit, but " An updated public-key fingerprint

OpenPGP fingerprints are created using message digests. And distributions
of the code inevitably involve fingerprints of code, not just keys.

Would prefer it just say "An updated fingerprint mechanism"

One of the things I have been working on recently involves fingerprints of
symmetric keys which I describe on the right key list. The approach is
powerful and I believe it is likely to be useful for a range of personal
pki apps.

The thing that has been a killer in the past is management of personal
private keys. The problem is getting worse as we have five platforms
instead of just one. In 1992 I only had a desktop. Now I have desktops,
laptops, tablets, phones and a watch. And only the last one of those is
singular. This is a problem that is clearly linked to OpenPGP and should be
served by any solution. But any solution has to support any application
requiring credential management.

On Mon, Jun 15, 2015 at 10:38 AM, The IESG <> wrote:

> A new IETF working group has been proposed in the Security Area. The IESG
> has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at by 2015-06-25.
> Open Specification for Pretty Good Privacy (openpgp)
> ------------------------------------------------
> Current Status: Proposed WG
> Chairs:
>   Daniel Gillmor <>
>   Christopher Liljenstolpe <>
> Assigned Area Director:
>   Stephen Farrell <>
> Mailing list
>   Address:
>   To Subscribe:
>   Archive:
> Charter:
> OpenPGP is an Internet standard that covers object encryption, object
> signing, and identity certification. These were defined by the first
> incarnation of the OpenPGP working group.
> The following is an excerpt from the charter of the original incarnation
> of the openpgp working group
> > The goal of the OpenPGP working group is to provide IETF standards for
> > the algorithms and formats of PGP processed objects as well as providing
> the MIME
> > framework for exchanging them via e-mail or other transport protocols.
> The working group concluded this work and was closed in March of 2008. In
> the intervening period, there has been a rough consensus reached that the
> RFC that defined the IETF openpgp standard, RFC4880, is in need of
> revision.
> This incarnation of the working group is chartered to primarily produce a
> revision of RFC4880 to address issues that have been identified by the
> community since the working group was originally closed.
> These revisions will include, but are not limited to:
> - Potential inclusion of elliptic curves recommended by the CFRG (see
> note below)
> - A symmetric encryption mechanism that offers modern message integrity
> protection (e.g. AEAD)
> - Revision of mandatory-to-implement algorithm selection and deprecation
> of weak algorithms
> - An updated public-key fingerprint mechanism
> The Working Group will perform the following work:
> - Revise RFC4880
> - Other work related to OpenPGP may be entertained by the working group
> as long as it does not interfere with the completion of the RFC4880
> revision. As the revision of RFC4880 is the primary goal of the working
> group, other work may be undertaken, so long as:
> 1. The work will not unduly delay the closure of the working group after
> the revision is finished (unless the working group is rechartered).
> 2. The work has widespread support in the working group.
> These additional work items may only be added with approval from the
> responsible Area Director or by re-chartering.
> Inclusion of CFRG Curves
> -----------------------------
> The Working Group will consider CFRG curves as possible Mandatory to
> Implement (MTI) based on the output of the CFRG and/or Working Group
> consensus in the matter.
> Working Group Process
> --------------------------
> The working group will endeavor to complete most if not all of its work
> online on the working group's mailing list. We expect that the
> requirement for face-to-face sessions at IETF meetings to be minimal.
> Furthermore, the working group will accept no ID's as working group items
> unless there is a review by at least two un-interested parties of the ID
> as part of the acceptance process.
> Milestones:
>   Sep 2015 - Working Group (rough) consensus on the necessary updates to
> RFC4880.
>   Feb 2016 - First wg-id for RFC4880bis
>   Jul 2016 - RFC4880bis wg-id final call
> _______________________________________________
> new-work mailing list
> _______________________________________________
> secdir mailing list
> wiki:
new-work mailing list