Akos Vandra wrote: > Thank you, this was much more helpful. > > 2009/7/10 Victor Duchovni <victor.ducho...@morganstanley.com>: >> On Fri, Jul 10, 2009 at 11:11:48PM +0200, Akos Vandra wrote: >> >>>> The parties involved here are not connected to the internet, and thus >>>> don't have any access to a (this is an embedded project), and they >>>> must confirm eachother's identity based on the CA-signed certificates. >> Well, my address is not my identity. > > Surely not. But your picture, name, and other infos define who you are. > Actually, those are just attributes - I am me, but the fact that I am white, of Scottish descent, and 6'1" are simply attributes. As is the fact that I work for Carillon Information Security - these are not my Identity, these are attributes tied to my identity - I suggest you read Kim Cameron's Laws of Identity to help you get a better grasp of the differences between the two.
> "Identities" are just primary >> keys. It seems that you don't want identity certificates, but >> for some reason need attribute certificates with lots of attributes. >> >> Is the subject the holder of a corresponding private key in this context, > > yes > >> or this just a signed message binding the subject to a set of attributes? > > exactly, these are not exclusive. > They are exclusive - your identity ties you to one or more sets of attributes, which are completely different dependent on the context. I can have a much different set of attributes if I am identifying myself to my company, or to a partner company, to my local curling club, or to my bank. Again, see the "laws of Identity" referenced above. >> If the subject participates in a protocol in which the certificate >> authenticates its private key, generally a unique identifier for >> each subject is sufficient to support per-subject ACLs, ... >> >> If this is something akin to a signed "passport", the object in question >> is a signed message, not a certificate. > > you can't really draw a clear line between "signed message" and > "certificate", because a certificate isn't anything else but a signed > message from the CA saying that this public key's pair belongs to that > entity. > > >> Subject attributes are encoded in the subject DN. You can specify >> custom OIDs, if the standard OIDs are not sufficient. > > Thank you, I think this is what I need. An image can be base64 encoded > and passed as a field, but I'm not sure if there is any length limit, > I will have to make some research on this. Thanks for the link. I would encourage you to re-think your design if you are going to put all of those attributes into a certificate.... It appears that what you REALLY want is some form of Identity Federation... and not simply PKI. At the very least, you might want to consider X.509 Identity Certificates as well as Attribute Certificates... Have fun. Patrick ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
