On Wed, 11 Apr 2007, Alexander Klink wrote: > > I remember your presentation on the 23C3 where you showed some cases so I > That was probably Micha's part :)
Mhm. Not sure. Who was the first speaker? > > guess the following would be okay for servers and for differentiating > > between access classes. Christian is probably thinking about something > > like this: > > > > 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? > 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). > 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. > 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. Probably safe enough for most cases. > 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. regards, andreas ------------------------------------------------------------------------- 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
