On Wed, Mar 3, 2021 at 3:03 AM Jacob Champion <pchamp...@vmware.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
