Re: implement subject alternative names support for SSL connections

Поиск
Список
Период
Сортировка
От Alexey Klyukin
Тема Re: implement subject alternative names support for SSL connections
Дата
Msg-id CAAS3tyL_pqnnvuM=4RvetYMxBrYjGWdkjJHYMkCXzpxRtr_XXw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: implement subject alternative names support for SSL connections  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: implement subject alternative names support for SSL connections
Список pgsql-hackers
Дерево обсуждения
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
hlinnakangas@vmware.com> wrote:

The patch doesn't seem to support wildcards in alternative names. Is that on purpose?

Not really, we just did not have any use case for them, but it seems that RFC 5280 does not disallow them:

"  Finally, the semantics of subject alternative names that include
   wildcard characters (e.g., as a placeholder for a set of names) are
   not addressed by this specification.  Applications with specific
   requirements MAY use such names, but they must define the semantics."

I've added support for them in the next iteration of the patch attached to this email.
 

It would be good to add a little helper function that does the NULL-check, straight comparison, and wildcard check, for a single name. And then use that for the Common Name and all the Alternatives. That'll ensure that all the same rules apply whether the name is the Common Name or an Alternative (assuming that the rules are supposed to be the same; I don't know if that's true).

Thanks, common code has been moved into a separate new function.

Another question is how should we treat the certificates with no CN and non-empty SAN?

Current code just bails out right after finding no CN section present , but the RFC (5280) says:
"
   Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. 
"
which to me sounds like the possibility of coming across such certificates in the wild, although I personally see little use in them.

Regards,
-- 
Alexey Klyukin
Вложения

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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Allow units to be specified in relation option setting value.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Allow units to be specified in relation option setting value.