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

[Derek Atkins <[e-mail]>]

Hi,

I realize you've already summed up your responses, but I want to respond
for the record too.  (Yes, I realize it's been 9 days since you sent
this, so I missed your "please try to answer by the 8th" request).

In terms of the options, I think option 2 is best and closest matches
what can realistically be done.  Some others might want 3 or 4.  I doubt
anyone wants 1.

I think we should not do any of the 't' options -- I think 2440 and 4880
got it right by only specifying how to make signatures but not what they
mean.  I.e., it doesn't even define the 'web of trust'.  Now, I do think
it would be reasonable to have *separate* documents that explain, e.g.,
how to do web-of-trust in OpenPGP, how to do CA assertions in OpenPGP,
etc.  Indeed, I'd probably even be willing to author a draft on how to
specify and implement "name constraints" in OpenPGP using assertion
signature notifications.

-derek

Stephen Farrell <[e-mail]> writes:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
>
>

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant