Ставится ли печать на протоколе: Общие правила составления и оформления протокола

Ставится ли печать на протоколе: Общие правила составления и оформления протокола

Протоколы заседаний: составление и оформление

Протокол как отражение коллегиального способа принятия решений

Протокол заседания применяется для документирования деятельности коллегиальных и совещательных органов (коллегий, советов, комиссий, собраний, совещаний и др.), как постоянных, так и временных. Нередко протоколы заседаний ведутся на деловых встречах, переговорах для фиксации достигнутых сторонами договоренностей или иных выработанных совместно условий.

Протокол заседания – документ, содержащий последовательную запись обсуждения вопросов и принятия решений на собраниях, совещаниях, конференциях, заседаниях коллегиальных или совещательных органов.

Протокол заседания отражает деятельность по совместной выработке и принятию управленческих решений. Коллегиальному решению, как правило, подлежат наиболее важные и принципиальные вопросы в деятельности организации, требующие коллективного, совместного обсуждения и принятия решения.

Коллегиальный способ принятия решения используется в деятельности практически любой организации, независимо от ее организационно-правовой формы и характера деятельности, например в организациях, имеющих форму акционерного общества, на основе коллегиальности действуют общее собрание акционеров, совет директоров (наблюдательный совет), правление, ревизионная комиссия, счетная комиссия. Кроме того, в любой организации при единоличном исполнительном органе, например при генеральном директоре, могут создаваться дирекции, советы, комиссии для совместного обсуждения и решения различных вопросов деятельности организации.

Подготовительный этап

Как правило, заседанию предшествует большая подготовительная работа: подготовка повестки дня заседания, информирование членов коллегиального органа и других заинтересованных лиц, подготовка в соответствии с повесткой дня материалов для рассмотрения на заседании (как правило, это справка по вопросу или тезисы выступления и проект решения), их копирование и рассылка всем участникам заседания для предварительного ознакомления, подготовка помещения для проведения заседания и др.

Заседанию коллегиального органа предшествует регистрация участников, которая может проводиться в разных формах: от записи фамилий присутствующих непосредственно в черновик протокола (если число участников заседания не превышает 15 человек), составления списка присутствующих на заседании членов коллегиального органа и приглашенных с указанием всех необходимых сведений о них (должность, место работы) до регистрации участников с помощью технических средств. При проведении заседаний общих собраний акционеров акционерных обществ список присутствующих на заседании акционеров и доверенных лиц должен заверяться подписью председателя собрания. Доверенные лица могут быть включены в список присутствующих только при предъявлении доверенности на право представлять интересы акционера. Регистрация присутствующих на заседании – чрезвычайно важный момент, поскольку решения коллегиального органа обладает юридической силой лишь при наличии кворума, а также в том случае, если все участники заседания обладают достаточными полномочиями для участия в голосовании по принимаемым решениям.

Протокол составляется на основании стенограммы заседания, звукозаписи заседания или на основании черновых рукописных записей, которые ведутся во время заседания, а также материалов, подготовленных к заседанию (текстов докладов, выступлений, справок, проектов решений, повестки дня, списков участников и др.).

Если заседание стенографировалось или велась звукозапись, после заседания стенограмма расшифровывается, сверяется со звукозаписью и оформляется (такие записи называют стенограммами или стенографическими протоколами). Расшифровка стенограмм или звукозаписей заседания проводится либо по частям во время самого заседания, либо сразу после заседания, но в любом случае время, которое отводится на оформление стенограммы и протокола заседания, не должно превышать 3-5 дней со дня, когда проводилось заседание.

Если ход заседания записывался на магнитофон или диктофон, после расшифровки записи, составления и оформления стенограммы и (или) протокола кассета со звукозаписью в течение установленного срока (как правило, в течение двух недель) хранится в подразделении, обеспечивающем звукозапись заседаний, а затем размагничивается.

Оформление реквизитов протокола

С точки зрения полноты отражения хода заседания различаются полные и краткие протоколы.

Полный протокол содержит запись всех выступлений на заседании, краткий – только фамилии выступивших и тему выступления. Какой именно следует вести протокол в каждом конкретном случае, устанавливается в регламенте работы коллегиального органа или решается председателем коллегиального органа.

Протокол заседания оформляются на стандартных листах бумаги формата А4.

Оформление реквизитов протокола должно соответствовать ГОСТ Р 6.30-2003 «Унифицированные системы документации. Система организационно-распорядительной документации. Требования к оформлению документов».

Датой протокола является дата события (заседания, совещания). Дата оформляется цифровым или словесно-цифровым способом: 05.02.2005 или 05 февраля 2005 г.

Регистрационным номером протокола является порядковый номер заседания в течение календарного года или в течение срока действия выборного органа. При регистрации протоколов специальные регистрационно-учетные формы (журнал, картотека) не ведутся, каждому новому протоколу присваивается порядковый номер, следующий за номером протокола, подшитого в дело последним.

Место составления протокола указывается в соответствии с принятым административно-территориальным делением. Наименование места составления документа можно не указывать, если наименование территории входит в название организации: Московская городская Дума, Законодательное Собрание Тверской области.

Заголовок к тексту является обязательным реквизитом протокола. Он должен быть грамматически согласован с наименованием вида документа:

ПРОТОКОЛ (чего?) заседания комиссии по переоценке основных фондов

ПРОТОКОЛ (чего?) заседания дирекции

Текст протокола состоит из двух частей – вводной и основной. Вводная часть оформляется идентично в полной и краткой формах протокола. В ней указываются: фамилии председателя и секретаря заседания, фамилии или общее количество участников заседания и приглашенных лиц, повестка дня. Фамилии членов коллегиального органа или лиц, участвующих в заседании с правом голоса, перечисляются по алфавиту без указания должностей. Если указывается общее количество присутствующих, дается их обобщенное название и делается отметка о наличии списка регистрации:

Присутствовали: члены Научно-технического совета в количестве 25 чел.

Лица, не являющиеся членами коллегиального органа и приглашаемые на заседание в качестве экспертов в обсуждаемых вопросах или заинтересованных лиц, перечисляются после слова «Приглашенные:», также по алфавиту, но с указанием их должностей и места работы, если они являются представителями других организаций.

В повестке дня заседания указывается вопрос или вопросы, являющиеся предметом рассмотрения на заседании, должность и фамилия докладчика. Если вопросов несколько, они нумеруются арабскими цифрами и располагаются по степени их сложности, важности и в порядке обсуждения. Вопросы повестки дня строятся по формуле «о чем?»:

Повестка дня:

1. О формировании сметы расходов фирмы на 2005 г.

Доклад финансового директора Мовчана С.А.

2. О подготовке рекламной кампании сезона «Весна-Лето-2005»

Доклад зав. отделом рекламы Сомовой Н.Н.

Вопросы повестки дня должны формулироваться точно и ясно, отражать суть обсуждаемых вопросов. Не рекомендуется включать в повестку дня пункт «Разное».

Текст основной части протокола состоит из отдельных разделов по количеству вопросов повестки дня, каждый из которых строится по схеме:

1. СЛУШАЛИ:

ВЫСТУПИЛИ:

РЕШИЛИ: (или: ПОСТАНОВИЛИ:)

Эти ключевые для протокола слова печатаются прописными буквами и с красной строки. Разделы нумеруются арабскими цифрами в соответствии с повесткой дня. После слова «СЛУШАЛИ:» в именительном падеже указывается фамилия докладчика и в форме 3-го лица единственного числа или с предлогом «о» излагается содержание доклада. Если имеется текст доклада, после фамилии докладчика делается отметка:

В разделе «ВЫСТУПИЛИ:» последовательно указывают фамилии лиц, принявших участие в обсуждении доклада, и формулируются высказанные ими мнения. Фамилии выступивших и содержание их выступлений записываются так же, как выступление основного докладчика в предыдущей части протокола.

При необходимости в этом же разделе протокола фиксируются вопросы, заданные докладчику, и его ответы по следующей форме:

Вопрос: Если будет принято решение об эмиссии акций общества, предусматривается ли выпуск привилегированных акций?

Ответ: Нет, будут выпущены только обыкновенные акции.

Фамилия лица, задавшего вопрос, может не указываться.

В разделе «РЕШИЛИ:» («ПОСТАНОВИЛИ:») записывается принятое решение, кратко, точно, лаконично – так, чтобы не возникало двоякого толкования. Принятые решения формулируются в предписывающей форме: «Утвердить…», «Предусмотреть…», «Внести изменения…». По одному вопросу может быть принято несколько решений, в этом случае они нумеруются арабскими цифрами. При необходимости наряду с решением указываются результаты голосования: количество голосов «за», «против», «воздержавшихся», а также, если голосование было тайным, – количество выданных бюллетеней, полученных в результате голосования и признанных недействительными.

Участник совещания или заседания может представить особое мнение по принятому решению, которое излагается на отдельном листе и присоединяется к протоколу. Содержание особого мнения записывается в протокол после записи соответствующего решения.

Если протоколом утверждается какой-либо документ, он должен прилагаться к протоколу и иметь гриф утверждения, например:

Подписи председателя и секретаря заседания завершают оформление протокола. Подписывается один экземпляр протокола. Слева проставляется подпись председателя, справа — секретаря.

В соответствии с действующим законодательством в отдельных случаях протоколы заседаний подписываются только председателем (председательствующим) на заседании. Законодательством также предусмотрены случаи подписания протоколов всеми членами органа, принимающего решения. Например, Федеральным законом «Об акционерных обществах» (далее — Закон) предусмотрено (ст. 68), что протокол заседания совета директоров (наблюдательного совета) общества подписывается председательствующим на заседании, который несет ответственность за правильность составления протокола.

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

—          место и время проведения общего собрания акционеров;

—          общее количество голосов, которыми обладают акционеры – владельцы голосующих акций общества;

—          количество голосов, которыми обладают акционеры, принимающие участие в собрании;

—          председатель (президиум) и секретарь собрания, повестка дня собрания.

В Законе также указывается, что в протоколе общего собрания акционеров общества должны содержаться основные положения выступлений, вопросы, поставленные на голосование, и итоги голосования по ним, решения, принятые собранием.

Сокращенный вариант оформления протокола

Допускается сокращенный вариант оформления протокола, при котором слова СЛУШАЛИ, ВЫСТУПИЛИ, РЕШИЛИ (ПОСТАНОВИЛИ) не печатаются. После цифры, обозначающей номер вопроса в повестке дня, излагается содержание вопроса (пункт повестки дня). Последняя строка содержания вопроса подчеркивается, и под чертой печатаются фамилии докладчика и выступивших в обсуждении (первой указывается фамилия основного докладчика, а затем фамилии выступивших – в порядке их выступления). После указания фамилий при необходимости кратко излагается суть рассматриваемого вопроса, а ниже – решение (постановление).

Выписка из протокола

Для информирования заинтересованных организаций и лиц о принятых решениях, а также в целях подтверждения принятых решений могут оформляться выписки из протокола.

Выписка из протокола – документ, представляющий собой копию части протокола. В выписке воспроизводится вводная часть протокола (реквизиты бланка, сведения о председателе, секретаре, присутствовавших), вопрос повестки дня, по которому готовится выписка, и часть текста, отражающая рассмотрение вопроса и принятые по нему решения. Подписями председателя и секретаря выписка не удостоверяется. Для придания юридической силы выписке из протокола используется реквизит «Отметка о заверении копии», оформляемый секретарем. Если выписка из документа выдается для представления в другую организацию, она заверяется печатью организации.

В.Ф. Янковая

Решения единственных участников ООО теперь надо заверять нотариально. Как этого избежать?

Соответствующие изменения в законодательство приняты не были.

А что мы видим в реальности?

Например, Верховный Суд утверждает, что закон не содержит исключения в отношении решений единственного участника в части требования о нотариальном удостоверении, установленного подпунктом 3 пункта 3 статьи 67.1 ГК РФ. Но как же статья 39 ФЗ «Об ООО», которая прямо говорит, что в обществах, состоящих из одного участника, к решениям единственного участника не применяются требования, касающиеся подготовки и проведения собраний. Или, например, статья 17 ФЗ «Об ООО», которая видит разницу между решениями и собраниями, отдельно устанавливая обязанность удостоверять решения единственных участников.

И в конце концов, почему мы деликатно забываем про состав участников общества, присутствующих при принятии решений? Поскольку закон не содержит исключений, значит и это нужно подтверждать одновременно с удостоверением решений (или всё-таки заверением подписи?).

Но если в примерах выше судебный орган не видит то, что есть, то применительно к выбору способа подтверждения он видит то, чего нет. Закон не требует нотариального подтверждения решения о выборе способа подтверждения. Он говорит только о том, что решение принимается единогласно всеми участниками общества. Верховный Суд считает иначе.

Отдельно хочется обратить внимание на то, что Обзор начинает действовать со дня его опубликования. То есть Верховный Суд отменил решения нижестоящих судов по двум отдельно взятым делам, которые и легли в основу пунктов 2 и 3 Обзора, а остальным в обжаловании отказал? Похоже, у нас с Верховным Судом очень разное понимание слов «единообразное применение судами законодательства Российской Федерации, а также устранение противоречивых подходов при рассмотрении сходных юридических дел».

И ещё про «единообразие». Прелесть закона в том, что он должен быть более или менее внятно и однозначно сформулирован. Про обзор этого не скажешь. Если в Обзоре говорится только про ООО, значит ли это, что он не распространяется на АО? Если Обзор распространяет требования к собраниям участников на решения единственных участников, значит ли это, что их можно распространить и на решения учредителей? Если закон не видит разницы между решениями собраний и решениями участников, то можно ли принимать решения единственных участников заочно? И прочая, и прочая…

Если подытожить, то ситуация выглядит так — судебный орган взял на себя функции законодательного, а исполнительный не спешит работать по установленным им правилам. И это всё не слишком похоже на устойчивую конструкцию.

Оформление протокола заседания

Ответьте, пожалуйста, на два вопроса относительно оформления ­протокола заседания / собрания:

Если в повестку дня включается вопрос информативного характера, например, «О ходе строительства…», то:

• Необходимо ли выносить какое-либо решение типа: «Принять ­к сведению». Или можно вопрос оставить без постановляющей части?
• Нужно ли такие вопросы вообще включать в повестку дня?

Всегда ли в протоколе необходимо хотя бы кратко приводить содержание выступлений в ходе обсуждения вопроса, требующего принятия решения, или можно просто указать: «Проведено обсуждение…» и далее ­«Постановили (решили)»?

Ответ на первый вопрос читателя содержится в самом определении протокола как вида документа: протокол – документ, фиксирующий ход обсуждения вопросов и принятия решений на собраниях, совещаниях, конференциях и заседаниях коллегиальных органов, т.е. процесс принятия управленческих решений и сами решения.

Итак, протокол содержит запись хода обсуждения вопросов и принятия решений по ним. Если делается обычный доклад информационного характера, который не подлежит обсуждению и по нему не принимается никаких решений,то нет смысла включать его в виде отдельного пункта в повестку дня. Тогда и решение типа «Принять к сведению» записывать в протоколе не потребуется.

Если вопрос читателя следует понимать как вопрос о том, допустимо ли в принципе писать формулировку «Принять к сведению» в качестве принятого решения, то ответ на него будет утвердительным. Да, допустимо. Ведь даже в образце оформления краткого протокола, который приведен в приложении № 10 к Типовой инструкции по делопроизводству в федеральных органах исполнительной власти, такая формулировка принятого решения присутствует (см. Пример 2).

Но в реальной практике управленческой деятельности «голое информирование» встречается крайне редко. Да и ход строительства требует постоянного контроля. Как минимум по итогам такого доклада может быть принято решение о назначении следующей даты информирования о ходе строительст­ва, например, через месяц на следующем заседании или в виде письменного отчета, предоставленного конкретным должностным лицам.

Итак, вопрос «О ходе строительства…» может носить не только информативный характер. В зависимости от хода строительства присутствующие на заседании / собрании могут:

• либо одобрить его (если все идет по заранее намеченному плану),
• либо принять решение о необходимости экстренных мер для выправления ситуации, о сдвиге сроков, об изменении плана работ и т.д.,
• а также назначить дату и форму следующей «контрольной точки».

Получается, что по итогам доклада о ходе строительства коллегиальное решение все-таки принимается. Тогда его формулировку и нужно ­зафиксировать в протоколе в части «ПОСТАНОВИЛИ (РЕШИЛИ)».

Ответить на второй вопросчитателя нам помогут правила оформления протокола, которые содержатся в Типовой инструкции по делопроизводст­ву в федеральных органах исполнительной власти (утверждена приказом Минкультуры России от 08.11.2005 г. № 536).

Текст протокола состоит из двух частей:

• вводной и
• основной.

Образец полного протоколам. в Примере 1.

Во вводной части указываются председатель, секретарь и присутствующие (приглашенные). Вводная часть протокола заканчивается повесткой дня – перечнем рассматриваемых вопросов, перечисленных в порядке их значимости с указанием докладчика по каждому пункту повестки дня. Каждый вопрос нумеруется арабской цифрой, и его наименование ­начинается с предлога «О» («Об»), которое печатается от границы левого поля.

Основная часть протокола состоит из разделов в соответствии с пунктами повестки дня. Текст каждого раздела строится по схеме: «СЛУШАЛИ – ВЫСТУПИЛИ – ПОСТАНОВИЛИ (РЕШИЛИ)».

В части «ВЫСТУПИЛИ» указываются фамилии и инициалы всех выступивших по данному вопросу и краткое содержание их выступлений. Содержание выступления может быть оформлено отдельно, тогда в протоколе делается сноска «текст выступления прилагается» (см. раздел 2 протокола из Примера 1).

Если выступлений и обсуждений не было, то часть «ВЫСТУПИЛИ» просто не включается; тогда этот раздел протокола будет состоять только из двух частей: «СЛУШАЛИ» и «ПОСТАНОВИЛИ (РЕШИЛИ)» (см. раздел 1 протокола из Примера 1).

Пример 1

В практике делопроизводства применяется также краткий протокол, когда не требуется подробная запись хода обсуждения вопросов. Его форму мы привели в Примере 2.

В таком протоколе указывают только:

• список присутствующих,
• рассматриваемые вопросы и
• принятые решения.

Для начала посмотрим, как Типовая инструкция по делопроизводству в федеральных органах исполнительной власти предписывает оформлять краткую форму протокола. При этом напомним, что положения данного документа являются обязательными лишь для федеральных органов исполнительной власти. Остальные организации могут по собственному желанию заимствовать для себя формы документов и технологии работы, описанные в Типовой инструкции.

Фрагмент документа

Отметим, что в предыдущей Типовой инструкции по делопроизводству в федеральных органах исполнительной власти, утвержденной приказом Рос­архива от 27.11.2000 г. № 68 и в настоящее время утратившей силу, не было положений, посвященных краткому протоколу. Т.е. раньше оформление кратких протоколов не регламентировалось на федеральном уровне, поэтому они оформлялись в соответствии с инструкцией по делопроизводству конкретной организации. А инструкции по делопроизводству организаций в свою очередь составлялись на основе практического опыта, который был изложен в любом учебнике по делопроизводству.

В Типовой инструкции по делопроизводству в федеральных органах исполнительной власти, действующей сейчас (утв. приказом Минкультуры России от 08.11.2005 г. № 536), появился пункт 2.7.3.4, посвященный краткому протоколу. Поэтому инструкции по делопроизводству, разрабатываемые федеральными органами исполнительной власти, должны содержать такие же требования к оформлению краткого протокола. При этом отметим, что в требованиях, изложенных в пункте 2.7.3.4 Типовой инструкции, существуют «инновации в оформлении», которые не характерны для общепринятой практики оформления кратких протоколов. К ним в первую очередь можно отнести:

• исключение из вводной части повестки дня;
• центрирование наименования вопроса и подчеркивание его одной чертой ниже последней строки;
• оформление информации о присутствующих;
• правила оформления основной части.

Для наглядности покажем приложение № 10 к действующей Типовой инструкции по делопроизводству в федеральных органах исполнительной власти, которое содержит образец оформления краткого протокола:

Пример 2

Надо ли ставить печать на протоколе общего собрания участников ООО, а также печать на его сшиве? Участники — два юридических лица.

Мария в ответ на Ваши вопросы можем сообщить следующее:

В Уставе ООО С нет указания на то, каким числом голосов принимаются решения по передачи полномочий единоличного исполнительного органа общества?

В соответствии с пп. 4 п. 2 ст. 33 Федеральный закон от 8 февраля 1998 г. № 14-ФЗ «Об обществах с ограниченной ответственностью» (далее Закон) к компетенции общего собрания участников общества относится образование исполнительных органов общества и досрочное прекращение их полномочий.

Согласно п. 8 ст. 37 Закона решения о досрочном прекращении полномочий исполнительных органов принимаются большинством голосов от общего числа голосов участников общества, если иное не предусмотрено уставом общества.

Таким образом, решение по передачи полномочий единоличного исполнительного органа общества принимается большинством голосов от общего числа голосов участников ООО С.

Уставной капитал составляет 10000 р. Участник А внес в уставной капитал всю эту сумму, получается две доли. Означает ли это нарушение участником В обязанности по оплате доли в 5000 р. и как следствие выход из общества. Может ли это означать, что он не имеет право подавать иск?

В соответствии с п. 1 ст. 16 Закона каждый учредитель общества должен оплатить полностью свою долю в уставном капитале общества в течение срока, который определен договором об учреждении общества и не может превышать один год с момента государственной регистрации общества.

Не допускается освобождение учредителя общества от обязанности оплатить долю в уставном капитале общества.

Пунктом 3 ст. 16 Закона предусмотрено, что в случае неполной оплаты доли в уставном капитале общества неоплаченная часть доли переходит к обществу. Такая часть доли должна быть реализована обществом в порядке и в сроки, которые установлены статьей 24 Закона.

Доля учредителя общества, если иное не предусмотрено уставом общества, предоставляет право голоса только в пределах оплаченной части принадлежащей ему доли.

Таким образом, следует что участник А является единственным участником ООО С, т. к. им оплачено 100 % доли в уставном капитале ООО С (при наличии письменных доказательств уплаты 100% доли УК ООО С).

Следовательно, «участник» В не является участником ООО С и имеет право подать какой-либо иск на общих основаниях, т. е. как гражданин-не участник ООО С.

Можно ли рассчитывать на признание решения общего собрания участников ООО действительным при существенном нарушении порядка его созыва?

Согласно п. 1 ст. 43 Закона решение общего собрания участников общества, принятое с нарушением требований Закона, иных правовых актов Российской Федерации, устава общества и нарушающее права и законные интересы участника общества, может быть признано судом недействительным по заявлению участника общества, не принимавшего участия в голосовании или голосовавшего против оспариваемого решения.

Пунктом 2 ст. 43 Закона предусмотрено, что суд вправе с учетом всех обстоятельств дела оставить в силе обжалуемое решение, если голосование участника общества, подавшего заявление, не могло повлиять на результаты голосования, допущенные нарушения не являются существенными и решение не повлекло причинение убытков данному участнику общества.

Нарушения Закона и иных нормативных правовых актов Российской Федерации, допущенные при созыве общего собрания участников общества, оцениваются судом при рассмотрении иска об обжаловании соответствующего решения общего собрания участников общества (п. 5 ст. 43 Закона).

Согласно п. 1 ст. 71 Арбитражного процессуального кодекса Российской Федерации от 24 июля 2002 г. N 95-ФЗ (далее АПК РФ) Арбитражный суд оценивает доказательства по своему внутреннему убеждению, основанному на всестороннем, полном, объективном и непосредственном исследовании имеющихся в деле доказательств.

Доказательство признается арбитражным судом достоверным, если в результате его проверки и исследования выясняется, что содержащиеся в нем сведения соответствуют действительности (п. 3 ст. 71 АПК РФ)

Каждое доказательство подлежит оценке арбитражным судом наряду с другими доказательствами (п. 4 ст. 71 АПК РФ).

Никакие доказательства не имеют для арбитражного суда заранее установленной силы (п. 5 ст. 71 АПК РФ)

Арбитражный суд не может считать доказанным факт, подтверждаемый только копией документа или иного письменного доказательства, если утрачен или не передан в суд оригинал документа, а копии этого документа, представленные лицами, участвующими в деле, не тождественны между собой и невозможно установить подлинное содержание первоисточника с помощью других доказательств (п. 6 ст. 71 АПК РФ).

Результаты оценки доказательств суд отражает в судебном акте, содержащем мотивы принятия или отказа в принятии доказательств, представленных лицами, участвующими в деле, в обоснование своих требований и возражений (п. 7 ст. 71 АПК РФ).

Таким образом, признание решения общего собрания участников ООО С действительным либо недействительным при условии существенного нарушения порядка его созыва осуществляется судом с учетом всех имеющихся по делу доказательств.

Ставится ли печать на протоколе

Вконтакте

Facebook

Twitter

Google+

Одноклассники

Здравствуйте, в этой статье мы постараемся ответить на вопрос «Ставится ли печать на протоколе». Также Вы можете бесплатно проконсультироваться у юристов онлайн прямо на сайте.

Указанный закон раскрывает проведения порядок собраний акционерными обществами, устанавливает форме к требования документов общества.

Например, отдел кадров передает документы о трудоустройстве сотрудников в органзацию бухгалтерии для расчета заработной платы.

Нужна ли печать на протоколе общего собрания участников тоо

Все виды и разновидности протоколов, независимо от принадлежности к системе или подсистеме документации, классифицируются по двум основаниям – способу документирования и степени полноты записи хода заседания, которые действуют одновременно.
Разновидностью краткого протокола является протокол, составленный по сокращенной форме, которая предусматривает краткое последовательное изложение рассмотренных вопросов по схеме «вопрос – принятое решение».

Акты, протоколы. Состав реквизитов акта и протокола. Расположение реквизитов на бланке А4. Требования к оформлению акта и протокола.

Выдаваемые копии нумеруются, а сведения о них вносятся в реестр выданных копий, где получатель копии расписывается.
Нет не нужна. Проверено. Получаешь справку о дтп сразу после дтп и хоть на следующий день иди в страховую.

Нужно ли ставить печать в протокол собрания участников ООО о ликвидации

Протокол – документ, фиксирующий ход заседания и порядок принятия решений коллегиальным органом.

При оформлении дорожно-транспортного происшествия с помощью сотрудников ГИБДД участникам ДТП выдается справка установленной формы.

А на протоколе общего собрания участников нужно ставить печать общества или достаточно подписей участников? Как надлежит оформить протокол общего собрания участников ООО. Получается, если протокол состоит из трех листов не нужно, чтоб каждый лист подписывали все участники?

Вопрос №1. Какое наименование документа о приеме на работу считать правильным – «Приказ» или «Распоряжение»?

Помогите пожалуйста найти информацию по вопросу: нужно ли ставить печать в протокол внеочередного собрания участников ООО о ликвидации?

Подп. 3 пункта 3 статьи 67.1 ГК РФ устанавливает несколько способов подтверждения принятия общим собранием участников ООО решения и состава участников общества, присутствовавших при его принятии.

За расписание директора выходят приказы и указания, обязательны которые для исполнения всеми работниками Согласно.

К тому же сейчас в России вступил в действие ГОСТ Р ИСО 15489-1-2007 «Система стандартов по информациии, библиотечному и издательскому делу. Управление документами. Общие требования». А его основная идея состоит в том, что организации необходимо «прописать», утвердить правила управления документацией и им следовать.

Условия установлены положениями Трудового кодекса РФ. Форма была стандартизирована Постановлением Госкомстата №1 от 05.01. 2004 г. В этом Постановлении приняты две формы, согласно которым составляется приказ о приеме на работу:

• бланк № Т-1, составляемый при приеме на работу одного служащего;
• форма № Т-1а для одновременного приема нескольких человек.

Выписка из протокола представляет собой точную копию части текста подлинного протокола, относящегося к тому вопросу повестки дня, по которому готовят выписку. При этом воспроизводят все реквизиты бланка, вводную часть текста, тот вопрос повестки дня, по которому готовится выписка, а также текст, отражавший его обсуждение и принятое по нему решение.

Все вышеуказанные как, лица правило, вступают между собой в трудовые и корпоративные отношения, которые не могут повлечь за изменения собой прав и обязанностей для других обществ хозяйственных, если эти общества изначально не корпоративными связаны отношениями.

Наименование вопроса нумеруется римскими цифрами, начинается с предлога «О» или «Об», печатается центрованно и подчеркивается.

Все вышеуказанные как, лица правило, вступают между собой в трудовые и корпоративные отношения, которые не могут повлечь за изменения собой прав и обязанностей для других обществ хозяйственных, если эти общества изначально не корпоративными связаны отношениями.

Согласна с brick. Плюс хочу добавить: «банк требует с печатью» — это значит на копии надо написать «копия верна» и поставить печать.

ставится ли на подписи в протоколе печать

На практике ситуация с приложениями к протоколу существенно отличается от региона к региону и от местности к местности: в одних случаях к протоколу фактически не прилагается ничего, в других — приложения сдаются по подробному перечню.
Следует отметить, что слова «акт» и «реестр» допускают узкое и широкое толкование: узкий, буквальный смысл означает «документ, озаглавленный как акт (реестр)»; в широком смысле слово «акт» означает произвольный официальный документ (например, «правовой акт», «судебный акт»), а слово «реестр» — произвольный перечень.

Настоящий сайт не является средством массовой информации. В качестве печатного СМИ журнал «Упрощёнка» зарегистрирован Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор).

Протокол подписывается в двух экземплярах, на каждом экземпляре проставляется номер (1 или 2). Время подписания протокола на обоих экземплярах должно быть одинаковым.

Однако, если протокол содержит более 2 листов, то его желательно прожить и заверить сшивку подписью председательствующего и печатью Общества.

Нужно ли ставить печать на протоколе общего собрания ?

На лицо техническая ошибка, которая не повлечет указанных последствий. К тому же регистрирующий орган не проводит сверку паспортных данных — это вне его компетенции.
Выписка – это документ аналогичный приказу, но содержащий сведения только об одном сотруднике, устроенном в организацию.

Один из указанных способов может быть определен единогласным решением общего собрания участников общества при проведении общего собрания либо установлен в уставе ООО.

Типовая инструкция по делопроизводству в федеральных органах исполнительной власти (далее именуется – Типовая инструкция) устанавливает общие требования к функционированию служб документационного обеспечения управления, документированию управленческой деятельности и организации работы с документами ­в федеральных органах исполнительной власти – министерствах, службах, агентствах.

Регистрация ООО: основные этапы и необходимые документы

Располагается после наименования вида документа (ПРОТОКОЛ) перед датой, номером и местом составления документа.

Не заполнено обязательное поле Подтверждение пароля. Необходимо согласие на обработку персональных данных. Д анная статья — наглядное методическое пособие по оформлению протоколов. Она поможет вам правильно и быстро создать протокол. Она пригодится и когда вы решите научить этому своих коллег, чтобы избавить себя от необходимости исправлять допускаемые ими ошибки.

Таким образом наличие синей круглой печати на оригинале справки о ДТП не предусмотрено. Копия справки о ДТП может быть заверена синей круглой печатью.

Напротив, все вышеперечисленные выражения способы воли лица могут применяться заключения для некоторых сделок.

Что делать если кто-то из участников собрания учредителей голосует «против»

Поймите, что «важный» документ — это еще не повод ставить на него печать. Приказ издается руководителем, печатается в ед. числе, регистрируется в …20 нояб. 2012 г.

Друкувати RSS. Точка зору. Читацький Про сайт. Головна ДК. Бланки, форми. Попередня тема Наступна тема. Инна Товарищи, срочно, на протоколе сборов учредителей ставится печать фирмы? Re: Товарищи, срочно, на протоколе сборов учредителей ставится печать фирмы? Инна Re: Товарищи, срочно, на протоколе сборов учредителей ставится печать фирмы?

Затем ставятся подписи кадровика, руководителя и вновь принятого работника. Нумеруются приказы формы Т-1 с начала года и регистрируются в специальном журнале, который оформляется при открытии предприятия. Печать предприятия обязательна для проставления при наличии локального приказа руководителя.

Розширений пошук по форуму :: по порталу. Товарищи, срочно, на протоколе сборов учредителей ставится печать фирмы? У нас ставят. У нас банки требуют протоколы с печатями,поэтому ставим. Я всегда делала без печати. Недавно переписывала с другого шаблона, там МП было. Мое мнение — не ставится там печать.

Новости Инструменты Форум Барометр. Войти Зарегистрироваться. Вход для зарегистрированных:. Забыли пароль? Войти через:.

По некоторым функциям управления персоналом составляются протоколы заседаний аттестационных и квалификационных комиссий, которые входят в специальную подсистему кадровой документации.

Только правильно составленный и оформленный протокол в полной мере может обеспечить юридическую силу решений, которые принимаются на основе принципа коллегиальности. Мы подробно объясняем, как следует оформлять каждый реквизит этого документа. Отмечаем, что в оформлении протокола является обязательным, а что факультативным.

Ставится ли печать на протокол общего собрания участников ооо

После принятия федерального закона от 06.04.2015 № 82-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части отмены обязательности печати хозяйственных обществ» печать перестала быть обязательной для многих работодателей. Действующее законодательство обязывает иметь печати следующим организациям (перечень не является исчерпывающим):

• некоммерческих организаций;
• государственных, муниципальных унитарных предприятий;
• жилищных накопительных кооперативов.

А также в банке просят указывать НДС, хотя попадалось письмо НБУ, что это требование не соответствует нормативной базе. В одном банке хватило протокола, в другом еще и приказ нужен. Это не означает, что они правы, но часто гораздо легче и быстрее сделать так, как хотят, чем доказать, что законодательство такого не требует.

Об утверждении изменений в ШР. 2. О назначении комиссии по охране труда. 3.Приказ о приеме на работу :: Форум ::кадровый портал …7 дек 2012печать на приказах :: Форум ::кадровый портал КАДРОВИК.РУ25 ноя 2012Печать на приказах :: Форум ::кадровый портал КАДРОВИК.

Вконтакте

Facebook

Twitter

Google+

Одноклассники

Похожие записи:

Печать перекрывает подпись. Можно ли установить подлинность?

Дизайнер Артемий Лебедев ворвался в юриспруденцию, написав пост в фейсбуке следующего содеражания:

«Всю свою жизнь я жил неправильно. По счастью, у меня очень хороший и грамотный нотариус (она).

Как и все люди на свете, я был уверен, что любому документу придает веса, солидности и юридической неподкопности печать, поставленная прямо на подпись.

Пха-ха-ха!

Оказалось, что все ровно наоборот. Если печать хоть немного перекрывает подпись, то в случае экспертизы ни один криминалист не признает ни подпись, ни печать, если одно стоит на другом. Подпись и печать должны быть полностью независимо различимы.

Обязательно расскажите это своим юристам, адвокатам, менеджерам и молодым нотариусам». 

