Hi Andreas,
On Wed, Apr 11, 2007 at 03:29:17PM +0200, Andreas Thienemann 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?
Micha.
> > 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
Only a tiny bit. We currently have support for configuring that multiple
people (with possibly different roles) are needed for approval.
Currently, this is global for the workflow, though.
> would combining the Auth CAs work? That is, how do I differentiate between
> the different access levels?
This is something that should be on our TODO list: differentiating those
policies by the certificate role. On the web interface, you are asked
for the certificate role for which the certificate will be used. A while
ago I checked in some code that also restricts the certificate profiles
based on that choice. One could now check if the certificate role used
is RA Operator (or CA Operator) and increase the number of approvals
(and/or the roles) based on that. This is something that could be
implemented very quickly because the ACL system already has a notion of
an "affected role" (i.e. the role of the certificate to be issued).
> > 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).
Hmmm, I guess this is still a matter of discussion whether we really
want that to be possible. Personally, I don't believe this is a good
thing.
> > 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.
Good idea.
> 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
Sure, that's not really a problem.
> small keylength of 2048bit on the smartcard while current suggestions
> expect 4096bits.
Who suggests 4096? We are fairly paranoid, but none of the productive
CAs I have seen use that keylength.
> 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.
True. A tiny HSM if you want. I believe there is also engine support for
the OpenSC framework, so in theory it should be possible to issue
certificates on the smartcard using OpenXPKI.
> > 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.
That sounds' good, I'll let you know some ideas soon.
Regards,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
[EMAIL PROTECTED] | working @ urn:oid:1.3.6.1.4.1.11417
-------------------------------------------------------------------------
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
