Actually, one other thing. While I agree with you on the thin clients issue, many of our applications use their own PC's to run our application (they have other applications they use on their PC besides ours)
On Fri, Jan 30, 2009 at 12:24 PM, Denis McCarthy <dmccar...@annadaletech.com> wrote: > Hi Anders, > Good question. > >> If the computers OTOH are just ordinary but shared office computers, >> critical data should be server-based and protected by user access control. >> Thin clients is the most common solution to this fairly standard >> problem. Then it would be X.509 per user rather. >> > I think this gets to the nub of the point at issue. Our customers > often have several stores. We do not want our X509 certificates to be > 'per user' because what is critical for us is in which *store* the > transaction was executed in (what user performed the transaction is of > secondary importance - we want to ensure the user is authenticated > (which we do with usernames and passwords), but the store information > is paramount). If the customer uses windows roaming profiles for their > users (which many of the larger ones do) the problem with using > standard 'per user' X509 certificates is that, regardless of whether > the user logs in to a PC in store A, B or C, the X509 certificate in > their profile (which is stored centrally as part of the users' roaming > profile) remains the same. Therefore we would be unable to identify at > what store the user had processed a transaction unless we asked the > customer explicitly. As discussed previously, we are also > investigating hardware based tokens for this purpose, but if only we > could get access to the machine based certificate store in windows > from IE and/or firefox this would solve our problem. I do understand > of course that this is not what X509 certificates were designed for, > but I think what we wish to do with them is sensible, and worth > investigating > > Hopefully this explains the issue I have. > Regards > Denis > > > > On Fri, Jan 30, 2009 at 10:34 AM, Anders Rundgren > <anders.rundg...@telia.com> wrote: >> I guess what's puzzling some people like me, is what the security >> concept behind this arrangement really brings to the table. >> Authenticating machines connecting to the network is indeed useful >> but in general only has the function to prove that the device has been >> accepted and possibly configured by IT (AV etc.) >> >> I hope you don't mind me generalizing the discussion a bit: >> >> If the machines in question have entirely different function and thus >> need specific users. This could for example be X-ray equipment >> that only should be used by authorized and trained personnel. >> This still seems to point to user authentication. >> >> If the computers OTOH are just ordinary but shared office computers, >> critical data should be server-based and protected by user access control. >> Thin clients is the most common solution to this fairly standard >> problem. Then it would be X.509 per user rather. >> >> As nothing is more secure than its weakest link, using passwords >> for getting machine access (and thus being authenticated in the >> sense that this concept expects...), doesn't appear like an ideal >> solution. That the concept does not build on AD access, makes >> me believe that this idea needs a revision or two because administration >> is a core element of all security solutions and here we obviously have >> a lot of stuff to administer. >> >> Also the word "federation" rings in my ear. >> >> Anders Rundgren >> >> -- >> dev-tech-crypto mailing list >> dev-tech-crypto@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-crypto >> > > > > -- > Annadale Technologies Limited > -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
