On Fri, Mar 26, 2010 at 12:52:55PM +0100, Dick Visser wrote: > > Having noticed the many pitfalls of parsing X.509 certs, and written > > careful code to parse them (and avoided Postfix being linked to > > vulnerabilities later found in most certificate parsers), I am reluctant > > to ask Postfix users to write robust X.509 parsing code in their own > > policy service code. > > True. On the other hand, the admins responsible for setting the > institution information (most importantly: 'Organisation') in the > certificate are also the ones that need to check for it.
If there is no TTP (trusted third party, e.g. an external CA) in the loop, fingerprints work much more simply. Why do I need a TTP to authenticate my own users? Using X.509 certs for this is IMHO unwise. SASL (especially GSSAPI for sites with Kerberos) is much more usable than X.509 client certs in any case. > I can see that writing a X.509 parser is non-trivial. > Maybe this is totally the wrong idea, but would it be possible to reuse > the SSLRequire code of Apache in a new check_ccert_x, or possibly in a > policy daemon? > > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrequire Much too complex I think. > > Do your users actually want to install and use client certs? Do they > > have them in any case for other reasons? > > They don't have them now, but they will soon, and so will thousands of > others users: https://www.terena.org/activities/tcs/ Sorry, I am deeply skeptical of all PKI initiatives. > Right now nobody has them, so nobody uses them. TERENA has taken the > initiative to break this circle and to make them really available to our > community. My prediction is that Terena will fail for the same reasons as everyone that tried this before. The PKI model is deeply flawed. > It is expected that the same will happen with the personal (client) > certificates: once it is very easy and convenient to get one, > certificate based services will get used more and more. I expect that you'll not find this to be the case. > Lots of postmasters in the academic and research networking area will > want to use this. The TERENA Certificate Service is aimed at European > NRENs, which means in principle all students/employees/etc of higher > education and research institutes. So there is a huge potential. If PKI for the masses suddenly takes off, we can revisit Postfix support for this. In the mean time, what's available to policy services is the issuer name (CN or O) and subject CN. I am disinclined to send the peer certificate blob to policy services or build-in a complex language to evaluate client certs. We could perhaps agree on a robust encoding of the issuer and subject DN, and make these available to policy services (duplicating the current issuer name and subject name, which are components of each). I can probably help more users at lower implementation cost by allowing access checks on the public-key fingerprint instead of the certificate fingerprint, which would allow clients that renew CA certs with the same underlying private/public key pair to continue to access a given Postfix server. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
