Заранее извиняюсь, если вопросы будут наивными -  я немного не в теме, только-только влезаю...
Опишу ситуацию для понимания:

есть три стороны - владелицы ключей:
- "клиент"
- "сервер"
- "посредник"

Публичный GPG-ключ "клиента" подписан "посредником". "Сервер" имеет абсолютное доверие к публичному ключу "посредника", но не имеет в своём keyring (кольце ключей?) ключа "клиента".

"Сервер" проинициализировал GnuTLS (своими private/public ключи и keyring), повис на сокете и ждёт соединений.

"Клиент" также проинициализировал GnuTLS (своими private/public ключами без keyring) и соединяется к "серверу".

Теперь вопрос: как указать "серверу" проверять ключи подписантов на этапе установления соединения? То есть, чтобы такой подписанный "посредником" ключ был валидным, а неподписанные или подписанные другими посредниками (не "свои") ключи были бы невалидными и отвергались бы сервером?

Расширенный вопрос: ключ "посредника" подписан ключом "посредник-2". Ключа "посредника" нет у сервера, но есть ключ "посредника-2" с абсолютным доверием... Короче, как сделать аналог X509-инфраструктуры, но с возможностью мультиподписей?

Ну и напоследок: Возможно ли расширять keyring новыми ключами и подсовывать это "серверу" на лету, без переинициализации TLS?

• GnuTLS и OpenGPG-ключи: доверие стороннему ключу,anonymous, 22:05 , 26-Мрт-11
• GnuTLS и OpenGPG-ключи: доверие стороннему ключу,anonymous, 23:07 , 26-Мрт-11

> есть три стороны - владелицы ключей:
> - "клиент"
> - "сервер"
> - "посредник"

мб стоит заменить "посредник" на "сервер аутентификации"(т.е. AS, см. ниже)?

>[оверквотинг удален]
> к публичному ключу "посредника", но не имеет в своём keyring (кольце
> ключей?) ключа "клиента".
> "Сервер" проинициализировал GnuTLS (своими private/public ключи и keyring), повис на сокете
> и ждёт соединений.
> "Клиент" также проинициализировал GnuTLS (своими private/public ключами без keyring)
> и соединяется к "серверу".
> Теперь вопрос: как указать "серверу" проверять ключи подписантов на этапе установления
> соединения? То есть, чтобы такой подписанный "посредником" ключ был валидным, а
> неподписанные или подписанные другими посредниками (не "свои") ключи были бы невалидными
> и отвергались бы сервером?

описанное похоже на разграничение AS в Kerberos v5.

> Расширенный вопрос: ключ "посредника" подписан ключом "посредник-2". Ключа "посредника"
> нет у сервера, но есть ключ "посредника-2" с абсолютным доверием... Короче,
> как сделать аналог X509-инфраструктуры, но с возможностью мультиподписей?

вопрос понял, хотя и не сразу. покопайтесь в RFC Kerberos(RFC 1510) или возможно в последующих. возможно всё уже придумано и реализуется проще(распределение ролей между AS)

> Ну и напоследок: Возможно ли расширять keyring новыми ключами и подсовывать это
> "серверу" на лету, без переинициализации TLS?

> Расширенный вопрос: ключ "посредника" подписан ключом "посредник-2". Ключа "посредника"
> нет у сервера, но есть ключ "посредника-2" с абсолютным доверием... Короче,
> как сделать аналог X509-инфраструктуры, но с возможностью мультиподписей?

вот как я понял ваш вопрос:
рассмотрим пошагово 2 случая. первый с одним AS, второй с двумя AS.
терминология: К-клиент, С-сервер, AS1-"посредник1", AS2-"посредник-2", + -какое-то преобразование.

случай первый:
1)K---Kкл--->AS1
2)AS1---Kas1_pub--->K
3)AS1---Kas1_prv--->C
4)K---(Kкл+Kas1_pub)--->C

т.е. Кas1_prv = Kкл + Kas1_pub

случай второй:
1)K---Kкл--->AS1
2)AS1---Kas1_prv--->AS2
3)AS2---Kas2_pub--->AS1
4)AS1---Kas2_pub--->K
5)AS2---Kas2_prv--->C
6)K---(Kкл+Kas2_pub)--->С

т.е. Kas2_prv = Kкл + Kas2_pub, кароче тоже самое. только Ккл нужно как то встроить в диалог общения между AS`ми.

вроде всё просто (: опять же Kerberos должен уметь такое.