Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Fwd: [users@httpd] SSLRequire & UTF-8 characters
Date: Mon, 20 Dec 2010 22:28:29 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )
References: <284733045.25.1290005636636.JavaMail.root@iris>
 <201012190158.28169.sf@sfritsch.de> <4D0EF30F.3040004@velox.ch>
In-Reply-To: <4D0EF30F.3040004@velox.ch>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201012202228.29686.sf@sfritsch.de>

On Monday 20 December 2010, Kaspar Brand wrote:

> > Instead of an SSLOption (which would require a request_rec to
> > lookup), I have implemented a per-vhost option for restoring
> > compatibility.
> 
> Could we pass the request_rec from ssl_var_lookup() to
> ssl_var_lookup_ssl(), and from there on to
> ssl_var_lookup_ssl_cert() etc.? SSLOptions seems like the best
> place to me for such an option, it's where I would expect it to
> find as an httpd user.

The problem is that ssl_var_lookup can be called for an open 
connection before the request_rec is created. In the current trunk, 
this does not seem to be done for the SSL_*_DN variables, but it is 
done for other variables like SSL_CLIENT_S_DN_CN. So the question is: 
Do we accept that modules which may call ssl_var_lookup for SSL_*_DN 
without request_rec may get the result in an unexpected format?

> I would name the option LegacyDNStringFormat (instead of
> "...VarFormat").
> 
> > Can
> > we reject such certificates somehow? Should we close the
> > connection if we see such a thing in ssl_var_lookup_ssl_cert? Or
> > should we try to escape the 0-byte in the variable?
> 
> The latter. I suggest using ASN1_STRING_print_ex() with
> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as
> \0).


OK, makes sense.