(Ссылка на пост: https://www.facebook.com/temalebedev/posts/10158970493311095)

Юристы сразу разоблачили дилетанта в комментариях: нормальный эксперт/криминалист всегда найдёт способ определить её подлинность, и тот факт, что оттиск печати частично перекрывает подпись не проблема.

Первоначально готов был поддержать коллег-комментаров, но после ознакомления с имеющейся судебной практикой, моё мнение изменилось.

В одном деле апелляционный суд указал: «Согласно экспертному заключению N 7654/2-3 от 01.08.2016, установить, соответствует давность выполнения подписи в графе «Директор ООО «ИнвестОйл» Окуневич В.А.» в Соглашении об отсутствии претензий по вопросу взыскания судебных расходов, датированном 17.08.2015, не представляется возможным в связи с тем, «данная подпись не пригодна для исследования, т. к. в штрихах подписи в графе «директор ООО «ИнвестОйл» Окуневич В.А.» основная ее часть перекрывается оттиском печати. В оставшейся части подписи отсутствует достаточное количество прямолинейных штрихов необходимых для проведения исследования с целью определения давности ее выполнения»» (постановление Девятнадцатого арбитражного апелляционного суда от 13.12.2016 N 19АП-7086/2016 по делу N А14-16708/2014).

В другом деле содержится схожий вывод: «При этом, исследовательской частью заключения констатирована невозможность ответа на поставленный вопрос вследствие исследования не оригинала документа, а его электрофотографической копии. Кроме того, эксперт отметил, что штрихи исследуемой подписи Шуляка Д.А. перекрыты оттиском печати, что в значительной мере затруднило процесс выявления идентификационных признаков. Таким образом, проведенной судебной экспертизой факт фальсификации подписи Шуляка Д.А. в спорном протоколе не подтвержден. Суд апелляционной инстанции исходит при этом из отсутствия однозначного вывода относительно фальсификации подписи Шуляка Д.А. на исследуемом протоколе ввиду представления эксперту только лишь копии протокола, повлекшего невозможность подготовки однозначного ответа на поставленный вопрос» (постановление Восемнадцатого арбитражного апелляционного суда от 26.12.2017 N 18АП-14971/2017 по делу N А76-24319/2016).

 Есть и противоположная судебная практика, в которой экспертам удавалось провести экспертизу подписи, перекрытой печатью. Поэтому вопрос возможности проведения экспертизы будет решаться в каждом конретном случае по-разному. 

Таким образом, в совете дизайнера, на мой взгляд, есть рациональное зерно.

Сетевая рабочая группа К. Адамс Запрос комментариев: 3161 Доверие Категория: Стандарты Track P. Cain BBN Д. Пинкас Integris Р.Zuccherato Доверить Август 2001 г. Инфраструктура открытых ключей Internet X.509 Протокол отметок времени (TSP) Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения. Пожалуйста, обратитесь к текущему выпуску «Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола.Распространение памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (2001). Все права защищены. Аннотация В этом документе описывается формат запроса, отправляемого в Time Stamping Authority (TSA) и возвращаемого ответа. Это также устанавливает несколько требований безопасности для TSA операция в отношении обработки запросов для генерации ответов. 1. Введение Служба отметки времени поддерживает утверждения о том, что данные существовали до определенного времени.TSA может работать как доверенный Услуга третьей стороны (TTP), хотя другие операционные модели могут быть уместным, например, организация может потребовать TSA для внутренних в целях отметки времени. Службы неотказуемости [ISONR] требуют возможности установить наличие данных до указанного времени. Этот протокол можно использовать как строительный блок для поддержки таких услуг. Пример того, как доказать, что цифровая подпись была создана во время срока действия Срок действия сертификата открытого ключа указан в приложении.Адамс и др. Стандарты Track [Страница 1] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе (в верхний регистр, как показано) следует интерпретировать, как описано в [RFC2119]. Чтобы связать данные с определенным моментом времени, Время Возможно, потребуется использовать Stamp Authority (TSA). Эта доверенная третья сторона предоставляет «доказательство существования» для этой конкретной информации в мгновенно во времени.Роль TSA состоит в том, чтобы поставить отметку времени для получения доказательств. что указывает на то, что данные существовали до определенного времени. Это может затем использоваться, например, для проверки того, что цифровая подпись была применяется к сообщению до соответствующего ce

Network Working Group C. Adams Запрос комментариев: 3161 Доверие Категория: Стандарты Track P. Cain BBN Д.Пинкас Integris Р. Зуккерато Доверить Август 2001 г. Инфраструктура открытых ключей Internet X.509 Протокол отметок времени (TSP) Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения.Пожалуйста, обратитесь к текущему выпуску «Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола. Распространение памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (2001). Все права защищены. Аннотация В этом документе описывается формат запроса, отправляемого в Time Stamping Authority (TSA) и возвращаемого ответа. Это также устанавливает несколько требований безопасности для TSA операция в отношении обработки запросов для генерации ответов.1. Введение Служба отметки времени поддерживает утверждения о том, что данные существовали до определенного времени. TSA может работать как доверенный Услуга третьей стороны (TTP), хотя другие операционные модели могут быть уместным, например, организация может потребовать TSA для внутренних в целях отметки времени. Службы неотказуемости [ISONR] требуют возможности установить наличие данных до указанного времени. Этот протокол можно использовать как строительный блок для поддержки таких услуг.Пример того, как доказать, что цифровая подпись была создана во время срока действия Срок действия сертификата открытого ключа указан в приложении. Адамс и др. Стандарты Track [Страница 1] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе (в верхний регистр, как показано) следует интерпретировать, как описано в [RFC2119].Чтобы связать данные с определенным моментом времени, Время Возможно, потребуется использовать Stamp Authority (TSA). Эта доверенная третья сторона предоставляет «доказательство существования» для этой конкретной информации в мгновенно во времени. Роль TSA состоит в том, чтобы поставить отметку времени для получения доказательств. что указывает на то, что данные существовали до определенного времени. Это может затем использоваться, например, для проверки того, что цифровая подпись была применено к сообщению до того, как соответствующий сертификат был отозван тем самым позволяя использовать отозванный сертификат открытого ключа для проверка подписей, созданных до момента отзыва.Этот является важной операцией инфраструктуры открытого ключа. TSA может также может использоваться для обозначения времени подачи, когда крайний срок критический, или указать время транзакции для записей в журнал. Исчерпывающий список возможных вариантов использования TSA выходит за рамки объем этого документа. Этот стандарт не устанавливает общих требований безопасности для Работа TSA, как и другие стандарты PKIX, не устанавливает таких требования к работе ЦС. Скорее предполагается, что TSA ознакомит потенциальных клиентов с политикой, которую он реализует обеспечить точную генерацию меток времени, и клиенты будут использовать услуги TSA, только если они уверены, что эти политики удовлетворить их потребности.2. TSA TSA — это TTP, который создает токены с отметками времени, чтобы указать что данные существовали в определенный момент времени. В остальной части этого документа «действительный запрос» означает один который может быть правильно декодирован, имеет форму, указанную в разделе 2.4, и от поддерживаемого подписчика TSA. 2.1. Требования TSA TSA ТРЕБУЕТСЯ: 1. использовать надежный источник времени. 2. включить достоверное значение времени для каждого токена отметки времени.3. включить уникальное целое число для каждой вновь созданной отметки времени токен. Адамс и др. Стандарты Track [Страница 2] RFC 3161 Протокол отметок времени (TSP), август 2001 г. 4. для создания токена с отметкой времени при получении действительного запроса от запрашивающего, когда это возможно. 5. включить в каждый токен отметки времени идентификатор для однозначно указать политику безопасности, в соответствии с которой токен был создан.6. поставить отметку времени только для хэш-представления данных, т.е. отпечаток данных, связанный с устойчивостью к одностороннему столкновению хэш-функция, однозначно идентифицируемая по OID. 7. проверить OID хэша, устойчивого к односторонним столкновениям. функция и убедиться, что длина хеш-значения согласована с хеш-алгоритмом. 8. никоим образом не проверять отпечаток с отметкой времени (другое чем проверить его длину, как указано в предыдущем пункте).9. не включать никакую идентификацию запрашивающего лица в жетоны отметок времени. 10. подписывать каждый токен с отметкой времени, используя исключительно сгенерированный ключ для этой цели и иметь это свойство ключа, указанное на соответствующий сертификат. 11. включить дополнительную информацию в маркер отметки времени, если запросил запрашивающий, используя поле расширений, только для расширения, которые поддерживаются TSA. Если это не так возможно, TSA ДОЛЖЕН ответить сообщением об ошибке.2.2. Транзакции TSA В качестве первого сообщения этого механизма запрашивающий объект запрашивает токен с отметкой времени, отправляя запрос (который или включает TimeStampReq, как определено ниже) к метке времени Орган власти. Во втором сообщении администрация отметки времени отвечает, отправляя ответ (который является или включает TimeStampResp, как определено ниже) запрашивающему объекту. После получения ответа (который является или включает TimeStampResp который обычно содержит TimeStampToken (TST), как определено ниже), запрашивающий объект ДОЛЖЕН проверить ошибку статуса, возвращенную в ответ, и если ошибок нет, он ДОЛЖЕН проверить различные поля, содержащиеся в TimeStampToken, и срок действия цифровая подпись TimeStampToken.В частности, ДОЛЖНА проверьте, что то, что было отмечено временем, соответствует тому, что было запрошено с отметкой времени. Запрашивающая сторона ДОЛЖНА проверить, что TimeStampToken содержит правильный идентификатор сертификата Адамс и др. Стандарты Track [Страница 3] RFC 3161 Протокол отметок времени (TSP), август 2001 г. TSA, правильный отпечаток данных и правильный OID хеш-алгоритма. Это Затем ДОЛЖЕН проверять своевременность ответа, проверяя либо время, включенное в ответ, относительно местного доверенного времени ссылка, если она доступна, или значение одноразового номера (большой случайное число с высокой вероятностью того, что оно генерируется клиент только один раз) включен в ответ против включенного значения в запросе.Для получения дополнительных сведений об обнаружении атаки повторного воспроизведения см. раздел соображений безопасности (пункт 6). Если любой из вышеперечисленные проверки завершаются неудачно, TimeStampToken ДОЛЖЕН быть отклонен. Затем, поскольку сертификат TSA мог быть отозван, статус сертификата СЛЕДУЕТ проверять (например, путем проверки соответствующий CRL), чтобы убедиться, что сертификат все еще действителен. Затем клиентскому приложению СЛЕДУЕТ проверить поле политики, чтобы определить, была ли выпущена политика, в соответствии с которой был выпущен токен приемлемо для приложения.2.3. Идентификация TSA TSA ДОЛЖЕН подписывать каждое сообщение с отметкой времени с зарезервированным ключом. специально для этой цели. TSA МОЖЕТ иметь отдельные закрытые ключи, например, чтобы приспособить разные политики, разные алгоритмы, различные размеры закрытых ключей или для повышения производительности. В соответствующий сертификат ДОЛЖЕН содержать только один экземпляр расширение поля расширенного использования ключа, как определено в разделе [RFC2459] 4.2.1.13 со значением KeyPurposeID: id-kp-timeStamping.Это расширение ДОЛЖНО быть критичным. Следующий идентификатор объекта идентифицирует KeyPurposeID, имеющий значение id-kp-timeStamping. id-kp-timeStamping ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) идентифицированная организация (3) dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) kp (3) timestamping (8)} 2.4. Форматы запросов и ответов 2.4.1. Формат запроса Запрос с отметкой времени выглядит следующим образом: TimeStampReq :: = SEQUENCE { версия INTEGER {v1 (1)}, messageImprint MessageImprint, — OID хеш-алгоритма и хеш-значение данных, которые нужно Адамс и др.Стандарты Track [Страница 4] RFC 3161 Протокол отметок времени (TSP), август 2001 г. — с отметкой времени reqPolicy TSAPolicyId ДОПОЛНИТЕЛЬНО, nonce INTEGER ДОПОЛНИТЕЛЬНО, certReq BOOLEAN DEFAULT FALSE, расширения [0] IMPLICIT Extensions OPTIONAL} Поле версии (в настоящее время v1) описывает версию Time- Гербовый запрос. Поле messageImprint ДОЛЖНО содержать хэш данных, которые необходимо с отметкой времени.Хэш представлен в виде СТРОКИ ОКТЕТОВ. это длина ДОЛЖНА соответствовать длине хеш-значения для этого алгоритма (например, 20 байтов для SHA-1 или 16 байтов для MD5). MessageImprint :: = SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING} Алгоритм хеширования, указанный в поле hashAlgorithm, ДОЛЖЕН быть известный алгоритм хеширования (односторонний и устойчивый к коллизиям). Это означает что он ДОЛЖЕН быть односторонним и устойчивым к столкновениям.Штамп времени Власти ДОЛЖНЫ проверить, является ли данный алгоритм хеширования заведомо «достаточным» (на основании текущего уровня знаний в криптоанализ и современное состояние вычислительной техники ресурсы, например). Если TSA не распознает хеш алгоритм или знает, что алгоритм хеширования слабый (решение осталось на усмотрение каждого отдельного TSA), то TSA ДОЛЖЕН отказать чтобы предоставить маркер отметки времени, вернув pkiStatusInfo из ‘bad_alg’.Поле reqPolicy, если включено, указывает политику TSA в который ДОЛЖЕН быть предоставлен TimeStampToken. TSAPolicyId определен следующим образом: TSAPolicyId :: = ИДЕНТИФИКАТОР ОБЪЕКТА Одноразовый номер, если он включен, позволяет клиенту проверять своевременность ответ, когда местные часы недоступны. Одноразовый номер — это большой случайное число с большой вероятностью, что клиент его сгенерирует только один раз (например, 64-битное целое число). В таком случае тот же одноразовый номер значение ДОЛЖНО быть включено в ответ, в противном случае ответ должен быть отклоненным.Если поле certReq присутствует и имеет значение true, открытый ключ TSA сертификат, на который ссылается идентификатор ESSCertID внутри Атрибут SigningCertificate в ответе ДОЛЖЕН предоставляться TSA в поле сертификатов из структуры SignedData в этом ответ. Это поле может также содержать другие сертификаты. Адамс и др. Standards Track [Страница 5] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Если поле certReq отсутствует или присутствует поле certReq и установите значение false, затем поле сертификатов из SignedData структура НЕ ДОЛЖНА присутствовать в ответе.Поле расширений — это общий способ добавить дополнительную информацию. на запрос в будущем. Расширения определены в [RFC 2459]. Если расширение, помечено ли оно как критическое или некритическое, используется запрашивающей стороной, но не распознается сервером отметок времени, сервер НЕ ДОЛЖЕН выпускать токен и ДОЛЖЕН возвращать ошибку (unacceptedExtension). Запрос отметки времени не идентифицирует инициатора запроса, так как это информация не подтверждена TSA (см. раздел 2.1). В ситуации, когда TSA требует идентификации запрашивающего объекта, должны быть предусмотрены альтернативные средства идентификации / аутентификации. используется (например, инкапсуляция CMS [CMS] или аутентификация TLS [RFC2246]). 2.4.2. Формат ответа Ответ с отметкой времени выглядит следующим образом: TimeStampResp :: = SEQUENCE { статус PKIStatusInfo, timeStampToken TimeStampToken ДОПОЛНИТЕЛЬНО} Статус основан на определении статуса в разделе 3.2.3. из [RFC2510] следующим образом: PKIStatusInfo :: = SEQUENCE { статус PKIStatus, statusString PKIFreeText ДОПОЛНИТЕЛЬНО, failInfo PKIFailureInfo ДОПОЛНИТЕЛЬНО} Когда статус содержит значение ноль или единицу, TimeStampToken ДОЛЖЕН присутствовать.Когда статус содержит значение, отличное от нуля или единицы, TimeStampToken НЕ ДОЛЖЕН присутствовать. Одно из следующих значений ДОЛЖНО содержаться в статусе: PKIStatus :: = INTEGER { предоставлено (0), — когда PKIStatus содержит нулевое значение TimeStampToken, как запрошено, присутствует. предоставленоWithMods (1), — когда PKIStatus содержит значение, равное TimeStampToken, с доработками, присутствует. отказ (2), ожидание (3), revocationWarning (4), Адамс и др.Standards Track [Страница 6] RFC 3161 Протокол отметок времени (TSP), август 2001 г. — это сообщение содержит предупреждение о том, что отзыв — неизбежный revocationNotification (5) — уведомление о том, что произошел отзыв} Совместимые серверы НЕ ДОЛЖНЫ выдавать другие значения. Соответствует клиенты ДОЛЖНЫ генерировать ошибку, если значения, которые он не понимает, подарок. Когда TimeStampToken отсутствует, failInfo указывает причина, по которой запрос отметки времени был отклонен и может быть одним из следующие значения.PKIFailureInfo :: = BIT STRING { badAlg (0), — нераспознанный или неподдерживаемый идентификатор алгоритма badRequest (2), — транзакция не разрешена или не поддерживается badDataFormat (5), — представленные данные имеют неправильный формат timeNotAvailable (14), — источник времени TSA недоступен unacceptedPolicy (15), — запрошенная политика TSA не поддерживается TSA unacceptedExtension (16), — запрошенное расширение не поддерживается TSA addInfoNotAvailable (17) — запрошенная дополнительная информация непонятна — или недоступен systemFailure (25) — запрос не может быть обработан из-за сбоя системы} Это единственные значения PKIFailureInfo, которые ДОЛЖНЫ поддерживаться.Совместимые серверы НЕ ДОЛЖНЫ выдавать другие значения. Соответствует клиенты ДОЛЖНЫ генерировать ошибку, если значения, которые он не понимает, подарок. Поле statusString PKIStatusInfo МОЖЕТ использоваться для включения причины текст, например «поле messageImprint отформатировано неправильно». TimeStampToken выглядит следующим образом. Он определяется как ContentInfo ([CMS]) и ДОЛЖЕН инкапсулировать подписанный тип содержимого данных. TimeStampToken :: = ContentInfo — contentType — это id-signedData ([CMS]) — содержание — SignedData ([CMS]) Адамс и др.Стандарты Track [Страница 7] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Поля типа EncapsulatedContentInfo в SignedData конструкция имеют следующие значения: eContentType — это идентификатор объекта, который однозначно определяет Тип содержимого. Для токена с отметкой времени это определяется как: id-ct-TSTInfo ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2) us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) ct (1) 4} eContent — это сам контент, передаваемый в виде строки октетов.EContent ДОЛЖЕН быть значением TSTInfo в кодировке DER. Маркер отметки времени НЕ ДОЛЖЕН содержать никаких подписей, кроме подпись TSA. Идентификатор сертификата (ESSCertID) Сертификат TSA ДОЛЖЕН быть включен как атрибут signerInfo внутри Атрибут SigningCertificate. TSTInfo :: = SEQUENCE { версия INTEGER {v1 (1)}, политика TSAPolicyId, messageImprint MessageImprint, — ДОЛЖЕН иметь то же значение, что и аналогичное поле в — TimeStampReq serialNumber INTEGER, — Пользователи с отметкой времени ДОЛЖНЫ быть готовы к использованию целых чисел. — до 160 бит.genTime GeneralizedTime, точность Точность ДОПОЛНИТЕЛЬНАЯ, заказ BOOLEAN DEFAULT FALSE, nonce INTEGER ДОПОЛНИТЕЛЬНО, — ДОЛЖЕН присутствовать, если подобное поле присутствовало — в TimeStampReq. В этом случае он ДОЛЖЕН иметь такое же значение. tsa [0] GeneralName ДОПОЛНИТЕЛЬНО, extension [1] IMPLICIT Extensions OPTIONAL} Поле версии (в настоящее время v1) описывает версию времени- маркер жетон.Соответствующие серверы с отметками времени ДОЛЖНЫ иметь возможность предоставлять версию 1 жетоны отметок времени. Среди дополнительных полей ДОЛЖНО поддерживаться только поле nonce. Соответствующие запрашивающие метки времени ДОЛЖНЫ быть способны распознавать версию 1 жетон отметки времени со всеми необязательными полями присутствуют, но не обязано понимать семантику любого расширения, если оно есть. Адамс и др. Standards Track [Страница 8] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Поле политики ДОЛЖНО указывать политику TSA, в соответствии с которой ответ был произведен.Если бы подобное поле присутствовало в TimeStampReq, тогда он ДОЛЖЕН иметь то же значение, иначе ошибка (unacceptedPolicy) ДОЛЖЕН быть возвращен. Эта политика МОЖЕТ включать следующие типы информации (хотя этот список, конечно, не исчерпывающий): * Условия, при которых можно использовать маркер отметки времени. * Наличие журнала токенов с отметками времени, чтобы позволить позже проверка подлинности токена с отметкой времени. MessageImprint ДОЛЖЕН иметь то же значение, что и аналогичное поле в TimeStampReq при условии, что размер хеш-значения соответствует ожидаемый размер алгоритма хеширования, указанного в hashAlgorithm.Поле serialNumber — это целое число, присвоенное TSA каждому TimeStampToken. Он ДОЛЖЕН быть уникальным для каждого TimeStampToken, выпущенного заданный TSA (т. е. имя TSA и серийный номер идентифицируют уникальный TimeStampToken). Следует отметить, что свойство ДОЛЖНО быть сохраняется даже после возможного прерывания (например, краха) оказание услуг. genTime — это время, когда токен отметки времени был создан TSA. Это выражается как время UTC (всемирное координированное время) до уменьшить путаницу с использованием местного часового пояса.UTC — шкала времени, на основе второго (SI), определенного и рекомендованного CCIR, и поддерживается Международным бюро поид и мер (BIPM). А синонимом является «зулусское» время, которое используется в гражданской авиации и обозначается буквой «Z» (фонетически «зулусский»). Синтаксис ASN.1 GeneralizedTime может включать доли секунды Детали. Такой синтаксис, без ограничений из [RFC 2459] Раздел 4.1.2.5.2, где GeneralizedTime ограничивается представлением Здесь можно использовать время с точностью до секунды.Значения GeneralizedTime ДОЛЖНЫ включать секунды. Однако когда есть нет необходимости иметь точность лучше второй, тогда СЛЕДУЕТ использовать GeneralizedTime с точностью до одной секунды (как в [RFC 2459]). Синтаксис: ГГГГММДДччммсс [.s …] Z Пример: 1999060

