Re: [openpgp] How to re-launch the OpenPGP WG

ianG <iang@iang.org> Tue, 24 March 2015 01:48 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27781B2B3C for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 18:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 aJhjrU6u8U67 for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 18:48:32 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837A91B2B35 for <openpgp@ietf.org>; Mon, 23 Mar 2015 18:48:32 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2745D6D744; Mon, 23 Mar 2015 21:48:31 -0400 (EDT)
Message-ID: <5510C26E.7070409@iang.org>
Date: Tue, 24 Mar 2015 01:48:30 +0000
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <878uf2iehi.fsf@vigenere.g10code.de>
In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/0NbHP756yu0ewcC01xICW46PK1g>
Subject: Re: [openpgp] How to re-launch the OpenPGP WG
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 24 Mar 2015 01:48:34 -0000

Late comments!


On 12/03/2015 12:31 pm, Werner Koch wrote:
> Hi,
>
> Since some time the OpenPGP protocol is again en vogue and the tendency
> to prefer S/MIME over OpenPGP is not as strong as it seems to have been
> once.  Case in point, the DANE WG has a last call for an OpenPGP DNS
> record type.  This is obviously related to OpenPGP and should have been
> discussed here as well (actually we did briefly in Summer 2013).
>
> There are several tasks the WG should do:
>
>   - New signature subpackets.  For example one to specify a fingerprint
>     and not just the keyid.
>
>   - Take care of individual I-Ds.
>
>   - The use of SHA-1 needs to be replaced.

SHA3.

>   - A v5 key format.  Prepare for forthcoming public key algorithms.


Completely.

>   - A new encryption mode to replace our aging CFB+SHA1 method with a
>     fast and standard mode.


Wait for CAESAR, 2017.  It'll take that long anyway.


>   - Maybe extend it to key distribution.
>
> Is there any interest in this?


I'm theoretically interested.  But I think it is time to try another 
paradigm.

4880 took a decade.  Too long, the OODA loop was bigger than the 
evolving knowledge, the work-by-committee approach was broken.  Many of 
us died, emotionally.

I'd say:

   * designate key persons to design the elements.  Stick with what they 
choose.  Argue it a bit, but if we can't shift them, then go with it.

   * Less.  Algs, hashes, formats, protocols, bit saving, etc.

   * More.  We need to look up into the stack of apps and see what is 
needed.  Those apps didn't exist when PGP was designed.  We are in a new 
world now.  No point in designing for command line.

   * Trust <cof> model.  It's got to be completely overhauled.  Not so 
much as to change the internals, but to make sure that future uses can 
be composed with the new design.

   * Vendors.  Ain't nothing gonna happen unless you get them on side. 
By them, I mean the big ones.

   * project planning.  Let's not treat this as a committee, let's set 
up some coding projects to actually move the game forward.  Like, a C 
team, a Java team, PHP, what else?  Mandate:  to track the draft, 
compat, and push for more speed from the designers.


> How can we get the WG out of the concluded state?

As long as they don't turn off the list, do we care? ;-)

> Would the Dallas meeting be a starting point for this?
> Who would volunteer as Chair?


Hell's bells, no, can't afford it.



iang