Re: Allow matching whole DN from a client certificate - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Allow matching whole DN from a client certificate
Date
Msg-id e894221959604490c4b562c1510c42feb5045d9c.camel@vmware.com
Whole thread Raw
In response to Re: Allow matching whole DN from a client certificate  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Allow matching whole DN from a client certificate  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> Reading more on this it seems we would essentially have to go with RFC 4514, as
> it's the closest to a standard which seems to exist.  Having done a lot
> research on this topic, do you have a gut feeling on direction?

Yeah, if we're going to use string matching then I agree with the use
of RFC 4514. I think a string-based approach is going to work for only
the most simple cases, though. Anything more complicated than plain
ASCII and a fixed base DN is going to become pretty unmanageable with a
regex; you'd need a filter system of some sort that understands DN
structure. The documentation should be clear on the limitations.

> The OpenSSL X509_NAME_cmp function use RFC 5280 section 7.1 and RFC 4517
> section 4.2.15 (which in turn reference RFC 4514 for the DN string format).
> libnss has CERT_AsciiToName which is referencing RFCs 1485, 1779 and 2253 in
> lib/certdb/alg1485.c.  Comparing the two would be interesting.

Yeah. I'll poke around a bit.

> Right, multi-value RDN's are defined as sets so C=US,A=B+C=D is equivalent to
> C=US,C=D+A=B according to RFC 5280.

Other potential differences, by my understanding of that RFC, include
the quoting of the "escaped" character class (e.g. a comma can be
escaped as either "\," or "\2C"), the case of hex characters ("\FF" vs
"\ff"), and the option to not quote unprintable control characters
(e.g. ASCII DEL, 0x7F, can be included verbatim or quoted as "\7F").

--Jacob

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes
Next
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes