On Wed, Apr 1, 2015 at 2:57 PM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
It would also really help me (and I suspect others) evaluate
messages if you could say something about how you fit into
the openpgp universe (e.g. "I wrote the foo implementation"
or "I run a thing with N people using pgp" or whatever). An
essay on that is not useful here, but a line or two could
be really good.
I have written code that makes S/MIME easy to use by taking concepts
from the PGP world. I am planing to extend the same approach to PGP.
In particular, my scheme is designed to provide frictionless security
so that the user does not need to do anything differently unless we
are making something easier to do.
I am also looking at trust models that combine ideas from S/MIME, PGP
and TRANS. But that is not an immediate focus.
option 1: do nothing - there's nothing much to do or at least
not in the IETF or not within the IETF for the next >6 months.
I think it is clear that there is important work to be done.
option 2: do maintenance work on rfc4880 - produce a 4880bis
with better crypto options at least, and debate any further
detailed changes during chartering - the charter will contain
a list of specific things to do and other things will be out
of scope (for now)
I would support this. Cleaning up the legacy OpenPGP specs would be a
help even if it didn't go further. It is not my preferred option.
I think it is also important to decide in advance what our end
objective is going to be. We are going to approach this very
differently if we have given up hope of getting a single message
format.
option 3: do a major revision to openpgp - take rfc4880 as a
starting point but question all design decisions in the process
of developing a successor version of openpgp and write a
charter that allows for all such design decisions to be
questioned
I support this but the scope has to be manageable and to understand
what is 'manageable' we need more information on the existing
implementations.
In particular, I would like to achieve a clean break between the
message format layer and the trust model layer and tackle those
independently. Quite possibly in separate IETF and IRTF tracks.
If you give me the fingerprint of Alice's key and some way to resolve
that to a public key and her email security preferences, encrypting
the message is straightforward. I would like the IETF to come to a
single answer to that problem, though just as we have JPG and PNG and
GIF in the Web, it need not be a single format.
The question of how Bob finds Alice's fingerprint and what confidence
he can have in the answer is something that I think needs research.
PKIX and PGP are both early essays in the craft. We have 20 years of
operational experience and some important IPR is no longer encumbered.
option 4: move beyond openpgp (or smime) to develop a new
flavour of end-to-end security for interpersonal messaging,
possibly not that tightly coupled to email, but at least
supporting an email flavour
I do not support this at this time.
The reason I chose to start with email is that it is the hardest, most
constrained problem. If we can solve that problem we can apply the
same approach to everything else. The only problem that is as hard as
email is code signing and that is hard for the same reason - because
it is an asynchronous problem.
It is an important and inevitable piece of work which is why I care
about getting issues such as efficient JSON encoding right. But I
don't want to open the subject up until we have SPUD, efficient JSON
and the trust model sorted. And this is not a project I would want to
do in the security area, it would need the WebRTC type folk and the
messaging folk.
The only near term consequence of the expectation that we will
eventually do this work for me would be that I am much more open to
re-working existing data structures in JSON than I would be otherwise.
If we do eventually re-do the whole application layer then it should
have a consistent encoding from top to bottom with as few exceptions
as possible.
For options 2-4 one could include more or less work related
to trust models or key hierarchies/key distribution. If you
would like to include that kind of work please pick one of
those below. If pursuing any of these, we'd need a separate
discussion about the scope of that work and whether or not
one specific approach ought be standardised, but please
let's not yet have that discussion until we see that one of
the "t" options below has a good bit of support.
option 2t: option 2 + add some trust model/key management
option 3t: option 3 + add some trust model/key management
option 4t: option 4 + add some trust model/key management
My preferences are
Option 3t [With the T part in IRTF]
Option 3
Option 2
I do not want to do Option 2t or option 4.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp