- From: merlin <merlin@baltimore.ie>
- Date: Tue, 13 Mar 2001 16:42:40 +0000
- To: w3c-ietf-xmldsig@w3.org
- Cc: "Joseph M. Reagle Jr." <reagle@w3.org>, Brian LaMacchia <bal@microsoft.com>, Hans Granqvist <hgranqvist@verisign.com>
- Message-Id: <20010313164241.0AC0244397@yog-sothoth.ie.baltimore.com>
Hi Joseph/Brian/Hans, I attach two gzipped tarchives containing some sample signatures based (hopefully) on the current editor's draft of the spec: http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html Relevant namespaces are: <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> <!ENTITY c14n "http://www.w3.org/TR/2000/CR-xml-c14n-20001026"> <!ENTITY xpath "http://www.w3.org/TR/1999/REC-xpath-19991116"> <!ENTITY xslt "http://www.w3.org/TR/1999/REC-xslt-19991116"> The first archive contains a few separate signatures that exercise different basic things (enveloped/enveloping/detached/base 64, DSA, RSA, HMAC, truncated HMAC); in each case, intermediate C14N is included. The second archive contains a more vomitous signature that exercises local references of the form "", "#foo", "#xpointer(/)", "#xpointer(id('foo'))", with and without comments, local and external base 64 decoding, manifests, signature properties, XSL and XPath transforms including use of the here() function for an effective enveloped-reference transform. Again, all the intermediate C14N is included. As always, these aren't tested beyond the resolution of my eyeball. All feedback welcome. Merlin r/reagle@w3.org/2001.03.08/16:53:00 >Hans, > >Our testing has been relatively informal. There's been some peer exchanges, >as well as tar balls of examples sent to the list that others run through >their implementation. This is what we've been doing for the purposes of our >interoperability report [1] -- which will need to be updated once we move >Canonical XML to REC because the URI for its algorithm will change. So I'd >recommend trying the tar ball reference in [1], and if everything goes >smoothly, feel free to create your own with more exotic/boundary examples. > >[1] http://www.w3.org/Signature/2000/10/17-xmldsig-interop.html > >At 11:32 3/8/2001 -0800, Hans Granqvist wrote: >>Is there any ongoing efforts among DSig implementers to >>participate in interoperability tests? We have a full DSig >>implementation and we'd like to see how it stacks up. (If >>you want to try our toolkit, email me for a URL to download >>it.) >> >>I searched both the archives of this list, and the W3C member >>pages, and found nothing mentioning interop (except an IETF >>meeting in Pittsburgh, Pennsylvania, June/July, 2000). >> >>If there is no interop going on, I'd propose we start one. >>Any ideas how to do it 'properly'? >> >>Thanks, >>/Hans >>-- >>Hans Granqvist, Verisign XML Web Services, +1 650 429-5369, GMT-8 >> >>PS. Can the QA workshop [1] (which mentions conformance testing) >>and its members be part of this? >> >>[1] http://www.w3.org/2001/01/qa-ws/ > > >__ >Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature >W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com
Attachments
- application/octet-stream attachment: merlin-xmldsig-twelve.tar.gz
- application/octet-stream attachment: merlin-xmldsig-thirteen.tar.gz
Received on Tuesday, 13 March 2001 11:43:39 UTC