Re: [openpgp] Proposed WG charter

On 2/06/2015 08:18 am, Simon Josefsson wrote:
> Den Mon, 1 Jun 2015 13:03:56 -0700
>
> > On Jun 1, 2015 12:41 PM, "Simon Josefsson" <simon(_at_)josefsson(_dot_)org>
> > wrote:
> > > > > BTW, why do you and some others use the term MTI?  That term
> > > > > seems to mean mandatory-to-implement and comes from Jabber, to
> > > > > me this sounds very much like MUST (cf. RFC-2119).
> > > > The term MTI (Mandatory to Implement) is used to differentiate it
> > > > from MTU (Mandatory to Use).  I.e., an MTI algorithm is one that
> > > > you're guaranteed to be ABLE to use, but there is no requirement
> > > > that you actually DO use it.
> > > I think there is also a possible orthogonal Mandatory to Deploy so
> > > you would have:
> > >
> > > MTI: Code needs to be written
> > >
> > > MTD: Code that was written need to be enabled in deployment
> > >
> > > MTU: Code that was written actually need to be used
> > >
> > > The distinction between the two latter is when a protocol has
> > > several MTD algorithms, which is the typical case.

Interesting, thanks for the explanation!

The thing that I would see as being different from MUST and the above 
three MTx is that the latter (Jabber?) has thought about how to deploy 
changes.  It would seem to imply there is someone somewhere pulling the 
strings on the puppet to make the migration happen.  There is a 
foundation behind Jabber, maybe that's the puppetmaster.
This is something that IETF has shied away from, and OpenPGP is perhaps 
a leading proponent of not having any institutional push on the choice 
of crypto.
I think the reality of OpenPGP's lifecycle is that we are going to be 
dealing with legacy implementations and algorithms anyway, and just 
specifying MUST(s) will probably be sufficient.  The challenge is to 
really get that list down below 3.  Beyond that, distinctions such as 
MTI and MTD are going to be seen as legacy deployment.
tl;dr - I suspect we can stick to MUST rather than MTx.


> > But I don't want to expose this choice to users, any more then
> > signing and encryption ordering. There are real usability and
> > deployment issues that need to get solved, that require changes to
> > what is going on behind the scenes.

I'm with you!

> Users aren't involved in the two first parts.  Users are involved in
> the MTU step since ultimately they own the authority to chose their
> preferred algorithm -- assuming the protocol allows more than one
> choice, of course.  How they are involved, i.e., whether
> implementations expose the choices or not, is an UX issue.  Certainly
> there are challenges there, but I don't see the IETF has a lot to
> contribute around UX.

Which is a cop out.  Users are not typically capable of making that 
choice, and in the making of that choice, they cause network problems 
for everyone.  Obviously we can give them that choice and wrap it up in 
some form of crypto-freedom argument, but we can also give them a 
pencil, paper and a one time pad.  The purpose of the system is to 
deliver security, not crypto-purity, and everything we know about 
security points to the protocol author making the crypto decisions for them.
(But this is an old debate, everyone knows it, and the charter on the 
ground is moving OpenPGP forward, not recasting it entirely.)


iang

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