This document is the interop report for new features introduced in XML Signature 1.1. It includes the test cases and test results for these new features. It does not replicate interop testing performed for features retained from XML Signature 1.0.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the XML Security Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to email@example.com (subscribe, archives). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document summarizes interop tests and the test results for new features introduced in XML Signature 1.1 [XMLDSIG-CORE1]. Changes to XML Signature introduced in XML Signature 1.1 are summarized in a detailed change explanation document [XMLDSIG-CORE1-CHGS].
Tests that are marked 'Y' are completed, 'U' means 'untested' and should not be taken to make a statement about the implementation (as testing may simply not have been performed for interop due to timing or other reasons).
Various combinations of the following
Microsoft's test vectors - 48 files
Oracle's test vectors - 18 files
See test file directory.
|ECDSA (P256/P384/P521] with||SHA-1||Excl C14N||ECKeyValue||Y||Y|
|ECDSA (P256/P384/P521] with||SHA-256||Excl C14N||ECKeyValue||Y||Y|
|ECDSA (P256/P384/P521] with||SHA-384||Excl C14N||ECKeyValue||Y||Y|
|ECDSA (P256/P384/P521] with||SHA-512||Excl C14N||ECKeyValue||Y||Y|
The following are the SHA-224 tests:
|Signature Algorithm||Digest||Oracle||Apache Santuario (C++)|
|ECDSA (P256/P384/P521] with||SHA-224||Y||Y|
HMAC-SHA512to recommended (from optional).
SHA-1but allow it for compatibility
SHA-1use is DISCOURAGED (but support is still required).
SHA-1to state that use is DISCOURAGED (but still required).
HMAC-SHA1to state that use is DISCOURAGED
DSAwithSHA1is only required as Signature algorithm for Signature verification, but is optional for Signature generation. Previously it was required for both.
Various combinations of the following
Sun's test vectors - 18 files
Oracle's test vectors - 9 files (same as sun's, C14n 1.0 only)
Microsoft's test vectors - 14 files
|Digest||Signature||Oracle||Apache Santuario (C++)|
dsig11:X509Digestto list of elements that may be included, to support reference via base64-encoded digest of a certificate
X509Digest was added to correct issues
DEREncodedKeyValueKeyInfo child element
DEREncodedKeyValue- new representation for public keys
KeyInfoReference- alternative to
RetrievalMethodaccess to a
KeyInfoelement that does not require use of a
DEREncodedKeyValue with ECKey:
DEREncodedKeyValue with RSAKey:
|Item||Apache Santuario (C++)||OpenSAML (Shibboleth)||Oracle|
Note: Same author for both Apache Santuario (C++) and OpenSAML
(Shibboleth) implementations. In OpenSaml reproduced the
material by consuming the same keypair and successfully processing the
KeyInfoReference after copying it into a SAML document.
Verify that signature is deemed invalid
HMacOutputLength truncation length is below the
larger of (a) half the underlying hash algorithm's output length,
and (b) 80 bits. Test that error generated for SHA-256 with
truncation length is less than 128, e.g. 100 bits [RFC4868].
The following are test vectors for
The first one is truncated to 40 bytes, so it should be rejected. The second one is not truncated at all, so it should be accepted.
|Oracle||Apache Santuario (C++)|
|Truncated 40 (invalid)||Y||Y|
|Truncated 160 (valid)||Y||Y|
The following algorithms were added or changed in XML Signature 1.1 but were not included in this round of interop testing as they have been previously tested during the development of the corresponding W3C Recommendations: