CER (Canonical encoding rules) — несколько меньшие ограничения, чем в DER. Лучше бы сразу ознакомится со стандартом X.690 (основной современный стандарт ASN.1), там всё очень подробно расписано.
Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.
DER-кодировка описывается следующим правилом. Первым записывается байт, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и затем уже записываются сами данные.
Вот это вот в корне ошибочно.
На самом деле сам по себе стандарт ASN.1 содержит в себе как язык описания схем, так и правила кодирования. Правила кодирования действительно достаточно просты: все значения записываются в виде структур «TLV» (tag-length-value). Базовые требования к кодированию ASN.1 типов определяются в BER (Basic Encoding Rules). Именно эти правила являются основными для ASN.1. То что называется DER (Distinguished encoding rules) определяет не новые правила, а всего лишь накладывает ограничения на BER. Изначально DER был сделан из-за того, что с помощью BER один и тот же элемент данных мог быть закодирован различными способами. С помощью DER добавили ограничения и теперь каждый тип данных может быть закодироват одним способом В ограничения описываемые в DER входят:
1) Следует использовать явную форму кодирования длины структур данных;
2) Нельзя использовать конструктивную форму кодирования для типов BITSTRING, OCTETSTRING и для други строковых типов;
+ дополнительный набор правил-ограничений.
Так что DER — это не кодировка, а просто набор ограничений, наложенный на базовые правила кодирования (BER). Конечно я повсеместно вижу, как употребляют выражения вида «в DER-кодировке», и уже почти бросил обращать на это внимание, но все-таки заострю этот момент в данной статье.
Это первичный стандарт и он изначален. Однако все программные реализации опираются на RFC3280 (или RFC5280), так что этот первичный стардарт только вспомогателен. А ссылка полезна прежде всего тем, что есть русский перевод всего стандарта.
Насчет отпечатка в SHA-1: он действительно должен быть только в SHA-1. Сделано это только для того, чтобы все без исключения программы смогли однозначно идентифицировать данный сертификат. То есть например в Windows сертификаты находятся в так называемых «хранилищах сертификатов» и чтобы быстро найти нужный частно прибегают к поиску по хэшу сертификату, который и вычисляется только с помощью SHA-1. И так как этот отпечаток нужен исключительно только для различения сертификатов у локального пользователя то совершенно все равно скомпрометирован ли алгоритм SHA-1 или нет — это просто «отпечаток», простой уникальный номер сертификата.
Насчет различия самоподписанных и не самоподписанных сертификатов. По сути этих различий нет никаких. То есть также есть только три части сертификата (TBS, алгоритм подписи и сама подпись), отличается только на каком закрытом ключе выполнена подпись сертификата. В случае самоподписанного сертификата подпись выполнена на закрытом ключе соответствующему открытому ключу (который находится в TBS-части). В случае же не самоподписанного сертификата подпись выполнена на закрытом ключе «удостоверяющего центра», который как-бы удостоверивает, что этот публичный ключ (упомянутый в TBS-части) действительно соответствует данному лицу. Конечно различия самоподписанного и не самоподписанного сертификата на это не кончаются (например в самоподписанном сертификате поля «Issuer» и «Subject» в TBS-части совпадают, на в не самоподписанном — всегда различны), но более рассмотрение более детальных различий приведет к очень раздутому комментарию.
Также следует упомянуть, что автор рассматривает не первичный стандарт ITU-T X.509, а «производный» стандарт RFC5280. Кстати было бы здорово дополнить статью ссылкой на действительный стандарт X.509 (тем более что он уже полностью переведен на русский язык, как минимум для версии стандарта от 2005-го года): ITU-T X.509 (+ русский перевод).
Для лучшего понимания (всеми участниками) следует сказать, что аббревиатура «TBS» расшифровывается как «To Be Signed». То есть фактически сертификат состоит только из трех полей: части «to be signed», идентификатора алгоритма подписи и собственно самой подписи. Следует трактовать «TBS certificate» как некий набор элементов, который удостоверяются подписью этого сертификата. TBS могло бы быть просто куском данных, но для сертификата правильнее иметь в TBS части имена выдающей и принимающих сторон, а также дополнительные атрибуты сертификата.
Однако должен сказать, что Ваша статья IMHO достаточно странна. Либо она про X.509 сертификаты и тогда она очень поверхностна, либо она про некий пример ASN.1 структур на примере разбора X.509 сертификата. Но тогда для меня она тоже поверхностна.
В 2003 году я работая по договору найма (обычный трудовой договор, без указания цели договора или объекта заказа) создал в одиночку программный продукт. С тех пор этот продукт мною не поддерживается и был передан (путем обычного прекращения договора, без оформления каких бы то ни было бумаг) работодателю. Уже на протяжении около 10-ти лет продукт является весьма успешным в коммерческом плане. Никаких авторских отчисления я никогда не получал, в продукте нет никакого упоминания обо мне. Кроме того фирма-работодатель получила на него «свидетельство о регистрации программного продукта», где не указала автора. Конечно с тех пор продукт был делан-переделан другими людьми (я передал фирме исходный код продукта).
На что же с точки зрения этой статьи и с Вашей личной точки зрения я в настоящий момент имею право?
Посмотрел сейчас — в текущей линейке для России только один голос (для RealSpeak) и это «Милена». Как звучит эта женщина сейчас у меня нет возможности проверить :)
Слышал я эту «Катерину» когда разрабатывал IVR на Nuance SpeechServer… Единственный русский голос у Nuance, и на мой взгляд TTS в его исполнении слышится как будто 45-ти летнюю курящую женщину с большого бодуна попросили через силу чего-то там наговорить.
Так что рекомендую действительно поискать какие-то другие голоса генерации text-to-speech — меньше травмировать чуткие души бухгалтеров :)
Кстати ещё раз обращу внимание: моя программа позволяет осуществлять двунаправленные преобразования (в/из) для всех следующих форматов:
1) BER (DER, CER);
2) BER дополнительно закодированный BASE64;
3) Мой формат CompliXML;
То есть для «конвертации в мой формат» достаточно преобразовать с помощью моей программы стандартно кодированные BER данные.
Мой XML формат специфичен только для моей программы и приведен совместно с этим «complicance suite» только для показа варианта правильное реакции на декодирование тестовых BER файлов (tc*.ber). То есть первичны только бинарные файлы, мой XML формат служит только для описания возможной реакции. Если же говорить о проверке кодирования, то можно предложить вариант — с помощью тестируемого программного продукта декодировать тестовые бинарные файлы, сохранить полученный результат в любом формате, а потом закодировать этот вторичный результат повторно.
Насчет «отказался от XER» — этот формат тоже будет поддержан в моей программе. Насчет «почему отказался» — стандартный XER не содержит столь много детальной информации о каждом подблоке ASN.1, как мой формат. Кроме того в моём формате присутствует возможность генерации предупреждений и ошибок.
Предлагаемый набор тестов состоит из бинарных файлов (tc*.ber), представляющие из себя закодированные ASN.1 BER данные. Эти бинарные файлы передать проверяемому программному продукту. Например для проверки «декстопных» версий декодировщиков ASN.1 от OSS Nokalva или Objective Systems достаточно открыть эти файлы в программе декодирования.
Затем реакция декодера сопоставляется с ожидаемой реакцией (описана в файле «free_asn1_testsuite.pdf»). Если реакция не совпадает, то значит в проверяемом продукте имеются проблемы.
Вот это вот в корне ошибочно.
На самом деле сам по себе стандарт ASN.1 содержит в себе как язык описания схем, так и правила кодирования. Правила кодирования действительно достаточно просты: все значения записываются в виде структур «TLV» (tag-length-value). Базовые требования к кодированию ASN.1 типов определяются в BER (Basic Encoding Rules). Именно эти правила являются основными для ASN.1. То что называется DER (Distinguished encoding rules) определяет не новые правила, а всего лишь накладывает ограничения на BER. Изначально DER был сделан из-за того, что с помощью BER один и тот же элемент данных мог быть закодирован различными способами. С помощью DER добавили ограничения и теперь каждый тип данных может быть закодироват одним способом В ограничения описываемые в DER входят:
1) Следует использовать явную форму кодирования длины структур данных;
2) Нельзя использовать конструктивную форму кодирования для типов BITSTRING, OCTETSTRING и для други строковых типов;
+ дополнительный набор правил-ограничений.
Так что DER — это не кодировка, а просто набор ограничений, наложенный на базовые правила кодирования (BER). Конечно я повсеместно вижу, как употребляют выражения вида «в DER-кодировке», и уже почти бросил обращать на это внимание, но все-таки заострю этот момент в данной статье.
Насчет отпечатка в SHA-1: он действительно должен быть только в SHA-1. Сделано это только для того, чтобы все без исключения программы смогли однозначно идентифицировать данный сертификат. То есть например в Windows сертификаты находятся в так называемых «хранилищах сертификатов» и чтобы быстро найти нужный частно прибегают к поиску по хэшу сертификату, который и вычисляется только с помощью SHA-1. И так как этот отпечаток нужен исключительно только для различения сертификатов у локального пользователя то совершенно все равно скомпрометирован ли алгоритм SHA-1 или нет — это просто «отпечаток», простой уникальный номер сертификата.
Насчет различия самоподписанных и не самоподписанных сертификатов. По сути этих различий нет никаких. То есть также есть только три части сертификата (TBS, алгоритм подписи и сама подпись), отличается только на каком закрытом ключе выполнена подпись сертификата. В случае самоподписанного сертификата подпись выполнена на закрытом ключе соответствующему открытому ключу (который находится в TBS-части). В случае же не самоподписанного сертификата подпись выполнена на закрытом ключе «удостоверяющего центра», который как-бы удостоверивает, что этот публичный ключ (упомянутый в TBS-части) действительно соответствует данному лицу. Конечно различия самоподписанного и не самоподписанного сертификата на это не кончаются (например в самоподписанном сертификате поля «Issuer» и «Subject» в TBS-части совпадают, на в не самоподписанном — всегда различны), но более рассмотрение более детальных различий приведет к очень раздутому комментарию.
Также следует упомянуть, что автор рассматривает не первичный стандарт ITU-T X.509, а «производный» стандарт RFC5280. Кстати было бы здорово дополнить статью ссылкой на действительный стандарт X.509 (тем более что он уже полностью переведен на русский язык, как минимум для версии стандарта от 2005-го года): ITU-T X.509 (+ русский перевод).
Однако должен сказать, что Ваша статья IMHO достаточно странна. Либо она про X.509 сертификаты и тогда она очень поверхностна, либо она про некий пример ASN.1 структур на примере разбора X.509 сертификата. Но тогда для меня она тоже поверхностна.
Также вот тут собственно оригинал этой статьи на английском.
P.S.: Кстати в русском переводе отсутствует одна из картинок, а именно «Steps to perform Profile Guided Optimization».
В 2003 году я работая по договору найма (обычный трудовой договор, без указания цели договора или объекта заказа) создал в одиночку программный продукт. С тех пор этот продукт мною не поддерживается и был передан (путем обычного прекращения договора, без оформления каких бы то ни было бумаг) работодателю. Уже на протяжении около 10-ти лет продукт является весьма успешным в коммерческом плане. Никаких авторских отчисления я никогда не получал, в продукте нет никакого упоминания обо мне. Кроме того фирма-работодатель получила на него «свидетельство о регистрации программного продукта», где не указала автора. Конечно с тех пор продукт был делан-переделан другими людьми (я передал фирме исходный код продукта).
На что же с точки зрения этой статьи и с Вашей личной точки зрения я в настоящий момент имею право?
Так что рекомендую действительно поискать какие-то другие голоса генерации text-to-speech — меньше травмировать чуткие души бухгалтеров :)
Ссылки для скачивания остались прежними.
1) BER (DER, CER);
2) BER дополнительно закодированный BASE64;
3) Мой формат CompliXML;
То есть для «конвертации в мой формат» достаточно преобразовать с помощью моей программы стандартно кодированные BER данные.
Мой XML формат специфичен только для моей программы и приведен совместно с этим «complicance suite» только для показа варианта правильное реакции на декодирование тестовых BER файлов (tc*.ber). То есть первичны только бинарные файлы, мой XML формат служит только для описания возможной реакции. Если же говорить о проверке кодирования, то можно предложить вариант — с помощью тестируемого программного продукта декодировать тестовые бинарные файлы, сохранить полученный результат в любом формате, а потом закодировать этот вторичный результат повторно.
Насчет «отказался от XER» — этот формат тоже будет поддержан в моей программе. Насчет «почему отказался» — стандартный XER не содержит столь много детальной информации о каждом подблоке ASN.1, как мой формат. Кроме того в моём формате присутствует возможность генерации предупреждений и ошибок.
Затем реакция декодера сопоставляется с ожидаемой реакцией (описана в файле «free_asn1_testsuite.pdf»). Если реакция не совпадает, то значит в проверяемом продукте имеются проблемы.
Именно этот PDF и является начальное версией статьи, а текст на Хабре только специально адаптирован для ресурса.