26.34352Z X.690 | ISO / IEC 8825-1 устанавливает следующие ограничения для DER-кодирование. Адамс и др. Стандарты Track [Страница 9] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Кодирование ДОЛЖНО заканчиваться буквой «Z» (что означает «зулусское» время).В Элемент десятичной запятой, если он присутствует, ДОЛЖЕН быть опцией точки «.». В элементы дробных секунд, если они есть, ДОЛЖНЫ опускать все завершающие нули; если элементы соответствуют 0, они ДОЛЖНЫ быть полностью опущены, а элемент десятичной точки также ДОЛЖЕН быть опущен. Полночь (GMT) должна быть представлена ​​в виде: «ГГГГММДД000000Z». где «ГГГГММДД» представляет день после полуночи в вопрос. Вот несколько примеров правильных представлений: «19920521000000Z» «19920622123421Z» «19920722132100.3Z » точность представляет собой отклонение времени относительно времени UTC, содержащегося в GeneralizedTime. Точность :: = SEQUENCE { секунды INTEGER OPTIONAL, миллис [0] INTEGER (1..999) ДОПОЛНИТЕЛЬНО, микрос [1] INTEGER (1..999) ДОПОЛНИТЕЛЬНО} Если отсутствуют секунды, миллис или микросекунды, значение равно нулю. ДОЛЖЕН быть принят за отсутствующее поле. Добавляя значение точности к GeneralizedTime, верхний предел времени, когда маркер метки времени был создан TSA может быть получен.Таким же образом, вычитая точность из GeneralizedTime, нижний предел времени, в которое метка времени токен был создан TSA можно получить. точность может быть разложена на секунды, миллисекунды (от 1 до 999) и микросекунды (1-999), все выражены как целые числа. Если необязательное поле точности не указано, то точность может быть доступен с помощью других средств, например, TSAPolicyId. Если поле для заказа отсутствует или если поле для заказа присутствует и установлено значение false, тогда поле genTime указывает только время в токен временной отметки был создан TSA.В таком В этом случае заказ токенов с отметками времени, выпущенных тем же TSA или разные TSA возможны только тогда, когда разница между genTime первого токена отметки времени и genTime второго маркер отметки времени больше, чем сумма точности genTime для каждого токена отметки времени. Адамс и др. Standards Track [Страница 10] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Если поле упорядочивания присутствует и имеет значение true, каждая отметка времени токен из того же TSA всегда можно заказать на основе genTime независимо от точности genTime.Поле nonce ДОЛЖНО присутствовать, если оно присутствовало в TimeStampReq. В таком случае он ДОЛЖЕН равняться значению, указанному в Структура TimeStampReq. Назначение поля tsa — дать подсказку при идентификации название TSA. Если он присутствует, он ДОЛЖЕН соответствовать одному из имена субъектов, включенные в сертификат, который будет использоваться для проверить токен. Однако фактическая идентификация лица который подписал ответ, всегда будет происходить с использованием идентификатор сертификата (атрибут ESSCertID) внутри Атрибут SigningCertificate, который является частью signerInfo (см. Раздел 5 [ESS]).расширения — это общий способ добавления дополнительной информации в будущее. Расширения определены в [RFC 2459]. Конкретные типы полей расширения могут быть указаны в стандартах или могут быть определенным и зарегистрированным любой организацией или сообществом. 3. Транспорт В этом документе нет обязательного транспортного механизма для сообщений TSA. документ. Описанные ниже механизмы не являются обязательными; дополнительный дополнительные механизмы могут быть определены в будущем. 3.1. Протокол отметки времени с использованием электронной почты Этот раздел определяет средства для передачи ASN.1-закодированные сообщения для обмена протоколами, описанными в Разделе 2 и Приложении D, через Интернет-почта. Два объекта MIME указаны следующим образом: Тип содержимого: приложение / отметка-запрос Кодирование передачи содержимого: base64 > Тип содержимого: приложение / отметка времени-ответ Кодирование передачи содержимого: base64 > Эти объекты MIME могут быть соответственно отправлены и получены с использованием общих Механизмы обработки MIME и простой транспорт электронной почты в Интернете. для сообщений с отметкой времени.Адамс и др. Standards Track [Страница 11] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Для приложения / timestamp-query и application / timestamp-reply Типы MIME, реализации ДОЛЖНЫ включать необязательные «имя» и Параметры «имя файла». Включение имени файла помогает сохранить тип информация, когда запросы с отметкой времени и ответы сохраняются в виде файлов. Когда эти параметры включены, имя файла с соответствующим СЛЕДУЕТ выбрать расширение: Расширение файла типа MIME приложение / метка-запрос.TSQ приложение / отметка времени-ответ .TSR Кроме того, имя файла ДОЛЖНО быть ограничено восемью символами. с последующим трехбуквенным расширением. Имя файла из восьми символов base может быть любым отдельным именем. 3.2. Файловый протокол Файл, содержащий сообщение с отметкой времени, ДОЛЖЕН содержать только DER. кодирование одного сообщения TSA, т.е. НЕ ДОЛЖЕН быть постороннего заголовка или информацию о трейлере в файле. Такие файлы можно использовать для передавать сообщения с отметками времени, например, по FTP.Запрос отметки времени ДОЛЖЕН содержаться в файле с файлом расширение .tsq (например, запрос отметки времени). Ответ с отметкой времени ДОЛЖЕН содержаться в файле с расширением .tsr (например, Ответ с отметкой времени). 3.3. Протокол на основе сокетов Для транспорта будет использоваться следующий простой протокол на основе TCP. сообщений TSA. Этот протокол подходит для случаев, когда объект инициирует транзакцию и может опрашивать, чтобы получить результаты. Протокол в основном предполагает процесс слушателя на TSA, который может принимать сообщения TSA на четко определенный порт (номер порта IP 318).Обычно инициатор связывается с этим портом и отправляет начальный TSA. сообщение. Ответчик отвечает сообщением TSA и / или ссылочный номер, который будет использоваться позже при опросе фактического TSA ответ на сообщение. Если необходимо создать несколько ответных сообщений TSA для данного запрос (скажем, если квитанция должна быть отправлена ​​до того, как фактический токен может быть произведено), то также возвращается новая ссылка на опрос. Когда последнее ответное сообщение TSA было получено инициатор, то новая ссылка на опрос не предоставляется.Адамс и др. Стандарты Track [Страница 12] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Инициатор транзакции отправляет «прямое сообщение TSA на основе TCP» получателю. Получатель отвечает аналогичным сообщением. «Прямое сообщение TSA на основе TCP» состоит из: длина (32 бита), флаг (8 бит), значение (определено ниже) Поле длины содержит количество октетов оставшейся части сообщение (т.е., количество октетов «значение» плюс один). Все 32-битные значения в этом протоколе указываются в сетевом порядке байтов. Значение флага имени сообщения tsaMsg ’00’H Сообщение TSA в кодировке DER — Сообщение TSA pollRep ’01’H ссылка на опрос (32 бита), time-to-check-back (32 бита) — ответ на опрос, когда нет готового ответа на сообщение TSA; использовать опрос — контрольное значение (и расчетное значение времени) для последующего опроса pollReq ’02’H ссылка на опрос (32 бита) — запрос сообщения TSA, ответ на исходное сообщение negPollRep ’03’H’ 00’H — больше нет ответов на опрос (т.е., транзакция завершена) partialMsgRep ’04’H следующая ссылка опроса (32 бита), time-to-check-back (32 бита), Сообщение TSA в кодировке DER — частичный ответ (получение) на исходное сообщение плюс новый опрос — ссылка (и расчетная временная стоимость) для получения следующей части — ответ finalMsgRep ’05’H Сообщение TSA в кодировке DER — окончательный (и, возможно, единственный) ответ на исходное сообщение errorMsgRep ’06’H сообщение об ошибке, читаемое человеком — выдается при обнаружении ошибки (напр.g., ссылка на опрос — получен несуществующий или законченный) Последовательность сообщений, которые могут появиться, следующая: a) объект отправляет tsaMsg и получает одно из pollRep, negPollRep, partialMsgRep или finalMsgRep в ответ. б) конечный объект отправляет сообщение pollReq и получает одно из negPollRep, partialMsgRep, finalMsgRep или errorMsgRep в ответ. Параметр «time-to-check-back» представляет собой 32-разрядное целое число без знака. Это время в секундах, указывающее минимальный интервал, после которого клиент ДОЛЖЕН снова проверить статус.Он обеспечивает оценку времени, в течение которого конечный объект должен отправить его следующий опрос Адамс и др. Standards Track [Страница 13] RFC 3161 Протокол отметок времени (TSP), август 2001 г. 3.4. Протокол отметки времени через HTTP В этом подразделе описаны средства для передачи кодированных ASN.1 сообщения для обмена протоколами, описанными в разделе 2 и Приложение D через протокол передачи гипертекста. Два объекта MIME указаны следующим образом.Тип содержимого: приложение / отметка-запрос > Тип содержимого: приложение / отметка времени-ответ > Эти объекты MIME можно отправлять и получать с помощью обычного HTTP. движки обработки по WWW ссылкам и предоставляет простой браузер — серверный транспорт для сообщений с отметками времени. После получения действительного запроса сервер ДОЛЖЕН ответить либо действительный ответ с типом содержимого application / timestamp-response или с ошибкой HTTP. 4. Соображения безопасности Весь этот документ касается соображений безопасности.когда При разработке службы TSA были приняты следующие соображения: определены, которые влияют на достоверность или «доверие» к маркер отметки времени. 1. Когда TSA больше не будет использоваться, но закрытый ключ TSA имеет не был скомпрометирован, сертификат органа ДОЛЖЕН быть отозван. Когда расширение reasonCode относительно отозванного сертификат от TSA присутствует в расширениях записи CRL, он ДОЛЖЕН быть установлен в значение unspecified (0), affiliationChanged (3), superseded (4) или cessationOfOperation (5).В таком случае при любом в будущем токены, подписанные соответствующим ключом, будут считается недействительным, но токены, созданные до отзыва время останется в силе. Когда расширение reasonCode относительно отозванный сертификат от TSA отсутствует в CRL расширения записи, затем все токены, подписанные соответствующий ключ ДОЛЖЕН считаться недействительным. Для этого причина, рекомендуется использовать расширение reasonCode.Адамс и др. Стандарты Track [стр. 14] RFC 3161 Протокол отметок времени (TSP), август 2001 г. 2. Когда закрытый ключ TSA был скомпрометирован, соответствующий сертификат ДОЛЖЕН быть отозван. В этом случае Разумкод расширения относительно отозванного сертификата из TSA может присутствовать или не присутствовать в расширениях записей CRL. когда он присутствует, тогда он ДОЛЖЕН быть установлен на keyCompromise (1). любой токен, подписанный TSA с использованием этого закрытого ключа, нельзя доверять больше.По этой причине крайне важно, чтобы частный агент TSA ключ должен быть защищен надлежащими средствами безопасности и контроля, чтобы минимизировать возможность компромисса. Если закрытый ключ становится скомпрометированным, контрольный журнал всех токенов, сгенерированных TSA МОЖЕТ предоставить средства для различения подлинных и фальшивые задним числом токены. Два токена отметки времени из двух разных TSA — еще один способ решить эту проблему. 3. Ключ подписи TSA ДОЛЖЕН быть достаточной длины, чтобы позволить достаточно долгий срок службы.Даже если это будет сделано, ключ будет имеют ограниченный срок службы. Таким образом, любой токен, подписанный TSA, ДОЛЖЕН снова поставить отметку времени (если подлинные копии старых CRL доступно) или нотариально заверенное (если их нет) на более поздний срок для продления доверие, которое существует в подписи TSA. жетоны отметок времени также может храниться у органа регистрации доказательств, чтобы поддерживать это доверие. 4. Клиентское приложение, использующее только одноразовый номер и не использующее локальные часы, ДОЛЖНО беспокоиться о том, сколько времени он готов ждать ответ.Атака «человек посередине» может вызвать задержки. Таким образом, любой TimeStampResp, который занимает больше допустимого периода времени СЛЕДУЕТ считать подозрительным. Поскольку каждый вид транспорта указанные в этом документе имеют разные характеристики задержки, период времени, который считается приемлемым, будет зависеть от конкретный используемый способ транспортировки, а также другая среда факторы. 5. Если разные организации получают токены отметок времени на одних и тех же данных объект, использующий тот же алгоритм хеширования, или одна сущность получает несколько токенов отметки времени на одном объекте, сгенерированный жетоны отметок времени будут включать идентичные отпечатки сообщений; как в результате наблюдатель с доступом к этим токенам отметки времени может сделайте вывод, что отметки времени могут относиться к одним и тем же базовым данным.Адамс и др. Standards Track [Страница 15] RFC 3161 Протокол отметок времени (TSP), август 2001 г. 6. Случайные или преднамеренные повторы запросов, включающих может произойти тот же алгоритм хеширования и значение. Случайные повторы возникает, когда более одной копии одного и того же сообщения запроса получает отправлено в TSA из-за проблем в промежуточной сети элементы. Умышленные повторы происходят, когда посредник воспроизводит законные ответы TS.Чтобы обнаружить эти ситуации, можно использовать несколько методов. Использование одноразового номера всегда позволяет обнаруживать повторы, поэтому его использование РЕКОМЕНДУЕТСЯ. Другая возможность использовать как местные часы, так и скользящее временное окно во время которого запрашивающий запоминает все хэши, отправленные во время это временное окно. При получении ответа запрашивающий гарантирует, что время ответа будет в пределах времени окно и что есть только одно вхождение хэш-значения в это временное окно.Если одно и то же значение хеш-функции присутствует более чем один раз в пределах временного окна запрашивающая сторона может использовать одноразовый номер, или подождите, пока не переместится временное окно, чтобы вернуться к делу где одно и то же значение хеш-функции появляется только один раз за это время окно. 5. Права интеллектуальной собственности IETF не занимает никакой позиции относительно действительности или объема любых интеллектуальная собственность или другие права, которые могут быть заявлены в отношении к реализации или использованию технологии, описанной в этом документ или степень, в которой любая лицензия на такие права может или может быть недоступен; и не означает, что он сделал любые попытки идентифицировать такие права.Информация о IETF процедуры в отношении прав в стандартах-трек и стандарты- соответствующую документацию можно найти в BCP-11. Копии претензий права, предоставляемые для публикации, и любые гарантии лицензий быть доступным, или в результате попытки получить генеральная лицензия или разрешение на использование таких имущественных прав разработчиками или пользователями этой спецификации можно получить из Секретариат IETF. IETF приглашает любую заинтересованную сторону довести до ее сведения любые авторские права, патенты или заявки на патенты или другие проприетарные права, которые могут охватывать технологии, которые могут потребоваться для практики этот стандарт.Пожалуйста, направьте информацию исполнительному директору IETF. Директор. Следующие восемь (8) патентов США, связанных со временем штампы, перечисленные в хронологическом порядке, как известно авторам существуют в настоящее время. Это не может быть исчерпывающий список. Другие патенты МОГУТ существовать или выдаваться в любое время. Этот список предоставляется в информационных целях; на сегодняшний день IETF не уведомлен прав интеллектуальной собственности, заявленных в отношении любого из Адамс и др. Standards Track [Страница 16] RFC 3161 Протокол отметок времени (TSP), август 2001 г. спецификации, содержащиеся в этом документе.Если эта ситуация изменения, текущий статус можно найти в онлайн-списке заявленных права (страница IETF с уведомлениями о правах интеллектуальной собственности). Разработчикам этого протокола СЛЕДУЕТ проводить собственный патентный поиск. и определить, существуют ли какие-либо обременения на их реализация. Пользователи этого протокола ДОЛЖНЫ выполнять собственный патентный поиск и определить, существуют ли какие-либо препятствия на использование этого стандарт. # 5,001,752 Публичная / нотариальная служба с указанием даты и времени Дата подачи: 13 октября 1989 г. Выпущено: 19 марта 1991 г. Изобретатель: Эддисон М.Фишер # 5,022,080 Электронный нотариус Дата подачи: 16 апреля 1989 г. Выпущено: 4 июня 1991 г. Изобретатели: Роберт Т. Дерст, Кевин Д. Хантер. # 5,136,643 Публичная / нотариальная служба с ключевой датой и временем Дата подачи: 20 декабря 1990 г. Выпущено: 4 августа 1992 г. Изобретатель: Эддисон М. Фишер Примечание: это продолжение патента № 5,001,752.) # 5,136,646 Цифровой документ с отметкой времени и сертификатом Catenate Дата подачи: 2 августа 1990 г. Выпущено: 4 августа 1992 г. Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл. (правопреемник) Bell Communications Research, Inc., # 5,136,647 Метод безопасной временной отметки цифровых документов Дата подачи: 2 августа 1990 г. Выпущено: 4 августа 1992 г. Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл. (правопреемник) Bell Communications Research, Inc., # 5,373,561 Метод продления срока действия криптографии Сертификат Дата подачи: 21 декабря 1992 г. Выдан: 13 декабря 1994 г. Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл. (правопреемник) Bell Communications Research, Inc., Адамс и др. Стандарты Track [стр. 17] RFC 3161 Протокол отметок времени (TSP), август 2001 г. # 5,422,953 Персональное устройство нотариуса даты / времени Дата подачи: 5 мая 1993 г. Выпущено: 6 июня 1995 г. Изобретатель: Эддисон М.Фишер # 5781629 Система аутентификации цифровых документов Дата подачи: 21 февраля 1997 г. Выпущено: 14 июля 1998 г. Изобретатель: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл. (правопреемник) Surety Technologies, Inc., 6. Ссылки [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения Уровни требований », BCP 14, RFC 2119, март 1997 г. [RFC2246] Диркс, Т. и К. Аллен, «Протокол TLS, версия 1.0», RFC 2246, январь 1999 г. [RFC2510] Адамс, К. и С. Фаррелл, «Internet X.509 Открытый ключ Инфраструктура, протоколы управления сертификатами », RFC 2510, март 1999 г. [RFC2459] Housley, R., Ford, W., Polk, W. и D. Solo, «Интернет Инфраструктура открытого ключа X.509, сертификат и CRL Профиль », RFC 2459, январь 1999 г. [CMS] Housley, R., «Синтаксис криптографических сообщений», RFC 2630, Июнь 1999 г. [DSS] Стандарт цифровой подписи. FIPS Pub 186. Национальный Институт стандартов и технологий.19 мая 1994 г. [ESS] Хоффман П., «Расширенные службы безопасности для S / MIME», RFC 2634, июнь 1999 г. [ISONR] ISO / IEC 10181-5: Структуры безопасности в открытых системах. Система предотвращения отказа от авторства. Апрель 1997 г. [MD5] Ривест Р., «Алгоритм дайджеста сообщения MD5», RFC 1321, Апрель 1992 г. [SHA1] Стандарт безопасного хеширования. FIPS Pub 180-1. Национальный институт стандартов и технологий. 17 апреля 1995 г. Адамс и др. Стандарты Track [стр. 18] RFC 3161 Протокол отметок времени (TSP), август 2001 г. 7.Адреса авторов Карлайл Адамс Entrust, Inc. 1000 инноваций Оттава, Онтарио K2K 3E7 КАНАДА Электронная почта: [email protected] Пэт Кейн BBN 70 Fawcett Street Кембридж, Массачусетс 02138 США. Электронная почта: [email protected] Денис Пинкас Integris Версаль, 68 Б.П. 434 78430 Louveciennes ФРАНЦИЯ Электронная почта: [email protected] Роберт Зуккерато Entrust, Inc. 1000 инноваций Оттава, Онтарио K2K 3E7 КАНАДА Электронная почта: Роберт[email protected] Адамс и др. Standards Track [Страница 19] RFC 3161 Протокол отметок времени (TSP), август 2001 г. ПРИЛОЖЕНИЕ A. Атрибут метки времени подписи с использованием CMS Одно из основных применений отметки времени — установка отметки времени на цифровом подпись, чтобы доказать, что цифровая подпись была создана до данное время. Если соответствующий сертификат открытого ключа отозвано, это позволяет проверяющему узнать, была ли подпись создано до или после даты отзыва.Разумное место для хранения метки времени — это структура [CMS] как беззнаковый атрибут. В этом приложении определяется атрибут отметки времени подписи, который может быть используется для отметки времени цифровой подписи. Следующий идентификатор объекта определяет метку времени подписи. атрибут: id-aa-timeStampToken ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2) us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) aa (2) 14} Значение атрибута отметки времени подписи имеет тип ASN.1. SignatureTimeStampToken: SignatureTimeStampToken :: = TimeStampToken Значение поля messageImprint в TimeStampToken должно быть хэш значения поля подписи в SignerInfo для signedData имеет отметку времени.ПРИЛОЖЕНИЕ B — Размещение подписи в определенный момент времени Мы представляем пример возможного использования этой общей отметки времени. оказание услуг. Он ставит подпись в определенный момент времени, начиная с что соответствующая информация о статусе сертификата (например, CRL) НЕОБХОДИМО проверить. Это приложение предназначено для использования в в сочетании с доказательствами, полученными с использованием цифровой подписи механизм. Подпись может быть проверена только в соответствии с подтверждением отказа от авторства. политика. Эта политика МОЖЕТ быть явной или неявной (т.е., указанные в доказательства, предоставленные подписавшим). Политика неотказуемости может указать, среди прочего, период времени, разрешенный подписывающей стороной для объявить о компрометации ключа подписи, используемого для генерации цифровые подписи. Таким образом, подпись не может быть гарантирована действует до окончания этого временного периода. Чтобы проверить цифровую подпись, может быть использован следующий базовый метод: используемый: Адамс и др. Standards Track [Страница 20] RFC 3161 Протокол отметок времени (TSP), август 2001 г. A) Информация с отметками времени должна быть получена вскоре после подпись была произведена (e.г., в течение нескольких минут или часов). 1) Подпись предоставляется органу по штампам времени. (TSA). Затем TSA возвращает TimeStampToken (TST) при эта подпись. 2) После этого инициатор службы ДОЛЖЕН проверить, что TimeStampToken правильный. Б) Действительность цифровой подписи затем может быть проверена в следующим образом: 1) Сам токен отметки времени ДОЛЖЕН быть проверен, и он ДОЛЖЕН быть проверено, что это относится к подписи подписавшего.2) Дата / время, указанные TSA в TimeStampToken ДОЛЖЕН быть восстановлен. 3) Сертификат, используемый подписывающей стороной, ДОЛЖЕН быть идентифицирован и извлечен. 4) Дата / время, указанные TSA, ДОЛЖНЫ быть в пределах срок действия сертификата подписывающей стороны. 5) Информация об отзыве этого сертификата в ДОЛЖНА быть получена дата / время операции отметки времени. 6) В случае отзыва сертификата дата / время отзыв должен быть позже даты / времени, указанных TSA.Если все эти условия выполнены успешно, то электронная подпись признаются действительными. ПРИЛОЖЕНИЕ C: Модуль ASN.1 с использованием синтаксиса 1988 г. PKIXTSP {iso (1) идентифицированная организация (3) dod (6) Интернет (1) безопасность (5) механизмы (5) pkix (7) id-mod (0) id-mod-tsp (13)} ОПРЕДЕЛЕНИЯ НЕЯВНЫЕ ТЭГИ :: = НАЧАТЬ — ЭКСПОРТ ВСЕ — ИМПОРТ Адамс и др. Standards Track [Страница 21] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Расширения, AlgorithmIdentifier ОТ PKIX1Explicit88 {iso (1) идентифицированная организация (3) dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) id-mod (0) id-pkix1-explicit-88 (1)} GeneralName ОТ PKIX1Implicit88 {iso (1) идентифицированная организация (3) dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) id-mod (0) id-pkix1-implicit-88 (2)} ContentInfo ИЗ CryptographicMessageSyntax {iso (1) член-тело (2) us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) модули (0) cms (1)} PKIFreeText ОТ PKIXCMP {iso (1) идентифицированная организация (3) dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) id-mod (0) id-mod-cmp (9)}; — Локально определенные OID — — eContentType для токена отметки времени id-ct-TSTInfo ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2) us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) ct (1) 4} — 2.4.1 TimeStampReq :: = SEQUENCE { версия INTEGER {v1 (1)}, messageImprint MessageImprint, — OID хеш-алгоритма и хеш-значение данных, которые нужно — с отметкой времени reqPolicy TSAPolicyId ДОПОЛНИТЕЛЬНО, nonce INTEGER ДОПОЛНИТЕЛЬНО, certReq BOOLEAN DEFAULT FALSE, расширения [0] IMPLICIT Extensions OPTIONAL} MessageImprint :: = SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING} TSAPolicyId :: = ИДЕНТИФИКАТОР ОБЪЕКТА — 2.4.2 TimeStampResp :: = SEQUENCE { статус PKIStatusInfo, timeStampToken TimeStampToken ДОПОЛНИТЕЛЬНО} Адамс и др. Standards Track [Страница 22] RFC 3161 Протокол отметок времени (TSP), август 2001 г. — Статус основан на определении статуса — в разделе 3.2.3 [RFC2510] PKIStatusInfo :: = SEQUENCE { статус PKIStatus, statusString PKIFreeText ДОПОЛНИТЕЛЬНО, failInfo PKIFailureInfo ДОПОЛНИТЕЛЬНО} PKIStatus :: = INTEGER { предоставлено (0), — когда PKIStatus содержит нулевое значение TimeStampToken, как запрошено, присутствует.предоставленоWithMods (1), — когда PKIStatus содержит значение, равное TimeStampToken, с доработками, присутствует. отказ (2), ожидание (3), revocationWarning (4), — это сообщение содержит предупреждение о том, что отзыв — неизбежный revocationNotification (5) — уведомление о том, что произошел отзыв} — Когда TimeStampToken отсутствует — failInfo указывает причину, по которой — запрос отметки времени был отклонен и — может быть одним из следующих значений.PKIFailureInfo :: = BIT STRING { badAlg (0), — нераспознанный или неподдерживаемый идентификатор алгоритма badRequest (2), — транзакция не разрешена или не поддерживается badDataFormat (5), — представленные данные имеют неправильный формат timeNotAvailable (14), — источник времени TSA недоступен unacceptedPolicy (15), — запрошенная политика TSA не поддерживается TSA. unacceptedExtension (16), — запрошенное расширение не поддерживается TSA.addInfoNotAvailable (17) — запрошенная дополнительная информация непонятна — или недоступен systemFailure (25) — запрос не может быть обработан из-за сбоя системы} TimeStampToken :: = ContentInfo Адамс и др. Standards Track [Страница 23] RFC 3161 Протокол отметок времени (TSP), август 2001 г. — contentType — это id-signedData, как определено в [CMS] — содержание — это SignedData, как определено в ([CMS]) — eContentType в SignedData — id-ct-TSTInfo — Электронный контент в SignedData — это TSTInfo TSTInfo :: = SEQUENCE { версия INTEGER {v1 (1)}, политика TSAPolicyId, messageImprint MessageImprint, — ДОЛЖЕН иметь то же значение, что и аналогичное поле в — TimeStampReq serialNumber INTEGER, — Пользователи с отметкой времени ДОЛЖНЫ быть готовы к использованию целых чисел. — до 160 бит.genTime GeneralizedTime, точность Точность ДОПОЛНИТЕЛЬНАЯ, заказ BOOLEAN DEFAULT FALSE, nonce INTEGER ДОПОЛНИТЕЛЬНО, — ДОЛЖЕН присутствовать, если подобное поле присутствовало — в TimeStampReq. В этом случае он ДОЛЖЕН иметь такое же значение. tsa [0] GeneralName ДОПОЛНИТЕЛЬНО, extension [1] IMPLICIT Extensions OPTIONAL} Точность :: = SEQUENCE { секунды INTEGER OPTIONAL, миллис [0] INTEGER (1..999) ДОПОЛНИТЕЛЬНО, микрос [1] INTEGER (1..999) ДОПОЛНИТЕЛЬНО} КОНЕЦ ПРИЛОЖЕНИЕ D: Дескрипторы доступа для меток времени. [В этом приложении описывается расширение, основанное на расширении SIA, которое будет определен в «сыне-RFC2459». Поскольку во время публикация этого документа «сын-оф-RFC2459» еще не доступна, его описание помещено в информативном приложении. Содержание это приложение в конечном итоге будет включено в Документ RFC2459, после которого это приложение больше не понадобится.В будущей версии этого документа это приложение, скорее всего, будет опущено. обратитесь непосредственно к сыну RFC2459.] Сертификат TSA МОЖЕТ содержать доступ к информации о субъекте (SIA) extension (сын RFC2459), чтобы передать метод связавшись с TSA. Поле accessMethod в этом расширении ДОЛЖНО содержат OID id-ad-timestamping: Следующий идентификатор объекта определяет дескрипторы доступа для штамп времени. Адамс и др. Standards Track [Страница 24] RFC 3161 Протокол отметок времени (TSP), август 2001 г. id-ad-timeStamping ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) идентифицированная организация (3) dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) ad (48) timestamping (3)} Значение поля accessLocation определяет транспорт (например,грамм., HTTP) используется для доступа к TSA и может содержать другой транспорт. зависимая информация (например, URL). Адамс и др. Standards Track [Страница 25] RFC 3161 Протокол отметок времени (TSP), август 2001 г. Полное заявление об авторских правах Авторское право (C) The Internet Society (2001). Все права защищены. Этот документ и его переводы могут быть скопированы и предоставлены другие и производные работы, которые комментируют или иным образом объясняют это или помочь в его реализации могут быть подготовлены, скопированы, опубликованы и распространяется, полностью или частично, без ограничения каких-либо вида, при условии, что указанное выше уведомление об авторских правах и этот абзац включены во все такие копии и производные работы.Однако это сам документ не может быть изменен каким-либо образом, например, путем удаления уведомление об авторских правах или ссылки на Internet Society или другие Интернет-организации, за исключением случаев, когда это необходимо для разработки Интернет-стандартов, в этом случае процедуры для авторские права, определенные в процессе разработки стандартов Интернета, должны быть следовали, или по мере необходимости перевести его на другие языки, кроме Английский. Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут аннулировано Интернет-сообществом, его правопреемниками или правопреемниками.Этот документ и содержащаяся в нем информация размещены на Основа «КАК ЕСТЬ» и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. Подтверждение Финансирование функции редактора RFC в настоящее время обеспечивается Интернет-общество.Адамс и др. Standards Track [Страница 26]

