Prev: Postfix legacy releases 2.6.6, 2.5.10, 2.4.14 available
Next: 2.6.5->2.7.0 upgrade
From: Victor Duchovni on 23 Mar 2010 11:41
On Tue, Mar 23, 2010 at 10:10:44AM -0400, Wietse Venema wrote:

> > * issuer "TERENA Personal CA"
> > * O=TERENA
> > * C=NL
> >
> > I guess what I am looking for is a new restriction called something like
> > "check_ccert_attr", that would use user defined attributes to take
> > decisions. That would be really scalable for our situation.

Keep in mind that in general, ccert attributes are UTF-8 data so any code
to handle these would need to be UTF-8 compatible. Also, I code to parse
the issuer DN into all its components is not attractive in this context.
The component names ("dc", "ou", ...) can repeat or be unnamed numbered
"oids", ... It is far from clear how to expose the parsed DN to a policy
service or Wietse's proposed "check_access attr_name table" feature.

Therefore, the best that I can offer in this context is to expose
the full subject DN as a single attribute. This too requires care,
becase string encodings of DNs can be tricky to parse since "," or
"/" characters use to create "displayable" DNs can also occur inside
the values of DN components. I would have to generate an "escaped" DN,
in which internal delimiters are preceded by "\" or something similar.

You'll also need the issuer DN unless your CA file includes only the one
trusted issuer (and no standard CA file is preloaded by OpenSSL library
in addition to the CAfile you specify, as is the case in some vendor
releases of OpenSSL).

An extra complication is that the best subject name could in
subjectAltName value, not the subject DN.

Another option is to export the entire client certificate chain as a
single attribute (in a suitable encoding) and let the policy service
parse certificates via a suitable X.509 library.

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.

So, bottom line, X.509 is hell, and I would humbly suggest that you
stick with SASL or consider client cert fingerprints, if issuing your
own client certs (rather than using a public CA) is an option.

Do your users actually want to install and use client certs? Do they
have them in any case for other reasons?

--
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.

 | 
Pages: 1
Prev: Postfix legacy releases 2.6.6, 2.5.10, 2.4.14 available
Next: 2.6.5->2.7.0 upgrade