I would think very carefully before I looked at adopting the XML signature
specification for signing messages, especially if you are looking at only
doing partial signing of documents.
One of the biggest issues that has evolved over the development of this
specification is the concept of canonicalization. The problem with this is
that many XML parsers play games with whitespace (lose it, gain it, combine
it, ignore it) and an system where nodes read and write back out XML on the
way to deliver things can cause many problems of keeping data unchanged.
This is not generally a problem with the current mail system, but even still
you can get relays that will change CTE on body parts (generally from binary
to base64) and thus destroy signatures in S/MIME and PGP.
I would strongly advocate keeping the envelope and the transport properties
separate at least in the initial stages of thinking about things. Such
properites needs to be identified, formatted and the correct usage assigned
before we start even thinking about combining the two sets of properties
together.
jim
-----Original Message-----
From: owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Martin
Duerst
Sent: Sunday, February 01, 2004 11:33 AM
To: Paul Smith; mail-ng(_at_)imc(_dot_)org
Subject: Why XML (was: Re: What I see as problems to solve
... and a strawman solution)
At 15:10 04/02/01 +0000, Paul Smith wrote:
However, thinking about it a bit more, I can see reasons for XML -
<header> <to><name>fred
bloggs</name><address>fred(_at_)company(_dot_)com</address></to>
<to><address>jim(_at_)company(_dot_)com</address><name>Jim
Smith</name><comment>Director</comment></to>
...
</header>
would be more useful than the many ways to encode a To: field at the
moment, but that's about the only reason that I can come up
with. The
added complexity of XML parsing & generation, and the data
overhead may
or may not be worth it, IMHO, there are almost definitely
non-XML ways
of doing this.
One thing where I think XML could help a lot is to get some
order into the current header confusions. In particular, the
From:, Sender:, Reply-to:,... headers have been developed in
a somewhat ad-hoc fashion.
Rather than a mostly flat header structure and a two-level
distinction between (transport/SMTP) envelope and email body
(including headers), it seems to me more appropriate to have
a single format with some rather general wrapping
conventions. More on that maybe in another message.
A particularly interesting property for XML in the context of
email is that with XML digital signatures
(http://www.ietf.org/rfc/rfc3275.txt/
http://www.w3.org/TR/xmldsig-core/), you can sign arbitrary
pieces of a document, i.e. you can sign the body and some
headers, but not others. Also, the signature is not on the
bytestream, but on canonical XML. Together, these two
properties can alleviate quite a bit of the current problems
with signing email messages.
At 03:56 31/01/2004, Chuq Von Rospach wrote:
And anyway, why build a custom format that needs custom code to
decode, when you can use an existing system that allows for
existing
tools to do the packing and unpacking?
Because this assumes you have access to libraries which work on your
system which support parsing/creating XML. Let's assume
you're writing
a mailing system for a hardware device with a limited amount
of RAM &
ROM, and you only have assembler and C (if you're lucky) to
use, would
you still want XML?
Yes. The chances are that there are a few other things going
on on this system, even if it's very small. And a few of them
easily also use XML.
You might be surprised, but as far as I know, most of the
higher-end mobile phones these days support XML.
Regards, Martin.