> Well, the Subject Distinguished Name should have the > Organization...
Can you envision long-lived certs issued by gov't - like passports? In that case, Organization would not have the same semantics. But this is less relevant for our discussion. > ...but I strongly disagree with you if you think > access permissions belong anywhere in a cert. It appears to be convenient to have _separate_ certs - called ATRIBUTE certs - that carry that information. More convenient than other means of conveying this same information. In the above example - "identity cert" is your passport issued by (for the sake of the argument) USA, "attribute cert issued by a different authority" is your visa to enter (for the sake of the argument) India issued by Indian consulate and with life-time shorter than your passport. > Attribute certs are a lousy way to encode security policy. Matter of taste. > You really only need signed assertions if the relying party > has no trusted method of communication with the policy server > (file/db/etc). Of course. Just like you really only need identity certs if the relying party has no trusted method of communicating with authentication server. I.e. if everything in your shop (and other shops you're communicating with) is Kerberized - you don't need PKI. > Revocation is a pain, certificate status is a > pain, Of course. That's true for *all* the PK issues - be it identity or attribute certs. > and you've just multiplied your public key computation > load by a factor of three of four. No, you "merely" double it. One - check that the identity cert is valid, two - that the attribute cert that *you* are interested in (out of a dozen that may be attached to this identity cert) is OK. > Much better to check whether the authenticated party has > permission to do what's requested at the time of the request. Authentication and authorization are very disticnt and different things. Nonetheless, checking permissions is not that different from checking authenticity. For example - what means are there to check authenticity? And to check authorization? > Group membership is questionable -- the OU is certainly a > kind of group, but for the purposes of access control a party > may belong to many groups, and a robust policy might restrict > access to certain hours during certain days of the week. The idea is that credentials that are long-lived and are meaningful more-or-less universally (identity and - to a lesser extent - employment) seem to fit well in the identity cert. Credentials that have shorter life, but still somewhat persistent (and meaningful across localities) - would fit in the attribute certs. And credentials that are not meaningful outside of local environment and/or are very short-lived - probably are better served by online query to the policy server. > ...[from a different post]...Authentication involve untrusted > networks, passwords which can be stolen or forgotten etc. But > once you trust authentication, decisions about authorization > of authenticated users for certain operation are typically > within your server system. If the only credential necessary for authorization decision is requestor's identity, and all the policy information is readily available online - then yes. Imagine a situation in the future: you are coming to a car dealer and present your identity cert plus an attribute cert issued by a bank that says "owner of identity cert X has been approved for a loan for a new car in amount of up to $XX valid till XXX". ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
