At the moment I have * An Internet draft for expressing security policy in the form of DNS statements. * A draft of a white paper describing a general solution framework. * Some proprietary protocols that implement the client-broker interface * An aspiration to write a notary protocol ID.
I guess the sensible thing to do is probably to focus on getting out drafts for the security policy origination and the client-broker interface. On Wed, Feb 8, 2012 at 11:05 PM, Stephen Farrell <[email protected]> wrote: > > Hi Phill, > > > On 02/09/2012 03:40 AM, Phillip Hallam-Baker wrote: >> >> I think we have a set of requirements that point to a need for three >> separable technologies: >> >> 1) A means by which a site can express the intended security policy >> 2) An append only notary service >> 3) A means by which a client can obtain security policy curated by a >> fourth party >> >> Each of these components can be designed in stovepipe fashion to only >> serve one set of requirements or they can be conceived in slightly >> more general form. >> >> For example, Convergence, SK and CT all involve some form of append >> only notary. Such a facility would have far more general applicability >> than just addressing public keys. It might well be easier to get a >> broad range of parties establishing and supporting the necessary >> ecology of notary service providers if they are designed in such a >> fashion that they can be used for general purposes. >> >> >> So I will make separate protocol proposals in each area, but > > > Great. That's what's needed for progress to be made here. Send > the I-D URLs here as soon as you can! > > More opinions on your categorisation and its utility would also > be good, (e.g. it clearly doesn't try to address the secure-mail-from- > all-to-all problem, right?). > > >> I think >> what we are designing is going to be easier to deploy if we give some >> thought to re-usability of components and dual use. > > > Well... that assumes that there are folks out there who want to > re-use stuff. To some extent this space, for now, seems to be > a bit more solipsistic. Maybe the people proposing to solve all > problems aren't quite as confident as they claim? (...he said > deliberately, but honestly, trying to provoke people out of > silence:-) > > S. > > PS: I do appreciate your being constructive on this. > > >> >> >> On Wed, Feb 8, 2012 at 9:11 PM, Stephen Farrell >> <[email protected]> wrote: >>> >>> >>> <trying to poke things along a bit more actively hat on> >>> >>> So S/MIME works fine in many cases but does not work well >>> between random people connected to the Internet, unlike email. >>> That's a pity. >>> >>> Its not an easy problem though, XMPP have been trying for a >>> good while and we don't even seem to have a good solution for >>> SIP or Diameter which ought be much easier. >>> >>> I guess if this discussion lead to a way to manage keys that >>> could work at the same scale as email that would be a major >>> advance. I don't expect that myself. >>> >>> And of course, whatever the right answer there (if there >>> is one) is maybe very different from how we might manage keys >>> for web servers or MTAs or XMPP servers. >>> >>> Maybe we ought also think about whether or not the same key >>> management scheme is right for all those or not as part of >>> this too and whether we're able to solve all or just some/one >>> of those problems. >>> >>> Put another way: maybe it'd be better to tighten the focus >>> a teeny bit more on this list. Specific suggestions for topics >>> welcome. Why not start a new thread with your favourite >>> problem that's worth solving and maybe solveable. (Being the >>> IETF, we're not very interested in other things in the end:-) >>> >>> S. >>> >>> PS: I bet I'm not the only one who can no longer associate >>> the subject line with the content. Be good to be better at >>> that since it'll help to try move towards some concrete >>> outcomes here. >>> >>> On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >>>> >>>> >>>> Alice has three mobile phones and six laptops. >>>> >>>> Using embedded keys in those devices for authorization is no problem >>>> since each device can have a separate private key and the >>>> authentication server tracks the fact that there are nine devices that >>>> might authenticate Alice. >>>> >>>> The same model can even be made to work for confidentiality. Alice can >>>> read her DRM protected Kindle content on any one of those devices. >>>> (Though there may be limits on how many devices the DRM scheme will >>>> permit). >>>> >>>> >>>> Trying to make S/MIME email work in that scenario is futile. The >>>> sender only tracks one private key for Alice. So Alice has to export >>>> her private key to all her S/MIME clients. Not only is that terrible >>>> security practice, it is too much work. Worse, Alice has to repeat the >>>> process once a year. >>>> >>>> That is why I no longer believe that end-to-end is a desirable >>>> quality. A security requirement that does not consider the cost it >>>> imposes versus the risks it mitigates is ideology. >>>> >>>> >>>> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent<[email protected]> wrote: >>>>> >>>>> >>>>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>>>> >>>>>> >>>>>> >>>>>> But authentication works in that scenario because the protocols can >>>>>> allow >>>>>> each user to have as many keys as they need. The key is not shared >>>>>> across >>>>>> devices, the protocols allow for multiple cards per end user >>>>>> >>>>> Sorry, I don't understand you comment. >>>>> >>>>> Steve >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> therightkey mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/therightkey >> >> >> >> > -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
