Re: Trust intermediate CA for client certificates - Mailing list pgsql-hackers

Craig,

* Craig Ringer (craig@2ndquadrant.com) 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