Re: minimal canonicalization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 10:53 AM 7/25/2002 -0400, Joseph Reagle wrote:
>On Wednesday 24 July 2002 08:34 pm, Carl Ellison wrote:
>> We are using XML DSig to sign SOAP commands for UPnP.
>
>Is this Universal Plug and Play?

Yes.

>
>> In that case, you have a sender and a receiver.  If the sender is
>> powerful, it is generating the signature and controlling its
>> output, but it has no reason to use anything but C14N.  However,
>> the receiver is limited in CPU power (and possibly memory) and
>> needs to
>> canonicalize the incoming message in order to verify the
>> signature. That's the one that can't afford C14N.
>
>If you can constrain your process such that you know no
>intermediaries are  introducing particular sorts of changes, you
>might be able to go the  minimal route. However, if your using SOAP,
>I don't think that likely and  you're having to "detach" a SOAP
>message from the header, and you'll need  octet based means (and
>alignment to worry about) for this...

We thought we could get away with Minimal, but found disagreement
over whether the bytes on the wire could have pretty-printing white
space.  That's why I went looking and found the note that I sent to
start this mail thread.  The observation I wanted to offer this
mailing list is that unlike the way RFC3075 was worded, if you have
any constrained devices in your network, then all devices in the
network need to output C14N.


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPUFi18xqBGb+WvJAEQImlgCggXzZJSXyFS5dG6djc/IEFvD3QO8AoN/g
COSImBXVAUA0YKoWD26G7/tV
=8dX0
-----END PGP SIGNATURE-----


+--------------------------------------------------------+
|Carl Ellison      Intel Labs        E: cme@jf.intel.com |
|2111 NE 25th Ave                    T: +1-503-264-2900  |
|Hillsboro OR 97124                  F: +1-503-264-6225  |
|PGP Key ID: 0xFE5AF240              C: +1-503-819-6618  |
|  1FDB 2770 08D7 8540 E157  AAB4 CC6A 0466 FE5A F240    |
+--------------------------------------------------------+

Received on Friday, 26 July 2002 10:58:00 UTC