On Thu, Sep 13, 2012 at 6:47 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote: > <snip> > I see the following approaches as possible: > > 1) Do nothing > > Ignore the issue completely, let parties work around the infrastructure as > deployed without making allowance for the requirement. > > 2) Attempt to disrupt > > Attempt to design the protocol so that the intercept requirement cannot be > met in any circumstance. This is actually the traditional IETF approach. > The risk here is that people create their own work arounds and loopholes > and then demand that infrastructure supports it and the systems that result > do not provide for informed consent. > > 3) Provide a comprehensive mechanism that is conditioned on informed > consent. > > If we decide that preventing intercept is possible the next best outcome > is to enable intercept but only with informed consent. > > > If we want to support that particular use case we have to have the client > delegate its whole process of trust evaluation to the accepted interceptor > and at minimum constantly inform the user that this has occurred. We may > also decide that we want to inform the service that the user is connecting > to that an intercept has occurred. > > 100% agreement that we must pick one of these. -=R
Received on Friday, 14 September 2012 02:08:36 UTC