Вопрос #67 требует взглянуть по новому на вопрос #56.
Конфигурация. Имеется 3 идентификатора:
Id1 -- идентификатор КТ в DG1;
Id2 -- идентификационный номер в атрибуте serialNumber объекта Name (с префиксом IDC). Этот объект прямо переносится в X.509-сертификат владельца КТ;
Id3 -- идентификатор облегченного сертификата в его компоненте certHolderReference.
Предусмотрено связывание 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. Не кажется, что эти эффекты имеют критическое (или даже существенное) значение.
Вопрос #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. Не кажется, что эти эффекты имеют критическое (или даже существенное) значение.