Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: SSLRequire & UTF-8 characters & backward compatibility
Date: Sun, 2 Jan 2011 01:04:14 +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>
 <201012301343.57441.sf@sfritsch.de> <4D1D8BC3.3000105@velox.ch>
In-Reply-To: <4D1D8BC3.3000105@velox.ch>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201101020104.14502.sf@sfritsch.de>

On Friday 31 December 2010, Kaspar Brand wrote:
> On 30.12.2010 13:43, Stefan Fritsch wrote:
> >>> 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.
> > 
> > ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So
> > this change would also introduce an incompatibility with 2.2.x
> > for all the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
> 
> Good point, I didn't consider this when I came up with the
> suggestion quoted above. My new proposal would be to (only) use
> 
>   ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
> 
> for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
> escape the control characters (0x0 through 0x1f), but not the
> others listed in RFC 2253 - most of which primarily make sense
> when a complete DN is rendered, not single attribute values.

This will still treat non character string types (such as OCTET 
STRING) incorrectly, but I think we can ignore that problem. Or do you 
think we should add ASN1_STRFLGS_DUMP_UNKNOWN | ASN1_STRFLGS_DUMP_DER, 
too?

> > This would then also be covered by the SSLOption
> > LegacyDNStringFormat.
> 
> With the proposed change to the ASN1_STRING_print_ex flags, I think
> that we could unconditionally use the new format for the
> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no
> incompatibility with "simple" strings (i.e., 7-bit characters
> encoded as
> PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the
> current code produces unusable results in many cases anyway, so I
> would not try to retain that as a "legacy" string rendering.

Sounds good, commited to trunk as r1054323. Please review.

Cheers,
Stefan