[CAP] Then Again... (was Re: CAP Security UsingDigitalSignatures)

[Russo CTR Brian T]

I think not performing C14n would be a mistake because then you open
yourself up to a whole mess of bugs and interoperability issues involving
text encoding.. whitespace.. etc.. Not all of which would accurately be
characterized as bugs since many would involve legal serializations. 

If I can't load an infoset, then turn around and deserialize it without
changing anything - and have my implementation of XML "break" your
signature, then I consider that a problem. I understand how many wouldn't
but in the long run you're just shooting yourself in the foot for some
upfront convenience.

And if you don't have an easily interoperable format.. Then what's the
purpose of CAP?

 - bri


-----Original Message-----
From: cap-list-bounces at lists.incident.com
[mailto:cap-list-bounces at lists.incident.com] On Behalf Of matt hoffman
Sent: Thursday, March 12, 2009 11:16
To: Rex Buddenberg
Cc: Hughes, William; cap-list at lists.incident.com
Subject: Re: [CAP] Then Again... (was Re: CAP Security
UsingDigitalSignatures)

What Art is suggesting is that we perform no canonicalization and treat the
XML just like an email, with the requirement that message handlers do not
alter the formatting of the message in any way.  That is a very valid
suggestion; I think there are pros and cons, but it does put a requirement
on message handlers that did not previously exist.  I would be more
comfortable with the decision after a.) more current implementors weigh in
on the feasibility of passing the original message through formatting
intact, and b.) getting some feel on the current state of XML
canonicalization, which apparently has moved forward in the last year.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.incident.com/pipermail/cap-list/attachments/20090312/3dab01f0/attachment.bin>