bcrypto / btok

Cryptographic tokens
4 stars 4 forks source link

Идентификаторы и связывание #68

Closed agievich closed 5 years ago

agievich commented 5 years ago

Вопрос #67 требует взглянуть по новому на вопрос #56.

Конфигурация. Имеется 3 идентификатора:

Предусмотрено связывание Id1 = Id2. Связывание разумно, оно означает, что личный ключ X.509-сертификата действительно хранится на соответствующем КТ.

Проблема. Связывание Id1 = Id3, предусмотренное первоначально, после обсуждения вопроса #56 сделано необязательным. Облегченный сертификат, на котором строится аутентификация КТ перед терминалом, может быть "отвязанным" от токена: сертификат имеет идентификатор Id3, а соответствующий личный ключ хранится на токене с идентификатором Id1. Такая ситуация кажется неправильной. По крайней мере, она отличается от ситуации с сертификатами X.509.

Но это еще не все. Терминал, проведя аутентификацию КТ, удостоверяется в подлинности Id3. Действительно, 1) идентификатор Id3 был указан в проверенном облегченном сертификате КТ; 2) знание соответствующего сертификату личного ключа было проверено в ходе аутентификации.

После аутентификации Id3 выступает в роли идентификатора доверенного сеанса. Доверие к сеансу распространяется на данные обмена в рамках этого сеанса. Например, на идентификаторы Id1 и Id2, которые передаются в виде группы DG1 и как часть объекта Name.

Поэтому в билете аутентификации идентификатор Id3 имеет статус первичного, а идентификаторы Id1, Id2 --- статус подчиненных. Но с точки зрения ПС, которая разбирает билет, все наоборот: идентификаторы Id1 = Id2 главные, а идентификатор Id3 имеет только вспомогательное значение. Для прикладной системы важно уметь связывать аутентифицированные сеансы по Id1 = Id2, а не по идентификатору облегченного сертификата Id3.

Предложение. Вернуть связывание Id1 = Id3. Негативные эффекты такого связывания обсуждались в #56. Не кажется, что эти эффекты имеют критическое (или даже существенное) значение.

agievich commented 5 years ago

Пока откладывается.