ietf-openpgp
[Top] [All Lists]

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

2015-04-01 13:58:08

Hi all,

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:-)

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.

Please try respond to this if you can before Wed April 8th
and I'll try summarise whatever we get back to the list after
that, and we may or may not have a plan of action at that
point - we'll see I guess.

And pretty please do change the message subject if you want
to follow up and discuss something from someone else's response.
That'll at least make my life a little easier when it comes
to trying to summarise back to the list but it'll also make it
easier for folks to check if I've mucked up in how I summarise
(and I muck up a lot, sadly:-).

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.

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)

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

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

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

So that's for choices. Remember it's ok to pick more than
one with which you could live, but please be clear about
which you prefer.

I'd also like to talk about how we might process some of
the above if we establish rough consensus for one of 'em.

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:-)

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.

For options 3, 3t, 4 or 4t I do think we'd likely need to
have a face-to-face BoF meeting as there'd be a lot to
consider and pin down and higher bandwidth is much better
for that. In that case, the important date is June 5th
which is the next cutoff date for requesting such a meeting
for the Prague IETF to be held July 19-24. [1] (June 5th
might seem like a long way off, but it's not really so if
we needed such a meeting then starting to work towards that
soon would be much better than doing so late.)

Also, some of this can be done sequentially. For example,
as an area director I'm very happy re-chartering existing
working groups to add more tasks where those groups have
demonstrated the ability to be productive. In my experience
that can work better than starting out with the hard/ambitious
stuff as the very first thing to do. That might argue for
starting with option 2 and then, if all goes well, discussing
whether or how to tackle option 3 or 4. (We could even charter
a group to do the maintenance work for option 2 and when that's
done to then discuss how to re-charter for one of the more
complicated choices.) I'd suggest however, we ignore such
sequential processing for now, see what folks prefer as a
goal, and then think about whether there's a way to get to
what people want via sequencing things cleverly. So, just
for now, please don't suggest "2, followed by 3" even if
that's something you like the sound of - I think folks'
initial responses will probably make it obvious if we need
a chat about that.

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.

Thanks,
S.

[1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93





_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp