To:
ietf-provreg@cafax.se
From:
Andrew Newton <anewton@ecotroph.net>
Date:
Mon, 06 May 2002 15:42:52 -0400
Reply-To:
anewton@ecotroph.net
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: XML Digital Signatures for EPP.
This bounced from the list and I didn't catch it... so here it is again. > On Thu, 2002-04-18 at 12:06, Hollenbeck, Scott wrote: > > I don't think canonicalization (c14n) is really an issue since it's a > > just a process that describes how to produce a consistent representation > > of a well-formed instance. Looking at the spec [1] right now I don't > > see any real issues. > > My rather shallow understanding of this is that as the XML instance > pases from one parser to another, things that get signed as: > > <a> > <b/> > </a> > > can get easily transformed into: > > <a><b/></a> > > causing the signature to become invalid because the content has indeed > been changed. Again, my rather shallow understanding of the issue. > > I do know of one other standards body creating an XML protocol that ran > head-long into this topic and found that c14n wasn't good enough. > > > On the other hand, you're probably right about trying to provide > > integrity, authentication, and non-repudiation services at some other > > layer. The XML DSIG specs allow multiple transforms (such as c14n and > > perhaps compression) to be applied prior to signing, but XML signatures > > add a lot of "wrapper" that add to bandwidth and processing horsepower > > requirements. > > Interesting about the multiple transforms. It would seem that you could > just drop in ZIP or something, but I have been told otherwise. I'll > have to go pound on my source for a reason why it wouldn't work. > > -andy > >
S/MIME Cryptographic Signature