спецификации, руководства, описания, API

XML Java Спецификация API Цифровой подписи (JSR 105)

Введение

Этот документ описывает XML Java Спецификация API Цифровой подписи (JSR 105). Цель этого JSR состоит в том, чтобы определить стандартный API Java для генерирования и проверки допустимости XML-подписей.

Когда эта спецификация будет заключительной, будет Ссылочная Реализация, которая будет демонстрировать возможности этого API и обеспечит операционное определение этой спецификации. Технологический Набор Совместимости (TCK) также будет доступен, который проверит, совместима ли реализация спецификации. Они требуются согласно Процессу Сообщества Java 2.1.

JSR 105 API предназначается, чтобы предназначаться для следующих двух типов пользователей:

Программисты Java, которые хотят использовать JSR 105 API, чтобы генерировать и проверить XML-подписей.
Программисты Java, которые хотят создать конкретную реализацию JSR 105 API и зарегистрировать это как криптографическую службу провайдера JCA.

Подтверждения

JSR 105 Экспертных групп:

Николас Кэйтания, Hewlett-Packard
3-ий Дональд Э. Истлэйк, Motorola
Кристиан Геюр-Поллман, Основа программного обеспечения Apache
Ганс Грэнквист, VeriSign
Kazuyuki Harada, Fujitsu
Энтони Хо, DSTC
Мерлин Хьюз, Baltimore Technologies
Джойс Леунг, IBM
Грегор Карлингер, IAIK
Сшейте Господина, Entrust Technologies
Takuya Mori, NEC Corporation
Шон Муллан, Sun Microsystems (вывод cо-спецификации)
Энтони Надалин, IBM (вывод cо-спецификации)
Эрвин ван дер Куг, Основа программного обеспечения Apache
Крис Еунг, XML Азия

Кроме того, особая благодарность к: Валери Пенг, Винсент Райан, Шарон Луи, Chok Poh, K Венугопэла Рао., Пол Рэнк, Алексей Гаврилов, Билл Ситу, Эрик Джендрок, Эндрю Фэн, Manveen Kaur, Том Амиро, Майкл Ми, Дмитрий Силаев, Роман Макарчук, Vanitha Venkatraman, Аркадий Сучилин, и Скотт Фордин от Sun Microsystems, Vishal Mahajan от Apache, и Мартина Сентнера от IAIK.

Требования

Ключевые слова "ДОЛЖНЫ", "не ДОЛЖЕН", "ТРЕБУЕМЫЙ", "БЫТЬ", "НЕ БУДУ", "ДОЛЖЕН", "не ДОЛЖЕН", "РЕКОМЕНДУЕМЫЙ", "МОЖЕТ", и "ДОПОЛНИТЕЛЬНЫЙ" в этом документе должны быть интерпретированы как описано в RFC 2119.

Рекомендация W3C, Синтаксис XML-подписи и Обработка.
- API ДОЛЖЕН позволить программисту генерировать и проверять XML-подписей так, что весь ДОЛЖНЫЙ, и ДОЛЖНЫ могут быть удовлетворены, требования, определенные рекомендацией W3C.
- API ДОЛЖЕН позволить реализации API создаваться так, что весь ДОЛЖНЫЙ, и ДОЛЖНЫ могут быть удовлетворены, требования, определенные рекомендацией W3C.
Реализация ДОЛЖНА поддерживать Рекомендацию W3C, XML-подпись, которую Фильтр XPath Преобразовывает 2.0.
Реализация ДОЛЖНА поддерживать Рекомендацию W3C, Монопольную Версию 1.0 Канонизации XML.
DOM-независимый API. У API не ДОЛЖНО быть зависимостей от определенного представления XML, таких как ДОМ. ДОЛЖНО быть возможно создать реализации API для различной обработки XML и представлений механизма, таких как ДОМ, JDOM или dom4j.
Расширяемый, основанный на провайдере API. Для стороннего ДОЛЖНО быть возможно создать и включить реализацию, ответственную за управление и создание криптографического и преобразовать алгоритмы, разыменовывая URI, и упорядочивая объекты к/от XML.
Поддержка типа механизма XML по умолчанию: ДОМ. Реализация ДОЛЖНА минимально поддерживать тип механизма по умолчанию: ДОМ. Это гарантирует, что всем реализациям JSR 105 гарантируют минимальный уровень функциональности. Реализации МОГУТ поддерживать другие типы механизма.
Функциональная совместимость для типа механизма XML по умолчанию: ДОМ. API ДОЛЖЕН гарантировать, что приложения, используя реализацию ДОМА являются переносимыми и взаимодействующими.
Требования J2SE. Реализации этой технологии МОГУТ поддерживать J2SE 1.2 или позже но ДОЛЖЕН в минимальной версии 1.4 поддержки или позже J2SE.

Зависимости от API

J2SE (JDK) 1.2 или выше
W3C ДОМ Левель 2 API. Эта зависимость требуется классами javax.xml.crypto.dom и javax.xml.crypto.dsig.dom пакеты.

Нецели

