Re: Allow matching whole DN from a client certificate

On Wed, Mar 3, 2021 at 3:03 AM Jacob Champion <pchampion(at)vmware(dot)com> wrote:

> On Fri, 2021-02-26 at 15:40 -0500, Andrew Dunstan wrote:
> > I think the thing that's principally outstanding w.r.t. this patch is
> > what format we should use to extract the DN.
>
> That and the warning label for sharp edges.
>
> > Should we use RFC2253,
> > which reverses the field order, as has been suggested upthread and is in
> > the latest patch? I'm slightly worried that it might be a POLA
> > violation.
>
> All I can provide is the hindsight from httpd. [1] is the thread that
> gave rise to its LegacyDNStringFormat.
>
> Since RFC 2253 isn't a canonical encoding scheme, and we've already
> established that different TLS implementations do things slightly
> differently even when providing RFC-compliant output, maybe it doesn't
> matter in the end: to get true compatibility, we need to implement a DN
> matching scheme rather than checking string equality. But using RFC2253
> for version 1 of the feature at least means that the *simplest* cases
> are the same across backends, since I doubt the NSS implementation is
> going to try to recreate OpenSSL's custom format.
>
> --Jacob
>
> [1]
> https://lists.apache.org/thread.html/2055b56985c69e7a6977151bf9817a0f982a4ad3b78a6a1984977fd0%401289507617%40%3Cusers.httpd.apache.org%3E
>

This patch set no longer applies
http://cfbot.cputube.org/patch_32_2835.log

Can we get a rebase?

I marked the patch "Waiting on Author".

--
Ibrar Ahmed