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 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. 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
