Hello Ian, Thanks for your reply. I don't think I expressed myself too well in my first post. My main problem is with some of our larger customers, and the way I believe X509 certificates work. FYI, we are acting as our own CA (as we need to trust the client, not the other way round), and we do put data into the CN to identify a PC (e.g. 'terminal 56').Maybe an example will illustrate my problem a bit better:
Say we have a contract with Company X for them to use our service, via a web browser. Now, Company X transacts its business in 4 different locations (locations A, B, C and D). In each location it has 3 PCs (PC's A.1, A.2 A.3, B.1 etc.). Each of these PCs will carry our service. Company X has a 20 staff. Each staff member has their own profile on Company X's windows network. These staff roam, i.e., staff can be asked to work in any of stores A, B, C, or D, and also on any PC in these stores. To cater for this, Company X has standard centrally stored windows profiles for each employee. When they come to work in the morning, they log in to the PC on which they are working at for that day. When they do this their centrally stored profile data (including imported browser certificates as I understand it) is downloaded for use on the PC. When they log in to our system via the browser, they enter their username and password, and we take a look at the CN in the supplied X509 certificate to see what terminal the user is logging in at (to ensure the user is part of that organisation, and that the terminal itself is valid) The problem is the following: Say John Doe works for Company X. As I understand, John Doe will need an authorized X509 certificate installed under his own windows profile in order to allow his browser to connect to our site. Say he works in Location A Monday, and Location B Tueday. As Company X is using roaming profiles, the X509 certificate will 'follow him around' as he logs in to different PC's meaning that we will be unable to use the certificate to identify on what PC the user had been transaction (meaning that we will have settlement issues for the monies flowing as a result of the transactions this user has processed). I hope this better illustrates our current conundrum. As I said, any ideas about how we might crack this would be really appreciated. Regards Denis On Thu, Jan 29, 2009 at 10:10 AM, Ian G <i...@iang.org> wrote: > On 29/1/09 10:42, Denis McCarthy wrote: > >> a) Is there some way to set up a PC so that X509 certificate is per >> machine as opposed to per-user (I don't think you can as X509 is very >> much user based) > > > At some base level, X.509 is just a lump of data, and really doesn't mind > what you do with it. It is entirely possible to replace the CN field with > "Example Corp's 3rd PC on the right, 4th floor, Building X". Indeed, this > is what is done with webservers, where the name is set somehow to > www.example.com. > > What dictates that which goes in the strings is policy. This would > generally be the CPS. > > Therefore, you need to find a CA that has a CPS that has a way to put in > "machine identifiers". Or you simply run your own CA to do this. > > An alternate way to approach this is to consider who the person is. Well, > the person is the legal person, being the owner of the machine. Example Corp > above has many machines and it has certs for each of them. So even if we > want to be strict about the "person" aspect, we can be. > > Indeed, the whole business is built on selling certificates to legal persons > for machines called webservers, so a few extra PCs are no problem :) Maybe > all you need to do is use the domain naming feature, and extend it like: > 3rd.right.4thfloor.BuildingX.example.com Most CAs can deal with those > sorts of server certs (although check the usage bits that server certs come > with). > > >> d) Are we approaching this in the wrong way entirely (i.e., is there a >> simpler alternative to allow us to achieve what we need to achieve)? >> >> The security of the certificates is important, and they need to be >> password protected. > > > Um. What does this mean in a *machine* setting? Each machine can easily > remember the password, and you can put it in the file next to where you > store private key. However, this has the slight disadvantage that ... the > password is too close to the key and is thus no protection at all. > > Alternatively, you come back to a human or an external token or a postit > note on the machine or the wall. To answer that, I think more details about > the application are required, or the business. E.g., if the machines are > laptops and can be reasonably expected to retain power, then the > administrator can unlock the certificate into some memory store, and then > hand it over to the user. No password required. > > > > iang > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
