Craig, * Craig Ringer (craig@xxxxxxxxxxxxxxx) wrote: > Yep, in most applications I've seen you usually store a list of > authorized SubjectDNs or you just use your own self-signed root and > issue certs from it. Even with a self-signed root issuing certs, you need to map the individual cert to a PG user in some fashion. > I'm pretty sure I've seen tools match on part of the DN, like the > organisation field, but since I can't remember *where* I'm not sure > that's all that useful. Looking at what other tools do and how they handle this question would certainly be a good idea. > I don't know about "very rare" but it's certainly not common outside > very large orgs. I tried to find a CA that'd let me issue intermediate > client certs for 2ndQuadrant but found nobody that'd do it for > certificate volumes less than several thousand new certs a month. I'd > been using intermediate CAs based on my own self-signed CA root quite > heavily in infrastructure elsewhere I was rather surprised that the same > sort of thing wasn't easily available for public CAs. It's pretty simple, really- issuing certs is how the public CAs make their money. If they give you a CA cert that can issue certs, they're cut out of the loop. > I get the impression it's fairly common in internal infrastructure, > especially with the cert management tools offered by Microsoft Active > Directory servers, but have no strong information to substantiate this. > Nor do I know whether we need to support this mode of operation. In general, CAs view intermediate certs as a way to provide automated systems while having their self-signed root private key highly protected. The intermediate CAs therefore have a shorter life-span and end up changing much more frequently than the root certs (though root certs certainly also do change, but it's much more painful). That's one of the reasons that they're bad to use as part of the authentication criteria. The problem with trying to use intermediate CAs as a way of dividing up organizational responsibility is simply that there's very few systems out there which will support that kind of configuration, from what I've seen. Wrt Active Directory this problem is actually very well solved through use of Kerberos, where you have multiple realms, directional trust between the realms, and most tools (including PG) understand that a principal is the combination of username@REALM and let you authorize based on that. > BTW, This discussion has made me realise that I know less about SSL/TLS > and X.509 certificate extensions than I'd like to when dealing with this > topic. In particular, I don't know whether a CA can issue an > intermediate CA with extensions that restrict it to validly signing only > host certificates for hosts under a particular domain or > user-identifying client certs with CNs under a particular organisation - > and whether, if such extensions exist, applications actually check them > when verifying the certificate trust chain. You can set flags on certificates but I've not seen the kind of complex restrictions that you're describing. Remember that anything that the CA sets for an intermediate CA cert would have to be checked by whatever software is doing the certificate validation, meaning that you'd have to make sure all your certificate-based software is updated to do that kind of validation (and do it in a consistent way, or you'd get all kinds of fun failures). > Ugh, that's not something I've ever had the ... privilege ... to deal > with before. I worked for the company that built the original federal bridge software. :) I wasn't directly involved in that project, but I certainly gained some understanding of the complexities through working with the folks who were. > Only for using intermediate certs as authorization roots, and it may be > reasonable to say "we don't support that, use an authorized DN list". Or > come up with a better solution like checking attributes of the SubjectDN > for authorization purposes after validating the signature chain to prove > authenticity. I think it'd be valuable to distinguish "trusted CAs" from "intermediate CAs" in PG explicitly (as I recall, you can already do this by simply ensuring that your OpenSSL config is set up correctly for the system wide defaults). That's what most serious SSL users will be familiar with anyway. I'm on the fence about if only supporting a list of "trusted CAs" (through the cert files that we currently have) rises to the level of being a security issue, but we should at least update the documentation to reflect that all CAs listed in the file are fully trusted and plan to provide an intermediate CA list option. To be honest, our entire SSL support mechanism could really use some work and it'd be great if we had some folks looking into it seriously. One of the problems we've long had is the dependency on OpenSSL (yes, it's a problem) and it'd be good to consider, if we're changing the SSL configuration, how we could make it easier to introduce other SSL libraries in the future. > Certificate fingerprint? Easily obtained via most client UIs and via They change too much. This is the trade-off that you end up having to deal with- either you depend on the DN/CN, which can end up being duplicately issued by a given root CA, or you depend on the fingerprint and then have to re-enroll individuals whenever they get a new cert. This isn't an easy problem to solve, when dealing with the US ACES program, we could never get them to give us a "unique-to-a-person" identifier, the best we got was the DN. That changes when an individual changes organizations, which happens stupidly frequently in government, but (on rare occation..) it may also come with an actual change in responsibility, such that the individual shouldn't have access any longer. Being able to map certs based on the DN instead of just the CN would, imv, be a valuable improvment to the PG SSL options. We'd probably want to support that on a per-map basis and not just globally. > However, if I was managing a group large enough to want cert auth I'd > want to be able to specify something like: > > SubjectDNMatches: C=*, ST=*, L=*, O=MyCompany, CN=* If we had a way to use the DN in pg_ident.conf, you could use a regex to do the matching. > ... in which case there'd no longer be a need to restrict trust to > intermediate CAs, you'd just trust the root and restrict the authorized > SubjectDNs. In general, I'm open to doing it all kinds of ways; more options here would be better than what we've currently got. I would put splitting the CA cert chain file into trusted-CAs and intermediate-CAs as the higher priority here, followed by allowing the use of the DN for the mapping to PG user, and perhaps lastly something that tried to tie into a specific path, chain, or intermediate CA, as I don't see a very big use case for that. Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature
