On July 15, 2008 10:57:21 am you wrote: > > If you are including a value in there that is meant to be read by a > > person, then yes. If you are including a value in there that is meant to > > be interpretted and acted upon by a Relying Party computer program, then > > no - but then, as I said in my previous message, if you include a private > > extension, the chances of either of these being possible with a > > non-proprietary client is approximately nil. If your certificates are > > only ever being used by a proprietary client in a closed community, then > > feel free to add Private Extensions. If not, then it would probably be > > better to find a way to express what you want to convey using one of the > > standard extensions. > > ah, now that clears things up. Thanks Patrick. > > I am toying with the efficacy to use certificate attributes to make > application decisions (access control, look and feel, etc), so yes, a > private, closed system. > The main problem with doing this is scalability - every time your user changes preferences, they will need to go through the process to get a new certificate. Every time they move jobs, or change access rights, they will need a new certificate. This means that you need to revoke the old one, and somehow issue them a new one. Setting this up in a manner that actually has the certificates mean something is non-trivial. If you don't care about having trusted certificates, then I would strongly suggest doing your identity management another way - PKI is notoriously user-unfriendly. If you do care about having trusted certificates, then I strongly encourage you to de-couple identity and access management. The current state of the art for doing this, BTW, is Identity federation... you may want to take a look at it instead of shoehorning things into certificates that were never meant to go there (For the purists on the list - yes, there are attribute certificates, but I have yet to see anyone actually using them :)
> My idea, not a new one by any means, is to separate user provisioning > from application logic. I want to have an authoritative source of the > user and their role, and based on that, the application does something > special. I know there are probably easier ways to do this like assign > a user a role in the app, but I may want to have the user access > multiple apps and using a certificate seems like a good option. I will > certainly use the standard options where I can. I am reading through > the IETF PKIX docs even as we speak. > Sounds like what you really want is N-0 user Federation. SAML2.0 or WS-Fed will both do what you want - and if you implement it using Cardspace (active requestor profile) you should be able to get it to work relatively painlessly. Have fun. -- 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]
