From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com>
CC: "openpgp@ietf.org" <openpgp@ietf.org>
Thread-Topic: [FORGED] Re: [openpgp] Expiration impending:
 <draft-ietf-openpgp-rfc4880bis-01.txt>
Thread-Index: AQHS8sWFHqU4dlQfBk+AeHmoJilhxqJAOpqAgAAruwCAAU95AIAAANWAgAABvwCAAAGrAIAAAZCAgAFS0DP//3FRAIAA5ATV
Date: Tue, 4 Jul 2017 09:06:09 +0000
Message-ID: <1499159166033.35059@cs.auckland.ac.nz>
References: <149847732613.7086.8580563657011849337.idtracker@ietfa.amsl.com>
 <CALaySJKxWevOZYv1hOBFV-+3T=2x43vmie50t6ko2A+a-gTS_A@mail.gmail.com>
 <a3a82aab-a0d9-f044-21c0-26de346bf6b3@sixdemonbag.org>
 <20170702232541.t25v6mf36qnrxkex@genre.crustytoothpaste.net>
 <1b5da7bf-d43b-fde5-f6b6-28d9c6fd6edb@gmx.net>
 <94a05934-4b5c-4fb6-d127-beb0eacb47cf@sixdemonbag.org>
 <679411c5b2de4c308cbfbb3733c4fe54@usma1ex-dag1mb1.msg.corp.akamai.com>
 <9fbed93a-e4a7-3d00-1c53-ee587c2dface@o.banes.ch>
 <c51c709613184522815fa8838897dd2b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1499140902730.13818@cs.auckland.ac.nz>,
 <f1b3c9e5-ec8c-d4c2-2ccd-31fa65396440@sumptuouscapital.com>
In-Reply-To: <f1b3c9e5-ec8c-d4c2-2ccd-31fa65396440@sumptuouscapital.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/5_vV-iKMBWOQapqmUXM240Eo7FM>
Subject: Re: [openpgp] [FORGED] Re: Expiration impending:
 <draft-ietf-openpgp-rfc4880bis-01.txt>
Precedence: list

Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com> writes:=
=0A=
=0A=
>The most common complaint I'm hearing about OpenPGP is that it is too=0A=
>complex, as such I'm beginning to change my mind as to whether protocol=0A=
>agility is only a good thing, maybe we should work more on getting to=0A=
>consensus and reduce implementation complexity in order to make it possibl=
e=0A=
>for better auditing of implementations etc.=0A=
=0A=
The easiest way to do that would be through a profile of 4880.  So instead =
of=0A=
opening up giant can of worms and trying to redo 4880 itself, where everyon=
e=0A=
will want their own favourite change applied, publish a profile of 4880 wit=
h a=0A=
standard feature set for file encryption, email encryption, signed data, an=
d=0A=
maybe one or two other things.  =0A=
=0A=
For example for file encryption you might have MUST AES, MUST MDC, MUST=0A=
Iterated and Salted S2K (why do the other options even exist?), MUST either=
=0A=
five-octet or partial lengths... I think that's about it.  Then you can do =
PGP=0A=
file encryption in a pretty minimal amount of code rather than having to=0A=
include an entire protocol suite to deal with every obscure option in the=
=0A=
spec.=0A=
=0A=
The profile option, rather than rewrite-the-RFC, is fully compatible with=
=0A=
existing implementations while allowing us to move forward on best-practice=
=0A=
mechanisms and ciphers and, above all, simplify implementation and testing.=
=0A=
=0A=
Peter.=