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

From Andrew Dunstan
Subject Re: Allow matching whole DN from a client certificate
Date
Msg-id 488b63cc-1879-d88c-7770-0ea05f3e8cca@dunslane.net
Whole thread Raw
In response to Re: Allow matching whole DN from a client certificate  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Allow matching whole DN from a client certificate  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 1/28/21 5:10 PM, Andrew Dunstan wrote:
>
>> (I'd still recommend switching to use the RFC
>> flag to OpenSSL, to ease future improvements.) There should be a bunch
>> of warning documentation saying not to do anything more complex unless
>> you're an expert, and that the exact regular expression needed may
>> change depending on the TLS backend.
>
> I'll play around with the RFC flag.
>
>
>> If you want to add UTF-8 support to the above, so that things outside
>> ASCII can be matched nicely, then the ASN1_STRFLGS_ESC_MSB flag should
>> be removed from the _print_ex() call per OpenSSL documentation, and we
>> should investigate how it plays with other non-UTF-8 database
>> encodings. That seems like work but not a huge amount of it.
>
> How about if we remove ASN1_STRFLGS_ESC_MSB when the server encoding is
> UTF8? That should be an extremely simple change.
>
>
>

Of course, we don't have any idea what the database is at this stage, so
that wasn't well thought out.


I'm inclined at this stage just to turn on RFC2253. If someone wants to
deal with UTF8 (or other encodings) at a later stage they can.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Is Recovery actually paused?
Next
From: Alvaro Herrera
Date:
Subject: Re: LogwrtResult contended spinlock