Система и способ для передачи, хранения и извлечения аутентифицированных документов

007089 Уровень техники Изобретение относится к системам и способам для обеспечения верифицируемой цепочки данных и защиты для создания, выполнения, обслуживания, передачи, извлечения и уничтожения электронных исходных информационных объектов, таких как Электронные Исходные документы. Данное изобретение преимущественно использует Доверенную Службу Защиты Информации(ДСЗИ, TCU) Заявителей, которая содержит в себе электронные исходные записи и сопоставимые системные ролевые имена в качестве виртуального электронного хранилища при проверке достоверности прав индивидуума на выполнение запрашиваемого действия, подлинности представленных электронных информационных объектов, и состояния сертификатов аутентификации, используемых при проверке цифровой подписи и в процессах аутентификации пользователя. Такие ДСЗИ и операции описаны в патентах США 5615268;5748738;6237096 и 6367013. В данном описании используется следующий список сокращений. Используемые cокращенияCRL - Список Аннулированных Сертификатов (CAC);CSS - Служба Контроля за Состоянием Сертификатов (CKCC);IETF - Рабочая Группа По Инженерным Проблемам Интернета;ITU - Международный Союз по Телекоммуникациям;LDAP - Облегченный Протокол доступа к сетевым каталогам;OCSP - Онлайновый Протокол Сведений о Состоянии Сертификата, IETF-RFC 2560 X. 509 Онлайновый Протокол Сведений о Состоянии Сертификата Интернет - Инфраструктуры Открытого ключа OCSP, июнь 1999;PIN - Персональный Идентификационный Номер (ПИН);PKCS - Криптографические Стандарты Открытого Ключа;PKIX - Инфраструктура Открытого ключа (стандарт X. 509);S/MIME - Защищенные Многоцелевые Расширения Электронной Почты В Сети Интернет;SCVP - Простой Протокол Проверки Достоверности Сертификата, Проект -IETF-PKIX-SCVP-06,июль 2000;TCU - Доверенная Служба Защиты Информации (ДСЗИ);UETA - Единый Акт об Электронных Транзакциях;XML - Расширяемый Язык Разметки; Закон США Акт об Электронных Подписях во Всемирной и Национальной Торговле (ESIGN) и законы штатов США, разработанные по образцу UETA, разработанном Национальной Конференцией Специальных Уполномоченных по Унификации Законов Штатов, утвержденные и рекомендованные для введения в действие в 1999 году, обеспечивают гарантии законного положения для информационных объектов, подписанных электронной подписью (электронных документов), которые генерируются правительством, при банковской деятельности и электронной коммерции, и имеют своей целью реализацию эффективности и экономических выгод от этих потенциально совершенных электронных транзакций.PKI и ЦС представляют собой основные элементы технологии цифровой подписи, используемой при создании электронных исходных записей. PKI представляет собой совокупность ЦС, где доверие устанавливается между пользователями и организациями пользователей, при помощи создания либо иерархических взаимоотношений между ЦС, либо через перекрестную сертификацию между взаимодействующими ЦС. ЦС является уполномоченным для выпуска сертификатов аутентификации, которые связывают идентичность индивидуума или объекта с его или ее открытым ключом (проверка), причем только индивидууму дают доступ к соответствующему секретному ключу (подписание). В настоящее время,сертификаты обычно соответствуют стандарту сертификатов ITU X. 509 и сами подписываются цифровой подписью выпускающим ЦС. Такие сертификаты изображены, например, на фиг. 10 патента США 6237096, содержание которого приведено в качестве ссылки. Эти сертификаты аутентификации содержат серийный номер, идентифицирующую информацию субъекта (пользователя) и выпускающего (ЦС), период действия сертификата (дата и время, раньше и позже которых он не может использоваться), открытый ключ субъекта, и информация криптографического алгоритма, требуемая для создания и проверки цифровых подписей. Для создания цифровой подписи, информационный объект подвергают хешированию (обработке,использующей одностороннюю криптографическую функцию, которая может обнаружить изменения в объекте с точностью до одного бита), и затем случайные данные подвергаются шифрованию при помощи личного (секретного) ключа индивидуума. Проверка цифровой подписи достигается при помощи реверсирования этого процесса. Цифровая подпись дешифруется при помощи открытого ключа индивидуума,извлекаемого из его сертификата аутентификации и результат сравнивается с повторно вычисленной-1 007089 контрольной суммой исходного информационного объекта. Эти процессы могут меняться при использовании различных алгоритмов цифровой подписи. Цифровые подписи являются столь же достоверными,как и доверие, которое существует между доверяющими сторонами и выпускающим ЦС; и уровень уверенности, достигаемой физическим контролем, инструкциями и процедурами, осуществляемыми ЦС. Назначением технологии PKI является создание и поддержание одновременно защищенной и доверенной среды для сторон, обменивающихся информацией. Такие стороны уверены в том, что PKI установит идентичность пользователей и уведомит их в тех случаях, когда сертификат пользователя будет более не жизнеспособен. Сертификаты аннулируются в тех случаях, когда индивидуум покидает организацию, когда выпущен заменяющий сертификат, или когда подписывающий ключ утерян, захвачен или скомпрометирован. Поставщики сообщают о состоянии сертификата, при помощи широкого разнообразия способов. Эти разнообразные способы затрудняют получение пользователем состояния сертификата для других пользователей. Формирование доверительных взаимоотношений и возможности взаимодействия диктуются сертификатом PKI и политикой безопасности, а также их осуществлением. Политика сертификата определяет уровень персональной проверки (то есть, процесс для проверки достоверности информации запрашиваемой сертификатом и идентичности получателя, которому предназначен сертификат), требуемый (например, два вида удостоверения с фотографией, проверка кредитоспособности) для получения подтверждения на выпуск сертификата. Политика безопасности диктует физические, процедурные и процессуальные средства управления, необходимые для обслуживания прикладной среды. Существуют две преобладающих модели для создания и организации ЦС. Первая представляет собой иерархическую модель ЦС, которая напоминает перевернутое дерево, вершина которого представляет собой корневой ЦС. Корневой ЦС подписывает сертификаты непосредственно подчиненных ему ЦС. Затем эти ЦС подписывают сертификаты подчиненных им ЦС, и так далее. Эти взаимоотношения создают цепочки сертификатов, которые формируют ветви дерева. Два ЦС подтверждают, что между ними существуют доверительные взаимоотношения, посредством прохождения соответствующих им цепочек сертификатов до тех пор, пока не будет достигнут общий для них узел. ЦС могут быть сгруппированы и связаны с одним или более служебными каналами поставок, вертикально-организованными промышленными структурами, организациями или предприятиями. Во второй модели, ЦС создается для отдельного предприятия и обеспечивает услуги ЦС одному или более объектам в пределах этого предприятия. ЦС предприятия обычно не имеет никаких заранее установленных доверительных взаимоотношений с каким бы то ни было ЦС другого предприятия. Должно быть предпринято точно определенное действие, чтобы предоставить возможность взаимодействия в форме перекрестной сертификации ЦС, посредством чего два или более ЦС, которые соглашаются доверять друг другу, подписывают сертификаты друг друга и используют эти перекрестносертифицированные сертификаты во время проверки цифровой подписи. Сертификаты, выпущенные одним ЦС, затем могут быть подтверждены другим перекрестно-сертифицированным ЦС и его пользователями. ЦС аннулирует сертификаты в тех случаях, когда в числе других причин, информация, содержащаяся там, становится недействительной, когда секретный ключ пользователя становится скомпрометированным, или когда необходимо завершить привилегии приложения пользователя, основанные на сертификате. ЦС не могут просто удалить или изъять сертификат у его владельца, если он уже находится в собственности владельца. Вместо этого, сертификат отмечается в базе данных ЦС как аннулированный, и публикуются сведения о состоянии сертификата. Затем пользователи PKI могут узнавать о достоверности сертификата, при помощи запрашивания сведений о состоянии сертификата у выпускающего ЦС или идентифицированного хранилища сведений о состоянии (каталога). Предыдущий способ использовал передачу сведений о состоянии сертификата посредством публикации списка аннулированных сертификатов ЦС, известных как CAC. CAC загружались приложениями и доверяющими сторонами для определения того, был ли аннулирован сертификат конкретного пользователя и расширением для определения того, допустима ли все еще цифровая подпись этого пользователя или нет. Со временем CAC удлинялся, неся в себе и связь, инепроизводительные издержки от обработки данных. Дополнительный недостаток этого подхода состоит в том, что CAC часто выпускаются с большими интервалами (например, один или два раза в день). По этой причине, CAC после публикации часто тут же устаревают. Аннулированные сертификаты удаляются из CAC только после истечения срока действия сертификата. Мост PKI представляет собой способ обеспечения возможности взаимодействия между ЦС при помощи согласования распределения CAC. Такой мост является центральным хранилищем CAC, который в сущности присоединяется к набору ЦС, которые соглашаются принять сертификаты и политики безопасности друг друга. Все ЦС объявляют свои CAC мосту. Таким образом предоставляется возможность централизованной проверки достоверности сертификата любого индивидуума или объекта. Если сертификат предварительно не был аннулирован, то его все еще считают имеющим силу. Самый большой недостаток мостов PKI состоит в том, что они должны быть достижимы любым ЦС или пользователем,полагающимся на мост в отношении сведений о состоянии сертификата. Пропускная возможность, объ-2 007089 ем вычислений и требования к памяти могут быть дорогостоящими. Более современный способ для получения сведений о состоянии сертификата представляет собойIETF OCSP, который осуществляет прямой запрос к базе данных, которая может предоставить сведения о состоянии сертификата в режиме реального времени. Однако некоторые поставщики имеют осуществленные OCSP ответчики, которые базируются на CAC. Сведения о состоянии сертификата, которые передаются этим типом ответчиков настолько же своевременны как и CAC, на котором они базируются. Попытки достигнуть получения сведений о состоянии сертификата в режиме реального времени, такие как IETF SCVP, продолжают развиваться. Во время создания этого изобретения, комбинирование и приведение в соответствие способов проверки состояния не было осуществлено в открытой среде PKI. Любой подход к проверке достоверности сертификата представляет собой бескомпромиссное решение для ЦС, который выпустил сертификаты. Все пользователи, которые обладают сертификатами,выпущенными одним из членов ЦС, являются допустимыми/уполномоченными, если действие их сертификата не было приостановлено или аннулировано, или прекращено в связи с истечением срока действия. Обычной темой для управления участием является то, выпущен ли сертификат. Выпуск управляется сертификатом и политикой безопасности и деловыми правилами. Доверительная среда может изменяться от полностью открытой, где любой способный заплатить вступительный взнос, является выпускающим сертификат, до закрытой или ограниченной, требуя членства в предприятии или общности интересов. В любом случае, сертификат ЦС и/или политика безопасности управляют тем, предоставлена ли возможность взаимодействия. Изобретение заявителей использует подход к PKI и к проблеме возможности взаимодействия ЦС с точки зрения, совершенно отличной от описанных выше. Внимание заявителей сосредоточено на установлении доверительной среды, подходящей для создания, выполнения, обслуживания, передачи, извлечения и разрушения исходных электронных информационных объектов, которые также могут являться пригодными для передачи записями (собственность может перейти в другие руки). Чтобы представить себе эти цели, система, управляющая электронным оригиналом или аутентичной копией, должна предоставить возможность различения оригинала от любой его копии. Так среди бумажных оригиналов, может существовать только один оригинал. Примерами пригодных для передачи записей являются электронные оборотные документы и ценные бумаги. Электронная исходная запись может являться любой исходной записью, квалифицируется ли она в качестве пригодной для передачи записи или нет. Перемещение электронных исходных записей между системами должно иметь место, при помощи способов, которые гарантируют, что существует только один оригинал. Это изобретение создает электронную исходную запись, помещая обязанности по защите этой записи в руки независимой доверенной стороны, функционера или ДСЗИ, управляемого для выгоды владельца записи. Создание доверительной среды необходимо, но не достаточно для обслуживания электронных исходных записей. Для целей этого изобретения, доверительная среда создается формированием общности интересов, которая имеет закрытое или ограниченное членство, и в которой идентичность предполагаемых членов, организаций и их пользователей гарантируется при помощи соответствующих процедур проверки, которые управляют предоставлением признания в сообществе. Дополнительно, организация индивидуума, участие, ролевое имя и атрибуты определяются ДСЗИ во время регистрации. Индивидуумы должны быть однозначно идентифицированы в системе и в их сертификате аутентификации. Кроме того, должна быть предоставлена возможность удаления индивидуумов и организаций из сообщества, и оповещения об этом действии других членов сообщества. Традиционные подходы к возможности взаимодействия ЦС в недостаточной мере достигают этих целей. Проверка как минимум требует, чтобы организация и/или индивидуум имели поручителя среди известных членов сообщества. Кроме того, для оценки приемлемости потенциальных деловых партнеров,клиентов и заказчиков могут использоваться рейтинги, подобные выпускаемым компанией Dun andBradstreet для организаций или рейтинги проверки кредитной истории Equifax для индивидуумов, или эквивалентные кредитные или платежные истории. И проверяющую организацию, и поручающихся за нее пользователей, нужно считать заслуживающими доверия прежде, чем ДСЗИ разрешит принять их в члены. После того, как организация согласится на договорные термины, определяющие членство, каждый из поручающихся за нее индивидуумов будет предоставлять уникальный идентификатор и пароль,который даст возможность им обращаться к ДСЗИ. Как только индивидуум внесен в список членов одной или более ДСЗИ, владелец этой транзакции может назвать его участником транзакции и дать определенный доступ ко всем исходным записям, или их идентифицированному подмножеству, основываясь на его идентичности, ролевом имени и/или надежности. Для облегчения идентификации и аутентификации и предоставления транзакциям возможности происходить полностью в электронной форме, выбранное подмножество этой идентифицирующей информации включается в сертификат аутентификации участника. Сертификат аутентификации связывает идентичность пользователя с его открытым ключом, используя подтверждение достоверности цифровой подписи, произведенной при помощи ее согласования с подписанным секретным ключом. Сертификат или политика безопасности направляют требования доказательства подлинности (например, два вида удостоверения с фотографией, проверки кредитоспособности, личное представление),-3 007089 требуемые перед выпуском сертификата. Этот сертификат будет прикреплен к учетной записи ДСЗИ пользователя, если это требуется для органа управления, подписывающегося цифровым образом. Компоновка должна включать в себя подмножество элементов данных сертификата, которые однозначно идентифицируют пользователя (например, идентификатор сертификата, имя выпускающего ЦС, обычное имя пользователя). Будучи единожды связанным с учетной записью пользователя, сертификат может использоваться в сочетании с его цифровой подписью для предоставления доказательств подлинности, необходимых для разрешения заранее определенного набора авторизованных действий и для проверки цифровой подписи пользователя на предъявленных информационных объектах. Это особенно верно в случаях,когда владелец или агент владельца, управляющий набором электронных записей, приказывают ДСЗИ передать право собственности (то есть, внутренняя транзакция) и/или передать обязанности по защите электронных записей другому ДСЗИ (то есть, внешняя транзакция). Как описано выше, сертификаты аутентификации и криптография открытого ключа используются для обслуживания и аутентификации пользователя и проверки цифровой подписи. Сертификат цифровым образом подписывается выпускающим ЦС, процессом, при помощи которого идентичность получателя сообщения удостоверяется их открытым ключом. ЦС в выпуске сертификата декларирует, что индивидуум, идентифицированный в сертификате, является держателем соответствующего секретного ключа, используемого для цифрового подписания информационных объектов или их фрагментов. Настоящее изобретение отличается от других решений электронной коммерции, основанных наPKI, так как PKI рассматривается только в качестве санкционирующего элемента и не является единственным основанием доверительной среды. Поручительство, заключение контракта на членство, и регистрация являются основными факторами. Хотя сертификат и использование криптографии открытого ключа рассматриваются как технологии, облекающие членскими правами, сертификаты должны однозначно идентифицировать и должны быть привязаны к конкретным пользователям прежде, чем они могут быть привязаны к учетной записи ДСЗИ этого пользователя. Там, где используются сертификаты, учетная запись может быть активирована сразу по завершении этого связывания между сертификатом и учетной записью пользователя. Это связывание может быть столь же простым, как добавление Идентификатора Сертификата и Выпускающего ЦС к информации учетной записи пользователя или может использовать другую информацию, передаваемую сертификатом, такую как компоненты различительного имени пользователя (см. стандарт ITU X. 509). Информация связывания может передаваться в регистрационной форме или извлекаться непосредственно из сертификата согласно системной политике безопасности ДСЗИ. Проверка соответствия может проводиться всякий раз, когда используется сертификат, для гарантирования того, что описание пользователя в транзакциях сертификата соответствует содержимому данных регистрации. Сертификат пользователя подписывается выпускающим ЦС и его целостность и подлинность подтверждается при помощи сертификата и открытого ключа, выпускаемых ЦС. Коллективный набор компонентов, используемых для идентификации, должен быть доказуемо уникален. По достижении связывания этой учетной записи ДСЗИ и сертификата пользователя, ДСЗИ должен знать только, куда идти для того, чтобы проверить сведения о состоянии сертификата. В централизованных средах ЦС для обеспечения возможности взаимодействия требуются отдельно взятая PKI, перекрестное сертифицирование или создание мостов PKI (сложносоставная система, которая выполняет проверку сведений о состоянии сертификата, в которой продукция множества поставщиков используется многочисленными ЦС). Общепринятый элемент состоит в том, что все сертификаты имеют равное значение. Сертификаты, могущие передавать различные доверительные уровни и приложения в открытой среде, должны иметь возможность различной интерпретации и использования этих доверительных уровней. Эта философия может быть охарактеризована как мы будем строить дороги,которые приведут Вас туда, куда бы Вы хотели. Пользователи проверяются при приеме в члены ЦС при помощи разнообразных критериев (например, проверки кредитоспособности, средства для оплаты, стоимости сертификата). ДСЗИ, наоборот, занимается только известным набором утвержденных ЦС и в пределах этого набора только теми сертификатами, которые связаны с его учетными записями пользователя. Любой другой сертификат будет игнорироваться. Эта философия может быть охарактеризована как единственная из дорог, которая будет открыта Вам, будет той, которая требуется для проведения Вашего бизнеса. Для внесения ДСЗИ в списки членов, пользователи исследуются дважды, один раз - для удовлетворения политики сертификата ЦС, и второй раз - для того, чтобы подтвердить, что для них существует деловая потребность во вхождении в ДСЗИ. Деловые правила, осуществляемые ДСЗИ, могут приспособить сертификаты, которые выпускаются на различных доверительных уровнях. Раскрытие изобретения До настоящего времени, все сведения о состоянии сертификата, передавались службам используя единственное средство сообщения о состоянии сертификата, могут являться CAC, OCSP, LDAP и т.д. Настоящее изобретение отличается тем, что оно допускает возможность взаимодействия с любой ЦС илиPKI для целей извлечения и предоставления сведений о состоянии сертификата. Большей частью, это также уменьшает уверенность относительно возможности длительного соединения в режиме реального-4 007089 времени между системами или ДСЗИ, и элементами, предоставляющими отчеты о состоянии сертификата ЦС, посредством кэширования сведений о состоянии сертификата. В одном аспекте изобретения заявителей, способ обеспечения CKCC для проверки достоверности сертификатов аутентификации, выпущенных соответствующими ЦС, включает в себя этапы: идентификации информации, необходимой для извлечения сведений о состоянии сертификата аутентификации из выпускающего ЦС, который выпускает сертификат аутентификации; конфигурирования соединителя на основе идентифицированной информации для обмена информацией с выпускающим ЦС; обмена информацией с выпускающим ЦС в соответствии с конфигурированным соединителем; и извлечения сведений о состоянии сертификата аутентификации. Выпускающий ЦС и соединитель определяются в списке утвержденных ЦС в запоминающем устройстве конфигурации. Местные дата и время могут подвергаться проверке на предмет того, попадают ли они в диапазон периода действия, обозначенного в периоде действия сертификата аутентификации. Выпускающий ЦС может быть включен в список утвержденных ЦС при помощи проверки и утверждения выпускающего ЦС согласно заранее определенным деловым правилам, и если выпускающий ЦС был проверен и не утвержден, то выпускающий ЦС может обозначаться в списке неутвержденных ЦС в запоминающем устройстве конфигурации. Проверка и утверждение выпускающего ЦС могут включать в себя регистрацию представления доверенного сертификата аутентификации с CKCC и добавление, по меньшей мере, представления, состояния и элемента данных время существования в локальную кэш-память. Затем соединитель конфигурируется для извлечения добавленных сведений о состоянии, когда запрашиваются сведения о состоянии доверенного сертификата аутентификации. Обмен информацией с выпускающим ЦС также может осуществляться в соответствии с последовательностью соединителей. Способ дополнительно может включать в себя проверку локальной кэш-памяти на предмет сведений о состоянии, и если сведения о состоянии найдены в локальной кэш-памяти, а местные дата и время находятся в пределах периода действия, извлечение сведений о состоянии из локальной кэш-памяти. Если сведения о состоянии не найдены в локальной кэш-памяти, или если местные дата и время не находятся в пределах периода действия, CKCC устанавливает сеанс связи с компонентом выпускающего ЦС,предоставляющим отчет о состоянии сертификата, составляет запрос о состоянии сертификата в соответствии с конфигурированным соединителем, извлекает сведения о состоянии из компонента, предоставляющего отчет о состоянии сертификата, закрывает сеанс связи с компонентом, предоставляющим отчет о состоянии сертификата, и добавляет в локальную кэш-память, по меньшей мере, сведения об идентификации, состоянии и времени существования сертификата аутентификации. Сведения о состоянии сертификата могут указываться CAC, и в соответствии с графиком публикации выпускающего ЦС, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации, CKCC очищает кэш-память, связанную с выпускающим ЦС, и CKCC определяет сведения о состоянии сертификата аутентификации изCAC и запоминает сведения о состоянии в кэшпамяти, связанной с выпускающим ЦС. Сведения о состоянии сертификата также могут указываться Дельта Списком Аннулированных Сертификатов (САС), и после уведомления выпускающим ЦС о том, что CAC доступен, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии, сертификата, перечисленного в запоминающем устройстве конфигурации; если CAC является полным CAC, то CKCC очищает кэш-память,связанную с выпускающим ЦС, определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэшпамяти; а если CAC содержит только изменения, случившиеся после публикации полногоCAC, CKCC определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэш-памяти. В другом аспекте изобретения Заявителей, способ извлечения сведений о состоянии сертификата аутентификации, выпущенного выпускающим ЦС в ответ на запрос от ДСЗИ к CKCC для подтверждения сведений о состоянии сертификата аутентификации, включает в себя этапы: определения местонахождения и предоставления отчета о состоянии, если сведения о состоянии присутствуют в кэш-памятиCKCC и являются подлинными; и, в противном случае, выполняют этапы получения типа сведений о состоянии и способа извлечения из запоминающего устройства конфигурации CKCC; если типом сведений о состоянии является CAC, и сведения о состоянии не найдены в кэш-памяти, то предоставляют отчет о состоянии как допустимый; если типом сведений о состоянии не является CAC, то составляют запрос сведений о состоянии сертификата в соответствии с типом сведений о состоянии; устанавливают сеанс связи с выпускающим ЦС; извлекают сведения о состоянии из компонента выпускающего ЦС,предоставляющего отчет о состоянии, используя полученный способ извлечения и завершают сеанс связи; интерпретируют извлеченные сведения о состоянии; привязывают к интерпретируемым извлеченным сведениям о состоянии значение времени существования, представляющего период, определенный политикой CKCC для типа сведений о состоянии; добавляют, по меньшей мере, идентификацию сертификата аутентификации, сведения о состоянии и значение времени существования в кэшпамять; и предоставляют ДСЗИ отчет о состоянии в ответ на запрос. В еще одном аспекте изобретения Заявителей, CKCC для обеспечения точной и своевременной индикации сведений о состоянии сертификатов аутентификации, выпущенных выпускающими ЦС, включает в себя обеспечение сведений о состоянии сертификата аутентификации в качестве показанных CAC,-5 007089 когда выпускающий сертификаты ЦС, использует CAC для индикации сведений о состоянии. В противном случае, обеспечиваются сведения о состоянии, в качестве показанных кэш-памятью, когда кэшпамять включает в себя сведения о состоянии и элемент данных время существования не выходит за определенные пределы. Если элемент данных время существования выходит за определенные пределы, сведения о состоянии стираются из кэшпамяти, и сведения о состоянии запрашиваются и извлекаются при помощи протокола предоставления отчета о состоянии сертификата в режиме реального времени,когда сведения о состоянии не находятся в кэш-памяти. В кэш-память добавляются, по меньшей мере,идентификация сертификата, сведения о состоянии и элемент данных время существования и обеспечивается извлеченное состояние. Элемент данных счетчик использования сведений о состоянии может быть добавлен в кэшпамять и его показания могут увеличиваться или уменьшаться всякий раз, когда проверяются сведения о состоянии сертификата. Если элемент данных счетчик использования сведений о состоянии переходит пороговую величину, то обеспечиваются сведения о состоянии и кэш-память стирается в части сведений о состоянии. Элемент данных последние выбранные сведения о состоянии также может быть добавлен в кэш-память и элемент данных последние выбранные сведения о состоянии вместе с элементом данных счетчик использования сведений о состоянии, предоставляют возможность определения уровня активности сведений о состоянии сертификата. Когда к CKCC осуществляется запрос для извлечения сведений о состоянии нового сертификата, и кэш-память достигает назначенного предела размера буфера, CKCC просматривает кэшпамять на предмет обнаружения элемента данных последние выбранные сведения о состоянии, показывающего самую старую дату и стирает соответствующие входные данные из кэш-памяти; и затем CKCC извлекает требуемые сведения о состоянии, размещает их в кэш-памяти и обеспечивает требуемое состояние. В еще одном аспекте изобретения Заявителей, способ выполнения транзакций между первой стороной и второй стороной, при помощи передачи управления аутентифицированным информационным объектом, имеющим верифицируемый след данных, включает в себя: извлечение из доверенного запоминающего устройства аутентифицированного информационного объекта, который включает в себя первый блок цифровой подписи, имеющий цифровую подпись предъявляющей стороны и первый сертификат аутентификации, устанавливающий отношения, по меньшей мере, идентичности и криптографического ключа к предъявляющей стороне, выполнение извлеченного аутентифицированного информационного объекта второй стороной, при помощи включения в извлеченный аутентифицированный информационный объект блока цифровой подписи второй стороны, и пересылку выполненного извлеченного аутентифицированного информационного объекта к ДСЗИ. ДСЗИ проверяет цифровые подписи и проверяет достоверность сертификатов аутентификации, связанных с цифровыми подписями при помощи, по меньшей мере, извлечения сведений о состоянии сертификатов аутентификации из CKCC. ДСЗИ отклоняет блок цифровой подписи, если соответствующая цифровая подпись не проверена, или срок сведений о состоянии соответствующего сертификата аутентификации истек или они аннулированы, и если, по меньшей мере, один блок подписи в информационном объекте не отклонен, ДСЗИ присоединяет к информационному объекту блок цифровой подписи ДСЗИ и индикатор даты и времени, и от имени первой стороны берет объект под свой контроль. Краткое описание чертежей Различные особенности и преимущества изобретения заявителей станут очевидными, при прочтении этого описания вместе с чертежами, на которых: фиг. 1 иллюстрирует процесс проверки достоверности электронного информационного объекта ДСЗИ, применяющий CKCC; фиг. 2 иллюстрирует фоновую обработку CKCC, посредством чего CAC и CAC добавляются в запоминающее устройство сведений о состоянии сертификата; фиг. 3 иллюстрирует отдельное кэширование проанализированных CAC, ответов OCSP, и сведений о состоянии, выведенных из других способов предоставления отчетов о состоянии сертификата; фиг. 4 иллюстрирует расширяемый синтаксис для блока подписи, содержащего примеры элементов данных, в которых цифровая подпись применяется к фрагментам информационных объектов и присоединенным данным (аутентифицированным атрибутам); фиг. 5 иллюстрирует взаимодействие ДСЗИ с CKCC и извлечение CKCC сведений о состоянии сертификата через Интернет из членских и внешних ЦС; фиг. 6 иллюстрирует процесс регистрации пользователя ДСЗИ, завершающийся этапом проверки состояния сертификата, в котором проверка достоверности цифровой подписи демонстрирует успешную регистрацию; фиг. 7 иллюстрирует процесс регистрации пользователя ДСЗИ, в котором сертификат пользователя выпускает внешний ЦС, завершающийся этапом проверки состояния сертификата, в котором проверка достоверности цифровой подписи демонстрирует успешную регистрацию; и фиг. 8 изображает пример со сдачей в аренду автомобиля, который показывает, каким образом-6 007089 Осуществление изобретения Проверка сведений о состоянии сертификата является критическим элементом в системе или приемке ДСЗИ любого представляемого электронного информационного объекта. Для представления, которое будет принято, состояние сертификата должно быть определено как допустимое. Запрашивание сведений о состоянии сертификата обычно требует, чтобы между ДСЗИ и источником сведений о состоянии сертификата имел место обмен информацией. Частота этого обмена информацией будет расти пропорционально числу представлений ДСЗИ. Проверка сведений о состоянии сертификата может потребоваться в режиме реального времени, и запросы сведений о состоянии могут выполняться при каждом представлении. Однако, сведения о состоянии не могут обновляться в режиме реального времени, как это имеет место с CAC. Все CAC публикуются с определенными интервалами, обычно один или два раза в сутки. Поиск и повторный анализCAC может иметь отрицательное воздействие на производительность системы. Настоящее изобретение значительно уменьшает непосредственные вычислительные и коммуникационные требования, переводя большую часть работы на CKCC. Между ДСЗИ и CKCC осуществляется единственный протокол передачи сведений о состоянии сертификата. Этот протокол передачи сведений о состоянии может иметь атрибуты, подобные IETF OCSP, который предоставляет приложению возможность запросить ЦС на предмет сведений о состоянии единственного сертификата, и таким образом минимизировать обработку служебных сигналов.CKCC обеспечивает и обслуживает достаточную информацию относительно местонахождения,средств связи и обработки сведений о состоянии сертификата для каждого ЦС, с которым он должен взаимодействовать. Поэтому CKCC делает возможной стабилизацию и оптимизацию дизайна приложения. CKCC преимущественно анализирует и кэширует сведения о состоянии сертификата для минимизации времени ответа о состоянии на запрос сведений о состоянии ДСЗИ. Поэтому CKCC устраняет потребность в какой бы то ни было из традиционных форм взаимодействия PKI. Потенциальное восстановление компрометации сильно расширено, так как учетная запись пользователя ДСЗИ может быть легко дезактивирована или при помощи удаления ЦС из списка CKCC утвержденных ЦС, может быть устранен набор пользователей. Использование Сертификатов Аутентификации. После регистрации в ДСЗИ, участника можно попросить дополнительно аутентифицировать себя через использование криптографии открытого ключа и своего сертификата аутентификации. Такая аутентификация может быть связана с установлением защищенного сеанса связи, запросами об услугах ДСЗИ или цифровым подписанием и предъявлением электронного информационного объекта. Прежде, чем кто-нибудь сможет взаимодействовать с ДСЗИ, должны быть выполнены четыре условия: 1) он сначала должен быть зарегистрирован в качестве пользователя системы, 2) он должен быть выпущен и владеть парой открытого ключа и соответствующим ей сертификатом аутентификации, если ему предоставляют более, чем доступ только для чтения, 3) сертификаты должны быть выпущены утвержденным ЦС, и 4) сертификат пользователя не должен быть с истекшим сроком действия, или быть известным в качестве бездействующего или аннулированного. Это последнее условие обычно требует,чтобы ДСЗИ непосредственно запрашивало выпускающий ЦС на предмет извлечения сведений о состоянии сертификата. Поскольку существует широкое разнообразие стандартов и вариантов осуществления ЦС для предоставления отчета о состоянии сертификата, это представляет собой нелегкую или непростую задачу. Как заявлено в разделе Уровень Техники в случае, когда вовлечено множество ЦС или PKI,обычно требуются некоторые формы возможностей взаимодействия PKI. Настоящее изобретение устраняет эту потребность, создавая Службу Контроля за Состоянием Сертификатов. Перекрестное сертифицирование ЦС или создание мостов не нужны, поскольку единственным знанием, необходимым дляCKCC является список утвержденных выпускающих ЦС, их IP-адресов или чего-либо подобного, и их средств предоставления отчетов о состоянии сертификатов. Для извлечения сведений о состоянии сертификата, соединитель или программный модуль определены для каждого способа обеспечения сведений о состоянии сертификата. Каждый сертификат аутентификации содержит и поле субъект (пользователь), и поле выпускающий (ЦС). Поле выпускающий используется для непосредственного запроса ДСЗИ к CKCC, который в таком случае проверяет свою кэш-память на предмет наличия сведений о состоянии сертификата. Если сведения о состоянии присутствуют в кэш-памяти CKCC, он возвращается к ДСЗИ. Если сведения о состоянии отсутствуют,CKCC, активизирует соответствующий соединитель для отыскания сведений о состоянии сертификата. Будет использоваться любое число способов для предоставления отчетов и отыскания сведений о состоянии сертификата: LDAP, OCSP, CAC и т.д. Для выполнения любого действия ДСЗИ, пользователь должен сначала зарегистрироваться в ДСЗИ. Будучи единожды успешно зарегистрированным, пользователь может создавать или выбирать транзакцию, если ему предоставлены такие полномочия. Если он имеет полномочия представлять электронные информационные объекты, он теперь может их осуществить. При получении электронного информационного объекта, ДСЗИ выполняет необходимые этапы проверки достоверности цифровой подписи. За-7 007089 прос сведений о состоянии сертификата будет составлен и отправлен к CKCC. Если возвращены допустимые сведения о состоянии, ДСЗИ примет и будет хранить представление в качестве аутентичной копии, в противном случае это будет отклонено. Обработка Цифровой Подписи и Проверка Сведений о Состоянии Сертификата. Цифровые подписи могут быть применены к одному или более фрагментам или полному содержимому информационного объекта. Цифровые подписи могут принадлежать сторонам транзакции или агентам, которые дают транзакции возможность достигнуть положения или состояния в контексте делового процесса. Цифровые подписи фактически могут быть применены к дополнительной информации,касающейся выполняемой задачи. Одним таким примером могла бы служить запись окружного регистратора по делам собственности. Другим примером может быть применение подписи стороны, удостоверяющей подлинность информационных объектов, представляемых для ДСЗИ. В этом последнем примере, представляющий, как указано, заворачивает или запечатывает информационный объект, в котором цифровая подпись применена ко всему содержимому, предотвращая какие бы то ни было последующие изменения. Всякий раз, когда применяется цифровая подпись, подписывающее лицо будет запрошено на предмет подтверждения его намерения, быть ответственным за его цифровую подпись. Это действие, которое требуется в соответствии с последним законодательством, может принять форму читаемого текста в окне дисплея или начального экрана (заставки), и может требовать вызова графической кнопки и/или обращения для регистрации к криптографическому маркеру, который является также криптографическим ключом и запоминающим устройством сертификата. Фактическая демонстрация упомянутой готовности к совершению через использование доверенного приложения, которое вычисляет цифровую подпись пользователя при помощи выбранного содержимого, и объединяет ее с его сертификатом аутентификации в форме блока подписи. Блок подписи также может содержать аутентифицированные и не аутентифицированные элементы данных. Аутентифицированные элементы данных включаются в вычисление цифровой подписи (например, местных даты и времени) и могут рассматриваться в качестве защищенных цифровой подписью (целостных). Не аутентифицированные элементы данных добавляются после вычисления подписи и не являются защищенными. Фиг. 4 показывает образец синтаксиса, который содержит элементы данных и размещение блока подписи. Этот пример не должен интерпретироваться буквально, поскольку он предназначен только для того, чтобы служить иллюстративным примером. Информационный объект и любые блоки подписей преимущественно могут помещаться в упаковку(S/MIME) или в тэги в расширяемом информационном синтаксисе (XML, HTML, XHTML) для удобства манипулирования и облегчения обработки информации. Эту структуру данных затем посылают к ДСЗИ для проверки достоверности. Наоборот, блок(и) подписей можно независимо посылать к ДСЗИ, которая будет являться принадлежностью фактической исходной записи, и которая никогда не оставит ДСЗИ. В последнем случае, достоверность каждого блока подписи проверяется отдельно. Процесс для проверки достоверности цифровой подписи во время представления отличается от выполняемого впоследствии. Четырехступенчатая проверка достоверности выполняется в первый раз, когда ДСЗИ осматривает цифровую подпись: 1) проверяют цифровую подпись, процесс, который доказывает,что содержимое, защищенное цифровой подписью, не было изменено во время передачи; 2) осуществляют проверку того, что текущее время ДСЗИ попадает в допустимый период действия сертификата аутентификации индивидуума (не раньше, не позже); 3) запрашивают и извлекают сведения о состоянии сертификата из выпускающего ЦС, пункта распределения CAC, или другого утвержденного источника сведений о состоянии сертификата, используя локально назначенную CKCC; 4) подтверждают, что информация учетной записи пользователя ДСЗИ сходится с той, которая передана в сертификате, и что запрашиваемое действие авторизовано в базе данных правил ДСЗИ. Для предъявляющего информационный объект, в процесс добавляют один дополнительный этап. На этом пятом этапе проверяют, что идентичность предъявителя совпадает с идентичностью стороны, которая установила текущий сеанс связи с ДСЗИ. Если все испытания проходят успешно, действие позволяется и/или информационный объект принимается и удерживается ДСЗИ от имени его владельца. Если какой бы то ни было этап является неудачным, инициируются средства защиты. После этой начальной проверки сведений о состоянии сертификата, доверительная среда ДСЗИ поддерживает подлинность и целостность всех удерживаемых информационных объектов. Не ожидается,что будет необходима какая бы то ни было дополнительная проверка сведений о состоянии сертификата,пока не представлена новая версия документа. Два аспекта этого изобретения отличаются от нормального хода реализации PKI. Первый состоит в том, что это изобретение базируется на существовании приложения, а именно - ДСЗИ (или любого приложения/системы, требуемых для проверки достоверности сведений о состоянии сертификата), и его возможностях создавать и обслуживать электронные исходные записи. Второй состоит в том, что выпускающий ЦС требует идентифицирования только в качестве исполнителя политики, управляющей доверительной средой, и что ни перекрестная сертификация ЦС, ни мостовое соединение PKI не требуются. Необходимым обоснованием для включения выпускающего ЦС являются задокументированные деловые отношения. Во время процесса регистрации ДСЗИ, создается учетная запись пользователя, ко-8 007089 торая приводит в качестве ссылки определенную информацию сертификата пользователя, что в действительности связывает учетную запись пользователя с сертификатом аутентификации пользователя. Использование ДСЗИ. Обычно, как только организация соглашается использовать услуги ДСЗИ, агентам этой организации предоставляют управление доступом к этим транзакциям организации. Агенты организации в таком случае идентифицируют набор индивидуумов, которым они предоставят право выполнять выбранные действия в отношении транзакций организации. Все действия требуют, чтобы пользователь имел учетную запись с ДСЗИ, чтобы учетная запись была активирована, и чтобы пользователь имел идентичность для входа в систему и был способен обеспечивать соответствующий пароль или ответ на фразу - запрос. Кроме того, каждая транзакция, которая составлена из набора различных версий электронных исходных записей, имеет набор полномочий, которые управляют доступом пользователя на различных этапах делового процесса. Это выражается в предоставлении и лишении прав на совершение транзакций записей как действий транзакций, несмотря на нормальный ход дел, то есть начало через постоянное хранение или разрушение. Если разрешено, только подключение к ДСЗИ, обязанному рассматривать электронную исходную запись. Однако, любое действие уровня систем либо ввод, либо замена электронной исходной записи, требуют от индивидуума или дополнительно аутентифицировать себя при помощи криптографии открытого ключа, или при помощи применения своих цифровой подписи и сертификата аутентификации. Во всех случаях идентичность индивидуума должна быть подтверждена. Там, где используются цифровые подписи, это влечет за собой следующее: 1) пользователь имеет соответствующие права доступа, 2) декодирование цифровой подписи и проверку достоверности содержимого, по которой основные случайные данные или сборники сообщений, которые были применены, не были изменены, 3) проверку того, что время представления попадает в пределы периода действия сертификата, и 4) проверку того, что сертификат пользователя все еще действителен. Проверка сведений о состоянии сертификата требует, чтобы были запрошены выпускающий ЦС или ответчик сведений о состоянии сертификата. Так как этот этап должен предприниматься каждым аутентифицированным действием или представлением электронной исходной записи, пропускная способность канала связи может стать исчерпанной, и потенциально могут иметь место задержки, отставания и отклонения из-за оставшихся без ответа или задержавшихся ответов о состоянии. Настоящее изобретение обращено к этим и другим высоко гарантированным аспектам функционирования ДСЗИ и обеспечения достоверности всех сторон, взаимодействующих с ДСЗИ. В высоко гарантированной среде, в которой эксплуатируется ДСЗИ, проверка сведений о состоянии сертификата необходима только тогда, когда обслуживание запрашивается правомочным пользователем. Для информационных объектов, сведения о состоянии сертификата нуждаются в проверке только во время представления. Если все цифровые подписи определены как допустимые, впоследствии информационный объект считают аутентичным. Защита и процедурные практики и способы размещены в ДСЗИ для предотвращения злонамеренных действий и отказов оборудования, которые имеют своим результатом несанкционированные изменение или потерю документа. Каждое представление завершается созданием новой версии электронной исходной записи. ДСЗИ загружена обслуживанием знаний, относительно которого версия исходной записи является последней. Эта версия может быть идентифицирована в качестве электронного оригинала и как пригодная для передачи запись. ДСЗИ демонстрирует свое предположение об управлении оригинальной исходной записью, добавляя достоверную отметку времени и даты к исходной записи, и затем применяя эту цифровую подпись и добавляя свой сертификат. Упаковка может быть применена к исходной записи ввиду целесообразности обработки и защиты. Хотя этот процесс управления версиями создает автономный аутентифицированный след данных и защиту, для подтверждения достоверности обслуживаются отдельные резервные контрольные записи.CKCC заявителей преодолевает описанные ограничения, которые в настоящее время продолжают существовать с PKI и электронной коммерцией (e-commerce). Исходная информация, требуемая для получения от члена ЦС сведений о состоянии сертификата, регистрируется CKCC, сразу после их создания. Исходная информация для внешних утвержденных ЦС может быть введена во время процесса регистрации пользователя. Поисковая информация CKCC требуется для каждого источника сведений о состоянии сертификата. Существуют несколько типов источников сведений о состоянии сертификата, и CKCC обязана иметь соединитель или способ для каждого зарегистрированного типа. Одним способом, используемым некоторыми ЦС для передачи сведений о состоянии сертификата,является CAC, который включает в себя: список аннулированных сертификатов и причины для их аннулирования, информацию о выпускающем CAC, и о том, когда был выпущен CAC и когда будет выпущена следующая версия CAC. Каждый CAC подписывается выпускающим ЦС или назначенным подписывающим лицом, гарантирующим его целостность и подлинность. Сертификаты будут удалены из CAC сразу, как только их период действия будет превышен. Там где используются CAC, CKCC извлекает последнюю интерпретацию CAC из пункта распределения ЦС, например, профиль X. 509 v2 CAC (IETF RFC2459, январь 99), подтверждает его подпись,анализирует ее, и создает кэш-память для хранения результатов. CKCC использует интервал публикацииCAC, осуществляемой ЦС, для управления при выполнении следующей загрузки CAC. Каждый CAC-9 007089 содержит поле достоверности, которое обычно устанавливается для предоставления возможности некоторой отсрочки при выполнении загрузки. Таким образом учитывается перегруженность канала связи и время простоя ЦС, и CKCC вынуждается требовать устранения недостатков, если этот интервал превышен. Такое устранение недостатков может включать в себя повторную проверку достоверности любых представлений, которые связаны с недавно добавленным аннулированным сертификатом. Каждый новыйCAC заменяет собой предварительно загруженный CAC. Исключение к этому правилу предоставляется для дельта - CAC обработки. Содержимое дельта - CAC присоединяется к текущему содержимому кэшпамяти. Дельта CAC BaseCRLNumber относится к самому последнему полному выпущенному CAC. Дельта CAC публикуются с более короткими интервалами (минуты, часы), и только тогда, когда аннулирование сертификата произошло непосредственно после последнего полного CAC. CKCC несет ответственность за отыскание CAC и дельта CAC, основанного на интервале публикации или уведомлении, и не превыше его интервала, установленного в политике безопасности ДСЗИ. Вторым способом, используемым ЦС для распределения сведений о состоянии сертификата, является OCSP. Там где используется OCSP, CKCC запрашивает ответчика OCSP в тех, случаях когда запрашивается состояние сертификата. Ответы OCSP подписываются для гарантирования их целостности и подлинности. CKCC анализирует ответ OCSP и добавляет детали сертификата и сведения о состоянии в другую кэш-память. Признак времени существования, определяемый локальной политикой безопасности ДСЗИ, включен и определяет, когда введенные данные будут удалены из кэш-памяти. Эта функция направлена на уменьшение обмена служебными сигналами, когда одной и той же стороной/объектом на коротком интервале загружаются в ДСЗИ несколько информационных объектов. Признак времени существования обычно бывает значительно короче (например, 5 мин), чем нормальный интервал публикацииCAC (дважды в сутки, ежедневно). CKCC может заново проверять сведения о состоянии сертификата,если было обработано более одного информационного объекта, до вычищения сведений о состоянии сертификата из кэшпамяти для гарантирования того, что аннулирование сертификата не произошло. Если аннулирование сертификата произошло во время интервала времени существования, то пункт организации владельца контакта должен быть уведомлен. Существует несколько других способов запроса, но они для краткости не будут описаны. Понятно, что при использовании каждый из них будет требовать соединителя и потенциально отдельную кэш-память. Фиг. 1 показывает последовательность операций для создания электронного оригинала. Для целей описания, информационный объект выдуман в виде договора купли-продажи. Копия электронного информационного объекта (неоформленная) извлекается из ДСЗИ или из системы подготовки документов,и цифровым образом или голографически (рукописно) подписывается соответствующими сторонами. Наблюдая за процессом выполнения, агент владельца использует доверенное приложение для цифрового подписания и упаковывания информационного объекта и отправки его к ДСЗИ. Имея предварительно созданный, выполненный или извлеченный электронный документ, предъявляющий цифровым образом подписывает и представляет его ДСЗИ как например на этапе 101. В этом процессе электронной подписи (eSeal), формируется упаковка, которая содержит подписанное содержимое и блок(и) цифровой подписи, которые дополнительно содержат цифровую подпись(и) и сертификаты предъявляющего и любого другого подписавшегося. Существуют пять процессов, представленных на Фиг. 1: (1) действие, когда недействительная цифровая подпись(и) и/или аннулированный сертификат(ы) найдены, (2) проверка сведений о состоянии сертификата, причем сведения о состоянии локально кэшируются, (3) проверка сведений о состоянии сертификата, причем сведения о состоянии сертификата должны быть извлечены, (4) CAC извлекает и обрабатывает, и (5) создание электронного оригинала(eOriginal), когда подписанный цифровым образом документ определен быть подлинным. На этапе 103 ДСЗИ принимает подписанный цифровым образом электронный документ. На этапе 105 ДСЗИ подтверждает, что предъявляющий имеет полномочия для добавления электронного документа к выбранной учетной записи и/или транзакции. На этапе 107 ДСЗИ криптографическим способом проверяет любые цифровые подписи, включенные в упакованный электронным образом цифровой электронный документ. Открытый ключ, найденный в сертификате аутентификации X. 509 подписывающей стороны, используется во время процесса проверки. На этапе 109 сведения о периоде действия сертификата извлекаются из сертификата аутентификации подписывающей стороны, и на этапе 111 период действия проверяется по отношению к текущим дате и времени. Если любое из вышеупомянутых испытаний оканчивается неудачно, представление отклоняется на этапе 113, и уведомление об отрицательном результате может быть послано на этапе 114. Действие записывается в журнал на этапе 117. Если все испытания проходят успешно, то сведения о состоянии сертификата для каждого сертификата, содержащегося в пределах упаковки, запрашивают у CKCC на этапе 119. На этапах 121 и 123 сведения о состоянии сертификата визуально контролируются, если они присутствуют в запоминающем устройстве сведений о состоянии сертификата. На этапе 125, сведения о состоянии сертификата извлекают, и достоверность сертификата проверяют на этапе 127. Если какой бы то ни было сертификат найден недействительным по любой причине, представление отклоняется на этапе 113, уведомление об отрицательном результате может быть послано на этапе 115, и действие регистрируется на этапе 117. Предъявляющий, как ожидается, будет искать средство для устранения недостатков.- 10007089 Если на этапе 127 все цифровые подписи и сертификаты определены в качестве допустимых для представления, то на этапе 129 ДСЗИ применяет другую упаковку, которая включает в себя отметку времени и даты и блок цифровой подписи ДСЗИ. В таком случае, ДСЗИ берет на себя управление представлением в качестве электронной исходной записи от имени владельца записи. На этапе 131 ДСЗИ размещает электронный оригинал в защищенном постоянном запоминающем устройстве, на этапе 133 ДСЗИ посылает уведомление о положительном результате, и на этапе 117 ДСЗИ регистрирует в журнале только что завершенные действия. Если на этапе 123 определено, что сведения о состоянии сертификата не присутствуют в запоминающем устройстве сведений о состоянии сертификата, то CKCC на этапе 135 отыскивает поле выпускающего ЦС в проверяемом сертификате. На этапе 137, CKCC визуально контролирует, что выпускающий ЦС находится в списке утвержденных ЦС, который на этапе 139 может обслуживаться и быть доступным для Запоминающего Устройства Соединителя ЦС. Если ЦС не в списке, то недействительные сведения о состоянии возвращаются, процесс возобновляется на этапе 125 и проходит через этапы 127,113, 115 и 117, завершаясь отклонением представления и передачей уведомления об отрицательном результате и регистрацией в журнале. Если выпускающий ЦС найден в списке утвержденных ЦС на этапе 137, и на этапе 141 определено, что механизмом предоставления отчета о состоянии сертификата является CAC, то указатель допустимости сведений о состоянии возвращается на этап 125. Если ЦС известен, и сведения о состоянии отсутствуют для подчиненного сертификата, но механизмом предоставления отчета о состоянии является CAC, то может предполагаться, что сведения о состоянии сертификата допустимы, обеспечивая существование CAC и подлинности для ЦС. Процесс в таком случае продолжается через этапы 127, 129, 131, 133 и 117, завершаясь созданием электронного оригинала, передачей уведомления о положительном результате, и регистрацией только что завершенных действий в журнале. Если на этапе 141 определено, что механизмом предоставления отчета о состоянии сертификата не является CAC, то информация соединителя, полученная на этапе 137, используется для запрашивания сведений о механизме предоставления отчета о состоянии сертификата. Содержащаяся в описании соединителя вся информация о конфигурации необходима для запрашивания соответствующего запоминающего устройства сведений о состоянии сертификата, которое может представлять собой ЦС, каталог или запоминающее устройство сведений о состоянии сертификата любого другого типа. Запоминающие устройства сведений о состоянии, связанные с этапами 145, 147, 149 и 151 (то есть, соответственно с каталогом LDAP, ответчиком OCSP, базой данных и сервером) представляют собой примеры таких запоминающих устройств. В ответ на запрос, осуществляемый на этапе 143, один из них отвечает информацией о состоянии сертификата, и сведения о состоянии на этапе 153 добавляются в запоминающее устройство сведений о состоянии сертификата. После добавления на этапе 153, процесс в запоминающем устройстве сведений о состоянии сертификата, возобновляется на этапе 121 и продолжается через этапы 123, 125 и 127 к заключению, где представление или принимается (этапы 129, 131, 133, 117), или отклоняется (этапы 113, 115, 117).CAC публикуются на этапе 155 через заранее определенные интервалы и на этапе 157 как требуется, когда предоставляют отчет о заподозренной компрометации, и политика требует немедленного ответа. Этот процесс дополнительно описан на фиг. 2. Если ЦС известен, и сведения о состоянии не присутствуют, и механизм предоставления отчета о состоянии является отличным от CAC, Служба Контроля за Состоянием Сертификатов выбирает соединитель и запрашивает механизм предоставления отчета о состоянии сертификата (этап 143). Соединитель содержит необходимую информацию, которая осуществляет поиск сведений о состоянии и возможную интерпретацию. Любой из источников сведений о состоянии сертификата, работающих в режиме реального времени, изображенных на этапах 145-151, ответит на запрос сведений о состоянии сертификата сведениями о текущем состоянии, но этот процесс не ограничен только этими источниками. Сведения о состоянии принимаются и на этапе 153 добавляются в Запоминающее Устройство Сведений о Состоянии Сертификата. Когда сведения о состоянии добавлены, генерируется ответ, и действие возвращается на этап 123, с возобновлением обработки сведений о состоянии на этапе 125 и завершением, как описано ранее. Обратимся теперь к фиг. 2, на которой CKCC выполняет поиск CAC в качестве фонового процесса.CAC содержит список всех аннулированных или приостановленных до тех пор сертификатов, пока текущие дата и время находятся вне периода действия, содержащегося в сертификате. Приостановленные сертификаты обрабатываются так, как будто они аннулированы, но они могут быть восстановлены, что будет иметь результатом их удаление из CAC. Аннулированные сертификаты не могут быть восстановлены. На этапе 155, Администратор ЦС конфигурирует ЦС для публикации CAC через заранее определенные интервалы. На этапе 157 Администратор ЦС также может опубликовать Дельта CAC, как диктуется локальным сертификатом или политикой безопасности. Администратор ЦС или ЦС поместят в публикацию Дельта CAC уведомление. Дельта CAC может быть произведен всякий раз, когда сертификат аннулируется или приостанавливается во время интервала между публикациями полных CAC. ДельтаCAC могут содержать полный список аннулированных CAC. На этапе 201, CAC и Дельта CAC публику- 11007089 ются в запоминающем устройстве или каталоге CAC. На этапе 203, CKCC отыскивает график публикации CAC или уведомления Дельта CAC, и этап 205 изображает таймер, используемый для намеченного поиска. Таймер также предоставляет возможность поиска, основанного на поле следующее обновление, содержащемся во всех CAC. На этапе 207, CAC или Дельта CAC извлекаются из запоминающего устройства CAC. На этапе 209, CAC или Дельта CAC подвергаются анализу до добавления на этапе 153 в соответствующую кэш-память или список в Запоминающем Устройстве Сведений о Состоянии Сертификата на этапе 121 или в каталог, основанного на установленном графике, либо после уведомления. Анализ CAC предоставляет возможность более простого управления и уменьшения объема служебных сигналов во входных данных поиска CAC. Этапы 119, 123,125, 135, 137 и 141 CKCC для полноты проиллюстрированы на фиг. 2, и осуществляются как описано в связи с фиг. 1. Обратимся теперь к фиг. 3, на которой Запоминающее Устройство Сведений о Состоянии Сертификата содержит множество блоков кэш-памяти, которые содержат сведения о состоянии сертификата от различных механизмов предоставления отчетов. Блоки кэш-памяти (пять из которых изображены на фиг. 3) могут отображать индивидуальные ЦС (блоки кэш-памяти 301, 303) или совокупности ЦС (блоки кэшпамяти 307, 309). Для предоставления отчетов о состоянии в режиме реального времени, сведения о состоянии остаются в кэш-памяти до тех пор, пока не потребуется место (например, наименее часто использующиеся) или на основе требований политики (например, содержатся только в течение указанного временного интервала). Сведения о состоянии обычно очищаются сразу по превышении критерия. Назначение блоков кэш-памяти состоит в том, чтобы хранить сведения о состоянии сертификата для политики, диктующей продолжительность периода, уменьшая таким образом обмен служебными сигналами, требующийся во время отыскания сведений о состоянии сертификата и CAC. Поэтому CKCC может соединять перерывы из-за нарушения связи.CAC могут подвергаться анализу, и сведения о состоянии индивидуальных аннулированных сертификатов, помещаемые в кэш-память для уменьшения служебных вычислений, получаются, когда CAC должен быть повторно проверен. Это изображено блоками кэш-памяти 305, 307. Содержимое кэшпамяти заменяется всякий раз, когда извлекается новый полный CAC. Обратимся теперь к фиг. 4, на которой показан пример синтаксической структуры, представляющей некоторые из наиболее важных элементов данных, которые должны быть включены в блок цифровой подписи. Фиг. 4 представляет собой пример свободной формы элементов данных, которые составляют цифровую подпись, где подпись применяется к множеству фрагментов сообщения и отметке даты/времени. Этот пример предназначен для того, чтобы служить иллюстрацией синтаксиса, который может использоваться для блока цифровой подписи. Может быть отмечено, что элемент данных CumulativeHashValue применяется к Значению Хеш-функции одного или более фрагментов или к полному содержимому и к любым Аутентифицированным Данным. Фиг. 5 изображает защищенную архитектуру связи, показывая функциональные блоки, которые обеспечивают Службу Контроля за Состоянием Сертификатов. Фигура показывает взаимодействие между тремя ЦС, CKCC и ДСЗИ. CKCC предпочтительно локально размещают в ДСЗИ для гарантирования высокой доступности. Ее главное назначение состоит в обеспечении ДСЗИ обычным интерфейсом и гарантировании защищенного и своевременного снабжения информацией о состоянии сертификата. Его дополнительное назначение состоит в обеспечении гарантированного уровня или качества обслуживания управляющей системой связи и служебных вычислений, требуемых при обслуживании информации о состоянии сертификата. Как видно на фиг. 5, сервер CKCC и ДСЗИ, с соответствующим маршрутизатором связи и концентратором, преимущественно размещаются за коммуникационным брандмауэром. Маршрутизатор и концентратор непосредственно информируют CKCC и ДСЗИ по обстановке. Часть этой информации включает представления электронных подписей, которые, как описано выше, направляются к ДСЗИ через сеть, такую как Интернет, от Клиентского Приложения Пользователя. Также изображены CKCC и связь ДСЗИ через OCSP. Фиг. 5 также изображает три ЦС в различных обычных средах за соответствующими коммуникационными брандмауэрами. ЦС Предприятия может содержать в себе сервер, который служит средством связи с ЦС Лизингового Предприятия, обведенного штриховыми линиями. Внешний PKI или Ответчик могут включать в себя сервер, который служит средством связи с объектами, такими как PKI, ЦС и ответчиком о состоянии сертификата. Иерархический Член PKI может включать в себя сервер, который служит средством связи с объектами, такими как V3 LDAP для CAC и сведений о состоянии сертификата, Корневой ЦС, и ЦС для ипотеки и лизинговой индустрии, для кредиторов, заключительных агентов, и страховщиков прав на имущество. Фиг. 6 и 7 изображают использование Службы Контроля за Состоянием Сертификатов во время процесса регистрации пользователя (абонент и объект) как для члена ЦС, так и для внешних ЦС соответственно. ЦС члена - это то, что является доверенным для выпуска сертификатов пользователя. Внешние ЦС управляются внешними объектами и нуждаются в утверждении до того, как их сертификаты будут использованы вместе с действиями ДСЗИ. Авторизация идентичности пользователя требует неукосни- 12007089 тельного проведения в жизнь всеми ЦС или делегирования агентам организации. Дополнительное требование состоит в том, что сертификат пользователя должен быть непосредственно связан или авторизован для использования с одной или более учетными записями подписавших организаций прежде, чем ДСЗИ может предоставить этому пользователю доступ. Как только это будет достигнуто, ДСЗИ примет цифровую подпись пользователя и положится на CKCC для проверки достоверности сведений о состоянии сертификата. На фиг. 6, процесс регистрации ДСЗИ начинается на этапе 601 с получения администратором/агентом организации от поручителя информации о регистрации пользователя. На этапе 603, этот администратор/агент отвечает за проверку достоверности полномочий поручителя, осуществляя запрос. Поручителям обычно предоставляют управление только над их учетными записями. На этапе 605, администратор/агент регистрирует пользователя с ДСЗИ, налаживая учетную запись пользователя. На этапе 607, администратор/агент в таком случае может назначить пользователю транзакционные привилегии. Транзакционные привилегии могут включать в себя способности к предъявлению, созданию версий, передаче и т.д. электронных оригиналов и других исходных записей. На этапе 609, инициализируется криптографический маркер (механизм цифровой подписи), и на этапе 611 пара открытого ключа генерируется в маркере. На этапе 613 создается запрос сертификата, и на этапе 615 запрос посылают к ЦС организации. На этапе 617 сертификат извлекают и помещают в маркер. На этапе 619, сертификат связывают или ассоциируют с учетной записью ДСЗИ пользователя. На этапе 621, проверяют достоверность идентичности пользователя, например, представляясь администратору/агенту организации персоной, которая может лично поручиться за идентичность пользователя. Обычно требовались бы по меньшей мере две формы идентификации. Так как участие пользователя подтверждается поручителем, оно должно быть достаточно за исключением высокоценных транзакций,при которых кто-то знающий администратора/агента может попросить их поручиться за идентичность пользователя. На этапе 623, пользователя просят подписать контракт соглашения, посредством чего пользователь соглашается, что использование цифровой подписи пользователя является обязывающим. На этапе 625, пользователю предоставляют прикладное руководство пользователя и инструкцию, которую считают необходимой. На этапах 627 и 629, пользователя обеспечивают идентификаторами входа в систему, временными паролями и криптографическим маркером. На этапе 631, пользователь регистрируется в системе, и на этапе 633 представляет ДСЗИ пробный документ. На этапе 635 ДСЗИ проверяет достоверность цифровой подписи и сертификата пользователя. На этапе 637 ДСЗИ запрашивает CKCC о состоянии сертификата. На этапе 639 ДСЗИ принимает сведения о состоянии, и следовательно, продолжает функционировать. Если полученные сведения о состоянии сертификата допустимы, регистрация завершается на этапе 641 и пользователь способен получать доступ к ДСЗИ и использовать ее. Если сведения о состоянии сертификата недопустимы, регистрация завершается на этапе 643, и администратор/агент определяет причину ошибки и назначает средства для устранения недостатков, которые могут привести к повторению некоторых или всех обрисованных выше этапов процесса регистрации. Надежный процесс, начерченный на фиг. 6 гарантирует, что по его завершении регистрируемый участник является полностью уполномоченным. На фиг. 7, пользователю предоставляют возможность использования криптографического маркера,предварительно выпущенного внешней ЦС, если выполняются продиктованные политикой условия. Как описано выше, следуют этапы регистрации 601-607. Проверка идентичности пользователя и этапы контракта 621-627 также следуют, как описано выше. Так как пользователь уже имеет маркер, процесс отклоняется от описанного на фиг. 6. На этапе 701,пользователь помещает маркер в совместимое с ним считывающее устройство и начинает работу. На этапе 703 приложение администратора извлекает сертификат пользователя из маркера. На этапе 705 отображается информация сертификата и принимается информация идентификации выпускающего ЦС. Информация ЦС используется на этапе 707 для проверки того, что ЦС находится в утвержденном списке. Если ЦС не находится в утвержденном списке, то на этапе 709 информацией ЦС снабжают администратора ДСЗИ, и администратор проверяет Орган Управления Политиками Приложений на этапе 711 для разрешения продолжить регистрацию. Только Орган Управления Политиками Приложений может разрешить добавление внешнего ЦС в утвержденный список. Если на этапе 713 разрешение было отклонено, регистрация завершается на этапе 649, предоставляя пользователю три опции. Первая запрашивает и использует маркер, выпускаемый членской ЦС. Другая опция запрашивает просмотр отклоняющих решений ЦС. Третья опция запрашивает имена предварительно утвержденных внешних ЦС. Если Выпускающий ЦС является утвержденным, но не в списке на этапе 713, администратор на этапе 715 добавляет ЦС и информацию соединителя к утвержденному списку, конфигурируя CKCC для извлечения из ЦС сведений о состоянии сертификата. На этапе 619, сертификат пользователя связывается или ассоциируется с недавно созданной учетной записью пользователя. Как показано на фиг. 6 и на этапах 631 - 639, пользователя приглашают осуществить пробное представление к ДСЗИ для подтверждения того, что учетная запись была установлена правильно и того, что пользователь может получать доступ к ДСЗИ. Если CKCC возвращает допустимую- 13007089 информацию о состоянии, то регистрация завершается на этапе 641. Если CKCC возвращает недействительные сведения о состоянии, то администратор определяет причину ошибки и назначает средства для устранения недостатков, которые могут привести к повторению некоторых или всех описанных выше этапов процесса регистрации. Наиболее вероятная причина отказа может относиться к способностиCKCC устанавливать контакт и правильно извлекать сведения о состоянии сертификата из внешней ЦС.CKCC играет важную роль при проверке того, что как сертификат пользователя, так и выпускающий ЦС, имеют санкцию на доступ к ДСЗИ или другой системе. Если выпускающий ЦС удален из утвержденного списка и относящиеся к нему данные конфигурации соединителя также удалены, всем ассоциированным пользователям отказывают в дополнительном доступе к ДСЗИ. Следует понимать, чтоCKCC может работать с другими приложениями и системами, требующими сведений о состоянии сертификата, в том числе и с теми приложениями и системами, которые требуют взаимодействия с множеством PKI и ЦС. Например, другое использование CKCC должно снабдить сведениями о состоянии доверенные сертификаты аутентификации, в том числе самоподписываемые сертификаты, в которых существует соглашение между ищущим услуги клиентом и оператором приложения. Отображение доверенного сертификата (например, РЕМ, идентификатор сертификата, прикладная цифровая подпись) подвергается кэшированию CKCC, и сведения о состоянии запрашиваются при помощи соединителя доверенного сертификата. Таким образом приложению предоставляется возможность иметь отдельные средства информирования о состоянии сертификата, независимо от того, является ли сертификат самоподписываемым или выпущенным ЦС. Этот способ доверенного сертификата может использоваться там, где небольшое количество управляемых сертификатов используется сообществом скорее, чем запрашивание одного или нескольких ЦС сообщества. Таким образом будет оценено, что термины ЦС и выпускающий ЦС,как используется в этой заявке, охватывают такие общепринятые выпускающие самоподписываемые сертификаты, а также обычные ЦС. Кроме того, CKCC может использовать комбинацию соединителей для отыскания сведений о состоянии сертификата. По меньшей мере один соединитель может быть виртуальным, таким как только что описанный для использования с доверенными сертификатами. CKCC активизирует соединители в заранее определенной, например, упорядоченной, последовательности до тех пор, пока сведения о состоянии сертификата не будут приобретены. Этот способ допускает создание иерархии источников сведений о состоянии (например, от наиболее доверенных - к наименее доверенным). Фиг. 8 изображает пример со сдачей в аренду автомобиля, который показывает, каким образомCKCC может использоваться в электронной коммерции. Агенту по продаже автомобилей или представителю агента, которого в будущем для простоты называют дилером, Автомобильным ЦС, который изображен в виде компьютера, был выдан соответствующий сертификат аутентификации. Арендатору автомобиля, который мог присутствовать в агентстве по продаже автомобилей, Банковским ЦС был выдан соответствующий сертификат аутентификации. Удаленному арендодателю Финансовым ЦС был выдан соответствующий сертификат аутентификации. Альтернативно, либо арендатором или арендодателем,мог быть создан самоподписываемый сертификат, который дилер зарегистрировал заявкой на аренду иCKCC, например, потому что арендатор является постоянным покупателем дилера. Как раскрыто в этой заявке, CKCC извлекает и предоставляет отчет о состоянии для этих и других сертификатов, используя любые средства предоставления отчетов о состоянии сертификата, которые используют утвержденный протокол предоставления отчетов о состоянии. На фиг. 8 предполагается, что Автомобильный ЦС и Финансовый ЦС используют OCSP, что Банковский ЦС использует CAC, и что дилер и арендаторы имеют некоторые формы маркера (например, PKCS11, PKCS12, запоминающее устройство ключей браузера и т.д.), которые содержат их сертификаты и криптографические средства подписания. Очевидно, что фиг. 8 представляет собой только образец выполнения транзакции; большее или меньшее количество ЦС по мере надобности может быть связано с обменом информацией, по мере надобности для конкретной транзакции. На этапе 801, дилер либо создает договор аренды, либо извлекает его из заявки на аренду, такой как компьютерная программа, выполняющаяся локально в местном представительстве или удаленно на удаленном сайте, например, на Сервере Приложений. На этапе 803 дилер управляет выполнением договора аренды арендатором и арендодателем. В это время договор аренды может быть отображен и локальному арендатору и удаленному арендодателю, и дилер, если это необходимо, может быть запрошен для того,чтобы он ответил на любые вопросы и сделал исправления. Дилер может организовать отображение арендодателю договора аренды, снабжая арендодателя унифицированным указателем информационного ресурса (URL), который предоставляет арендодателю возможность просмотра и выполнения договора аренды с выполненной версией, возвращаемой дилеру. После локального подписания арендатором и дилером, например при помощи планшетного персонального компьютера (ПК, PC), который фиксирует цифровую подпись арендатора на договоре аренды, и удаленного подписании арендодателем, договор аренды передается (этап 805) к Электронному Хранилищу, которое показано находящимся на связи с Сервером Приложений. Цифровое подписание арендатором и дилером преимущественно является динамическим, с использованием Сервера Приложений, обновляющим экраны при помощи применения к- 14007089 отображаемому изображению(ям) подписанного цифровым образом указателя. Фактически, цифровые подписи предпочтительно не отображаются. Будет признано очевидным, что Сервер Приложений и связанное Электронное Хранилище могут использоваться дилером для организации удаленного подписания договора арендодателем. На этапах 807-811, арендодатель извлекает договор аренды из хранилища, соглашается с условиями договора аренды при помощи его цифрового подписания, и возвращает хранилищу его версию, подписанную цифровым образом. Этапы 807-811 иллюстрируют как совместную работу множества сайтов, так и асинхронную обработку транзакций. На этапах 813-817, полученный электронный документ(ы) (договор аренды) проверяют на предмет цифровых подписей, и если какие бы то ни было из них найдены, достоверность цифровых подписей проверяется и соответствующие сертификаты аутентификации подтверждаются. На этапе 817, проверяют местное время для гарантирования того, что оно попадает в пределы периода(ов) действия сертификата(ов), и на этапе 819, CKCC запрашивает сведения о состоянии сертификата(ов). В ответ на этапе 821,CKCC сперва проверяет свою локальную кэш-память или запоминающее устройство данных на предмет сведений о состоянии сертификата, и если сведения о состоянии сертификата присутствуют и являются подлинными, CKCC на этапе 827 возвращает сведения о состоянии сертификата как об активном. На этапе 823, если сведения о состоянии сертификата отсутствуют или не являются подлинными, CKCC запрашивает выпускающий ЦС при помощи типа соединителя, созданного для этой цели. На этапе 825,выпускающий ЦС, например, Банковский ЦС, или его средства предоставления отчета о состоянии (например, каталог), возвращает к CKCC сведения о состоянии, предпочтительно при помощи того же самого соединителя, и на этапе 827 CKCC отправляет отчет о состоянии запрашиваемого сертификата назад,к Серверу Приложений. При условии того, что все цифровые подписи и сертификаты проверены и их достоверность подтверждена, аутентичность электронного документа доказана, Сервер Приложений берет на себя управление электронным документом, и на этапе 829 сохраняет его в Электронном Хранилище в качестве новой версии. Таким образом можно видеть, что при обеспечении надлежащих характеристик, Сервер Приложений и Электронное Хранилище взаимодействуют в качестве ДСЗИ. На этапе 831 новая версия обозначается в качестве аутентичной копии Электронный Оригинал, который также может являться пригодной для передачи записью, присоединяет отметку времени и даты и прилагает цифровую подпись ДСЗИ к документу. Данный этап имеет место до тех пор, пока по меньшей мере одна цифровая подпись на документе является допустимой. На этапе 833 если какая-то цифровая подпись или сертификат не в состоянии пройти все проверки,дилер извещается для поиска средств устранения недостатков, применение которого обычно влечет за собой повторение этапов 801-829 до тех пор, пока не будет применена допустимая замена цифровых подписей. Если сведения о состоянии сертификата подписывающей стороны аннулированы или их срок действия истек, процесс устранения недостатков не может завершиться до тех пор, пока не будут выпущены новый сертификат и криптографический материал. Следует понимать, что информационный объект, такой как договор аренды автомобиля, может быть представлен в электронной форме, например, XML, PDF, PKCS7, S/MIME, и т.д., которая предоставляет возможность размещения и обнаружения цифровых подписей, и предотвращает несанкционированное модифицирование. Поэтому, многие из этих форм можно рассматривать в качестве обеспечивающих защищенные упаковки или оболочки для содержащейся информации. Также следует понимать, что CKCC может использоваться для проверки сведений о состоянии сертификатов независимо от использования ключей. Такие сертификаты включают в себя, но не в ограничительном смысле, те, которые главным образом используются не для идентичности и аутентификации,например, соглашение/обмен ключами, подписание сертификата, подписание CAC, шифрование ключей,шифрование данных, только шифрование, только дешифрование, и протокол защищенных соединений(SSL). Соответственно, следует понимать, что как используется в этой заявке, термин сертификат аутентификации обычно охватывает такие сертификаты, которые не используются для идентификации. Кроме того, соединитель CKCC преимущественно может внедрять более одной проверки сведений о состоянии сертификата в отдельном сеансе связи. Между прочим, эта возможность может использоваться при проверке достоверности некоторых или всей цепочки сертификатов пользователя/объекта и сертификатов ЦС, например, иерархии ЦС от Корневого ЦС вниз к выпускающему ЦС. Это обеспечивает дополнительную гарантию того, что все ЦС в пути сертификата все еще являются допустимыми. В этой заявке описан способ для конфигурирования Службы Контроля за Состоянием Сертификатов (CKCC), который включает в себя этапы: определения установочной информации, необходимой для отыскания сведений о состоянии сертификата для требующегося выпускающего ЦС, идентификации соединителя, совместимого с методикой поиска сведений о состоянии сертификата, используемой для извлечения сведений о состоянии сертификата из выпускающего ЦС, конфигурирования соединителя установочными и коммуникационными параметрами, определенными для выбранного соединителя и выпускающего ЦС, и установления соответствия CKCC между выпускающим ЦС и соединителем. Обозначение ЦС и соединитель добавляются к списку утвержденных ЦС в запоминающем устройстве кон- 15007089 фигурации. Способ для выполнения транзакций, при помощи передачи аутентифицированных информационных объектов, имеющих соответствующие верифицируемые следы данных, включает в себя этап извлечения аутентифицированного информационного объекта первой стороной из доверенного запоминающего устройства. Аутентифицированный информационный объект включает в себя: первую цифровую подпись предъявляющей стороны, первый сертификат, привязывающий, по меньшей мере, идентичность и криптографический ключ к предъявляющей стороне, достоверные дату и время, цифровую подпись доверенного запоминающего устройства, сертификат, привязывающий, по меньшей мере, идентичность и криптографический ключ к доверенному запоминающему устройству; цифровую подпись и сертификат предъявляющей стороны, подтвержденной доверенным запоминающим устройством при предъявлении подтверждения подлинности информационного объекта; и аутентифицированный информационный объект, помещенный на хранение в качестве электронного исходного информационного объекта, отданного под управление доверенного запоминающего устройства. Способ выполнения транзакций дополнительно включает в себя этапы: требования у какого бы то ни было подписывающего объекта совершить использование и быть скрепленным их цифровой подписью до акта подписания, выполнения упомянутого информационного объекта любой стороной, состоящего из вложения, по меньшей мере, цифровой подписи и сертификата аутентификации подписывающей стороны, создания блока подписи, который содержит, по меньшей мере, цифровую подпись и сертификат аутентификации подписывающей стороны, привязки блока подписи к информационному объекту,повторения выполнявшихся ранее этапов, на которых разнообразные объекты цифровым образом подписывают информационный объект и/или упаковку, и пересылку к ДСЗИ цифровым образом подписанного и/или упакованного информационного объекта. ДСЗИ проверяет каждую цифровую подпись и подтверждает каждый привязанный сертификат аутентификации и извлекает сведения о состоянии из CKCC. Блоки подписи отклоняются, если цифровая подпись подписывающей стороны не проходит проверку,или срок действия сертификата аутентификации подписывающей стороны истек, или как сообщают, аннулирован. Отклонение какого бы то ни было блока подписи имеет своим результатом запрашивание замены блока подписи или инициирование средства устранения недостатков. Если, по меньшей мере,один блок подписи определен в качестве допустимого, ДСЗИ присоединяет свой собственный блок подписи, также содержащий достоверную дату и время, к подчиненному информационному объекту, создавая электронный оригинал, который содержит это и управляет им от имени владельца. Создание блока цифровой подписи может включать в себя этапы: вычисления одного или нескольких информационных наполнений случайных данных для одного или нескольких фрагментов информационных объектов или для целого информационного объекта, вычисления случайных данных по одному или нескольким информационным наполнениям случайных данных и любым присоединенным данным,таким как местные дата и время, подписания логического обоснования или команды, шифрования вычисленных случайных данных при помощи секретного ключа подписывающей стороны, формируя тем самым цифровую подпись подписывающей стороны, и размещения цифровой подписи подписывающей стороны в блоке подписи наряду с сертификатом аутентификации подписывающей стороны. Если присоединенные данные включают в себя местные дату и время, то создание блока цифровой подписи может дополнительно включать в себя этапы либо отображения местных даты и времени, требования у подписывающей стороны подтверждения того, что дата и время корректны, и корректирования местных даты и времени, если что-то из них некорректно, либо принятия системных даты и времени, если они установлены доверенной службой времени, и местные дата и время защищены от взлома и фальсификации. Местные дата и время могут проверяться для гарантирования того, что они точны и попадают в пределы периода действия сертификата аутентификации пользователя, и что локальные данные и время не отстают и не опережают дату и время, определенные периодом действия. Средство устранения недостатков цифровой подписи, которое не может осуществить требуемую проверку, повторно вычисляет цифровую подпись, и повторно передает блок подписи. Устранение нарушений из-за периода действия сертификата аутентификации включает в себя уведомление пользователя о том, что срок действия сертификата пользователя истек и должен быть возобновлен, а также уведомление владельца транзакции о том, что транзакция не завершена. Размещение одного или более блоков подписи и информации, содержащейся в них, определяется,по меньшей мере, одним тэгом подписи. Одна или более рукописные подписи и даты оцифровываются и используются для выполнения информационного объекта и размещения подписей и дат, определяемого,по меньшей мере, одним тэгом подписи. Один или несколько блоков подписи могут быть отправлены к ДСЗИ по отдельности, наряду с указанием соответствующих тэгов подписи, и ДСЗИ может подтверждать каждый блок подписи, отправленный независимо или в виде группы. Если либо проверка цифровой подписи, либо этап проверки достоверности сертификата аутентификации терпят неудачу, ДСЗИ отклоняет блок подписи и может запросить средство устранения недостатков, а если этап проверки достоверности блока подписи проходит успешно, ДСЗИ помещает блок подписи в обозначенный тэг. Для отправляемых по отдельности блоков подписи, ДСЗИ может добавлять достоверные дату и время к каждому блоку подписи. В соответствии с деловыми правилами, ДСЗИ присоединяет его собственный блок- 16007089 подписи, который содержит достоверные дату и время в упаковке, которая охватывает подчиненный информационный объект и вставленные поля блока подписи, создавая тем самым электронный исходный информационный объект. Многопользовательские блоки подписей могут быть добавлены в пределы упаковки, и упаковки могут рекурсивно применяться для осуществления других деловых и защитных процессов. ДСЗИ может проверять достоверность цифровой подписи(ей) и наличие сертификата(ов) аутентификации в блоке(ах) подписи, который(ые) должен содержаться внутри или добавляться к содержимому электронного исходного информационного объекта, при помощи проверки базы данных деловых правил на предмет того, что подписывающий объект, идентифицированный в соответствии с сертификатом аутентификации, имеет полномочия для выполнения запрашиваемых действий, проверки достоверности цифровой подписи подписывающего объекта, проверки того, что период действия сертификата перекрывает текущие достоверные дату и время, проверки того, что переданные местные дата и время попадают в пределы допустимого отклонения по отношению к дате и времени ДСЗИ, и проверки сведений о состоянии сертификата, используя CKCC. Если какой бы то ни было из этих этапов влечет за собой недействительные или ложные выходные данные, цифровую подпись считают недействительной, запрашиваемое действие не разрешают, и обращаются к средству устранения недостатков; в противном случае,цифровую подпись считают допустимой, и разрешают запрашиваемое действие. Регистрация выпускающего ЦС с CKCC может включать в себя этапы проверки и утверждения выпускающего ЦС для включения в базу знаний CKCC в качестве авторизованного, основываясь на деловых правилах предприятия или организации и системной политике. Если этап проверки терпит неудачу, выпускающий ЦС добавляется к запоминающему устройству конфигурации CKCC в качестве неавторизованного, и/или регистрация ЦС завершается; в противном случае, выпускающий ЦС добавляется в качестве авторизованного, а параметры связи (IP-адрес, ключ и сертификат SSL) и способ, используемый для предоставления отчета о состоянии сертификата (OCSP, CAC, LDAP), добавляются в запоминающее устройство конфигурации CKCC, а также добавляется соединитель для интерпретации сведений о состоянии сертификата, если он еще не осуществлен. Этим способом CKCC предоставляет возможность взаимодействия между системой или ДСЗИ и набором разнообразных ответчиков сведений о состоянии сертификата. Проверка сведений о состоянии сертификата, преимущественно использует CKCC для установления связи, извлечения сведений о состоянии сертификата из утвержденного сертификата выпускающего ЦС и их кэширования. Когда CKCC принимает запрос сведений о состоянии сертификата от системы или ДСЗИ, CKCC сперва проверяет свою локальную кэш-память для обнаружения сведений о состоянии сертификата и в случае, если они обнаруживаются и не выходят за пределы интервала времени существования, сведения о состоянии возвращаются. Если сведения о состоянии сертификата отсутствуют или выходят за пределы интервала времени существования, то CKCC извлекает из своего запоминающего устройства конфигурации сведения о состоянии при помощи первой запрашиваемой информации соединения. Затем CKCC устанавливает сеанс связи с компонентом, предоставляющим отчет о состоянии сертификата, идентифицированном в ее запоминающем устройстве конфигурации. CKCC составляет запрос сведений о состоянии сертификата в соответствии со способом, содержащимся в запоминающем устройстве конфигурации CKCC, и CKCC извлекает сведения о состоянии сертификата из компонента, предоставляющего отчет о состоянии сертификата, и закрывает сеанс связи с компонентом. CKCC добавляет,по меньшей мере, идентификатор сертификата, сведения о состоянии сертификата и время существования в свою кэш-память и возвращает сведения о состоянии сертификата запрашивающей системе или ДСЗИ. Предоставление отчета о состоянии сертификата может быть основано на CAC и обработке CAC. В соответствии с графиком публикации выпускающего ЦС, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурацииCKCC. CKCC очищает свою кэш-память, связанную с выпускающим ЦС, анализирует сведения о состоянии сертификата из CAC, и размещает сведения о состоянии сертификата в своей кэш-памяти, связанной с выпускающим ЦС. После уведомления выпускающим ЦС о том, что CAC доступен, CKCC может извлечь CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации CKCC. Там, где по стандартам требуется, чтобы CAC представлял собой полный CAC, CKCC очищает кэш-память, связанную с выпускающим ЦС, анализируетCAC, и размещает сведения о состоянии сертификата и связанную информацию в кэш-памяти, связанной с выпускающим ЦС. Там, где CAC содержит только изменения, встречающиеся после публикации полного CAC, CKCC анализирует сведения о состоянии сертификата из CAC и размещает сведения о состоянии сертификата и связанную информацию в кэш-памяти, связанной с выпускающим ЦС. Использование CKCC для получения сведений о состоянии сертификата, которое предоставляет пользователю, системе или ДСЗИ возможность использования отдельного средства для получения сведений о состоянии сертификата, могут включать в себя этапы: запрашивания CKCC на предмет наличия сведений о состоянии сертификата аутентификации в блоке подписи на информационном объекте, где запрашивание сведений о состоянии может использовать отдельное средство (например, OCSP), преоб- 17007089 разования запроса сведений о состоянии в форму, требуемую выпускающим ЦС, и извлечения и/или предоставления отчета о состоянии сертификата. Если состояние сертификата аннулированное, блок подписи не используется и требуется средство устранения недостатков; если цифровая подпись проверена и сведения о состоянии сертификата допустимы, блок подписи добавляется к электронному исходному информационному объекту. ДСЗИ может запрашивать CKCC для проверки достоверности сведений о состоянии сертификата аутентификации подписывающей стороны при помощи определения местонахождения и предоставления отчета о состоянии сертификата, если сведения о состоянии присутствуют в кэш-памяти/хранилище данных CKCC и являются подлинными, и получения типа и средств для извлечения сведений о состоянии сертификата из запоминающего устройства конфигурации CKCC. Если конкретным способом обеспечения сведениями о состоянии сертификата является CAC, и сведения о состоянии указанного сертификата не находятся в кэш-памяти выпускающего ЦС в CKCC, то CKCC сообщает о состоянии сертификата как о допустимом. Если способом обеспечения сведений о состоянии сертификата не является CAC, тоCKCC составляет запрос сведений о состоянии сертификата в соответствии со способом, содержащимся в запоминающем устройстве конфигурации CKCC, и устанавливает соответствующую связь с выпускающим ЦС. CKCC извлекает сведения о состоянии сертификата из компонента, предоставляющего отчет о состоянии при помощи идентифицированного способа проверки сведений о состоянии сертификата, и закрывает сеанс связи. CKCC анализирует или интерпретирует извлеченные сведения о состоянии сертификата, ассоциирует значение времени существования, равное периоду, определенному типом сведений о состоянии, как указано в политике CKCC, и добавляет, по меньшей мере, идентификатор сертификата, сведения о состоянии, и значение времени существования в кэш-память сведений о состоянии сертификата выпускающего ЦС. Затем CKCC возвращает сведения о состоянии сертификата к запрашивающей системе. Способ для регистрации пользователей в системе или ДСЗИ, в котором сертификат выпускается утвержденным выпускающим ЦС, который известен CKCC, включающий в себя: проверку пользователя,использующего процедуры и критерии установления членства, введение информации регистрации пользователя, которая также была подписана утвержденным поручителем организации, и создание и отправку запроса сертификата к идентифицированному выпускающему ЦС. Сертификат аутентификации пользователя извлекается, выпускается и помещается в маркер для доставки. Цифровая подпись, проверка цифровой подписи и проверка сведений о состоянии сертификата CKCC выполняются для гарантирования того, что генерирование пары открытого ключа и процесс выпуска сертификата были завершены корректно. От пользователя требуется поставить подпись под соглашением принятия пользователя, которое фиксирует пользователя, предоставляя тот же самый вес использованию его цифровой подписи,поскольку он дает использовать его или ее рукописную подпись, пользователю доставляют маркер, и система пользователя или учетная запись ДСЗИ активируется. Способ регистрации пользователей в системе или ДСЗИ, в котором пользователь уже имеет сертификат, выпущенный ЦС, который предварительно не известен CKCC, может включать в себя запрашивание маркера пользователя для сертификата аутентификации пользователя и получение информации выпускающего, и запрашивание базы знаний CKCC, для обнаружения того, содержится ли там выпускающий ЦС. В противном случае устанавливают связь с предприятием или администратором политики организации для того, чтобы определить, действительно ли выпускающий ЦС удовлетворяет системным правилам для включения ЦС. В случае, когда выпускающий ЦС считают не авторизованным, регистрация завершается, а когда выпускающий ЦС считают авторизованным, регистрация продолжается,как описано выше. Часть содержимого сертификата аутентификации пользователя может использоваться для привязывания сертификата к учетной записи пользователя, после утверждения пользователя для доступа к системе или ДСЗИ, при помощи ввода информации регистрации пользователя, вставки маркера пользователя, который содержит его сертификат аутентификации, в локальное считывающее устройство маркеров,извлечения и отображения содержимого сертификата, при наличии от пользователя подтверждения того,что содержимое корректно, и добавления выбранных полей к данным регистрации пользователя системы или ДСЗИ, которые извлекаются из сертификата, таких как идентификатор сертификата, выпускающий ЦС, подмножество различительных имен пользователя или другая информация идентификации, передаваемая в расширениях сертификата (например, subjectAltName). Извлеченные данные могут быть определены в политике системы или ДСЗИ таким образом, чтобы извлечение и ввод данных могли быть автоматизированы. Способ, посредством которого предъявитель информационного объекта ручается за подлинность представленного информационного объекта, включает в себя этап присоединения блока подписи предъявителя к информационному объекту и/или упаковке и отправления его к системе или ДСЗИ. Если проверка достоверности блока подписи оканчивается неудачно, ДСЗИ запрашивает повторную передачу или средство устранения недостатков, а если проверка достоверности блока подписи проходит успешно, то ДСЗИ проверяет совпадение идентичности предъявителя и инициатора сеанса связи, отклоняя представление в случае, если инициатор и предъявитель являются различными. Если все проверки завершаются- 18007089 успешно, ДСЗИ добавляет этот блок подписи к представлению, создавая электронный исходный информационный объект. Выполняющийся в CKCC способ поддержания точности и своевременности сведений о состоянии сертификата для средств предоставления отчета о состоянии сертификата в режиме реального времени,которые используют элемент данных время существования, включает в себя эти этапы. Если используемым способом обеспечения сведений о состоянии является CAC, то CKCC предоставляет отчет о состоянии. Если сведения о состоянии сертификата находятся в кэш-памяти и элемент данных время существования не выходит за определенные пределы, то CKCC предоставляет отчет о состоянии. Если элемент данных время существования выходит за определенные пределы, то CKCC стирает входные данные о состоянии сертификата из кэш-памяти выпускающего ЦС. Если сведения о состоянии извлекаются при помощи средств предоставления отчета о состоянии сертификата в режиме реального времени(например, OCSP, запроса LDAP и т.д.), и сведения о состоянии не находятся в кэш-памяти, сведения о состоянии сертификата запрашиваются, извлекаются и докладываются. Затем CKCC добавляет, по меньшей мере, идентификатор сертификата, сведения о состоянии сертификата и времени существования в свою кэш-память и возвращает сведения о состоянии сертификата запрашивающей системе или ДСЗИ. Элемент данных счетчик использования сведений о состоянии сертификата может добавляться ко входным сведениям о состоянии сертификата в кэш-памяти выпускающего ЦС CKCC, и счетчик использования сведений о состоянии может увеличиваться или уменьшаться всякий раз, когда проверяются сведения о состоянии сертификата. Если счетчик использования сведений о состоянии переходит порог,установленный политикой CKCC, то отчет о состоянии сертификата может быть предоставлен, но тогдаCKCC стирает входные сведения о состоянии сертификата из кэш-памяти выпускающего ЦС. Если возвращенные CKCC сведения о состоянии сертификата недействительны или аннулированы, то система или ДСЗИ регистрируют в журнале и/или предоставляют отчет об ошибке предъявителю и/или владельцу транзакции, и запрашиваемое действие не разрешают, и обращаются к средству устранения недостатков. В противном случае, цифровую подпись считают допустимой, и требуемое действие разрешают. Элемент данных последние выбранные сведения о состоянии сертификата может добавляться и использоваться вместе со счетчиком использования для определения уровня активности сведений о состоянии сертификатов. Фоновый процесс может заставить CKCC автоматически отыскивать обновленные сведения о состоянии сертификата и устанавливать новые элементы данных время существования и счетчик использования, когда критерий в политике CKCC удовлетворяется. Эта упреждающая выборка может предоставить возможность сокращения среднего времени между запросом сведений о состоянии сертификата системы или ДСЗИ, и ответом CKCC. Если к CKCC делается запрос на предмет отыскания сведений о состоянии сертификата для нового сертификата, и кэш-память достигает назначенного предела размера буфера, элемент данных последние выбранные сведения о состоянии сертификата может добавляться ко входным данным о состоянии сертификата в кэш-памяти выпускающего ЦС CKCC. CKCC просматривает кэш-память выпускающего ЦС на предмет обнаружения элемента данных, показывающего самую старую дату (наименее часто используемого) и очищает эти входные данные. Затем CKCC извлекает требуемые сведения о состоянии сертификата, размещает их на освобожденном месте в кэш-памяти выпускающего ЦС и предоставляет отчет о состоянии системе или ДСЗИ, которые действуют в соответствии с политикой. Способ проверки сведений о состоянии, в распределенной CKCC включает в себя: координирование между различными CKCC, осуществляемое всякий раз, когда вводится новый выпускающий ЦС,установление входных данных во всех базах знаний CKCC, если другая CKCC имеет основной обязанностью запрашивание выпускающего ЦС, запрашивание других CKCC вместо выпускающего ЦС для уменьшения обмена информацией между CKCC и выпускающим ЦС, синхронизацию и локальное кэширование сведений о состоянии сертификата, если множество локальных систем имеют более плотную концентрацию запросов о состоянии сертификата по отношению к выпускающему ЦС, и разделение или передачу обязанностей запрашивания, если другая CKCC имеет более обременительную активность с данным выпускающим ЦС, чем первоначальная основная CKCC. Исключение набора пользователей связанных с выпускающим ЦС изменяя ссылку выпускающего ЦС в базе знаний CKCC на не утверждено, может быть осуществлено при помощи требования того,чтобы утверждение для выпускающего ЦС было отозвано, просматривания требования на предмет достоинств и определения, что если необходимо какое бы то ни было действие, и если определено, что по любой причине выпускающий ЦС был блокирован, тогда сведения о состоянии выпускающего ЦС в базе знаний CKCC изменяются на не утверждено. Любой последующий запрос о состоянии сертификата,выпущенного ЦС, перечисленного как не утверждено, повлечет за собой в CKCC возвращение сведений о состоянии как неудавшихся. Способ повторного включения в работу набора заблокированных пользователей при помощи предварительного установления ссылки выпускающего ЦС как не утверждено, может быть осуществлен при помощи требования того, чтобы утверждение было предоставлено для повторного включения в ра- 19007089 боту выпускающего ЦС, просматривания требования на предмет достоинств и определения, что если необходимо какое бы то ни было действие, и если определено что выпускающего ЦС нужно повторно включить в работу, тогда сведения о состоянии выпускающего ЦС в базе знаний CKCC изменяются на утверждено. CKCC обрабатывает запросы сведений о состоянии сертификата для восстановленных выпускающих ЦС, как если бы они были любыми другими утвержденными ЦС. Связь с компонентами, предоставляющими отчет о состоянии, может быть установлена посредством создания модульного и многократно используемого устройства для каждого протокола сведений о состоянии сертификата, используемого для определения местонахождения, запрашивания и извлечения такой информации, использования версии устройства, которая является совместимой со всеми ЦС и ответчиками, которые понимают конкретный протокол сведений о состоянии сертификата, и обладания версией устройства для каждого используемого протокола предоставления отчета о состоянии. Устройство разработано таким образом, чтобы оно было легко приспосабливаемо для поддержки протоколов предоставления отчетов о состоянии сертификата, которые появятся в будущем. Выполнение транзакции, в которой предъявителем является первая ДСЗИ и представление передает обязанности по защите одного или более электронных оригиналов к второй ДСЗИ, может включать в себя наличие владельца транзакции, приказывающего первой ДСЗИ передать обязанности по защите одного или более электронных исходных документов второй ДСЗИ. Владелец транзакции приказывает второй ДСЗИ передать обязанности по защите одного или более электронных исходных документов, и владелец снабжает первую ДСЗИ декларацией, которая определяет, какие электронные оригиналы должны быть переданы второй ДСЗИ. Первая ДСЗИ устанавливает связь со второй ДСЗИ и определяет цель своих действий второй ДСЗИ. Первая ДСЗИ или владелец могут передавать декларацию второй ДСЗИ таким образом, чтобы она была способна определить, когда передача обязанностей по защите будет завершена. Первая ДСЗИ передает каждый идентифицированный электронный оригинал второй ДСЗИ, которая использует CKCC для гарантирования того, что цифровая подпись первой ДСЗИ на каждом переданном электронном оригинале допустима, и что электронные оригиналы являются неизмененными. Если какая бы то ни было из цифровых подписей первой ДСЗИ является недействительной, то вторая ДСЗИ уведомляет об этом первую ДСЗИ и обращается к средству устранения недостатков (например, просит,чтобы первая ДСЗИ отказалась от использования текущего сертификата аутентификации). Если первая ДСЗИ не способна выполнить просьбу, вторая ДСЗИ регистрирует этот случай и уведомляет владельца транзакции о том, что требуемая передача обязанностей по защите потерпела неудачу; в противном случае, вторая ДСЗИ создает новую упаковку для каждого успешно переданного информационного объекта,добавляя отметку времени и даты и ее блок подписи. Вторая ДСЗИ уведомляет первую ДСЗИ о каждой успешной передаче, и после завершения, первая ДСЗИ может по усмотрению владельца либо отметить и сохранить копии таким образом, что они не могут быть истолкованы в качестве оригинала, либо может уничтожить все копии переданных информационных объектов, которые существуют. Процесс повторяется до тех пор, пока все идентифицированные электронные оригиналы не будут переданы. Этим способом, вторая ДСЗИ становится хранителем для переданных записей, которые являются аутентичными копиями. Вторая ДСЗИ может присоединять достоверные дату и время, цифровым образом подписывать,упаковывать и хранить декларацию, делая ее независимым элементом следа защиты. При выполнении транзакции, команда владельца также может установить, что передача прав собственности имеет место, и передача документации на право собственности может быть помещена или в первую, или во вторую ДСЗИ. Несущая ответственность ДСЗИ подтверждает подлинность передачи документов на право собственности, проверяя достоверность всех цифровых подписей, периоды действия сертификатов, и проверяя при помощи CKCC сведения о состоянии сертификата. Затем ДСЗИ присоединяет достоверные дату и время, и цифровым образом подписывает, упаковывает и хранит эти новые электронные исходные информационные объекты, которые добавляются к декларации. Там, где эти электронные оригиналы помещаются в первую ДСЗИ, передача прав собственности осуществляется до передачи обязанностей по защите, и первоначальная декларация становится частью следа прав собственности. Некоторые из переданных записей могут быть простыми электронными информационными объектами, а не только электронными оригиналами. CKCC может использовать любой подходящий протокол сведений о состоянии сертификата для обмена информацией с системой или ДСЗИ. Настоящее изобретение может быть воплощено во многих различных формах, не отступая от его основных особенностей, и таким образом вышеописанные варианты осуществления во всех отношениях следует рассматривать в качестве иллюстративных, а не ограничительных. Подчеркивается, что термины содержит и содержащий, как используется в этом описании и в нижеследующей формуле изобретения, предназначены для того, чтобы характеризовать наличие заявленных признаков, не препятствуя наличию одного или более других признаков. Обозначенные рамки изобретения формулируются нижеследующей формулой изобретения, а не предыдущим описанием, и все изменения, которые попадают в пределы формулы изобретения, обозначаются как охваченные в ней.- 20007089 ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Способ обеспечения Службы Контроля за Состоянием Сертификатов (CKCC) для проверки достоверности сертификатов аутентификации, выпущенных соответствующими выпускающими Центрами Сертификации (ЦС), содержащий этапы идентифицирования информации, необходимой для извлечения сведений о состоянии сертификата аутентификации из выпускающего ЦС, который выпустил сертификат аутентификации; конфигурирования соединителя на основе идентифицированной информации для обмена информацией с выпускающим ЦС; обмена информацией с выпускающим ЦС в соответствии с конфигурированным соединителем, когда запрашиваются сведения о состоянии сертификата аутентификации; и извлечения сведений о состоянии сертификата аутентификации; в котором выпускающий ЦС и соединитель определяются в списке утвержденных ЦС в запоминающем устройстве конфигурации. 2. Способ по п.1, в котором местные дата и время подвергаются проверке на предмет того, попадают ли они в диапазон периода действия, обозначенный в сертификате аутентификации. 3. Способ по п.1, в котором выпускающий ЦС включают в список утвержденных ЦС при помощи проверки и утверждения выпускающего ЦС согласно заранее определенным деловым правилам, и если выпускающий ЦС был проверен и не утвержден, то выпускающий ЦС обозначается в списке неутвержденных ЦС в запоминающем устройстве конфигурации. 4. Способ по п.3, в котором проверка и утверждение выпускающего ЦС включают в себя регистрацию представления доверенного сертификата аутентификации с CKCC и добавление, по меньшей мере,представления, состояния и элемента данных время существования в локальную кэш-память, и соединитель выполнен с возможностью извлечения добавленных сведений о состоянии, когда запрашиваются сведения о состоянии доверенного сертификата аутентификации. 5. Способ по п.2, дополнительно содержащий этапы проверки локальной кэш-памяти на предмет сведений о состоянии, и если сведения о состоянии найдены в локальной кэш-памяти, а местные дата и время находятся в пределах периода действия, то извлечения сведений о состоянии из локальной кэшпамяти, причем если сведения о состоянии не найдены в локальной кэш-памяти или если местные дата и время не находятся в пределах периода действия, CKCC устанавливает сеанс связи с компонентом выпускающего ЦС, предоставляющим отчет о состоянии сертификата, составляет запрос о состоянии сертификата в соответствии с конфигурированным соединителем, извлекает сведения о состоянии из компонента, предоставляющего отчет о состоянии сертификата, закрывает сеанс связи с компонентом, предоставляющим отчет о состоянии сертификата, и добавляет в локальную кэш-память, по меньшей мере,сведения об идентификации, состоянии и времени существования сертификата аутентификации. 6. Способ по п.1, в котором сведения о состоянии сертификата указываются Списком Аннулированных Сертификатов (CAC) и в соответствии с графиком публикации выпускающего ЦС, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации, CKCC очищает кэш-память, связанную с выпускающим ЦС, и CKCC определяет состояние сертификата аутентификации из CAC и запоминает сведения о состоянии в кэшпамяти, связанной с выпускающим ЦС. 7. Способ по п.1, в котором сведения о состоянии сертификата указываются Списком Аннулированных Сертификатов (CAC) и после уведомления выпускающим ЦС о том, что CAC доступен, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации; если CAC является полным CAC, то CKCC очищает кэшпамять, связанную с выпускающим ЦС, определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэш-памяти; а если CAC содержит только изменения, случившиеся после публикации полного CAC, CKCC определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэшпамяти. 8. Способ по п.1, в котором этап обмена информацией включает в себя обмен информацией в соответствии с последовательностью соединителей. 9. Способ по п.1, в котором соединитель внедряет более одной проверки сведений о состоянии сертификата в отдельный этап обмена информацией. 10. Способ по п.1, в котором сертификат аутентификации не используется для идентификации. 11. Способ извлечения сведений о состоянии сертификата аутентификации, выпущенного выпускающим Центром Сертификации (ЦС) в ответ на запрос от Доверенной Службы Защиты Информации(ДСЗИ) к Службе Контроля за Состоянием Сертификатов (CKCC) для подтверждения сведений о состоянии сертификата аутентификации, включающий в себя этапы определения местонахождения и предоставления отчета о состоянии, если сведения о состоянии присутствуют в кэш-памяти CKCC и являются подлинными; в противном случае, выполняют этапы получения типа сведений о состоянии и способа извлечения из запоминающего устройства конфи- 21007089 гурации CKCC; если типом сведений о состоянии является Список Аннулированных Сертификатов (CAC) и сведения о состоянии не найдены в кэш-памяти, то предоставляют отчет о состоянии как о допустимом; если типом сведений о состоянии не является CAC, то составляют запрос сведений о состоянии сертификата в соответствии с типом сведений о состоянии; устанавливают сеанс связи с выпускающим ЦС; извлекают сведения о состоянии из компонента выпускающего ЦС, предоставляющего отчет о состоянии, используя полученный способ извлечения и завершают сеанс связи; интерпретируют извлеченные сведения о состоянии; привязывают к интерпретируемым извлеченным сведениям о состоянии, значение времени существования, представляющего период, определенный политикой CKCC для типа сведений о состоянии; добавляют, по меньшей мере, идентификацию сертификата аутентификации, сведения о состоянии и значение времени существования в кэш-память; и предоставляют ДСЗИ отчет о состоянии в ответ на запрос. 12. Способ по п.11, в котором CKCC использует протокол сведений о состоянии сертификата в сеансе связи. 13. Способ по п.11, в котором извлекают более одних сведений о состоянии, используя полученный способ извлечения. 14. Способ по п.11, в котором сертификат аутентификации не используется для идентификации. 15. Способ обеспечения Службы Контроля за Состоянием Сертификатов (CKCC) для обеспечения точной и своевременной индикации сведений о состоянии сертификатов аутентификации, выпущенных выпускающими Центрами Сертификации (ЦС), содержащий обеспечение сведений о состоянии сертификата аутентификации в качестве показанных Списком Аннулированных Сертификатов (CAC), когда выпускающий сертификаты ЦС использует CAC для индикации сведений о состоянии; в противном случае, обеспечение сведений о состоянии в качестве показанных кэш-памятью, когда кэш-память включает в себя сведения о состоянии и элемент данных время существования не выходит за определенные пределы; если элемент данных время существования выходит за определенные пределы, сведения о состоянии стираются из кэш-памяти; запрашивание и извлечение сведений о состоянии при помощи протокола предоставления отчета о состоянии сертификата в режиме реального времени, когда сведения о состоянии не находятся в кэшпамяти; добавление в кэш-память, по меньшей мере, идентификации сертификата, сведений о состоянии и элемента данных время существования; и обеспечение извлеченного состояния. 16. Способ по п.15, в котором элемент данных счетчик использования сведений о состоянии добавляется в кэш-память; показания элемента данных счетчик использования сведений о состоянии увеличиваются или уменьшаются всякий раз, когда проверяются сведения о состоянии сертификата; если элемент данных счетчик использования сведений о состоянии переходит пороговую величину, то обеспечиваются сведения о состоянии и кэш-память стирается в части сведений о состоянии. 17. Способ по п.16, в котором элемент данных последние выбранные сведения о состоянии добавляется в кэш-память и элемент данных последние выбранные сведения о состоянии вместе с элементом данных счетчик использования сведений о состоянии предоставляют возможность определения уровня активности сведений о состоянии сертификата. 18. Способ по п.17, в котором когда к CKCC осуществляется запрос для извлечения сведений о состоянии нового сертификата и кэш-память достигает назначенного предела размера буфера, CKCC просматривает кэш-память на предмет обнаружения элемента данных последние выбранные сведения о состоянии, показывающего самую старую дату, и стирает соответствующие входные данные из кэшпамяти; и затем CKCC извлекает требуемые сведения о состоянии, размещает их в кэш-памяти и обеспечивает требуемое состояние. 19. Способ выполнения транзакций между первой стороной и второй стороной при помощи передачи управления аутентифицированным информационным объектом, имеющим верифицируемый след данных, содержащий этапы: извлечения из доверенного запоминающего устройства аутентифицированного информационного объекта, включающего в себя первый блок цифровой подписи, содержащий цифровую подпись предъявляющей стороны и первый сертификат аутентификации, связывающий, по меньшей мере, идентичность и криптографический ключ с предъявляющей стороной, индикатор даты и времени, и второй блок цифровой подписи, содержащий вторую цифровую подпись доверенного запоминающего устройства, и второй сертификат аутентификации, связывающий, по меньшей мере, идентичность и криптографический ключ с доверенным запоминающим устройством; достоверность первого блока цифровой подписи была подтверждена доверенным запоминающим устройством; и аутентифицированный информационный объ- 22007089 ект сохраняется в качестве электронного исходного информационного объекта под управлением доверенного запоминающего устройства; выполнения извлеченного аутентифицированного информационного объекта второй стороной при помощи включения в извлеченный аутентифицированный информационный объект третьего блока цифровой подписи, содержащего по меньшей мере третью цифровую подпись и третий сертификат аутентификации второй стороны; и пересылки выполненного извлеченного аутентифицированного информационного объекта к Доверенной Службе Защиты Информации (ДСЗИ), причем ДСЗИ проверяет цифровые подписи и проверяет достоверность сертификатов аутентификации, связанных с цифровыми подписями, включенными в информационные объекты, при помощи, по меньшей мере, извлечения сведений о состоянии сертификатов аутентификации из Службы Контроля за Состоянием Сертификатов (CKCC), обеспеченной согласно п.1; ДСЗИ отклоняет блок цифровой подписи, если соответствующая цифровая подпись не проверена, или срок сведений о состоянии соответствующего сертификата аутентификации истек или они аннулированы и если по меньшей мере один блок подписи в информационном объекте не отклонен, ДСЗИ присоединяет к информационному объекту блок цифровой подписи ДСЗИ и индикатор даты и времени и от имени первой стороны берет объект под свой контроль. 20. Способ по п.19, в котором блок подписи включает в себя по меньшей мере одни случайные данные по меньшей мере части информационного объекта, в который включен блок подписи, по меньшей мере одни случайные данные шифруют криптографическим ключом соответствующей подписывающей стороны блока, формируя тем самым цифровую подпись подписывающей стороны, и цифровая подпись подписывающей стороны включается в блок подписи с сертификатом аутентификации подписывающей стороны. 21. Способ по п.20, в котором этап выполнения включает в себя отображение второй стороне местных даты и времени, подтверждение второй стороной того, что отображенные местные дата и время корректны, и корректирование местных даты и времени в случае, если любая из них некорректна. 22. Способ по п.19, в котором если ДСЗИ отклоняет блок цифровой подписи, то ДСЗИ запрашивает средство устранения недостатков, которое требуется цифровой подписи для повторного вычисления и блоку подписи для повторной пересылки. 23. Способ по п.19, в котором ДСЗИ проверяет местные дату и время для соблюдения точности и того, чтобы они не выходили за пределы периода действия, указанного сертификатом аутентификации второй стороны. 24. Способ по п.23, в котором в случае, если местные дата и время выходят за пределы периода действия указанного сертификатом аутентификации второй стороны, то ДСЗИ уведомляет вторую сторону о том, что сертификат аутентификации отклоняется, и первую сторону о том, что транзакция не завершена. 25. Способ по п.19, в котором одна или несколько оцифрованных рукописных подписей включается в информационный объект, и размещение оцифрованных рукописных подписей в структуре данных определяется по меньшей мере одним тэгом подписи. 26. Способ по п.19, в котором размещение одного или нескольких блоков подписи в структуре данных определяется по меньшей мере одним тэгом подписи. 27. Способ по п.26, в котором один или несколько блоков подписи по отдельности пересылаются к ДСЗИ с соответствующими тэгами подписи, и ДСЗИ проверяет достоверность блоков подписи при помощи отклонения блока подписи в случае, если либо соответствующая цифровая подпись не проверена,либо достоверность соответствующего сертификата аутентификации не подтверждена, и размещения блока подписи согласно соответствующему тэгу подписи, если блок подписи не был отклонен,причем для блоков подписи, посылаемых по отдельности, ДСЗИ добавляет указание даты и времени к каждому блоку подписи, и присоединяет в соответствии с деловыми правилами блок подписи ДСЗИ в упаковке, которая охватывает информационный объект и помещенные в него блоки подписи. 28. Способ по п.27, в котором ДСЗИ проверяет цифровую подпись и подтверждает достоверность сертификата аутентификации в блоке подписи посредством определения из деловых правил того, связана ли сторона с сертификатом аутентификации, имеющимся у центра сертификации,проверки достоверности цифровой подписи стороны,проверки того, что период действия сертификата аутентификации перекрывает текущие дату и время ДСЗИ,проверки того, что местные дата и время попадают в пределы допустимого отклонения по отношению к текущим дате и времени ДСЗИ, и извлечения сведений о состоянии сертификата аутентификации из CKCC, и если какой бы то ни было из предшествующих этапов влечет за собой недействительные или ложные выходные данные, цифровую подпись считают недействительной, а транзакцию - не выполненной, в- 23007089 противном случае, цифровую подпись считают допустимой, а транзакцию - выполненной. 29. Способ по п.19, в котором CKCC снабжает ДСЗИ сведениями о состоянии сертификата аутентификации при помощи, по меньшей мере, этапов проверки локальной кэш-памяти на предмет сведений о состоянии, и если сведения о состоянии найдены в локальной кэш-памяти, а местные дата и время находятся в пределах периода действия, то извлечения сведений о состоянии из локальной кэш-памяти; если сведения о состоянии не найдены в локальной кэш-памяти, или если местные дата и время не находятся в пределах периода действия, CKCC устанавливает сеанс связи с компонентом выпускающего ЦС,предоставляющим отчет о состоянии сертификата, составляет запрос о состоянии сертификата в соответствии с конфигурированным соединителем, извлекает сведения о состоянии из компонента предоставляющего отчет о состоянии сертификата, закрывает сеанс связи с компонентом, предоставляющим отчет о состоянии сертификата, и добавляет в локальную кэш-память, по меньшей мере, сведения об идентификации, состоянии и времени существования сертификата аутентификации. 30. Способ по п.19, в котором первой стороной является первая ДСЗИ, и транзакция предназначена для передачи обязанностей по защите одного или более электронных оригиналов к первой ДСЗИ от второй ДСЗИ, владелец транзакции снабжает вторую ДСЗИ декларацией, которая идентифицирует электронные оригиналы, передаваемые первой ДСЗИ, вторая ДСЗИ устанавливает связь с первой ДСЗИ и определяет цель ее действий, декларация передается к первой ДСЗИ таким образом, чтобы она была способна определить, когда передача обязанностей по защите будет завершена, вторая ДСЗИ передает каждый идентифицированный электронный оригинал первой ДСЗИ, первая ДСЗИ извлекает сведения о состоянии сертификата второй ДСЗИ и проверяет цифровую подпись второй ДСЗИ на каждом переданном электронном оригинале, если какая бы то ни было из цифровых подписей второй ДСЗИ является недействительной, то первая ДСЗИ уведомляет об этом вторую ДСЗИ и обращается к средству устранения недостатков, если вторая ДСЗИ не обеспечивает средство устранения недостатков, то первая ДСЗИ уведомляет владельца транзакции о том, что требуемая передача обязанностей по защите потерпела неудачу, в противном случае вторая ДСЗИ создает новую упаковку для каждого успешно переданного информационного объекта, добавляя отметку времени и даты и блок подписи первого ДСЗИ. 31. Способ по п.30, в котором транзакция представляет собой передачу прав собственности в ответ на команду, причем передача документов на право собственности может быть помещена или в первую,или во вторую ДСЗИ, ДСЗИ, имеющая передачу документов на право собственности, подтверждает подлинность передачи документов на право собственности, проверяя достоверность всех цифровых подписей, периоды действия сертификатов, и используя CKCC для проверки сведений о состоянии сертификата для всех сертификатов аутентификации, включенных в передачу документов на право собственности,присоединяет указание даты и времени и цифровым образом подписывает, упаковывает и запоминает документы на право собственности, которые добавляются к декларации. 32. Способ по п.19, в котором для CKCC сведения о состоянии сертификата указываются Списком Аннулированных Сертификатов (CAC), в соответствии с графиком публикации выпускающего ЦС,CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации, CKCC очищает кэш-память, связанную с выпускающим ЦС, и CKCC определяет состояние сертификата аутентификации из CAC и запоминает сведения о состоянии в кэш-памяти, связанной с выпускающим ЦС. 33. Способ по п.19, в котором для CKCC сведения о состоянии сертификата указываются Списком Аннулированных Сертификатов (CAC) и после уведомления выпускающим ЦС о том, что CAC доступен, CKCC извлекает CAC из компонента, предоставляющего отчет о состоянии сертификата, перечисленного в запоминающем устройстве конфигурации; если CAC является полным CAC, то CKCC очищает кэш-память, связанную с выпускающим ЦС, определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэш-памяти; а если CAC содержит только изменения, случившиеся после публикации полного CAC, CKCC определяет сведения о состоянии из CAC и запоминает сведения о состоянии в кэш-памяти.