Re: Support for NSS as a libpq TLS backend

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Support for NSS as a libpq TLS backend
Дата
Msg-id 4b4e3a27cc56921d2acba2c25823fd2fc325b842.camel@vmware.com
обсуждение исходный текст
Ответ на Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Support for NSS as a libpq TLS backend
Список pgsql-hackers
On Mon, 2020-07-20 at 15:35 +0200, Daniel Gustafsson wrote:
> This version adds support for sslinfo on NSS for most the functions.

I've poked around to see what can be done about the
unimplemented ssl_client_dn_field/ssl_issuer_field functions. There's a
nasty soup of specs to wade around in, and it's not really clear to me
which ones take precedence since they're mostly centered on LDAP.

My take on it is that OpenSSL has done its own thing here, with almost-
based-on-a-spec-but-not-quite semantics. NSS has no equivalents to many
of the field names that OpenSSL supports (e.g. "commonName"). Likewise,
OpenSSL doesn't support case-insensitivity (e.g. "cn" in addition to
"CN") as many of the relevant RFCs require. They do both support
dotted-decimal representations, so we could theoretically get feature
parity there without a huge amount of work.

For the few attributes that NSS has a public API for retrieving:
- common name
- country
- locality
- state
- organization
- domain component
- org. unit
- DN qualifier
- uid
- email address(es?)
we could hardcode the list of OpenSSL-compatible names, and just
translate manually in sslinfo. Then leave the rest up to dotted-decimal 
OIDs.

Would that be desirable, or do we want this interface to be something
more generally compatible with (some as-of-yet unspecified) spec?

--Jacob

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: TRIM_ARRAY
Следующее
От: Andy Fan
Дата:
Сообщение: Re: How to get Relation tuples in C function