- 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