Hi there; On Monday 24 March 2008 12:24:40 Cabz.List wrote: > Morning, > > I am experiencing some PKI comprehension issues: > > 1) When one talks about creating the "Trusted Root CA" is this different > from the "Signing CA"? > a. The Trusted Root CA's private key is hidden away from the world > (not on an internet accessible disk) > b. The signing CA does all the "real work"? By this I mean, is the > "Signing CA" now used to sign client certs, and other servers certs such > as SMTP, HTTP, RADIUS, SSL-VPN solution, etc.? Basically the Trusted > Root CA, has intermediary CAs do all the work? > c. Am I looking at a forest and planting an unnecessary trees? By > this I mean, what is the better practice, having the Trusted Root CA do > the signing of all certs, or attempting to establish this Trusted Root > CA - Signing CA - hierarchy? RFC 1422 seems to desire a CA hierarchy, > while RFCs 2459 and 3280 seem to argue that with x509v3 it is uncessary > - ack!?! > How you set up your CA is determined by several things:
1: Policy Constraints: Essentially, if you want to have a particular certificate trusted by others, you need to have a Certificate Policy. Take a look at RFC3647 for the "standard" format, if you don't already have a policy that your environment says you have to follow. 2: Technical Constraints: What sort of programs are you using? What are your relying parties (the programs and people using the certificates to validate the identity presented) capable of? Can they (like Microsoft CAPI) do full RFC 3280 path validation and discovery, or are they limitted (like stock Apache, which doesn't even do CRLs without a lot of pain and suffering). 3: Your budget. If you are using raw OpenSSL for your CA, you probably don't have a lot of cash to spend on infrastructure (since OpenSSL, while technically very good, is missing some functionality that more capable tools like Entrust, Microsoft CA, or Redhat Certificate Services have - which is understandable, given that it is, first and foremost, a library, and not a CA product). So you may not have the extra funds for an offline root (we usually use a laptop, a dedicated HSM, and a good safe in a secure location), and for it's operation (even though it's offline, you still need to, at least periodically, issue CRLs (or, more correctly, an ARL)). However, you can satisfy quite a few of the requirements that even a fairly demanding Certificate Policy puts on your environment. We've written up a howto guide that shows how an OpenSSL CA could be used as a test CA in the Aerospace "CertiPath" framework - it can't be used in production, because several of the bits of functionality that the CertiPath Certificate Policy requires are only available in 0.9.8 and later, which doesn't have FIPS certification, which is another of the requirements. You can find the howto (which includes how to set up a Root and Signing CA) at: http://www.carillon.ca/library/openssl_testca_howto_1.2.pdf References to the policy are in the appendix of that document. > 2) Is the file index.txt (and the associated brethren), given question 1 > above, related to the Signing CA or the Trusted Root CA? > a. Should index.txt contain the serial number and cert of the > Trusted Root CA OR the serial number of the Signing CA? > b. Should the Signing CA (and any other intermediary CA) have its > own cert database? > See the above guide for how to handle this. You probably want a separate index.txt for each CA (or else you'll have them clobbering entries in each other, or have an unclear idea of who issued what). > 3) Is there a How To, that is considered a definitive resource on the > matter, that discusses using OpenSSL to build out a RFC compliant PKI > hierarchy for someone who is sleep deprived due to an infant? > a. I have created CAs in the past and gotten plenty of this to work, > but now that I have to try to due a true PKI environment, I realize I > have more questions than knowledge. Well, we're currently using that guide for customers that are working within a very rigid environment, so while I won't claim it is "definitive", it certainly shows how to do it, in a very policy constrained and technically demanding environment. :) Again, it sounds like you should start with your Certificate Policy, and then build out from there what is required within your community of trust. -- 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]
