что такое кодировка der
Разбираем x.509 сертификат
Привет, %username%!
Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.
Часть 1. Самоподписанный сертификат
В результате выполнения данной процедуры будет создан стандартный x.509 сертификат, который, будучи открытым с помощью hex-редактора, выглядит вот таким чудесным образом:
Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:
Имея два этих файла, один с двоичными данными, а другой с описанием сертификата, попробуем разобраться что здесь к чему.
Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.
ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia
Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.
DER-кодировка описывается следующим правилом. Первым записывается байт, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и затем уже записываются сами данные.
К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 02 03 01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.
В нашем случае, для описание простейшего самоподписаного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:
| Наименование типа | Краткое описание | Представление типа в DER-кодировке |
|---|---|---|
| SEQUENCE | Используется для описания структуры данных, состоящей из различных типов. | 30 |
| INTEGER | Целое число. | 02 |
| OBJECT IDENTIFIER | Последовательность целых чисел. | 06 |
| UTCTime | Временной тип, содержит 2 цифры для определения года | 17 |
| GeneralizedTime | Расширенный временной тип, содержит 4 цифры для обозначения года. | 18 |
| SET | Описывает структуру данных разных типов. | 31 |
| UTF8String | Описывает строковые данные. | 0C |
| NULL | Собственно NULL | 05 |
| BIT STRING | Тип для хранения последовательности бит. | 03 |
Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.
30 82 01 8F 30 81 F9 A0 03 02 01 02 02 01 01 30
0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 0D
31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 20 17
0D 31 33 30 39 31 35 31 35 33 35 30 32 5A 18 0F
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A 30
0D 31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 81
9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00
03 81 8D 00 30 81 89 02 81 81 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A 54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52 02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18 A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66 53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92 25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1 AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59 64 77 5F 02 03 01 00 01
30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03
81 81 00 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18
1B 72 1C
Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:
Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.509 подписывается определенная часть сертификата, называемая TBS-сертификат (to be signed). В TSB-сертификат входит последовательность SEQUENCE второго уровня со всеми вложенными данными.
Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.
Еще одно замечание относится к отпечатку сертификата. Как видите сам сертификат не содержит никаких сведений об отпечатке. Это объясняется тем, что отпечаток представляет собой обычное хеш-значение SHA-1 от всего файла сертификата, со всеми его полями, включая подпись издателя. Поэтому хранить отпечаток не обязательно, можно просто вычислять хеш при каждом просмотре сертификата.
Часть 2. Сертификат 2-го уровня
Мы с вами рассмотрели внутренности самоподписанного сертификата, и нам осталось понять чем отличается структура сертификатов более низкого уровня, от сертификата корневого центра.
Для этого, с помощью имеющегося у нас секретного ключа сертификата CA, создадим подчиненный ему сертификат user. И в этом нам снова поможет Bouncy Castle.
Распарсив наш сертификат и преобразовав его к читаемому виду, получим следующую красоту:
Как видите, единственное отличие от самоподписанного сертификата заключается в наличие дополнительного блока:
который содержит сведения об издателе сертификата и его открытом ключе. Вот тут я хотел бы добавить одно замечание. Без этого блока сертификат все равно будет оставаться рабочим, т.к. информация хранящаяся здесь считается не более, чем дополнением, более точно указывающим каким из ключей издателя был подписан текущий сертификат. Рассмотрим каждый элемент блока отдельно.
Заключение
Тех усидчивых людей, которые продрались сквозь все эти ASN.1 выражения и шестнадцатеричные наборы данных, я хотел бы поблагодарить за прочтение. Надеюсь вам было хоть немного интересно. И стало чуточку понятнее, что же такое на самом деле X.509 сертификат.
DER-шифрованный файл X.509
DER (Distinguished Encoding Rules) для ASN.1, как определено в рекомендации ITU-T Recommendation X.509, — более ограниченный стандарт кодирования, чем альтернативный BER (Basic Encoding Rules) для ASN.1, определенный в рекомендации ITU-T Recommendation X.209, на котором основан DER. И BER, и DER обеспечивают независимый от платформы метод кодирования объектов, таких как сертификаты и сообщения, для трансмиссии между устройствами и приложениями.
При кодировании сертификата большинство приложений используют стандарт DER, т. к. сертификат (сведения о запросе сертификата) должен быть закодирован с помощью DER и подписан.
Base64-шифрованный формат X.509
Этот метод кодирования создан для работы с протоколом S/MIME, который популярен при передаче двоичных файлов через Интернет. Base64 кодирует файлы в текстовый формат ASCII, при этом файлы повреждаются каждый раз при прохождении через шлюз, в то время как S/MIME обладает некоторыми криптографическими службами безопасности для элекронных приложений сообщений, включая целостность происходения и использование цифровых подписей, секретность и безопаспость данных при помощи кодирования, процесса проверки подлинности и невозможности отрицания авторства сообщений.
MIME (Multipurpose Internet Mail Extensions) спецификации (RFC 1341 and successors) определяет механизмы кодирования произвольных двоичных данных для передачи по электронной почте.
Стандарт X.690: BER, CER и DER
X.690 — один из стандартов ASN.1, разработанных совместно организациями ISO, IEC и ITU-T для удобства представления данных при их передаче в телекоммуникационных сетях. Правила кодирования, описанные в X.690, служат для представления структур данных, описанных по правилам ASN.1, в виде последовательностей байт. Такие последовательности удобнее передавать по линиям связи или сохранять в файлы, чем делать те же операции с самими структурами.
Правила кодирования, описанные в X.690 применяют в различных протоколах передачи данных и в криптографических протоколах, как-то: SMNP и LDAP, PKCS#7 (для кодирования сообщений), X.509 (для хранения сертификатов). В частности, в стандарте CMS (RFC #5652) говорится, что сообщение должно передаваться закодированным по правилам DER (описаны в X.690). Однако единой кроссплатформенной реализации правил кодирования на каждом из языков программирования, описанных в стандарте X.690, нет. Поэтому разработчикам ПО часто приходится реализовывать библиотеки для кодирования данных в соответствии с X.690. И тут возникает следующая проблема: очень сложно найти хорошее и понятное описание стандарта и правил кодирования на русском языке.
Собственно, задача этой статьи — дать именно такое описание.
Стандарт X.690 описывает следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Разберемся с этими правилами подробнее.
Basic Encoding Rules
Базовые правила кодирования или BER — правила для представления структуры, описанной с помощью ASN.1, в виде последовательности байт (или «октетов»). Такую последовательность удобнее передавать по линиям связи или сохранять в файл, чем делать те же операции с самими структурами.
Для того, чтобы различные типы данных можно было описывать схожим образом, в X.690 была определена общая структура блока закодированной информации, состоящая из следующих 3 частей:
Рассмотрим подробнее эти части:
Формат идентификатора строго фиксирован:
Биты 8 и 7 определяют класс данных (Universal (т.е. определенный в ASN.1), Application (Используемый в каком-то конкретном приложении), Context-specific (т.е. зависящий от контекста)* или Private (т.е. определенный в какой-то спецификации ASN.1));
Бит 6 определяет, является ли данные простыми (как-то INTEGER), или могут содержать в себе другие различные наборы данных (как-то SET). При этом в первом случае говорят о примитивном кодировании, а во втором — о конструктивном.
Биты 5-1 определяют тэг данных (их тип).
В случае если класс данных не определен в ASN.1, то тэг может быть больше 30. В таком случае используют несколько октетов для представления идентификатора. При этом биты 5-1 первого октета имеют значение 11111(2), а следующие октеты, кодируются следующим образом:
Бит 8 во всех октетах, кроме последнего равен 1. В последнем октете длины бит 8 равен 0;
Биты с 1 по 7 этих октетов содержат биты тэга в его двоичном представлении.
Октеты длины закодированных данных:
В случае, если длина блока закодированных данных заранее известна, октеты длины кодируются следующим образом:
Если эта длина не превышает 31 байта, то она просто записывается в соответствующий октет длины. Такая форма представления октетов длины называется примитивной (primitive).
Если длина блока закодированных данных больше 31 байта, то:
Такая форма представления октетов длины называется длинной (long)
Если же длина блока закодированных данных на момент кодирования длины неизвестна, то в октет длины записывается значение 0×80h, что указывает на кодирование с неопределенной длиной. В этом случае в конце блока закодированных данных должно стоять значение 0×0000h (2 октета), явно указывающее на его завершение.
Кодирование структур различных типов:
Кодирование различных типов данных детально и доступно описано в стандарте X.690 и затруднений при использовании вызывать не должно. Куда больший интерес вызывают особенности при кодировании различных типов данных.
В зависимости от структуры и преследуемых при кодировании целей, кодирование одних и тех же данных может существенно различаться. Так, кодирование значения TRUE типа BOOLEAN может иметь как вид: 01 01 01, так и вид: 01 01 0F;
Результат кодирования типа SET может быть различным в зависимости от того, в каком порядке мы кодируем «вложенные» типы данных: если set ::= SET < int, float>; int ::= INTEGER; float ::= REAL, то для set <-128, 0.15625>результат кодирования может быть таким: 31 08 02 01 80 09 03 80 FB 05, и таким: 31 08 09 03 80 FB 05 02 01 80.
В зависимости от того, примитивное или конструктивное кодирование используется, его результат может также различаться. Так для значения » Test User 1″ типа STRING при примитивном кодировании результат будет иметь вид: 13 0B 54 65 73 74 20 55 73 65 72 20 31, а при конструктивном: 33 0F 13 05 54 65 73 74 20 13 06 55 73 65 72 20 31.
Другие правила кодирования стандарта X.690:
Как видно из предыдущих примеров, результат кодирования по правилам BER может существенно различаться. Для того, чтобы результаты кодирования одних и тех же типов данных в разных системах были одинаковыми, были разработаны правила кодирования DER и CER.
Distinguished Encoding Rules:
Особые правила кодирования или DER совпадают с BER с учетом выполнения следующих ограничений:
1) для кодирования данных с известной длиной количество октетов длины должно быть наименьшим;
2) Кодирование простых типов данных (в том числе STRING, OCTET STRING и BIT ARRAY) всегда примитивное;
3) для типа SET кодирование вложенных типов должно происходить в порядке следования их тегов (согласно ASN.1).
Canonical Encoding Rules:
Канонические правила кодирования или CER совпадают с BER с учетом выполнения следующих ограничений:
1) для составных типов данных должно применяться кодирование с неизвестной длиной;
для примитивного кодирования количество октетов длины должно быть наименьшим;
2) для типа SET кодирование вложенных типов должно происходить в порядке следования их тегов (согласно ASN.1).
Сравнение BER, DER и CER:
В чем же преимущество различных правил кодирования?
BER предлагает пользователю различные пути для кодирования одних и тех же данных, причем предполагается, что система, которая поддерживает стандарты ASN.1, может корректно их декодировать вне зависимости от представления, в то время как DER и CER поддерживают только конкретный вариант кодирования для каждого типа. Это отличие проявляется в быстродействии кодирования данных: согласно исследованиям, если при кодировании используется строго определенный формат данных, то системе требуется для кодирования и декодирования намного меньше операций. Проще говоря, DER и CER обеспечивают много большее быстродействие, чем BER.
Основное же отличие DER от CER заключается в том, что в DER используется кодирование данных с известной длиной, а в CER в некоторых случаях (например, при кодировании данных типа STRING длиной более 1000 символов) используется кодирование с неизвестной заранее длиной. Это отличие выражается в количестве блоков, необходимых для кодирования длины зашифрованных данных. Так, для определения длины блока закодированных данных при кодировании с неизвестной длиной требуется всего 3 октета, в то время как для больших сообщений при DER кодировании их количество может достигать 32 октетов. То есть целесообразно использовать DER при кодировании небольших по размеру данных и CER — для больших.
Автор: Красавин А. А.
Дата публикации: 01.01.2013
Библиографическая ссылка: Красавин А. А. Стандарт X.690: BER, CER и DER // Комплексная защита информации. Электроника инфо. Материалы XVIII Международной конференции 21–24 мая 2013 года, Брест (Республика Беларусь). 2013. С. 132–133.
СОДЕРЖАНИЕ
Кодирование BER
Формат для базовых правил кодирования определяет самоописывающий и саморазграничивающий формат для кодирования структур данных ASN.1. Каждый элемент данных кодируется как идентификатор типа, описание длины, фактические элементы данных и, при необходимости, маркер конца содержимого. Эти типы кодирования обычно называются кодированием типа длина-значение или TLV-кодированием. Этот формат позволяет получателю декодировать информацию ASN.1 из неполного потока, не требуя каких-либо предварительных знаний о размере, содержании или семантическом значении данных.
Структура кодирования
Кодирование данных обычно состоит из четырех компонентов, которые появляются в следующем порядке:
| Октеты идентификатора Тип | Длина октеты Длина | Содержание октетов Значение | Октеты конца содержимого |
Октеты конца содержимого являются необязательными и используются только в том случае, если используется форма неопределенной длины. Октет содержимого также может быть опущен, если нет содержимого для кодирования, как в типе NULL.
Октеты идентификатора
Данные (особенно элементы последовательностей, наборов и вариантов выбора) могут быть помечены уникальным номером тега (показанным в ASN.1 в квадратных скобках []), чтобы отличать эти данные от других элементов. Такие теги могут быть неявными (где они кодируются как тег TLV значения вместо использования базового типа в качестве тега TLV) или явными (когда тег используется в построенном TLV, который охватывает TLV базового типа). Стиль тегов по умолчанию является явным, если неявный не установлен на уровне модуля ASN.1. Такие теги имеют класс по умолчанию, зависящий от контекста, но его можно переопределить, используя имя класса перед тегом.
Кодировка значения выбора такая же, как кодировка значения выбранного типа. Кодировка может быть примитивной или построенной, в зависимости от выбранного типа. Тег, используемый в октетах идентификатора, является тегом выбранного типа, как указано в определении выбранного типа ASN.1.
Следующие теги являются родными для ASN.1:
| Имя | Разрешенное строительство | Номер тега | |
|---|---|---|---|
| Десятичный | Шестнадцатеричный | ||
| Конец содержания (EOC) | Примитивный | 0 | 0 |
| BOOLEAN | Примитивный | 1 | 1 |
| ЦЕЛОЕ | Примитивный | 2 | 2 |
| BIT STRING | Оба | 3 | 3 |
| ОКТЕТНАЯ СТРОКА | Оба | 4 | 4 |
| НОЛЬ | Примитивный | 5 | 5 |
| ИДЕНТИФИКАТОР ОБЪЕКТА | Примитивный | 6 | 6 |
| Дескриптор объекта | Оба | 7 | 7 |
| ВНЕШНИЙ | Построено | 8 | 8 |
| НАСТОЯЩИЙ (плавающий) | Примитивный | 9 | 9 |
| ПЕРЕЧИСЛЕННЫЕ | Примитивный | 10 | А |
| ВСТРОЕННЫЙ PDV | Построено | 11 | B |
| UTF8String | Оба | 12 | C |
| ОТНОСИТЕЛЬНЫЙ-OID | Примитивный | 13 | D |
| ВРЕМЯ | Примитивный | 14 | E |
| Зарезервированный | 15 | F | |
| ПОСЛЕДОВАТЕЛЬНОСТЬ И ПОСЛЕДОВАТЕЛЬНОСТЬ | Построено | 16 | 10 |
| НАБОР и НАБОР | Построено | 17 | 11 |
| NumericString | Оба | 18 | 12 |
| PrintableString | Оба | 19 | 13 |
| T61String | Оба | 20 | 14 |
| VideotexString | Оба | 21 год | 15 |
| IA5String | Оба | 22 | 16 |
| UTCTime | Оба | 23 | 17 |
| GeneralizedTime | Оба | 24 | 18 |
| GraphicString | Оба | 25 | 19 |
| VisibleString | Оба | 26 | 1А |
| GeneralString | Оба | 27 | 1B |
| UniversalString | Оба | 28 год | 1С |
| СТРОКА ХАРАКТЕРА | Построено | 29 | 1D |
| BMPString | Оба | 30 | 1E |
| ДАТА | Примитивный | 31 год | 1F |
| ВРЕМЯ ДНЯ | Примитивный | 32 | 20 |
| ДАТА-ВРЕМЯ | Примитивный | 33 | 21 год |
| ПРОДОЛЖИТЕЛЬНОСТЬ | Примитивный | 34 | 22 |
| OID-IRI | Примитивный | 35 год | 23 |
| ОТНОСИТЕЛЬНЫЙ-OID-IRI | Примитивный | 36 | 24 |
Список назначений тегов универсального класса можно найти в Рек. МСЭ-Т X.680, раздел 8, таблица 1.
Кодирование
Октеты идентификатора кодируют тип элемента как тег ASN.1, состоящий из класса и числа, а также того, представляют ли октеты содержимого сконструированное или примитивное значение. Обратите внимание, что некоторые типы могут иметь значения как с примитивными, так и с построенными кодировками. Он кодируется как 1 или несколько октетов.
| Октет 1 | Октет 2 и далее | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Класс тега | ПК | Номер тега (0–30) | N / A | ||||||||||||
| 31 год | Более | Номер тега | |||||||||||||
В начальном октете бит 6 кодирует, является ли тип примитивным или составным, биты 7–8 кодируют класс типа, а биты 1–5 кодируют номер тега. Возможны следующие значения:
| Класс | Значение | Описание |
|---|---|---|
| Универсальный | 0 | Тип является родным для ASN.1 |
| Заявление | 1 | Тип действителен только для одного конкретного приложения. |
| Зависит от контекста | 2 | Значение этого типа зависит от контекста (например, в последовательности, наборе или выборе) |
| Частный | 3 | Определяется в частных спецификациях |
| ПК | Значение | Описание |
|---|---|---|
| Примитивный (P) | 0 | Октеты содержимого непосредственно кодируют значение элемента. |
| Построен (C) | 1 | Октеты содержимого содержат 0, 1 или более кодировок элементов. |
Длинная форма
Если номер тега слишком велик для 5-битного поля тега, его необходимо закодировать в следующих октетах.
Начальный октет кодирует класс и примитив / построенный, как и раньше, а биты 1–5 равны 1. Номер тега кодируется в следующих октетах, где бит 8 каждого равен 1, если октетов больше, а биты 1–7 кодируют номер тега. Комбинированные биты номера тега с прямым порядком байтов кодируют номер тега. Должно быть закодировано наименьшее количество следующих октетов; то есть биты 1–7 не должны быть 0 в первом последующем октете.
Октеты длины
Существует две формы октетов длины: определенная форма и неопределенная форма.
| Форма | Биты | |||||||
|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| Определенный, короткий | 0 | Длина (0–127) | ||||||
| Неопределенный | 1 | 0 | ||||||
| Определенный, длинный | 1 | Количество следующих октетов (1–126) | ||||||
| Зарезервированный | 1 | 127 | ||||||
Определенная форма
Он кодирует количество октетов содержимого и всегда используется, если тип является примитивным или сконструированным и данные доступны немедленно. Есть короткая форма и длинная форма, которые могут кодировать различные диапазоны длин. Числовые данные кодируются как целые числа без знака, причем младший бит всегда идет первым (справа).
| Октет 1 | Октет 2 | Октет 3 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| Длинная форма | 2 октета длины | 435 октетов содержимого | |||||||||||||||||||||
Неопределенная форма
Это вообще не кодирует длину, но октеты содержимого заканчиваются октетами маркера. Это применимо к сконструированным типам и обычно используется, если контент не доступен сразу во время кодирования.
Он состоит из одного октета, в котором бит 8 равен 1, а биты 1–7 равны 0. Затем 2 октета конца содержимого должны завершать октеты содержимого.
Октеты содержания
Октеты содержимого кодируют значение данных элемента.
Обратите внимание, что октетов содержимого может не быть (следовательно, длина элемента равна 0), если необходимо отметить только существование объекта ASN.1 или его пустоту. Например, это случай значения NULL ASN.1.
Кодирование CER
Кодировка DER
Наиболее существенными ограничениями кодирования DER являются:
Сравнение BER, CER и DER
Ключевое различие между форматом BER и форматами CER или DER заключается в гибкости, обеспечиваемой базовыми правилами кодирования. BER, как объяснено выше, является базовым набором правил кодирования, заданным ITU-T X.690 для передачи структур данных ASN.1. Это дает отправителям четкие правила кодирования структур данных, которые они хотят отправить, но также оставляет отправителям некоторые варианты кодирования. Как указано в стандарте X.690, «Альтернативные кодировки разрешены основными правилами кодирования в качестве опции отправителя. Получатели, заявляющие о соответствии основным правилам кодирования, должны поддерживать все альтернативы».
Получатель должен быть готов принять все законные кодировки, чтобы законно заявить о соответствии BER. Напротив, и CER, и DER ограничивают доступные спецификации длины одним параметром. Таким образом, CER и DER являются ограниченными формами BER и служат для устранения неоднозначности стандарта BER.
Чтобы облегчить выбор между правилами кодирования, документ стандартов X.690 предоставляет следующие рекомендации:
Выделенные правила кодирования более подходят, чем канонические правила кодирования, если закодированное значение достаточно мало, чтобы поместиться в доступной памяти, и есть необходимость быстро пропустить некоторые вложенные значения. Канонические правила кодирования более подходят, чем выделенные правила кодирования, если необходимо кодировать значения, которые настолько велики, что они не могут легко поместиться в доступную память, или если необходимо кодировать и передавать часть значения перед всем значением. доступен. Основные правила кодирования более подходят, чем канонические или выделенные правила кодирования, если кодирование содержит заданное значение или набор значений и нет необходимости в ограничениях, которые накладывают канонические и выделенные правила кодирования.
Критика кодирования BER
Применение
Несмотря на кажущиеся проблемы, BER является популярным форматом для передачи данных, особенно в системах с различными собственными кодировками данных.
Смотрите также
Рекомендации
Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.