MEMO Donald Eastlake 3rd Motorola July 2001 XMLDSIG Interoperability Report ------- ---------------- ------ Table of Contents Table of Contents..........................................1 1. Introduction............................................2 2. Orgnaizations Interoperating:...........................2 3. Interoperability Results................................3 3.1 Canonicalization.......................................3 3.2 Digest/Signature/MAC Algorithms........................3 3.3 Features Related to Location of Signed Data............4 3.4 Keying Information.....................................4 3.5 Transforms.............................................4 3.6 Manifest Element.......................................4 3.7 Miscellaneous..........................................5 Summary....................................................6 Author's Address...........................................6 D. Eastlake 3rd [Page 1] MEMO XMLDSIG Interoperability Report July 2001 1. Introduction XML Digital Signature (XMLDSIG) is a Proposed Standard as specified in [RFC 3075] produced by the joint IETF/W3C XMLDSIG working group. In addition, Canonical XML, which is normatively referenced by XMLDSIG, has been standardized by the W3C and is documented in Informational [RFC 3076]. It is the consensus of the working group that the XMLDSIG standard should be advanced to the IETF Draft Standard level. This memo supports that advancement by documenting interoperability of the XMLDSIG features and options except for Minimal Canonicalization which is to be dropped. The internet-draft to be advanced is draft- ietf-xmldsig-core2-00.txt (soon to be -01). It also has numerous clarifications and improvements in documentation over the current RFC. 2. Orgnaizations Interoperating: The following organizations, in alphabetic order, have independently produced interoperable implementations of XMLDSIG: Baltimore: Baltimore Technologies see Done: Done Information, Inc. Phone: +358 9-5259 240 see DSTC: Distributed Systems Technology Centre see Fujitsu: Fujitsu IAIK: Institute for Applied Information Processing and Communications at Technical University of Graz, Austria. Phone: (+43) (316) 873-5540 see IBM: IBM see D. Eastlake 3rd [Page 2] MEMO XMLDSIG Interoperability Report July 2001 Microsoft: Microsoft NEC: NEC RSA: RSA Security Inc. 3. Interoperability Results This section is primarily a restatement in text form of the interoperability matrix at . Note that this represents just a snapshot of the status of these implementations and they may have advanced significantly. 3.1 Canonicalization Interoperable for the W3C standard Canonical XML (required) and Canonical XML with Comments (recommended) show for all implementations by producing identical results from various inputs. (See also earlier canoncialization testing results at using the examples from the Canonical XML specification showing interoperability between at least Baltimore and IBM for all features and options.) Support for Minimal Canonicalization (recommended in the Proposed Standard) had been shown by NONE of the organizationad and will be DROPPED. 3.2 Digest/Signature/MAC Algorithms Interoperable support of the generation and validation of digests and signature/MAC values using SHA1 (required), DSAwithSHA1 (DSS, required), RSAwithSHA1 (recommended), and HMAC-SHA1 (required) shown by all implementations based on a variety of test cases. D. Eastlake 3rd [Page 3] MEMO XMLDSIG Interoperability Report July 2001 3.3 Features Related to Location of Signed Data Interoperability tests included detached, enveloping, and enveloped signatures. This includes same document references (URI="") with the enveloped signature transform and same document references with fragment (URI="#object1"). Also tested were same document and fragment XPointer ( #xpointer(/) and #xpointer(id("ID")) ). These are required features except for XPointer, which is recommended, and all implementations supported them except that the Fujitsu and RSA implementations did not support XPointer. 3.4 Keying Information The required KeyValue element was interoperably supported by all implementations. The recommended RetrievalMethod element was interoperably supported by Baltimore, IBM, NEC, and RSA. 3.5 Transforms Interoperable support of the three Transform algorithms and the recommended extension to one algorithm, as specified in the standard, are as follows: XSLT (optional): Baltimore, IBM, Microsoft, NEC XPath (recommended): Baltimore, Fujitsu, IAIK, IBM, Microsoft, NEC, RSA here() function (an addition to XPath) (recommended): Baltimore, IAIK, IBM, NEC, RSA Enveloped Signature Transform (required): All organizations (see also 3.3 above). 3.6 Manifest Element Baltimore, Done, Fujitsu, IAIK, IBM, NEC, and RSA interoperably support digest generation and validation for this optional element. D. Eastlake 3rd [Page 4] MEMO XMLDSIG Interoperability Report July 2001 3.7 Miscellaneous All implementations interoperably supported base64 encoding. All implementations interoperably supported laxly schema valid Signature element generation. D. Eastlake 3rd [Page 5] MEMO XMLDSIG Interoperability Report July 2001 Summary All defined features and options are supported by multiple independent interoperable implementation except for Minimal Canonicalization which has been dropped from the internet-draft which is the candidate for Draft Standard. Author's Address Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA Telephone: +1-508-634-2066 (h) +1-508-261-5434 (w) FAX: +1-508-261-4447 (w) EMail: Donald.Eastlake@motorola.com D. Eastlake 3rd [Page 6]