[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[openpgp] Option 4: Requirements vs. Solutions.



On Thu, Apr 2, 2015 at 1:55 PM, ianG <iang@xxxxxxxx> 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 mailing list
openpgp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/openpgp