Поддержка non-DOM реализаций. В то время как API ДОЛЖЕН позволить non-DOM реализациям создаваться, он выходит за рамки первой версии, чтобы гарантировать функциональную совместимость между реализациями кроме ДОМА. Дополнительные стандартные типы поставщика услуг МОГУТ быть добавлены в будущих и необходимых улучшениях API, МОЖЕТ быть рассмотрен для версии обслуживания JSR 105.
Поддержка высокоуровневого API. Мы ожидаем, что программисты МОГУТ разработать высокоуровневые API, которые будут основаны на JSR на 105 API, чтобы скрыть низкоуровневые детали, адресовать общие примеры использования или применить ограничения профилирования. Однако, это выходит за рамки первой версии, чтобы поддерживать эти требования. Высокоуровневый API МОЖНО рассмотреть для корректировочной версии JSR 105.
Поддержка сменных пользователем алгоритмов (кроме преобразования и алгоритмов канонизации, который поддерживается javax.xml.crypto.dsig. Класс TransformService): Разрешение разработчикам включить их собственные реализации алгоритмов XML-подписи, не требуя, чтобы они создали полный JSR, 105 реализаций походят на достойную цель, но не должны ТРЕБОВАТЬСЯ для этого выпуска JSR 105. Решение мы исследуем для последующего выпуска Java SE, состоит в том, чтобы улучшить базовый JCA/JCE, чтобы добавить лучшую поддержку регистрации, анализируя и обрабатывая алгоритмы безопасности XML, параметры, и ключевую информацию.

Краткий обзор пакета

JSR 105 API состоит из 6 пакетов:

javax.xml.crypto пакет содержит общие классы, которые используются, чтобы выполнить XML криптографические операции, такие как генерирование XML-подписи или шифрование данных XML. Два известных класса в этом пакете являются классом KeySelector, цель которого состоит в том, чтобы позволить разработчикам предоставлять реализации, которые определяют местоположение и дополнительно проверяют ключей, используя информацию, содержавшуюся в a KeyInfo объект, и класс URIDereferencer, который позволяет разработчикам создавать и определять свои собственные реализации разыменования URI.

javax.xml.crypto.dsig пакет включает интерфейсы, которые представляют базовые элементы, определенные в спецификации цифровой подписи XML W3C. Из основного значения класс XMLSignature, который позволяет Вам подписывать и проверять цифровой подписи XML. Большинство структур XML-подписи или элементов представляются соответствующим интерфейсом (за исключением KeyInfo структуры, которые включаются в их собственный пакет, и обсуждаются в следующем абзаце). Эти интерфейсы включают: SignedInfo, CanonicalizationMethod, SignatureMethod, Ссылка, Преобразовывают, DigestMethod, XMLObject, Декларация, SignatureProperty, и SignatureProperties. Класс XMLSignatureFactory является абстрактной фабрикой, которая используется, чтобы создать объекты, которые реализуют эти интерфейсы.

javax.xml.crypto.dsig.keyinfo пакет содержит интерфейсы, которые представляют большинство KeyInfo структуры, определенные в рекомендации цифровой подписи XML W3C, включая KeyInfo, KeyName, KeyValue, X509Data, X509IssuerSerial, RetrievalMethod, и PGPData. Класс KeyInfoFactory является абстрактной фабрикой, которая используется, чтобы создать объекты, которые реализуют эти интерфейсы.

javax.xml.crypto.dsig.spec пакет содержит интерфейсы, и классы, представляющие входные параметры для обзора, подписи, преобразовывают, или алгоритмы канонизации, используемые в обработке XML-подписей.

Наконец, javax.xml.crypto.dom и javax.xml.crypto.dsig.dom пакеты содержат DOM-специфичные классы для javax.xml.crypto и javax.xml.crypto.dsig пакетов, соответственно. Только разработчики и пользователи, которые создают или используют DOM-на-основе реализацию XMLSignatureFactory или KeyInfoFactory, должны должны быть сделать прямое использование этих пакетов.

Поставщики услуг

JSR 105 криптографических служб являются конкретной реализацией абстрактных классов XMLSignatureFactory и KeyInfoFactory и ответственны за создание объектов и алгоритмов, которые анализируют, генерируют и проверяют структуры KeyInfo и XML-подписи. Конкретная реализация XMLSignatureFactory ДОЛЖЕН оказать поддержку для каждого из НЕОБХОДИМЫХ алгоритмов как определено рекомендацией W3C для XML-подписей. Это МОЖЕТ поддерживать другие алгоритмы как определено рекомендацией W3C или другие спецификации.

JSR 105 рычагов модель провайдера JCA для регистрации и загрузки XMLSignatureFactory и KeyInfoFactory реализации.

Каждый бетон XMLSignatureFactory или KeyInfoFactory реализация поддерживает определенный тип механизма XML, который идентифицирует XML, обрабатывающий механизм, который реализация использует внутренне, чтобы проанализировать и генерировать структуры KeyInfo и XML-подпись. Этот JSR поддерживает один стандартный тип: ДОМ. Поддержка новых стандартных типов (таких как JDOM) МОЖЕТ быть добавлена в будущем.

