Subject: [openpgp] Option 4: Requirements vs. Solutions.

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Apr 2015 14:26:29 -0400

On Thu, Apr 2, 2015 at 1:55 PM, ianG <[email-masked]> 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.

---

From: ianG <[email-masked]>
Date: Thu, 02 Apr 2015 19:40:53 +0100

> comes to solutions. Where I insist on a broad scope is when we

With you all the way.

> thinking about the problem at the right level of abstraction.

+11

> my RAID-6 NAS with 4x6Tb drives by emailing them to its successor.

That's great as a requirement.  I agree.  We need more like that.

Now, may I make a humble suggestion as to process.  How about you open 
up a google docs entitled "PGPvNext Requirements" and c&p the above 
paras under a heading "Data Formats".

Then, make the google docs open edit.  (Contrary to our historical 
claims, not everything we do is under attack by all of humanity all at 
the same time ... I've found that having an open-edit google docs does 
work and nobody seems to go in and muck around.  And if they do, well, 
we can man-up and find another solution...)

Or, I'm entirely open to any other solution eg github as long as it is 
widely accessible to everyone without requiring excessive enrollment 
(h/t to Derek).  Does IETF have a favoured way of collaborating like a wiki?

> be long before it does become relevant.

Sure.  Design it for the Petabyte.  One day it will be needed.

> are poor and the requirements for civil are practically non existent.

(offtopic) if it's a serious problem for you, you might want to talk to 
my friend Stephen who wrote the book on digital evidence.  Contact me if 
you need an intro.  http://www.stephenmason.eu/?page_id=10

iang