The following pages contain documentation, example code, and ancillary files relating to IBM's SDKs. The documentation covers IBM-specific features of IBM's offerings. A platform-specific Security User Guide is included in each download. For information about the SDK for z/OS product and security components specific to that platform, see this Web site.
What's new for the IBM SDK and Runtime Environment, Java Technology Edition, Version 6
From Java 6 service refresh 10, the XML Digital Signature (DSig) provider is updated to support the NIST 800-131A recommendations by adding support for the following signatures as specified in XML DSig 1.1:
ECDSA signatures
SHA2 with DSA signatures
In addition, the default digest strength is raised to SHA2, where applicable, in accordance with NIST 800-131A guidelines.
When this specification is final, there will be a Reference Implementation which will demonstrate the capabilities of this API and will provide an operational definition of this specification. A Technology Compatibility Kit (TCK) will also be available that will verify whether an implementation of the specification is compliant. These are required as per the Java Community Process 2.1.
The JSR 105 API is intended to target the following two types of users:
Java programmers who want to use the JSR 105 API to generate and validate XML signatures.
Java programmers who want to create a concrete implementation of the JSR 105 API and register it as a cryptographic service of a JCA provider.
Acknowledgements
The JSR 105 Expert Group:
Nicolas Catania, Hewlett-Packard
Donald E. Eastlake 3rd, Motorola
Christian Geuer-Pollmann, Apache Software Foundation
Hans Granqvist, VeriSign
Kazuyuki Harada, Fujitsu
Anthony Ho, DSTC
Merlin Hughes, Baltimore Technologies
Joyce Leung, IBM
Gregor Karlinger, IAIK
Serge Mister, Entrust Technologies
Takuya Mori, NEC Corporation
Sean Mullan, Sun Microsystems
Anthony Nadalin, IBM (specification lead)
Erwin van der Koogh, Apache Software Foundation
Chris Yeung, XML Asia
Also, special thanks to: Valerie Peng, Vincent Ryan, Sharon Liu, Chok Poh, K. Venugopal Rao., Paul Rank, Alexey Gavrilov, Bill Situ, Eric Jendrock, Andrew Fan, Manveen Kaur, Tom Amiro, Michael Mi, Dmitri Silaev, Roman Makarchuk, Vanitha Venkatraman, Arkadiy Sutchilin, and Scott Fordin from Sun Microsystems, Vishal Mahajan from Apache, and Martin Centner from IAIK.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The API MUST allow a programmer to generate and validate XML Signatures such that all of the SHOULD and MUST requirements specified by the W3C recommendation can be satisfied.
The API MUST allow an implementation of the API to be created such that all of the SHOULD and MUST requirements specified by the W3C recommendation can be satisfied.
The API MUST NOT have dependencies on a specific XML representation, such as DOM. It MUST be possible to create implementations of the API for different XML processing and mechanism representations, such as DOM, JDOM or dom4j.
Extensible, provider-based API
It MUST be possible for a third-party to create and plug in an implementation responsible for managing and creating cryptographic and transform algorithms, dereferencing URIs, and marshalling objects to/from XML.
Support for a default XML mechanism type: DOM
An implementation MUST minimally support the default mechanism type: DOM. This ensures that all implementations of JSR 105 are guaranteed a minimal level of functionality. Implementations MAY support other mechanism types.
Interoperability for the default XML mechanism type: DOM
The API SHOULD ensure that applications using a DOM implementation are portable and interoperable.
J2SE requirements
Implementations of this technology MAY support J2SE 1.2 or later but MUST at a minimum support version 1.4 or later of J2SE.
W3C DOM Level 3 API. This dependency is required by classes of the javax.xml.crypto.dom and javax.xml.crypto.dsig.dom packages.
Non-Goals
Support for non-DOM implementations
While the API SHOULD allow non-DOM implementations to be created, it is beyond the scope of the first version to ensure interoperability between implementations other than DOM. Additional standard service provider types MAY be added in the future and necessary API enhancements MAY be considered for a maintenance revision of JSR 105.
Support for a higher-level API
We expect that programmers MAY design high-level APIs which will be built on the JSR 105 API to hide low-level details, address common use-cases or apply profiling constraints. However, it is beyond the scope of the first version to support these requirements. A high-level API MAY be considered for a maintenance release of JSR 105.
Support for user-pluggable algorithms (other than transform and canonicalization algorithms which is supported by the javax.xml.crypto.dsig.TransformService class)
Allowing developers to plug in their own implementations of XML Signature algorithms without requiring them to create a complete JSR 105 implementation seems like a worthy goal but SHALL NOT be REQUIRED for this release of JSR 105. A solution we are investigating for a subsequent release of Java SE is to enhance the underlying JCA/JCE to add better support for registering, parsing and processing XML security algorithms, parameters, and key information.
The javax.xml.crypto package contains common classes that are used to perform XML cryptographic operations, such as generating an XML signature or encrypting XML data. Two notable classes in this package are the KeySelector class, the purpose of which is to allow developers to supply implementations which locate and optionally validate keys using the information contained in a KeyInfo object, and the URIDereferencer class which allows developers to create and specify their own URI dereferencing implementations.
The javax.xml.crypto.dsig package includes interfaces that represent the core elements defined in the W3C XML digital signature specification. Of primary significance is the XMLSignature class, which allows you to sign and validate an XML digital signature. Most of the XML signature structures or elements are represented by a corresponding interface (except for the KeyInfo structures, which are included in their own package, and discussed in the next paragraph). These interfaces include: SignedInfo, CanonicalizationMethod, SignatureMethod, Reference, Transform, DigestMethod, XMLObject, Manifest, SignatureProperty, and SignatureProperties. The XMLSignatureFactory class is an abstract factory that is used to create objects that implement these interfaces.
The javax.xml.crypto.dsig.spec package contains interfaces and classes representing input parameters for the digest, signature, transform, or canonicalization algorithms used in the processing of XML signatures.
A JSR 105 cryptographic service is a concrete implementation of the abstract XMLSignatureFactory and KeyInfoFactory classes and is responsible for creating objects and algorithms that parse, generate and validate XML Signatures and KeyInfo structures. A concrete implementation of XMLSignatureFactory MUST provide support for each of the REQUIRED algorithms as specified by the W3C recommendation for XML Signatures. It MAY support other algorithms as defined by the W3C recommendation or other specifications.
JSR 105 leverages the JCA provider model for registering and loading XMLSignatureFactory and KeyInfoFactory implementations.
Each concrete XMLSignatureFactory and KeyInfoFactory implementation supports a specific XML mechanism type that identifies the XML processing mechanism that an implementation uses internally to parse and generate XML signature and KeyInfo structures. This JSR supports one standard type: DOM. Support for new standard types (such as JDOM) MAY be added in the future.
A JSR 105 implementation SHOULD use underlying JCE engine classes, such as java.security.Signature and java.security.MessageDigest, to perform cryptographic operations.
In addition to the XMLSignatureFactory and KeyInfoFactory classes, JSR 105 supports a service provider interface for transform and canonicalization algorithms. The TransformService class allows you to develop and plug in an implementation of a specific transform or canonicalization algorithm for a particular XML mechanism type. The TransformService class uses the standard JCA provider model for registering and loading implementations. Each JSR 105 implementation SHOULD use the TransformService class to find a provider that supports transform and canonicalization algorithms in XML Signatures that it is generating or validating.
DOM Mechanism Requirements
The following requirements MUST be abided by when implementing a DOM-based XMLSignatureFactory, KeyInfoFactory or TransformService, in order to minimize interoperability problems:
The unmarshalXMLSignature method of XMLSignatureFactory MUST support DOMValidateContext types. If the type is DOMValidateContext, it SHOULD contain an Element of type Signature. Additionally, the unmarshalXMLSignature method MAY populate the Id/Element mappings of the passed-in DOMValidateContext.
The implementation MUST support DOMStructures as the mechanism for the application to specify extensible content (any elements or mixed content).
If the dereference method of user-specified URIDereferencers returns NodeSetData objects, the iterator method MUST return an iteration over objects of type org.w3c.dom.Node.
URIReference objects passed to the dereference method of user-specified URIDereferencers MUST be of type DOMURIReference and XMLCryptoContext objects MUST implement DOMCryptoContext.
The previous 2 requirements also apply to URIDereferencers returned by the getURIDereferencer method of XMLSignatureFactory and KeyInfoFactory.
The unmarshalKeyInfo method of KeyInfoFactory MUST support DOMStructure types. If the type is DOMStructure, it SHOULD contain an Element of type KeyInfo.
The unmarshalXMLSignature method of XMLSignatureFactory MUST support DOMStructure types. If the type is DOMStructure, it SHOULD contain an Element of type Signature.
Note: A DOM implementation MAY internally use other XML parsing APIs other than DOM as long as it doesn't affect interoperability. For example, a DOM implementation of XMLSignatureFactory might use a SAX parser internally to canonicalize data.
Open API Issues
The following is a list of open API issues.
ID attribute registration of external XML document references is not supported.
Dereferencing the external document results in an octet stream which is subsequently converted to a NodeSet by the JSR 105 implementation. But the API does not provide a mechanism for registering ID attributes of external documents and therefore the XPath Transform implementation may be unable to identify the "foo" ID.
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation North Castle Drive, Armonk NY 10504-1758 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the information. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this information at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
JIMMAIL@uk.ibm.com [Hursley Java Technology Center (JTC) contact]
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
Trademarks
IBM is a trademark or registered trademark of International Business Machines Corporation in the United States, or other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
From Java 6 service refresh 10, the XML Digital Signature (DSig) provider is updated to support the NIST 800-131A recommendations by adding support for the following signatures as specified in 
XML DSig 1.1