▷ Применен русский перевод

| Электрон

Зарегистрируйте собственный протокол и перехватите существующие запросы протокола.

Процесс: основной

Пример реализации протокола, который имеет тот же эффект, что и файл: // протокол:

  const {приложение, протокол} = require ('электрон')
const path = require ('путь')

app.whenReady (). then (() => {
  protocol.registerFileProtocol ('атом', (запрос, обратный вызов) => {
    const url = request.url.substr (7)
    обратный вызов ({путь: путь.normalize (`$ {__ dirname} / $ {url}`)})
  })
})
  

Примечание: Все методы, если не указано иное, могут использоваться только после события ready модуля app будет выпущен.

Протокол зарегистрирован для определенного сеанса Electron объект. Если вы не укажете сеанс, тогда ваш протокол будет применяться к сеанс по умолчанию, который использует Electron. Однако, если вы определяете раздел или сеанс в вашем браузере Окно webPreferences , тогда это окно будет использовать другой сеанс, и ваш собственный протокол не будет работать, если вы просто используете электрон. Протокол.XXX .

Чтобы ваш настраиваемый протокол работал в сочетании с настраиваемым сеансом, вам необходимо чтобы явно зарегистрировать его в этом сеансе.

  const {сеанс, приложение, протокол} = require ('electronic')
const path = require ('путь')

app.whenReady (). then (() => {
  const partition = 'персистировать: пример'
  const ses = session.fromPartition (раздел)

  ses.protocol.registerFileProtocol ('атом', (запрос, обратный вызов) => {
    const url = request.url.substr (7)
    обратный вызов ({путь: путь.normalize (`$ {__ dirname} / $ {url}`)})
  })

  mainWindow = новый BrowserWindow ({webPreferences: {partition}})
})
  

Модуль протокола имеет следующие методы:

протокол.registerSchemesAsPrivileged (customSchemes)

Примечание: Этот метод можно использовать только до события ready приложения модуль генерируется и может быть вызван только один раз.

Регистрирует схему как стандартную, безопасную, обходит политику безопасности контента для ресурсов, позволяет зарегистрировать ServiceWorker и поддерживает API извлечения. Укажите привилегия со значением true для включения возможности.

Пример регистрации привилегированной схемы, которая обходит Content Security. Политика:

  const {протокол} = требуется ('электрон')
протокол.registerSchemesAsPrivileged ([
  {scheme: 'foo', привилегии: {bypassCSP: true}}
])
  

Стандартная схема соответствует тому, что RFC 3986 называет универсальным URI синтаксис. Например http и https — стандартные схемы, а файл — нет.

Регистрация схемы как стандартной позволяет относительным и абсолютным ресурсам разрешаться правильно при обслуживании. В противном случае схема будет вести себя как файл протокол, но без возможности разрешения относительных URL.

Например, когда вы загружаете следующую страницу с пользовательским протоколом без зарегистрировав его как стандартную схему, изображение не будет загружено, потому что нестандартные схемы не распознают относительные URL:

  <тело>
   
  

Регистрация стандартной схемы позволит получить доступ к файлам через Файловая система API. В противном случае средство визуализации выдаст безопасность ошибка схемы.

