Craig, * Craig Ringer (craig@xxxxxxxxxxxxxxx) wrote: > They are intermediary, but we're dealing with the case where trust and > authorization are not the same thing. Trust stems from the trusted root > in the SSL CA model, but that's a chain of trust for *identity* > (authentication), not *authorization*. Oh, I see. > The usual SSL terminology doesn't consider this, because it's a simple > back and white trust model where authenticated = authorized. That's not entirely accurate on a couple of levels. First, basic SSL is only concerned with authentication, authorization has historically been left up to the application. The more typical approach with the situation you're describing is to have an organization-level root CA which you only issue certs against. If you're using a public CA as your root, then you need to make sure you know how to ensure only the right people have access, typically be storing in the mapping table the unique ID issued by the CA for your users. It's very rare, from what I've seen, for public CAs to issue intermediate CAs to organizations to generate their own certs off of, so I'm a bit confused about how we got to this point. What I *have* seen is cross-root-cert trusts (known as the Federal Bridge in the US government), but that's quite a different thing as you have multiple self-signed root CAs involved and need to know how to properly traverse between them based on the trusts which have been built. Regarding cross-CAS authorization, there are extended attributes which are listed in the certificates that applications are expected to look at when considering authorization for the client. It's been taken further than that however, where inter-CA trusts have been defined with actual mappings between these extended attributes, including 'null' mappings (indicating that CA 'A' doesn't trust attribute 'q' from CA 'B'). > I guess that suggests we should be calling this something like > 'ssl_authorized_client_roots'. I'm no longer convinced that this really makes sense and I'm a bit worried about the simple authentication issue which I thought was at the heart of this concern. Is there anything there that you see as being an issue with what we're doing currently..? I do think we want to figure out a way to improve our mapping table to be able to use more than just the CN, since that can be repeated in multiple certs issued from a root CA, particularly when there are intermediary CAs. One option might be to provide a way to map against a specific issuing CA, or to a CA in the chain, but there's a lot of risk to that due to CA churn (in large setups, you're going to have lots of users who have certs issued from a bunch of different CAs, and those user certs will roll to new CAs as new badges are issued, for example..). It can get to be a real nightmare to try and keep up with all of the changes at that level. Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature
