Credential equivalence is not for every application. In particular there are cases where you want a user to have exactly one physical credential and that is a part of the security scheme.
But I still think that the rule of 'private keys never move outside the device once they are in' is a good one and one we could stick to.There are some use cases for which generating the keys on the device is not practical but I still think a different key per device and no movement of the key from one device to another is a good plan. So in this approach Alice would have Alice S/MIME private key corresponding to public key in cert (located at server) Alice 1 (desktop) Alice 2 (cell phone) ... Alice n (whatev) If Alice is going to read an encrypted email on a given device it asks the server to decrypt the session key and reencrypt it under the device key. Now people can say this is not true end to end, but have we really increased the number of possible points of vulnerability? So the server can be compromised, but so what? The endpoint can be compromised much more easily. On Thu, Feb 16, 2012 at 6:11 PM, Stephen Kent <[email protected]> wrote: > At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote: >> >> On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent <[email protected]> wrote: >>> >>> So, I don't agree that the distinction between the user and a machine >>> operated by a user is really significant, in the end. (Yes, I am ware of >>> the many security problems that arise because the user doesn't really >>> know >>> what the code is doing, but nothing is perfect.) >> >> >> I believe that there's a very good reason to separate them. We're going >> to need to move to a system where we have effectively a separate UID per >> application, within the overarching user's UID. This is the only effective >> way to isolate the damage which one application can cause, and the only >> effective way to audit precisely which application did what damage. > > > I appreciate the potential benefit for per-app IDs vs. user/machine IDs, but > given the sorry state of OS secruity, it's not clear that a per-app ID is > really meaningful. > > >> This is a recasting of Android's model, where the "user ID" is "the >> device's controller", and the applications themselves are assigned Linux >> UIDs so they can't interfere with each other. >> >>> I agree that credential portability is essential. [...] >> >> >> Credential portability is overrated. The real problem is credential >> equivalence. > > > PHB pointed out why credential portability is critical for encrypted e-mail. > For many other apps, it is not so critical. I am not sure that equivalence > is a good alternative, as mapping among multiple credentials creates an > opportunity for additional secruity problems. > > >> >>>> S/MIME with a private key shared to fifteen devices no longer looks >>>> very secure to me. >> >> >> S/MIME with a private key stored on a daemon system and unique private >> keys on each of fourteen accessing clients, on the other hand... > > > is not e-2-e secure and this less desirable. > > >> >>> Crednetial portability does not necessarily imply a private key kept in >>> SW >>> in every device. >> >> >> Credential portability does, however, imply a private key or other >> authenticator must be handled in SW in every device. Intermittent security >> is harder than complete security in a sufficiently complex system. > > > not true. many folks carry devices that could be used to store private keys > that are used briefly, to unwrap keys. > > Steve -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
