ietf-openpgp
[Top] [All Lists]

Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th

2015-04-06 17:45:01
On 2/04/2015 5:57 am, Stephen Farrell wrote:

So I think the volume and content of discussions over the
last few weeks clearly indicates a desire to do something
about openpgp, but that discussion doesn't seem to be closing
in on exactly what to do, in the IETF context. It'd help me
to try figure that out if folks would respond to this saying
which of the options below you think can make sense. Picking
more than one is fine, but if so, please say which you prefer.
Annotating/explaining your choice(s) is very welcome but
please try resist the temptation to change this into a chat
about a different set of options:-)

Sure ... why not break my silence with this.

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'm a long time user of PGP and GPG (about 20 years, I began with PGP
2.3a for DOS), co-founder of CryptoParty in Melbourne, privacy & civil
liberties campaigner, current Treasurer of Pirate Party Australia,
former Vice President of Linux Users of Victoria and professional geek
(former Sun Systems Engineer).  I've been training people with using
GPG specifically for several years across a variety of industries.
I've been lurking on this list for a while, a few years at least.

Anyway here's the options:

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.

Ah, nope, I believe there are some things to do to some extent.
Particularly in light of the legislation recently passed in my country
(see below).

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 think this is the most viable option at the moment.  We all know,
for example, that there are significant changes coming with ECC
becoming a viable option, so there are some things which could be
tightened at the same time.

I think the top of my list would have to be incorporating more of
what's usually classed as SMTP headers in the encrypted portion of a
(presumably PGP/MIME) message.  Ideally everything after the data
command is delivered to the SMTP server, but that might be pushing it
a bit (though mail from and rcpt to commands should be all said server
needs to do what it has to do).  Obviously the WGs dealing with SMTP
and probably POP3 and IMAP might have a thing or two to say about
that.

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

Maybe, there's no harm in questioning things, but the intended outcome
would need to be clear.

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 believe this is called starting a new WG to create and/or implement
some new thing.  While I've got nothing against that, there's a point
where you just have to say, "hey this is a new project, but we've been
inspired by what came before."

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.

Maybe.  Trust models always get a bit contentious because people
inevitably don't consider some obscure use case or policy set that is
not encountered often in their social or professional environs.  I'm
happy to have the discussion, but I suspect that a better approach
would be to step back and provide recommendations for end users or
communities to develop their own policies, but with a standardised
method of communicating those policies to others.

Option 1 is easy. The list can continue to debate stuff, but there's
no IETF process stuff needed and no new RFCs on the horizon. I get
off the hook:-)

Sorry dude, you're outta luck there.  ;)

For option 2, or 2t we could start crafting a charter on the list
once we've gotten agreement that that's the goal.  I don't think a
face-to-face BoF would be needed before forming a working group
unless the scope of the "t" part of 2t was proving hard to pin
down. (We could arrange some virtual audio meetings if that'd help
of course.) That could mean a working group is formed quite soon,
and that working group might choose to meet face-to-face in Prague
in July, or might prefer to work on the list only, or with some
audio meetings.

I'd be in the latter camp, primarily contributing via email where
possible, but this is Australia and in addition to the time difference
we've just had mandatory data retention foisted on us, so a lot more
of my energy is going to both political and technical solutions to
dealing with a country where we're all suspects.  Who'd've thought
we'd come half-way around the globe and struggle through two centuries
only to brand ourselves convicts again?  Incredible.

And lastly, please let's not have an IETF process discussion or a
discussion about why the IETF is great or crap. If we see that
there's IETF stuff folks want to do and if those folks are willing
and able to implement/deploy the results then that's enough to be
going on with.

If that happens I'll be sure to go play with my political party, there
are actual problems which need solving all over the place and I don't
have the time for kindergarden krap.


Regards,
Ben

-- 
Ben McGinnes  http://www.adversary.org/  Twitter: benmcginnes
    Writer, Systems Administrator, Trainer, ICT Consultant
Encrypted email preferred, primary OpenPGP/GPG key: 0x321E4E2373590E5D
OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D
OpenPGP/GPG key transition: http://www.adversary.org/keyswitch.txt.asc

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>