[openpgp] Option 4: Requirements vs. Solutions.
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 02 April 2015 18:26 UTC
Return-Path: <hallam@gmail.com>
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 048D81A0191 for <openpgp@ietfa.amsl.com>; Thu, 2 Apr 2015 11:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Level:
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 q5KkGUV7bf16 for <openpgp@ietfa.amsl.com>; Thu, 2 Apr 2015 11:26:31 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7292B1A0092 for <openpgp@ietf.org>; Thu, 2 Apr 2015 11:26:31 -0700 (PDT)
Received: by lbdc10 with SMTP id c10so65205040lbd.2 for <openpgp@ietf.org>; Thu, 02 Apr 2015 11:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=RpENStnYWAdVcw71izJERMqG3WNlY3F4aAV9dLbXNaU=; b=rBppcp3CtNZdIbAuQlmeTx3HAA43JfaEvAZPIJAlYm2mDq27Le0D9K5A1RiGuyyT/2 zBUlCnKMCWfgdEjXO/BctFbRiO5EE+qd1O4V6Dte40Z9TuASQnNy0wQo+uJ6UVg+bAex hOcZiJUHYALk26Ff0B0F9UgDNG6qPjiYJOhEryZ3ztYsv+mXAdWAB2G1FwVcdVKb/Ul+ LX/zEw/ubzPzkBLA4eEWJGMY9Za+ftXgJN6FUowgEDp0cU9c4Fw8SWofcwNRpetf+rfM /NyHfGb0rKIMtzgsVKuXURHtwFec/fM9NNLvZtaIG9UWW7JOWulQtEhZ0sG5V/Rqhydr QOdQ==
MIME-Version: 1.0
X-Received: by 10.152.18.225 with SMTP id z1mr42526528lad.124.1427999189786; Thu, 02 Apr 2015 11:26:29 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 11:26:29 -0700 (PDT)
Date: Thu, 02 Apr 2015 14:26:29 -0400
X-Google-Sender-Auth: 7PC6UCFcloXsCWMq5T1iWy_rnz8
Message-ID: <CAMm+Lwg2B=8+9qnDwbzGNJ8M5R9M2XMNhdyXT_24QZ-f+8jVfw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: ianG <iang@iang.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/g8NKkrPe2DyY-mfmpWw77TpE2XE>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: [openpgp] Option 4: Requirements vs. Solutions.
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: Thu, 02 Apr 2015 18:26:33 -0000
On Thu, Apr 2, 2015 at 1:55 PM, ianG <iang@iang.org> wrote: > On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote: > Storage has changed: we no longer consider a message over the wire as the > same thing as a message at rest on disk. We do/don't keep video chat, we > do/don't take naughty snaps using screen shots. We do/don't share huge > files (movies) for which OpenPGP is entirely unsuited because it assumes > everything is a datagram, and 16G datagrams aren't supported by any other > software. OK, so lets agree to a distinction here between requirements and solutions when it comes to scope. Contrary to what most folk accuse me of, I am very focused when it comes to solutions. Where I insist on a broad scope is when we consider requirements. So I don't want to work on design of a start from scratch messaging infrastructure in PGPvNext. However I do want PGPvNext to support the type of requirements that sort of work might anticipate. I find it really annoying when someone says 'there is no difference between options A and B, my friends and I prefer A so thats what we will do' and then when I point out that there are actually a lot of differences between the two because A can't support a large number of use cases that B does. Then they say "well those are not in scope". All requirements are always in scope as far as I am concerned. I might not be able to meet all of them. But having them on the table helps thinking about the problem at the right level of abstraction. So I don't want to do a protocol that combines push email (SMTP) with pull (e.g. dropbox) for a couple of years so certain patents expire (among other reasons). Or add real time video messaging, jabber etc. But I would like to make sure we don't foreclose the option. In particular I would like to see: * Convergence on JSON as the data model and JSON based encoding. * Data formats that handle very large chunks of data * Data formats that support real time streaming By large chunks of data, I mean Terabytes and up. If protocol convergence is achieved, I should be able to transfer the contents of my RAID-6 NAS with 4x6Tb drives by emailing them to its successor. I don't propose that we design such a protocol now. Unless you are living in one of the six houses served by the Google 100Gbs Ethernet you are going to be waiting a long time for ten Tb to move. But I do know folk at CERN who already have that size of problem and it won't be long before it does become relevant. > Evidence has changed: we do/don't keep transcripts around for evidence. We > do/don't think of digsigs as human signatures. We do/don't worry about > removal of files. We do/don't consider the wire to be a threat and we > do/don't consider our counterparty to be a threat. Looking at the current state of the art for collecting and maintaining digital evidence, I am appalled. The requirements for criminal cases are poor and the requirements for civil are practically non existent.
- [openpgp] Option 4: Requirements vs. Solutions. Phillip Hallam-Baker
- Re: [openpgp] Option 4: Requirements vs. Solution… ianG