> 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. 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. Oil ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
