On 02 Nov 2014, at 12:07 PM, Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
> 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. Currently the application in this case is mod_authnz_ldap. While it is possible to build a complex expression to match a series of DNs, you are limited in knowing the length of the chain in advance, and in my case that isn’t possible - chains may be of arbitrary length. > 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 problem I am trying to solve is that I trust both CA1 and CA2 to issue certificates, but I don’t trust CA2 not to (accidentally or purposefully) issue a certificate with the same issuer as CA1. As a result I want to store a record of the full sequence of DNs all the way to the root. Back when CAs were one level deep the issuer was enough, but with arbitrary certificate chains this isn’t possible any more. In other words, you may come in if a) your cert validates to any trusted anchor, and b) your cert is issued by a specific pre-agreed trust anchor. > 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). Good point, let me change that. Regards, Graham —