JSR 105 реализаций ДОЛЖЕН использовать базовые классы механизма JCA, такие как java.security. Подпись и java.security. MessageDigest, чтобы выполнить криптографические операции.

В дополнение к XMLSignatureFactory и KeyInfoFactory классы, JSR 105 поддерживает интерфейс поставщика услуг для алгоритмов канонизации и преобразования. Класс TransformService позволяет Вам разрабатывать и включать реализацию определенного преобразования или алгоритма канонизации для определенного типа механизма XML. TransformService класс использует стандартную модель провайдера JCA для регистрации и загрузки реализаций. Каждый JSR 105 реализаций ДОЛЖЕН использовать TransformService класс, чтобы найти провайдера, который поддерживает, преобразовывает и алгоритмы канонизации в XML-подписи, которые он генерирует или проверяет.

Требования ДОМА Мечанисма

Следующие требования ДОЛЖНЫ соблюдаться, реализовывая DOM-на-основе XMLSignatureFactory, KeyInfoFactory или TransformService чтобы минимизировать проблемы функциональной совместимости:

unmarshalXMLSignature метод XMLSignatureFactory ДОЛЖЕН поддерживать типы DOMValidateContext. Если тип DOMValidateContext, это ДОЛЖНО содержать Элемент типа Signature. Дополнительно, unmarshalXMLSignature метод MAY заполняет отображения Идентификатора/Элемента переданного - в DOMValidateContext.
Метод знака XMLSignatures, произведенного XMLSignatureFactory ДОЛЖЕН поддерживать типы DOMSignContext, и проверить метод MUST поддерживают типы DOMValidateContext. Это требование также применяется к проверить методу SignatureValue и проверить методу Ссылки.
Реализация ДОЛЖНА поддерживать DOMStructures как механизм для приложения, чтобы определить расширяемый контент (любые элементы или смешанный контент).
Если разыменовать метод определенного пользователем URIDereferencers возвращает объекты NodeSetData, iterator возврат метода MUST итерация по объектам типа org.w3c.dom.Node.
URIReference объекты, которые передают к dereference метод определенных пользователем URIDereferencers ДОЛЖЕН иметь тип DOMURIReference и XMLCryptoContext объекты ДОЛЖНЫ реализовать DOMCryptoContext.
Предыдущие 2 требования также применяются к URIDereferencers возвращенный getURIDereferencer метод XMLSignatureFactory и KeyInfoFactory.
unmarshalKeyInfo метод KeyInfoFactory ДОЛЖЕН поддерживать типы DOMStructure. Если тип DOMStructure, это ДОЛЖНО содержать Элемент типа KeyInfo.
Метод преобразования Transform ДОЛЖЕН поддерживать типы параметра контекста DOMCryptoContext.
newtransform и newCanonicalizationMethod методы XMLSignatureFactory ДОЛЖЕН поддерживать типы параметра DOMStructure.
init, и marshalParams методы TransformService ДОЛЖЕН поддерживать типы DOMCryptoContext и DOMStructure.
unmarshalXMLSignature метод XMLSignatureFactory ДОЛЖЕН поддерживать типы DOMStructure. Если тип DOMStructure, это ДОЛЖНО содержать Элемент типа Signature.
Упорядочивать метод KeyInfo ДОЛЖЕН поддерживать DOMStructure и типы параметра DOMCryptoContext.

Отметьте, что реализация ДОМА МОЖЕТ внутренне использовать другой XML, анализирующий API кроме ДОМА, пока это не влияет на функциональную совместимость. Например, реализация ДОМА XMLSignatureFactory мог бы использовать синтаксический анализатор SAX внутренне, чтобы канонизировать данные.

Открытые Проблемы API

Следующее является списком открытых проблем API.

Регистрация атрибута ID внешних ссылок XML-документа не поддерживается.
Рассмотрите следующую ссылку:
```
  <Reference URI="document.xml">
    <Transforms>
      <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <XPath>id("foo")</XPath>
      </Transform>
    </Transforms>
  </Reference>
      
```
Разыменование внешнего документа приводит к потоку октета, который впоследствии преобразовывается в NodeSet JSR 105 реализаций. Но API не обеспечивает механизм для того, чтобы он зарегистрировал атрибуты ID внешних документов, и поэтому XPath Преобразовывает реализацию, может быть неспособно идентифицировать "foo" ID.

Программирование Примеров

Примеры 1-3 ниже демонстрируют, как генерировать различные типы простого XML Цифровая подпись, используя JSR 105 API. Пример 1 описывает, как генерировать отсоединенную подпись, используя алгоритм подписи DSA. Пример 2 описывает, как генерировать окутанную подпись. Пример 3 decribes, как генерировать подпись окутывания . Пример 4 описывает, как проверить XML-подписи.

Свяжитесь с Нами

XML Java Спецификация API Цифровой подписи (JSR 105)

Оглавление

Краткий обзор пакета