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
