ГОСТ Р ИСО/МЭК 26300—2010/Раздел 17

ГОСТ Р ИСО/МЭК 26300—2010 «Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v1.0» — Раздел 17


17 Пакеты

править

В этом разделе описан формат пакета, который может быть необязательно использован в OpenDocument. Он содержит следующие подразделы:

  • введение;
  • структура zip-файла;
  • шифрование;
  • изображение предварительного просмотра;
  • файл декларации.

17.1 Введение

править

Поскольку XML не имеет никакой собственной поддержки двоичных объектов типа изображений, [OLE]-объектов, или других медиа-типов, а также несжатые XML-файлы могут стать очень большими, OpenDocument использует пакетный файл, чтобы хранить содержимое XML-документа вместе со своими связанными двоичными данными, и произвольно сжимает содержимое XML. Пакет — это стандартный zip-файл, структура которого рассмотрена ниже.

Информация о файлах, содержащихся в пакете, сохраняется в XML-файле, называемом файлом декларации. Файл декларации всегда сохраняется в каталоге META-INF с именем файла META-INF/manifest.xml. В декларации записываются следующие основные информационные части:

  • список всех файлов в пакете;
  • медиа-тип каждого файла в пакете;
  • если файл, сохраненный в пакете, зашифрован, в декларации сохраняется информация, необходимая для его расшифровки.

17.2 Структура zip-файла

править

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

В приведенном формате каждый файл в архиве располагается последовательно и сопровождается центральным каталогом в конце zip-архива. Центральный каталог — это непрерывное множество элементов каталога, каждый из которых содержит всю информацию в локальном заголовке файла, плюс дополнения, типа комментариев и атрибутов файла. Очень важно, что центральный каталог содержит указатели на позицию каждого файла в архиве, которые делают навигацию по zip-файлу быстрой и простой.

Для получения более подробной информации о формате zip-файла см. [ZIP].

17.3 Шифрование

править

Процесс шифрования состоит из нескольких стадий.

  • Создание 20-байтового SHA1 результирующего дайджеста пароля, введенного пользователем, и его передача компоненту пакета.
  • Компонент пакета инициализирует генератор случайных чисел с текущим временем.
  • Генератор случайных чисел используется, чтобы генерировать случайный 8-байтовый вектор инициализации и 16-байтовый шум для каждого файла.
  • Шум используется вместе с 20-байтовым SHA1 результирующим дайджестом пароля для получения уникального для каждого файла 128-битного ключа. Алгоритмом получения ключа является алгоритм PBKDF2, использующий HMAC-SHA-1 (см. [RFC2898]) с количеством итераций, равным 1024.
  • Полученный ключ используется вместе с вектором инициализации для шифрования файла, с использованием алгоритма Blowfish в режиме CFB (cipher-feedback).

Каждый зашифрованный файл сжимается перед шифрованием. Для разрешения проверки содержимого файла пакета необходимо, чтобы зашифрованные файлы были помечены как 'STORED', а не 'DEFLATED'. Так как элементы, помеченные как 'STORED', должны иметь размер, равный сжатому размеру, необходимо хранить их несжатый размер в декларации. Сжатый размер сохраняется как в локальном заголовке файла, так и в записи центрального каталога zip-файла.

17.4 Поток типа MIME

править

Если для документа, который использует пакеты, существует тип MIME, то в пакете следует размещать поток, названный «mimetype». Этот поток следует размещать первым потоком zip-файла пакета, он не должен быть сжатым и не должен использовать дополнительную область в своем заголовке (см. [ZIP]).

Цель состоит в том, чтобы позволить упакованным файлам быть идентифицированными через механизм «магических чисел», похожий на Unix-утилиту file/magic. Если zip-файл в начале содержит поток, который распакован, и не имеет никаких дополнительных данных в заголовке, то имя потока и его содержимое можно найти в фиксированных позициях. Более подробно:

  • строка 'PK' в нулевой позиции всех zip-файлов;
  • строка 'mimetype' в 30-ой позиции всех таких файлов пакета;
  • тип MIME непосредственно в 38-й позиции такого пакета.

17.5 Использование унифицированных идентификаторов ресурса (IRI) в пакетах

править

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

Для IRI, которые используются в пределах пакета, существуют следующие ограничения:

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

Ссылка относительного пути (как описано в § 6.5 [RFC3987]), которая встречается в файле из пакета, должна быть разрешена точно так же, как если бы целый пакет был бы разархивирован в каталог с текущим местоположением. Чтобы получить (разархивированный) файл, который содержит ссылку относительного пути, должны использоваться базовые IRI для разрешения ссылок относительного пути.

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

17.6 Изображение предварительного просмотра

править

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

Эскиз должен быть сохранен как «thumbnail.png» в отдельной папке по имени «Thumbnails».

Папка «Thumbnails» не должна получить медиа-тип в файле manifest.xml, так как она, фактически, не является частью документа.

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

Чтобы соответствовать стандарту управления эскизами (TMS) на www.freedesktop.org, эскизы должны быть сохранены как 24-битное построчное изображение PNG с полной альфа-прозрачностью. Необходимый для эскизов размер — 128x128 пикселей.

17.7 Файл декларации

править

Элементы и атрибуты в файле декларации находятся в пространстве имен: urn:oasis:names:tc:opendocument:xmlns:manifest:1.0.

17.7.1 Схема Relax-NG

править

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

Язык схемы, используемый в пределах этой спецификации, — Relax-NG (см. [RNG]).

Префикс для нормативной схемы Relax-NG декларации:

<?xml version="1.0" encoding="UTF-8"?>
<!--
    OASIS OpenDocument v1.0 (Second Edition)
    Спецификация комитета №1, 19 Jul 2006
    Relax-NG Manifest Schema

    $Id$

    © 2002-2005 OASIS Open
    © 1999-2005 Sun Microsystems, Inc.
-->

<grammar
    xmlns="http://relaxng.org/ns/structure/1.0"
    
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
    
    xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0">

17.7.2 Корневой элемент декларации

править

Корневой элемент называют декларацией (manifest). Корневой элемент содержит фиксированный атрибут, который определяет пространство имен, как описано выше, и множественные <manifest:file-entry> элементы, каждый из которых описывает один файл в пакете.

<define name="manifest">
    <element name="manifest:manifest">
        <oneOrMore>
            <ref name="file-entry"/>
        </oneOrMore>
    </element>
</define>

<start>
    <choice>
        <ref name="manifest"/>
    </choice>
</start>

17.7.3 Включение файла

править

Элемент <manifest:file-entry> представляет один файл, хранит в пакете его местоположение, тип MIME и необязательные данные, требуемые для расшифровки этого файла.

Каталоги получают свои <manifest:file-entry> включения, только если они имеют наследуемую семантику. Например, каталог, представляющий поддокумент, на который ссылаются как на объект из основного документа, содержал бы <manifest:file-entry> с подходящим медиа-типом. Каталог для целей администрирования или целей удобства, типа каталога, который содержит различные загрузочные модули, не получил бы включение в файле декларации.

<define name="file-entry">
    <element name="manifest:file-entry">
        <ref name="file-entry-attlist"/>
        <optional>
            <ref name="encryption-data"/>
        </optional>
    </element>
</define>

С элементом <manifest:file-entry> связаны следующие атрибуты:

  • полный путь;
  • размер;
  • медиа-тип.
Полный путь
править

Атрибут manifest:full-path описывает местоположение файла внутри пакета.

<define name="file-entry-attlist" combine="interleave">
    <attribute name="manifest:full-path">
        <data type="string"/>
    </attribute>
</define>
Размер
править

Атрибут manifest:size присутствует, только если файл сохранен в шифрованном формате. Причина, из-за которой требуется этот атрибут, объясняется в разделе 17.3. Этот атрибут используется только для зашифрованных файлов.

<define name="file-entry-attlist" combine="interleave">
    <optional>
        <attribute name="manifest:size">
            <data type="nonNegativeInteger"/>
        </attribute>
    </optional>
