Hi Martin: On Thursday 23 November 2006 16:46, Martín Coco wrote: > Hi, > > We're in the process of designing a PKI infrastracture for our company, > and I have a couple of design questions about it. I know this is an > OpenSSL mailing list, but it seems a right place to discuss this. If > it's not, I'll appreciate if you can hand me some links to a more proper > place. > > I've been reading the man for OpenSSL, this mailing list, and also > acquired the book "Planning for PKI". > > My main goal is to design a PKI for our server infrastructure (ldaps, > https, mail, vpn, etc.) The problem is that, for example, when reading > the mentioned book, all the examples are based on people, but not on
Ok - when you are designing the infrastructure, the question to ask is what are you putting in place strong authentication for? The reason that the books tend to focus on people, is that the usual business problem that companies have is identifying an individual via a strong mechanism. This means that they want the credential tied strongly to the individual. So, they write their Certificate Policy to indicate what hoops people have to go through to get a certificate. This means that and when a user presents this certificate, either to another user, or to a service such as a portal, or use it to set up a VPN, then it is possible to say with a high level of certainty, that it really is that user that is signing that document, accessing that portal, or establishing the VPN. The same is principle is true of servers - so when you are issuing certificates to servers, it is because you don't trust that your DNS records cannot be corrupted (for instance), and so you need another mechanism so that users know that it is really a given server that they are accessing. I personally have never seen a structure that was broken down by type. I have seen structures that were broken down by country (since jurisdictions have different rules for how PKI works), by assurance level (so, a High assurance level had a CA and repository that were in a cage guarded by guys with guns etc., and a rudimentary level had a CA that was shoved under someone's desk). I have also seen them broken down by "partner facing" - i.e. this CA is going to be cross certified with someone else, and "internal only". Usually, the best advice we give clients is keep the numbers of CA down to the absolute minimum that will satisfy your legal and audit requirements. So, if you have a single assurance level, a single jurisdiction, and a single customer base, then probably a root and a single subordinate could do. However, it will all depend on the legal, jurisdictional, and security environment in which you are operating. <snip> > Also, if a person connecting to one of these servers were to > authenticate it, it should have the subCA's certificate and the root CA > certificate to validate the certification path, right? That would mean > that every person should have a certificate for each subCA or service > they want to check, and the root CA. Is this correct? > Actually, since the Root CA is your ultimate "Trust Anchor", it is probably sufficient for users and servers to have that trust anchor in their trusted path. > How does all this sound to you? Whenever I try to look for examples, all > I find is based on people, or very specific examples. > > I'll appreciate any comments on this. > > Thanks, > Martín. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] -- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