По умолчанию apis веб-хранилища (localStorage, sessionStorage, webSQL, indexedDB, cookies) отключены для нестандартных схем.В общем, если вы хотите зарегистрируйте собственный протокол для замены протокола http , вам необходимо зарегистрировать это как стандартная схема.

protocol.registerFileProtocol (схема, обработчик)

• схема Строка
• обработчик Функция
  • запрос Протокол Запрос
  • обратный вызов Функция

Возвращает Boolean — Был ли протокол успешно зарегистрирован

Регистрирует протокол схемы , который отправляет файл в качестве ответа.В Обработчик будет вызван с запросом и обратным вызовом , где запрос входящий запрос по схеме .

Для обработки запроса необходимо вызвать обратный вызов либо с помощью файла path или объект, имеющий свойство path , например обратный вызов (filePath) или обратный вызов ({path: filePath}) . filePath должен быть абсолютным путем.

По умолчанию схема обрабатывается как http: , которая анализируется иначе. из протоколов, которые следуют «универсальному синтаксису URI», например file: .

protocol.registerBufferProtocol (схема, обработчик)

• схема Строка
• обработчик Функция
  • запрос Протокол Запрос
  • обратный вызов Функция

Возвращает Boolean — Был ли протокол успешно зарегистрирован

Регистрирует протокол схемы , который будет отправлять Buffer в качестве ответа.

Использование аналогично registerFileProtocol , за исключением того, что обратный вызов должен вызываться либо с объектом Buffer , либо с объектом, имеющим данные свойство.

Пример:

  protocol.registerBufferProtocol ('atom', (запрос, обратный вызов) => {
  обратный вызов ({mimeType: 'text / html', data: Buffer.from (' 
 Response 
 ')})
})
  

protocol.registerStringProtocol (схема, обработчик)

• схема Строка
• обработчик Функция
  • запрос Протокол Запрос
  • обратный вызов Функция

Возвращает Boolean — Был ли протокол успешно зарегистрирован

Регистрирует протокол схемы , который будет отправлять String в качестве ответа.

Использование аналогично registerFileProtocol , за исключением того, что обратный вызов должен вызываться либо со строкой , либо с объектом, имеющим данные свойство.

protocol.registerHttpProtocol (схема, обработчик)

• схема Строка
• обработчик Функция
  • запрос Протокол Запрос
  • обратный вызов Функция
    • ответ Протокол Ответ

Возвращает Boolean — Был ли протокол успешно зарегистрирован

Регистрирует протокол схемы , который будет отправлять HTTP-запрос в качестве ответа.

Использование аналогично registerFileProtocol , за исключением того, что обратный вызов должен вызываться с объектом, имеющим свойство url .

protocol.registerStreamProtocol (схема, обработчик)

• схема Строка
• обработчик Функция
  • запрос Протокол Запрос
  • обратный вызов Функция

Возвращает Boolean — Был ли протокол успешно зарегистрирован

Регистрирует протокол схемы , который будет отправлять поток в качестве ответа.

Использование аналогично registerFileProtocol , за исключением того, что Обратный вызов должен вызываться либо с объектом ReadableStream , либо с объектом, который имеет свойство data .

Пример:

  const {протокол} = требуется ('электрон')
const {PassThrough} = require ('поток')

  

RFC 3161 — Временная метка инфраструктуры открытых ключей Internet X.509 P (RFC3161)

 Сетевая рабочая группа C.Адамс
Запрос комментариев: 3161 Доверие
Категория: Стандарты Track P. Cain
 BBN
 Д. Пинкас
 Integris
 Р. Зуккерато
 Доверить
 Август 2001 г.  Интернет X.Инфраструктура открытых ключей 509
 Протокол отметок времени (TSP)  Статус этой памятки  Этот документ определяет протокол отслеживания стандартов Интернета для
 Интернет-сообщество и просит обсуждения и предложения по
 улучшения. Пожалуйста, обратитесь к текущему выпуску "Интернет
 Официальные стандарты протокола »(STD 1) для состояния стандартизации
 и статус этого протокола. Распространение памятки не ограничено.  Уведомление об авторских правах  Авторское право (C) The Internet Society (2001).Все права защищены.  Аннотация  В этом документе описывается формат запроса, отправляемого в Time
 Stamping Authority (TSA) и возвращаемого ответа. Это
 также устанавливает несколько требований безопасности для TSA
 операция в отношении обработки запросов для генерации ответов.  1. Введение  Служба отметки времени поддерживает утверждения о том, что данные
 существовали до определенного времени. TSA может работать как доверенный
 Услуга третьей стороны (TTP), хотя другие операционные модели могут быть
 соответствующий, e.g., организации может потребоваться TSA для внутренних
 в целях отметки времени.  Службы неотказуемости [ISONR] требуют возможности установить
 наличие данных до указанного времени. Этот протокол можно использовать
 как строительный блок для поддержки таких услуг. Пример того, как
 доказать, что цифровая подпись была создана во время срока действия
 Срок действия сертификата открытого ключа указан в приложении.  Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
 «ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе (в
 верхний регистр, как показано) следует интерпретировать, как описано в [RFC2119].Чтобы связать данные с определенным моментом времени, Время
 Возможно, потребуется использовать Stamp Authority (TSA). Эта доверенная третья сторона
 предоставляет "доказательство существования" для этой конкретной информации в
 мгновенно во времени.  Роль TSA состоит в том, чтобы поставить отметку времени для получения доказательств.
 что указывает на то, что данные существовали до определенного времени. Это может
 затем использоваться, например, для проверки того, что цифровая подпись была
 применено к сообщению до того, как соответствующий сертификат был отозван
 тем самым позволяя использовать отозванный сертификат открытого ключа для
 проверка подписей, созданных до момента отзыва.Этот
 является важной операцией инфраструктуры открытого ключа. TSA может
 также может использоваться для обозначения времени подачи, когда крайний срок
 критический, или указать время транзакции для записей в
 журнал. Исчерпывающий список возможных вариантов использования TSA выходит за рамки
 объем этого документа.  Этот стандарт не устанавливает общих требований безопасности для
 Работа TSA, как и другие стандарты PKIX, не устанавливает таких
 требования к работе ЦС. Скорее предполагается, что TSA
 ознакомит потенциальных клиентов с политикой, которую он реализует
 обеспечить точную генерацию меток времени, и клиенты будут использовать
 услуги TSA, только если они уверены, что эти политики
 удовлетворить их потребности.2. TSA  TSA - это TTP, который создает токены с отметками времени, чтобы указать
 что данные существовали в определенный момент времени.  В остальной части этого документа «действительный запрос» означает один
 который может быть правильно декодирован, имеет форму, указанную в разделе
 2.4, и от поддерживаемого подписчика TSA.  2.1. Требования TSA  TSA ТРЕБУЕТСЯ:  1. использовать надежный источник времени.  2. включить достоверное значение времени для каждого токена отметки времени.3. включить уникальное целое число для каждой вновь созданной отметки времени
 токен.  4. для создания токена с отметкой времени при получении действительного запроса
 от запрашивающего, когда это возможно.  5. включить в каждый токен отметки времени идентификатор для
 однозначно указать политику безопасности, в соответствии с которой токен был
 создан.  6. поставить отметку времени только для хэш-представления данных, т.е.
 отпечаток данных, связанный с устойчивостью к одностороннему столкновению
 хэш-функция, однозначно идентифицируемая по OID.7. проверить OID хэша, устойчивого к односторонним столкновениям.
 функция и убедиться, что длина хеш-значения согласована
 с хеш-алгоритмом.  8. никоим образом не проверять отпечаток с отметкой времени (другое
 чем проверить его длину, как указано в предыдущем пункте).  9. не включать никакую идентификацию запрашивающего лица в
 жетоны отметок времени.  10. подписывать каждый токен с отметкой времени, используя исключительно сгенерированный ключ
 для этой цели и иметь это свойство ключа, указанное на
 соответствующий сертификат.11. включить дополнительную информацию в маркер отметки времени, если
 запросил запрашивающий, используя поле расширений, только для
 расширения, которые поддерживаются TSA. Если это не так
 возможно, TSA ДОЛЖЕН ответить сообщением об ошибке.  2.2. Транзакции TSA  В качестве первого сообщения этого механизма запрашивающий объект
 запрашивает токен с отметкой времени, отправляя запрос (который или
 включает TimeStampReq, как определено ниже) к метке времени
 Орган власти.Во втором сообщении администрация отметки времени
 отвечает, отправляя ответ (который является или включает TimeStampResp,
 как определено ниже) запрашивающему объекту.  После получения ответа (который является или включает TimeStampResp
 который обычно содержит TimeStampToken (TST), как определено ниже),
 запрашивающий объект ДОЛЖЕН проверить ошибку статуса, возвращенную в
 ответ, и если ошибок нет, он ДОЛЖЕН проверить различные
 поля, содержащиеся в TimeStampToken, и срок действия
 цифровая подпись TimeStampToken.В частности, ДОЛЖНА
 проверьте, что то, что было отмечено временем, соответствует тому, что было запрошено
 с отметкой времени. Запрашивающая сторона ДОЛЖНА проверить, что
 TimeStampToken содержит правильный идентификатор сертификата  TSA, правильный отпечаток данных и правильный OID хеш-алгоритма. Это
 Затем ДОЛЖЕН проверять своевременность ответа, проверяя либо
 время, включенное в ответ, относительно местного доверенного времени
 ссылка, если она доступна, или значение одноразового номера (большой
 случайное число с высокой вероятностью того, что оно генерируется
 клиент только один раз) включен в ответ против включенного значения
 в запросе.Для получения дополнительных сведений об обнаружении атаки повторного воспроизведения см.
 раздел соображений безопасности (пункт 6). Если любой из
 вышеперечисленные проверки завершаются неудачно, TimeStampToken ДОЛЖЕН быть отклонен.  Затем, поскольку сертификат TSA мог быть отозван, статус
 сертификата СЛЕДУЕТ проверять (например, путем проверки
 соответствующий CRL), чтобы убедиться, что сертификат все еще действителен.  Затем клиентскому приложению СЛЕДУЕТ проверить поле политики, чтобы
 определить, была ли выпущена политика, в соответствии с которой был выпущен токен
 приемлемо для приложения.2.3. Идентификация TSA  TSA ДОЛЖЕН подписывать каждое сообщение с отметкой времени с зарезервированным ключом.
 специально для этой цели. TSA МОЖЕТ иметь отдельные закрытые ключи,
 например, чтобы приспособить разные политики, разные алгоритмы,
 различные размеры закрытых ключей или для повышения производительности. В
 соответствующий сертификат ДОЛЖЕН содержать только один экземпляр
 расширение поля расширенного использования ключа, как определено в разделе [RFC2459]
 4.2.1.13 со значением KeyPurposeID:  id-kp-timeStamping.Это расширение ДОЛЖНО быть критичным.  Следующий идентификатор объекта идентифицирует KeyPurposeID, имеющий
 значение id-kp-timeStamping.  id-kp-timeStamping ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1)
 идентифицированная организация (3) dod (6)
 интернет (1) безопасность (5) механизмы (5) pkix (7)
 kp (3) timestamping (8)}  2.4. Форматы запросов и ответов  2.4.1. Формат запроса  Запрос с отметкой времени выглядит следующим образом:  TimeStampReq :: = SEQUENCE {
 версия INTEGER {v1 (1)},
 messageImprint MessageImprint,
 - OID хеш-алгоритма и хеш-значение данных, которые нужно  - с отметкой времени
 reqPolicy TSAPolicyId ДОПОЛНИТЕЛЬНО,
 nonce INTEGER ДОПОЛНИТЕЛЬНО,
 certReq BOOLEAN DEFAULT FALSE,
 расширения [0] IMPLICIT Extensions OPTIONAL}  Поле версии (в настоящее время v1) описывает версию Time-
 Гербовый запрос.Поле messageImprint ДОЛЖНО содержать хэш данных, которые необходимо
 с отметкой времени. Хэш представлен в виде СТРОКИ ОКТЕТОВ. это
 длина ДОЛЖНА соответствовать длине хеш-значения для этого алгоритма
 (например, 20 байтов для SHA-1 или 16 байтов для MD5).  MessageImprint :: = SEQUENCE {
 hashAlgorithm AlgorithmIdentifier,
 hashedMessage OCTET STRING}  Алгоритм хеширования, указанный в поле hashAlgorithm, ДОЛЖЕН быть
 известный алгоритм хеширования (односторонний и устойчивый к коллизиям).Это означает
 что он ДОЛЖЕН быть односторонним и устойчивым к столкновениям. Штамп времени
 Власти ДОЛЖНЫ проверить, является ли данный алгоритм хеширования
 заведомо «достаточным» (на основании текущего уровня знаний в
 криптоанализ и современное состояние вычислительной техники
 ресурсы, например). Если TSA не распознает хеш
 алгоритм или знает, что алгоритм хеширования слабый (решение осталось
 на усмотрение каждого отдельного TSA), то TSA ДОЛЖЕН отказать
 чтобы предоставить маркер отметки времени, вернув pkiStatusInfo из
 'bad_alg'.Поле reqPolicy, если включено, указывает политику TSA в
 который ДОЛЖЕН быть предоставлен TimeStampToken. TSAPolicyId определен
 следующим образом:  TSAPolicyId :: = ИДЕНТИФИКАТОР ОБЪЕКТА  Одноразовый номер, если он включен, позволяет клиенту проверять своевременность
 ответ, когда местные часы недоступны. Одноразовый номер - это большой
 случайное число с большой вероятностью, что клиент его сгенерирует
 только один раз (например, 64-битное целое число). В таком случае тот же одноразовый номер
 значение ДОЛЖНО быть включено в ответ, в противном случае ответ должен
 быть отклоненным.Если поле certReq присутствует и имеет значение true, открытый ключ TSA
 сертификат, на который ссылается идентификатор ESSCertID внутри
 Атрибут SigningCertificate в ответе ДОЛЖЕН предоставляться
 TSA в поле сертификатов из структуры SignedData в этом
 ответ. Это поле может также содержать другие сертификаты.  Если поле certReq отсутствует или присутствует поле certReq
 и установите значение false, затем поле сертификатов из SignedData
 структура НЕ ДОЛЖНА присутствовать в ответе.Поле расширений - это общий способ добавить дополнительную информацию.
 на запрос в будущем. Расширения определены в [RFC 2459].
 Если расширение, помечено ли оно как критическое или некритическое,
 используется запрашивающей стороной, но не распознается сервером отметок времени,
 сервер НЕ ДОЛЖЕН выпускать токен и ДОЛЖЕН возвращать ошибку
 (unacceptedExtension).  Запрос отметки времени не идентифицирует инициатора запроса, так как это
 информация не подтверждена TSA (см. раздел 2.1). В
 ситуации, когда TSA требует идентификации запрашивающего
 объекта, должны быть предусмотрены альтернативные средства идентификации / аутентификации.
 используется (например, инкапсуляция CMS [CMS] или аутентификация TLS [RFC2246]).  2.4.2. Формат ответа  Ответ с отметкой времени выглядит следующим образом:  TimeStampResp :: = SEQUENCE {
 статус PKIStatusInfo,
 timeStampToken TimeStampToken ДОПОЛНИТЕЛЬНО}  Статус основан на определении статуса в разделе 3.2.3.
 из [RFC2510] следующим образом:  PKIStatusInfo :: = SEQUENCE {
 статус PKIStatus,
 statusString PKIFreeText ДОПОЛНИТЕЛЬНО,
 failInfo PKIFailureInfo ДОПОЛНИТЕЛЬНО}  Когда статус содержит значение ноль или единицу, TimeStampToken ДОЛЖЕН
 присутствовать.Когда статус содержит значение, отличное от нуля или единицы,
 TimeStampToken НЕ ДОЛЖЕН присутствовать. Одно из следующих значений ДОЛЖНО
 содержаться в статусе:  PKIStatus :: = INTEGER {
 предоставлено (0),
 - когда PKIStatus содержит нулевое значение TimeStampToken, как
 запрошено, присутствует.
 предоставленоWithMods (1),
 - когда PKIStatus содержит значение, равное TimeStampToken,
 с доработками, присутствует.
 отказ (2),
 ожидание (3),
 revocationWarning (4),  - это сообщение содержит предупреждение о том, что отзыв
 - неизбежный
 revocationNotification (5)
 - уведомление о том, что произошел отзыв}  Совместимые серверы НЕ ДОЛЖНЫ выдавать другие значения.Соответствует
 клиенты ДОЛЖНЫ генерировать ошибку, если значения, которые он не понимает,
 подарок.  Когда TimeStampToken отсутствует, failInfo указывает
 причина, по которой запрос отметки времени был отклонен и может быть одним из
 следующие значения.  PKIFailureInfo :: = BIT STRING {
 badAlg (0),
 - нераспознанный или неподдерживаемый идентификатор алгоритма
 badRequest (2),
 - транзакция не разрешена или не поддерживается
 badDataFormat (5),
 - представленные данные имеют неправильный формат
 timeNotAvailable (14),
 - источник времени TSA недоступен
 unacceptedPolicy (15),
 - запрошенная политика TSA не поддерживается TSA
 unacceptedExtension (16),
 - запрошенное расширение не поддерживается TSA
 addInfoNotAvailable (17)
 - запрошенная дополнительная информация непонятна
 - или недоступен
 systemFailure (25)
 - запрос не может быть обработан из-за сбоя системы}  Это единственные значения PKIFailureInfo, которые ДОЛЖНЫ поддерживаться.Совместимые серверы НЕ ДОЛЖНЫ выдавать другие значения. Соответствует
 клиенты ДОЛЖНЫ генерировать ошибку, если значения, которые он не понимает,
 подарок.  Поле statusString PKIStatusInfo МОЖЕТ использоваться для включения причины
 текст, например «поле messageImprint отформатировано неправильно».  TimeStampToken выглядит следующим образом. Он определяется как ContentInfo
 ([CMS]) и ДОЛЖЕН инкапсулировать подписанный тип содержимого данных.  TimeStampToken :: = ContentInfo
 - contentType - это id-signedData ([CMS])
 - содержание - SignedData ([CMS])  Поля типа EncapsulatedContentInfo в SignedData
 конструкция имеют следующие значения:  eContentType - это идентификатор объекта, который однозначно определяет
 Тип содержимого.Для токена с отметкой времени это определяется как:  id-ct-TSTInfo ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2)
 us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) ct (1) 4}  eContent - это сам контент, передаваемый в виде строки октетов.
 EContent ДОЛЖЕН быть значением TSTInfo в кодировке DER.  Маркер отметки времени НЕ ДОЛЖЕН содержать никаких подписей, кроме
 подпись TSA. Идентификатор сертификата (ESSCertID)
 Сертификат TSA ДОЛЖЕН быть включен как атрибут signerInfo внутри
 Атрибут SigningCertificate.TSTInfo :: = SEQUENCE {
 версия INTEGER {v1 (1)},
 политика TSAPolicyId,
 messageImprint MessageImprint,
 - ДОЛЖЕН иметь то же значение, что и аналогичное поле в
 - TimeStampReq
 serialNumber INTEGER,
 - Пользователи с отметкой времени ДОЛЖНЫ быть готовы к использованию целых чисел.
 - до 160 бит.
 genTime GeneralizedTime,
 точность Точность ДОПОЛНИТЕЛЬНАЯ,
 заказ BOOLEAN DEFAULT FALSE,
 nonce INTEGER ДОПОЛНИТЕЛЬНО,
 - ДОЛЖЕН присутствовать, если подобное поле присутствовало
 - в TimeStampReq.В этом случае он ДОЛЖЕН иметь такое же значение.
 tsa [0] GeneralName ДОПОЛНИТЕЛЬНО,
 extension [1] IMPLICIT Extensions OPTIONAL}  Поле версии (в настоящее время v1) описывает версию времени-
 маркер жетон.  Соответствующие серверы с отметками времени ДОЛЖНЫ иметь возможность предоставлять версию 1
 жетоны отметок времени.  Среди дополнительных полей ДОЛЖНО поддерживаться только поле nonce.  Соответствующие запрашивающие метки времени ДОЛЖНЫ быть способны распознавать версию
 1 жетон отметки времени со всеми необязательными полями присутствуют, но не
 обязано понимать семантику любого расширения, если оно есть.Поле политики ДОЛЖНО указывать политику TSA, в соответствии с которой
 ответ был произведен. Если бы подобное поле присутствовало в
 TimeStampReq, тогда он ДОЛЖЕН иметь то же значение, иначе ошибка
 (unacceptedPolicy) ДОЛЖЕН быть возвращен. Эта политика МОЖЕТ включать
 следующие типы информации (хотя этот список, конечно, не
 исчерпывающий):  * Условия, при которых можно использовать маркер отметки времени.  * Наличие журнала токенов с отметками времени, чтобы позволить позже
 проверка подлинности токена с отметкой времени.MessageImprint ДОЛЖЕН иметь то же значение, что и аналогичное поле в
 TimeStampReq при условии, что размер хеш-значения соответствует
 ожидаемый размер алгоритма хеширования, указанного в hashAlgorithm.  Поле serialNumber - это целое число, присвоенное TSA каждому
 TimeStampToken. Он ДОЛЖЕН быть уникальным для каждого TimeStampToken, выпущенного
 заданный TSA (т. е. имя TSA и серийный номер идентифицируют уникальный
 TimeStampToken). Следует отметить, что свойство ДОЛЖНО быть
 сохраняется даже после возможного прерывания (например,г., крах)
 оказание услуг.  genTime - это время, когда токен отметки времени был создан
 TSA. Это выражается как время UTC (всемирное координированное время) до
 уменьшить путаницу с использованием местного часового пояса. UTC - шкала времени,
 на основе второго (SI), определенного и рекомендованного CCIR, и
 поддерживается Международным бюро поид и мер (BIPM). А
 синонимом является "зулусское" время, которое используется в гражданской авиации и
 обозначается буквой «Z» (фонетически «зулусский»).Синтаксис ASN.1 GeneralizedTime может включать доли секунды
 Детали. Такой синтаксис, без ограничений из [RFC 2459]
 Раздел 4.1.2.5.2, где GeneralizedTime ограничивается представлением
 Здесь можно использовать время с точностью до секунды.  Значения GeneralizedTime ДОЛЖНЫ включать секунды. Однако когда есть
 нет необходимости иметь точность лучше второй, тогда
 СЛЕДУЕТ использовать GeneralizedTime с точностью до одной секунды
 (как в [RFC 2459]).  Синтаксис: ГГГГММДДччммсс [.с ...] Я
 Пример: 1999060
