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)
Message-ID: <54560256.8040509@velox.ch>
Date: Sun, 02 Nov 2014 11:07:18 +0100
From: Kaspar Brand <httpd-dev.2014@velox.ch>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client
 certificate chain
References: <070C39DD-61EF-40A8-A6F7-8605EB972AB4@sharp.fm>
 <5454AC17.7030708@velox.ch> <D99A97D6-1FB9-4F84-A678-6871CC1E15C9@sharp.fm>
In-Reply-To: <D99A97D6-1FB9-4F84-A678-6871CC1E15C9@sharp.fm>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 01.11.2014 13:41, Graham Leggett wrote:
> The trouble with doing that is that it makes life really difficult to
> match arbitrary certificate chains - you need to know in advance how
> many certs are in each chain, and you need to perform a lot of
> messing about to perform a match, and to ensure the subjects are in
> the right order.

Assuming that mod_ssl exported the subject DNs as SSL_CLIENT_S_DN_0,
SSL_CLIENT_S_DN_1 etc., what would be left to the application is
assembling them properly (by prepending "name=" and inserting comma
separators) to get the string you're looking for. Seems fairly
straightforward IMO, and shouldn't be too complex to code in the
application.

> The use case this solves is that I want to uniquely identify a
> certificate and store that identity in an LDAP directory.

I'm not in the position of making a judgement about the fitness of the
suggested approach to your use case, of course (that's your call), but
let me add that an X.509 certificate isn't uniquely identified by the
subject DNs of its certification path. Uniqueness of an X.509
certificate is ensured through its (issuer DN, serial number) tuple.
Certification paths (and hence the suggested SSL_CLIENT_CERT_SUBJECTS
string) may change when cross-certified CAs are added to the mix, see
e.g. RFC 4158.

> The format chosen is the subjects of the certs encoded as RFC2253,
> which are turned into a DN that is in turn RFC2253 encoded again. The
> result is therefore still a valid DN, and so can be stored in any DN
> formatted field in LDAP. This works nicely with 389ds.

I don't dispute that such a string "can be stored in any DN formatted
field in LDAP", but consider the use of the "name" RDN (OID 2.5.4.41)
fairly nonstandard. X.520 defines "Name" as "the attribute supertype
from which string attribute types typically used for naming may be
formed" (and "string attribute types" referring to things like
commonName, surname etc.). "distinguishedName" (2.5.4.49) would be more
appropriate, though it isn't really meant for use as an RDN attribute
type (but "an attribute for specifying the name of an object" in an
X.500 DIT).

> In terms of separating them, simply unpack the outer DN as per
> RFC2253, leaving you with the inner subject DNs. In practise you’re
> unlikely to want to separate them, instead you want to say “I want to
> trust this specific certificate issued by this specific CA”. Back in
> time matching the issuer was enough, but as soon as intermediate
> certs came along it became significantly more difficult to do.
> 
> (Having said the above I don’t disagree that the _n variables could
> be useful, it’s just that they don’t solve the use case I am
> facing).

My concern with the proposed SSL_CLIENT_CERT_SUBJECTS variable is that
it hardcodes a specific use case instead of adding a generic way to
retrieve the subject DNs of the complete certification path. The latter
is what should be implemented in mod_ssl, while constructing
SSL_CLIENT_CERT_SUBJECTS (or similar stuff) should be done in the
application, IMO.

Kaspar