</define>
Медиа-тип
править

Атрибут manifest:media-type указывает тип MIME определяемого файла. Для ознакомления с полным списком типов MIME см. http://www.isi.edu/in-notes/iana/assignments/media-types/media-types. Как пример, все потоки XML имеют медиа-тип «text/xml».

    <define name="file-entry-attlist" combine="interleave">
        <attribute name="manifest:media-type">
            <data type="string"/>
        </attribute>
    </define>

17.7.4 Данные шифрования

править

Элемент <manifest:encryption-data> содержит полную информацию, необходимую для расшифровки файла.

<define name="encryption-data">
    <element name="manifest:encryption-data">
        <ref name="encryption-data-attlist"/>
        <ref name="algorithm"/>
        <ref name="key-derivation"/>
    </element>
</define>

Элемент <encryption-data> содержит в себе следующие элементы:

  • алгоритм;
  • источник ключа.
Тип контрольной суммы
править

Атрибут manifest:checksum-type определяет название алгоритма формирования дайджеста и может быть использован для проверки пароля. На текущий момент поддерживается только алгоритм SHA1 формирования дайджеста.

<define name="encryption-data-attlist" combine="interleave">
    <attribute name="manifest:checksum-type">
        <data type="string"/>
    </attribute>
</define>
Контрольная сумма
править

Атрибут manifest:checksum определяет BASE64-кодированный дайджест (определенный в [RFC2045]), который может использоваться, чтобы проверить правильность пароля способом, описанным в атрибуте manifest:checksum-type.

<define name="encryption-data-attlist" combine="interleave">
    <attribute name="manifest:checksum">
        <data type="base64Binary"/>
    </attribute>
</define>

17.7.5 Алгоритм

править

Элемент <manifest:algorithm> содержит информацию об алгоритме, который используется для шифрования данных.

<define name="algorithm">
    <element name="manifest:algorithm">
        <ref name="algorithm-attlist"/>
        <empty/>
    </element>
</define>

С <manifest:algorithm> связаны следующие атрибуты:

  • название алгоритма;
  • вектор инициализации.
Название алгоритма
править

Атрибут manifest:algorithm-name определяет название алгоритма, который используется для шифрования файла, он также определяет, каким способом используется данный алгоритм. На текущий момент поддерживается только алгоритм Blowfish в режиме обратной связи шифра CFB.

<define name="algorithm-attlist" combine="interleave">
    <attribute name="manifest:algorithm-name">
        <data type="string"/>
    </attribute>
</define>
Вектор инициализации
править

Атрибут manifest:initialisation-vector определяет 8 байт, использующихся как вектор инициализации для шифра потока. Вектор инициализации — это 8-байтовая двоичная последовательность, закодированная в тип BASE64 (определенный в [RFC2045]) в момент записи в файл декларации.

<define name="algorithm-attlist" combine="interleave">
    <attribute name="manifest:initialisation-vector">
        <data type="base64Binary"/>
    </attribute>
</define>

17.7.6 Источник ключа

править

Элемент <manifest:key-derivation> содержит информацию, которая была использована для формирования ключа шифра файла из пароля, заданного пользователем.

<define name="key-derivation">
    <element name="manifest:key-derivation">
        <ref name="key-derivation-attlist"/>
        <empty/>
    </element>
</define>

С элементом <manifest:key-derivation> связаны следующие атрибуты:

  • название источника ключа;
  • шум;
  • количество итераций.
Название источника ключа
править

Атрибут manifest:key-derivation-name определяет название алгоритма, который был использован для получения источника ключа. В настоящее время пакеты поддерживают использование только метода PBKDF2 получения ключа. Для получения более подробной информации см. [RFC2898].

<define name="key-derivation-attlist" combine="interleave">
    <attribute name="manifest:key-derivation-name">
        <data type="string"/>
    </attribute>
</define>

Атрибут manifest:salt определяет 16-байтовую последовательность, которая используется как «шум» (salt) алгоритмом получения ключа. Шум — это 16-байтовая двоичная последовательность, кодированная в BASE64 (определенный в [RFC2045]) до записи в файл декларации.

<define name="key-derivation-attlist" combine="interleave">
    <attribute name="manifest:salt">
        <data type="base64Binary"/>
    </attribute>
</define>
Количество итераций
править

Атрибут manifest:iteration-count определяет количество итераций, использующихся алгоритмом получения ключа.

<define name="key-derivation-attlist" combine="interleave">
    <attribute name="manifest:iteration-count">
        <data type="nonNegativeInteger"/>
    </attribute>
</define>

Пример декларации:

<manifest:manifest
    xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0">
    <manifest:file-entry
        manifest:media-type="application/vnd.oasis.opendocument.text"
        manifest:full-path="/"/>
    <manifest:file-entry manifest:media-type="image/jpeg"
        manifest:full-path="Pictures/100000000000032000000258912EB1C3.jpg"
         manifest:size="66704">
        <manifest:encryption-data>
            <manifest:algorithm manifest:algorithm-name="Blowfish CFB"
                manifest:initialisation-vector="T+miu403484="/>
            <manifest:key-derivation manifest:key-derivation-name="PBKDF2"
                manifest:iteration-count="1024"
                manifest:salt="aNYdmqv4cObAJSJjm4RzqA=="/>
        </manifest:encryption-data>
    </manifest:file-entry>
    <manifest:file-entry
        manifest:media-type="text/xml" manifest:full-path="content.xml"
        manifest:size="3143">
        <manifest:encryption-data>
            <manifest:algorithm manifest:algorithm-name="Blowfish CFB"
                manifest:initialisation-vector="T+miu403484="/>
            <manifest:key-derivation manifest:key-derivation-name="PBKDF2"
                manifest:iteration-count="1024"
                manifest:salt="aNYdmqv4cObAJSJjm4RzqA=="/>
        </manifest:encryption-data>
    </manifest:file-entry>
    <manifest:file-entry manifest:media-type="text/xml"
        manifest:full-path="styles.xml" manifest:size="5159">
        <manifest:encryption-data>
            <manifest:algorithm manifest:algorithm-name="Blowfish CFB"
                manifest:initialisation-vector="bChL2No5I+A="/>
            <manifest:key-derivation manifest:key-derivation-name="PBKDF2"
                manifest:iteration-count="1024"
                manifest:salt="/kfasyu7X0Ae+1uopdeCtA=="/>
        </manifest:encryption-data>
    </manifest:file-entry>
    <manifest:file-entry
        manifest:media-type="text/xml" manifest:full-path="meta.xml"/>
    <manifest:file-entry manifest:media-type="text/xml"
        manifest:full-path="settings.xml" manifest:size="5317">
        <manifest:encryption-data>
            <manifest:algorithm manifest:algorithm-name="Blowfish CFB"
                manifest:initialisation-vector="JQxEm6rD+4c="/>
            <manifest:key-derivation manifest:key-derivation-name="PBKDF2"
                manifest:iteration-count="1024"
                manifest:salt="PlpDaxloh4KUKx+v1g4V9g=="/>
        </manifest:encryption-data>
    </manifest:file-entry>
</manifest:manifest>

17.7.7 Суффикс схемы Relax-NG

править

Суффикс для нормативной схемы декларации Relax-NG:

</grammar>


Это произведение не охраняется авторским правом.
В соответствии со статьёй 1259 Гражданского кодекса Российской Федерации не являются объектами авторских прав официальные документы государственных органов и органов местного самоуправления муниципальных образований, в том числе законы, другие нормативные акты, судебные решения, иные материалы законодательного, административного и судебного характера, официальные документы международных организаций, а также их официальные переводы; государственные символы и знаки (флаги, гербы, ордена, денежные знаки и тому подобное), а также символы и знаки муниципальных образований; произведения народного творчества (фольклор), не имеющие конкретных авторов; сообщения о событиях и фактах, имеющие исключительно информационный характер (сообщения о новостях дня, программы телепередач, расписания движения транспортных средств и тому подобное).
Россия