[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


Home | Date list | Subject list