Внутренний номер: 324809
Varianta în limba de stat
Республика Молдова
от 07.12.2006
об утверждении Технических норм
в сфере цифровой подписи
в сфере цифровой подписи
Утратил силу согласно ПСИБ69 от 15.07.16, МО215-216/19.07.16 ст.1201; в силу с 19.07.16
ИЗМЕНЕН
ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390
Во исполнение Постановления Правительства № 945 от 5 сентября 2005 года «О центрах сертификации открытых ключей» (Официальный монитор Республики Молдова, 2005 г., № 123-125, ст. 1020), на основании ч. (2) ст. 36 Закона № 264-XV от 15 июля 2004 года об электронном документе и цифровой подписи (Официальный монитор Республики Молдова, 2004 г., № 132-137, ст. 710) ПРИКАЗЫВАЮ:
1. Утвердить Технические нормы в сфере цифровой подписи (прилагаются).
2. Контроль за исполнением настоящего приказа возложить на заместителя директора Службы информации и безопасности Республики Молдова господина Валентина Дедю.
3. Настоящий приказ вступает в силу со дня опубликования в Официальном мониторе Республики Молдова.
ИЗМЕНЕН
ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390
Во исполнение Постановления Правительства № 945 от 5 сентября 2005 года «О центрах сертификации открытых ключей» (Официальный монитор Республики Молдова, 2005 г., № 123-125, ст. 1020), на основании ч. (2) ст. 36 Закона № 264-XV от 15 июля 2004 года об электронном документе и цифровой подписи (Официальный монитор Республики Молдова, 2004 г., № 132-137, ст. 710) ПРИКАЗЫВАЮ:
1. Утвердить Технические нормы в сфере цифровой подписи (прилагаются).
2. Контроль за исполнением настоящего приказа возложить на заместителя директора Службы информации и безопасности Республики Молдова господина Валентина Дедю.
3. Настоящий приказ вступает в силу со дня опубликования в Официальном мониторе Республики Молдова.
Директор Службы
информации и безопасности Ион УРСУ
№ 64. Кишинэу, 7 декабря 2006 г.
Утверждены
Приказом директора Службы информации
и безопасности Республики Молдова
№ 64 от 7 декабря 2006 г.
Приказом директора Службы информации
и безопасности Республики Молдова
№ 64 от 7 декабря 2006 г.
ТЕХНИЧЕСКИЕ НОРМЫ
в сфере цифровой подписи
I. Общие положения
в сфере цифровой подписи
I. Общие положения
1. Настоящие технические нормы разработаны в соответствии с Законом об электронном документе и цифровой подписи № 264-XV от 15 июля 2004 года, Постановлением Правительства № 945 от 5 сентября 2005 года «О центрах сертификации открытых ключей» и устанавливают нормы и требования соответствия стандартам и рекомендациям в сфере цифровой подписи, принципы формирования инфраструктуры открытых ключей, создания и управления закрытыми, открытыми ключами и сертификатами открытых ключей, создания и проверки цифровой подписи и фиксирования времени.
2. Настоящие технические нормы являются регламентирующим документом в сфере цифровой подписи и обязательны для юридических лиц, оказывающих услуги по сертификации открытых ключей и иные виды услуг, связанных с цифровой подписью, а также для пользователей цифровой подписи.
3. В настоящем документе используются следующие понятия и сокращения:
статус сертификата – состояние сертификата открытого ключа в определенный момент времени. Статус сертификата определяется списком отозванных сертификатов;
функция хеширования – криптографическая функция, которая отвечает следующим условиям: функция является однонаправленной и имеет высокую алгоритмическую сложность для нахождения коллизий;
фиксирование времени – процедура, осуществляемая путем добавления к электронному документу метки времени таким образом, чтобы исключить возможность изменения документа с сохранением добавленной ранее метки времени;
метка времени (time-stamp) – атрибут электронного документа, который, посредством цифровой подписи, заверяет, что информация существовала в определенный момент времени;
CWA (CEN Workshop agreement) – Соглашение рабочей группы Европейского комитета по стандартизации. Справочные тексты опубликованы на сайте www.cenorm.be;
DSA (Digital Signature Algorithm) – асимметричный криптографический алгоритм цифровой подписи. Справочные тексты опубликованы на сайте www.nist.gov;
FIPS (Federal Information Processing Standard) – федеральный стандарт по обработке информации. Справочные тексты опубликованы на сайте www.nist.gov;
IETF (Internet Engineering Task Force) – рабочая группа инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org;
ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) – Международная организация по стандартизации / Международная комиссия по электротехнике. Официальный сайт www.iso.org;
ITU-T (International Telecommunication Union Telecommunication Standardization Sector) – стандарт Международного союза электросвязи в области телекоммуникаций. Справочные тексты опубликованы на сайте www.itu.int;
PKCS (Public Key Cryptography Standards) – криптографические стандарты с открытым ключом. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
RFC (Request for comments) – рекомендации, утверждающие документы, прошедшие публичный анализ в рамках процесса, согласованного с рабочей группой инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org/rfc;
RSA (Rivest, Shamir, Adleman) – асимметричный криптографический алгоритм цифровой подписи, разработанный исследователями Rivest, Shamir и Adleman. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
SM – национальный стандарт Республики Молдова.
подтверждение достоверности данных и протокол сервера сертификации – процедура подтверждения достоверности и корректности электронных документов, подписанных цифровой подписью, действительности сертификата открытого ключа и обладания или наличия данных.
[Пкт.3 абз. введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
2. Настоящие технические нормы являются регламентирующим документом в сфере цифровой подписи и обязательны для юридических лиц, оказывающих услуги по сертификации открытых ключей и иные виды услуг, связанных с цифровой подписью, а также для пользователей цифровой подписи.
3. В настоящем документе используются следующие понятия и сокращения:
статус сертификата – состояние сертификата открытого ключа в определенный момент времени. Статус сертификата определяется списком отозванных сертификатов;
функция хеширования – криптографическая функция, которая отвечает следующим условиям: функция является однонаправленной и имеет высокую алгоритмическую сложность для нахождения коллизий;
фиксирование времени – процедура, осуществляемая путем добавления к электронному документу метки времени таким образом, чтобы исключить возможность изменения документа с сохранением добавленной ранее метки времени;
метка времени (time-stamp) – атрибут электронного документа, который, посредством цифровой подписи, заверяет, что информация существовала в определенный момент времени;
CWA (CEN Workshop agreement) – Соглашение рабочей группы Европейского комитета по стандартизации. Справочные тексты опубликованы на сайте www.cenorm.be;
DSA (Digital Signature Algorithm) – асимметричный криптографический алгоритм цифровой подписи. Справочные тексты опубликованы на сайте www.nist.gov;
FIPS (Federal Information Processing Standard) – федеральный стандарт по обработке информации. Справочные тексты опубликованы на сайте www.nist.gov;
IETF (Internet Engineering Task Force) – рабочая группа инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org;
ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) – Международная организация по стандартизации / Международная комиссия по электротехнике. Официальный сайт www.iso.org;
ITU-T (International Telecommunication Union Telecommunication Standardization Sector) – стандарт Международного союза электросвязи в области телекоммуникаций. Справочные тексты опубликованы на сайте www.itu.int;
PKCS (Public Key Cryptography Standards) – криптографические стандарты с открытым ключом. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
RFC (Request for comments) – рекомендации, утверждающие документы, прошедшие публичный анализ в рамках процесса, согласованного с рабочей группой инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org/rfc;
RSA (Rivest, Shamir, Adleman) – асимметричный криптографический алгоритм цифровой подписи, разработанный исследователями Rivest, Shamir и Adleman. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
SM – национальный стандарт Республики Молдова.
подтверждение достоверности данных и протокол сервера сертификации – процедура подтверждения достоверности и корректности электронных документов, подписанных цифровой подписью, действительности сертификата открытого ключа и обладания или наличия данных.
[Пкт.3 абз. введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
II. Создание и управление открытым и закрытым ключами
4. Открытые и закрытые ключи уполномоченных лиц центров сертификации открытых ключей (далее - центры сертификации) и пользователей цифровой подписи создаются средствами цифровой подписи в соответствии с требованиями стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Secure signature-creation device “EAL 4+”, или SMV ISO/IEC 19790:2008 Information technology – Security techniques – Security requirements for cryptographic modules.
[Пкт.4 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
[Пкт.5 исключен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
6. Минимальная длина открытого и закрытого ключа составляет:
1) 2048 бит для алгоритма RSA для пользователей цифровой подписи;
2) 4096 бит для алгоритма RSA для центров сертификации;
3) 2048 бит для алгоритма DSA;
4) 160 бит для алгоритма DSA, основанного на эллиптических кривых;
5) 512 бит для алгоритма SM GOST 34.10:2006.
7. Длины открытых и закрытых ключей уполномоченных лиц центров сертификации должны быть не меньше длины открытых и закрытых ключей уполномоченных лиц нижестоящих центров сертификации и пользователей цифровой подписи, сертифицирующих открытые ключи в этих центрах.
8. Управление открытыми и закрытыми ключами осуществляется в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
9. Срок действия закрытого ключа уполномоченного лица центра сертификации составляет:
2 года и 6 месяцев – для центра сертификации высшего уровня;
1 год и 3 месяца – для центров сертификации второго уровня;
7 месяцев – для центров сертификации третьего уровня.
Начало периода действия закрытого ключа исчисляется с даты и времени начала срока действия сертификата соответствующего открытого ключа.
10. Срок действия сертификата открытого ключа, соответствующего закрытому ключу уполномоченного лица центра сертификации, составляет:
5 лет – для центра сертификации высшего уровня;
2 года и 6 месяцев – для центров сертификации второго уровня;
1 год и 3 месяца – для центров сертификации третьего уровня.
101. Срок действия закрытого ключа сервиса метки времени (TSP), сервиса on-line проверки статуса сертификата (OCSP), сервиса проверки достоверности данных и протокола сервера сертификации (DVCS) и сертификата открытого ключа, соответствующего закрытому ключу сервиса, составляет 2 года и 6 месяцев.
[Пкт.101 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
102. Срок действия закрытого ключа пользователя цифровой подписи и сертификата открытого ключа, соответствующего закрытому ключу пользователя цифровой подписи, составляет 1 год.
[Пкт.102 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
11. Закрытые ключи уполномоченных лиц центров сертификации и пользователей цифровой подписи хранятся на материальных носителях, реализующих криптографические функции. Криптографические операции подписания с использованием закрытого ключа должны осуществляться на микрочипе материального носителя.
12. Материальный носитель, содержащий закрытый ключ уполномоченного лица центра сертификации и пользователя цифровой подписи, должен соответствовать требованиям стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Secure signature-creation device “EAL 4+”, или SMV ISO/IEC 19790:2008 Information technology – Security techniques – Security requirements for cryptographic modules.
[Пкт.12 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
13. Материальный носитель, содержащий закрытый ключ пользователя цифровой подписи, дополнительно к перечисленным в пункте 12 стандартам должен соответствовать и требованиям стандарта PKCS#15 Cryptographic Token Information Syntax Standard.
[Пкт.13 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
14. Плановая смена открытых и закрытых ключей уполномоченных лиц центров сертификации осуществляется не ранее одного месяца до истечения срока действия закрытого ключа и не позднее истечения срока действия закрытого ключа.
15. Внеплановая смена открытых и закрытых ключей уполномоченных лиц центров сертификации осуществляется в случае компрометации или угрозы компрометации закрытого ключа.
16. В рамках процедуры смены закрытого и открытого ключей уполномоченного лица центра сертификации высшего уровня, данное лицо:
создает новую пару ключей (закрытый и открытый);
создает сертификат открытого ключа в форме электронного документа, содержащий старый открытый ключ, и подписывает его цифровой подписью с использованием нового закрытого ключа;
создает сертификат открытого ключа в форме электронного документа, содержащий новый открытый ключ, и подписывает его цифровой подписью с использованием закрытого ключа, срок действия которого истекает;
создает сертификат открытого ключа в форме электронного документа, содержащий новый открытый ключ, и подписывает его цифровой подписью с использованием нового закрытого ключа.
17. В рамках процедуры смены открытых и закрытых ключей уполномоченного лица центра сертификации второго или третьего уровня, данное лицо:
создает новую пару ключей (закрытый и открытый);
сертифицирует новый открытый ключ в вышестоящем центре сертификации.
18. Старый закрытый ключ уполномоченного лица центра сертификации перестает действовать с момента создания сертификата нового открытого ключа. Сертификат старого открытого ключа уполномоченного лица центра сертификации продолжает действовать до истечения срока его действия.
19. По истечении срока действия закрытого ключа он используется до истечения срока действия сертификата открытого ключа, соответствующего этому закрытому ключу, только для подписания списка отозванных сертификатов.
[Пкт.19 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
191. По истечении срока действия сертификата открытого ключа, соответствующего закрытому ключу, отмеченному в пункте 19, закрытый ключ уничтожается.
[Пкт.191 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
20. Сертификат открытого ключа уполномоченного лица центра сертификации высшего уровня, содержащий новый открытый ключ и подписанный цифровой подписью с использованием закрытого ключа, срок действия которого истекает, а также сертификат открытого ключа уполномоченного лица центра сертификации высшего уровня, содержащий старый открытый ключ и подписанный цифровой подписью с использованием нового закрытого ключа, действуют до истечения срока действия сертификата старого открытого ключа.
21.Процедура смены открытых и закрытых ключей пользователей цифровой подписи определяется пользователями цифровой подписи в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
[Пкт.4 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
[Пкт.5 исключен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
6. Минимальная длина открытого и закрытого ключа составляет:
1) 2048 бит для алгоритма RSA для пользователей цифровой подписи;
2) 4096 бит для алгоритма RSA для центров сертификации;
3) 2048 бит для алгоритма DSA;
4) 160 бит для алгоритма DSA, основанного на эллиптических кривых;
5) 512 бит для алгоритма SM GOST 34.10:2006.
7. Длины открытых и закрытых ключей уполномоченных лиц центров сертификации должны быть не меньше длины открытых и закрытых ключей уполномоченных лиц нижестоящих центров сертификации и пользователей цифровой подписи, сертифицирующих открытые ключи в этих центрах.
8. Управление открытыми и закрытыми ключами осуществляется в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
9. Срок действия закрытого ключа уполномоченного лица центра сертификации составляет:
2 года и 6 месяцев – для центра сертификации высшего уровня;
1 год и 3 месяца – для центров сертификации второго уровня;
7 месяцев – для центров сертификации третьего уровня.
Начало периода действия закрытого ключа исчисляется с даты и времени начала срока действия сертификата соответствующего открытого ключа.
10. Срок действия сертификата открытого ключа, соответствующего закрытому ключу уполномоченного лица центра сертификации, составляет:
5 лет – для центра сертификации высшего уровня;
2 года и 6 месяцев – для центров сертификации второго уровня;
1 год и 3 месяца – для центров сертификации третьего уровня.
101. Срок действия закрытого ключа сервиса метки времени (TSP), сервиса on-line проверки статуса сертификата (OCSP), сервиса проверки достоверности данных и протокола сервера сертификации (DVCS) и сертификата открытого ключа, соответствующего закрытому ключу сервиса, составляет 2 года и 6 месяцев.
[Пкт.101 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
102. Срок действия закрытого ключа пользователя цифровой подписи и сертификата открытого ключа, соответствующего закрытому ключу пользователя цифровой подписи, составляет 1 год.
[Пкт.102 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
11. Закрытые ключи уполномоченных лиц центров сертификации и пользователей цифровой подписи хранятся на материальных носителях, реализующих криптографические функции. Криптографические операции подписания с использованием закрытого ключа должны осуществляться на микрочипе материального носителя.
12. Материальный носитель, содержащий закрытый ключ уполномоченного лица центра сертификации и пользователя цифровой подписи, должен соответствовать требованиям стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Secure signature-creation device “EAL 4+”, или SMV ISO/IEC 19790:2008 Information technology – Security techniques – Security requirements for cryptographic modules.
[Пкт.12 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
13. Материальный носитель, содержащий закрытый ключ пользователя цифровой подписи, дополнительно к перечисленным в пункте 12 стандартам должен соответствовать и требованиям стандарта PKCS#15 Cryptographic Token Information Syntax Standard.
[Пкт.13 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
14. Плановая смена открытых и закрытых ключей уполномоченных лиц центров сертификации осуществляется не ранее одного месяца до истечения срока действия закрытого ключа и не позднее истечения срока действия закрытого ключа.
15. Внеплановая смена открытых и закрытых ключей уполномоченных лиц центров сертификации осуществляется в случае компрометации или угрозы компрометации закрытого ключа.
16. В рамках процедуры смены закрытого и открытого ключей уполномоченного лица центра сертификации высшего уровня, данное лицо:
создает новую пару ключей (закрытый и открытый);
создает сертификат открытого ключа в форме электронного документа, содержащий старый открытый ключ, и подписывает его цифровой подписью с использованием нового закрытого ключа;
создает сертификат открытого ключа в форме электронного документа, содержащий новый открытый ключ, и подписывает его цифровой подписью с использованием закрытого ключа, срок действия которого истекает;
создает сертификат открытого ключа в форме электронного документа, содержащий новый открытый ключ, и подписывает его цифровой подписью с использованием нового закрытого ключа.
17. В рамках процедуры смены открытых и закрытых ключей уполномоченного лица центра сертификации второго или третьего уровня, данное лицо:
создает новую пару ключей (закрытый и открытый);
сертифицирует новый открытый ключ в вышестоящем центре сертификации.
18. Старый закрытый ключ уполномоченного лица центра сертификации перестает действовать с момента создания сертификата нового открытого ключа. Сертификат старого открытого ключа уполномоченного лица центра сертификации продолжает действовать до истечения срока его действия.
19. По истечении срока действия закрытого ключа он используется до истечения срока действия сертификата открытого ключа, соответствующего этому закрытому ключу, только для подписания списка отозванных сертификатов.
[Пкт.19 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
191. По истечении срока действия сертификата открытого ключа, соответствующего закрытому ключу, отмеченному в пункте 19, закрытый ключ уничтожается.
[Пкт.191 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
20. Сертификат открытого ключа уполномоченного лица центра сертификации высшего уровня, содержащий новый открытый ключ и подписанный цифровой подписью с использованием закрытого ключа, срок действия которого истекает, а также сертификат открытого ключа уполномоченного лица центра сертификации высшего уровня, содержащий старый открытый ключ и подписанный цифровой подписью с использованием нового закрытого ключа, действуют до истечения срока действия сертификата старого открытого ключа.
21.Процедура смены открытых и закрытых ключей пользователей цифровой подписи определяется пользователями цифровой подписи в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
III. Создание и управление сертификатами открытых ключей
22. Процедуры сертификации открытых ключей (идентификация, аутентификация и регистрация пользователей цифровой подписи, получение заявлений на сертификацию открытых ключей, создание сертификатов открытых ключей, приостановление, возобновление действия и отзыв сертификатов) осуществляются в соответствии с рекомендацией IETF RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.
23. Управление сертификатами открытых ключей осуществляется в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
24. Заявления на сертификацию открытых ключей в форме электронного документа создаются в соответствии со стандартом PKCS#10: Certification Request Syntax Specification, версия 1.7, или с рекомендацией IETF RFC 2986 Certification Request Syntax Specification.
25. Сертификаты открытых ключей в форме электронного документа должны соответствовать требованиям стандарта ITU-T X.509, версии 3, стандарту SMV ISO CEI 9594-8:2007 Information technology. Open Systems Interconnection. The Directory: Public-key and attribute certificate frameworks или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile и IETF RFC 3739 Qualified Certificates Profile. Структуры сертификатов открытых ключей уполномоченных лиц центров сертификации и пользователей цифровой подписи представлены в приложениях № 1 и 2 настоящих технических норм.
[Пкт.25 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
26. Списки отозванных сертификатов должны соответствовать требованиям стандарта ITU-T X.509, версия 2, стандарту SMV ISO CEI 9594-8:2007 Information technology. Open Systems Interconnection. The Directory: Public-key and attribute certificate frameworks или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Структура списка отозванных сертификатов представлена в приложении № 4 настоящих технических норм.
[Пкт.26 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
27. Временем приостановления или возобновления действия сертификата открытого ключа считается время опубликования (выпуска) обновленного списка отозванных сертификатов (время, указанное в поле thisUpdate).
28. Статус сертификата открытого ключа определяется в соответствии с одной из следующих рекомендаций:
1) IETF RFC 2560 Internet X.509 Public Key Infrastructure Online Certificate Status Protocol;
2) IETF RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP, HTTP;
3) IETF RFC 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status;
[Пкт.28 подпкт.3) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
4) IETF RFC 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates.
[Пкт.28 подпкт.4) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
281. Структура сертификата сервиса on-line проверки статуса сертификата (OCSP) представлена в приложении №3 к настоящим Техническим нормам.
[Пкт.281 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
23. Управление сертификатами открытых ключей осуществляется в соответствии с рекомендациями IETF RFC 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
24. Заявления на сертификацию открытых ключей в форме электронного документа создаются в соответствии со стандартом PKCS#10: Certification Request Syntax Specification, версия 1.7, или с рекомендацией IETF RFC 2986 Certification Request Syntax Specification.
25. Сертификаты открытых ключей в форме электронного документа должны соответствовать требованиям стандарта ITU-T X.509, версии 3, стандарту SMV ISO CEI 9594-8:2007 Information technology. Open Systems Interconnection. The Directory: Public-key and attribute certificate frameworks или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile и IETF RFC 3739 Qualified Certificates Profile. Структуры сертификатов открытых ключей уполномоченных лиц центров сертификации и пользователей цифровой подписи представлены в приложениях № 1 и 2 настоящих технических норм.
[Пкт.25 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
26. Списки отозванных сертификатов должны соответствовать требованиям стандарта ITU-T X.509, версия 2, стандарту SMV ISO CEI 9594-8:2007 Information technology. Open Systems Interconnection. The Directory: Public-key and attribute certificate frameworks или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Структура списка отозванных сертификатов представлена в приложении № 4 настоящих технических норм.
[Пкт.26 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
27. Временем приостановления или возобновления действия сертификата открытого ключа считается время опубликования (выпуска) обновленного списка отозванных сертификатов (время, указанное в поле thisUpdate).
28. Статус сертификата открытого ключа определяется в соответствии с одной из следующих рекомендаций:
1) IETF RFC 2560 Internet X.509 Public Key Infrastructure Online Certificate Status Protocol;
2) IETF RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP, HTTP;
3) IETF RFC 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status;
[Пкт.28 подпкт.3) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
4) IETF RFC 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates.
[Пкт.28 подпкт.4) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
281. Структура сертификата сервиса on-line проверки статуса сертификата (OCSP) представлена в приложении №3 к настоящим Техническим нормам.
[Пкт.281 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
IV. Создание и проверка цифровой подписи
29. Цифровая подпись создается средствами цифровой подписи в соответствии с требованиями стандарта SMV CWA 14170:2007 Security requirements for signature creation applications.
30. Проверка цифровой подписи осуществляется средствами цифровой подписи в соответствии с требованиями стандарта SMV CWA 14171:2007 General guidelines for electronic signature verification.
31. Формат цифровой подписи должен соответствовать требованиям стандарта PKCS#7 Cryptographic Message Syntax Standard или IETF RFC 5126 CMS Advanced Electronic Signatures (CAdES) и XML Advanced Electronic Signatures (XAdES).
[Пкт.31 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
32. Алгоритмы создания и проверки цифровой подписи должны соответствовать требованиям одного из следующих стандартов и рекомендаций:
1) SM ISO/CEI 9796-2:2006 Информационные технологии. Методы обеспечения безопасности. Схемы цифровой подписи, позволяющие восстанавливать сообщения. Часть 2: Механизмы, основанные на факторизации целого числа; SM ISO/CEI 9796-3:2006 Информационные технологии. Методы защиты. Схемы цифровой сигнатуры, позволяющие восстанавливать сообщения. Часть 3: Механизмы, основанные на дискретном логарифме;
2) SM ISO/CEI 14888-1:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 1: Общие положения; SM ISO/CEI 14888-2:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 2: Механизмы на основе идентификаторов; SM ISO/CEI 14888-3:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 3: Механизмы на основе сертификатов;
3) SM GOST R 34.10:2006 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи;
4) IETF RFC 3447 Public-Key Cryptography Standards PKCS#1: RSA Cryptography Specifications, версия 2.1;
5) FIPS Publication 186-3 Digital Signature Standard (DSS) или SMV ISO/CEI 14888-2-2009 Information technology – Security techniques – Digital signatures with appendix – Part 2: Integer factorization based mechanisms.
[Пкт.32 подпкт.5) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
33. Алгоритмы функции хеширования должны соответствовать требованиям одного из следующих стандартов:
1) SM ISO/CEI 10118-1:2006 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 1: Общие положения; SM ISO/CEI 10118-2:2006 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 2: Хеш-функции с использованием алгоритма шифрования n-битными блоками; SM ISO/CEI 10118-3:2006 Технологии информационные. Методы обеспечения защиты. Хэш-функции. Часть 3: Выделенные хэш-функции; SM ISO/CEI 10118-4:2006 Информационная технология. Методы защиты. Хэш-функции. Часть 4: Хэш-функции, применяющие модульную арифметику;
2) SM GOST R 34.11:2006 Информационная технология. Криптографическая защита информации. Функция хеширования;
3) FIPS Publication 180-3 Secure Hash Standard (SHS) или SM ISO/CEI 10118-3:2006 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions.”
[Пкт.33 подпкт.3) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
30. Проверка цифровой подписи осуществляется средствами цифровой подписи в соответствии с требованиями стандарта SMV CWA 14171:2007 General guidelines for electronic signature verification.
31. Формат цифровой подписи должен соответствовать требованиям стандарта PKCS#7 Cryptographic Message Syntax Standard или IETF RFC 5126 CMS Advanced Electronic Signatures (CAdES) и XML Advanced Electronic Signatures (XAdES).
[Пкт.31 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
32. Алгоритмы создания и проверки цифровой подписи должны соответствовать требованиям одного из следующих стандартов и рекомендаций:
1) SM ISO/CEI 9796-2:2006 Информационные технологии. Методы обеспечения безопасности. Схемы цифровой подписи, позволяющие восстанавливать сообщения. Часть 2: Механизмы, основанные на факторизации целого числа; SM ISO/CEI 9796-3:2006 Информационные технологии. Методы защиты. Схемы цифровой сигнатуры, позволяющие восстанавливать сообщения. Часть 3: Механизмы, основанные на дискретном логарифме;
2) SM ISO/CEI 14888-1:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 1: Общие положения; SM ISO/CEI 14888-2:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 2: Механизмы на основе идентификаторов; SM ISO/CEI 14888-3:2006 Информационные технологии. Методы защиты. Цифровые сигнатуры с приложением.
Часть 3: Механизмы на основе сертификатов;
3) SM GOST R 34.10:2006 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи;
4) IETF RFC 3447 Public-Key Cryptography Standards PKCS#1: RSA Cryptography Specifications, версия 2.1;
5) FIPS Publication 186-3 Digital Signature Standard (DSS) или SMV ISO/CEI 14888-2-2009 Information technology – Security techniques – Digital signatures with appendix – Part 2: Integer factorization based mechanisms.
[Пкт.32 подпкт.5) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
33. Алгоритмы функции хеширования должны соответствовать требованиям одного из следующих стандартов:
1) SM ISO/CEI 10118-1:2006 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 1: Общие положения; SM ISO/CEI 10118-2:2006 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 2: Хеш-функции с использованием алгоритма шифрования n-битными блоками; SM ISO/CEI 10118-3:2006 Технологии информационные. Методы обеспечения защиты. Хэш-функции. Часть 3: Выделенные хэш-функции; SM ISO/CEI 10118-4:2006 Информационная технология. Методы защиты. Хэш-функции. Часть 4: Хэш-функции, применяющие модульную арифметику;
2) SM GOST R 34.11:2006 Информационная технология. Криптографическая защита информации. Функция хеширования;
3) FIPS Publication 180-3 Secure Hash Standard (SHS) или SM ISO/CEI 10118-3:2006 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions.”
[Пкт.33 подпкт.3) в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
V. Фиксирование времени
34. Добавление метки времени осуществляется в соответствии с требованиями рекомендации IETF RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).
35. Синхронизация времени служб сертификации, в том числе программных и технических средств по предназначению, осуществляется в соответствии с рекомендацией IETF RFC 4330: Simple Network Time Protocol (SNTP) или IETF RFC 1305 :Network Time Protokol (NTP).
[Пкт.35 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
36. Структура сертификата открытого ключа службы метки времени (TSP) представлена в приложении №3 к настоящим Техническим нормам.
[Пкт.36 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
38. Структура сертификата службы подтверждения достоверности данных и протокола сервера сертификации (DVCS) представлена в приложении №3 к настоящим Техническим нормам.
[Глава VI введена ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
35. Синхронизация времени служб сертификации, в том числе программных и технических средств по предназначению, осуществляется в соответствии с рекомендацией IETF RFC 4330: Simple Network Time Protocol (SNTP) или IETF RFC 1305 :Network Time Protokol (NTP).
[Пкт.35 изменен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
36. Структура сертификата открытого ключа службы метки времени (TSP) представлена в приложении №3 к настоящим Техническим нормам.
[Пкт.36 введен ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
VI. Подтверждение достоверности данных
и протокол сервера сертификации
37. Подтверждение достоверности данных и протокола сервера сертификации осуществляется в соответствии с требованиями рекомендации IETF RFC 3029 Data Validation and Certification Server Protocols (DVCS).и протокол сервера сертификации
38. Структура сертификата службы подтверждения достоверности данных и протокола сервера сертификации (DVCS) представлена в приложении №3 к настоящим Техническим нормам.
[Глава VI введена ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
[Приложение 1 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
[Приложение 2 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]
[Приложение 4 в редакции ПСИБ32 от 23.06.2010, МО110-113/02.07.2010 ст.390]