26.34352Z  X.690 | ISO / IEC 8825-1 устанавливает следующие ограничения для
 DER-кодирование.  Кодирование ДОЛЖНО заканчиваться буквой «Z» (что означает «зулусское» время). В
 Элемент десятичной запятой, если он присутствует, ДОЛЖЕН быть опцией точки ".". В
 элементы дробных секунд, если они есть, ДОЛЖНЫ опускать все завершающие нули;
 если элементы соответствуют 0, они ДОЛЖНЫ быть полностью опущены, а
 элемент десятичной точки также ДОЛЖЕН быть опущен.  Полночь (GMT) должна быть представлена ​​в виде: «ГГГГММДД000000Z».
 где «ГГГГММДД» представляет день после полуночи в
 вопрос.Вот несколько примеров правильных представлений:  "19920521000000Z"
 "19920622123421Z"
 "19920722132100.3Z"  точность представляет собой отклонение времени относительно времени UTC, содержащегося
 в GeneralizedTime.  Точность :: = SEQUENCE {
 секунды INTEGER OPTIONAL,
 миллис [0] INTEGER (1..999) ДОПОЛНИТЕЛЬНО,
 микрос [1] INTEGER (1..999) ДОПОЛНИТЕЛЬНО}  Если отсутствуют секунды, миллис или микросекунды, значение равно нулю.
 ДОЛЖЕН быть принят за отсутствующее поле.Добавляя значение точности к GeneralizedTime, верхний предел
 времени, когда маркер метки времени был создан TSA
 может быть получен. Таким же образом, вычитая точность из
 GeneralizedTime, нижний предел времени, в которое метка времени
 токен был создан TSA можно получить.  точность может быть разложена на секунды, миллисекунды (от 1 до 999)
 и микросекунды (1-999), все выражены как целые числа.  Если необязательное поле точности не указано, то точность
 могут быть доступны другими способами, например.g., TSAPolicyId.  Если поле для заказа отсутствует или если поле для заказа присутствует
 и установлено значение false, тогда поле genTime указывает только время в
 токен временной отметки был создан TSA. В таком
 В этом случае заказ токенов с отметками времени, выпущенных тем же TSA или
 разные TSA возможны только тогда, когда разница между
 genTime первого токена отметки времени и genTime второго
 маркер отметки времени больше, чем сумма точности
 genTime для каждого токена отметки времени.Если поле упорядочивания присутствует и имеет значение true, каждая отметка времени
 токен из того же TSA всегда можно заказать на основе genTime
 независимо от точности genTime.  Поле nonce ДОЛЖНО присутствовать, если оно присутствовало в
 TimeStampReq. В таком случае он ДОЛЖЕН равняться значению, указанному в
 Структура TimeStampReq.  Назначение поля tsa - дать подсказку при идентификации
 название TSA. Если он присутствует, он ДОЛЖЕН соответствовать одному из
 имена субъектов, включенные в сертификат, который будет использоваться для
 проверить токен.Однако фактическая идентификация лица
 который подписал ответ, всегда будет происходить с использованием
 идентификатор сертификата (атрибут ESSCertID) внутри
 Атрибут SigningCertificate, который является частью signerInfo (см.
 Раздел 5 [ESS]).  расширения - это общий способ добавления дополнительной информации в
 будущее. Расширения определены в [RFC 2459].  Конкретные типы полей расширения могут быть указаны в стандартах или могут
 быть определенным и зарегистрированным любой организацией или сообществом.3. Транспорт  В этом документе нет обязательного транспортного механизма для сообщений TSA.
 документ. Описанные ниже механизмы не являются обязательными; дополнительный
 дополнительные механизмы могут быть определены в будущем.  3.1. Протокол отметки времени с использованием электронной почты  Этот раздел определяет средства для передачи сообщений в кодировке ASN.1.
 для обмена протоколами, описанными в Разделе 2 и Приложении D, через
 Интернет-почта.  Два объекта MIME указаны следующим образом:  Тип содержимого: приложение / отметка-запрос
 Кодирование передачи содержимого: base64 << АСН.1 сообщение Time-Stamp в кодировке DER, в кодировке base64 >>  Тип содержимого: приложение / отметка времени-ответ
 Кодирование передачи содержимого: base64 << сообщение отметки времени в кодировке ASN.1 DER, в кодировке base64 >>  Эти объекты MIME могут быть соответственно отправлены и получены с использованием общих
 Механизмы обработки MIME и простой транспорт электронной почты в Интернете.
 для сообщений с отметкой времени.  Для приложения / timestamp-query и application / timestamp-reply
 Типы MIME, реализации ДОЛЖНЫ включать необязательные "имя" и
 Параметры "имя файла".Включение имени файла помогает сохранить тип
 информация, когда запросы с отметкой времени и ответы сохраняются в виде файлов.
 Когда эти параметры включены, имя файла с соответствующим
 СЛЕДУЕТ выбрать расширение:  Расширение файла типа MIME
 приложение / отметка-запрос .TSQ
 приложение / отметка времени-ответ .TSR  Кроме того, имя файла ДОЛЖНО быть ограничено восемью символами.
 с последующим трехбуквенным расширением. Имя файла из восьми символов
 base может быть любым отдельным именем.3.2. Файловый протокол  Файл, содержащий сообщение с отметкой времени, ДОЛЖЕН содержать только DER.
 кодирование одного сообщения TSA, т.е. НЕ ДОЛЖЕН быть постороннего заголовка
 или информацию о трейлере в файле. Такие файлы можно использовать для
 передавать сообщения с отметками времени, например, по FTP.  Запрос отметки времени ДОЛЖЕН содержаться в файле с файлом
 расширение .tsq (например, запрос отметки времени). Ответ с отметкой времени
 ДОЛЖЕН содержаться в файле с расширением .tsr (например,
 Ответ с отметкой времени).3.3. Протокол на основе сокетов  Для транспорта будет использоваться следующий простой протокол на основе TCP.
 сообщений TSA. Этот протокол подходит для случаев, когда объект
 инициирует транзакцию и может опрашивать, чтобы получить результаты.  Протокол в основном предполагает процесс слушателя на TSA, который может
 принимать сообщения TSA на четко определенный порт (номер порта IP 318).  Обычно инициатор связывается с этим портом и отправляет начальный TSA.
 сообщение. Ответчик отвечает сообщением TSA и / или
 ссылочный номер, который будет использоваться позже при опросе фактического TSA
 ответ на сообщение.Если необходимо создать несколько ответных сообщений TSA для данного
 запрос (скажем, если квитанция должна быть отправлена ​​до того, как фактический токен может быть
 произведено), то также возвращается новая ссылка на опрос.  Когда последнее ответное сообщение TSA было получено
 инициатор, то новая ссылка на опрос не предоставляется.  Инициатор транзакции отправляет «прямое сообщение TSA на основе TCP»
 получателю. Получатель отвечает аналогичным сообщением.  «Прямое сообщение TSA на основе TCP» состоит из:
 длина (32 бита), флаг (8 бит), значение (определено ниже)  Поле длины содержит количество октетов оставшейся части
 сообщение (т.е., количество октетов «значение» плюс один). Все 32-битные
 значения в этом протоколе указываются в сетевом порядке байтов.  Значение флага имени сообщения
 tsaMsg '00'H Сообщение TSA в кодировке DER
 - Сообщение TSA
 pollRep '01'H ссылка на опрос (32 бита),
 time-to-check-back (32 бита)
 - ответ на опрос, когда нет готового ответа на сообщение TSA; использовать опрос
 - контрольное значение (и расчетное значение времени) для последующего опроса
 pollReq '02'H ссылка на опрос (32 бита)
 - запрос сообщения TSA, ответ на исходное сообщение
 negPollRep '03'H' 00'H
 - больше нет ответов на опрос (т.е., транзакция завершена)
 partialMsgRep '04'H следующая ссылка опроса (32 бита),
 time-to-check-back (32 бита),
 Сообщение TSA в кодировке DER
 - частичный ответ (получение) на исходное сообщение плюс новый опрос
 - ссылка (и расчетная временная стоимость) для получения следующей части
 -- ответ
 finalMsgRep '05'H Сообщение TSA в кодировке DER
 - окончательный (и, возможно, единственный) ответ на исходное сообщение
 errorMsgRep '06'H сообщение об ошибке, читаемое человеком
 - выдается при обнаружении ошибки (напр.g., ссылка на опрос
 - получен несуществующий или законченный)  Последовательность сообщений, которые могут появиться, следующая:  a) объект отправляет tsaMsg и получает одно из pollRep, negPollRep,
 partialMsgRep или finalMsgRep в ответ.  б) конечный объект отправляет сообщение pollReq и получает одно из
 negPollRep, partialMsgRep, finalMsgRep или errorMsgRep в
 ответ.  Параметр «time-to-check-back» представляет собой 32-разрядное целое число без знака. Это
 время в секундах, указывающее минимальный интервал, после которого
 клиент ДОЛЖЕН снова проверить статус.Он обеспечивает оценку времени, в течение которого конечный объект должен отправить
 его следующий опрос  3.4. Протокол отметки времени через HTTP  В этом подразделе описаны средства для передачи кодированных ASN.1
 сообщения для обмена протоколами, описанными в разделе 2 и
 Приложение D через протокол передачи гипертекста.  Два объекта MIME указаны следующим образом.  Тип содержимого: приложение / отметка-запрос << сообщение запроса отметки времени в кодировке ASN.1 DER >>  Тип содержимого: приложение / отметка времени-ответ << АСН.1 ответное сообщение с меткой времени в кодировке DER >>  Эти объекты MIME можно отправлять и получать с помощью обычного HTTP.
 движки обработки по WWW ссылкам и предоставляет простой браузер -
 серверный транспорт для сообщений с отметками времени.  После получения действительного запроса сервер ДОЛЖЕН ответить либо
 действительный ответ с типом содержимого application / timestamp-response или
 с ошибкой HTTP.  4. Соображения безопасности  Весь этот документ касается соображений безопасности. когда
 При разработке службы TSA были приняты следующие соображения:
 определены, которые влияют на достоверность или "доверие" к
 маркер отметки времени.1. Когда TSA больше не будет использоваться, но закрытый ключ TSA имеет
 не был скомпрометирован, сертификат органа ДОЛЖЕН быть
 отозван. Когда расширение reasonCode относительно отозванного
 сертификат от TSA присутствует в расширениях записи CRL,
 он ДОЛЖЕН быть установлен в значение unspecified (0), affiliationChanged (3),
 superseded (4) или cessationOfOperation (5). В таком случае при любом
 в будущем токены, подписанные соответствующим ключом, будут
 считается недействительным, но токены, созданные до отзыва
 время останется в силе.Когда расширение reasonCode относительно
 отозванный сертификат от TSA отсутствует в CRL
 расширения записи, затем все токены, подписанные
 соответствующий ключ ДОЛЖЕН считаться недействительным. Для этого
 причина, рекомендуется использовать расширение reasonCode.  2. Когда закрытый ключ TSA был скомпрометирован,
 соответствующий сертификат ДОЛЖЕН быть отозван. В этом случае
 Разумкод расширения относительно отозванного сертификата из
 TSA может присутствовать или не присутствовать в расширениях записей CRL.когда
 он присутствует, тогда он ДОЛЖЕН быть установлен на keyCompromise (1). любой
 токен, подписанный TSA с использованием этого закрытого ключа, нельзя доверять
 больше. По этой причине крайне важно, чтобы частный агент TSA
 ключ должен быть защищен надлежащими средствами безопасности и контроля, чтобы
 минимизировать возможность компромисса. Если закрытый ключ
 становится скомпрометированным, контрольный журнал всех токенов, сгенерированных
 TSA МОЖЕТ предоставить средства для различения подлинных и
 фальшивые задним числом токены.Два токена отметки времени из двух разных
 TSA - еще один способ решить эту проблему.  3. Ключ подписи TSA ДОЛЖЕН быть достаточной длины, чтобы позволить
 достаточно долгий срок службы. Даже если это будет сделано, ключ будет
 имеют ограниченный срок службы. Таким образом, любой токен, подписанный TSA, ДОЛЖЕН
 снова поставить отметку времени (если подлинные копии старых CRL
 доступно) или нотариально заверенное (если их нет) на более поздний срок для продления
 доверие, которое существует в подписи TSA. жетоны отметок времени
 также может храниться у органа регистрации доказательств, чтобы
 поддерживать это доверие.4. Клиентское приложение, использующее только одноразовый номер и не использующее локальные часы, ДОЛЖНО
 беспокоиться о том, сколько времени он готов ждать
 ответ. Атака «человек посередине» может вызвать задержки.
 Таким образом, любой TimeStampResp, который занимает больше допустимого периода
 времени СЛЕДУЕТ считать подозрительным. Поскольку каждый вид транспорта
 указанные в этом документе имеют разные характеристики задержки,
 период времени, который считается приемлемым, будет зависеть от
 конкретный используемый способ транспортировки, а также другая среда
 факторы.5. Если разные организации получают токены отметок времени на одних и тех же данных
 объект, использующий тот же алгоритм хеширования, или одна сущность получает
 несколько токенов отметки времени на одном объекте, сгенерированный
 жетоны отметок времени будут включать идентичные отпечатки сообщений; как
 в результате наблюдатель с доступом к этим токенам отметки времени может
 сделайте вывод, что отметки времени могут относиться к одним и тем же базовым данным.  6. Случайные или преднамеренные повторы запросов, включающих
 может произойти тот же алгоритм хеширования и значение.Случайные повторы
 возникает, когда более одной копии одного и того же сообщения запроса получает
 отправлено в TSA из-за проблем в промежуточной сети
 элементы. Умышленные повторы происходят, когда посредник воспроизводит
 законные ответы TS. Чтобы обнаружить эти ситуации,
 можно использовать несколько методов. Использование одноразового номера всегда позволяет
 обнаруживать повторы, поэтому его использование РЕКОМЕНДУЕТСЯ. Другая
 возможность использовать как местные часы, так и скользящее временное окно
 во время которого запрашивающий запоминает все хэши, отправленные во время
 это временное окно.При получении ответа запрашивающий
 гарантирует, что время ответа будет в пределах времени
 окно и что есть только одно вхождение хэш-значения в
 это временное окно. Если одно и то же значение хеш-функции присутствует более чем
 один раз в пределах временного окна запрашивающая сторона может использовать одноразовый номер,
 или подождите, пока не переместится временное окно, чтобы вернуться к делу
 где одно и то же значение хеш-функции появляется только один раз за это время
 окно.  5. Права интеллектуальной собственности  IETF не занимает никакой позиции относительно действительности или объема любых
 интеллектуальная собственность или другие права, которые могут быть заявлены в отношении
 к реализации или использованию технологии, описанной в этом
 документ или степень, в которой любая лицензия на такие права может
 или может быть недоступен; и не означает, что он сделал
 любые попытки идентифицировать такие права.Информация о IETF
 процедуры в отношении прав в стандартах-трек и стандарты-
 соответствующую документацию можно найти в BCP-11. Копии претензий
 права, предоставляемые для публикации, и любые гарантии лицензий
 быть доступным, или в результате попытки получить
 генеральная лицензия или разрешение на использование таких имущественных прав
 разработчиками или пользователями этой спецификации можно получить из
 Секретариат IETF.  IETF приглашает любую заинтересованную сторону довести до ее сведения любые
 авторские права, патенты или заявки на патенты или другие проприетарные
 права, которые могут охватывать технологии, которые могут потребоваться для практики
 этот стандарт.Пожалуйста, направьте информацию исполнительному директору IETF.
 Директор.  Следующие восемь (8) патентов США, связанных со временем
 штампы, перечисленные в хронологическом порядке, как известно авторам
 существуют в настоящее время. Это не может быть исчерпывающий список. Другие
 патенты МОГУТ существовать или выдаваться в любое время. Этот список предоставляется
 в информационных целях; на сегодняшний день IETF не уведомлен
 прав интеллектуальной собственности, заявленных в отношении любого из  спецификации, содержащиеся в этом документе.Если эта ситуация
 изменения, текущий статус можно найти в онлайн-списке заявленных
 права (страница IETF с уведомлениями о правах интеллектуальной собственности).  Разработчикам этого протокола СЛЕДУЕТ проводить собственный патентный поиск.
 и определить, существуют ли какие-либо обременения на их
 реализация.  Пользователи этого протокола ДОЛЖНЫ выполнять собственный патентный поиск и
 определить, существуют ли какие-либо препятствия на использование этого
 стандарт.  # 5,001,752 Публичная / нотариальная служба с указанием даты и времени
