Hi, >>> Root Certificate >>> | | | >>> +--------------------+ | +--------------------+ >>> | | | >>> Server CA Auth CA (User) Auth CA (Admins) >>> >>> Or would you suggest a different setup? >> Sounds reasonable to me. Maybe combining the Auth CAs into one >> would be >> something to consider (you can still configure a higher level of >> approvals needed for an admin certificate to be issued in OpenXPKI). > > That would mean changing the workflow model. No problem there, but how > would combining the Auth CAs work? That is, how do I differentiate > between > the different access levels?
just as Alex I'd also suggest using a single user CA for both types of user certificates. Then you can define different certificate profiles for the user classes. Generally I am in favour of a scheme where certificates are only used for authentication and where no authorization details are coded INTO the certificate. For example you could define an LDAP group that lists all Admins. But this really depends on your environment and your policy. >> Yes, that's the way it is at the moment. In the above scenario, it >> (theoretically) would be enough to create the Root CA certificate >> using >> openssl and then create the Sub-CA certificates using OpenXPKI - >> but we >> do not ship with a CA certificate profile, which means you would >> have to >> write a corresponding profile (which is probably at least as >> complicated >> as issuing the certificates using OpenSSL). > > Issuing the certificates through openssl is not that hard in > itself. But > I would expect openxpkiadm to be able to roll out the root certificate > (that is the selfsigned cert). Well, it's an administration tool, not a CA itself... But I understand your requirement. For our main installation here we solved this by having a dedicated Root CA environment that is simply a bunch of shell scripts. This allows to protect the CA key properly and to offload CA creation to very simple processes. I have been thinking of adding this component to OpenXPKI (as contrib stuff) or to create a new SF project out of it. >> Currently, you need an existing CA installation (i.e. certificate and >> key) to issue a certificate, i.e. there is no way to issue a self- >> signed >> certificate in OpenXPKI, which prevents us from creating root >> certificates within OpenXPKI. > > Mhm. OpenXPKI is big iron :) >> Furthermore, it is a bit of a design question - we thought that >> the Root >> CA should possibly live on a different machine (preferably without >> any >> network access) than the CA. Not having the possibility to do it >> sort of >> prevents the user from just bootstrapping the CA on the system it >> will >> run on. > > I'm thinking about having the root key on a smartcard for one test- > setup. > Granted, this would result in slower keygeneration for the sub-ca, but > sub-cas are not created every day. Another problem would be the > relatively > small keylength of 2048bit on the smartcard while current suggestions > expect 4096bits. > But the key would be tamperproof and removable. With a pin-pad > reader it's > also not network-accessible and can be locked away in a safe if not in > use. That's OK for testing, but I'd recommend against a production CA on a single SmartCard: there's no way for secure key backup if the key is generated on the SmartCard, creating a single point of failure should the SmartCard get unaccessible. Real-life example: Our Root CA solution works with said shell script, an nCipher HSM, a customized Knoppix CD (containing the CA softare and HSM drivers), an USB stick for permanent storage and a standard PC. For Root CA operation we simply plug in the HSM to a standard PC, plug in the USB stick, boot Knoppix (networking is disabled in this remaster). Then we can use the shell script to perform Root CA operations such as CRL or Cert issuance via the HSM. Resulting data (certs, CRLs) are stored on the memory stick which is then backed up to CD. You can use the same setup without HSM by storing the CA key on the memory stick as well. Less secure but if you keep the USB stick in a vault this should be sufficiently secure. >> But I agree that we need a better documentation on how to >> bootstrap the >> system, i.e. creating the needed CA certificates ... > > Agreed! I haven't had time yet to really roll out the test setup > here. If > you could provide me with some general hints, maybe just a list of > keywords what to do I'd offer to try it and flesh out the > guidelines until > I have something working. Well, I'll take this as encouragement to finally spend some time on writing documentation... cheers Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