Дата подачи: 13 октября 1989 г.
Выпущено: 19 марта 1991 г.
Изобретатель: Эддисон М.Фишер  # 5,022,080 Электронный нотариус
Дата подачи: 16 апреля 1989 г.
Выпущено: 4 июня 1991 г.
Изобретатели: Роберт Т. Дерст, Кевин Д. Хантер.  # 5,136,643 Публичная / нотариальная служба с ключевой датой и временем
Дата подачи: 20 декабря 1990 г.
Выпущено: 4 августа 1992 г.
Изобретатель: Эддисон М. Фишер
Примечание: это продолжение патента № 5,001,752.)  # 5,136,646 Цифровой документ с отметкой времени и сертификатом Catenate
Дата подачи: 2 августа 1990 г.
Выпущено: 4 августа 1992 г.
Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл.
(правопреемник) Bell Communications Research, Inc.,  # 5,136,647 Метод безопасной временной отметки цифровых документов
Дата подачи: 2 августа 1990 г.
Выпущено: 4 августа 1992 г.
Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл.
(правопреемник) Bell Communications Research, Inc.,  # 5,373,561 Метод продления срока действия криптографии
Сертификат
Дата подачи: 21 декабря 1992 г.
Выдан: 13 декабря 1994 г.
Изобретатели: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл.
(правопреемник) Bell Communications Research, Inc.,  # 5,422,953 Персональное устройство нотариуса даты / времени
Дата подачи: 5 мая 1993 г.
Выпущено: 6 июня 1995 г.
Изобретатель: Эддисон М.Фишер  # 5781629 Система аутентификации цифровых документов
Дата подачи: 21 февраля 1997 г.
Выпущено: 14 июля 1998 г.
Изобретатель: Стюарт А. Хабер, Уэйкфилд С. Сторнетта мл.
(правопреемник) Surety Technologies, Inc.,  6. Ссылки  [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения
 Уровни требований », BCP 14, RFC 2119, март 1997 г.  [RFC2246] Диркс, Т. и К. Аллен, «Протокол TLS, версия 1.0»,
 RFC 2246, январь 1999 г.  [RFC2510] Адамс, К. и С. Фаррелл, "Internet X.509 Открытый ключ
 Инфраструктура, протоколы управления сертификатами », RFC
 2510, март 1999 г.  [RFC2459] Housley, R., Ford, W., Polk, W. и D. Solo, "Интернет
 Инфраструктура открытого ключа X.509, сертификат и CRL
 Профиль », RFC 2459, январь 1999 г.  [CMS] Housley, R., "Синтаксис криптографических сообщений", RFC 2630,
 Июнь 1999 г.  [DSS] Стандарт цифровой подписи. FIPS Pub 186. Национальный
 Институт стандартов и технологий.19 мая 1994 г.  [ESS] Хоффман П., «Расширенные службы безопасности для S / MIME», RFC
 2634, июнь 1999 г.  [ISONR] ISO / IEC 10181-5: Структуры безопасности в открытых системах.
 Система предотвращения отказа от авторства. Апрель 1997 г.  [MD5] Ривест Р., "Алгоритм дайджеста сообщения MD5", RFC 1321,
 Апрель 1992 г.  [SHA1] Стандарт безопасного хеширования. FIPS Pub 180-1. Национальный институт
 стандартов и технологий. 17 апреля 1995 г.  7. Адреса авторов  Карлайл Адамс
 Entrust, Inc.1000 инноваций
 Оттава, Онтарио
 K2K 3E7
 КАНАДА  Электронная почта: [email protected]  Пэт Кейн
 BBN
 70 Fawcett Street
 Кембридж, Массачусетс 02138
 США.  Электронная почта: [email protected]  Денис Пинкас
 Integris
 Версаль, 68
 Б.П. 434
 78430 Louveciennes
 ФРАНЦИЯ  Электронная почта: [email protected]  Роберт Зуккерато
 Entrust, Inc.
 1000 инноваций
 Оттава, Онтарио
 K2K 3E7
 КАНАДА  Электронная почта: [email protected]  ПРИЛОЖЕНИЕ A. Атрибут метки времени подписи с использованием CMS  Одно из основных применений отметки времени - установка отметки времени на цифровом
 подпись, чтобы доказать, что цифровая подпись была создана до
 данное время.Если соответствующий сертификат открытого ключа
 отозвано, это позволяет проверяющему узнать, была ли подпись
 создано до или после даты отзыва.  Разумное место для хранения метки времени - это структура [CMS] как
 беззнаковый атрибут.  В этом приложении определяется атрибут отметки времени подписи, который может быть
 используется для отметки времени цифровой подписи.  Следующий идентификатор объекта определяет метку времени подписи.
 атрибут:  id-aa-timeStampToken ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2)
 us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) aa (2) 14}  Значение атрибута отметки времени подписи имеет ASN.1 тип
 SignatureTimeStampToken:  SignatureTimeStampToken :: = TimeStampToken  Значение поля messageImprint в TimeStampToken должно быть
 хэш значения поля подписи в SignerInfo для
 signedData имеет отметку времени.  ПРИЛОЖЕНИЕ B - Размещение подписи в определенный момент времени  Мы представляем пример возможного использования этой общей отметки времени.
 оказание услуг. Он ставит подпись в определенный момент времени, начиная с
 что соответствующая информация о статусе сертификата (например,g., CRL)
 НЕОБХОДИМО проверить. Это приложение предназначено для использования в
 в сочетании с доказательствами, полученными с использованием цифровой подписи
 механизм.  Подпись может быть проверена только в соответствии с подтверждением отказа от авторства.
 политика. Эта политика МОЖЕТ быть неявной или явной (т. Е. Указана в
 доказательства, предоставленные подписавшим). Политика неотказуемости может
 указать, среди прочего, период времени, разрешенный подписывающей стороной для
 объявить о компрометации ключа подписи, используемого для генерации
 цифровые подписи.Таким образом, подпись не может быть гарантирована
 действует до окончания этого временного периода.  Чтобы проверить цифровую подпись, может быть использован следующий базовый метод:
 используемый:  A) Информация с отметками времени должна быть получена вскоре после
 подпись была произведена (например, в течение нескольких минут или часов).  1) Подпись предоставляется органу по штампам времени.
 (TSA). Затем TSA возвращает TimeStampToken (TST) при
 эта подпись.  2) После этого инициатор службы ДОЛЖЕН проверить, что
 TimeStampToken правильный.Б) Действительность цифровой подписи затем может быть проверена в
 следующим образом:  1) Сам токен отметки времени ДОЛЖЕН быть проверен, и он ДОЛЖЕН быть
 проверено, что это относится к подписи подписавшего.  2) Дата / время, указанные TSA в TimeStampToken
 ДОЛЖЕН быть восстановлен.  3) Сертификат, используемый подписывающей стороной, ДОЛЖЕН быть идентифицирован и
 извлечен.  4) Дата / время, указанные TSA, ДОЛЖНЫ быть в пределах
 срок действия сертификата подписывающей стороны.5) Информация об отзыве этого сертификата в
 ДОЛЖНА быть получена дата / время операции отметки времени.  6) В случае отзыва сертификата дата / время
 отзыв должен быть позже даты / времени, указанных
 TSA.  Если все эти условия выполнены успешно, то электронная подпись
 признаются действительными.  ПРИЛОЖЕНИЕ C: Модуль ASN.1 с использованием синтаксиса 1988 г.  PKIXTSP {iso (1) идентифицированная организация (3) dod (6) Интернет (1)
 безопасность (5) механизмы (5) pkix (7) id-mod (0) id-mod-tsp (13)}  ОПРЕДЕЛЕНИЯ НЕЯВНЫЕ ТЭГИ :: =  НАЧАТЬ  - ЭКСПОРТ ВСЕ -  ИМПОРТ  Расширения, AlgorithmIdentifier
 ОТ PKIX1Explicit88 {iso (1) идентифицированная организация (3)
 dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7)
 id-mod (0) id-pkix1-explicit-88 (1)}  GeneralName ОТ PKIX1Implicit88 {iso (1)
 идентифицированная организация (3) dod (6) интернет (1) безопасность (5)
 механизмы (5) pkix (7) id-mod (0) id-pkix1-implicit-88 (2)}  ContentInfo ИЗ CryptographicMessageSyntax {iso (1)
 член-тело (2) us (840) rsadsi (113549) pkcs (1) pkcs-9 (9)
 smime (16) модули (0) cms (1)}  PKIFreeText ОТ PKIXCMP {iso (1) идентифицированная организация (3)
 dod (6) интернет (1) безопасность (5) механизмы (5) pkix (7) id-mod (0)
 id-mod-cmp (9)};  - Локально определенные OID -  - eContentType для токена отметки времени  id-ct-TSTInfo ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1) тело-член (2)
us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16) ct (1) 4}  - 2.4.1  TimeStampReq :: = SEQUENCE {
 версия INTEGER {v1 (1)},
 messageImprint MessageImprint,
 - OID хеш-алгоритма и хеш-значение данных, которые нужно
 - с отметкой времени
 reqPolicy TSAPolicyId ДОПОЛНИТЕЛЬНО,
 nonce INTEGER ДОПОЛНИТЕЛЬНО,
 certReq BOOLEAN DEFAULT FALSE,
 расширения [0] IMPLICIT Extensions OPTIONAL}  MessageImprint :: = SEQUENCE {
 hashAlgorithm AlgorithmIdentifier,
 hashedMessage OCTET STRING}  TSAPolicyId :: = ИДЕНТИФИКАТОР ОБЪЕКТА  - 2.4.2  TimeStampResp :: = SEQUENCE {
 статус PKIStatusInfo,
 timeStampToken TimeStampToken ДОПОЛНИТЕЛЬНО}  - Статус основан на определении статуса
- в разделе 3.2.3 [RFC2510]  PKIStatusInfo :: = SEQUENCE {
 статус PKIStatus,
 statusString PKIFreeText ДОПОЛНИТЕЛЬНО,
 failInfo PKIFailureInfo ДОПОЛНИТЕЛЬНО}  PKIStatus :: = INTEGER {
 предоставлено (0),
 - когда PKIStatus содержит нулевое значение TimeStampToken, как
 запрошено, присутствует.предоставленоWithMods (1),
 - когда PKIStatus содержит значение, равное TimeStampToken,
 с доработками, присутствует.
 отказ (2),
 ожидание (3),
 revocationWarning (4),
 - это сообщение содержит предупреждение о том, что отзыв
 - неизбежный
 revocationNotification (5)
 - уведомление о том, что произошел отзыв}  - Когда TimeStampToken отсутствует
 - failInfo указывает причину, по которой
 - запрос отметки времени был отклонен и
 - может быть одним из следующих значений.PKIFailureInfo :: = BIT STRING {
 badAlg (0),
 - нераспознанный или неподдерживаемый идентификатор алгоритма
 badRequest (2),
 - транзакция не разрешена или не поддерживается
 badDataFormat (5),
 - представленные данные имеют неправильный формат
 timeNotAvailable (14),
 - источник времени TSA недоступен
 unacceptedPolicy (15),
 - запрошенная политика TSA не поддерживается TSA.
 unacceptedExtension (16),
 - запрошенное расширение не поддерживается TSA.addInfoNotAvailable (17)
 - запрошенная дополнительная информация непонятна
 - или недоступен
 systemFailure (25)
 - запрос не может быть обработан из-за сбоя системы}  TimeStampToken :: = ContentInfo  - contentType - это id-signedData, как определено в [CMS]
 - содержание - это SignedData, как определено в ([CMS])
 - eContentType в SignedData - id-ct-TSTInfo
 - Электронный контент в SignedData - это TSTInfo  TSTInfo :: = SEQUENCE {
 версия INTEGER {v1 (1)},
 политика TSAPolicyId,
 messageImprint MessageImprint,
 - ДОЛЖЕН иметь то же значение, что и аналогичное поле в
 - TimeStampReq
 serialNumber INTEGER,
 - Пользователи с отметкой времени ДОЛЖНЫ быть готовы к использованию целых чисел.
 - до 160 бит.genTime GeneralizedTime,
 точность Точность ДОПОЛНИТЕЛЬНАЯ,
 заказ BOOLEAN DEFAULT FALSE,
 nonce INTEGER ДОПОЛНИТЕЛЬНО,
 - ДОЛЖЕН присутствовать, если подобное поле присутствовало
 - в TimeStampReq. В этом случае он ДОЛЖЕН иметь такое же значение.
 tsa [0] GeneralName ДОПОЛНИТЕЛЬНО,
 extension [1] IMPLICIT Extensions OPTIONAL}  Точность :: = SEQUENCE {
 секунды INTEGER OPTIONAL,
 миллис [0] INTEGER (1..999) ДОПОЛНИТЕЛЬНО,
 микрос [1] INTEGER (1..999) ДОПОЛНИТЕЛЬНО}  КОНЕЦ  ПРИЛОЖЕНИЕ D: Дескрипторы доступа для меток времени.  [В этом приложении описывается расширение, основанное на расширении SIA, которое
 будет определен в "сыне-RFC2459". Поскольку во время
 публикация этого документа "сын-оф-RFC2459" еще не доступна,
 его описание помещено в информативном приложении. Содержание
 это приложение в конечном итоге будет включено в
 Документ RFC2459, после которого это приложение больше не понадобится.В будущей версии этого документа это приложение, скорее всего, будет опущено.
 обратитесь непосредственно к сыну RFC2459.]  Сертификат TSA МОЖЕТ содержать доступ к информации о субъекте (SIA)
 extension (сын RFC2459), чтобы передать метод
 связавшись с TSA. Поле accessMethod в этом расширении ДОЛЖНО
 содержат OID id-ad-timestamping:  Следующий идентификатор объекта определяет дескрипторы доступа для
 штамп времени.  id-ad-timeStamping ИДЕНТИФИКАТОР ОБЪЕКТА :: = {iso (1)
 идентифицированная организация (3) dod (6)
 интернет (1) безопасность (5) механизмы (5) pkix (7)
 ad (48) timestamping (3)}  Значение поля accessLocation определяет транспорт (например,грамм.,
 HTTP) используется для доступа к TSA и может содержать другой транспорт.
 зависимая информация (например, URL).  Полное заявление об авторских правах  Авторское право (C) The Internet Society (2001). Все права защищены.  Этот документ и его переводы могут быть скопированы и предоставлены
 другие и производные работы, которые комментируют или иным образом объясняют это
 или помочь в его реализации могут быть подготовлены, скопированы, опубликованы
 и распространяется, полностью или частично, без ограничения каких-либо
 вида, при условии, что указанное выше уведомление об авторских правах и этот абзац
 включены во все такие копии и производные работы.Однако это
 сам документ не может быть изменен каким-либо образом, например, путем удаления
 уведомление об авторских правах или ссылки на Internet Society или другие
 Интернет-организации, за исключением случаев, когда это необходимо для
 разработки Интернет-стандартов, в этом случае процедуры для
 авторские права, определенные в процессе разработки стандартов Интернета, должны быть
 следовали, или по мере необходимости перевести его на другие языки, кроме
 Английский.  Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут
 аннулировано Интернет-сообществом, его правопреемниками или правопреемниками.Этот документ и содержащаяся в нем информация размещены на
 Основа "КАК ЕСТЬ" и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ
 TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ
 НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ
 ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ
 КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.
Об авторе
 
 alexxlab  administrator 
Оставить ответ
 Отменить ответ
  
Рубрики
Вложен
Вложения
Заработ
Заработок
Начать
Новичк
Новичкам
Разное
С чего начать
Совет
Советы
Фриланс
 © 2019 ICQ Information Center